# MLエンジニアのための本質から理解するLLM推論: LLM Inference Benchmarking [[Kazuki Fujii]]（[[東京科学大学]] 博士課程）が Zenn で公開した記事。AutoRegressive Decoder Only Transformer を前提として、LLM 推論のベンチマーク測定に必要な基礎概念を体系的に解説する。著者は「多くの論文やテクニカルブログで提案手法の有効性を正しく理解するには、基礎的な知識が重要」と動機を説明している。 ## 推論プロセスの 4 段階 [[LLM推論]]は以下の 4 段階で構成される。 1. **プロンプト（Prompt）**: ユーザーが LLM にプロンプトを与える入力段階。 2. **キューイング（Queuing）**: クエリがシステムの処理キューに積まれ、実行待ちになる段階。 3. **プリフィル（Prefill）**: LLM がプロンプト全体を処理し、KV cache を構築する段階。通常は計算バウンド（Compute Bound）になる。 4. **生成（Generation）**: KV cache を参照しながらトークンを 1 つずつ逐次生成する段階（デコード）。 この 4 段階の分離がベンチマーク設計の基盤となる。 ## メトリクス体系 ### 入出力シーケンス長 - **ISL（Input Sequence Length）**: ユーザークエリ、システムプロンプト、チャット履歴、RAG 文書を含む入力トークン数の総計。 - **OSL（Output Sequence Length）**: LLM が生成するトークン数。 ### ストリーミング 生成完了を待たずにトークン塊をユーザーに逐次送信する機能。ユーザー体験の観点でレイテンシ感を下げる効果がある。 ### TTFT（Time to First Token） プロンプト送信から最初のトークン生成（応答）までの経過時間。ISL が長くなるほど TTFT が増加するが、その原因は「KV cache のサイズが増大するため」である。この因果関係を正確に把握することが、最適化の方向性を誤らないために重要とされる。 ### End-to-End Request Latency（E2EL） クエリ送信から応答の完了（全トークン生成）までの総時間。構成要素はキューイング待機、バッチング処理、プリフィル、生成、ネットワーク往復遅延の合算であり、単一フェーズの時間とは性格が異なる。 ### ITL（Intertoken Latency） 連続するトークン間の生成時間の平均値（平均デコード間隔）。ツール・フレームワーク間で定義が異なることがあり、特に **TTFT を含むか否か**で値の解釈が変わる。異なるシステム間での ITL 数値を単純比較する際は定義の確認が必須である。 ### TPS（Tokens Per Second） システム全体で 1 秒あたりに出力されるトークン数。同時リクエスト数を増やしていくと、GPU 演算能力またはメモリ帯域幅の制約に到達し、TPS は頭打ち（飽和）になる。スループット上限を知ることはキャパシティプランニングの基礎となる。 ## 著者の主張 > 推論ベンチマークを正確に理解するには、Prefill/Decoding フェーズの計算内容、KV cache の動作、行列積の FLOPs といった「裏で何が行われているか」の本質的理解が不可欠である。 この主張は本記事シリーズ全体の基盤となっており、指標の表面的な数値だけでなく計算的根拠の理解を促す姿勢を一貫して反映している。 ## 前提アーキテクチャ 議論は全面的に **AutoRegressive Decoder Only Transformer** を前提とする。エンコーダ・デコーダ型や非自己回帰型モデルへの適用は想定外である。 ## 関連 - [[LLM推論]] — Prefill（計算バウンド）と Decode（メモリバウンド）の二相構造と KV cache の役割 - [[Kazuki Fujii]] — 著者。[[東京科学大学]] 博士課程 - [[東京科学大学]] — 著者所属機関