LLM の性能は prefill と decode で決まり方が違う

LLM の推論速度を考えるとき、単に「GPU が速い」「量子化したから速い」「行列積が多い」と見るだけでは十分ではありません。入力 prompt をまとめて処理する prefill と、1 token ずつ生成する decode では、同じモデルを動かしていても性能の決まり方が異なるためです。

ローカル LLM の実用条件を整理した際にも、モデルがメモリへ載ることと、実際に十分な速度で動くことは別の問題として扱いました[1]。量子化についても、保存量、通信量、演算量、誤差は一つの指標ではありません[2]。量子化モデルの実測では、ファイル容量、実行時メモリ、prompt processing、token generation を分けて確認する必要があります[3]。

この違いを整理すると、LLM の推論性能は次のように考えられます。

• prefill は複数 token をまとめて処理するため、大きな行列積になりやすく、演算性能の影響を受けやすい
• decode は通常 1 token ずつ進むため、行列ベクトル積に近づき、重みの読み出しに必要なメモリ帯域の影響を受けやすい
• TTFT と token generation rate は、同じ「速さ」でも異なる処理を測っている
• 低 bit 化でデータ量が減っても、その形式をハードウェアが直接高速に演算できるとは限らない
• ベンチマーク値はモデル、prompt 長、batch size、GPU、SLO などの条件とセットで読む必要がある

以下では、この整理を順に確認します。

prefill と decode では計算の形が違う

Transformer の線形層では、重み行列に入力を掛ける処理が繰り返されます。

prefill では、入力 prompt に含まれる複数 token をまとめて処理できます。このため、いったん読み込んだ重みを多数の token に対して再利用でき、大きな行列同士の積として計算しやすくなります。

一方、decode では通常、次の 1 token を生成するたびに同じ重みを順次読みます。行列の一方の次元が小さくなり、行列ベクトル積に近い性質になります。

この違いは Apple の M5 に関する一次情報でも確認できます。Apple は M5 の GPU Neural Accelerators が専用の行列積演算を提供すると説明しています。また、4096 token の prompt を使った MLX の比較では、Qwen3-14B 4bit の TTFT は M4 比 4.06 倍、後続 token の生成速度は 1.19 倍でした[4]。

Apple 自身も、この測定について最初の token の生成は演算性能に制約され、後続 token の生成はメモリ帯域に制約されると説明しています[4]。

同じモデル、同じ GPU 世代差でも、TTFT と token generation で改善率が大きく違うのは、処理の性質が同じではないためです。

Roofline で演算性能とメモリ帯域を分ける

この違いを整理する方法の一つが Roofline モデルです。

Roofline では、横軸に arithmetic intensity を取ります。これは、データを 1 byte 移動する間にどれだけ演算するかを表す指標です。性能上限は、ピーク演算性能と、メモリ帯域に arithmetic intensity を掛けた値の小さい方で決まります[5]。

P = \min(P_{\mathrm{peak}}, B_{\mathrm{mem}} \times I)

I が小さい左側では、演算器を使い切る前にデータ供給が追いつかなくなります。この領域ではメモリ帯域の影響が大きくなります。

I が大きい右側では、同じデータに対して多くの演算を行えるため、やがてピーク演算性能が上限になります。

整理すると次のようになります。

Roofline 上の位置	Arithmetic intensity	主な制約
左側	低い	メモリ帯域
右側	高い	演算性能

prefill では重みを読み込んだあと複数 token に対して計算できるため、arithmetic intensity を高めやすくなります。decode では 1 token を生成するために大きな重みを読む割合が高く、arithmetic intensity を上げにくくなります。

ただし、prefill が常に演算性能で決まり、decode が常にメモリ帯域で決まるわけではありません。モデル、系列長、batch size、量子化形式、GPU の演算性能とメモリ帯域の組み合わせによって境界は変わります。

TTFT と token generation rate は同じ速度ではない

LLM の体感速度を評価するとき、TTFT と token generation rate は分けて見る必要があります。

TTFT は request を送ってから最初の token が返るまでの時間です。長い prompt をローカルで処理する場合、prefill が大きな割合を占めやすくなります。

