1. 推論の最適化とは（3行でつかむ）

• 推論は2つの段階に分かれます：入力文を一度に読み込む「プリフィル」（演算が詰まる）と、答えを1トークンずつ作る「デコード」（メモリの読み出しが詰まる）です。性能と費用の議論のほとんどは、この違いから始まります事実［参考資料1・13］
• 速さ・安さ・待ち時間は同時には最適化できません：同時に処理する人数（バッチ）を増やすとGPU1枚あたりの処理量とコストは改善しますが、1人あたりの応答の間隔は延びます（第4章で本稿が試算）本稿の計算
• メモリが同時処理数を決めます：会話の途中状態（KVキャッシュ）は1トークンごとに増え、GPUのメモリを占めます。その持ち方（PagedAttention など）と、2段階を別の機械に分ける設計が、実際のサービスの工夫の中心です事実［参考資料1・9］

2. 推論の2つの段階 ― プリフィルとデコード

言語モデルは、入力のあとに続く文字（トークン）を1つずつ予測して並べます。1つ作るたびにモデル全体を1回通す必要があり、Leviathan らは「K個のトークンを作るにはモデルをK回、順番に動かす」と書いています事実［参考資料3］。ただし最初に入力文全体を読む部分は別で、全トークンを並列に処理できます。Sarathi-Serve の論文はこれを、プリフィルは「遅延は大きいがGPUの演算を使い切る」、デコードは「遅延は小さいが、1回に1トークンしか処理しないため演算の使用率が低い」と整理しています事実［参考資料10］。

Splitwise の論文は同じ違いを、プロンプト処理は「演算が重い」、トークン生成は「メモリが重い」段階で、遅延・スループット・メモリ・消費電力の性質がそれぞれ異なる、と述べています事実［参考資料8］。LLM の遅延として、MLPerf Inference の規則はTTFT（最初のトークンの遅延）とTPOT（生成されるトークン間の平均間隔）の2つを集計すると定義しています事実［参考資料14］。「待たされる」感覚は TTFT、「文字が流れる速さ」は TPOT にほぼ対応します（この対応づけは本稿の解説です）。

3. KVキャッシュ ― 会話の途中状態がメモリを占める

Transformer は、新しいトークンを作るたびに、過去のすべてのトークンとの関係（注意：attention）を計算します。過去のトークンの Key と Value を毎回計算し直すと無駄が大きいため、保存して使い回します。これが KV キャッシュです。1トークンあたりの大きさは、2（KeyとValue）×層数×KVヘッドの数×ヘッドの次元×1要素のバイト数、で決まります（本稿の整理）。

vLLM の論文は、OPT-13B（FP16）では1トークンのKVキャッシュが800 KB（2 × 5,120 × 40層 × 2バイト）で、2,048トークンなら1リクエストで最大1.6 GBになる、と示しています事実［参考資料1］。また、13Bモデルを NVIDIA A100（40 GB）で動かす例で、メモリの約65%が重み、約30%がリクエストごとの動的な状態（主にKVキャッシュ）だったと報告しています事実［参考資料1］。KVキャッシュが大きいほど同時に抱えられる人数が減り、スループットが下がります。

そのため、近年のモデルは KV を減らす設計を取り入れています。Ainslie らの GQA（grouped-query attention）は、Key/Value のヘッドを、Query のヘッドより少なくする方式で、多頭注意に近い品質で多対一注意（MQA）に近い速度を目指します事実［参考資料6］。Llama 3 の論文は、8つの Key/Value ヘッドの GQA を使い、「推論速度を上げ、デコード中のKVキャッシュを小さくする」と述べています事実［参考資料7］。

4. バッチ処理とスループット ― 同時に処理するほど安くなるが、待たされる

