SGLangとの協業：H20-96GでDeepSeek-R1を効率的にデプロイするベストプラクティス

はじめに

DeepSeek-R1のような大規模Mixture-of-Experts（MoE）モデルをデプロイするには、レイテンシ、スループット、コストの間で精細なバランスを実現する必要があります。この課題は、H20 GPUのような性能が非対称なハードウェアでは特に顕著です。H20はメモリ帯域幅は高いものの、計算スループットは低いという特徴があります。私たちは、ハイエンドGPUの厳格なSLAを満たしながら、H20のコスト優位性を活用するサービススタックを設計しました。

本記事では、この目標を達成するためのベストプラクティスを概説します。従来の手法から逸脱したハードウェア認識型のデプロイ戦略と、一連のシステムおよびカーネルレベルの最適化を含みます：

• ハードウェア認識並列化：プリフィル段階では単一ノードTP-8、デコード段階では小規模EP-16を採用し、レイテンシ目標を満たしながら障害ドメインを縮小。
• カーネルレベル最適化：FlashMLA-FP8とDeepGEMM swapABにより、H20の計算スループットを向上。
• スケジューリングとロードバランシング：Single-Batch Overlap（SBO）が小バッチスループットを向上させ、非同期Expert Affinity Load Balancerがクロスノード通信を削減。
• 軽量な可観測性：分散MoEサービス専用に設計された診断スタックにより、ボトルネックを迅速に特定。

実験により、私たちの戦略を使用して、各ノードが4096トークン入力シーケンスで16.5k入力トークン/秒および5.7k出力トークン/秒を達成することが示されました。これはH20上でのSOTA性能であり、私たちの知る限り、デプロイメント、最適化、大規模な産業実践を網羅した初の包括的な研究です。

H20の課題

H20の重要性

H20 GPUは供給が豊富で、Ant Groupは超大規模クラスタを構築することができます。わずかなスループット向上でも、日常的なコストの大幅な削減につながります。

H20 vs. H800の比較

H20はより大きなメモリ（96 GB）、より高いメモリ帯域幅（4000 GB/s）、2倍以上のNVLink帯域幅（900 GB/s）を備えていますが、計算性能は弱く、RDMA NIC帯域幅は低くなっています。推論、特にデコード段階は多くの場合メモリバウンドであり、H20の高いメモリ帯域幅と容量の利点が顕著です。私たちはこれに基づいて最適化を設計し、推論スループットを最大化しています。

ソリューション：H20での最適化と戦略

デプロイ戦略

プリフィル（Prefill）

• SLA：プリフィルは計算集約的で、マルチノードDP+EPは最初のトークンまでの時間（TTFT）を増加させ、SLAに違反します。単一ノードTPはTTFTを目標内に保ちます。
• 弾力的なスケーリング：プリフィルはKVキャッシュに応じてスケールする必要があり、単一ノードTPはリソースとキャッシュ管理を簡素化します。

デコード（Decode）

• ハードウェア特性：H20は計算を犠牲にしてより大きなメモリとより高いNVLink帯域幅（H800と比較して）を実現し、KVキャッシュを効率的に利用し、MoE通信を高帯域幅NVLinkに配置します。
• 障害ドメイン：小規模EP設定はデコードやGPU障害の影響を限定し、EP高可用性（HA）はまだ成熟していないため、小規模EPがより信頼性が高いです。

最適化

プリフィル

観察

• 長いシーケンスではMLAはMHAよりもコストが高い。
• MoEレイテンシは計算量が低いにもかかわらず予想外に高い。
• embed/mlp all reduce + RMSNorm + fused_qkv_a_proj_with_mqaはTPで冗長な通信と計算を導入。

ソリューション

• MHA/MLA：調整可能なパラメータse = extend × (extend + prefix)を導入し、バッチサイズとシーケンス長に基づいてMHAまたはMLAを選択。
• MoE：b_scale計算を最適化し、TMAでdown proj入力アクセスを再構築し、実際のエキスパート分布に基づいて設定を調整。
• TP最適化：embed/mlp reduce scatter + RMSNorm + fused_qkv_a_proj_with_mqa + all gatherを最適化し、計算と通信を削減。

デコード

ロードバランシング

Expert Affinity EPLB

標準EPLBはGPU内の負荷のみをバランスし、エキスパート間の相関を無視して、頻繁に共活性化されるエキスパートを異なるノードに分散させ、クロスノード通信を増加させます。私たちはEPLBを拡張し、top-kエキスパート共活性化を追跡してエキスパート親和性マトリックスを構築し、事後調整により高共活性化エキスパートを同一ノードに配置し、元のバージョンより約5%性能向上を実現しました。

非同期動的負荷調整

静的EPLBはロードバランシングと推論を密結合し、移行が推論をブロックしてレイテンシを引き起こします。私たちは両者を分離して並列実行し、階層転送戦略を採用して移行の影響を最小化し、静的EPLB性能に匹敵またはそれを超える性能を実現しながら、>70%のロードバランシング率を維持します。

計算

FP8 MLA

BF16 FlashMLAは性能が良好ですが最適化の余地があります。私たちはHopper（SM90）でエンドツーエンドFP8 attentionを実装し、TMAでメモリ転送、WGMMAで計算を行います。2つのワープグループがQK^TとPVをパイプライン化し、共有メモリの圧力を削減し、計算とメモリをオーバーラップさせます。BF16より約70%高速化し、以前のFP8版よりさらに約5%向上しました。

SwapAB GEMM

Hopper WGMMA PTX制約ではNが8の倍数、Mが固定64となり、粗粒度のタイリングで無駄が生じます。私たちはswapABを導入し、M次元をNにマッピングして、より細粒度のBLOCK_M（32）を実現し、MoEの可変Mワークロードのスループットを向上させました。

SBO（Single-Batch-Overlap）

なぜTBOを使わないのか

H20でのTBO Decodeの利点は限定的です：Hopper WGMMA block_mは64に固定され、小バッチは冗長なMLP GEMMを導入します；大バッチ（64/128）では低計算ハードウェアはTPOT SLAを満たせません。

SBOの仕組み

SLAに違反せずにDecodeスループットを向上させるため、SBOを採用し、DeepEPとDeepGEMMを修正しました。設計は通信-計算の整列粒度に基づいています。通信オーバーラップにおいて、トークンパケットがNICなどの要因により受信側に順不同で到着することを観察しました。