一方、最初の token が出た後の生成速度は、decode を繰り返す速さです。この段階では、重みを何度も読みながら 1 token ずつ生成するため、メモリ帯域の影響が大きくなりやすくなります。

Apple の M5 で TTFT が 4.06 倍、後続 token の生成が 1.19 倍という差は、この区別を具体的に示しています[4]。

ただし、TTFT は prefill そのものと同義ではありません。実装やサービス構成によっては、tokenization、queueing、scheduler、通信、最初の token を返すまでの追加処理も含まれます。

そのため、

TTFT = prefill

と置くのではなく、

長い prompt のローカル推論では、TTFT の主要部分を prefill が占めやすい

と理解する方が安全です。

ベンチマーク値は条件とセットで読む

LLM の性能記事では、「何倍」という数字だけが目立つことがあります。しかし、その数字が正しくても、適用範囲まで同じとは限りません。

prefill と decode を別 GPU に分離する DistServe は、最大 7.4 倍高い request rate、または最大 12.6 倍厳しい SLO を達成したと報告しています[6]。

ここで確認すべきなのは、論文に 7.4 倍という数値が存在するかだけではありません。

特定の実験条件で最大 7.4 倍

と、

prefill と decode を分離すれば 7.4 倍

は別の主張です。

モデル、入力、SLO、GPU 構成などが変われば結果も変わります。論文の up to の数値を使う場合は、最大値であることと測定条件を残す必要があります。

FlashAttention-3 についても同じです。原論文では H100 上の FP16 順伝播で最大 740 TFLOPS、理論ピークに対する利用率 75%、FlashAttention-2 比 1.5〜2.0 倍という結果が報告されています[7]。

この数値は正しい一方、「FlashAttention-3 は常に 1.5〜2.0 倍速い」と読み替えることはできません。測定条件を維持したまま原論文へ戻る必要があります。

低 bit 化と演算速度は別々に確認する

量子化では、bit 数を下げれば重みの保存量を減らせます。しかし、それだけで実際の推論速度が同じ割合で向上するとは限りません。

量子化で確認すべきものは少なくとも分かれています。

重みを少ない bit 数で保存できる
    ↓
読み出すデータ量を減らせる
    ↓
その量子化形式を演算器が直接処理できるか
    ↓
変換処理や復号処理が必要か
    ↓
実際のワークロードで制約が変わるか
    ↓
実測でどれだけ速くなるか

量子化モデルを選ぶときも、理論上の重み容量だけでは足りません。実行時メモリや実測速度まで確認する必要があります[1]。実際の比較では prompt processing と token generation を分けて測ることで、低 bit 化がどの部分へ効いているかを確認できます[3]。

したがって、「4 bit だから速い」とも、「量子化は容量削減だけ」とも一括して結論することはできません。

LLM の性能を読むときの判断基準

ここまでを、技術記事やベンチマークを読むときの確認手順にまとめます。

1. prefill と decode を分けます。
2. TTFT と後続 token の生成速度を分けます。
3. 演算性能とメモリ帯域のどちらが制約になっているかを確認します。
4. 量子化形式と、ハードウェアが実際に実行できる演算形式を分けます。
5. ベンチマーク値ではモデル、prompt 長、batch size、GPU、SLO を確認します。
6. up to の最大値を一般性能へ置き換えません。
7. 現在確認できる仕様と、そこから導いた将来予測を分けます。

LLM の「速さ」を一つの数字として見ると、これらの差が隠れます。prefill と decode を分けるだけでも、なぜ同じハードウェアで TTFT だけ大きく改善するのか、なぜ低 bit 化しても生成速度が比例して上がらないことがあるのかを説明しやすくなります。

この整理から他の記事を確認する

ここまでの整理を使うと、LLM の性能について書かれた他の記事も、記事全体を「正しい」「間違い」の二択にせず確認できます。

例として、Qiita の「LLMの計算はほぼ全部 GEMM (General Matrix Multiply) である」[8] を見ます。

この記事は Transformer 推論、prefill と decode、Roofline、低精度演算、Apple M5、DistServe、FlashAttention-3 まで広く扱っています。

中心となる説明は、ここまで整理した内容とおおむね一致しています。一方、細部には定義や計算から修正できる箇所と、成立条件を補った方がよい記述があります。

