菜单
主题
vLLM Logo

GB300 上的 DeepSeek-V3.2：性能突破

12 分钟阅读
DaoCloud 与 vLLM 团队
#硬件#量化#性能

总结

DeepSeek-V3.2（NVFP4 + TP2）已在 GB300（SM103 - Blackwell Ultra）上成功流畅运行。利用 FP4 量化，其在纯预填充场景下实现了单 GPU 7360 TGS（每 GPU 每秒生成的 Token 数）的吞吐量。在混合上下文场景（ISL=2k, OSL=1k）下，输出吞吐量为 2816 TGS。

然而，与 DeepSeek-R1 相比，DeepSeek-V3.2 在 vLLM 中的推理性能仍有显著的提升空间。

同时，使用 2 个 GB300 GPU，DeepSeek-R1（NVFP4 + EP2）在纯预填充场景下可实现 22476 TGS（ISL=2K, OSL=1, batch=256）的吞吐量，在混合上下文场景（ISL=2k, OSL=1k）下可达到 3072 TGS。

与 Hopper 系列相比，B300 系列在预填充方面展现了 8 倍的性能提升，在混合上下文场景中则有 10-20 倍的提升。

注：本博客强调架构和部署验证，而非峰值吞吐量调优，结果反映的是可复现的基准性能。

所有实验均可使用以下软件栈复现：

  • vLLM: v0.14.1
  • CUDA: 13.0

基准测试设置

在本博客中，我们在三种典型的基准测试场景下评估了性能：

  • 纯预填充场景

    此场景将输出序列长度设为 OSL = 1，因此执行时间主要由预填充阶段决定。主要用于测量预填充吞吐量，并比较不同架构和并行策略处理长输入上下文的能力。

  • 混合上下文场景（短输出）

    此场景使用短输出长度 ISL=2k, OSL= 64/128 且伴随长输入上下文。

  • 混合上下文场景（中等输出）

    这代表了更真实的在线服务工作负载，预填充和解码阶段对执行时间都有显著贡献。我们通常使用 ISL=2k, OSL=1k 来评估混合执行下的吞吐量。

以下是用于生成这些基准测试的示例命令：

vllm bench serve --model nvidia/DeepSeek-R1-0528-NVFP4 \
  --seed $RANDOM \
  --dataset-name random \
  --base-url http://${PROXY_NODE_IP}:8000 \
  --tokenizer /mnt/models/DeepSeek-V3.2 \
  --num-prompts 1000 \
  --max-concurrency $MAX_CONCURRENCY \
  --random-input-len $ISL \
  --random-output-len $OSL \
  --ignore-eos

所有图表中均使用了由 vllm bench serve 报告的指标。

  • 预填充吞吐量

    总 Token 吞吐量 (tok/s)

  • 解码吞吐量

    输出 Token 吞吐量 (tok/s)

基于 FP4 权重量化的基础方案

Blackwell 最显著的特性之一是第五代 Tensor Core 原生支持 NVFP4。

1. 从 Hugging Face 下载 NVFP4 模型权重

2. 使用 FlashInfer 提供的 FP4 MoE 内核

在 Blackwell 上运行 FP4 MoE 模型需要明确设置 VLLM_USE_FLASHINFER_MOE_FP4=1 以启用 FlashInfer FP4 MoE 内核。

export VLLM_USE_FLASHINFER_MOE_FP4=1

3. 部署模型

GB300/B300 单 GPU 显存为 288GB。两个 GPU 足以容纳 DeepSeek 系列模型的 NVFP4 格式权重。

vllm serve nvidia/DeepSeek-V3.2-NVFP4    -tp 2
# or
vllm serve nvidia/DeepSeek-R1-0528-NVFP4 -tp 2

4. 优化配置

以下是使用 --max-num-batched-tokens 参数以实现 TP2 更好预填充吞吐量的最大边界批次参考值：

# DeepSeek-R1-0528-NVFP4
--max-num-batched-tokens 32768
 
# DeepSeek-V3.2-NVFP4
--max-num-batched-tokens 20480

Blackwell 架构带来的性能提升

FP8 vs. FP4（针对 DeepSeek V3.2）

