Roofline分析が明らかにする、Hopper上でDeepSeek-V3のZeRO-3が失敗する理由

H800クラスタでのDeepSeek-V3の学習構成を分析しているインフラエンジニアは、最適な並列化戦略を決定するためにRoofline分析を使用しています。2026年10月に公開されたこの技術的な詳細解説では、Fully Sharded Data Parallelism（FSDP、別名ZeRO-3）がこの特定のモデルアーキテクチャをスケールアップする際に深刻な通信ボトルネックを生み出すことを実証しています。

この分析は、システムを計算バウンドではなく通信バウンドにしないために、パイプライン並列化が必要であると結論づけています。理論上のハードウェア限界と実際の測定性能を比較することで、著者らは複数のフルスケールシステムを構築しベンチマークすることなく、学習効率を予測するための手法を提供しています。

何が起きたか

DeepSeek-V3の学習に関するシリーズの後編で、著者らは並列化の選択、アクティベーションチェックポインティング、低精度演算がメモリ要件にどのように影響するかを検討しました。彼らは、モデルが2048ノードのH800クラスタに収まるような構成を特定しました。著者らは、この結果は偶然ではないと指摘しています。モデルアーキテクチャを固定し、DeepSeekが使用した特定のハードウェアを対象とすれば、元のチームが選択した構成に自然と導かれるからです。

対処すべき核心的な課題は、フルサイズのクラスタで複数のシステムを実装・ベンチマークする prohibitive なコストをかけることなく、有用な浮動小数点演算数/秒（FLOPs/sec）を最大化する並列化戦略を選択することです。パイプライン並列化の実装はFSDPよりもはるかに複雑であるため、エンジニアはコードを書く前に両者のどちらを選ぶかを判断するための信頼できる方法を必要としています。著者らは、たとえ両方のシステムを構築したとしても、ベンチマークのエラーによって比較が無効になる可能性があると主張しています。

これを解決するために、彼らはRoofline分析という古典的な性能モデリング手法を適用しました。この手法では、必要な総FLOPsを固定値として扱い、システムが計算速度によって制限されているのか、それとも分散通信帯域幅によって制限されているのかを識別します。分析の結果、FSDPはInfiniBandの帯域幅にバウンドされるため、DeepSeek-V3には不適切な選択であることが明らかになりました。一方、他の戦略ではGPUを計算で稼働させ続けることができます。

仕組み

Roofline分析は、「光速」（SOL: Speed of Light）性能という概念に基づいています。これはハードウェアが達成できる厳密な上限を表します。物理学では光の速度を超えるものは存在せず、コンピューティングにおいてもソフトウェアは基盤となるシリコンの理論ピークを超えることはできません。しかし、マーケティング仕様のピーク値を使用することはしばしば誤解を招きます。NVIDIAが公表しているTFLOP/sの数値は、ゼロ初期化されたテンソルや完璧な命令スケジューリングなど、実際の行列乗算ではめったに発生しない理想的な条件を前提としています。

メモリ読み込み、キャッシュ階層のレイテンシ、電力制限などの要因により、実世界の性能は仕様書から乖離します。例えば、ゼロ以外のデータを処理すると電力キャップが発動してクロック速度が低下することがあり、つまり性能は入力データの値に依存します。これに対応するため、著者らはHuggingFaceのSmol Training Playbookからのマイクロベンチマークで測定された達成可能なFLOPsを使用しています。BF16精度の場合、H800は758 TFLOP/sを達成しており、これは理論ピーク値989 TFLOP/sの76.6%です。FP8の場合、1.46 PFLOP/sを達成しており、これはピーク値1.98 PFLOP/sの73.6%です。

ネットワーク帯域幅も同様に扱われます。InfiniBandの仕様では50 GB/sとされていますが、これはほぼ達成可能です。一方、H800におけるNVLinkの性能はH100よりも低くなります。DeepSeekは、H800 NVLinkで单向き帯域幅160 GB/sしか達成できなかったと報告しており、これは仕様書の200 GB/sを下回っています。分析ではこれらの測定値を使用して、通信と計算に費やす時間を計算します。

分散学習では、ボトルネックが高帯域幅メモリ（HBM）からノード間帯域幅へ移行します。学習ステップに必要な総FLOPsは、ピザをスライスしても全体のサイズが変わらないのと同様に、並列化に関係なく一定です。しかし、通信オーバーヘッドは劇的に変化します。もし通信時間が計算時間を超えると、システムは通信バウンドとなり、GPUはデータ待ちでアイドル状態になります。目標は、計算が通信よりも長くかかるようにし、トレーナーがこれらの操作をオーバーラップさせてレイテンシを隠蔽できるようにすることです。

主要な詳細

• ハードウェアターゲット: この分析は、NVIDIA H800 GPUの2048ノードクラスタに焦点を当てています。
• 達成可能な計算性能: 測定されたBF16性能は758 TFLOP/s（ピークの76.6%）、FP8は1.46 PFLOP/s（ピークの73.6%）です。
• ネットワーク制約: InfiniBand帯域幅はGPUあたり50 GB/sと仮定され、NVLinkはDeepSeekの報告に基づき160 GB/sに制限されています。
• 並列化の判定: FSDP（ZeRO-3）は、このモデルサイズではInfiniBand帯域幅にバウンドされるため却下されます。
• 方法論: このアプローチでは、FLOPsとバイト転送のための「光速」時間を計算し、ステップが計算バウンドなのか通信バウンドなのかを決定するために比較します。
• 簡略化: 明確さを保つため、Multi-Token Prediction（MTP）はこの特定の分析からは省略されています。

なぜ重要なのか

機械学習インフラチームにとって、この分析は莫大な先行投資なしに重要なアーキテクチャ決定を行うための厳格なフレームワークを提供します。数千個のGPUで複数の並列化戦略を構築・ベンチマークすることは、コストと時間の面で現実的ではありません。Roofline分析は、合理的な精度で性能ボトルネックを予測できるスプレッドシートベースの代替案を提供します。これにより、チームが複雑なパイプライン並列化セットアップなどの実装パスを追跡した後になって、単純なFSDPアプローチがネットワーク制限により失敗していたことに気づくのを防ぎます。

さらに、マーケティング仕様と達成可能な性能の区別は、正確な容量計画にとって極めて重要です。理論上のピーク値に頼ると、学習スループットを大幅に見積もりすぎてしまう可能性があります。測定されたマイクロベンチマークを使用することで、エンジニアは現実的なタイムラインと予算期待値を作成できます。これは、モデルが大きくなり精度が低下するにつれて特に重要になります。低精度は計算速度を加速しますが、通信量は減少しないため、帯域幅ボトルネックが悪化する可能性があるからです。

実行できること

• cuBLASなどのライブラリを使用して自社のハードウェアのGEMM性能をベンチマークし、仕様書に頼るのではなく達成可能なFLOP/sを決定してください。
• クラスタ環境で実際のNVLinkおよびInfiniBand帯域幅を測定してください。実世界のトポロジーや電力キャップによりスループットが低下する可能性があります。
• 実装前にRoofline分析を用いて並列化戦略を比較し、通信時間が計算時間を超えているかどうかを確認してください。
• モデル内で電力制限を考慮に入れてください。ゼロ以外のデータ入力が学習中にGPUクロック速度をスロットリングする可能性があることを認識してください。
• 可能な限り計算バウンドの設定を優先し、通信オーバーヘッドが計算とオーバーラップできることを確認してください。
• 精度レベルを変更する際は前提を見直してください。低精度は計算速度を向上させますが、ボトルネックをネットワーク帯域幅へシフトさせる可能性があります。