AIと読むDeepSeek-V3 Technical Report③ - Infrastructures -
3. インフラストラクチャ
3.1 コンピュータークラスター
DeepSeek-V3 は、2048 個の NVIDIA H800 GPU を搭載したクラスターでトレーニングされています。H800 クラスターの各ノードには、ノード内で NVLink および NVSwitch で接続された 8 個の GPU が含まれています。異なるノード間では、InfiniBand(IB)インターコネクトが通信を促進するために利用されています。
3.2 トレーニングフレームワーク
DeepSeek-V3 のトレーニングは、当社のエンジニアがゼロから作成した効率的で軽量なトレーニングフレームワークである HAI-LLM フレームワークによってサポートされています。全体として、DeepSeek-V3 は、16 ウェイのパイプライン並列処理(PP)、8 ノードにまたがる 64 ウェイのエキスパート並列処理(EP)、および ZeRO-1 データ並列処理(DP)を適用します。
DeepSeek-V3 の効率的なトレーニングを促進するために、細心の注意を払ったエンジニアリング最適化を実装します。まず、効率的なパイプライン並列処理のために DualPipe アルゴリズムを設計します。既存の PP メソッドと比較して、DualPipe はパイプラインバブルが少なくなっています。さらに重要なことに、フォワードおよびバックワードプロセス間で計算フェーズと通信フェーズを重複させることで、クロスノードエキスパート並列処理によって導入される大きな通信オーバーヘッドの課題に対処します。次に、IB および NVLink の帯域幅を最大限に活用し、通信専用のストリーミングマルチプロセッサ(SM)を節約するために、効率的なクロスノード全対全通信カーネルを開発します。最後に、トレーニング中のメモリフットプリントを細心の注意を払って最適化することで、高価なテンソル並列処理(TP)を使用せずに DeepSeek-V3 をトレーニングできるようにします。
3.2.1 DualPipe と計算-通信の重複
図4: 個々のフォワードおよびバックワードチャンクのペアの重複戦略(トランスフォーマーブロックの境界は揃えられていません)。オレンジ色はフォワード、緑色は「入力のバックワード」、青色は「重みのバックワード」、紫色は PP 通信、赤色はバリアを示します。全対全通信と PP 通信の両方を完全に隠すことができます。
DeepSeek-V3 では、クロスノードエキスパート並列処理によって導入される通信オーバーヘッドにより、計算対通信比が約 1:1 と非効率になっています。この課題に対処するために、フォワード計算フェーズとバックワード計算フェーズの重複を効果的に行うことでモデルトレーニングを高速化するだけでなく、パイプラインバブルを削減する DualPipe と呼ばれる革新的なパイプライン並列アルゴリズムを設計しました。
DualPipe の重要なアイデアは、個々のフォワードおよびバックワードチャンクのペア内で計算と通信を重複させることです。具体的には、各チャンクを 4 つのコンポーネント(注意、全対全ディスパッチ、MLP、全対全結合)に分割します。特に、バックワードチャンクの場合、注意と MLP の両方を、ZeroBubbleのように、入力のバックワードと重みのバックワードの 2 つの部分にさらに分割します。さらに、PP 通信コンポーネントがあります。図 4 に示すように、フォワードチャンクとバックワードチャンクのペアの場合、これらのコンポーネントを再配置し、通信と計算に専用の GPU SM の比率を手動で調整します。この重複戦略では、実行中に全対全通信と PP 通信の両方を完全に隠すことができます。効率的な重複戦略を考えると、完全な DualPipe スケジューリングを図 5 に示します。双方向パイプラインスケジューリングを採用しており、パイプラインの両端からマイクロバッチを同時にフィードし、通信のかなりの部分を完全に重複させることができます。この重複により、モデルがさらにスケールアップしても、一定の計算対通信比を維持する限り、ノード間で微細なエキスパートを採用し、ほぼゼロの全対全通信オーバーヘッドを達成できます。
図5: 8 つの PP ランクと 2 つの方向の 20 個のマイクロバッチの DualPipe スケジューリングの例。逆方向のマイクロバッチは順方向のマイクロバッチと対称であるため、説明を簡単にするためにバッチ ID を省略しています。共有の黒い境界で囲まれた 2 つのセルには、相互に重複する計算と通信があります。
さらに、大きな通信負荷がないより一般的なシナリオでも、DualPipe は依然として効率上の利点を示します。表 2 に、異なる PP メソッド間のパイプラインバブルとメモリ使用量をまとめます。表に示すように、ZB1Pおよび 1F1Bと比較して、DualPipe はパイプラインバブルを大幅に削減しながら、ピークアクティベーションメモリを
メソッド | バブル | パラメータ | アクティベーション |
---|---|---|---|
1F1B | 1× | ||
ZB1P | 1× | ||
DualPipe (Ours) | 2× |
表2: 異なるパイプライン並列メソッド間のパイプラインバブルとメモリ使用量の比較。F
はフォワードチャンクの実行時間を示し、B
はフルバックワードチャンクの実行時間を示し、W
は「重みのバックワード」チャンクの実行時間を示し、F&B
は相互に重複する 2 つのフォワードチャンクとバックワードチャンクの実行時間を示します。
3.2.2 クロスノード全対全通信の効率的な実装
DualPipe の十分な計算性能を確保するために、通信専用の SM の数を節約するために、効率的なクロスノード全対全通信カーネル(ディスパッチと結合を含む)をカスタマイズします。カーネルの実装は、MoE ゲーティングアルゴリズムとクラスターのネットワークトポロジを使用して共同設計されています。具体的には、クラスターでは、クロスノード GPU は IB で完全に相互接続されており、ノード内通信は NVLink を介して処理されます。NVLink は、約 3.2 倍の IB(50 GB/秒)の帯域幅(160 GB/秒)を提供します。IB と NVLink の異なる帯域幅を効果的に活用するために、各トークンを最大 4 つのノードにディスパッチするように制限し、IB トラフィックを削減します。各トークンのルーティング決定が行われると、最初に IB を介して、ターゲットノードの同じノード内インデックスを持つ GPU に送信されます。ターゲットノードに到達したら、後続の到着トークンによってブロックされることなく、NVLink を介してターゲットエキスパートをホストする特定の GPU に瞬時に転送されるように努めます。このようにして、IB と NVLink による通信が完全に重複し、各トークンは NVLink からの追加オーバーヘッドなしに、ノードあたり平均 3.2 エキスパートを効率的に選択できます。これは、DeepSeek-V3 は実際には 8 つのルーティングされたエキスパートのみを選択しますが、同じ通信コストを維持しながら、この数を最大 13 エキスパート(4 ノード×3.2 エキスパート/ノード)までスケールアップできることを意味します。全体として、このような通信戦略では、わずか 20 の SM で IB と NVLink の帯域幅を最大限に活用するのに十分です。
詳細には、ワープ特殊化技術を採用し、20 個の SM を 10 個の通信チャネルに分割します。ディスパッチプロセス中、(1)IB 送信、(2)IB-to-NVLink 転送、(3)NVLink 受信は、それぞれのワープによって処理されます。各通信タスクに割り当てられるワープの数は、すべての SM での実際のワークロードに応じて動的に調整されます。同様に、結合プロセス中、(1)NVLink 送信、(2)NVLink-to-IB 転送と累積、(3)IB 受信と累積も、動的に調整されたワープによって処理されます。さらに、ディスパッチカーネルと結合カーネルの両方が計算ストリームと重複するため、他の SM 計算カーネルへの影響も考慮します。具体的には、カスタマイズされた PTX(Parallel Thread Execution)命令を採用し、通信チャンクサイズを自動調整することで、L2 キャッシュの使用量と他の SM への干渉を大幅に削減します。
3.2.3 最小限のオーバーヘッドでのメモリの極端な節約
トレーニング中のメモリフットプリントを削減するために、次の手法を採用します。
RMSNorm と MLA アッププロジェクションの再計算。
RMSNorm 操作と MLA アッププロジェクションをすべてバックプロパゲーション中に再計算することで、出力アクティベーションを永続的に保存する必要がなくなります。わずかなオーバーヘッドで、この戦略により、アクティベーションを保存するためのメモリ要件が大幅に削減されます。
CPU での指数移動平均。
トレーニング中、学習率の減衰後のモデルのパフォーマンスを早期に見積もるために、モデルパラメータの指数移動平均(EMA)を保持します。EMA パラメータは CPU メモリに保存され、各トレーニングステップ後に非同期的に更新されます。この方法により、追加のメモリや時間オーバーヘッドなしで EMA パラメータを維持できます。
Multi-Token Prediction のための共有埋め込みと出力ヘッド。
DualPipe 戦略では、モデルの最も浅いレイヤー(埋め込みレイヤーを含む)と最も深いレイヤー(出力ヘッドを含む)を同じ PP ランクに展開します。この配置により、MTP モジュールとメインモデルの間で、共有埋め込みと出力ヘッドのパラメータと勾配を物理的に共有できます。この物理的な共有メカニズムにより、メモリ効率がさらに向上します。
3.3 FP8 トレーニング
図6: FP8 データ形式を使用した全体的な混合精度フレームワーク。明確にするために、線形演算子のみを示します。
低精度トレーニングの最近の進歩に触発されて、DeepSeek-V3 のトレーニングに FP8 データ形式を利用した細粒度の混合精度フレームワークを提案します。低精度トレーニングは非常に有望ですが、アクティベーション、重み、および勾配に外れ値が存在することによって制限されることがよくあります。推論量子化では大きな進歩が見られましたが、大規模言語モデルの事前トレーニングで低精度技術の適用に成功したことを実証する研究は比較的少ないです。この課題に対処し、FP8 形式の動的範囲を効果的に拡張するために、細粒度の量子化戦略を導入します。これは、
3.3.1 混合精度フレームワーク
低精度トレーニングで広く採用されている手法に基づいて、FP8 トレーニング用の混合精度フレームワークを提案します。このフレームワークでは、ほとんどの計算密度の高い演算は FP8 で実行されますが、いくつかの重要な演算は、トレーニング効率と数値安定性のバランスをとるために、元のデータ形式で戦略的に維持されます。全体のフレームワークを図 6 に示します。
まず、モデルトレーニングを高速化するために、コア計算カーネル、つまり GEMM 演算の大部分が FP8 精度で実装されています。これらの GEMM 演算は、FP8 テンソルを入力として受け取り、BF16 または FP32 で出力を生成します。図 6 に示すように、線形演算子に関連付けられた 3 つの GEMM、つまり Fprop(フォワードパス)、Dgrad(アクティベーションバックワードパス)、および Wgrad(重みバックワードパス)は、FP8 で実行されます。この設計は、理論的には元の BF16 メソッドと比較して計算速度を 2 倍にします。さらに、FP8 Wgrad GEMM により、アクティベーションをバックワードパスで使用するために FP8 で保存できます。これにより、メモリ消費量が大幅に削減されます。
FP8 形式の効率上の利点にもかかわらず、特定の演算子は、低精度計算に対する感度の高さから、より高い精度を必要とします。さらに、一部の低コストの演算子も、トレーニングコスト全体に対する無視できるオーバーヘッドでより高い精度を利用できます。このため、注意深い調査の後、次のコンポーネントについては元の精度(例:BF16 または FP32)を維持します。埋め込みモジュール、出力ヘッド、MoE ゲーティングモジュール、正規化演算子、および注意演算子です。これらの高精度のターゲットを絞った保持により、DeepSeek-V3 の安定したトレーニングダイナミクスが確保されます。数値安定性をさらに保証するために、マスターウェイト、ウェイト勾配、およびオプティマイザの状態をより高い精度で保存します。これらの高精度コンポーネントはメモリオーバーヘッドを招きますが、分散トレーニングシステムの複数の DP ランク間で効率的なシャーディングを行うことで、その影響を最小限に抑えることができます。
図7: (a) 特徴量の外れ値によって引き起こされる量子化誤差を軽減するための細粒度量子化手法を提案します。説明を簡単にするために、Fprop のみを示します。(b) 量子化戦略と組み合わせて、高精度累積のために
3.3.2 量子化と乗算による精度の向上
混合精度 FP8 フレームワークに基づいて、量子化手法と乗算プロセスの両方に焦点を当てて、低精度トレーニングの精度を向上させるためのいくつかの戦略を導入します。
細粒度の量子化。
低精度トレーニングフレームワークでは、FP8 形式の限られた動的範囲により、オーバーフローとアンダーフローが一般的な課題です。これは、指数ビットが削減されているためです。標準的な手法として、入力テンソルの絶対値の最大値を FP8 の最大表現可能な値にスケーリングすることにより、入力分布を FP8 形式の表現可能な範囲に合わせます。この手法により、低精度トレーニングはアクティベーションの外れ値に非常に敏感になり、量子化精度が大幅に低下する可能性があります。これを解決するために、より粒度の細かいレベルでスケーリングを適用する細粒度の量子化手法を提案します。図 7(a)に示すように、(1)アクティベーションの場合、1x128 タイルベース(つまり、128 チャネルあたりトークンごと)で要素をグループ化してスケーリングします。また、(2)重みの場合、128x128 ブロックベース(つまり、128 出力チャネルあたり 128 入力チャネル)で要素をグループ化してスケーリングします。このアプローチにより、量子化プロセスは、要素の小さなグループに応じてスケールを調整することで、外れ値に適切に対応できるようになります。付録 B.2 では、重みの量子化と同じ方法でブロックベースでアクティベーションをグループ化およびスケーリングした場合のトレーニングの不安定性についてさらに説明します。
私たちの方法の重要な変更点の 1 つは、GEMM 演算の内側次元に沿ってグループごとのスケーリング係数を導入することです。この機能は、標準の FP8 GEMM では直接サポートされていません。ただし、正確な FP32 累積戦略と組み合わせると、効率的に実装できます。
特に、細粒度の量子化戦略は、マイクロスケーリング形式のアイデアと非常に一致していますが、NVIDIA の次世代 GPU(Blackwell シリーズ)のテンソルコアは、量子化粒度が小さいマイクロスケーリング形式のサポートを発表しています(NVIDIA, 2024a)。私たちの設計が、将来の作業が最新の GPU アーキテクチャに対応するための参考になることを願っています。
累積精度の向上。
低精度 GEMM 演算はアンダーフローの問題に悩まされることが多く、その精度は高精度累積に大きく依存します。高精度累積は通常、FP32 精度で実行されます(Kalamkar et al., 2019; Narang et al., 2017)。ただし、NVIDIA H800 GPU の FP8 GEMM の累積精度は、約 14 ビットの保持に制限されていることがわかりました。これは、FP32 累積精度よりも大幅に低くなっています。この問題は、内側次元 K が大きい場合にさらに顕著になります。これは、バッチサイズとモデル幅が増加する大規模モデルトレーニングでは典型的なシナリオです。たとえば、K = 4096 の 2 つのランダム行列の GEMM 演算では、予備テストで、テンソルコアの限られた累積精度により、最大相対誤差がほぼ 2% になります。これらの問題にもかかわらず、限られた累積精度は、一部の FP8 フレームワーク(NVIDIA, 2024b)で依然としてデフォルトのオプションであり、トレーニング精度を著しく制限しています。
この問題に対処するために、高精度を実現するための CUDA コアへの昇格戦略を採用します)。プロセスを図 7(b)に示します。具体的には、テンソルコアでの MMA(行列乗算-累積)の実行中、中間結果は制限されたビット幅を使用して累積されます。
この変更により、単一のワープグループの WGMMA(Warpgroup-level Matrix Multiply-Accumulate)命令の発行率が低下することに注意してください。ただし、H800 アーキテクチャでは、通常、2 つの WGMMA が同時に持続します。一方のワープグループが昇格演算を実行している間、もう一方のワープグループは MMA 演算を実行できます。この設計により、2 つの演算の重複が可能になり、テンソルコアの高い利用率を維持できます。実験に基づいて、
指数よりも仮数。
Fprop で E4M3(4 ビット指数と 3 ビット仮数)を使用し、Dgrad と Wgrad で E5M2(5 ビット指数と 2 ビット仮数)を使用する以前の研究で採用されていたハイブリッド FP8 形式とは対照的に、すべてのテンソルで E4M3 形式を採用し、より高い精度を実現します。このアプローチの実現可能性は、細粒度の量子化戦略、つまりタイルおよびブロックごとのスケーリングに起因すると考えられます。小さな要素グループで動作することで、私たちの方法論は、これらのグループ化された要素間で指数ビットを効果的に共有し、限られた動的範囲の影響を軽減します。
オンライン量子化。
遅延量子化は、テンソル単位の量子化フレームワークで採用されています。これは、現在の値を推測するために、以前の反復での絶対値の最大値の履歴を保持します。正確なスケールを確保し、フレームワークを簡素化するために、1x128 アクティベーションタイルまたは 128x128 ウェイトブロックごとに最大絶対値をオンラインで計算します。それに基づいて、スケーリング係数を導出し、アクティベーションまたはウェイトをオンラインで FP8 形式に量子化します。
3.3.3 低精度のストレージと通信
FP8 トレーニングフレームワークと組み合わせて、キャッシュされたアクティベーションとオプティマイザの状態を低精度形式に圧縮することで、メモリ消費量と通信オーバーヘッドをさらに削減します。
低精度のオプティマイザの状態。
AdamWオプティマイザの最初のモーメントと 2 番目のモーメントを追跡するために、FP32 の代わりに BF16 データ形式を採用し、観測可能なパフォーマンスの低下はありません。ただし、(オプティマイザによって保存された)マスターウェイトと(バッチサイズ累積に使用される)勾配は、トレーニング全体を通して数値安定性を確保するために、依然として FP32 で保持されます。
低精度の活性化。
図 6 に示すように、Wgrad 演算は FP8 で実行されます。メモリ消費量を削減するために、線形演算子のバックワードパス用にアクティベーションを FP8 形式でキャッシュするのが自然な選択です。ただし、低コストの高精度トレーニングのために、いくつかの演算子で特別な考慮事項が取られます。
(1) 注意演算子の後の線形入力。これらのアクティベーションは、精度に敏感な注意演算子のバックワードパスでも使用されます。これらのアクティベーション専用に、カスタマイズされた E5M6 データ形式を採用します。さらに、これらのアクティベーションは、バックワードパスで 1x128 量子化タイルから 128x1 タイルに変換されます。余分な量子化誤差を導入しないように、すべてのスケーリング係数は丸められ、つまり 2 の整数乗になります。
(2) MoE の SwiGLU 演算子の入力。メモリコストをさらに削減するために、SwiGLU 演算子の入力をキャッシュし、その出力をバックワードパスで再計算します。これらのアクティベーションも、細粒度の量子化手法を使用して FP8 で保存され、メモリ効率と計算精度のバランスをとります。
低精度の通信。
通信帯域幅は、MoE モデルのトレーニングにおける重要なボトルネックです。この課題を軽減するために、MoE アッププロジェクションの前にアクティベーションを FP8 に量子化し、MoE アッププロジェクションで FP8 Fprop と互換性のあるディスパッチコンポーネントを適用します。注意演算子の後の線形入力と同様に、このアクティベーションのスケーリング係数は 2 の整数乗です。同様の戦略が、MoE ダウンプロジェクションの前のアクティベーション勾配に適用されます。フォワードおよびバックワード結合コンポーネントの両方で、トレーニングパイプラインの重要な部分でトレーニング精度を維持するために BF16 で保持します。
3.4 推論と展開
DeepSeek-V3 は H800 クラスターに展開されており、各ノード内の GPU は NVLink を使用して相互接続されており、クラスター全体のすべての GPU は IB を介して完全に相互接続されています。オンラインサービスのサービスレベル目標(SLO)と高スループットの両方を同時に確保するために、プリフィル段階とデコード段階を分離する次の展開戦略を採用します。
3.4.1 プリフィル
プリフィル段階の最小展開ユニットは、32 個の GPU を搭載した 4 つのノードで構成されます。注意部分では、シーケンス並列処理(SP)と組み合わせた 4 ウェイテンソル並列処理(TP4)を採用し、8 ウェイデータ並列処理(DP8)と組み合わせています。その小さな TP サイズ(4)は、TP 通信のオーバーヘッドを制限します。MoE 部分では、32 ウェイエキスパート並列処理(EP32)を使用します。これにより、各エキスパートが十分に大きなバッチサイズを処理することが保証され、計算効率が向上します。MoE 全対全通信については、トレーニングと同じ方法を使用します。最初に、IB を介してノード間でトークンを転送し、次に NVLink を介してノード内 GPU 間で転送します。特に、浅いレイヤーの密な MLP には 1 ウェイテンソル並列処理を使用して、TP 通信を節約します。
MoE 部分の異なるエキスパート間で負荷分散を実現するには、各 GPU がほぼ同じ数のトークンを処理するようにする必要があります。このために、負荷の高いエキスパートを複製し、冗長に展開する冗長エキスパートの展開戦略を導入します。負荷の高いエキスパートは、オンライン展開中に収集された統計に基づいて検出され、定期的に(たとえば、10 分ごと)調整されます。冗長エキスパートのセットを決定した後、観察された負荷に基づいてノード内の GPU 間でエキスパートを慎重に再配置し、クロスノード全対全通信オーバーヘッドを増加させることなく、可能な限り GPU 全体の負荷を分散するように努めます。DeepSeek-V3 の展開では、プリフィル段階に 32 個の冗長エキスパートを設定します。各 GPU では、ホストする元の 8 つのエキスパートに加えて、追加の冗長エキスパートも 1 つホストします。
さらに、プリフィル段階では、スループットを向上させ、全対全および TP 通信のオーバーヘッドを隠すために、計算負荷が類似した 2 つのマイクロバッチを同時に処理し、1 つのマイクロバッチの注意と MoE を別のマイクロバッチのディスパッチと結合と重複させます。
最後に、エキスパートの動的冗長戦略を検討しています。ここでは、各 GPU がより多くのエキスパート(たとえば、16 個のエキスパート)をホストしますが、各推論ステップ中にアクティブ化されるのは 9 つのみです。各レイヤーでの全対全演算を開始する前に、その場でグローバルに最適なルーティングスキームを計算します。プリフィル段階にはかなりの計算が含まれるため、このルーティングスキームの計算オーバーヘッドはほぼ無視できます。
3.4.2 デコード
デコード中、共有エキスパートはルーティングされたエキスパートとして扱います。この観点から見ると、各トークンはルーティング中に 9 つのエキスパートを選択します。ここで、共有エキスパートは常に選択される負荷の高いエキスパートと見なされます。デコード段階の最小展開ユニットは、320 個の GPU を搭載した 40 個のノードで構成されます。注意部分では、SP と組み合わせた TP4 を採用し、DP80 と組み合わせていますが、MoE 部分では EP320 を使用します。MoE 部分では、各 GPU は 1 つのエキスパートのみをホストし、64 個の GPU が冗長エキスパートと共有エキスパートをホストする役割を担います。ディスパッチ部分と結合部分の全対全通信は、低レイテンシーを実現するために、IB を介した直接のポイントツーポイント転送によって実行されます。さらに、IBGDA(NVIDIA, 2022)テクノロジーを活用して、レイテンシーをさらに最小限に抑え、通信効率を向上させます。
プリフィルと同様に、オンラインサービスからの統計的なエキスパート負荷に基づいて、特定の間隔で冗長エキスパートのセットを定期的に決定します。ただし、各 GPU は 1 つのエキスパートしかホストしないため、エキスパートを再配置する必要はありません。デコードの動的冗長戦略も検討しています。ただし、これには、グローバルに最適なルーティングスキームを計算するアルゴリズムと、オーバーヘッドを削減するためのディスパッチカーネルとの融合をより慎重に最適化する必要があります。
さらに、スループットを向上させ、全対全通信のオーバーヘッドを隠すために、デコード段階で計算負荷が類似した 2 つのマイクロバッチを同時に処理することも検討しています。プリフィルとは異なり、注意はデコード段階でより多くの時間を消費します。したがって、1 つのマイクロバッチの注意を別のマイクロバッチのディスパッチ + MoE + 結合と重複させます。デコード段階では、エキスパートごとのバッチサイズは比較的小さく(通常は 256 トークン以内)、ボトルネックは計算ではなくメモリアクセスです。MoE 部分では、1 つのエキスパートのパラメータのみをロードする必要があるため、メモリアクセスオーバーヘッドは最小限であり、SM の使用数を減らしても全体的なパフォーマンスに大きな影響はありません。したがって、注意部分の計算速度に影響を与えないように、ディスパッチ + MoE + 結合に SM の一部のみを割り当てることができます。
3.5 ハードウェア設計に関する提案
全対全通信と FP8 トレーニングスキームの実装に基づいて、AI ハードウェアベンダーにチップ設計に関する次の提案を行います。
3.5.1 通信ハードウェア
DeepSeek-V3 では、計算中の通信レイテンシーを隠すために、計算と通信の重複を実装します。これにより、シリアル計算と通信と比較して、通信帯域幅への依存度が大幅に削減されます。ただし、現在の通信実装は高価な SM に依存しています(たとえば、この目的のために H800 GPU で利用可能な 132 個の SM のうち 20 個を割り当てます)。これにより、計算スループットが制限されます。さらに、通信に SM を使用すると、テンソルコアが完全に利用されないため、大きな非効率が生じます。
現在、SM は主に全対全通信のために次のタスクを実行します。
- 単一の GPU から同じノード内の複数の GPU に宛てられた IB トラフィックを集約しながら、IB(InfiniBand)ドメインと NVLink ドメイン間でデータを転送します。
- RDMA バッファ(登録された GPU メモリ領域)と入出力バッファの間でデータを転送します。
- 全対全結合の reduce 操作を実行します。
- IB および NVLink ドメイン全体の複数のエキスパートへのチャンク化されたデータ転送中に、細粒度のメモリレイアウトを管理します。
将来のベンダーが、価値のある計算ユニット SM からこれらの通信タスクをオフロードするハードウェアを開発し、NVIDIA SHARP Graham et al. (2016) のような GPU コプロセッサまたはネットワークコプロセッサとして機能することを願っています。さらに、アプリケーションプログラミングの複雑さを軽減するために、このハードウェアが計算ユニットの観点から IB(スケールアウト)および NVLink(スケールアップ)ネットワークを統合することを目標としています。この統合インターフェイスにより、計算ユニットは、単純なプリミティブに基づいて通信要求を送信することで、IB-NVLink 統合ドメイン全体で読み取り、書き込み、マルチキャスト、および reduce などの操作を簡単に実行できます。
3.5.2 計算ハードウェア
テンソルコアにおけるより高い FP8 GEMM 累積精度。
NVIDIA Hopper アーキテクチャの現在のテンソルコア実装では、FP8 GEMM(一般行列乗算)は固定小数点累積を採用しており、加算前に最大の指数に基づいて右シフトで仮数積を整列させます。実験では、符号付き右シフト後の各仮数積の最上位 14 ビットのみが使用され、この範囲を超えるビットは切り捨てられることが明らかになりました。ただし、たとえば、32 個の FP8 × FP8 乗算の累積から正確な FP32 結果を達成するには、少なくとも 34 ビットの精度が必要です。したがって、将来のチップ設計では、テンソルコアでの累積精度を向上させて、フル精度累積をサポートするか、トレーニングおよび推論アルゴリズムの精度要件に応じて適切な累積ビット幅を選択することをお勧めします。このアプローチにより、計算効率を維持しながら、エラーが許容範囲内に収まることが保証されます。
タイル単位およびブロック単位の量子化のサポート。
現在の GPU はテンソル単位の量子化のみをサポートしており、タイル単位およびブロック単位の量子化のような細粒度の量子化に対するネイティブサポートが欠如しています。現在の実装では、N_C
間隔に達すると、部分的な結果がテンソルコアから CUDA コアにコピーされ、スケーリング係数と乗算され、CUDA コアの FP32 レジスタに追加されます。逆量子化オーバーヘッドは、正確な FP32 累積戦略と組み合わせることで大幅に軽減されますが、テンソルコアと CUDA コア間の頻繁なデータ移動は、依然として計算効率を制限します。したがって、将来のチップでは、テンソルコアがスケーリング係数を受信し、グループスケーリングを使用して MMA を実装できるようにすることで、細粒度の量子化をサポートすることをお勧めします。このようにして、頻繁なデータ移動を回避しながら、最終結果が得られるまで、部分和の累積と逆量子化全体をテンソルコア内で直接完了できます。
オンライン量子化のサポート。
現在の実装は、私たちの研究で実証されたその有効性にもかかわらず、オンライン量子化を効果的にサポートするのに苦労しています。既存のプロセスでは、量子化のために HBM(高帯域幅メモリ)から 128 個の BF16 アクティベーション値(前の計算の出力)を読み取る必要があり、量子化された FP8 値は MMA 用に再度読み込まれるために HBM に書き戻されます。この非効率性に対処するために、将来のチップでは、FP8 キャストと TMA(テンソルメモリアクセラレータ)アクセスを 1 つの融合演算に統合し、グローバルメモリから共有メモリへのアクティベーションの転送中に量子化を完了して、頻繁なメモリの読み書きを回避することをお勧めします。また、高速化のためのワープレベルのキャスト命令をサポートすることもお勧めします。これにより、レイヤー正規化と FP8 キャストのより良い融合がさらに容易になります。あるいは、HBM の近くに計算ロジックを配置するニアメモリコンピューティングアプローチを採用することもできます。この場合、BF16 要素を GPU の HBM から読み取るときに直接 FP8 にキャストできるため、チップ外メモリへのアクセスを約 50% 削減できます。
転置 GEMM 演算のサポート。
現在のアーキテクチャでは、行列転置を GEMM 演算と融合するのは面倒です。ワークフローでは、フォワードパス中のアクティベーションは 1x128 FP8 タイルに量子化されて保存されます。バックワードパス中、行列を読み出し、逆量子化し、転置し、128x1 タイルに再量子化して、HBM に保存する必要があります。メモリ操作を削減するために、将来のチップでは、トレーニングと推論の両方で必要な精度について、MMA 演算の前に共有メモリから行列の転置読み取りを直接有効にすることをお勧めします。FP8 形式変換と TMA アクセスの融合と組み合わせると、この強化により量子化ワークフローが大幅に合理化されます。
Pre-Trainingへ続く
Discussion