記事
マルチノードDeepSeek展開による低レイテンシーと高スループット
ほとんどのシステムでは、レイテンシとスループットはしばしば相反する目標であり、設計および展開の際に妥協が必要です。例えば、密な大規模言語モデルでは、バッチサイズを増加させるとスループットが向上する一方でレイテンシも増加します。単一マシン内でテンソル並列処理を増やすとレイテンシが低下しますが、レプリカの数が減少し、スループットが低下します。
DeepSeek-V3/R1のようなエキスパート混合モデル（MoE）は、優れたモデル能力と運用効率を最近示しています。例えば、DeepSeek-V3/R1モデルには合計6710億のパラメータがありますが、推論中に各トークンは37億のパラメータしか使用しません。このモデルアーキテクチャは、推論システムにとって挑戦と機会の両方を提供します。
この記事では、従来のシステムとは異なり、DeepSeek-V3/R1のようなMoEモデルがマルチノード展開でより多くのGPUを利用することで、ほとんどのシナリオで高いスループットと低いレイテンシを同時に達成できることを示しています。
展開アーキテクチャ
モデルが持つ大量の小さなエキスパートにより、展開は複数のデバイスにわたる必要があります。単一ノード展開（8xH200 GPUsを使用）およびマルチノード展開（8xH100 GPUsを使用）の両方を考慮しました。
両方の展開アーキテクチャは、社内開発のリクエストスケジューラーを通じてデータ並列性を活用しています。データ並列性の実装は、複数の推論エンジンインスタンスを起動し、それぞれが独立してリクエストを処理し、維持します。エンジンとのやり取りを行うリクエストスケジューラーは、可能な限り均等にリクエストを分散させ、またKV再利用を促進し、部分的に一致したプレフィックスのリクエストをキャッシュを含むサーバーに送信します。エンジンインスタンスは複数のノードにまたがりません。オプションでテンソル並列性を使用して、複数のデバイスにわたるアテンションを分割することができます。インスタンスは、単一ノードの場合はNVLink、マルチノードの場合はInfiniBandで相互接続され、エキスパートの送信と収集を行います。
単一ノード展開の構成は、スモールバッチサイズで優れたレイテンシを提供しますが、負荷が増加するとパフォーマンスが急速に低下します。
サービングエンジンを展開するには、複数のエンジンインスタンスをホストするノードあたり1つのPodを起動します。PyTorchは分散コミュニケーションの設定及びNVSHMEMの初期化の交渉を担当しています。通信に関しては、以前のブログ投稿で説明したカスタムCUDAカーネルを使用しています。2つの展開の実装はほとんど同じであり、モデルはエキスパート並列性を実装するファブリックに基づいて使用する正しいカーネルを選択します。
並列化技術
私たちのパフォーマンス比較に入る前に、DeepSeek-V3/R1のような大規模MoEモデルを展開するための重要な並列化戦略を理解することが重要です。
テンソル並列性
LLM推論では、通常、テンソル並列性（TP）がメモリ使用量を削減し、各GPUの計算を減少させるために使用され、これによりレイテンシが低下します。通常、アテンションおよびMLPレイヤーの線形射影を行または列の次元に沿って分割し、アテンション操作をアテンションヘッドの次元に沿って分割することができ柔軟性があります。
TPでは、Llama-3アーキテクチャはLinear ProjectionおよびAttention operationsの計算をGPU間で重複させることはありません。これは理想的なシャーディング方法ですが、DeepSeek-V3/R1モデルではTPではこれを達成できません。
DeepSeek-V3/R1モデルはMulti-Latent Attention（MLA）を使用します。MLAレイヤーはまず、Linear Projection kv_a_projを使用して潜在ベクトルを計算し、次に別のLinear Projection kv_b_projを使用してそれを各アテンションヘッドの空間に変換します。すべてのアテンションヘッドが同じ潜在ベクトルを共有するため、TPは潜在ベクトルを分割できず、すべてのTPランクはkv_a_projとkv_b_projのパラメータと計算を複製する必要があります。同様に、MLAは潜在ベクトルをKVキャッシュに保存するため、各TPランクはKVキャッシュの同一のコピーを保存します。
MLAには一部の重複がありますが、テンソル並列性は計算需要の一部を減少させ、これにより高出力速度が要求されるシナリオで価値があります。
エキスパート並列性
DeepSeek-V3/R1モデルはMLPレイヤーをMoEレイヤーに置き換えます。MoEレイヤーには256のルーティングされたエキスパートと1つの共有エキスパートがあります。各トークンは計算のために8つの異なるルーティングされたエキスパートに送信され、その結果は重み付け和されます。各トークンはまた共有エキスパートで計算され、その結果がルーティングされたエキスパートからの結果に加算されます。
エキスパート並列性（EP）はMoEレイヤーの典型的なシャーディングアプローチとして機能し、各GPUはコードストリームを管理しながら共有エキスパートのコピーを保持します。TPと比較して、EPの利点は、計算をより多くのGPUに分散させることができるため、各GPUの計算およびメモリ使用量を減少させることです。
エキスパート計算を行う前に、すべてのGPUはAllToAll通信を行い、トークンを対応するエキスパートがあるGPUに送信し、エキスパート計算後に別のAllToAll通信を行って各GPUからの計算結果を集めて重み付け和を行う必要があります。これら2つのAllToAll通信カーネル、DispatchとCombineをNVSHMEMを使用して最適化しました。詳細については、以前のブログ投稿で実装を紹介しました。また、カーネルはGitHubでオープンソース化されています。
データ並列性
EPにより、MoE計算を128台またはそれ以上のGPUに分散させることが可能です。しかし、MLA計算をEPで分割することはできません。この時点でデータ並列性（DP）を導入できます。各DPグループはMLAレイヤーの完全なコピーを持ち、それぞれが異なる入力を受け取り、MLAレイヤー計算を独立して行います。
MLAレイヤーのDPとTPを組み合わせて、1つのDPグループを複数のTPランクに分割できます。MoEレイヤーのEPとMLAレイヤーのDP/TPを組み込むことができます。EP = DP * TPです。例えば、16台のマシンでのEP128 DP32 TP4は、ルーティングされたエキスパートを128台のGPUに分散し、4台のGPUを1つのDPグループとして合計32の独立したDPグループを形成します。
単一ノード vs マルチノード
DeepSeekの6710億パラメータは単一の8-GPU H100マシン（80 GB * 8）のメモリ容量を超えていますが、単一の8-GPU H200マシンはモデル全体を収容することができます（141 GB * 8）。EP8 DP8 TP1構成を使用すると、GPUあたり約100 GBのメモリが使用され、KVキャッシュや他の中間結果のために約40 GBが残ります。1つのトークンは70272バイトのKVキャッシュを占有します。各リクエストが5000トークンを持つと仮定すると、各GPUはおおよそ100リクエストを収容可能です。
異なる構成下での単一ノードとマルチノード展開のパフォーマンス差を理解したいと考えました。単一ノード展開には1台のH200マシンを使用し、マルチノード展開には最大16台のH100マシンを使用しました。各展開環境に対して、TP 1, 2, 4, 8の組み合わせと、GPUあたりのバッチサイズ1, 2, 4, 8, 16, 32, 64, 128を使用しました。各リクエストが5000トークンのKVキャッシュ長を持ち、リクエストのクエリ長が2であることを前提とし、保守的に受け入れ率が60%であると仮定しました。以下の図は、異なる構成のスループットと出力速度を示しています。
水平軸は、トークン/秒単位のリクエストごとの出力速度を表しています。垂直軸は、トークン/秒単位でのマシンごとのスループットを対数スケールで示しています。各EP構成のパレートフロンティアを異なる色の線で示しています。
極めて高い出力速度が要求されるシナリオでは、単一ノードEP8 DP1 TP8をバッチサイズ1で使用することで、100トークン/秒を超える出力速度を達成できますが、このシナリオではスループットは極めて低く、出力速度に等しくなります。このシナリオでは、バッチ全体が2トークンしかなく、2*8=16までのエキスパートがアクティブ化され、合計で最大57億のパラメータがアクティブ化されます。
出力速度範囲が80-40トークン/秒の場合、スループットが増加するにつれて出力速度が大幅に低下します。一方、EP128は単一ノード展開と同じ出力速度で約5倍のスループットを持ちます。
この現象は、単一ノード展開がどのように振舞うかを調べることで説明できます。バッチサイズの増加はアクティブ化されるエキスパートの数の増加に直結しています。バッチサイズが1の場合、GPUあたりのアクティブ化されるエキスパートの平均数は2 * 8 / 8 = 2です。バッチが十分に大きいとき、すべてのエキスパートがアクティブ化され、各GPUは256 / 8 = 32エキスパートをアクティブ化します。より多くのエキスパートをアクティブ化することは、GPUがメモリからより多くのパラメータを読み取る必要があることを意味し、メモリ帯域幅の圧力を著しく増加させます。大規模言語モデルのデコードフェーズはすでにメモリ帯域幅によるボトルネックが計算パフォーマンスではなくなっているため、単一ノード展開でのバッチサイズの増加により出力速度が大幅に低下します。
4つのマルチノード展開構成（EP16, EP32, EP64, EP128）の比較からわかるように、より高いEP値はスループットと出力速度の同時改善に向けてパレートフロンティアをシフトします。
より高いEP番号を使用することで、各GPUに割り当てられるエキスパートの数が少なくなります。例えば、EP128では、各GPUは256 / 128 = 2エキスパートを担当するため、メモリ帯域幅の圧力が著しく減少します。つまり、より大きなEP番号を使用することで、より多くのメモリ帯域幅を効果的に獲得します。GPUあたりのバッチサイズが64未満の場合、バッチサイズの増加はエキスパート計算速度に大きな影響を与えません。なぜなら、入力の増加数がメモリ帯域幅の圧力を著しく増加させないからです。そのため、EP128を使用しているときに、バッチサイズの増加が出力速度に大きな影響を与えないことを観察します。
興味深いことに、大きなバッチサイズ（GPUあたり64リクエスト）の場合、単一ノード展開スループットがマルチノード展開よりもわずかに高い現象が観察されました。部分的な理由は、ノード内のNVLinkがノード間のInfiniBandよりも高い帯域幅を持っているためです。もう一つの理由は、私たちの実装における制約によるものです。この現象を後ほど詳細に分析します。
メモリ容量の制限により、EP8 DP8 TP1構成はGPUあたりのバッチサイズを128にすることができません。そのため、より高いスループットを追求するシナリオでは、マルチノード展開が依然としてより良い選択です。
計算と通信のオーバーラップ
エキスパート並列性に関しては、中断が発生し、エキスパートレイヤーの通信が行われる間、GPUがアイドル状態になるということを簡単に紹介しました。無駄を減らし、レイテンシを下げるために、データに依存しない計算タスクを見つけ、このアイドルの時間を埋める必要があります。
上の図の上部は、1層の計算フローを示しています。MoEの計算はDispatchに依存し、次の層の計算はCombineの結果に依存します。
各GPUに共有エキスパートを配置します。この方法で、共有エキスパートの計算はAllToAll通信を必要としません。したがって、Dispatchの送信直後に共有エキスパートの計算を行い、Dispatch受信の完了待ちをします。このオーバーラップスキームを「Dispatch Overlap」と呼びます。
Dispatch Overlapは実装が簡単で、非常に広範な適用可能性を持っています。この技術は、すべてのEPサイズとバッチサイズ全体にわたって共有エキスパートの計算時間を隠します。
さらに計算と通信のオーバーラップを増やすために、DeepSeek技術報告で言及したマイクロバッチングを使用しました。照合の依存性を分解するために、1つのTransformer Layerを5つのステージに分割:
ステージ1: InputNorm、QKVProj、AppendKV、BMM
ステージ2: BMM、Attn、OProj、PostNorm、Gate
ステージ3: Dispatch送信、共有エキスパート
ステージ4: Dispatch受信、MoE、Combine送信
ステージ5: Combine受信
最初の3つのデンストランスフォーマーレイヤーでは、全バッチを使用します。次の58のMoEトランスフォーマーレイヤーでは、バッチを2つのマイクロバッチに均等に分割します。2つのマイクロバッチは、3つのステージのオフセットで交互に実行されます。これら2つのマイクロバッチ間にはデータ依存性がないため、Dispatch送信やCombine送信後に別のマイクロバッチの計算に切り替えることができます。
レイテンシの内訳
次に、オーバーラップの影響を比較する実験を行い、単一ノード展開EP8とマルチノード展開EP128のパフォーマンスの違いを比較します。比較を容易にするため、次の実験にはH100 GPUを使用しました。TP1、GPUあたりのバッチサイズ128、リクエストごとのクエリ長2、KVキャッシュ長5000を使用しました。
上記の図は、1つのMoEトランスフォーマーレイヤーに費やした総時間とさまざまなケルネルタイプのレイテンシ割合を示しています。Dispatch、Combine、GroupGEMM以外のカーネルの実行時間は、EP8、EP128 NoOverlap、EP128 DispatchOverlapシリーズで等しいはずです。なぜなら、バッチサイズは同じだからです。
オーバーラップ
まず、3つのオーバーラップ方法の効果を比較しましょう。NoOverlapは合計2667µsを要し、DispatchOverlapは2651µsで、16µs（0.6%）の節約しかありません。マイクロバッチングは非常に顕著な改善を示し、合計1896µsで、29%のスピードアップが見られました。DispatchとCombineの時間は大幅に短縮されました。Dispatchは593µsから367µsに減少し、Combineは1012µsから237µsに減少しました。
計算カーネルに関しては、バッチ128を64に分割すると総実行時間が増えます。そのため、通信に費やす時間を1001µs短縮しても、総時間は771µsしか減少しませんでした。この理由は、次のルーフラインモデルを用いて説明します。
そのため、マイクロバッチングが常にパフォーマンスを向上させるわけではありません。
上記の図は、マイクロバッチの性能向上を、DispatchOverlapと比較してバッチサイズ4-128の範囲で示しています。バッチサイズが32未満の場合、マイクロバッチが5%-40%パフォーマンスを低下させます。バッチサイズが32以上の場合、マイクロバッチが10%-35%パフォーマンスを向上させます。
EP8とEP128の比較
前の図に戻り、EP8とEP128のマイクロバッチを比較してみましょう。EP8は合計で1802µsを要し、EP128の1896µsより少し短いです。記載済みのマイクロバッチによるカーネルの実行時間増加以外の主要な違いは、MoE計算用のGroupGEMMと、2つの通信カーネルであるDispatchとCombineにあります。
EP8のGroupGEMMは555µsを要し、EP128のGroupGEMMは270µsで半分に減少しました。これがマルチノード展開の主要な利点です。
残念ながら、通信に費やす時間は213µs増加し、このGroupGEMMの利点を大幅に相殺しました。別途行った通信カーネルの性能テストでは、インフィニバンド帯域幅の半分しか達成できませんでした。私たちは引き続き通信カーネルを最適化する予定です。
重要なほど遅れているカーネルはGEMMです。マイクロバッチングでGEMMは95µs増加しました。次に、以下のルーフラインセクションを使用してGEMMをより深く分析します。現時点でのGEMM実装は最適なパフォーマンスを達成していないと考えています。
ルーフライン
ルーフラインモデルは、カーネルの性能を分析する優れたツールです。その水平軸はFLOP対メモリI/Oバイト比である算数的強度を表しています。水平軸の値はカーネルの概要から直接計算でき、垂直軸は達成されるパフォーマンスを表し、FLOPを基準とした待ち時間で割ります。
カーネル性能の理論上の上限は、GPUの仕様によって直接決まります。H100のFP8ピークパフォーマンスは1979 TFLOP/sであり、ルーフラインモデルでは水平線で表されます。H100のメモリ帯域幅は3.35 TB/sであり、原点を通る直線の傾きとして表示されます。これら2つの線が、計算ボトルネックとメモリボトルネックのカーネルのパフォーマンス限界を示しています。
次に、GroupGEMMとGEMMカーネルの性能について説明します。
GroupGEMM
MoEにおけるGroupGEMMカーネルは、次の計算を実行します。合計でgグループがあり、i番目のグループはm_iトークンを持ち、[m_i, k] x [k, n] --> [m_i, n] の行列積を実行します。性能テストでは、各グループのトークン数が同じであるとし、m_i = m とします。その場合、GroupGEMMのFLOP数は2 * g * m * k * n、メモリI/Oバイトはg * (m * k + n * k + m * n)です。
DeepSeek-V3/R1モデルでは、256のエキスパートがあり、各トークンは計算のために8つのエキスパートにディスパッチされます。バッチサイズが128、クエリ長が2を仮定し、EP128 DP128構成を使用すると、各エキスパートが受け取る平均トークン数はm = 128 * 2 * 8 * 128 / 256 = 1024です。同様に、他の構成およびバッチサイズのmを計算できます。
DeepGEMMのGroupGEMMの実装を使用し、性能テストを行いました。EP8、EP16、EP32、EP64、EP128構成の組み合わせとTP1、およびバッチサイズ1-128をカバーするテストポイントを用意しました。
上記の図は、異なるEP構成下でのGroupGEMMのルーフラインモデルを示しています。異なるEPは異なるグループ数に対応しています。図はほぼ重なるパフォーマンスラインを示し、GroupGEMMの性能は主に総トークン数（g * mで表されます）によって決まることを示しています。
各EP構成のバッチサイズ128でのGPUあたりのデータポイントを示すスターは、EPが増える（およびDPが同期して増える）につれて、各エキスパートの受け取るトークン数mも増えることを示しています。EP8でのm=128に対して、EP128ではm=2048となります。
mの増加に伴い、算数的強度も増加します。ほとんどの構成では、GroupGEMMはメモリ帯域幅による制限を受けているため、mの増加が性能を改善します。
GEMM
GEMMカーネルはモデルの線形プロジェクションに対応しており、Q/K/V/Oプロジェクションが含まれます。[m, k] x [k, n] --> [m, n]の行列積に対するFLOP数は2 * m * k * n、メモリI/Oバイトはm * k + n * k + m * nです。そしてまたバッチサイズ1-128に対する待ち時間をテストできます。
上記の図は、異なるEP構成下でのGEMMのルーフラインモデルを示しています。GEMMのパフォーマンスは、メモリ帯域幅の制限を受けます。バッチサイズが増えると、算数的強度が増すため、性能が向上します。
マイクロバッチ
マイクロバッチングを使用する場合、バッチを均等に2つに分割します。2つの図からわかるように、mがm/2になると、行列積の効率が低下します。そのため、mのサイズの行列積1回を実行するよりも、m/2のサイズの行列積2回を実行する方が時間がかかります。
マルチトークン予測
この記事全体を通じて、パフォーマンスのためにMTP（Multi-Token Prediction）を用いた推論を仮定しています。MTPは、各リクエストのクエリ長を1から2に変更します。行列積においては、これはmをm * 2に変更することに相当し、行列積の効率が向上します。一方で、MLAのルーフラインモデルを描くなら、クエリ長の増加がMLAカーネル効率を大幅に向上させます。
したがって、MTPの利用はモデル効率で重要な役割を果たします。
実装と最適化
このセクションでは、DeepSeek-V3/R1モデルの実装および最適化の詳細について紹介します。
量子化
DeepSeek-V3/R1はFP8でネイティブにトレーニングされ、ブロックごとの量子化スキームを使用しています。重みは静的に量子化され、アクティベーションは動的に量子化されます。スケーリングファクターをチャンネルごとや行列ごとに静的に計算するのではなく、アクティベーションについては128要素のベクター単位で、行列については128x128のタイル単位でスケーリングファクターが計算され、量子化による精度劣化が制限されます。
Perplexityでは、CUDAとTritonカーネルのミックスを必要としますが、CUDAは特に性能に敏感で、頻繁な変更が要求されないカーネル（たとえばアテンションやGEMM）に使用され、Tritonは広範なアクティベーション、正規化、ユーティリティカーネルに使用されます。Tritonによって、ブロック量子化スキームにすぐに適応することができました。
線形およびMoEレイヤーでは、Deep GEMMカーネルと独自のTriton GEMMカーネルを組み合わせて使用しています。特定の行列の次元および低いバッチサイズではSplit-Kがレイテンシを低下させるためです。量子化されていないレイヤーは(M, K) x (K, N)の積を行うとき、(M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128))のスケーリングファクターがブロック量子化に必要です。ブロック量子化の場合、アクティベーションのスケーリングファクターは動的に、予め校正されるのではなく、リアルタイムで計算されます。アクティベーションのスケーリング・ファクターはKに沿った集約のみ行われM方向には行われないため、カーネルはスキームをサポートするためにわずかに変更が必要です。
Cuda グラフ、ブロック量子化、動的にルーティングされたトークン数をサポートするために、DeepSeek-V3/R1で使用されるSiLUアクティベーション関数には大幅な変更が必要でした。ブロック量子化は水平削減を導入するため、問題になることがありますが、カーネルはすでにその隠れ次元に沿って1024要素のチャンクにアクティベーションを分割しました。1つのブロック内では、クオンタイズされるテンソルはさらに128のブロックに分割され、最大絶対値が計算されます。Tritonは効率的なクロスワープ最大還元を生成し、わずかなオーバーヘッドでこれを行いました。
CUDA グラフの下でMoE ルーターをサポートするために、カーネルは、トークン数ごとにエキスパートを示すルーティング情報を認識し、トークン数の上限としてバッファが割り当てられていたサイズに基づいて作業をスケジュールするのではなく、直接それを読むための情報が必要です。問題は入力テンソルの次元に基づいて分割できないので、上限を保持するバッファのサイズに基づいてパーシステントカーネルを所定の数だけ起動し、ルーティング情報を読み取り、トークンがどの程度埋まっているかを決定して、動的にアクティベーションを処理します。
一部のカーネルをすでにFlashInferプロジェクトに送り込んでおり、今後より多くのコードをオープンソース化していくことを予定しています。
MLAレイヤー
MLA計算にはFlashInferを使用しています。FlashInferは柔軟なページテーブル設定と非常に高い性能をサポートしています。
q_a_projとkv_a_projを単一のqkv_a_projに融合しました。これにより、レイテンシは15.4 µs + 14.8 µs = 30.2 µsから16.7 µsに減少しました。
kv_b_projをk_b_projとv_b_projの2つの行列に分解しました。これら2つの行列に関連する計算には、FP8ブロック量子化BMMカーネルを書きました。
Cudaグラフ
Cudaグラフはカーネル起動のオーバーヘッドを大幅に削減し、重要なパフォーマンス向上をもたらします。各バッチサイズに対してCudaグラフを作成しています。
AllToAllカーネルを開発する前に、AllToAll通信にはtorch.all_to_all_single()を使用しました。この操作はすべてのGPUが同じバッチサイズを使用する必要がありますが、異なるDPグループは異なるバッチサイズを実行する可能性があります。
異なるDPグループが異なるバッチサイズを使用することを保証するために、各モデル実行の前にallreduce()操作を使用してすべてのDPグループの間で最大バッチサイズを取得します。それから、すべてのDPグループはこのバッチサイズを使用して実行します。
このアプローチはCudaグラフの使用を保証するですが、3つの欠点があります。第一に、追加のallreduce()操作を必要とします。第二に、小さいバッチサイズのDPグループがパッドされることを強制されます。第三に、実装のコードが複雑になります。
独自のAllToAllカーネルを実装した後、すべてのGPUが同じバッチサイズを使用する必要はなくなりました。そのため、追加のallreduce()操作またはバッチサイズのパッドも不要です。
MoEルーター
MoEルーターはTritonで実装され、標準ライブラリに由来する修正されたソートに依存し、ソートされた要素のインデックスも追跡します。この実装はすべてのMoEモデルで共有されており、Mixtralルーティングは、すべてのエキスパートを含むグループが同じというDeepSeekルートの特別なケースです。スパースなカーネルがトップKインデックスとスコアを直接消費するのに対し、All-to-Allを利用した密なディスパッチ/コンバインスキームはトークンベースではなくエキスパートごとの集約されたルーティング情報を必要とします。
今後の作業
今後の作業では、DeepSeekモデルの性能をさらに最適化する予定です。
最も重要な次の最適化は、Prefill Disaggregationです。DeepSeek-V3/R1モデルのプレフィル段階とデコード段階は、非常に異なる計算特性を持っています。どちらも異なる最適化戦略と展開スキームを使用できます。
MLAレイヤーにおいて、デコードフェーズではマトリックス吸収を使用してMLA計算のFLOP数を減少させます。プレフィル段階では、最初に潜在ベクトルをK/V空間にプロジェクトし、それをマルチヘッド・アテンション（MHA）形式で計算する方が良いです。
プレフィルとデコードを同じGPUで実行する場合、プレフィルがデコードの出力速度に与える影響を減らすために、通常はクエリを複数のチャンクに分割してプレフィルを行います。KVキャッシュが潜在ベクトルを保存するため、MLAをMHA形式に変換するのが難しくなります。
MoEレイヤーに関しては、デコードフェーズではできる限り大きなEPとDPを使用し、専門トークンの数を増やし、GroupGEMMのパフォーマンスを向上させます。プレフィル段階ではトークン数がすでに十分に大きいため、GroupGEMMが計算ボトルネックになっています。したがって、プレフィルに関しては小さなEPとDPを使用できます。
プレフィルとデコードが同じGPUで実行される場合、いずれかのDPグループがプレフィルを実行している限り、すべてのGPU上のMoEレイヤーのレイテンシが増加し、デコード出力速度に大きな影響を及ぼします。
Prefill Disaggregationの他に、以下の側面を最適化する予定です:
AllToAllの性能: 私たちのAllToAllカーネルは現時点でインフィニバンド帯域幅の1/3しか達成できません。引き続きこのカーネルを最適化する予定です。
EAGLE数推論: 上記のデータでは、1つのトークンを予測する数推論を使用すると仮定しました。EAGLEはツリー構造を使用して複数トークンを予測でき、出力速度を大幅に向上させることができます。
GEMMカーネル: 以前示したルーフラインモデルでわかるようにGEMMカーネルの効率は理論的な限界からまだ遠いです。引き続きこのカーネルを最適化する予定です。
GB200 NVL72: NVIDIAの最新のGB200 NVL72ソリューションでは、72 Blackwell GPUが高速なNVLinkで相互接続されています。MoEアーキテクチャモデルにとっては非常に大きなチャンスであり、チャレンジでもあります。
結論
DeepSeek MoEモデルのマルチノード展開は、通常の密なLLMでは不可能なことを達成します: スループットとレイテンシの同時改善です。エキスパートをより多くのGPUに分散させることで、デバイスごとのメモリ帯域幅の圧力を減少させ、より迅速な処理とシステムのスループットの向上を可能にします。私たちの実験は、EP128構成が単一ノード展開と同等の出力速度で最大5倍のスループットを達成することを示しています。
マイクロバッチングのような計算-通信オーバーラッピング技術はマルチノード通信のオーバーヘッドを大幅に削減し、実装は最大40%のスピードアップを示しています。カスタムAllToAll通信カーネルと最適化されたカーネル実装が6710億パラメータモデルの効率的な展開を可能にしました。
MoEアーキテクチャはその能力で人気を集めているため、これらの展開戦略はそのようなモデルを効率的にスケールアップするための貴重な洞察を提供します。