デコードでは、1トークンのたびにモデルの重みを全部メモリから読みます。1人分だけ処理しても、10人分まとめて処理しても、重みの読み出しは1回です。そのため、まとめて処理する人数（バッチ）を増やすほど、GPU1枚あたりの1秒のトークン数が増えます。vLLM の論文も、高いスループットには「十分な数のリクエストを同時にバッチ処理する必要がある」と書いています事実［参考資料1］。

従来の「静的バッチ」では、バッチ内の最も長い応答が終わるまで全員が待たされます。Orca（OSDI 2022）は、1回のモデル実行（1イテレーション）ごとにスケジュールし直す「イテレーションレベルのスケジューリング」を提案しました。先に終わった要求はすぐ返せて、新しい要求は次のイテレーションから加われます事実［参考資料2］。今日の多くのサービング基盤が使う「連続バッチ処理（continuous batching）」の考え方で、この対応づけは本稿の解説です。

すべて本稿の計算。Llama 3 8B（BF16）、H100 SXM（帯域3.35 TB/s、密な演算は疎性ありの値の半分と仮定）、全員が2,048トークンの時点、1 GPU、1 GPU時間を3 US$とした例示値。実測ではありません。

5. メモリの使い方 ― PagedAttention、プレフィックスの再利用、FlashAttention

従来のシステムは、各リクエストのKVキャッシュを、最大長に合わせて連続した領域に確保していました。実際の応答は最大長よりずっと短いことが多く、使われない予約領域（内部断片化）や領域の隙間（外部断片化）が生じます。vLLM の論文の測定では、既存システムでKVキャッシュのうち実際のトークン状態に使われていたのは20.4〜38.2%でした事実［参考資料1］。

PagedAttention は、OSの仮想メモリとページングにならい、KVキャッシュを固定サイズのブロックに分けて、連続していない場所に置き、ブロック表で論理的な順序とつなぎます。これで無駄はほぼ最後のブロック内に限られ、リクエスト内・リクエスト間でブロックを共有することもできます。vLLM の著者らは、同程度の遅延で、既存の最先端システム（FasterTransformer、Orca）に比べスループットが2〜4倍になったと報告しています（著者の測定条件の値）事実［参考資料1］。

元のSVG模式図・数値・出典注記を見る

同じ文章の先頭（システムプロンプトや共通の文書）を多数のリクエストが共有する場合は、その部分のKVキャッシュを再計算せず再利用できます。SGLang の論文は、そのための仕組みRadixAttentionを提案し、多段の対話やRAGなどで最大6.4倍のスループットを報告しています（著者の条件の値）事実［参考資料12］。再利用が効くかどうかは、共通部分の割合と、キャッシュをどれだけ保持できるか（メモリ）で決まります（本稿の解説）。

アテンション計算そのものも、メモリの読み書きがボトルネックです。FlashAttention は、GPUの大容量メモリ（HBM）と小さな高速メモリ（SRAM）の間の読み書きの回数を、タイル分割で減らす「IOを意識した」厳密な（近似でない）アテンションのアルゴリズムです事実［参考資料5］。結果を変えずにメモリ移動を減らす点で、投機的デコーディング（次章）のような「出力を変えない高速化」の仲間です（この分類は本稿の整理）。

6. 投機的デコーディング ― 小さなモデルに下書きさせ、大きなモデルがまとめて検算する

デコードは重みの読み出しで時間がかかる一方、演算には余裕があります（第4章）。そこで、安い小さなモデル（ドラフト）で数トークン先まで下書きを作り、大きなモデルがそれらを並列に検算して、合っていれば一度に複数トークン進める方法が考えられました。Leviathan らは、受理・棄却の仕組みを工夫して、出力の分布を変えずにT5-XXL で2〜3倍の速度向上を報告し事実［参考資料3］、Chen らは700億パラメータの Chinchilla で、分散環境で2〜2.5倍を報告しています事実［参考資料4］（いずれも著者の条件）。

