この結果が単なる「またNVIDIAが1位」ではない理由
MLPerfの結果を見ると毎回NVIDIAが首位で、ニュースバリューが薄く見えるかもしれません。しかし今回のMLPerf Training v6.0は性質が異なります。MLCommonsが新しい事前学習ワークロードを2つ初めて追加したからです。
- DeepSeek-V3 671B (MoE) — 671Bパラメータ規模の巨大MoEモデルであり、話題のDeepSeek-R1推論モデルのベース
- GPT-OSS-20B — 小型ながら実力のあるMoEモデル
問題は、これら2つのワークロードが従来のdenseモデルとはまったく異なる学習パターンを要求する点です。トークンがexpertへ動的にルーティングされるため通信パターンが不規則で、CPU-GPU同期が頻繁に割り込み学習効率を削ります。NVIDIAはこの2つのベンチマークに唯一結果を提出し、同時に全ベンチマークで首位を獲得しました。つまり、競合がまだ最適化を完了していない領域で既に「実測性能」を出しているということです。
根拠資料: NVIDIA Developer Blog - MLPerf Training 6.0
数字で見る成績表: GB300 NVL72が叩き出した記録
まず今回のラウンドの主要結果を表で整理します。時間の単位に注目してください。「分(min)」であり「時間」ではありません。
| ワークロード | GPUプラットフォーム | クラスタ規模 | 学習時間 |
|---|---|---|---|
| DeepSeek-V3 671B (MoE) | GB300 NVL72 | 8,192 GPUs | 2.02分 |
| GPT-OSS 20B (MoE) | GB300 NVL72 | 512 GPUs | 7.43分 |
| Llama 3.1 405B | GB200 NVL72 | 8,192 GPUs | 7.07分 |
| Llama 3.1 8B | GB200 NVL72 | 1,024 GPUs | 4.46分 |
| Llama 2 70B LoRA | GB300 NVL72 | 512 GPUs | 0.4分 |
| FLUX.1 | GB300 NVL72 | 512 GPUs | 17.1分 |
| DLRM-dcnv2 | GB300 NVL72 | 64 GPUs | 0.67分 |
DeepSeek-V3 671Bが8,192 GPUで2分で学習されたという事実は、個々のGPUではなくクラスタ全体が1台の「コンピュータ」としてスケールしたことを意味します。これが成立するにはネットワークファブリック、通信オーバーラップ、パイプラインバランスがすべて噛み合う必要があります。1つでも崩れるとボトルネックが生じ、時間が数倍に膨らみます。
特にMoEのexpert parallelismはlow-entropy, bursty flowを生みます。特定のexpertにトラフィックが集中しリンク衝突が発生、従来のECMPハッシュでは有効帯域が急落します。NVIDIAはSpectrum-X EthernetのAdvanced Adaptive Routingでパケット単位にリアルタイム負荷分散し、ファブリック理論帯域に近い性能を維持しました。受信側ConnectX SuperNICがout-of-order配送を処理する構成です。
さらに特定のexpertに複数senderが同時に集中するincast状況では、Spectrum-X Congestion Controlがリアルタイムテレメトリで早期検知しsenderを事前pacingします。結果としてall-to-all通信がcomputeの背後に隠れ、tail latencyが跳ねません。
本当に注目すべきはソフトウェア: 6つの最適化を読み解く
ベンチマークの数字は結果に過ぎず、今回のラウンドの真の勝負はソフトウェアスタックで決まりました。開発者視点で実際に参考になる6点を整理します。
1. Token-dropless MoE向けFull-iteration CUDA Graphs
従来はMoEの動的ルーティングによりCPU-GPU同期が絶えず割り込み、CUDA Graphでiteration全体を包むことが不可能でした。NVIDIAはexpert演算子(quantizer, grouped GEMM, token dispatcher)を同期なしモードへ移行し、入力shapeをGPU値から直接導出するよう変更しました。デバイスメモリはpaged stashingでホスト介入なしに管理。結果、2,000 GPU以上のクラスタでCPUがcritical pathから完全に外れました。
2. CuTe DSLとカーネルフュージョン
メモリ帯域バウンド層とgrouped GEMMをフュージョンするには、ハードウェア層で数学演算とメモリ処理を結合する必要があります。CuTe DSLでレジスタローカリティを保ちつつglobal memory往復を削減。DeepSeek-V3で8%以上、GPT-OSSで93%のE2Eスピードアップが得られました。
3. MXFP8 Attention Block
従来のMoE学習はattentionに16-bit精度を使用していましたが、今回MXFP8 attentionレシピを開発しました。batched matmul入力テンソルを8-bitに保ちFP8演算の利点を活かしつつ、モデル品質は維持。cuDNNのTransformer Engineライブラリ経由で利用可能です。
4. RouterおよびHybrid EP最適化
MoE routerのelementwiseカーネルをフュージョンし、FP64 → FP32へ移行してカーネル速度5倍を達成。HybridEP内のメタデータ処理カーネルもフュージョンし、permute/unpermuteカーネルをチューニングしてE2E 5%の利得を得ました。
5. 1F1B All-to-All Overlap
Megatron-Coreにあった1F1B A2AオーバーラップスキームをCUDA Graphで包み、ホストオーバーヘッドを除去。通信ストリーム優先度調整、動的CuTe DSLカーネル、delayed wgrad対応を加え、**A2A通信オーバーラップはほぼ100%**に到達、8%の性能利得を実現しました。
6. パイプラインステージ間の不均衡最小化
カーネルが高速化するほど、パイプライン並列ステージ間の不均衡が顕在化します。DeepSeek-V3のハイブリッド層構成(先頭3層dense + 末尾MTP/logits GEMM)をMegatron-Coreのflexible pipeline layoutで再配置し、logit projection GEMMにMXFP8を適用してパイプライン不均衡1%未満、E2E 4%削減を達成しました。
実務適用の観点で重要なポイント
これらの最適化は大半がNVIDIA内部のカーネル作業ですが、Megatron Bridgeがすべての改善をパッケージングして開発者に直接提供します。最新のNeMoコンテナ26.06時点で、GB300上のDeepSeek-V3学習性能は3ヶ月で1,298 → 1,648 TFLOPS/GPU (6,338 tokens/sec/GPU) へ1.3倍向上しました。シリコンはそのままで、ソフトウェアのみでここまで引き出した点が核心です。
MoE構造自体の理解が不足している場合は、Mixture of Experts (MoE) 완벽 해부を先に読むと、今回の最適化がなぜ必要なのかがより明確になります。
日本の開発現場でこのニュースをどう捉えるか
正直に言えば、国内で8,192 GPUクラスタを直接運用するチームはごく少数です。そのため「他人事」として流しがちですが、実は押さえるべきポイントは別にあります。
第一に、ソフトウェア最適化のROIがハードウェア更新より大きいというシグナルです。 シリコンはそのままなのに3ヶ月で1.3倍の性能向上が得られたということは、皆さんが使う推論/学習スタックもバージョンアップだけで相当な利得が得られる可能性があるということです。特にvLLM、TensorRT-LLM、Megatron-LMといったスタックのリリースノートを軽視しないでください。
第二に、日本のオンプレ・SI環境ではネットワークファブリックが依然としてボトルネックです。 Spectrum-XやQuantum InfiniBandなしで一般的なEthernetでMoE学習を回すと、expert parallelismで帯域が急落します。クラウドベンダー選定時にはネットワークトポロジーを必ず確認してください。
第三に、この技術の限界も明確です。 今回の結果はclosed division基準であり、NVIDIA自身のスタックに極度に最適化された数値です。オープンソースフレームワーク(PyTorch vanilla)や他ハードウェアで同等性能を期待してはいけません。またMoE最適化はモデル構造に強く結合しているため、新しいルーティング方式が登場すれば再度チューニングが必要です。
次のステップ学習方向: MoE学習を直接扱う場合、Megatron-Coreのpipeline layoutドキュメントとTransformer EngineのFP8レシピを先に確認し、その上でCUDA GraphキャプチャがMoEでなぜ難しいのかを理解する順序が良いです。
データ主権や規制環境のため閉域網でAIを運用する必要があるチームは、クラウド接続が切れても安全にAIを運用する方法も合わせて読むと、インフラ戦略の立案に役立ちます。
結論として、今回のMLPerf 6.0は「NVIDIAがまた勝った」ではなく、フルスタック共同設計(full-stack co-design)がAI学習の実質的ボトルネックをどう除去するかを示す事例です。皆さんのパイプラインでも、ボトルネックはハードウェアではなくソフトウェアスタックのどこかに潜んでいる可能性が高いです。