対象記事の中心部分は妥当

対象記事では、Transformer の線形層や attention を行列積として整理し、prefill と decode で行列の形が変わることを説明しています[8]。

この整理は、Apple の M5/MLX の説明とも一致します。

• prefill は大きな行列積になりやすい
• decode は行列ベクトル積に近づく
• prefill は演算性能の影響を受けやすい
• decode はメモリ帯域の影響を受けやすい

したがって、記事の中心的な性能説明を否定する必要はありません。

FlashAttention-3 について記載されている、H100 上の FP16 順伝播で最大 740 TFLOPS、75% utilization、FlashAttention-2 比 1.5〜2.0 倍という値も原論文と一致しています[7]。

DistServe の最大 7.4 倍、最大 12.6 倍という値も原論文に対応しています[6]。対象記事は「最大」として紹介しており、この数値の扱いは適切です。

Roofline の左右は逆になっている

対象記事には、prefill について次の記述があります[8]。

演算強度(FLOP/byte)が高くなり、rooflineの左側(compute-bound)に入ります。

ここは左右が逆です。

Roofline では arithmetic intensity が低い側が左、高い側が右です。左側ではメモリ帯域による制約が強く、右側ではピーク演算性能による制約が強くなります[5]。

したがって、

左側 = memory-bound
右側 = compute-bound

です。

対象記事自身も、その直後では 512 token の例を高い arithmetic intensity として扱い、compute-bound へ移ると説明しています[8]。後続の論旨は Roofline の通常の読み方と一致しているため、概念全体の取り違えではなく、「左右」の書き違いと考えるのが自然です。

4608 は signed 13 bit には収まらない

対象記事は MXFP4 の教材用演算器について、32 項の加算結果 SoP4 の最大絶対値を 4608 と計算し、表ではデータ幅を signed 14bit としています[8]。

この表は整合しています。

一方、その直後には「SoP4 の最大絶対値 4608 は 13bit に収まり」とあります[8]。

signed 13 bit の 2 の補数表現で扱える範囲は次です。

-4096 ... 4095

4608 はこの範囲を超えるため、正負を含む SoP4 を保持するには signed 14 bit が必要です。

4608 という正の絶対値だけなら 13 bit で表せますが、符号付きデータ幅としては 14 bit です。対象記事の表と本文で記述が食い違っており、表側の signed 14bit が正しいことになります。

「全部が 0.5 刻み」は「0.5 の整数倍」が正確

同じ MXFP4 の説明では、E2M1 で表せる大きさとして次の値が挙げられています[8]。

0, 0.5, 1, 1.5, 2, 3, 4, 6

続けて「全部が 0.5 刻み」としていますが、隣接する値の間隔は一定ではありません。2 から 3、3 から 4 は 1、4 から 6 は 2 です。

ここで必要な性質は「すべて 0.5 の整数倍である」です。

各値を 2 倍すれば整数になるため、ブロック内で整数演算へ変換できるという後続の説明は成立します。

この箇所は計算そのものの誤りではなく、表現を正確にすれば済むものです。

「TTFT はほぼ全部 prefill」は条件を付けた方がよい

対象記事では TTFT について、「ほぼこの prefill の時間で決まる」「Enter を押してからカーソルが点滅している時間はほぼ全部 prefill」と説明しています[8]。

ローカルで 1 request を処理し、長い prompt を与え、queueing やネットワークなどの時間が小さい条件では、実用上の近似として理解できます。

ただし TTFT は prefill そのものと同義ではありません。

実装やサービス構成によっては、tokenization、request の待ち時間、scheduler、通信、最初の token を返すまでの追加処理などが含まれます。prompt が短ければ prefill の割合も小さくなります。

Apple の M5 の計測も、4096 token の prompt、M4 と M5 の MacBook Pro、MLX という条件を固定しています[4]。

したがって、

長い prompt のローカル推論では、TTFT の主要部分を prefill が占めやすい

程度まで条件を残す方が正確です。

これは明確な誤りというより、成立する範囲より広く述べた表現として扱うのが適切です。

M5 の事実と将来の M7 の予測は分ける