Leviathan らは、ドラフトの下書きが大モデルに受け入れられる確率の平均を受理率 α、ドラフト1回のコストが大モデル1回の何倍かをc、1回に下書きするトークン数をγとして、1回の検算で進むトークン数の期待値を (1 − α^(γ+1)) ÷ (1 − α)、実時間の改善率の期待値を (1 − α^(γ+1)) ÷ ((1 − α)(γc + 1)) と導いています（トークンごとの受理が独立で同じ確率という単純化つき）事実［参考資料3］。

すべて本稿の計算（Leviathan らの式［参考資料3］に c＝0.05 を代入）。ドラフトのコスト比 c＝0.05 は例示の値です（論文は、約2桁小さいドラフトで c が0.05未満だったと報告）。

注意点が3つあります。第一に、検算のために余分な演算をするので、演算の総量は増えます。Leviathan らも、この方法は演算を増やして遅延を減らす、と整理しています事実［参考資料3］。デコードが演算でなくメモリで詰まっているときに効き、バッチが大きく演算にも余裕がなくなると、効果は小さくなりえます（これは演算量が増えるという論文の記述からの本稿の解説で、実測値ではありません）。第二に、ドラフトは別の小さなモデルのほか、大きなモデルの内部の特徴から次を予測する方式（EAGLE など）がある、という実装の違いがあります事実［参考資料19］。第三に、評価の場では、MLPerf Inference の規則は投機的デコーディングを特定のワークロードに限り、規則が定めた参照用の予測ヘッドと設定のもとでだけ認めています事実［参考資料14］。

7. プリフィルとデコードの分離、チャンク化 ― 干渉をどう避けるか

プリフィルとデコードを同じGPUで混ぜると、長いプリフィルがデコード中の他の利用者の応答を止めてしまいます。DistServe の論文は、既存のシステムが両者を同じGPUでまとめてバッチ処理するため「強い干渉」が起き、資源の配分や並列化の方針も両者で縛られる、と指摘しています事実［参考資料9］。対策は大きく2つあります。

• チャンク化（chunked prefill）：Sarathi-Serve は、プリフィルをほぼ等しい大きさの断片に分け、進行中のデコードを止めずに新しい要求を加える「停止しないスケジュール」を提案しました。Mistral-7B（A100 1枚）で vLLM の2.6倍の「サービング容量」（遅延の上限を守って処理できる量）を報告しています（著者の条件）事実［参考資料10］
• 分離（disaggregation）：プリフィル専用とデコード専用のGPU群に分け、KVキャッシュを間の通信で渡します。Splitwise は、同程度のコストで 1.4倍のスループットを2割低い費用で、または同じ費用・電力で 2.35倍のスループットを報告し事実［参考資料8］、DistServe は、遅延の条件を満たしたまま最大 7.4倍の要求、または 12.6倍厳しい遅延条件を報告しています事実［参考資料9］（いずれも著者の条件）

Mooncake は、Moonshot AI のサービス（Kimi）の基盤として、プリフィルとデコードを分け、GPUクラスターの余っているCPU・DRAM・SSDをKVキャッシュの置き場として使う設計を公開しました。著者らは、実際の負荷でKimiが75%多くの要求を処理できたと述べています（同社の報告）事実［参考資料11］。

すべて事実（各論文の著者の報告）。ベースライン、モデル、ハード、負荷が論文ごとに異なるため、表の倍率どうしを比べて優劣をつけることはできません。

8. 遅延・スループット・コストの読み方 ― 数字に添えるべき条件

第4〜7章で見たとおり、同じシステムでも条件で数字は何倍も変わります。速度やコストの主張を見るときに、確認すべき項目を表にまとめます（本稿の整理）。

第4〜7章をもとにした本稿の整理です。価格は日々変わるため、本稿は特定の事業者の料金を掲載しません。

9. 限界と、確認できなかったこと

