実務でよく使われる MFU（Model FLOPs Utilization）の近似計算式は、**「モデル 1 トークンあたりの FLOPs × 実測トークンスループット ÷ GPU の理論ピーク FLOPs」** という形になります。
## 1. MFU の定義と基本式
Google が PaLM／TPU v4 系の論文・技術資料で導入している定義は、
> **MFU = 実際にモデルで使われた FLOPs/s ÷ ハードウェアの理論ピーク FLOPs/s**
という形です。([services.google.com](https://services.google.com/fh/files/blogs/tpu_v4_benchmarking.pdf?utm_source=chatgpt.com "TPU v4 Benchmarking"))
もう少し実務で使いやすい形にすると：
$
[
\boxed{
\mathrm{MFU} \approx
\frac{\text{1 トークンあたりのモデル FLOPs} \times \text{トークン毎秒}}
{\text{GPU（またはクラスタ）の理論ピーク FLOPs}}
}
]
$
記号で書くと：
- ($C_{\text{tok}}$)：モデル 1 トークンあたりの FLOPs（forward+backward）
- ($R_{\text{tok}}$)：実測トークンスループット [tokens/s]
- ($P_{\text{peak}}$)：ハードウェアの理論ピーク FLOPs [FLOPs/s]
として、
$
[
\mathrm{MFU} \approx \frac{C_{\text{tok}} \cdot R_{\text{tok}}}{P_{\text{peak}}}
]
$
となります。
この「**観測されたスループット ÷ 理論的最大スループット**」という定義は、
- Google の TPU v4 ベンチマーク資料（PaLM を例に MFU を定義）([services.google.com](https://services.google.com/fh/files/blogs/tpu_v4_benchmarking.pdf?utm_source=chatgpt.com "TPU v4 Benchmarking"))
- 変換器推論の高速化論文「Efficiently Scaling Transformer Inference」([arXiv](https://arxiv.org/pdf/2211.05102?utm_source=chatgpt.com "EFFICIENTLY SCALING TRANSFORMER INFERENCE ..."))
などの技術文献で明示的に説明されています。
## 2. Transformer 学習における FLOPs 近似
Dense Transformer（GPT 系）の学習では、**1 トークンあたりの FLOPs はおおよそ「6 × パラメータ数」**という経験式が広く使われています。
JAX ML の scaling-book などで、以下のように説明されています：
- forward で約 (2N) FLOPs
- backward で約 (4N) FLOPs
- 合計 (6N) FLOPs / token
$
[
\Rightarrow\ C_{\text{tok}} \approx 6N
]
$
ここで (N) はモデルのパラメータ数です。([jax-ml.github.io](https://jax-ml.github.io/scaling-book/transformers/?utm_source=chatgpt.com "All the Transformer Math You Need to Know | How To Scale ..."))
より厳密な式は、Narayanan et al.（Megatron-LM 論文）で与えられています。Transformer 言語モデルの 1 イテレーションあたり FLOPs を
- バッチサイズ (B)
- シーケンス長 (s)
- Transformer 層数 (l)
- hidden size (h)
- vocabulary size (V)
とすると、
$
[
F_{\text{iter}} = 96 B s l h^2 \left(1 + \frac{s}{6h} + \frac{V}{16 l h}\right)
]
$
と近似できます。
このとき、1 イテレーションあたりのトークン数は (B s) なので、
$
[
C_{\text{tok}} = \frac{F_{\text{iter}}}{B s}
\approx 96 l h^2 \left(1 + \frac{s}{6h} + \frac{V}{16 l h}\right)
]
$
通常の設定（(s \ll 6h), (V \ll 16 l h)）では括弧内はだいたい 1 に近く、
Transformer のパラメータ数 (N \approx 12 l h^2) を使えば、
$
[
C_{\text{tok}} \approx 96 l h^2 \approx 8 N
]
$
程度となり、桁の近い「6N ルール」と整合的です（導出の前提の違いで係数は多少変わります）。
## 3. 実務でよく使う MFU の近似式
実際に現場で一番よく使われるのは、次のような単純な式です（PaLM を解説した資料や Llama3 関連の解説でもこの形で紹介されています）。([Zenn](https://zenn.dev/nariaki3551/scraps/6221fb5a306064?utm_source=chatgpt.com "Llama3におけるバッチサイズの設定について - Zenn"))
### (1) トークン毎秒から求める形
- モデルパラメータ数：(N)
- 実測トークンスループット：(R_{\text{tok}}) [tokens/s]
- GPU（またはクラスタ）のピーク性能：(P_{\text{peak}}) [FLOPs/s]
とすると、
$
[
\boxed{
\mathrm{MFU} \approx
\frac{6 N \cdot R_{\text{tok}}}{P_{\text{peak}}}
}
]
$
※ 6 の係数は「Transformer 学習では 1 トークンあたりだいたい (6N) FLOPs」という近似に基づきます。([jax-ml.github.io](https://jax-ml.github.io/scaling-book/transformers/?utm_source=chatgpt.com "All the Transformer Math You Need to Know | How To Scale ..."))
### (2) ステップ時間とバッチから求める形
- バッチサイズ（シーケンス数）：(B)
- シーケンス長：(s)
- 1 イテレーションの所要時間：(t_{\text{iter}}) [s/iter]
とすると、1 秒あたりのトークン数は
$
[
R_{\text{tok}} = \frac{B \cdot s}{t_{\text{iter}}}
]
$
なので、
$
[
\mathrm{MFU} \approx
\frac{6 N \cdot B \cdot s}{t_{\text{iter}} \cdot P_{\text{peak}}}
]
$
この式は、Google/DeepMind 系の FLOPs 計算（総学習計算量 ($C \approx 6ND$)）や Narayanan et al. の詳細な FLOPs 式と整合的な近似として、各種ブログ・技術解説・研究でも使われています。([Adam Casson](https://www.adamcasson.com/posts/transformer-flops?utm_source=chatgpt.com "Transformer FLOPs - Adam Casson"))
## 4. この定義・式が書かれている「権威ある」文献例
MFU とその考え方／式が記載されている代表的な文献を挙げておきます：
1. **Aakanksha Chowdhery et al., “PaLM: Scaling Language Modeling with Pathways,” JMLR, 2024.**
- PaLM 540B のトレーニングで MFU を指標として導入し、MFU の値をテーブルで報告しています。([jmlr.org](https://jmlr.org/papers/volume24/22-1144/22-1144.pdf?utm_source=chatgpt.com "PaLM: Scaling Language Modeling with Pathways"))
2. **Google, “TPU v4 Benchmarking” whitepaper.**
- 「PaLM 論文で導入した Model FLOPs Utilization (MFU)」として、
「**観測されたスループット（例：tokens/s）を、ピーク FLOPs で 100% 動作したときの理論最大スループットで割ったもの**」と定義しています。([services.google.com](https://services.google.com/fh/files/blogs/tpu_v4_benchmarking.pdf?utm_source=chatgpt.com "TPU v4 Benchmarking"))
3. **“Efficiently Scaling Transformer Inference for Large Language Models” (arXiv:2211.05102)**
- 推論ですが定義は同じで、
「MFU は観測スループットを、ピーク FLOPs で動いた場合の理論最大スループットで割ったもの」と明記。([arXiv](https://arxiv.org/pdf/2211.05102?utm_source=chatgpt.com "EFFICIENTLY SCALING TRANSFORMER INFERENCE ..."))
4. **Deepak Narayanan et al., “Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM,” 2021.** [[2021__SC21__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM|Narayanan+, SC212021]]
- 「MFU」という名前こそ使っていませんが、
- Transformer 学習 1 イテレーションあたり FLOPs を
- $
[
F_{\text{iter}} = 96 B s l h^2 \left(1 + \frac{s}{6h} + \frac{V}{16 l h}\right)
] $
と明示的に導出し、
- 「実効 TFLOP/s」および「理論ピークに対するパーセンテージ」を報告しており、実質的に MFU を計算しています。
5. **NVIDIA NeMo Framework Performance Guide（公式ドキュメント）**
- 学習性能チューニングの指標として、明示的に MFU（Model FLOPs Utilization）を使っていることを記載しています。([NVIDIA Docs](https://docs.nvidia.com/nemo-framework/user-guide/latest/performance/performance-guide.html?utm_source=chatgpt.com "Performance Tuning Guide — NVIDIA NeMo Framework User ..."))
## 5. まとめ（実務用の一行）
H100 などで自分のジョブの MFU をざっくり出したい場合は、次の式を使うと計算しやすいです：
$
[
\boxed{
\mathrm{MFU} \approx
\frac{6 \times N_{\text{params}} \times \text{tokens/sec}}{\text{GPU（群）の理論ピーク FLOPs}}
}
]
$
- tokens/sec は **実測**（ログから計算）
- 理論ピーク FLOPs は GPU データシートに記載の値（FP8/FP16 など、使っている精度に合わせる）
---
1. **定義:**
* モデルの計算（主に浮動小数点演算）において、**ハードウェアが持つ理論上のピーク演算性能に対して、実際に達成された演算性能の割合** を示す指標です。
* **FLOPs (Floating-point Operations Per Second)** は、1秒あたりに実行できる浮動小数点演算の回数です。LLMの学習では主に `matmul` (行列積) 演算が計算量の大部分を占めます。
* MFUは、GPUなどの計算リソースをどれだけ効率的に「計算」のために使えているかを示します。
2. **計算方法:**
* 一般的には以下の式で計算されます。
```
MFU (%) = (達成された FLOPs / 理論上のピーク FLOPs) * 100
```
または、ステップ時間を使って以下のように計算することも多いです。
```
達成された TFLOPS = (1ステップあたりのモデル計算FLOPs) / ステップ時間 / 10^12
MFU (%) = (達成された TFLOPS / ハードウェアの理論ピーク TFLOPS) * 100
```
* **1ステップあたりのモデル計算FLOPs:**
* これはモデルアーキテクチャ、バッチサイズ、シーケンス長から理論的に計算されます。
* Transformerモデルの場合、主な計算量はAttention層とFFN層の `matmul` にあり、パラメータ数 `N` 、バッチサイズ `B` 、シーケンス長 `S` を用いて概算できます。
* フォワードパスとバックワードパス（勾配計算）の両方を考慮する必要があります。一般的に、バックワードパスはフォワードパスの約2倍の計算量とされます。したがって、モデルのフォワードパスのFLOPsを `F` とすると、1ステップのモデル計算FLOPsは `B * S * (F_{fwd} + F_{bwd}) ≈ B * S * 3 * F_{fwd}` と近似されることがあります。より正確には、 `F_{fwd}` と `F_{bwd}` をモデル構造から精密に計算します。よく使われる近似式として、パラメータ数を `N` として `6 * N * B * S` や `8 * N * B * S` などがあります（係数はモデル構造や計算方法の仮定に依存）。
* 論文 [PaLM](https://arxiv.org/abs/2204.02311) や [Megatron-LM](https://arxiv.org/abs/1909.08053) などで詳細な計算方法が議論されています。
* **ハードウェアの理論ピーク TFLOPS:**
* 使用しているGPU（例: NVIDIA A100, H100）のデータシートに記載されている、特定の数値精度（例: FP16 Tensor Core, BF16 Tensor Core）における理論上の最大演算性能（TFLOPS = 10^12 FLOPs/sec）。
* 分散学習の場合は、使用している全GPUの理論ピークTFLOPSの合計値を使います。
3. **意味・重要性:**
* **計算効率の指標:** GPUなどの高価な計算リソースを、モデルの学習計算のためにどれだけ有効活用できているかを示します。
* **ボトルネックの特定:** MFUが低い場合、計算以外の要因（メモリ帯域律速、通信律速、ソフトウェアオーバーヘッドなど）がボトルネックになっている可能性を示唆します。
* **ソフトウェアスタックの評価:** 使用しているフレームワーク（PyTorch, TensorFlow）、ライブラリ（Megatron-LM, DeepSpeed）、カーネル実装などの効率性を評価するのに役立ちます。
4. **影響要因:**
* **カーネル実装の効率:** 特に `matmul` などの主要演算カーネルが、ハードウェア（例: Tensor Core）を最大限活用できるように最適化されているか。
* **メモリ帯域幅:** 計算に必要なデータをGPUメモリから計算ユニットへ、または計算結果をメモリへ書き戻す速度が十分か。メモリ律速の場合、計算ユニットがデータ待ちでアイドル状態になり、MFUが低下します。
* **通信オーバーヘッド:** 分散学習におけるノード間の通信（勾配同期など）が計算時間を妨げている場合、MFUが低下します（特に計算と通信のオーバーラップが不十分な場合）。
* **バッチサイズとシーケンス長:** これらが小さすぎると、GPUの計算ユニットを飽和させられず、MFUが低くなる傾向があります（Arithmetic Intensityが低い状態）。
* **数値精度:** FP32よりもFP16やBF16の方が理論ピーク性能が高いため、同じ達成FLOPsでもMFUの計算上の分母が変わります。また、混合精度計算の実装効率も影響します。
* **モデルアーキテクチャ:** 計算量に対するメモリアクセス量の比率（Arithmetic Intensity）が低いモデル構造は、MFUが上がりにくい傾向があります。
5. **HFU (Hardware FLOPs Utilization) との違い:**
* 文脈によりますが、MFUは特に「モデルの学習計算に使われたFLOPs」に焦点を当てる場合に使われます。
* HFUは、より広く「ハードウェア全体で達成されたFLOPs」（モデル計算以外のオーバーヘッドも含む可能性）として使われることがあります。
* 実用上は、MFUとHFUはほぼ同義で、**ハードウェアの理論ピーク性能に対する実効性能の割合** として使われることが多いです。重要なのは、どの理論ピーク性能（例：FP16 Tensor Core）を基準にしているかを明確にすることです。
6. **目標値:**
* 最新のGPU（A100, H100など）と最適化されたソフトウェアスタックを用いたLLM学習では、**MFU 50%以上** が一つの目安とされることが多いです。非常に高度に最適化されたシステムでは、60%や70%を超えることも報告されています。
* ただし、モデルサイズ、バッチサイズ、ハードウェア、並列化戦略などによって達成可能なMFUは大きく異なります。
7. **利点と欠点:**
* **利点:**
* 計算リソースの利用効率を直接的に評価できる。
* ボトルネックが計算にあるのか、それ以外（メモリ、通信など）にあるのかを判断する手がかりになる。
* ソフトウェアや実装の最適化度合いを測るのに有効。
* **欠点:**
* **計算が複雑:** 1ステップあたりのモデル計算FLOPsを正確に見積もるのが難しい場合がある。モデル構造やフレームワークの実装に依存する。
* **MFUが高くてもTPSが低い場合がある:** 例えば、非常に小さいバッチサイズでMFUが高くても、ステップ時間が長くなり、結果的にTPSは低くなる可能性がある。
* **通信性能を直接反映しない:** MFUは主に計算効率を見る指標であり、通信が非常に非効率でも計算部分だけ見るとMFUが高い、という状況もあり得る（ただし、通常は通信待ちで計算が止まるとMFUも下がる）。
---
[Nemo Megatron (DGXC Benchmarking) \| NVIDIA NGC](https://catalog.ngc.nvidia.com/orgs/nvidia/teams/dgxc-benchmarking/resources/nemo-megatron-dgxc-benchmarking)
> MFU = (global batch size) * (model flops) / (training step time) / (number of GPUs) / (peak GPU FLOPS)
The peak theoretical throughput for H100 FP8 is 1979 TFLOPS and for H100 BF16 is 989 TFLOPS.
```
model flops = (sequence length) * ((attention flops) + (mlp flops) + (embedding flops))
model flops breakdown:
attention flops = (24 * (number of layers) * (hidden size)^2) + (12 * (number of layers) * (hidden size) * (sequence length))
mlp flops = 48 * (number of layers) * (hidden size)^2
embedding flops = 6 * (vocab size) * (hidden size)
GPT 3 175b calculation:
sequence length = 2048
attention flops = 24 * 96 * 12288^2 + 12 * 96 * 12288 * 4096 = 376,883,380,224
mlp flops = 48 * 96 * 12288^2 = 695,784,701,952
embedding flops = 6 * 51200 * 12288 = 3,774,873,600
model flops = 2048 * (376,883,380,224 + 695,784,701,952 + 3,774,873,600) = 2.20E+15
```