从部署一个embedding模型说起。我有天在容器里跑vllm/vllm-openai:v0.27.1加载qwen3-embedding-0.6b进去ps -ef发现了run_engine_core这个进程顺手ps -T -p pid看了一眼发现里面整整齐齐躺着三个线程。群里也有不少人问过run_engine_core进程里的三个线程到底是干嘛的为什么不能一个线程全干完这几个线程之间是各干各的还是有联动这篇文章就把我实际排查、看源码、压测过程中对这三个线程的理解完整写一遍能帮你看懂线程状态也能帮你定位部署大模型时常见的性能问题。1. 先搞清楚run_engine_core进程里到底能看到什么1.1 一次真实部署里的线程观察vLLM部署起来之后进程结构其实比想象中分层更明显。最顶层是API Server进程往下是run_engine_core再往下往往会看到一组GPU Worker。用ps -T -p pid观察run_engine_core进程典型状态下能看到三个业务线程对应关系可以简化成下面这样线程内部对应组件核心职责线程一Scheduler调度器决定每轮推理放哪些请求进batch管理KV Cache线程二ModelExecutor模型执行器真正跑Transformer forward调GPU线程三OutputProcessor输出处理器处理采样结果更新序列状态并生成响应在较新版本的vLLM里面这三个组件已经完全拆开各自跑在独立线程或者说独立异步循环里。这也解释了为什么你用py-spy dump --pid pid的时候经常能看到三个线程各自卡在不同的调用栈上一个卡在Scheduler._schedule一个卡在ModelRunner.execute_model还有一个卡在OutputProcessor.process_outputs。线程名的可读性不要抱太大期望。vLLM的线程并没有设置非常具体的业务名你直接ps -T看到的很可能就是python之类的一串名字。要确认线程到底在干什么最靠谱的手段是py-spy dump后面第4章我会专门演示。1.2 为什么偏要拆成三个线程这是很多人第一个问题调度、执行、输出处理串行在一轮循环里做掉不行吗当然行但GPU利用率会很难看。一个典型的单线程驱动循环长这样先调度CPU算几十毫秒再执行模型GPU算几百毫秒最后处理输出CPU再算十几毫秒。问题在于整个循环里GPU真正干活的时间占比只有T_execute / (T_schedule T_execute T_process)中间CPU忙的时候GPU全在空转。拆成三个线程后调度线程在GPU跑当前batch时就能提前准备下一个batch输出处理线程也能在处理上一轮结果的同时让执行线程立刻接续下一批输入GPU的空闲窗口被压到很小。这就是业界常说的延迟掩盖latency hiding也是vLLM高吞吐表现背后的核心原因之一。2. 三个线程各自在忙什么2.1 Scheduler线程真正的“排班系统”调度线程负责的是整个推理引擎的“排班表”。vLLM里每个请求进来后会被包装成SequenceGroup一个请求如果开了beam search就会对应多条序列Sequence。调度线程维护着这三类状态waiting刚进来还没轮到执行的请求running当前正在占用GPU执行前向的请求swapped因为显存不够被暂时“换出”的请求每轮迭代调度线程要回答一个核心问题本轮把哪些序列放进batch答案取决于当前还有多少KV Cache余量、每个序列还要生成多少token、最大允许的batch token数是多少。vLLM的continuous batching就体现在这里running里的序列一旦结束waiting里的新请求会立刻补上而不是等整个batch全部跑完。调度线程还要处理一个昂贵操作叫preemption。当KV Cache不够用的时候调度线程必须选中部分序列把这部分序列的KV Cache释放掉把已经算出的token固化下来这会导致这些序列从running挪到swapped。preemption非常耗CPU一旦发生频繁你的GPU利用率反而会下降这个我后面在问题排查部分细说。从源码实现来看_schedule阶段做的事情包括检查可用显存slot、处理swapped序列的重新调度、将waiting里的请求塞进running、对超长序列做preemption决策最终产出一个SchedulerOutputs。这个输出会被投递给模型执行线程。2.2 ModelExecutor线程唯一碰GPU的那只手模型执行线程拿到SchedulerOutputs后开始组装本轮真正要计算的内容。它需要做这些事把调度结果里的token ID拼成batch输入张量跑Embedding层跑Transformer的各层Self-Attention、FeedForward、Normalization跑最终的采样Sampling如果开了Tensor ParallelTP或Pipeline ParallelPP还要负责和多个GPU Worker通信协调这个线程是整个引擎里唯一直接发起CUDA Kernel的线程因此它的耗时基本决定了单次step的“地板时间”。你如果开nvidia-smi看到GPU利用率上不去又确认请求队列里明明有请求那大概率要顺着执行线程的调用栈去找原因。执行线程跑完前向之后会产出ModelOutput里面包含每个序列生成的下一个token的id、logprobs、隐藏状态等。这些结果不会直接返回给用户而是交给输出处理线程去消化。2.3 OutputProcessor线程负责“收拾残局”输出处理线程的工作容易被低估但实际上它才是决定响应能不能按时返回的那一环。它拿到模型输出后要做以下处理把新生成的token追加回对应的序列检查是否生成了EOS结束符或者是否超过了长度限制处理beam search里需要保留的候选序列更新序列组的分数、长度、是否完成等状态对完成的序列生成最终的响应内容返回给上层API释放掉已完成序列占用的KV Cache slot让调度线程下一轮可以复用可以这么理解调度线程决定“谁进来”执行线程负责“跑一遍”输出线程决定“跑完的结果怎么收走”。输出处理线程如果处理慢了会出现一个很有趣的现场GPU早就跑完了但下一批batch迟迟没有提交因为上一批输出的KV Cache还没释放序列状态还没更新完。这种情况下GPU利用率会掉但你用nvidia-smi看显存用量却是满的。3. 三个线程怎么协作不是无脑并行而是流水线步进3.1 数据流与同步机制三个线程之间是典型的生产者-消费者模型数据靠内部队列或帧缓冲传递。流程大致如下新请求 - Scheduler线程 - SchedulerOutputs - ModelExecutor线程 - ModelOutput - OutputProcessor线程 - 更新序列状态/KV Cache - 下一轮Scheduler每一轮step三个线程各自处理一个阶段的产物但它们之间存在严格的依赖关系下一轮调度的前提是上一轮输出已经被处理完因为KV Cache分配表必须在调度前保证是最新的。vLLM内部通过类似step barrier的机制来对齐这一轮三线程各自完成的时间点保证三个阶段的边界一致。实际到代码层面你会看到last_outputs、cache_events这类变量在协调推进。旧版本里直接用Condition、Lock新版本引入了更多异步条件变量和asyncio.Queue。这里的要点不在于具体实现细节而在于你理解它是一种“依赖步进”的流水线不是三个线程各跑各的map-reduce。3.2 三线程带来的吞吐收益怎么算假设一轮step里调度耗时T_schedule 20ms模型执行耗时T_execute 120ms输出处理耗时T_process 15ms单线程串行方案下一轮耗时约155msGPU利用率约120 / 155 77%。三线程流水线方案下理想稳态每轮耗时约等于max(20, 120, 15) 120msGPU利用率理论上接近100%。虽然实际因为有同步损耗、GIL争抢达不到理论值但吞吐提升是实打实的。这也是为什么同样一块A10不改模型、不换显存单纯把vLLM从老版本升到新版本decode吞吐能提升一截的原因之一。需要说明的是三线程内的Python代码部分仍受CPython GIL约束不可能真正同时跑Python指令。vLLM之所以能绕开这个限制是因为模型执行线程把重计算都下沉到了PyTorch/CUDA Kernel里Kernel执行时GIL会释放所以GPU真正长时间跑的时候调度线程和输出处理线程在CPU上依然可以穿插执行。3.3 一轮step的完整时序实例按时间线看一轮step大概是这样的t0时刻调度线程完成schedule()把本次batch的SchedulerOutputs写入缓冲通知执行线程。t1时刻执行线程被唤醒发现GPU空闲立刻提交CUDA Kernel开始跑batch N的前向。执行线程跑batch N的同时调度线程没有被阻塞可以回去准备下一轮请求的排班输出线程同时也在处理batch N-1的结果两者在CPU上争夺GIL但因为执行线程在CUDA里释放了GIL这一轮整体错开了。t2时刻执行线程完成batch N把ModelOutput交给输出处理线程自己拿到下一轮的SchedulerOutputs假设调度线程已经准备好了继续跑batch N1。输出线程处理batch N的同时batch N1已经在GPU上跑了流水线建立完成。这套模型在压测高并发时表现最明显请求背后基本不断流某个请求的响应延迟略有增加但整体吞吐接近“GPU不空转”的极限。4. 实操观察如何确认三个线程在干什么4.1 用系统命令先看线程数量和PID进入容器或宿主机后找到run_engine_core进程ID用以下命令看线程ps -ef | grep run_engine_core ps -T -p pid top -H -p pid如果你用的是容器部署注意容器内可能没有完整的psps命令依赖procps包缺少时可以先apt-get update apt-get install -y procps。top -H可以实时看每个线程的CPU占用这对定位某个线程是不是在空转或忙等非常有用。4.2 用py-spy看Python线程调用栈ps -T只能告诉你线程数量不能告诉你线程在干什么。最直接的办法是py-spy。先安装pip install py-spy然后对目标进程做线程栈dumppy-spy dump --pid pid输出里会列出每个Python线程当前正在执行的函数调用栈。正常稳定运行状态下你大概率能看到某个线程停在Scheduler._schedule或Scheduler.schedule相关调用栈一个线程停在ModelRunner.execute_model或AdapterModelRunner相关调用栈还有一个线程停在output_processor相关的调用栈。这样三个线程的对应关系就一目了然了。py-spy在生成环境下会短暂暂停进程生产中如果业务敏感建议先用小流量测试或者直接靠metrics判断不到万不得已不要生产环境乱dump。4.3 用日志和指标佐证线程状态vLLM一些版本里可以开启更详细的日志export VLLM_LOG_LEVELDEBUG这样run_engine_core的step推进、调度决策时机都会被打印出来。另一个更稳的手段是让vLLM暴露Prometheus metrics。mmap指标里有几个跟调度和执行高度相关的计数比如vllm:engine_generation_tokens_total生成token总量判断执行线程是否有产出vllm:engine_num_preemptions_total抢占次数调度线程压力的直接信号vllm:engine_time_to_first_token_seconds首token延迟能侧面反映调度线程排队情况如果num_preemptions_total持续快速上涨而生成token总量增长缓慢那基本可以断定调度线程陷入了preemption风暴。4.4 一个容易被忽略的前提先确认镜像版本三个线程的观察结果和vLLM版本强相关。老版本vLLM比如0.3、0.4早期的驱动循环还比较接近单线程串行风格你去看run_engine_core进程里的线程不一定能清清楚楚看到三个业务线程各自卡在三个调用栈上。如果你用的镜像是vllm/vllm-openai:v0.27.1这一代新镜像三组件拆分的特征已经很明显线程关系基本就是我上面描述的这套。部署大模型之前先确认镜像版本可以避免拿着老版本的线程现象套用新版本逻辑越查越懵。5. 常见问题与排查实录5.1 调度线程卡住GPU利用率低但请求一大堆现象请求并发很高但nvidia-smi里GPU利用率一直上不了60%ps -T看线程耗时发现某个线程CPU占用极高。这种场景我遇到过两次一次是负载里混了大量超长prompt另一次是KV Cache规划明显偏保守导致频繁preemption。preemption会让调度线程做大量额外计算要找到被抢占的序列、把对应的KV Cache写回CPU、更新调度表。这一套动作走完执行线程拿不到新batchGPU只能空等。排查思路先看vllm:engine_num_preemptions_total指标有没有快速上涨然后用py-spy dump看调度线程的调用栈是否长时间停在schedule相关函数里。缓解手段给KV Cache预留更多空间比如调大gpu_memory_utilization例如从0.85调到0.92降低触发preemption的概率检查max_num_batched_tokens和max_num_seqs是否和实际负载匹配如果长prompt是常态考虑把--preemption-mode配置调整好或者减少max_model_len让KV Cache能容纳更多并发序列调度线程的设计目标本来就是轻量快进快出。一旦它变成瓶颈GPU利用率必然下滑这不是模型算力不够是“排班”追不上“干活”。5.2 输出处理线程堆积GPU空转显存却一直占满现象nvidia-smi里显存占用很高但GPU计算利用率却在往下掉响应延迟明显变大。输出处理线程的调用栈卡在process_outputs或者是采样结果解析相关的函数上。输出处理线程堆积常见于高n值、高best_of的生成请求。一次请求背后挂着一堆候选序列每个序列都要更新状态、维护堆结构、做beam search筛选这些全在Python层跑非常消耗CPU时间。如果这时候调度线程也在忙于preemption两个线程互相抢GIL情况会更糟GPU跑完一个batch后迟迟拿不到下一个batch的输入。缓解手段不要盲目调大单请求的best_of和n能用一个候选序列解决的不要开beam search降低batch token上限给输出处理线程留出更多CPU时间片如果确实是Python层输出处理太重考虑换用带优化输出处理的新版本vLLM镜像后续版本对这块有持续优化5.3 GIL导致的三线程“假并行”问题三个线程是拆了但CPython的GIL仍在。调度线程和输出处理线程如果都是纯Python计算密集代码它们实际上无法真正做到CPU并行只能靠GIL按时间片切换。vLLM能把吞吐做上去核心原因是模型执行线程在CUDA Kernel里释放了GILGPU真正在跑的时候另外两个线程有机会在CPU上跑。但如果你把GPU换成一个极小模型比如qwen3-embedding-0.6b这种小embedding模型模型执行时间很短GIL的切换反而可能成为开销大头这时候三个线程的“排队感”会更明显。这也是为什么小模型部署时有时候加大并发反而收益不明显的潜在原因之一。模型太小GPU还没跑几毫秒就跑完了大量时间花在调度、输出处理这些Python操作和线程同步上。5.4 部署场景的镜像选择和模型加载阶段线程表现vllm/vllm-openai:v0.27.1加载qwen3-embedding-0.6b这类embedding模型时这三个业务线程在后端推理阶段的表现会比纯生成模型更轻因为embedding任务基本不需要逐token生成采样和输出处理逻辑简单许多。真正重的线程压力往往出现在模型加载阶段那时候跑模型加载的worker线程会并行工作和后面的三个业务线程是两回事。如果部署的是DeepSeek、GLM这类大模型情况反过来scheduler和output processor的线程开销会被模型decode时间掩盖掉但KV Cache管理、preemption、prefill的调度策略会直接决定你能承载多少并发。GLM系列用户我在实践里给的建议是优先用官方镜像版本不要盲目追小版本号因为不同小版本对模型结构的算子支持有差异。5.5 线程卡死与死锁判断怎么从容恢复如果py-spy dump看到三个线程长时间各自卡着不动且top -H显示各自CPU占用都很低这是典型的死锁特征。vLLM本身的线程死锁在正常使用中不常见但当你同时启用多个CUDA context、跑多进程数据并行比如multiprocessing加载多个模型线程之间可能因为CUDA context锁互相等待。遇到这种现场先别急着kill -9可以按以下顺序处理抓py-spy dump留证据再看nvidia-smi确认是否有CUDA kernel疑似卡死抓pstack看原生线程栈确认是不是卡在CUDA runtime的锁上如果确认锁死最稳的是直接重启推理容器然后缩小并发重现范围逐项排除是哪个自定义配置触发的我自己的习惯是每次部署前固定录制一份正常状态下的py-spy dump存档出问题时可对比调用栈差异能省大量排查时间。6. 最后分享一点实践经验这几个线程的关系理清楚之后再去看vLLM的部署和调参逻辑会顺很多。我自己调试时最常用的判断流程就是先看GPU利用率再确认平滑指标最后用py-spy dump定位线程卡点。三者互相印证基本能把性能问题归类到调度、执行、输出处理三个阶段中的某一环。还有一个小技巧压测时别只盯着首token延迟和总吞吐顺手记一下每轮step的token产出速率和preemption计数。调度线程哪怕慢1ms放大到成千上万次step里GPU的空转时间都会被拉得很明显。反过来输出处理线程的优化空间往往被你忽略因为GPU利用率好看并不代表响应延迟合理。最后镜像版本升级这件事真的别偷懒。旧版本vLLM的单线程驱动在低并发场景下问题不明显但一上压测、一上线多用户调用线程拆分带来的吞吐差异立刻拉开。遇到性能问题先看版本再谈调参。按我上面的思路把三个线程的职责和协作关系吃透再去看官方源码的效率会比以前高很多。