## 1. 序論：H100時代における効率性指標としてのMFUの再定義 大規模言語モデル（LLM）のパラメータ数が数千億から兆のオーダーへと爆発的に増加する中、学習インフラストラクチャの投資対効果を最大化することは、AI研究開発における最重要課題の一つとなっています。NVIDIA H100 Tensor Core GPUの登場は、Transformer Engineの導入やFP8精度のネイティブサポートにより、理論上の演算性能（Peak FLOPS）を劇的に向上させました。しかし、ハードウェアの理論性能と、実際の学習ワークロードで発揮される実効性能との間には乖離が存在します。この乖離を定量化し、システム全体の効率性を評価するための指標として、Model FLOPS Utilization（MFU）が広く採用されています。 本報告書は、NVIDIA H100を用いたLLMの分散学習において、MFUの値が明記されている文献、技術ブログ、およびベンチマーク結果を網羅的に調査・分析したものです。調査の結果、H100環境下でのMFUは、クラスタの規模、採用する並列化戦略、モデルアーキテクチャ（Dense vs MoE）、そして通信バックボーンの構成によって、**約20%から58%**という広範な値をとることが明らかになりました。特に、数万基規模のGPUを用いるハイパースケール環境と、数百基規模の最適化されたミッドスケール環境では、MFUの挙動に顕著な差異が見られます。本稿では、これらのデータを体系化し、H100のポテンシャルを最大限に引き出すための要因を技術的観点から深掘りします。 ## 2. 理論的枠組みとH100におけるMFUの特異性 ### 2.1 MFUの定義と算出における複雑性 MFU（Model FLOPS Utilization）は、実際の学習ステップにおいて処理されたトークン数とモデルのパラメータ数から算出される「有効演算量」を、ハードウェアの理論上のピーク性能で除した値です。これは、再計算（Activation Checkpointing）などのオーバーヘッドを含めたHardware FLOPS Utilization（HFU）とは異なり、純粋にモデルの学習に寄与した演算の割合を示します。 NVIDIA H100においてMFUを議論する際、最も注意すべき点は「分母」となる理論ピーク性能の定義です。H100は、従来のBF16/FP16演算に加え、FP8演算をサポートしています。文献1および2によれば、H100の理論ピーク性能は、BF16で約989 TFLOPS、FP8ではその2倍の約1,979 TFLOPSに達します（Sparsityを考慮した場合、さらに数値は変動します）。したがって、同じ「MFU 40%」という値であっても、それがBF16ベースで算出されたものか、FP8ベースで算出されたものかによって、実効スループット（Tokens/sec）には2倍の開きが生じます。本調査では、可能な限り文献が前提としている精度フォーマットを特定し、数値を文脈化して分析します。 ### 2.2 Hopperアーキテクチャがもたらすボトルネックの変化 H100（Hopperアーキテクチャ）は、A100（Ampere）と比較して演算性能が飛躍的に向上した一方で、メモリ帯域幅（HBM3）やインターコネクト帯域（NVLink/InfiniBand）の向上率は演算性能の向上率に追いついていない側面があります。これにより、LLM学習におけるボトルネックの所在が変化しています。Uberのエンジニアリングチームによる報告3では、Llama 2 70Bのファインチューニングにおいて、H100のMFUがA100よりも低くなるケースが観測されました。これは、H100の演算速度が速すぎてメモリ供給が追いつかず、Memory-Bound（メモリ帯域律速）な状態に陥りやすいためです。このように、H100におけるMFUの向上は、単なる計算能力の向上ではなく、いかにメモリ階層と通信遅延を隠蔽（Overlap）するかにかかっています。 ## 3. 規模別・組織別MFUベンチマーク詳細分析 調査した文献に基づき、H100を用いた分散学習におけるMFUの実測値を、クラスタ規模と実施組織別に分類し、詳細に分析します。 ### 3.1 ミッドスケール・高効率環境（128〜1,024 GPU） 数百基から千基程度のGPUクラスタにおいて、ハードウェアとソフトウェアの統合的な最適化が行われた場合、H100は50%を超える高いMFUを達成可能です。この規模では、通信レイテンシの影響を比較的低く抑えることができ、理想的なスケーリングに近い性能が観測されています。 #### 3.1.1 MosaicML (Databricks) と CoreWeaveによる最高水準の効率 MosaicML（現在はDatabricksの一部）とCoreWeaveによる共同検証は、H100の性能を最大限に引き出した事例として複数の文献で言及されています。彼らは、128基のH100 GPUを用いた30BパラメータのDenseモデル学習において、**51.9%**という極めて高いMFUを達成しました5。 この高い数値の背景には、複数の技術的要因が絡み合っています。まず、インフラストラクチャとしてCoreWeaveのベアメタルインスタンスが使用されており、仮想化ハイパーバイザーによるオーバーヘッドが排除されています5。ソフトウェア面では、MosaicMLのComposerフレームワークが採用されており、これにはFlashAttentionや低レベルのカーネル最適化が組み込まれています。さらに、FP8精度の導入により、BF16を使用するA100と比較して3倍の学習速度を実現しながらも、モデルの収束性には悪影響を与えないことが確認されています2。 文献5では、この51.9%という数値について、他の主要なAI研究所が報告している典型的な値（35〜45%）と比較して28%の改善であると強調しています。また、信頼性（Reliability）の観点からも、1,024 GPU規模で3.66日の平均故障間隔（MTTF）を達成しており、高いMFUを維持しながら安定した学習が可能であることを実証しています5。これは、単発のベンチマークではなく、実運用に耐えうる構成での数値として重要な意味を持ちます。 #### 3.1.2 NVIDIA Megatron-Coreによるベースライン性能 NVIDIA自身が開発するMegatron-Coreライブラリを用いたベンチマークでも、高いMFUが報告されています。文献7および7によると、20億から4620億パラメータのモデルを数千基のGPUで学習させた際、最大で**47%**のMFUを達成しています。 Megatron-Coreは、Tensor Parallelism (TP)、Pipeline Parallelism (PP)、Context Parallelism (CP)、Expert Parallelism (EP)といった多様な並列化戦略を組み合わせることで、通信と演算のオーバーラップを最大化しています。特に、H100においてはTransformer Engineとの統合が進んでおり、FP8演算を効率的に活用するための最適化が施されています。47%という数値は、特定のモデルアーキテクチャに過度に適応させた結果ではなく、汎用的なライブラリとしての性能指標であり、多くの企業が目標とすべきベースラインと言えます。 ### 3.2 ハイパースケール・プロダクション環境（10,000 GPU以上） GPU数が数万基に達するハイパースケール環境では、通信のオーバーヘッドが指数関数的に増大し、また故障発生率の上昇に伴うチェックポイント作成等のオーバーヘッドも無視できなくなります。そのため、MFUの値はミッドスケール環境と比較して低下する傾向にあります。 #### 3.2.1 Meta Llama 3 (16,000+ H100, BF16) MetaによるLlama 3の学習は、現時点で公開されている中で最大規模のH100クラスタ運用事例の一つです。文献8および8によると、約16,000基のH100を使用し、Llama 3（405Bモデル等）の学習において、BF16精度でGPUあたり約380〜430 TFLOPSのスループットを記録しました。これは、H100のBF16理論ピーク性能（約989 TFLOPS）に対して、**38%〜43%**のMFUに相当します。 この数値はMosaicMLの52%と比較すると低く見えますが、16,000基という圧倒的な規模を考慮すれば、驚異的な効率性と言えます。Metaは、この規模での学習を安定させるために、Mixture-of-Experts (MoE) ではなく、標準的なDense Transformerアーキテクチャを採用しました9。MoEは理論上の計算効率は高いものの、通信パターンが複雑であり、数万基規模での動的ルーティングに伴う通信ボトルネックやロードバランシングの課題が、MFUを著しく低下させるリスクがあるためです。Metaの事例は、極大スケールにおいては、理論的なアルゴリズム効率よりも、システム全体の安定性と通信の単純性を優先することで、結果的に高い実効MFU（約40%）を維持できることを示唆しています。 #### 3.2.2 Meta Llama 4世代とFP8の課題 (32,000+ H100) さらに規模を拡大した次世代モデル（Llama 4相当）の学習において、Metaは約32,000基のH100を使用し、FP8精度への移行を行っているとの報告があります。文献8の観測によると、FP8を用いた場合の実効スループットは約390 TFLOPSであり、これはFP8の理論ピーク性能（約1,979 TFLOPS）に対して、MFUは約**19.7%**にとどまります。 ここで重要なのは、MFUのパーセンテージが半減している一方で、絶対的なスループット（TFLOPS）はBF16時と同等以上を維持している点です。FP8への移行により演算器の能力は2倍になりましたが、メモリ帯域やネットワーク帯域は変わらないため、システムが完全に「通信・メモリ律速」の状態に陥っていることを示唆しています。文献8では、MoE（Mixture of Experts）アーキテクチャの採用がMFUを低下させる要因の一つであり、FP8の採用はその効率低下を補うための必然的な選択であった可能性が指摘されています。つまり、FP8における「MFU 20%」は、ハードウェアの演算能力を持て余している状態を示していますが、それでもBF16での学習と比較して同等以上の速度で、より大規模なモデルを扱えるという点で実用的価値があります。 ### 3.3 アカデミック・新規フレームワークによる最適化事例 標準的なMegatron-LMやDeepSpeedを超えて、特定のボトルネック解消に特化した新規フレームワークの研究においても、H100のMFUに関する重要なデータが得られています。 #### 3.3.1 Memoフレームワークによるメモリ管理の最適化 文献10および10で提案されているMemoフレームワークは、長文脈（Long Context）学習時におけるメモリ断片化と再計算のオーバーヘッド削減に焦点を当てています。同研究では、8基のA800 GPU（H100と同等のメモリ帯域を持つ構成も含む議論）において、7Bモデル（シーケンス長100万トークン）の学習で**52.30%**のMFUを達成しました。これは、同条件下のMegatron-LMやDeepSpeedと比較して約2.42倍の効率改善とされています。特に、アクティベーションをCPUメモリへオフロードし、その転送時間を演算時間で隠蔽するスケジューリング技術が、高いMFUの実現に寄与しています。 #### 3.3.2 DHelixによる通信と演算のインターリービング 文献11および11で紹介されているDHelixは、パイプライン並列化における「バブル（待機時間）」を削減するために、順伝播と逆伝播の計算をインターリーブ（交互配置）させる手法を提案しています。この手法により、H100クラスタにおいても通信コストの高いTensor Parallelismをノード間で適用することが現実的になり、従来手法と比較して**最大58%**のMFU向上が見込めると報告されています。ただし、H100の高速なネットワーク環境下では、DHelixによる改善幅はA100環境ほど劇的ではないとも記されています。 #### 3.3.3 Llama 3ベースMoEモデルの効率化 文献12および13の技術レポートでは、Llama 3アーキテクチャをベースとしたMoEモデル（8 Experts, Top-2）の事前学習において、**46.8%**のMFUを達成したと報告されています。通常、MoEモデルはスパースな計算特性によりMFUが低くなりがちですが、既存のDenseチェックポイントからのアップサイクル（Upcycling）技術と、NeMoフレームワーク上の最適化を組み合わせることで、Denseモデルに近い高い利用率を実現しています。 以下の表に、調査によって判明した主要なMFU値をまとめます。 | **組織・プロジェクト** | **GPU規模 (H100)** | **精度** | **モデル種別** | **達成MFU** | **出典** | | ---------------------------- | ---------------- | ---------- | -------------------- | ------------- | ------ | | **MosaicML / CoreWeave** | 128 | FP8/BF16混合 | Dense (30B) | **51.9%** | 5 | | **Memo (Academic)** | 8 (A800/H100) | 混合精度 | Dense (7B, Long Ctx) | **52.30%** | 10 | | **NVIDIA Megatron-Core** | 1,000+ | 混合精度 | Dense | **~47%** | 7 | | **Llama 3 MoE (Academic)** | 512 | 混合精度 | MoE (8B) | **46.8%** | 12 | | **Meta Llama 3** | ~16,384 | BF16 | Dense (405B) | **38% - 43%** | 8 | | **Meta Llama 4 (観測値)** | ~32,000 | FP8 | Dense/MoE | **~19.7%** | 8 | | **Uber (Llama 2 Fine-tune)** | 32 | BF16 | Dense (70B) | _A100より低下_ | 3 | ## 4. H100におけるMFU変動要因の深層分析 H100環境下でMFUが大きく変動する背景には、ハードウェアの物理的特性とソフトウェアの相互作用による複雑な要因が存在します。ここでは、文献から得られた知見を基に、そのメカニズムを解明します。 ### 4.1 精度フォーマットとArithmetic Intensity（演算強度）の相関 H100におけるMFUの解釈を最も難しくしているのが、FP8の存在です。FP8を利用すると、GPUの演算器（Tensor Core）はBF16の2倍のデータを処理できますが、データをGPUメモリ（HBM3）から演算器へ運ぶための帯域幅は2倍にはなりません。 Uberの事例3は、この「演算性能とメモリ帯域の不均衡」を如実に示しています。彼らがLlama 2 70Bをファインチューニングした際、バッチサイズが十分に大きくない設定では、H100の演算器が瞬時に計算を終えてしまい、次のデータ転送を待つアイドル時間が発生しました。その結果、絶対的な処理時間はA100より速いものの、稼働率（MFU）としてはA100を下回るという現象が起きました。これを解決するためには、CPUオフローディングやFlashAttentionを活用してGPUメモリを節約し、バッチサイズを限界まで引き上げてArithmetic Intensity（メモリ転送量あたりの演算回数）を高める必要がありました。 ### 4.2 インターコネクト・トポロジーと通信の隠蔽 数千基規模の分散学習において、MFUを維持するためには、GPU間の通信時間を演算時間で隠蔽（Overlap）することが不可欠です。 - **ノード内通信（NVLink）:** H100 SXM5システムでは、ノード内の8基のGPUはNVLinkによって全結合され、900GB/sという極めて広帯域な通信が可能です。MosaicMLの52%という高いMFU6は、このノード内帯域を最大限に活かし、通信ボトルネックをほぼ解消できていることを示唆しています。 - **ノード間通信（InfiniBand vs Ethernet）:** MetaのLlama 3学習クラスタ9や、Microsoft AzureのH100クラスタ15では、NVIDIA Quantum-2 InfiniBand（400Gbps/800Gbps）が採用されています。一方、AWSのP5インスタンス16では、EFA（Elastic Fabric Adapter）を用いた3,200 GbpsのEthernetベースのネットワーキングが採用されています。文献6によると、CoreWeaveはトポロジーアウェアなスケジューリングを行うことで、InfiniBandファブリックの性能を完全に引き出し、ノード間通信によるMFU低下を防いでいます。 - **通信の隠蔽技術:** Megatron-CoreやDeepspeedなどのフレームワークは、Backward Pass（勾配計算）を行っている最中に、すでに計算が終わったレイヤーの勾配を隣のGPUに送信する「Communication Overlap」を実装しています。しかし、モデルサイズが巨大化し、Tensor Parallelism（TP）の度合いが高まると、各GPUが持つデータの断片が小さくなり、通信頻度が増加します。MetaがLlama 3でMoEを避けた理由の一つも、MoE特有のAll-to-All通信が、この隠蔽メカニズムを破綻させ、MFUを低下させることを懸念したためと考えられます。 ### 4.3 ソフトウェアスタックの影響 同じH100ハードウェアを使用していても、採用するソフトウェアスタックによってMFUには大きな差が生じます。 - **MosaicML Composer:** 文献2や2で強調されているように、ComposerはFlashAttentionやFP8学習を「箱から出してすぐに（Right out of the box）」使える形で最適化しており、ユーザーが複雑なカーネルチューニングを行わなくても高いMFU（~52%）を出せるように設計されています。 - **DeepSpeed:** MicrosoftのDeepSpeedは汎用性が高い反面、特定のハードウェア構成に特化した最適化を行うにはチューニングが必要です。文献10の比較では、MemoフレームワークがDeepSpeedよりも高いMFUを記録しており、標準設定のDeepSpeedではメモリ管理や通信スケジュールに改善の余地があることが示唆されています。しかし、DeepSpeedも進化を続けており、文献17等ではZeRO最適化による大規模モデルへの対応力が強調されています。 ## 5. 結論と今後の展望 本調査により、NVIDIA H100を用いた分散学習におけるMFUは、単一の固定値ではなく、システム全体の設計品質を表す動的な指標であることが確認されました。 1. **実用的な目標値:** 適切に構築された数百〜千基規模のH100クラスタにおいて、BF16/FP8混合精度学習を行う場合、**50%前後のMFU**は達成可能な目標値です。これは、MosaicMLやCoreWeaveの事例が証明しています。 2. **スケールの代償:** 1万基を超えるハイパースケール環境では、通信と同期のコストにより、MFUは**40%前後**（BF16時）に収束します。これはシステム設計の失敗ではなく、物理的な制約とのトレードオフの結果です。 3. **FP8のパラドックス:** 次世代の学習（Llama 4等）で主流となるFP8全導入環境では、理論ピーク性能の倍増に伴い、MFUの数値自体は**20%程度**まで低下する可能性があります。しかし、これは「利用率が悪い」のではなく、「ハードウェアの進化（演算速度）にメモリ・通信が追いついていない」ことを示しており、絶対的な学習時間は短縮されます。 今後、NVIDIA Blackwell（B200）などの次世代GPUが登場し、FP4などのさらに低い精度が導入されると、この「低MFU・高スループット」の傾向はさらに加速すると予想されます。研究者やエンジニアは、単にMFUのパーセンテージを追うのではなく、採用している精度やモデルアーキテクチャを考慮した上で、その数値がシステムの限界性能に対して妥当な水準にあるかを判断する必要があります。 --- 引用文献: 本報告書におけるデータおよび主張は、以下の資料に基づいています。 7 (NVIDIA公式ベンチマークおよび技術ブログ) 2 (MosaicML/DatabricksおよびCoreWeaveによる検証レポート) 8 (Meta Llama 3/4に関する技術的観測と論文) 3 (Uber Engineering BlogによるH100評価) 10 (Memo, DHelix, MegaScale等のアカデミック論文) 6 (クラウドプロバイダー各社のインフラ仕様)