在现实里看到4 hours and 37 minutes of serving nothing这种日志第一反应多半不是惊讶而是想立刻去查服务进程还活着没有。这个标题其实代表了一类很常见的本地部署问题服务进程在跑端口能访问GPU/CPU 也可能有占用但任务发进去之后就像进了黑洞几分钟、几十分钟甚至几个小时都没有有效输出。如果这是线上服务等于白白烧了几个小时算力还找不到任何明确的报错。这篇文章来拆解这类问题。不只是讲“现象是什么”而是给出一套可以照着走的排查流程先确认服务是否真的可用再逐层检查资源占用、日志、推理链路、队列和 API 超时最后给出预防空跑的工程化建议。无论你是在跑大模型推理服务、ComfyUI 工作流、TTS 任务还是 OCR 批量解析这套方法都适用。先给结论“服务空跑”通常不是单一原因而是从请求进入、资源分配、模型推理到结果返回的某个环节出现了静默阻塞。排查顺序比排查工具更重要下面按顺序展开。1. 核心问题速览空跑问题边界与排查维度先看清楚“serving nothing”可能出现在哪些层面避免一上来就陷入某个细节。通常可以从下面几个维度判断问题边界排查维度典型现象常见 Root Cause进程层进程未退出CPU/内存占用正常死锁、队列阻塞、等待外部资源资源层GPU 利用率低但显存占用高显存碎片、静态分配、批次未提交日志层无 ERROR也无进度输出日志缓冲、错误被吞、输出级别过高网络层客户端请求已发送服务端无响应连接池耗尽、Keep-Alive 卡死、代理超时模型层模型加载后推理无输出数据预处理卡住、推理后端崩溃未退出业务层批量任务队列长期不消费并发数设置过大、单任务超时无兜底这张表的含义是排查时不要只看有没有报错而是要对整个请求生命周期做分段观测。很多空跑问题恰恰是“没报错但没结果”比显式崩溃更难定位。2. 适用场景谁最需要这套排查方法这篇文章的读者不需要特定项目背景但以下场景最容易遇到“空跑”本地部署 LLM / Stable Diffusion / TTS / OCR 等模型服务通过 WebUI 或 API 对外提供推理能力。使用 ComfyUI 或其他工作流引擎跑批量任务队列积压却看不到任务进度。编写定时脚本调用推理接口返回超时后脚本不退出任务堆积。把推理服务封装成容器或 systemd 服务设置了高并发请求但某些请求导致服务整体不可用。在批量场景中上游任务一批一批进入下游偶尔发生长时间无输出最终通过日志才发现出现了4 hours and 37 minutes of serving nothing这类空转记录。如果只是偶尔一次重启服务可能就能恢复。但如果是批量任务、定时服务、长连接 API这种问题会反复出现必须从机制上解决。3. 第一轮检查先确认服务是不是“假活”很多情况下服务看着在运行但实际已经无法接收或处理新请求。这一步的目标是快速分清“服务崩了但进程没退出”和“服务还能正常接收请求”的差别。3.1 健康检查接口与行为探测如果服务提供了/health或/ready之类的健康检查接口先调用它# 假设服务监听在 127.0.0.1:8000 curl -v --max-time 10 http://127.0.0.1:8000/health观察几个关键信息是否有 HTTP 状态码返回。是否几秒钟内就返回还是一直阻塞到超时。返回内容是ok还是包含模型加载状态、队列长度、GPU 状态。如果健康检查接口本身长时间不响应说明服务主循环已经阻塞问题很可能在线程调度、锁竞争或事件循环卡死。如果健康检查正常但推理接口无输出说明问题在具体推理链路而不是服务整体。3.2 验证端口监听和连接状态# 查看 8000 端口是否在监听以及当前 accept 队列 ss -lntp | grep 8000 # 查看已建立的连接数量和等待队列 ss -antp | grep 8000 | head -n 50 # 查看进程是否存在 ps aux | grep -E python|uvicorn|comfyui | grep -v grep重点看 ESTABLISHED 连接数量是否持续增长但 FIN_WAIT / CLOSE_WAIT 堆积。如果是通常是客户端发起请求后没有正确读取响应或者服务端处理线程没有释放连接最终把连接池耗尽新请求全部排队。3.3 最小请求探测法调用一个最简单、保证能出结果的接口而不是直接提交重任务# 常用推理服务的通用探测请求具体字段需要按实际项目调整 curl --max-time 30 http://127.0.0.1:8000/api/generate \ -H Content-Type: application/json \ -d {prompt: hi, max_tokens: 8} # 记录返回时间 time curl --max-time 30 http://127.0.0.1:8000/api/generate \ -H Content-Type: application/json \ -d {prompt: hi, max_tokens: 8}最小探测请求的意义在于它能区分“所有请求都卡住”和“只有特定请求卡住”。如果最小请求也卡住说明推理后端有问题如果最小请求很快说明是特定任务的输入、参数或队列策略引发阻塞。4. 第二轮检查资源层到底发生了什么服务进程看着是正常的资源占用却可能出卖它。这里说的资源不只是 GPU还包括 CPU、内存、磁盘 I/O。4.1 GPU 状态观测先看 GPU 整体资源情况nvidia-smi再看具体进程占用nvidia-smi --query-compute-appspid,used_memory,process_name --formatcsv然后持续观测变化watch -n 2 nvidia-smi需要重点关注三种状态状态说明GPU-Util 长期为 0显存占用很高模型加载后没有推理请求或批次没有提交或者显存分配后未释放GPU-Util 在 0 和 100 之间频繁跳动推理在跑但可能卡在 CPU 预处理、后处理或数据加载上GPU 进程消失但显存仍占用进程退出未释放显存或存在僵尸进程如果任务是图片生成、视频生成类还要看 GPU 工作频率和功耗。如果频率一直很低可能是推理任务根本没有进入 kernel 执行阶段。4.2 CPU / 内存 / 磁盘 I/Otop -H -p $(pgrep -f 你的服务进程名 | head -n 1) # 查看是否存在大量 D 状态进程不可中断睡眠 ps -eo pid,stat,wchan:30,cmd | grep -E D|服务进程名如果某个进程长期处于 D 状态说明它正在等待磁盘 I/O。这类问题在批量文档解析、大量视频抽帧、模型反复加载的场景特别常见输入输出目录放在网络磁盘上网络波动导致 read/write 挂起任务队列全部堆住。4.3 显存不足的“静默表现”显存不足未必直接抛CUDA out of memory。在有些推理框架中申请显存失败会进入重试循环或者退回 CPU 推理或者干脆暂停任务等待显存释放。此时日志可能只是“等待资源”但没有任何有效输出。从材料和技术常识来看更稳妥的判断是显存问题不能只看有没有报错要看任务是不是在等显存。可以在任务运行期间采样显存变化曲线观察是否存在持续申请但从未释放的显存碎片增长。5. 第三轮检查日志与错误码重点找“被吞掉”的异常空跑问题最棘手的地方是日志里常常什么都没有。但“没有日志”本身也是一种信息。下面几类情况很典型5.1 日志级别和输出缓冲如果服务使用 Python 的print或logging并且被重定向到文件输出可能被缓冲导致进程实际已经打印了大量日志但文件里什么都没有。排查时先确认输出模式。建议在启动命令中强制禁用缓冲# Python 服务通用做法具体脚本名按实际项目替换 python -u app.py server.log 21 # 如果使用 uvicorn注意 access log 和 error log 是否分开 uvicorn app:app --host 0.0.0.0 --port 8000 --log-level debug server.log 21如果日志已经堆积很久重启前先看文件大小判断是否还在写入ls -lh server.log tail -n 200 server.log5.2 依赖库的静默失败很多 infer 库底层是 C / CUDA 实现Python 侧可能只捕获到通用异常甚至不捕获。常见现象是模型文件损坏加载阶段返回 null但服务没退出。CUDNN / TensorRT 初始化失败进入重试循环。图像解码失败某个 batch 的数据预处理直接返回空但后续流程还在等待。排查时可以把日志级别调到 debug并且给关键调用加上显式超时。不要假设底层库会用raise上报错误。5.3 资源句柄泄漏与文件锁如果服务长时间运行很容易出现文件句柄耗尽# 查看进程文件句柄数量 ls /proc/pid/fd | wc -l # 查看限制 cat /proc/pid/limits | grep open files句柄耗尽后新任务无法打开模型文件、输出文件或日志文件表现就是任务“无输出”。这类问题不容易从业务日志中看到但系统日志里通常会有Too many open files。5.4 CUDA 错误与上下文损坏CUDA 上下文损坏后后续所有调用都可能失败但 Python 进程不退出。此时可以尝试在代码里定期检查 CUDA 状态或者用cuda-memcheck做诊断。不过最直接的验证方式还是重启服务后重新提交小任务看是否恢复。如果重启后正常说明问题大概率发生在运行过程中的某个 CUDA 操作或显存状态上。6. 第四轮检查推理链路分段定位假设服务本身没有假活日志也正常这时需要把“请求到输出”的全链路拆开逐段确认卡在哪里。这里给出一种通用分段思路。6.1 请求接收与参数校验服务端是否已经接收到请求请求体是否完整# 在服务端入口处增加调试输出属于通用示例路径需按项目调整 app.post(/api/generate) async def generate(request: Request): body await request.json() logger.debug(request received: keys%s, list(body.keys())) # 如果这里能打出日志说明请求已经到服务端如果这里的日志没有输出问题在网关、负载均衡或网络层。如果有输出说明进入业务处理逻辑。6.2 队列与并发控制大多数推理服务会先把请求放入队列由后台 worker 消费。空跑常见原因队列满了新请求阻塞等待。worker 数量为 0 或全部卡死。某个任务执行时间过长没有超时控制把唯一 worker 占死。查看队列长度# 通用思路如果是 Redis 队列 redis-cli LLEN task_queue # 如果是 Python multiprocessing 队列需要从代码侧写监控 # 如果是 pg 或 mysql 表驱动任务直接查表如果队列一直在增长但没有 worker 消费重点检查 worker 是否启动、是否因为异常退出未重启、是否有全局锁阻塞。6.3 数据预处理与输入文件读取很多空跑发生在“读输入”阶段。例如批量图片中的某一张损坏解码卡住。视频抽帧时某帧序列异常。输入文本编码不是 UTF-8解析卡住。输入文件来自对象存储或网络磁盘下载超时。排查方法先输入最小、最简单、已知完整的样本确认流程能跑通。然后再逐步替换为真实样本直到定位到导致卡住的具体输入。6.4 模型推理后端如果在预处理之后日志停留在“正在推理”但没有结束时间重点关注推理后端状态。# 查看进程内线程数确认是否存在多个阻塞线程 top -H -p pid pstree -p pid | wc -l # 如果是 Java 服务可以用 jstack jstack pid thread_dump.txt # 如果是 Python 服务可以用 py-spy 做采样 py-spy dump --pid pidpy-spy dump对 Python 进程很有用可以快速看到当前线程栈卡在哪个函数。如果线程栈显示卡在 CUDA runtime 调用问题大概率在底层推理如果卡在文件读写问题在 I/O如果卡在queue.get()问题在生产者-消费者链路。6.5 后处理与响应返回推理本身可能已经完成但后处理阶段卡住。例如生成结果需要组装成 JSON 或 Markdown但某个字段类型不匹配导致死循环。输出目录无法写入进程在重试。流式响应没有 flush客户端等不到任何数据。在返回响应的代码处加上时间戳日志对比请求进入时间就可以判断是否卡在后处理。7. 批量任务场景为什么队列会空跑数小时回到标题4 hours and 37 minutes of serving nothing批量任务最容易出现这种长时间静默。如果单看某一次任务可能几秒钟就完成但放到批量场景里几个不小心的设计会放大成几小时的空转。7.1 并发数远超实际处理能力任务提交方并发拉满推理服务或下游模型只能串行处理请求全部堆积在队列里。服务看起来“在工作”但某些请求已经超时对调用方来说就是无输出。排查方法查看任务队列堆积数量。查看每个任务从入队到完成的时间分布。查看是否有很多超时重试导致下游积压更严重。7.2 失败任务没有跳过机制一个批次里如果有 10% 的任务因输入损坏或依赖问题失败而代码没有捕获异常整个批次可能停住。有些框架表现得像“还在跑”实际上已经卡在某个失败的子任务上。通用做法是给每个子任务单独捕获异常并记录失败原因而不是让整个批次中断。import concurrent.futures from typing import Callable def run_batch_with_fault_tolerance( items: list, worker: Callable, max_workers: int 2, timeout_per_item: int 60, ): results {} with concurrent.futures.ThreadPoolExecutor(max_workersmax_workers) as executor: future_map { executor.submit(worker, item): idx for idx, item in enumerate(items) } for future in concurrent.futures.as_completed(future_map): idx future_map[future] try: results[idx] future.result(timeouttimeout_per_item) except Exception as exc: results[idx] {error: str(exc), idx: idx} return results7.3 没有任务级超时这是批量空跑最重要的原因。一个任务如果没有硬超时下游卡住时上游会一直等。单个任务卡住不可怕可怕的是卡住的任务不释放线程/进程/显存最终拖垮整批任务。建议对单任务设置超时。对批量任务设置整体进度监控。超时后记录堆栈和输入信息避免下次再踩。7.4 幂等与重试设计如果任务重试后状态没有正确重置可能造成“重试永远失败但永远在重试”。例如任务已经处理完成但状态没更新重启后又重新处理。输入目录和输出目录混用任务互相覆盖文件。重试时没有清空临时目录旧文件被当作新结果。批量任务要尽量做到输入不可变、输出隔离、状态可查询、失败可重试且重试结果一致。8. API 服务层的连接卡死与资源泄漏serving nothing在 API 服务中往往表现为“连接建立成功但一直等到超时”。这个现象可以从连接生命周期来排查。8.1 连接池配置问题线程池或连接池过小任务并发量上来之后请求只有一个假象进程还在运行但新请求已经无法获取可用连接。以 Pythonrequests.Session为例默认连接池大小是 10。如果某个批量服务用同一个 Session 发起大量并发请求很容易出现连接池耗尽import requests from requests.adapters import HTTPAdapter session requests.Session() adapter HTTPAdapter(pool_connections20, pool_maxsize20, max_retries3) session.mount(http://, adapter) session.mount(https://, adapter)这只是一个通用示例实际连接池大小需要根据服务并发数调整。关键是连接池不是越大越好过大会压垮下游过小则会导致请求排队。8.2 服务端线程模型如果服务端使用多线程模型每个请求创建一个线程任务卡住时线程不会释放。线程数量达到上限后新请求无法被处理但服务主进程仍然存活。排查命令# 查看进程线程数 cat /proc/pid/status | grep Threads # 或通过 ps 查看 ps -eLf | grep 服务进程名 | wc -l一旦线程数持续增长或接近上限基本可以判断存在线程泄漏。需要从代码层面约束并发数例如使用 Semaphore 或任务队列。8.3 请求超时设置很多空跑问题其实是因为客户端没有设置超时。默认情况下某些 HTTP 客户端在连接建立后会无限等待响应。此时服务端可能已经崩溃或卡住但客户端毫不知情。# 通用 curl 示例设置连接超时和总超时时间 curl --connect-timeout 10 --max-time 120 \ -H Content-Type: application/json \ -d {prompt:test} \ http://127.0.0.1:8000/api/generate代码中也应该显式设置超时import requests try: resp requests.post( http://127.0.0.1:8000/api/generate, json{prompt: test}, timeout(10, 120), # (connect timeout, read timeout) ) resp.raise_for_status() except requests.exceptions.Timeout: print(request timeout, need check server status) except requests.exceptions.RequestException as exc: print(frequest failed: {exc})8.4 反向代理与负载均衡如果服务前面还有 Nginx 或网关需要同时检查代理层的超时配置。有些问题发生在服务端已经返回结果但代理层没有及时转发给客户端导致客户端一直空等。排查时可以绕过代理直接访问服务端口对比响应时间。9. 资源占用与性能观察的工程化方法只做一次nvidia-smi和top不足以定位长时空跑更重要的是形成持续观测能力。资源占用本身不会告诉你“为什么空跑”但能帮你缩小范围。9.1 建立黄金指标建议给推理服务建立四组指标指标组典型指标流量QPS、请求进入数、完成数、失败数延迟P50 / P95 / P99 延迟、平均响应时长资源GPU-Util、显存使用、CPU 使用率、内存占用队列队列长度、任务入队时间、任务完成时间如果“请求进入数”远大于“请求完成数”说明任务在积压。如果两者都很少但 GPU-Util 很高说明可能在做无用计算或死循环。9.2 慢请求日志与采样当任务执行时间超过阈值时主动记录一条结构化日志。日志不要只记录“任务超时”还要记录输入标识、执行到哪个阶段、资源占用快照。import time import logging logger logging.getLogger(inference) class TimingMiddleware: def __init__(self, app, slow_threshold: int 30): self.app app self.slow_threshold slow_threshold async def __call__(self, scope, receive, send): start time.time() await self.app(scope, receive, send) elapsed time.time() - start if elapsed self.slow_threshold: logger.warning(slow request, elapsed%.2f, scope%s, elapsed, scope.get(path))具体中间件写法要视 Web 框架而定但核心思想一致只有主动记录慢请求才不用在出问题时靠猜。9.3 周期性抓取堆栈如果服务已经空跑数小时只能通过堆栈判断当时卡在哪里。具体做法是周期性执行py-spy dump或jstack保存多次快照。如果多次快照都停在同一个位置基本定位到瓶颈。9.4 保留“最小可复现样本”每次排查后把触发问题的最小输入样本单独保存。不要只保存完整数据集。最小样本加上当时的日志、堆栈和资源占用就是下一次排查最有效的起点。这比任何告警规则都更能降低问题定位成本。10. 常见问题与排查对照表这里把实际排查中最高频的问题整理成表格便于对照。问题现象可能原因排查方式解决方案服务启动后端口可访问但所有请求无响应主循环阻塞、事件循环卡死、锁竞争健康检查接口、堆栈快照定位死锁或 I/O 阻塞增加主循环看门狗GPU 显存占用高但利用率低模型已加载但未推理显存碎片多次采样 nvidia-smi结合任务状态检查请求是否真正进入推理阶段必要时重启释放显存日志没有任何输出输出缓冲、日志级别过高、日志写入失败确认输出是否重定向用-u或--log-level debug调整日志配置增加启动时间戳标记批量任务队列堆积worker 卡死、并发过大、失败任务未跳过查询队列长度查看 worker 线程增加任务级超时、失败跳过、并发限制小请求正常大请求卡住显存不足、数据预处理太重、请求体过大逐步缩小输入观察任务阶段日志分批处理、降低输入规模、显存不足时加合理错误处理客户端超时但服务端认为已完成反向代理超时、响应未 flush、连接被关闭绕过代理直连测试抓包对比返回调整代理超时修复流式响应 flush进程长时间 CPU 100% 但无输出死循环、正则灾难、批量处理逻辑异常py-spy dump或top -H定位热点代码增加循环次数保护重启服务后恢复资源泄漏、句柄耗竭、CUDA 上下文损坏对比启动前后资源变化增加资源监控和定期重启策略11. 避免空跑的最佳实践清单从工程化角度建议在服务上线前就做以下设计。每一条都能降低4 hours and 37 minutes of serving nothing出现的概率。11.1 给所有外部调用设置默认超时无论是模型推理、数据库访问、文件读取还是 HTTP 请求都要设置超时。不要让任务无限制等待。这是最简单但最有效的一步。11.2 增加任务级进度回传如果是批量任务每个任务完成时都更新状态。不要只记录“队列里有多少任务”还要记录“正在处理哪个任务、完成多少、失败多少”。这样即使出现问题也能快速定位到具体任务和输入样本。11.3 使用结构化日志日志至少包含任务 ID、阶段、耗时、输入标识、错误详情。纯文本日志在排查长时空跑时很难过滤。11.4 独立资源限制GPU 显存、线程池、连接池、队列大小都要设置上限。无限资源上限意味着问题发生时只能靠重启解决。11.5 定期最小化自检服务启动后可以加一个自检任务提交一个最小请求确认模型能正常返回。自检失败就标记服务不健康而不是等到外部调用超时才发现。11.6 输出与输入严格隔离输入目录、临时目录、输出目录分开放任务之间不要共用临时文件。否则一旦某个任务失败留下脏文件后续任务可能一直读到错误数据。11.7 显存使用要能回收对于长驻推理服务模型权重不重复加载但中间结果和 feature map 要确保在不同请求之间不残留。如果显存占用持续增长优先考虑是否存在缓存未清理或自定义算子内存泄漏。12. 遇到空跑后的快速行动顺序如果现在你的日志里也出现了长时间没有输出的记录按这个顺序处理先看进程状态和端口判断服务是否假活。发送最小探测请求验证基本推理链路是否可用。看 GPU / CPU / 磁盘 I/O确认资源层是否有异常。调到 debug 日志观察请求进入、预处理、推理、后处理各阶段时间点。如果日志停在某个阶段抓一次线程堆栈或进程堆栈。检查队列长度和 worker 状态确认是否批量任务积压。如果有失败子任务被跳过或异常被吞掉先恢复该任务并记录原因。临时方案优先重启服务并保留重启前日志和堆栈。长期方案是补上超时、慢请求日志、批量任务监控和自检任务。这套顺序的核心是先“止血”再“定位”最后“防复发”。不要一上来就翻代码也不要一上来就全量重启服务。先保留现场再做最小化验证这是最快也最稳妥的做法。4 hours and 37 minutes of serving nothing这类日志不是笑话是成本。只要把请求生命周期分段观测、给关键环节设置超时、用日志和监控覆盖“静默失败”大部分空跑问题都能在十几分钟内定位到具体环节而不是等到几小时后才发现。建议在下一个批量任务上线前先把最小自检、任务级超时和慢请求日志这三件事补上它们的性价比远高于任何复杂的监控系统。