DeepSeek-V3.2 on GB300：性能表现与部署实践

摘要

DeepSeek-V3.2（NVFP4 + TP2）已经在 GB300（SM103，Blackwell Ultra）上成功、稳定地跑通。借助 FP4 量化，它在纯 Prefill 场景下实现了单 GPU 7360 TGS（tokens / GPU / second）的吞吐量；在混合场景（ISL=2k, OSL=1k）下，输出吞吐量达到 2816 TGS。

不过，相比 DeepSeek-R1，DeepSeek-V3.2 在 vLLM 中的推理性能依然有明显优化空间。

与此同时，使用 2 张 GB300 GPU 时，DeepSeek-R1（NVFP4 + EP2）在纯 Prefill 场景下可达到 22476 TGS（ISL=2K, OSL=1, batch=256）的吞吐量，在混合场景（ISL=2k, OSL=1k）下则达到 3072 TGS。

相比 Hopper 系列，B300 系列在 Prefill 阶段带来了 8 倍性能提升，在混合场景下则带来了 10 到 20 倍提升。

Note

本文更关注架构和部署层面的验证，而不是极限吞吐调优，因此结果反映的是可复现的基线性能。

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

• vLLM：v0.14.1
• CUDA：13.0

基准测试设置

本文在三类具有代表性的基准场景下评估性能：

• 纯 Prefill 场景

  该场景将输出序列长度设为 OSL = 1，因此执行时间几乎完全由 Prefill 阶段主导。它主要用于衡量 Prefill 吞吐量，以及比较不同架构和并行策略处理长输入上下文的能力。

• 混合场景（短输出）

  该场景使用较短输出长度，即 ISL=2k, OSL=64/128，同时保留较长输入上下文。

• 混合场景（中等输出）

  这更接近真实在线服务负载，Prefill 和 Decode 两个阶段都会显著影响执行时间。我们通常使用 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 输出的以下指标：

• Prefill 吞吐量

  Total token throughput (tok/s)

• Decode 吞吐量

  Output token throughput (tok/s)

基础部署方案：FP4 权重量化

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

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

• DeepSeek-V3.2-NVFP4
• DeepSeek-R1-0528-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 单卡显存为 288GB，两张 GPU 就足以容纳 DeepSeek 系列模型的 NVFP4 权重。

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

4. 推荐优化参数

下面给出在 TP2 配置下，为获得更高 Prefill 吞吐量可参考的 --max-num-batched-tokens 参数值：

# 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 的优势。在纯 Prefill 场景（ISL=2k, OSL=1, batch=64）下，TP2 相比 FP8 提升了 1.8 倍，总吞吐量最高达到 7360 TGS。在混合场景（ISL=2k, OSL=1k）下，输出吞吐量提升到 2816 TGS，相当于 8 倍增益。相比之下，TP4 配置的提升幅度更有限，Prefill 仅提升 14%，混合场景提升 2 倍，因此 TP2 的效率明显更高。

这些收益主要来自两个方面：更低的内存开销和更简单的计算路径。NVFP4 明显缓解了内存带宽压力，这对提升输出 token 吞吐量非常关键；同时，注意力层中的简化计算也直接改善了 Prefill 阶段的端到端延迟。

为什么推荐 NVFP4 + TP2？

结果表明，权重量化只是性能方程的一部分，另一个重要因素是并行度与单 GPU 工作负载之间的平衡。NVFP4 大幅缩小了模型权重和 KV cache 的占用，降低了带宽压力，并允许系统使用更大的 batch size。

在 TP2 配置下，每张 GPU 的工作负载仍然足够大，可以让 Tensor Core 充分吃满 FP4 更高的 FLOPs 和更好的带宽效率。相反，TP4 更细的切分会稀释单卡负载，使系统无法完全兑现 NVFP4 带来的效率收益。

Tip

如果你要使用 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 总吞吐量：

• 在纯 Prefill（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 模块对注意力层计算的优化，也进一步提升了 Prefill 阶段的效率。

