第二章 vLLM 核心模块深度解析

第二章 vLLM 核心模块深度解析

如果把第一章比作"认识武器和靶场"，那么第二章就是"拆开武器看内部齿轮"。高并发部署能不能顶住流量，本质上不取决于你开了多少张卡，而取决于 vLLM 内部那几个核心模块是否真的被你理解并调对了。很多团队部署 DeepSeek V4 时遇到的"加了卡却没变快""并发一高就 OOM""长请求把短请求拖死"，其根因几乎全在这三个模块上。

本章要做三件事：第一，把 vLLM 从收到一个 HTTP 请求到吐出第一个 token 的完整链路讲清楚，让你知道延迟都耗在哪里；第二，把 PagedAttention 这套 KV Cache 分页管理机制讲透，因为它是高并发下显存利用率和并发上限的真正基石；第三，把连续批处理（Continuous Batching）与调度器讲明白，因为它决定了你的吞吐量天花板。这三件事对应了高并发部署最痛的三个症状：首 token 延迟长、显存被吃满、吞吐上不去。

为什么偏偏是这三个模块？因为 DeepSeek V4 这类超大 MoE 模型，部署时最痛的三件事恰恰对应它们：首 token 延迟长（链路与调度）、显存被 KV Cache 迅速吃满（分页管理）、吞吐上不去（批处理策略）。理解它们，你后面调 max_num_seqs、max_num_batched_tokens、gpu_memory_utilization 这些参数时，才知道每个数字背后改的是哪个物理过程，而不是凭感觉乱拧旋钮。

上图是 vLLM 最粗粒度的数据流。它看起来是一条直线，但每一个箭头背后都藏着可以优化的旋钮。比如 Tokenizer 在 vLLM 中由独立进程（Tokenizer Manager）异步完成，不阻塞 GPU 计算流水线；调度器不是简单地"排队"，而是基于预算（budget）动态决定这一轮能塞进多少请求；GPU Worker 执行时又按张量并行把一层算子切分到多卡。理解这条链路的价值在于：当延迟超标时，你能立刻判断该去哪一段找原因，而不是从头到尾瞎试。

本章与第一章、第三章的关系可以这样理解：第一章让你知道"为什么需要 vLLM，以及 DeepSeek V4 对部署提出了什么要求"；第二章（本章）给你"引擎内部的零件清单与工作原理"；第三章再上升到"高并发下的进阶原理与瓶颈分析"。三者构成"动机 → 机制 → 优化"的递进。如果你跳过本章直接去调参，那你只是在照搬别人的配置；读完本章，你才有能力为自己的硬件和流量特征推导配置。

需要提前说明的一个事实边界：vLLM 的架构（连续批处理、PagedAttention、多进程 EngineCore 等）是公开且稳定的工程实现，本章所述机制以 vLLM 主流版本为准；而 DeepSeek V4 作为系列最新版本，其精确规格（层数、专家数、上下文长度等）建议结合官方发布文档核实。本章重点放在"如何把 vLLM 的机制正确映射到 MoE 大模型"这一可复用的方法论上，不对未公开的模型超参做断言。凡是涉及具体版本行为（如某版本是否默认开启前缀缓存、块大小默认值），请以你实际部署版本的源码或官方文档为准。

读到这里你应该建立一个核心直觉：vLLM 的高并发能力不是"堆硬件"堆出来的，而是"把等待时间利用起来"设计出来的。调度器在 GPU 算前一个请求的同时，已经把后一个请求的分词、KV 块分配做好了；当某个请求在等用户侧消费（streaming）或采样时，GPU 不会空转，而是去算别的请求。这种"零空闲"的设计哲学，贯穿了本章所有模块。

为了让你带着问题读，这里先给一个常被忽略的事实：在传统的"静态批处理"服务里，一个批次里只要有一个请求特别长，整批都要等它算完才能释放 GPU——这就叫队头阻塞（head-of-line blocking）。一个慢请求能让后面几十个快请求一起陪跑。vLLM 的连续批处理正是为消灭这种浪费而生。所以当你发现"GPU 利用率很高但 QPS 上不去"时，先别怀疑硬件，先怀疑是不是调度预算或批大小被设得太保守——这是第三章会展开的主题。

下面三节，我们逐一拆开来看：

• 2.1 节先从最直观的"一个请求的一生"入手，沿着时间轴看延迟分布，帮你定位"慢到底慢在哪一段"；
• 2.2 节深入显存，讲清楚 KV Cache 为什么必须分页、vLLM 怎么用块表（block table）做到显存零碎片，以及为什么这对 MoE 大模型尤其关键；
• 2.3 节回到调度器，讲连续批处理如何在每一轮迭代里动态拼装一个最优批次，以及抢占（preemption）机制如何保证显存不够时不崩。

读完后，你应当能用一句话向同事解释："vLLM 快，是因为它把 GPU 的空闲时间全部用连续批处理填满了，而 PagedAttention 保证了显存撑得起这么大的并发。" 这句话看似简单，却是本章三节的合流结论——如果你能讲清它背后的每一环，第二章就算学透了。

最后提醒一个工程纪律：本章所有机制讲解都基于真实可查的 vLLM 设计，但你在生产调参时，凡涉及具体版本行为（例如某版本是否默认开启前缀缓存、块大小默认值等），请以你实际部署版本的源码或官方文档为准。教程给你"为什么这样设计"的判断力，但具体开关的默认值会随版本漂移，这是必须亲手验证的部分。带着这个心态进入下面的三节，你会读得更踏实。

2.0 如何带着"问题"读本章

为了避免你像看说明书一样滑过本节，建议在心里先记下三个待解问题，读完三节再回来核对：

• 问题一：当用户说"首 token 太慢"，我该先查链路哪一段、调哪个参数？（答案在 2.1）
• 问题二：为什么并发一高就 OOM，而显存明明还有空？（答案在 2.2 的分页与块表）
• 问题三：GPU 利用率看着很高，QPS 却上不去，问题在哪？（答案在 2.3 的调度预算）

这三个问题，正是高并发部署现场最高频的三类工单。能独立答出，本章就算过关。

2.0.1 一个贯穿全章的核心公式

如果你讨厌记概念，至少记住这一条因果链：理解链路 → 定位延迟段；理解分页 → 放大并发上限；理解调度 → 填满 GPU。三者相乘，才是 vLLM 的真实吞吐，而不是任何单一模块的功劳。后面第三章的进阶优化，本质都是在这条链上找最细的瓶颈环节去打磨。把这话刻在脑子里，你读第三章会轻松很多。

2.0.2 本章与后续章节的依赖关系

需要再明确一下阅读路径，免得你跳读时断片：本章（第二章）是"机制"，必须建立在前述第一章的"动机"之上，也直接支撑第三章的"优化"。具体来说，2.1 的延迟分段是第三章压测方法的输入；2.2 的 KV 分页是第三章显存优化的前提；2.3 的调度预算是第三章吞吐调优的主战场。所以如果你打算直接跳到第三章去调参，我强烈建议你先回来把本章三节通读——否则第三章给你的参数会像没有地基的房子。

最后再强调一次事实边界：本章所有机制描述针对 vLLM 公开架构，DeepSeek V4 的未公开超参请查官方文档，教程不臆造。带着这个边界感读完本章，你就具备了"看懂一份 vLLM 配置为什么这样写"的能力，而不只是"会抄一份配置"。