在 GB300 (B300) 上部署 DeepSeek V3.2 时，我们观察到一个显著的性能特征：NVFP4 量化带来了巨大的性能收益，即使仅使用标准配置一半的硬件资源（GPU 数量），也能实现优异的整体性能。然而，实验结果也清楚地表明，仅靠低精度不足以完全释放性能潜力，并行策略的选择同样至关重要。

数据凸显了 NVFP4 + TP2 的显著优势。在纯预填充场景（ISL=2k, OSL=1, batch=64）下，TP2 比 FP8 提升了 1.8 倍，并实现了高达 7360 TGS 的总吞吐量。在混合上下文场景（ISL=2k, OSL=1k）下，输出吞吐量提升至 2816 TGS（即 8 倍的收益）。相比之下，TP4 配置的收益较为温和——预填充仅提升 14%，混合上下文场景下提升 2 倍，这使得 TP2 结果更加高效。

这些收益归功于两个因素：降低了内存开销并简化了计算逻辑。NVFP4 大幅缓解了内存带宽压力，这对增加输出 Token 吞吐量至关重要。此外，注意力层内计算的简化直接优化了预填充阶段的端到端延迟。

为什么我们推荐 NVFP4 + TP2 的组合？

结果表明，权重量化只是方程的一部分；另一个性能驱动力在于并行性与单 GPU 工作负载之间的平衡。NVFP4 显著减少了模型和 KV 缓存的占用，降低了带宽压力并允许更大的批次大小。

在 TP2 配置下，每个 GPU 的工作负载依然足够大，使得 Tensor Core 能够充分利用 FP4 更高的 Tensor Core FLOPs 和带宽效率。相反，TP4 的更细粒度分区稀释了每个 GPU 的工作负载，导致系统无法完全捕捉到 NVFP4 提供的效率提升。

提示：要使用 FP8，请切换到 FP8 模型权重，然后使用 VLLM_USE_FLASHINFER_MOE_FP8=1。在 FP8 下，DeepSeek-V3.2 需要 4 个 GPU，并请使用 -tp 4。

Blackwell Ultra vs. Hopper（针对 DeepSeek R1）

下图展示了在相同的请求和 vLLM 设置下，GB300 (NVL72)、B300 (HGX) 和上一代 H200 的单 GPU 总吞吐量对比。

  • 在纯预填充（ISL=2k）场景中，GB300 的单 GPU 吞吐量比 B300 高出 14%，比 H200 高出 8 倍。
  • 在短输出混合上下文场景（ISL=2k, OSL=128）中，GB300 的单 GPU 吞吐量比 B300 高出 12%，比 H200 高出 20 倍。

原因多方面：除 FP4 外，B300 的 FLOPs 比 Hopper 系列高出 7.5 倍（峰值达到约 15 PFLOPs）。SM 的 SFU 模块对注意力层计算的优化带来了预填充阶段的效率提升。

其 288GB 内存也是 H200 的 2 倍，内存带宽几乎翻倍。此外，Blackwell Ultra 的高密度 NVFP4 FLOPs 加速了 MoE 前向计算，相比 Hopper 的 FP8，这些都促进了解码阶段的显著性能飞跃。

参考资料：深入了解 NVIDIA Blackwell Ultra

即使在采用 TP2 的小规模节点内配置中，GB300 也比 B300 有小幅提升。

部署调优

EP2 与 TP2 选择

鉴于 DeepSeek-R1 的权重可以装入仅两个 B300 GPU 的 HBM 中，我们探索了基于 TP2 还是基于 EP2 进行扩展效果更好。

注：切换到 EP2 的 CLI 参数是 -dp=2 --enable-expert-parallel。

a. 纯预填充场景（ISL=2k, OSL=1）

EP2（蓝色曲线）达到了 22476 TGS 的吞吐量上限，在吞吐量和首字延迟（TTFT）的增长斜率上均优于 TP2（绿色曲线）。这得益于 EP 典型的“大包、低频率”通信模式，在高并发下更好地利用了 RDMA/NVLink 的高带宽。

