NVIDIA、MoE学習を高速化する融合カーネル

NVIDIA Technical Blog は 2026年6月15日、Mixture-of-Experts モデルの学習スループットを高める高度な融合カーネルを解説しました。CuTe DSL で実装されたカスタム融合MLPカーネルにより、MoEブロックのメモリ転送や同期のボトルネックを減らす狙いです。

要点

• NVIDIA は、denseモデルとMoEモデル向けの融合MLPカーネルを紹介しています。
• 未融合パスと比べて、カーネルレベルで1.3倍から2倍の高速化が示されています。
• DeepSeek-V3 の事前学習構成ではエンドツーエンドで最大8%、GPT-OSS の事前学習構成では93%の改善に言及しています。
• GLU系活性化、量子化、スケーリング、クランプ、バイアス、動的スケジューリングなどを融合して扱います。
• cuDNN Frontend、Transformer Engine、Megatron Core から利用できるため、既存の大規模学習基盤への取り込みが意識されています。

今回のブログ記事で語られていること

この記事は、MoEモデルの品質そのものではなく、学習基盤の効率を上げる低レイヤーの最適化を扱っています。MoEは、各トークンに対して一部のエキスパートだけを動かすことで、モデル容量を増やしながら計算量を抑える設計です。しかし実際の学習では、エキスパートへのルーティング、活性化関数、量子化、通信、CPU同期、メモリ転送が複雑に絡み、GPUのTensor Coreを十分に使い切れない場面が出ます。NVIDIAの記事は、このMoEブロック内のボトルネックを、融合カーネルでまとめて減らすという内容です。

公式記事では、活性化関数がメモリ律速になりやすいこと、ルーティングされたエキスパートごとのトークン数計算でCPU同期が露出しやすいこと、量子化処理もTensor Coreを待たせる要因になることが整理されています。これに対して、GroupGEMM、活性化、量子化、転置、逆活性化などを融合したカーネル群を用意し、同期なしMoE実行とフルイテレーションCUDA Graphsを可能にする方向が示されています。対応する活性化関数として SwiGLU、GeGLU、sReLU なども挙げられています。

実務で重要なのは、この更新がモデル研究者だけでなく、学習基盤チームに直接関係する点です。MoEの訓練では、モデル構成やデータだけでなく、カーネル、量子化形式、通信オーバーラップ、GPU利用率、フレームワーク統合が学習時間とコストを左右します。NVIDIAは、cuDNN Frontend、Transformer Engine、Megatron Core から利用できると説明しており、既存の大規模学習スタックに組み込みやすくする意図が読み取れます。

ただし、記事中の性能数値は特定の構成に依存します。DeepSeek-V3 と GPT-OSS の例では改善幅が大きく異なっており、これはモデル構造、既存のボトルネック、GPU構成、通信、量子化形式、学習コードの状態によって効果が変わることを示しています。自社の学習基盤で同じ改善が出るとは限らないため、まずプロファイリングでどこが詰まっているかを確認すべきです。

実務で確認したいこと

AI基盤チームは、MoE学習でGPU利用率が下がっている箇所、CPU同期、量子化処理、活性化関数、通信待ちをプロファイルしてください。そのうえで、Transformer Engine や Megatron Core のバージョン、対応GPU、量子化形式、モデル構成が今回の最適化を使えるかを確認する必要があります。

また、カーネル変更は速度だけでなく数値安定性や再現性にも影響します。既存のチェックポイント、評価指標、損失推移、分散学習の障害時復旧と合わせて検証するのが安全です。

今回のブログ記事が関係する人

関係するのは、大規模言語モデルやMoEモデルを訓練するAI基盤チーム、Megatron Core や Transformer Engine を使う機械学習エンジニア、GPUクラスタの利用率と学習コストを改善したいプラットフォーム担当です。

結局、今回のブログ記事をどう読むべきか

NVIDIAの記事は、MoEモデルを大規模に訓練する際の実効コストを下げるためのシステム最適化です。MoEの採用を検討するチームは、モデル能力だけでなく、学習基盤がMoE特有のメモリ・同期・量子化ボトルネックに対応できるかを確認する必要があります。