対象記事は Apple M5 の Neural Accelerator を根拠の一つとして、将来の M7 Max ではネイティブな MXFP4 積和が重要になるという見通しを述べています[8]。

M5 については確認できる事実があります。

Apple は M5 の GPU Neural Accelerators が専用の行列積演算を提供すると明記しています[4]。また、MLX の実測では TTFT の改善が後続 token の生成速度より大きくなっています[4]。

そこから、将来の Mac で低精度行列積の性能がさらに重要になると予測することはできます。

一方、

M7 Max がネイティブ MXFP4 演算器を搭載する

ことは、現在確認された仕様ではありません。

対象記事自身も M7 に関する部分を仮説として位置づけています[8]。したがって、この部分は「誤り」でも「確認済みの事実」でもなく、現在の仕様を根拠にした将来予測として読むのが適切です。

対象記事の確認結果

対象記事の主要な主張を、ここまでの基準で整理すると次のようになります。

主張	判定	確認方法
prefill は演算性能の影響を受けやすい	妥当	Apple の M5/MLX 実測と説明を確認
decode はメモリ帯域の影響を受けやすい	妥当	Apple の後続 token 生成の説明を確認
FlashAttention-3 の 740 TFLOPS	妥当	原論文の H100/FP16 結果を確認
DistServe の最大 7.4 倍	妥当	原論文で最大値と実験条件を確認
Roofline の左側が compute-bound	明確な誤り	Roofline の横軸と性能上限式を確認
4608 は signed 13 bit に収まる	明確な誤り	signed 13 bit の範囲を計算
E2M1 の値は全部 0.5 刻み	表現が不正確	「0.5 の整数倍」なら成立
TTFT はほぼ全部 prefill	条件付きで成立	prompt 長、待ち時間、実装条件を確認
M7 Max のネイティブ MXFP4	仮説・予測	現時点の M5 仕様とは分けて扱う

まとめ

LLM の性能は、一つの「速い・遅い」では決まりません。

prefill では大きな行列積を効率よく処理できるかが重要になりやすく、decode では重みを繰り返し読み出すためのメモリ帯域が重要になりやすくなります。そのため TTFT と後続 token の生成速度は別々に見る必要があります。

量子化についても、重みを少ない bit 数で保存できること、読み出すデータ量が減ること、その形式を演算器が直接処理できること、実際の推論が高速化することは別々の段階です。

この整理を先に置けば、他の記事の主張も「全体として正しいか」という二択ではなく、どこまでが確認できる事実で、どこに計算上の誤りがあり、どこから条件付きの説明や将来予測になるのかを分けて読めます。

今回確認した記事も、prefill と decode の性能差や Apple M5、DistServe、FlashAttention-3 に関する中心的な説明はおおむね妥当です。一方で、Roofline の左右と signed 13 bit の記述には明確な修正点があり、TTFT の説明には成立条件を残した方が正確です。

参考文献

1. id774, MacBook Pro でローカル LLM を実用化する条件（2026-07-17）. https://blog.id774.net/entry/2026/07/17/5102/
2. id774, 量子化について詳しく解説する（2026-08-07）. https://blog.id774.net/entry/2026/08/07/5472/
3. id774, LLM の量子化モデルで必要メモリと推論速度を見積もる方法（2026-08-08）. https://qiita.com/ynakayama/items/0392abf8d2bceb74fecb
4. Apple, Exploring LLMs with MLX and the Neural Accelerators in the M5 GPU（2025-11-19）. https://machinelearning.apple.com/research/exploring-llms-mlx-m5
5. Samuel Williams, Andrew Waterman, David Patterson, Roofline: An Insightful Visual Performance Model for Floating-Point Programs and Multicore Architectures（2009-04-10）. https://escholarship.org/uc/item/78h8v7mr
6. Yinmin Zhong et al., DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving（2024-07-10）. https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin
7. Jay Shah et al., FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision（2024-07-11）. https://arxiv.org/abs/2407.08608
8. sukimaengineer, LLMの計算はほぼ全部 GEMM (General Matrix Multiply) である（2026-08-10）. https://qiita.com/sukimaengineer/items/2708b7d559c70697e105