然而，蓝色 EP 曲线由于专家路由不平衡出现了一些波动，导致不同批次触及不同的专家分布，从而导致专家负载和全对全（all-to-all）通信量的变化。

b. 短输出混合上下文场景（ISL=2k, OSL=64）

在 TP2 下，每一步解码都会引入 GPU 间通信开销，导致 TPOT（每个输出 Token 的时间）相比 EP2 有 50% 到 2 倍的降级。

然而，TP 也将 TTFT 改善了约 50%，加快了每一步的执行。这种改进抵消了 TPOT 的降级，最终在输出 Token 吞吐量上实现了 5%–20% 的整体增益。

结论

  • 对于在 GB300 上进行解耦预填充的 DeepSeek-R1，EP 更适合预填充器（然后只需增加 DP 计数进行扩展）。EP 在预填充阶段具有更高的吞吐量上限（峰值比 TP2 高约 10% - 15%），且 TTFT 随并发量的增长更为平缓，这对控制队列和尾部延迟更有利。
  • 在 P+D 集成部署中，策略取决于工作负载：
    • 当 ISL 较大而 OSL 较小时，预填充阶段成为主要瓶颈，建议使用 TP2，以防止过度的注意力层延迟挤占解码阶段的 GPU 时间。
    • 相反，对于输出密集型情况，EP2 的 TPOT 优势变得占据主导，因此它是首选配置。

MTP 的优势

MTP 对解码提供了不错的改进，但并非万能药。

如下所述，内置草稿模型一次推测 1 个 Token，在接受率和计算负载之间取得平衡。

--speculative-config.method mtp \
--speculative-config.num_speculative_tokens 1

当上下文长度不长时，对于 GB300 上的 DeepSeek R1-0528，在一定并发范围内（<=256）启用 MTP（蓝色）比禁用 MTP（绿色）实现了更高的吞吐量（接受率可达 > 80%）。然而，在高并发下启用 MTP 时，吞吐量急剧下降。

在混合上下文场景（ISL=2k, OSL=64）下，解码比例极低。MTP 的多 Token 预测开销无法分摊，导致单 Token 计算量、内存压力和调度复杂性增加。在低并发下，开销无法分摊；在高并发下，它进一步压缩了预填充批处理和系统并发性。

因此，整体吞吐量在低并发和高并发水平下均低于禁用 MTP 的情况。

DeepSeek V3.2 - 仍有提升空间

如下图所示，在相同的 GB300 设置下，DeepSeek R1 的预填充吞吐能力约为 DeepSeek V3.2 的 3 倍。

  • EP2 下的 DeepSeek R1 峰值预填充吞吐量可达约 22476 TGS。
  • EP2 下的 DeepSeek V3.2 相对较弱，预填充峰值吞吐量约为 7360 TGS。
  • 在 TTFT 方面，当两个模型都使用 TP2 时，R1 的延迟比 V3.2 降低了约 55%。

然而，在混合上下文场景（ISL=2k, OSL=1k）中，两个模型在输出吞吐量和 TPOT 方面的差距并不显著。

为什么 R1 的总体吞吐量超过了 V3.2？

主要原因是 V3.2 引入了 Indexer/Sparse MLA（索引器 + 稀疏注意力索引器），并使用了带有专用缓存结构的 DeepseekV32IndexerBackend。在预填充阶段，这增加了额外的量化/索引计算，从而降低了吞吐量。性能分析还显示，单个 DSA 层步骤的内核执行时间是 MLA 的 2.7 倍。

从 vLLM 代码角度来看，除了索引器路径，V3.2 和 R1 之间的 NVFP4 MoE 内核选择是相同的。因此，预填充性能差异主要源于 V3.2 的索引器/稀疏注意力机制带来的开销。

DSA 的优势更适合超长上下文。如果您的上下文不需要足够的注意力计算，额外的开销就会变得明显。然而，随着上下文长度进一步增加，DSA 在解码阶段的 TPOT 优势就会显现，在 10k-20k 个 Token 之间超越 MLA，并以约 6 倍更陡峭的斜率领先。

最后，DeepseekV32IndexerBackend 仍相对较新且不够成熟，具有相当大的优化潜力。