• 実機の測定値は載せていません：本稿の計算は、メモリ律速を仮定した理想化の見積もりです。MLPerf の個別の提出結果の数字や、各社のハードウェアの比較は、設定が揃わないため載せていません
• 扱っていない技術：量子化の詳細、MoE の専門家並列、テンソル並列・パイプライン並列の通信コスト、KVキャッシュの量子化・圧縮、スライディングウィンドウ注意などは、本稿では詳しく扱っていません（モデルの効率化は本シリーズ「モデルの効率化」編を参照）
• サービング基盤ごとの機能差：vLLM（Apache-2.0 のオープンソース、2026年10月14日にもリポジトリが更新されていることを確認）事実［参考資料20］、SGLang、その他の基盤の個別の機能や版ごとの違いは、検証していません
• 価格：各事業者のAPI料金は変動が速く、公式の価格表の確認と日付の記載が必要なため、本稿には載せていません。コストの例は、GPU時間を3 US$とした例示の値です
• 標準：LLM推論の遅延・スループットを定める国際規格は確認できませんでした。ISO/IEC 22989 は用語の規格です

10. 評価・標準の読み方

推論の性能は、(1) 遅延（TTFT・TPOT）、(2) 遅延の上限を守って出せる処理量、(3) 出力の品質が保たれているか、(4) 消費電力、の4つの組合せで評価します。業界で最もよく使われる公開の枠組みが MLCommons の MLPerf Inference で、利用者の到着を模したサーバーシナリオとオフラインシナリオを定め、LLM のベンチマークごとに TTFT・TPOT の上限と精度目標を決めています事実［参考資料14］。確認日 2026年10月15日時点で、MLCommons のベンチマークのページは MLPerf Inference v6.1 を示しており事実［参考資料15］、2026年9月16日の発表では、30団体が提出し、RAG のエンドツーエンドのテストなどが加わったと伝えています事実［参考資料15］。

区分タグは各セルに付けています。MLPerf の遅延上限の数値は、GitHub の規則文書（2026年10月15日時点の master）から転記しており、版が変わると改定されます。表の整理は本稿によるものです。

読み方の注意は3つです。

• 設定と実施主体で数字が変わる：MLPerf は提出者が自社の最適化で測る方式で、規則がハーネス、精度目標、投機的デコーディングの可否まで定めています。規則の外で測った「○倍」とは別物です
• ベンチマークは入れ替わる：MLPerf Inference は版ごとにモデルとシナリオが変わります（例：v6.1 で RAG のエンドツーエンドとエッジのエージェント処理が追加）。古い版の数字を「現在」として扱わない
• 標準は「用語」が中心：LLM 推論の速度や遅延を要求事項として定める国際規格は、本稿の調査範囲では確認できませんでした。ISO/IEC 22989 は概念と用語の規格で、性能の合否を決めるものではありません。性能の主張は、公開ベンチマークの規則と条件に依存します

11. 用語集

12. 参考資料（一次情報）

