突破极限:DeepSeek-V4-Pro 在 H20 上的服务优化

突破极限:DeepSeek-V4-Pro 在 H20 上的服务优化
突破极限:DeepSeek-V4-Pro 在 H20 上的服务优化

1. 引言

DeepSeek-V4-Pro是一款拥有1.6万亿参数的MoE模型,同时提供FP8与FP4权重。此类大规模模型天然适合NVIDIA Blackwell GPU,但H20 GPU仍广泛部署,尽管缺少原生FP4 Tensor Core等优势。

硬件限制并未降低服务要求。长上下文预填充仍需控制TTFT,交互式解码需满足各服务层级的TPOT目标。

Hardware specification comparison across H20-96GB, H20-141GB, and B300, covering FP4 and FP8 compute, HBM capacity, memory bandwidth, NVLink, and RDMA

一个模型需要多种服务配置。工作负载特征、SLO与硬件行为共同决定部署拓扑。

2. 从硬件约束到服务配置

2.1 硬件约束与角色分配

Hardware assignment by serving role: H20-96GB serves TTFT-sensitive prefill with short-lived state, while H20-141GB serves KV-capacity-bound decode with persistent state

2.2 容量选择

采用Humming MXFP4AFP8减少权重占用,Online C128扩展KV容量。

Two horizontal bar-chart panels show full-token capacity scaling for DP32-EP32 and PP2-TP8 from Baseline FP8 through Humming MXFP4AFP8 to Online C128

2.3 场景化服务配置

Two independent prefill deployment strategies: PP2 and PP4 use different layer partitions while every stage follows the same Attention-CP8 and MoE-TP8 execution pathSingle-node TP8 is the dashed reference and PP2-TP8 is the two-node low-latency serving profile used in our deployment; both execute Attention-TP8 and MoE-TP8, each followed by its own AllReduceReplacing MoE-EP with MoE-TP in the prefill pathSymmetric-memory collectives provide a reusable foundation for TP and CP, while fused Prefill kernels collapse the communication-heavy critical pathHumming prefill workflow from routing capture through separate W13 and W2 tuning to staged validationPP2-TP8 DSpark execution coordinated across two pipeline stages, with target hidden states sent to Stage 1 and accepted tokens and next candidates returned under a shared stage-tick protocol

在batch size 1下,H20-141GB达到271 output tokens/s,优化后预填充吞吐达8.45k input tokens/s,1M-token提示处理仅需43.7秒。高吞吐解码配置下每节点达4.67k output tokens/s。