菜单
主题
vLLM Logo

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

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

总结

DeepSeek-V3.2 (NVFP4 + TP2) 已在 GB300 (SM103 - Blackwell Ultra) 上成功平稳运行。利用 FP4 量化，在仅预填充（prefill-only）场景下，单 GPU 吞吐量达到了 7360 TGS（tokens / GPU / second）。在混合上下文场景 (ISL=2k, OSL=1k) 中，输出吞吐量为 2816 TGS。

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

同时，使用 2x 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 足以容纳 NVFP4 格式的 DeepSeek 系列模型权重。

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

4. 优化配置

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

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

Blackwell 架构带来的性能提升

FP8 与 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 Cache 的占用，从而降低了带宽压力并允许更大的批次大小。

在 TP2 配置下，每个 GPU 的工作负载足够大，使 Tensor Core 能够充分利用 FP4 更高的 FLOPs 和带宽效率。相反，TP4 更细粒度的划分稀释了每个 GPU 的工作负载，阻止系统充分捕捉 NVFP4 提供的效率增益。

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

Blackwell Ultra 与 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。这些因素共同促成了 Decode 阶段性能的巨大飞跃。

参考：深入了解 NVIDIA Blackwell Ultra

即使在采用 TP2 的小规模节点内配置中，GB300 相比 B300 也表现出了微小的改进。

部署调优

EP2 与 TP2 的选择

鉴于 DeepSeek-R1 的权重可以容纳在仅两块 B300 GPU 的 HBM 中，我们探讨了基于 TP2 还是 EP2 进行 DP 扩展更好。

注意：切换到 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 间通信开销，与 EP2 相比，TPOT 性能下降了 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

当上下文长度不长时，在一定并发范围内（<=256），为 GB300 上的 DeepSeek R1-0528 启用 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 (Indexer + SparseAttnIndexer)，并使用了带有专用缓存结构的 DeepseekV32IndexerBackend。在预填充阶段，这增加了额外的量化/索引计算，从而降低了吞吐量。性能分析还显示，单个 DSA 层步骤的内核执行时间是 MLA 的 2.7 倍。

从 vLLM 代码角度来看，除了 Indexer 路径，V3.2 和 R1 的 NVFP4 MoE 内核选择是相同的。因此，预填充性能差异主要来自 V3.2 的 Indexer/Sparse Attention 开销。

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

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

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

解耦预填充（Disaggregated Prefill，针对 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 Connector 来促进跨进程/节点的 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