它的 288GB 显存也是 H200 的 2 倍，内存带宽接近翻倍。此外，Blackwell Ultra 高密度的 NVFP4 FLOPs 让 MoE forward 比 Hopper 上的 FP8 更快。这些因素共同推动了 Decode 阶段的显著性能跃升。

参考：Inside NVIDIA Blackwell Ultra

即使是在小规模单节点、TP2 配置下，GB300 相比 B300 也能看到小幅收益。

部署调优

EP2 vs. TP2 的选择

由于 DeepSeek-R1 的权重可以装入仅两张 B300 GPU 的 HBM 中，我们进一步探索：更适合的扩展方式，是基于 TP2 做 DP 扩展，还是基于 EP2 做 DP 扩展。

Note

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

a. 纯 Prefill 场景（ISL=2k, OSL=1）

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

不过，蓝色 EP 曲线会有一定波动。这是因为专家路由不均衡，不同 batch 会命中不同的专家分布，导致专家负载和 all-to-all 通信量发生变化。

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

在 TP2 下，每个 decode step 都会引入跨 GPU 通信开销，因此 TPOT 相比 EP2 会下降 50% 到 2 倍。

不过，TP 同时又将 TTFT 改善了约 50%，加快了每个 step 的执行速度。这个收益会抵消 TPOT 的劣势，最终体现在输出 token 吞吐量上，仍然能获得 5% 到 20% 的整体提升。

结论

• 对 GB300 上的 DeepSeek-R1 做 P/D 分离部署时，EP 更适合作为 Prefill 角色，然后再通过增加 DP 数量横向扩展。EP 在 Prefill 阶段的吞吐上限更高，峰值大约比 TP2 高 10% 到 15%；同时它的 TTFT 随并发增长更平缓，更有利于控制排队和尾延迟。
• 对于 P+D 一体化部署，策略取决于负载形态：
  • 当 ISL 大、OSL 小时，Prefill 成为主瓶颈，推荐 TP2，避免注意力层延迟过高，挤占 Decode 阶段的 GPU 时间。
  • 对于输出占比更高的场景，EP2 在 TPOT 上的优势会成为主导，因此它是更优选择。

MTP 的收益

MTP 能为 Decode 带来不错的收益，但它并不是银弹。

如下所示，内置草稿模型每次推测 1 个 token，在接受率和计算负载之间做平衡：

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

当上下文长度不长时，在 GB300 上为 DeepSeek R1-0528 启用 MTP（蓝线），在一定并发范围内（<=256）会比禁用 MTP（绿线）获得更高吞吐量，接受率甚至可以超过 80%。但在高并发下，启用 MTP 后吞吐量会明显下跌。

在混合场景（ISL=2k, OSL=64）中，Decode 占比其实很低。此时 MTP 多 token 预测的额外开销无法被摊销，反而会带来更高的单 token 计算量、更大的内存压力以及更复杂的调度。低并发时它无法摊销开销；高并发时又会进一步挤压 Prefill batching 和整体系统并发能力。

因此，无论低并发还是高并发，总体吞吐量都低于关闭 MTP 的方案。

DeepSeek V3.2：仍有很长的路要走

如下图所示，在相同 GB300 配置下，DeepSeek R1 的 Prefill 吞吐能力大约是 DeepSeek V3.2 的 3 倍。

• DeepSeek R1 在 EP2 下的 Prefill 峰值吞吐量约为 22476 TGS
• DeepSeek V3.2 在 EP2 下相对偏弱，Prefill 峰值吞吐量约为 7360 TGS
• 在 TTFT 上，两个模型都使用 TP2 时，R1 的延迟比 V3.2 低约 55%

不过，在混合场景（ISL=2k, OSL=1k）中，这两个模型在输出吞吐量和 TPOT 上的差距并不算特别显著。

为什么 R1 的整体吞吐量会优于 V3.2？

主要原因在于，V3.2 引入了 Indexer / Sparse MLA（Indexer + SparseAttnIndexer），并使用 DeepseekV32IndexerBackend 以及专门的缓存结构。在 Prefill 阶段，这会引入额外的量化和索引计算，从而拖慢吞吐量。性能分析也表明，单个 DSA 层 step 的内核执行时间大约是 MLA 的 2.7 倍。

