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

DeepSeek-V3.2（NVFP4 + TP2）已在 GB300（SM103 - Blackwell Ultra）上成功、顺畅地运行。借助 FP4 量化，其单 GPU 在纯 Prefill 场景下的吞吐量达到 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 倍。

注意：本文侧重于架构和部署验证，而非极致的吞吐量调优，测试结果反映的是可复现的基线性能。

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

• • 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)

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

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

• • DeepSeek-V3.2-NVFP4^[1]
• • DeepSeek-R1-0528-NVFP4^[2]

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
# 或
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

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 更细粒度的分区稀释了每 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 总吞吐量对比：

• • 在纯 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 前向计算，相比 Hopper 的 FP8 更为高效。这些因素共同推动了 Decode 阶段的显著性能飞跃。

参考：Inside NVIDIA Blackwell Ultra^[3]

GB300 在小规模节点内 TP2 配置下也展现出优于 B300 的小幅提升。

EP2 vs. TP2 的选择

鉴于 DeepSeek-R1 的权重可以放入仅两张 B300 GPU 的 HBM 中，我们探索了基于 TP2 还是基于 EP2 进行 DP 扩展更合适。

注意：切换到 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 步骤都会引入 GPU 间通信开销，导致 TPOT 相比 EP2 下降 50% 到 2 倍。

然而，TP 也将 TTFT 缩短了约 50%，加速了每个步骤的执行。这一改善抵消了 TPOT 的下降，最终在输出 token 吞吐量方面实现了 5%-20% 的整体增益。

结论

• • 对于 GB300 上的 DeepSeek-R1 PD分离部署，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 批处理和系统并发能力。

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

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

• • DeepSeek R1 在 EP2 下可达约 22476 TGS 的 Prefill 峰值吞吐量。
• • 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 层步骤的内核执行时间是 MLA 的 2.7 倍。

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

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

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

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

以下是通过 RDMA scaleout 网络进行 1P+1D 分离部署的快速入门教程（下篇博客将展示在 NVLink72 跨 GB 系列机柜上的实践技巧）。

# 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 CLI 与 Prefill 节点完全一致，仅 VLLM_NIXL_SIDE_CHANNEL_HOST 不同


# 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 基准测试（使用随机数据集，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^[4] 中的补丁。
不过，该功能已合并到最新的 vLLM main 分支，如果您使用的是更新版本，可能不需要此补丁。

我们使用 Nixl KV Connector 来实现跨进程/节点的 KV 传输。P 和 D 角色均使用 TP2 策略。

随着并发负载增加，PD 分离部署相比整合式部署展现出吞吐量优势，差距不断扩大，同时保持更低的延迟（TTFT 和 TPOT）。延迟增长的斜率也更为平稳。

在 TPOT 方面，1P1D 和 3P1D 均优于非PD分离部署。在 batch size 为 256 时，PD分离部署将 TPOT 控制在 60ms 以内，而整合式部署超过 80ms。

当 ISL 持续增长（从 2K 到 8K）时，1P1D 部署的吞吐量开始捉襟见肘，Prefill 成为瓶颈。请求在 P 节点排队等待，无法充分利用 Decoder 的算力。增加 2 个 P 副本（3P1D）后，可以并行处理更多请求的 Prefill 阶段，实现更优的总吞吐量。

虽然PD分离部署的单 GPU 吞吐量未必最高，但通过更多硬件投入，可以获得更好的 Goodput 和 SLO 保障。