因此，我们认为 DeepSeek-V3.2 仍有巨大的改进空间。

解耦预填充（针对 DeepSeek-V3.2）

以下是通过 RDMA 横向扩展网络进行 1P+1D 解耦预填充的快速入门教程（下一篇博客将展示跨 GB 系列托盘使用 NVLink72 的技巧）。

# Prefill Node
export VLLM_USE_FLASHINFER_MOE_FP4=1
export UCX_NET_DEVICES=mlx5_bond_0:1   # optional, tell NIXL to use specific RDMA interface
export VLLM_NIXL_SIDE_CHANNEL_HOST=${PREFILL_NODE_IP}
vllm serve nvidia/DeepSeek-V3.2-NVFP4 -tp 2 --max-num-batched-tokens 20480 \
  --kv-transfer-config \
  '{"kv_connector":"NixlConnector","kv_role":"kv_both","kv_load_failure_policy":"fail","kv_buffer_device":"cuda"}' \
  --port 8000
 
# Decode Node
export VLLM_NIXL_SIDE_CHANNEL_HOST=${DECODE_NODE_IP}
...
# Exactly the same environment variables and vLLM CLI as Prefill Node, except `VLLM_NIXL_SIDE_CHANNEL_HOST`
 
 
# Proxy Node
cd vllm # move to vLLM source code and may need to install necessary dependencies
python tests/v1/kv_connector/nixl_integration/toy_proxy_server.py \
  --port 8000 \
  --prefiller-hosts ${PREFILL_NODE_IP}   --prefiller-ports 8000 \
  --decoder-hosts ${DECODE_NODE_IP}      --decoder-ports   8000
 
# If you have multiple Prefillers or Decoders:
# just append to hosts list, like: `--prefiller-hosts ${IP1} ${IP2}  --prefiller-ports 8000 8000 `
 
# vLLM bench against the proxy (using a random dataset and ISL=4k,OSL=1k)
vllm bench serve --model nvidia/DeepSeek-V3.2-NVFP4 \
  --seed $RANDOM --dataset-name random \
  --base-url http://${PROXY_NODE_IP}:8000 \
  --tokenizer /mnt/models/DeepSeek-V3.2   \
  --num-prompts 500    --max-concurrency 100 \
  --random-input-len 4096  --random-output-len 1024 \
  --ignore-eos

注：vLLM v0.14.1 上的 PD 解耦：要使用 vLLM v0.14.1 运行 PD 解耦，您需要手动应用 PR #32698 中的补丁。不过，此功能已合并到 vLLM 最新主分支，如果您使用较新版本，则可能不需要此补丁。

我们使用 Nixl KV 连接器来促进跨进程/节点的 KV 传输。P 和 D 角色均使用 TP2 策略。

随着并发负载增加，解耦设置在吞吐量上显示出优于集成设置的优势，差距不断扩大，同时保持较低的延迟（TTFT 和 TPOT）。延迟增长的斜率也更稳定。

关于 TPOT，1P1D 和 3P1D 的表现都优于非解耦设置。在批处理大小为 256 时，解耦设置将 TPOT 抑制在 60ms 以内，而集成设置则超过了 80ms。

当 ISL 继续增长（从 2K 到 8K）时，1P1D 设置的吞吐量开始挣扎，预填充成为瓶颈。请求在 P 节点队列中等待，无法充分利用解码器的计算能力。当增加 2 个 P 副本（3P1D）时，它们可以并行处理更多请求的预填充阶段，从而实现更好的总吞吐量。

尽管解耦设置的单 GPU 吞吐量可能不是最高的，但通过投入更多硬件，可以获得更好的 Goodput 和 SLO 保证。

预告：下一篇博客将展示在 GB200 上利用 NVL72 进行 P/D 解耦的实践。

致谢

我们要感谢 vLLM 社区中许多有才华的人，他们为这一努力共同做出了贡献。

  • Verda 团队：感谢提供 GB300 集群及基础设施支持。
  • DaoCloud 团队：Xingyan Jiang, Nicole Li, Peter Pan, Kebe Liu
  • InferAct 团队：Jie Li, Kaichao You