从 vLLM 的代码实现看，除了 Indexer 路径之外，V3.2 和 R1 在 NVFP4 MoE 内核选择上其实是一致的。因此，Prefill 性能差异主要来自 V3.2 在 Indexer / Sparse Attention 路径上的额外开销。

DSA 的优势更适合超长上下文。如果上下文还没有长到需要足够多的注意力计算，那么这部分额外开销就会非常显眼。但随着上下文长度进一步增加，DSA 在 Decode 阶段的 TPOT 优势会逐渐体现，在 10k 到 20k token 区间超越 MLA，并以大约 6 倍更陡的斜率继续领先。

最后，DeepseekV32IndexerBackend 目前仍是一个相对新的实现，还不算成熟，仍然有相当大的优化潜力。

因此，我们认为 DeepSeek-V3.2 仍有非常大的提升空间。

P/D 分离部署（DeepSeek-V3.2）

下面给出一个通过 RDMA scale-out 网络实现 1P+1D Prefill/Decode 分离部署的快速入门示例。下一篇博客会继续展示如何在 GB 系列机柜间利用 NVLink72 做这件事。

# Prefill 节点
export VLLM_USE_FLASHINFER_MOE_FP4=1
export UCX_NET_DEVICES=mlx5_bond_0:1   # 可选，告诉 NIXL 使用指定 RDMA 网卡
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 节点
export VLLM_NIXL_SIDE_CHANNEL_HOST=${DECODE_NODE_IP}
...
# 除了 VLLM_NIXL_SIDE_CHANNEL_HOST 不同，环境变量和 vLLM CLI 与 Prefill 节点一致


# Proxy 节点
cd vllm # 进入 vLLM 源码目录，可能还需要安装相关依赖
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

# 如果你有多个 Prefiller 或 Decoder：
# 直接在 hosts 列表后追加即可，例如：--prefiller-hosts ${IP1} ${IP2} --prefiller-ports 8000 8000

# 对 proxy 做 vLLM bench（随机数据集，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

Note

vLLM v0.14.1 上的 P/D 分离：如果你要在 vLLM v0.14.1 上运行 P/D 分离，需要手动应用 PR #32698 中的补丁。 这一特性已经合并进更新的 vLLM main 分支，因此如果你用的是更高版本，通常不再需要手动打这个补丁。

这里我们使用 Nixl KV Connector 负责跨进程 / 跨节点传输 KV。Prefill 和 Decode 两侧都使用 TP2。

随着并发负载上升，P/D 分离方案相比一体化部署会逐渐体现吞吐量优势，而且差距会不断扩大，同时还能保持更低的延迟，无论是 TTFT 还是 TPOT 都更稳。延迟增长的斜率也更加平滑。

在 TPOT 上，1P1D 和 3P1D 都优于非分离部署。在 batch size 为 256 时，P/D 分离可以把 TPOT 控制在 60ms 以内，而一体化部署会超过 80ms。

当 ISL 持续增大（从 2K 增长到 8K）时，1P1D 的吞吐量开始吃紧，Prefill 成为瓶颈。请求会在 P 节点排队，导致 Decoder 无法被充分利用。增加 2 个 P 副本后（3P1D），系统就能并行处理更多请求的 Prefill 阶段，从而拿到更高的总吞吐量。

虽然 P/D 分离方案的单 GPU 吞吐量未必最高，但通过增加硬件投入，它能换来更好的 Goodput 和更强的 SLO 保证。

预告：下一篇博客将展示如何在 GB200 上借助 NVL72 做 P/D 分离部署。

致谢

感谢 vLLM 社区中参与这项工作的众多优秀工程师：

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

参考链接

• DeepSeek-V3.2-NVFP4
• DeepSeek-R1-0528-NVFP4
• Inside NVIDIA Blackwell Ultra
• PR #32698
• Verda
• 英文原文：blog.vllm.ai/2026/02/13/gb300-deepseek.html