限界を超えて:H20上でのDeepSeek-V4-Proのサービス最適化

限界を超えて:H20上でのDeepSeek-V4-Proのサービス最適化

1. はじめに

DeepSeek-V4-Proは1.6兆パラメータを持つMoEモデルであり、FP8およびFP4の両方の重みを提供する。このような大規模モデルはNVIDIA Blackwell GPUに適しているが、ネイティブFP4 Tensor Coreなどの利点を欠くH20 GPUも依然として広く展開されている。

ハードウェアの制約があっても、サービス要件が下がるわけではない。長いコンテキストのプリフィルではTTFTを制御する必要があり、インタラクティブなデコードでは各サービス層のTPOT目標を満たす必要がある。

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

1つのモデルに複数のサービス構成が必要となる。ワークロードの特性、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

バッチサイズ1において、H20-141GBは271 output tokens/sを達成し、最適化後のプリフィルスループットは8.45k input tokens/sに達し、100万トークンのプロンプト処理はわずか43.7秒で完了する。高スループットデコード構成では、1ノードあたり4.67k output tokens/sを実現する。