1. Kwon W. ほか "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP '23 (2023), DOI 10.1145/3600006.3613165, arXiv 2309.06180 — arxiv.org/abs/2309.06180
2. Yu G.-I. ほか "Orca: A Distributed Serving System for Transformer-Based Generative Models", OSDI '22 (2022) — usenix.org/conference/osdi22/presentation/yu
3. Leviathan Y. ほか "Fast Inference from Transformers via Speculative Decoding", ICML 2023, PMLR 202 (2023), arXiv 2211.17192 — proceedings.mlr.press/v202/leviathan23a.html
4. Chen C. ほか "Accelerating Large Language Model Decoding with Speculative Sampling", arXiv 2302.01318 (2023) — arxiv.org/abs/2302.01318
5. Dao T. ほか "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness", NeurIPS 2022, arXiv 2205.14135 — arxiv.org/abs/2205.14135
6. Ainslie J. ほか "GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints", EMNLP 2023, DOI 10.18653/v1/2023.emnlp-main.298, arXiv 2305.13245 — arxiv.org/abs/2305.13245
7. Grattafiori A. ほか（Meta） "The Llama 3 Herd of Models", arXiv 2407.21783 (2024)（表3：8B は32層、モデル次元4,096、ヘッド32、Key/Value ヘッド8） — arxiv.org/abs/2407.21783
8. Patel P. ほか "Splitwise: Efficient Generative LLM Inference Using Phase Splitting", ISCA 2024, DOI 10.1109/ISCA59077.2024.00019, arXiv 2311.18677 — arxiv.org/abs/2311.18677
9. Zhong Y. ほか "DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving", OSDI '24 (2024), arXiv 2401.09670 — usenix.org/conference/osdi24/presentation/zhong-yinmin
10. Agrawal A. ほか "Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve", OSDI '24 (2024), arXiv 2403.02310 — usenix.org/conference/osdi24/presentation/agrawal
11. Qin R. ほか（Moonshot AI ほか） "Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving", arXiv 2407.00079 (2024)（FAST '25 版の題名は "Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot"） — arxiv.org/abs/2407.00079
12. Zheng L. ほか "SGLang: Efficient Execution of Structured Language Model Programs", arXiv 2312.07104 (2023) — arxiv.org/abs/2312.07104
13. NVIDIA "NVIDIA H100 Tensor Core GPU"（H100 SXM：GPU メモリ 80 GB、メモリ帯域 3.35 TB/s、Tensor Core の値は「疎性あり」、最大TDP 700 W まで／確認日 2026年10月15日） — nvidia.com/en-us/data-center/h100/
14. MLCommons "MLPerf Inference Rules"（inference_policies リポジトリの inference_rules.adoc。確認日 2026年10月15日の master。TTFT/TPOT の定義、シナリオ、LLM ベンチマークの精度目標・遅延上限、投機的デコーディングの付録） — github.com/mlcommons/inference_policies/blob/master/infer...
15. MLCommons "MLCommons Sets Participation Record with New MLPerf Inference v6.1 Benchmark Results"（2026年9月16日の発表。GlobeNewswire 配信の転載ページ）、およびベンチマークのページ https://mlcommons.org/benchmarks/inference-datacenter/（v6.1 の表示を確認／2026年10月15日） — financialcontent.com/article/gnwcq-2026-9-16-mlcommons-se...
16. Reddi V. J. ほか "MLPerf Inference Benchmark", ISCA 2020, DOI 10.1109/ISCA45697.2020.00045, arXiv 1911.02549 — arxiv.org/abs/1911.02549
17. Tschand A. ほか "MLPerf Power: Benchmarking the Energy Efficiency of Machine Learning Systems from Microwatts to Megawatts for Sustainable AI", arXiv 2410.12032 (2024) — arxiv.org/abs/2410.12032
18. ISO/IEC "ISO/IEC 22989:2022 Information technology — Artificial intelligence — Artificial intelligence concepts and terminology"（第1版、2022年7月。JTC 1/SC 42） — iso.org/standard/74296.html
19. Li Y. ほか "EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty", ICML 2024, arXiv 2401.15077 — arxiv.org/abs/2401.15077
20. vLLM project GitHub リポジトリ vllm-project/vllm（ライセンス Apache-2.0、2026年10月14日に更新を確認） — github.com/vllm-project/vllm

13. 主張と出典の対応表（監査）

最終更新：2026年10月15日／出典は一次情報（査読論文・学会論文、MLCommons の規則文書と発表、NVIDIA のデータシート、ISO のページ）に限定しています。実機の測定値、各社の価格、LLM推論の遅延を定める国際規格については、確認できなかったため記載していません。倍率は各論文の著者の条件つきの報告で、本稿の計算は理想化した試算です。図2・5・7はベクター作図、図3・4・6は本稿の計算を含む作図、図1と図8はAI生成イメージ（枠のみ）です。