vLLM作为主流的LLM推理引擎，其部署中常现GPU利用率卡在85%而CPU却100%拉满的怪象。这不仅不是故障，反而是高效协同的体现。深入理解其工作逻辑，能帮助工程师规避优化误区，精准定位瓶颈，从而以更低的成本实现更优的系统性能。
智能速览
vLLM推理是GPU与CPU协同工作的流水线工程。
GPU利用率受限于推理的Prefill与Decode两个计算阶段。
Decode阶段的内存带宽瓶颈是GPU无法满载的核心原因。
CPU过载主因是承担了Tokenization、调度与采样等协调工作。
盲目增加GPU并非良策，CPU与GPU性能平衡才是关键。
精华内容
要理解这种“反常”现象，需深入vLLM的工作内核，剖析GPU与CPU在其中扮演的真实角色与协同逻辑。
协同工作流
vLLM的推理过程并非GPU的独角戏，而是一场精密的GPU与CPU协同配合。整个流程分为8步：从接收请求、文本转Tokenization，到请求调度批处理，再到GPU执行核心的前向传播计算，最后由CPU完成采样、Token解码和流式返回。其中，GPU仅负责核心计算环节，而CPU则承担了其余6步的协调与处理工作，是名副其实的“全能协调员”。
这种分工决定了两者必然存在资源占用差异，CPU的工作量远比想象中要大。
GPU为何不满载
GPU使用率稳定在70%-85%是正常现象，主要由两个核心因素决定。首先，大模型推理分为Prefill（提示词处理）和Decode（逐token生成）两阶段。Prefill阶段计算密集，GPU使用率可飙升至近100%，但仅持续几百毫秒；而占大部分时间的Decode阶段是串行计算，GPU使用率通常只有50%-70%。
其次，在Decode阶段，系统瓶颈是显存带宽而非计算核心。GPU需要频繁读取KV缓存，显存带宽先被占满，导致计算核心处于“半空闲”状态。这如同高性能跑车行驶在拥堵路段，动力无法完全释放。
CPU为何常拉满
CPU使用率突破100%甚至更高，是因为它承担了繁重的协调任务。关键场景包括：处理长提示词时的Tokenization操作，这对单线程CPU是巨大负担；高并发下的请求调度与KV缓存管理；每生成一个token就执行一次的采样逻辑；以及流式返回时带来的网络处理开销。
这些任务在高并发场景下会累积消耗大量CPU资源，导致CPU使用率飙升。当看到CPU使用率达到800%时，在8核CPU上即意味着所有核心已全力工作。
优势而非隐患
这种“GPU留力、CPU主导”的模式，实际上是vLLM的设计优势。它让GPU专注于并行计算，避免了被协调任务浪费算力，从而提升了系统吞吐量和稳定性。同时，用成本更低的CPU处理调度，有助于降低整体部署成本。
然而，隐患在于CPU配置过低或参数设置不当，会导致CPU过载并拖累GPU，造成系统性能下降。因此，实现CPU与GPU的性能平衡，避免“一头强、一头弱”，是发挥vLLM最大效能的关键。
部署优化策略
理解了底层原理，优化便有了明确方向。首先可调整vLLM的核心参数，如增加–max-num-seqs（最大序列数）和–max-num-batched-tokens（最大批处理token数），提升批处理效率。其次，如果CPU常年过载，应优先升级CPU核心数，增强其协调能力。
此外，应确保单GPU上只运行一个vLLM进程，避免资源争夺。通过这些方法，可以实现系统从“CPU过载、GPU空闲”到“CPU稳定、GPU高效”的转变，显著提升整体性能并节省成本。
理解vLLM的GPU与CPU协同机制，是通往高效低成本部署的必经之路。它不仅能解决当下的性能困惑，更能为未来的系统优化提供清晰指引。面对日益复杂的LLM服务需求，你准备好平衡好这套“动力总成”了吗？
