大规模服务 DeepSeek-V4.1-Flash：vLLM 媲美 DeepInfer 并扩展至 GB300 NVL72
TL;DR：在一个 NVIDIA GB300 NVL72 机架上，采用 P/D 分离和 Wide-EP 的 vLLM 在 SemiAnalysis AgentX 基准测试中以每 GPU 954K tokens/s 的吞吐量服务 DeepSeek-V4.1-Flash，用户 P90 为 196 tokens/s——是 vLLM 早期单节点结果的 7.9 倍——其解码吞吐量在 DeepSeek 自家推理引擎 DeepInfer 的 6% 以内。 这一结果之所以重要，是因为它表明通用服务引擎可以媲美特定模型的引擎，同时还能在整个 NVL72 机架上进行在线扩展。
vLLM 的公告
vLLM 发布了一项关于在机架规模下服务 DeepSeek-V4.1-Flash 的性能研究。该文章是 vLLM 早期针对同一模型的单节点工作的后续，描述了实现这一扩展的工程细节。
头条结果：在一个 NVIDIA GB300 NVL72 机架上，采用 P/D（预填充/解码）分离和 Wide-EP 的 vLLM 在 SemiAnalysis AgentX 基准测试中以每 GPU 954K tokens/s 的吞吐量服务 DeepSeek-V4.1-Flash，用户 P90 为 196 tokens/s。这是 vLLM 在首次发布该模型时聚合单节点结果的 7.9 倍。成本为 DeepSeek 非高峰时段每 GPU 小时 38.96 美元。吞吐量计入缓存输入、未缓存输入和输出 token。
专用解码路径为单用户达到 826 tokens/s。
与 DeepSeek 自家引擎 DeepInfer 相比，vLLM 的解码吞吐量在批大小 8 到 256 范围内相差在 6% 以内，其预填充性能也紧随 DeepInfer 发布的曲线。
文章开头总结了经验教训：
- 通用引擎可以媲美特定模型的引擎
- 先理解模型，再优化
- 小型 DEP 实例最适合预填充
- Wide-EP 解码与 EPLB 配合良好
- 在 NVL72 规模下 CPU 开销变得关键
- 专用解码路径可实现低延迟
关键数字一览
| 指标 | 结果 |
|---|---|
| SemiAnalysis AgentX 上的吞吐量，GB300 NVL72 | 每 GPU 954K tokens/s |
| 每用户 P90 延迟 | 每用户 196 tokens/s |
| 相比 vLLM 早期聚合单节点结果的提升 | 7.9 倍 |
| 成本 | DeepSeek 非高峰时段每 GPU 小时 38.96 美元 |
| 专用解码路径上的单用户延迟 | 826 tokens/s |
| 解码吞吐量 vs. DeepInfer（批大小 8 到 256） | 相差在 6% 以内 |
vLLM 与 DeepInfer 的对比
DeepInfer 是 DeepSeek 为 DeepSeek-V4.1-Flash 自研的推理引擎。它与 vLLM 的文章在同一周发布，作为离线引擎，并发布了预填充和解码曲线。vLLM 将其视为该模型最相关的参考点，并在展示自身优化之前与之对比。
解码对比
在 DeepSeek 的解码配置下——131K 上下文，nextn=3——vLLM 在 GB200 上实现的吞吐量在批大小 8 到 256 范围内与 DeepInfer 发布的结果相差在 6% 以内。vLLM 从 DeepInfer README 中的图表读取了其数值。
预填充对比
vLLM 明确指出其预填充对比并非同类引擎基准测试。DeepInfer 发布的预填充曲线使用 EP4DP4，带 32 个冗余专家和 140-token 有界重放，硬件未在图表中说明，vLLM 从图表中读取了数值。vLLM 自身的运行在 GB300 上使用 DEP2，无冗余专家，128-token 重放，并使用自己的提示词。
由于设置不同，vLLM 表示不会将两条曲线之间的差距解读为引擎间的加速比。该对比显示的是，vLLM 的 DEP2 预填充在 DeepSeek 发布的范围内紧随其自家引擎。
为什么两个引擎结果接近
文章将相似性归因于双向的共同血统。DeepInfer 最初基于 vLLM 构建，而 vLLM 反过来持续集成了 DeepSeek 库中的内核——包括 MegaAttn、MegaMoE 和 Mega-mHC——并围绕它们对堆栈的其余部分进行了大量优化。
vLLM 指出的区别：DeepInfer 针对离线模式下的单一模型，而相同的 vLLM 构建还通过 P/D 分离和 Wide-EP 在整个 NVL72 机架上在线服务该模型。
影响优化策略的模型特性
在调优之前，vLLM 量化了 DeepSeek-V4.1-Flash 的架构特性。三个发现推动了其余工作：
- 小型 KV 缓存占用。 得益于跨层 KV 共享和 FP4 压缩，全局 KV 缓存每 token 仅需 890 字节，根据 DeepSeek-V4.1-Flash 技术报告。
- 轻量级注意力。 第 2、8 和 14 层使用 2 倍压缩进行全上下文索引。使用有界重放时，第 20 层为所有 token 写入全局 KV，但仅对最后 128 个 token 运行索引和注意力；第 21 至 39 层仅处理这些 token。
- 即使在长上下文中，解码也受 MoE 限制。 在 128K 上下文和每 rank 64 个请求的 DEP4 解码下，MoE 占目标步骤的 62%，而注意力和索引器合计仅占 13%。
vLLM 还测量了目标模型在 DEP32 下的前向时间，每 rank 16 个请求，每请求 6 个 token（一个 token 加五个 DSpark 草稿 token），所有请求上下文长度相同，在 GB300 上。长上下文几乎不影响解码延迟：从 128K 到 855K token——上下文增加 6.7 倍——仅增加 0.6 ms（+7%）的目标模型解码延迟。
| 每请求上下文 | 64K | 128K | 256K | 512K | 855K |
|---|---|---|---|---|---|
| 目标前向（ms） | 8.86 | 8.93 | 9.03 | 9.25 | 9.53 |
| 相比 128K | -0.8% | – | +1.1% | +3.6% | +6.7% |
这些特性导致了五个策略决策，按 vLLM 的框架：
- 预填充应以较小的 DEP 规模运行。 即使在 B300 或 GB300 上的 DEP2 实例也能容纳模型权重和许多并发会话的 KV 缓存，较小的世界规模大大简化了 DP/EP 负载均衡。
- KV 容量很少限制批大小。 KV 缓存可轻松放入 HBM，因此每个操作可以推向其计算或内存带宽极限，而不是绕开 KV 容量。这也使扫描保持一致且低噪声，无抢占或 KV 缓存压力。
- Wide-EP 对解码有效。 MegaMoE 解码受权重读取限制，Wide-EP 直接削减了这一主导的 MoE 成本。
- 解码 DP 负载均衡更简单。 对于此模型，解码步骤时间随上下文长度变化很小，因此 DP 负载均衡可以简化为按每 rank 请求数的最少负载。
- 合成工作负载仍能代表解码。 使用平均输入和输出长度可以在不重放完整代理轨迹的情况下提供良好的性能估计。
预填充：DEP2 效果最佳，外加三个瓶颈修复
小型 DEP 实例在预填充中胜出
在并发 256 的 AgentX 纯预填充运行中，DEP4 的每 GPU 吞吐量仅为 DEP2 的 83%（53.3K vs. 64.4K tokens/s）。关闭前缀缓存的镜像和滞后重放表明 DP 不平衡是原因：当 rank 失步时，DEP4 损失 13.6% 的吞吐量。vLLM 因此称 DEP2 是简单的默认选择。
| 每实例预填充吞吐量（tokens/s） | 镜像（平衡） | 滞后（不平衡） | 损失 |
|---|---|---|---|
| DEP2 | 138.7K | 130.5K | 5.9% |
| DEP4 | 267.6K | 231.1K | 13.6% |
vLLM 指出不平衡成本是在早期构建上测量的，并且它是 DEP 规模的属性，而非内核的属性。
干净轨迹暴露了上下文长度瓶颈
在两块 GB300 GPU 上，8K-token 预填充在没有先前上下文时耗时 87.9 ms，但在有 512K 缓存上下文时耗时 189.4 ms。vLLM 解决了该轨迹背后的三个额外瓶颈：
- 将 SWA 有界重放扩展到第 20 层（PR #59894）：在 32K 新 token 时 +19.9%。 SWA 有界重放已将第 21 至 39 层限制为最后 128 个 token。此前第 20 层仍对所有新 token 执行索引器计算。现在它为所有新 token 写入 KV，但仅对 128-token 重放批次运行其余计算。增益从 4K 时的 10.1% 增加到 64K 时的 23.1%。
- 共享 Engram 主机表的 2 MB 页（PR #62359）：在 32K 时再 +2.8%。 Engram 从跨 DP rank 共享的主机表执行随机读取。之前的 /dev/shm 映射使用 64 KB GPU 页，导致频繁的 GPU TLB 未命中。将表移至主机 NUMA cuMem 分配可实现 2 MB GPU 页。
- 预填充索引器中的 DeepSelect top-k（PR #62240）：在 32K 时再 +15.6%。 预填充索引器现在使用 DeepSelect 对候选块进行排序，与解码路径一致。该收益随被排序的键数量增加而增长，在 64K 时达到 15.2%。
这些更改共同将新 token 预填充吞吐量在 4K 到 64K 新 token 范围内提升了 35.6% 到 43.9%，基于 128K 缓存前缀。在 32K 新 token 时，总增益为 42.5%。在 64K 时，吞吐量从每 GPU 71.2K 上升到 102.5K tokens/s（+43.9%）。
解码：Wide-EP 扩展和 EPLB 专家均衡
Wide-EP 与 EPLB 是既定实践，在 DeepSeek 的推理系统概述中有所描述，vLLM 已支持两者一段时间。本节重点介绍 vLLM 的新发现和经验教训。
从 DEP4 到 DEP32 的 Wide-EP 扩展
vLLM 测量了从 DEP4 到 DEP32 的解码扩展，每 GPU 64 个请求，128K 上下文，启用 EPLB。目标 MegaMoE 时间从 13.4 ms 降至 6.0 ms，因为每个 rank 持有的专家更少，而其余工作保持在约 10 ms。因此，每 GPU 吞吐量增益逐渐减少。在 DEP32 时，草稿的通信开销也开始抵消更宽并行性的好处。这些测量在 NVIDIA GB200 上进行。
EPLB 结果
vLLM 配置 EPLB 每 3,000 步重新排列专家，基于前 1,000 步的负载。EPLB 将目标模型的平衡度从 0.35 提高到 0.94，草稿从 0.21 提高到 0.89，恢复了与均匀路由差距的约 97% 和 93%。
两项更改使其生效：
- PR #62009 引入了基于 NVLink 的
symm_mem后端，可在不到一秒内重新平衡整个 DEP32，而无需停止解码，将 EPLB 的副本映射和负载记录融合到 MegaMoE 内核中（每步节省约 0.2 ms），并从解码循环中移除主机同步。 - PR #61395 支持异构目标模型和草稿模型的 EPLB。DSpark 草稿有 128 个路由专家，top-3 路由，而目标有 384 个，top-6，因此 EPLB 分别跟踪每个模型的专家放置和负载，并重新平衡两者。
在 NVL72 规模下 CPU 开销变得关键
Wide-EP 解码在每一层同步所有 rank，因此一个慢 rank 会阻塞整个实例。异步调度在小规模下能很好地隐藏 CPU 开销，但更多 rank 使这变得困难，原因有二：GPU 步骤变短，留给 CPU 工作的余量减少；并且一个 rank 落后的可能性增加。
在实践中，vLLM 观察到未优化的 DEP32 比 DEP16 运行更慢——每步 17.57 ms 对比 13.84 ms——尽管其 GPU 执行时间快了 1.1 ms。文章列出了发现的所有原因，按影响排序。由于这些影响来自不同设置，每行都带有自己的设置。
| 原因 | 修复 | PR | 效果 | 设置 |
|---|---|---|---|---|
| KV 读取在解码工作线程上同步发布 | NIXL 推送与 UCX 分散-聚集；打包的 KV 行作为单个 NIXL 区域发送 | NIXL 推送连接器，#61121 | 每 GPU 141K 到 440K tokens/s；P90 约每用户 40 到 159 tokens/s | GB300，8P1D，并发 3,072 |
| Gloo 全归约延迟随 rank 数线性增长 | 递归倍增 CPU 全归约 | #61767，基于 #60267 | DP 同步每步 10.8 到 1.5 ms；步骤 16.10 到 13.15 ms | DEP32 解码 |
| 准入突发：一步内最多准入 140 个请求 | 每步最多 4 个新 KV 加载的可选上限 | #61725 | 每 GPU 460K 到 516K tokens/s；P90 每用户 109 到 153 tokens/s | GB300，7P1D，并发 4,800，带两个其他 CPU 修复 |
| 准入工作随提示长度增长 | 提示作为单个 int32 缓冲区；跳过滑动窗口块表的空块；分块提示复制内核 | #59908、#62702、#61724、#62698 | 855K 提示：每次准入 CPU 38.8 到 6.0 ms | 引擎微基准测试 |
低延迟：针对小批量的专用解码路径
vLLM 通过 PR #61868 和 #61869 扩展了对 DeepSeek-V4.1-Flash 的低延迟内核支持，延续了之前关于 Kimi K3 兆内核的工作。
在真实 AgentX 会话中，专用解码路径在四块 B300 GPU 上为单用户达到 826 P90 tokens/s，比标准解码路径（575）高 44%。该测量涵盖 SemiAnalysis AgentX，TP4 在四块 B300 GPU 上，并发 1、8 和 16，在 InferenceX PR #4332 切换到专用解码路径之前和之后。
vLLM 如何测量性能
vLLM 将准确测量分解为两个问题：预填充或解码步骤应花费多少，以及 DP 和 EP 不平衡带来多少额外开销？
- 预填充和解码步骤时间。
vllm bench forward工具（PR #61339）通过实际的execute_model路径测量精确预填充或解码批次的模型前向时间，跨 DP 和 EP rank。这仅测量 GPU 时间，并提供干净的轨迹。另外，vLLM 的DecodeBenchConnector在给定并发下测量引擎级端到端解码性能。GPU 专用时间与服务步骤时间之间的差距揭示了意外开销。 - 预填充 DP 不平衡：镜像与滞后重放。 代理轨迹因运行而异，因此 DP 不平衡难以隔离。因此 vLLM 在每个 DP rank 上重放相同的请求。在镜像运行中，所有 rank 同时收到请求。在滞后运行中，rank r 收到相同请求的时间晚 r x 5 秒，因此 rank 失步但完成相同总工作量。两次运行之间的差异就是 DP 不平衡的成本。
- 解码 EP 不平衡：真实与均匀路由。 对于每个 MoE 层，平衡度定义为平均 rank 负载除以最大 rank 负载，按步和 EPLB 窗口计算。作为平衡参考，vLLM 运行相同的解码批次，但 token 均匀随机路由。该参考仍有采样噪声：在 DEP32 下，每 GPU 72 个请求，均匀路由达到目标（top-6 路由）约 0.96 的平衡度，草稿（top-3）约 0.94。真实路由与均匀路由之间的差距是专家平衡最多能恢复的，EPLB 运行显示了它实际恢复了多少。
术语
DEP 后跟数字表示数据并行注意力加上专家并行，跨该数量的 GPU。DEP2 是两块 GPU，DEP4 是四块，DEP32 是 32 块。目标前向是主模型在每个解码步骤的完整前向传递，验证草稿 token 并产生输出；草稿前向是 DSpark 草稿模型的完整前向传递，为下一步提出 token。
致谢
vLLM 感谢 DeepSeek 开源并分享 DeepSeek-V4.1-Flash 及其优化内核，这为工作提供了基础，并感谢发布 DeepInfer 及其性能结果。还感谢 SemiAnalysis 提供 AgentX 基准平台。
vLLM 特别感谢 NVIDIA 的 Pei Li、Hanjie Qiu、Lisa Wang、Yaoyao Ding、Rohit Nagraj 和 Xin Li 在性能优化方面的合作、对 vLLM 和 Dynamo 的支持以及帮助提交 AgentX 结果，以及 vLLM 社区的 Canlin Guo 在预填充优化方面的贡献。该工作由 Inferact 领导。