# LLM推論 ## 定義 LLM推論(LLM inference / serving)とは、学習済み大規模言語モデルでトークンを生成する実行過程で、入力を一括処理する Prefill フェーズと、トークンを 1 つずつ生成する Decode フェーズに分かれる。Prefill は TTFT(Time To First Token)、Decode は TPOT(Time Per Output Token)で評価される。([[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) 実行はクラウドの多 GPU・多ノードからエッジ/オンデバイスまで多様な環境にまたがり、演算子オフロード・グラフ実行・Mixture-of-Experts ルーティングといった動的挙動を伴う。([[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) 現在の理解は、Prefill(計算バウンド)と Decode(メモリバウンド)というフェーズ差を診断と最適化の基本軸に据える点でおおむね一致しており、「帯域不足」という単純な説明は細粒度観測によって繰り返し反証されてきた。効率化のタクソノミーはサーベイごとに分類原理が異なり(介入点・アルゴリズム/システム・data/model/system)、統一されていない。実務では KV キャッシュの配置・転送・共有・圧縮が Prefill-Decode 分離や本番スケジューリングの共通制御対象として肥大化しており、通信・アクセラレータ・エンジン選定の最適化はその上に積み重なる独立した層として並立する。オンライン SLO 志向とオフラインスループット志向という 2 つの設計軸の分岐は近年明確になったが、モデル構成×ハードウェア×リクエスト負荷を横断する包括的で再現可能なベンチマークは依然として未確立である。 ## 子概念 - [[FlashAttention]] - [[GPU観測性]] - [[LLMネイティブ推薦]] - [[Prefill-Decode分離]] - [[Speculative Decoding]] - [[モデル圧縮]] - [[制約付きデコーディング]] ## フェーズ構造と観測粒度 - **Prefill=計算バウンド/Decode=メモリバウンドの段階差が観測の基本軸である。** - 根拠: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] — オンデバイス推論で演算子レベル PMC により、Decode の行列ベクトル乗算では CPU サイクルの 50% 超(4 スレッドで 80% 超)がメモリ帯域律速で stall することを示した。フェーズごとに律速資源が変わることが、推論最適化と観測設計の出発点になる。 - **ボトルネックは「帯域不足」という素朴な見立てでなく、別の資源にあることが多い。** - 根拠: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] — MoE のボトルネックはメモリ帯域でなく、evict されたエキスパートの fetch による**ディスク I/O**だと結論した。 - 根拠: [[@2025__arXiv__Collective Communication for 100k+ GPUs]] — 推論のボトルネックは帯域でなく**CPU 準備オーバーヘッド**や CUDA Graph 由来のパディングだと特定した。 - **推論最適化は、モデル・GPU・ネットワークの単一層でなく要求からカーネルまでの統合分析を要する。** - 根拠: [[@2025__EngineeringAtMeta__Zoomer - Powering AI Performance at Meta's Scale Through Intelligent Debugging and Optimization]] — [[Zoomer]] は推論要求レート・サーバーレイテンシ・アクティブ要求・GPU メモリ割り当て・サービングパラメータを [[Crochet]] と Thrift リクエストプロファイリングで取得し、[[Kineto]]／PyTorch Profiler のカーネル・メモリ転送トレースや [[Dynolog]] のホストメトリクスと合わせて分析する。単一 GPU の細粒度プロファイリングを扱う [[ProfInfer]]・[[eInfer]] に対し、要求単位の QPS 最適化と自動負荷試験まで含む本番運用ループを示す。 - **観測対象はスケール(サーバ/分散規模 対 エッジ)で変わる。** - 根拠: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]] — サーバ/分散規模では CPU・GPU・ネットワーク・ノード横断のリクエスト追跡や GPU 常駐コレクティブを扱う。 - 根拠: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] — エッジ(Orange Pi・Rubik Pi)では演算子オフロード・スレッド偏り・干渉タスクを扱う。スケールの違いがボトルネックの所在(通信か・I/O か・スレッド偏りか)を変える。 - **MoE ルーティングが観測の難所として共通する。** - 根拠: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] — MoE のルーティング挙動と通信ボトルネックを追跡する。 - 根拠: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] — 活性化エキスパート ID と「距離」(前回活性化からのトークン距離)を追跡する。動的にエキスパートが選ばれる MoE は静的なグラフ解析では捉えられず、実行時計装の主対象になる([[Mixture-of-Experts]])。 - **データフローアクセラレータの優位はデコードフェーズ(メモリバウンド)に限定され、プリフィルフェーズ(計算バウンド)では GPU と大差ない。** - 根拠: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]] — ALCF での実測で Cerebras CS-3 の ITL が A100 比 18.8 倍短縮する一方、TTFT の改善は 35% にとどまる。プリフィル=計算バウンド・デコード=メモリバウンドの区別と整合し、アーキテクチャの物理的優位性の限界を示す。デコード律速が大きいオンライン推論ではデータフローが有効だが、大バッチオフライン推論では GPU の柔軟なバッチ拡大が優位に転じる。 - **投機的復号の高速化率は、Decode フェーズ内でもバッチサイズに応じて計算律速へ連続的に遷移する。** - 根拠: [[@2026__arXiv__Speculative Decoding - Performance or Illusion?]] — vLLM 上で [[Speculative Decoding]] の速度向上がバッチサイズ増加とともに縮小する(検証段階のコスト支配が強まるため)ことを実測し、この減衰率がモデルサイズに応じて増幅されることを示した(Llama3.1-8B の 4.3% に対し Llama3-70B は 14.0%)。 - 関連: ProfInfer が示す段階間の律速資源の違いとは別軸で、同一 Decode フェーズ内部の遷移を示す([[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]])。 - **オンライン推論の性能診断は、フェーズごとに異なる観測粒度を組み合わせる必要がある。** - 根拠: [[@2026__OSDI__StriaTrace - Efficient Tracing and Diagnosis for Online LLM Inference]] — 本番サービングで TTFT/TPOT と推論ステップのトークン数を対応づけ、Prefill/Decode のテイル異常を検知する。 - 根拠: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] — オンデバイス推論で演算子レベルの PMC を用いてメモリ帯域やディスク I/O の律速を特定する。前者のステップ・リクエスト粒度と後者の演算子・ハードウェア粒度は代替関係ではなく、SLO 違反を検知してから内部律速を掘り下げる階層として接続できる。 ## 推論効率化サーベイの分類軸と発展史 - **LLM 推論効率化はアルゴリズムレベルとシステムレベルの二重構造をなす。** - 根拠: [[Efficient Large Language Models - A Survey]] — 推論最適化をアルゴリズムレベル(投機的復号、KV キャッシュ最適化)とシステムレベル(FlexGen、Orca、vLLM、DeepSpeed-Inference、Flash-Decoding)に二分する。投機的復号は小型ドラフトモデルから木構造候補を生成し棄却サンプリングで品質を保持する唯一の手法であり、SpecInfer(トークン木検証)・Medusa(追加ヘッド方式)・BiLD(フォールバック/ロールバック方策)の 3 設計が立つ。KV キャッシュ最適化は圧縮系(KIVI: 2 ビット量子化でピークメモリ 2.6 倍削減)と退避系(H₂O: 動的劣モジュラ退避、StreamingLLM: アテンションシンク+ウィンドウで一定メモリの無限系列長)に分かれる。システムレベルでは Orca の反復レベルスケジューリング(FasterTransformer 比 36.9 倍スループット)から vLLM の PagedAttention(2–4 倍スループット)へ、メモリ管理の OS 的仮想化が進む。 - 関連: [[Towards Efficient Generative Large Language Model Serving]] が推論フレームワーク 10 種の横断比較に特化するのに対し、Wan+ は推論をモデル圧縮・効率的アーキテクチャ(FlashAttention、MoE、状態空間モデル)を含むモデル中心手法全体の一部として位置づける。 - **モデル圧縮が推論効率化の前段として機能し、両者は直列に組み合わさる。** - 根拠: [[Efficient Large Language Models - A Survey]] — [[モデル圧縮]](量子化・プルーニング・低ランク近似・知識蒸留)は推論とは独立のセクションで扱われるが、実際にはモデル圧縮後のモデルが推論パイプラインに投入される。PTQ の重み限定量子化(GPTQ: 175B を 3–4 ビット化)と KV キャッシュ量子化(KIVI: 2 ビット)は推論のメモリ律速を異なるレイヤーで緩和する。FlexGen が「重み+KV キャッシュの 4 ビット量子化で OPT-175B を単一 16GB GPU で推論」した例が、この直列最適化の実効性を示す。 - **低レイテンシと高スループットは双対最適化目標であり、同時最適化は原理的に困難である。** - 根拠: [[Towards Efficient Generative Large Language Model Serving]] — サービングシステム 10 種を横断比較し、FlexFlow-Serve は SpecInfer による投機的復号でレイテンシに特化し、vLLM はページドアテンションによる KV キャッシュ効率化でスループットに特化するという設計の分岐を明示した。 - 関連: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] が示す Prefill=計算バウンド/Decode=メモリバウンドのフェーズ差は、この双対性の物理的根拠と一致する——Prefill の高速化(TTFT 削減)とバッチ効率(スループット)は異なる資源を律速とするため。 - **投機的復号は出力品質を保持できる唯一のアルゴリズム的高速化手法である。** - 根拠: [[Towards Efficient Generative Large Language Model Serving]] — 非自己回帰復号・早期脱出・カスケード推論がいずれも品質劣化を伴うのに対し、投機的復号は木構造検証で LLM の出力分布を保存することを示す。 - 関連: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] が分散推論で speculative decoding のトレース可能性を問うのは、この品質保証前提を運用で検証する必要があるからだ。 - **2025 年時点の推論サービングサーベイは、単一フレームワーク比較から新興シナリオの運用問題へ広がった。** - 根拠: [[Towards Efficient Generative Large Language Model Serving]] — アルゴリズム/システムの 2 軸で効率化を整理する(Miao+ CSUR)。 - 根拠: [[@2025__INLG__Taming the Titans - A Survey of Efficient LLM Inference Serving]] — モデル配置・スケジューリング・KV キャッシュ・PD 分離・マルチプレクシングをインスタンス内軸、異種 GPU 配置・ロードバランシング・クラウド/エッジ協調をクラスタ軸、長コンテキスト/RAG/MoE/LoRA/投機的復号/エージェント/マルチモーダルを新興シナリオ軸として整理する(Zhen+)。推論サービングは「単一モデルを速く動かす」段階から「複数段階・複数モダリティ・外部ツールを SLO 下で調停する」段階へ移っている。 - **2024 年型の三層タクソノミーは、2025 年型の分離・永続化・cache-aware orchestration で拡張される。** - 根拠: [[A Survey on Efficient Inference for Large Language Models]] — LLM 推論効率化を data-level、model-level、system-level に整理し、system-level を推論エンジン、offloading、投機的復号、メモリ管理、バッチング、スケジューリング、分散システムへ分ける(Zhou+)。 - 根拠: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]] — PagedAttention、SGLang、LMCache、P/D-Serve を並べると、system-level の中で「KV キャッシュ管理」が独立した横断軸として成長し、単一エンジン内メモリ管理から分離型クラスタのデータプレーンへ拡張したことが分かる。 - **LLM 推論の発展史は attention 最適化から disaggregation へ読めるが、一次根拠は個別システム論文で補強すべきである。** - 根拠: [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]] — KV Cache、FlashAttention、Continuous Batching、Speculative Decoding、PagedAttention、RadixAttention を、分離型推論へ向かう発展線として整理する(Aravilli+)。この視点は有用だが、CAP 定理などの説明は比喩として注記されているため、性能・実装根拠は vLLM、SGLang、LMCache、P/D-Serve、DistServe の各論文へ遡る必要がある。 - **既存サーベイの taxonomy は複数の独立した分類原理を持つ。** - 根拠: [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 1 Introduction]] — 「介入点による3分類」(モデル中心・データ中心・フレームワーク中心、Wan+)で efficient inference を model-centric(§2.4)の一部門としてモデル圧縮・効率的事前学習・効率的ファインチューニング・効率的アーキテクチャと並置する。この切り口は Miao+ のアルゴリズム/システム2軸、Zhou+ の data/model/system 3層タクソノミーとは分類原理が異なる。 - 根拠: [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]] — Table 2 は同じフレームワーク中心の主題を「そのフレームワークがどのタスクに対応するか(Training/Fine-Tuning/Inference)」という運用上の軸で再整理する。この軸は、Miao+ が挙げる推論フレームワーク横断比較(FlexFlow-Serve・vLLM 等)の背後にある「なぜこれらが推論専用ツールとして独立に存在するのか」という問いに対する一次的な説明になる。 - **Zhou+ の "first token latency" / "per-output token latency" は、後発コミュニティ用語 TTFT / TPOT・ITL が指すのと同一の指標を、指標体系として先に定式化したものである。** - 根拠: [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 2 Preliminaries]] — §2.2 Inference Process of LLMs は、Prefilling 段階の遅延を **first token latency**、Decoding 段階の1トークンあたり平均遅延を **per-output token latency** と定義し、これらに generation latency・token throughput・request throughput・model size・KV cache size・peak memory を加えた8指標の体系を提示する(2024年4月)。 - 関連: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]] が使う TTFT・TPOT・ITL・E2EL・TPS・RPS・Goodput という後発の実務コミュニティ用語と概念的に対応するが、後者は SLO との結びつきや ITL の TTFT 包含/非包含といったツール依存の計算差異まで踏み込む点で発展している。Zhou+ の指標定義は、ProfInfer が実測で示す「Prefill=計算バウンド・Decode=メモリバウンド」というフェーズ差の測定対象を先に切り分けた理論的土台であり、Zhou+ の第2.3節が挙げる3根本原因(モデルサイズ・注意演算の二乗複雑度・自己回帰復号のメモリアクセスコスト)は ProfInfer の実測結果を後から説明する形になっている。 ## Goodput・SLO・ベンチマーク設計と品質劣化 - **Goodput は SLO 達成スループットを示す実用的指標である。** - 根拠: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]] — 生のスループット(TPS/RPS)は SLO を無視した指標だが、実際の運用では TTFT・ITL の制約が満たせないリクエストは実質的に無効になる。秒間 10 RPS のシステムが TTFT 200 ms 以下・ITL 50 ms 以下の SLO 制約により Goodput が 3 RPS まで低下する例を示す(道下幹也)。Goodput は「SLO を満たすスループット」として設計の評価指標に据える必要がある([[サービスレベル目標]])。 - **ユースケースの ISL/OSL プロファイルがベンチマーク設計の前提となる。** - 根拠: [[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]] — 翻訳(ISL≈OSL≈500〜2000)・生成(ISL≈100、OSL≈1000)・要約(ISL≈1000、OSL≈100)・推論(ISL≈100、OSL≈1000〜10000)の 4 パターンを定義する。同じハードウェアとモデルでも ISL/OSL 比が変わればベンチマーク結果は大きく変わるため、実用目的に合わせたプロファイル選択が不可欠。 - **ITL・TPS の計算方法はツール間で異なり、直接比較には正規化が必要である。** - 根拠: [[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]], [[@2026__Zenn__MLエンジニアのための本質から理解するLLM推論]] — [[GenAI-Perf]] の ITL は TTFT を含まないが、LLMPerf は含む。TPS の分母定義もツールにより異なる。 - **本番 LLM の品質劣化はルーティング・推論設定・コンパイラの 3 層で独立して発生しうる。** - 根拠: [[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]] — [[Anthropic]] の 2025 年 8〜9 月の 3 件の障害事例は、同一の「出力品質低下」という症状が (1) コンテキストウィンドウのサーバールーティングエラー、(2) TPU サーバーの誤設定によるトークン生成エラー、(3) XLA:TPU コンパイラの混合精度演算バグ、という全く異なる層に起因しうることを示す。 - 関連: [[ICSE 2026|@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] が定量化した「症状と根本原因の多対多関係」を、LLM 推論システムの具体例として裏付ける。 - **近似 top-k と厳密 top-k の精度不一致がトークン選択を変化させる可能性がある。** - 根拠: [[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]] — XLA:TPU コンパイラバグ事例では、混合精度(異なる浮動小数点精度で動作する演算間)のトークン確率計算が不一致を起こしトークン選択に影響した。修正は近似的 top-k から厳密な top-k への切り替えと精度処理の標準化だった。LLM 推論における数値精度の差異が出力に与える影響は、モデル評価の文脈ではほとんど考慮されない。 - **推論コスト最適化は信頼性低下として現れる場合がある。** - 根拠: [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] — 短いコンテキストウィンドウ、小型モデルへの切り替え、低サンプリング、積極的なキャッシュ利用などのコスト制約が、サービスエラーを出さずに推論品質を劣化させる失敗モードを「コスト起因劣化」として扱う。 - 関連: TTFT/ITL/Goodput や KV キャッシュ最適化の効率指標に、意味的正しさと安定性の制約を重ねる必要があることを示す([[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]], [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]])。 - **推論電力の低下と実効性能の向上は別の評価軸である。** - 根拠: [[@2025__arXiv__Dissecting the NVIDIA Blackwell Architecture with Microbenchmarks]] — Blackwell の RTX 5080 は GPT-NeoX の FP8 推論で 45.14 W まで電力が下がったが、FP8 D-GEMM の大規模形状では H100 より低いスループットだった。推論エンジンの精度設定は電力を下げても、レイテンシ・スループット・出力品質を同時に改善するとは限らない。 ## Prefill-Decode分離とスケジューリング制御 - **PD分離はテイルレイテンシを改善するが、KV Cache 転送がボトルネックになる。** - 根拠: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]] — Prefill ノードと Decode ノードを物理分離すると ITL のテイルレイテンシが改善されるが、GB オーダーの KV Cache をノード間で転送する必要が生じる(Llama-3.1-405B で入力 8k トークン時に約 4 GB/リクエスト)。100 並行リクエスト時の転送は高速ネットワーク(400 Gbps NIC + GPUDirect RDMA)なしには成立しない。「KV Cache を設計の中心に据える」ことが分散推論基盤の定石とされる理由がここにある。 - **PD分離は「同じ GPU 枚数での役割分割」としても ITL テイルを改善しうる。** - 根拠: [[@2026__さくらのナレッジ__高火力PHYを利用した分散推論基盤の性能検証]], [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]] — H100 HGX の PD 分離検証で、入力 8k・出力 1k・4 GPU 条件では、32 同時接続で Aggregated が ITL P99 100 ms 以内に収まらない一方、PD 分離は 30 ms 以内に収まる。「GPU を増やす」だけでなく「Prefill と Decode のリソースを分ける」こと自体が SLO 達成に効く。 - **KV Cache Reuse は TTFT を下げるが、Prefix 構造とストレージ読み込みコストに制約される。** - 根拠: [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]], [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]] — DeepSeek-V4 はオンディスク KV キャッシュで共有プレフィックス再プリフィルを避ける方向を示し、Mooncake Store を用いたリモート KV Cache Reuse/Sharing は 8k 入力のキャッシュヒット量を増やすほど TTFT が最大 1.75 倍程度削減されることを実測した。一方で、完全ヒット近傍でも KV Cache 読み込みが TTFT の約 1/4 を占める観察があり、KV Cache は「再計算を避ける」だけでなく「読み込みをどう安くするか」が制御対象になる。 - **DistServe は PD 分離を Goodput 最適化として定式化した一次論文である。** - 根拠: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]] — Prefill と Decode の同居が TTFT/TPOT 干渉と資源・並列化結合を生むことを示し、段階別の GPU 割当・テンソル並列・パイプライン並列探索で per-GPU Goodput を最大化する。vLLM 比でチャット 2.0〜4.6 倍、コード補完 5.7 倍、要約 4.3 倍のリクエスト率を達成し、DeepSpeed-MII 比では最大 7.4 倍高いリクエスト率を示した。 - 反証: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]] が指摘する「PD 分離は KV キャッシュ転送が難点」という議論に対し、配置制約とノード内 NVLINK を使えば OPT-175B でも転送を総レイテンシ 0.1% 未満に抑えられることを示す。 - **本番規模の分離型推論では、scheduler の観測信号そのものが不完全になる。** - 根拠: [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]] — Prefill queue の pending token 数や SSE connection 数が実 TTFT を十分に説明しないと述べる。Prefix hit ratio、batch size、scenario ごとの prompt 分布が Prefill 能力を変えるため、グローバルスケジューラだけでは idle Prefill を正確に把握できない。これは [[GPU観測性]] や [[LLM学習モニタリング]] と同様、推論サービングでも「正しい制御信号をどう観測するか」が設計問題になることを示す。 - **同一レプリカ内での QoS 差別化 co-scheduling は、PD 分離とは異なる軸でサイロ非効率を解消する。** - 根拠: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]] — 既存の LLM サービングが interactive/batch の二値サイロ(専用 GPU クラスタ)に依存し、負荷変動でリソースが偏在すると指摘する。Niyama は Prefill/Decode を同一レプリカに同居させたまま(chunked-prefill、[[Sarathi-Serve]] 拡張)、複数 QoS クラスのリクエストを 1 つの共有クラスタで co-schedule することでこれを解消し、SOTA サイロ構成比で GPU 必要台数を 13〜32% 削減した。 - 関連: [[DistServe]] が Prefill/Decode を物理的に分離してリソースを最適化するのと対照的に、「分離せず共有インフラ上でスラックを再配分する」という逆方向のアプローチであり、LLM サービング効率化には「分離してそれぞれ最適化する」路線と「共有して動的に配分する」路線の 2 系統が並立していることを示す。 - **チャンクサイズは固定パラメータでなく、デッドラインスラックに基づき動的に決定すべき制御変数である。** - 根拠: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]] — chunked-prefill([[Sarathi-Serve]])は固定チャンクサイズを前提とするため、最も厳格な QoS クラスの TBT 制約に合わせると全体スループットが低下する(固定チャンクサイズ 330 で 50ms SLO を満たすとスループットが 28% 低下する例)。Niyama は decode queue 内リクエストの次トークンデッドラインまでの残り時間(スラック)を毎イテレーション計算し、デッドラインを侵害しない範囲でチャンクサイズを機会的に拡大する。これは PagedAttention・RadixAttention 等がメモリ管理を制御対象にしたのと同様に、チャンクサイズという実行時パラメータ自体がスケジューリングの一級市民になったことを示す。 - **EDF と SRPF の線形補間が、LLM 推論スケジューリングにおける低負荷/高負荷のトレードオフを解消する。** - 根拠: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]] — EDF(Earliest Deadline First)は低負荷で違反ゼロだが負荷がしきい値を超えると違反率がほぼ 100% に急騰し、SRPF(Shortest Remaining Prompt First)は高負荷に強いが長いリクエストのデッドラインを低負荷でも不公平に犠牲にする。Niyama のハイブリッド優先度式(デッドライン項 + α × 残処理時間項)はこの 2 極を補間し、最大 40% 高い負荷までテールレイテンシ SLO を維持した。既存のクラウド QoS スケジューリング(Paragon・Quasar)は LLM 推論の二段階実行モデル・高いプリエンプションコストを前提としておらず、この補間設計は LLM 推論固有の解決策として位置づけられる。 - **過負荷対応は「一部リクエストを早期に諦める」設計が全体最適になりうる。** - 根拠: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]] — 積極的降格(eager relegation)は、デッドラインをすでに違反した/違反しそうなリクエストを relegated queue へ先回りして降格させ、5% 程度の犠牲で残り 95% のリクエストの中央値レイテンシを安定させる。 - 関連: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]] の Early Rejection(過負荷指向スケジューリング)と同じ問題意識(全リクエスト処理を前提としない)を持つが、Mooncake が受け入れ制御(admission control)として過負荷を扱うのに対し、Niyama は受け入れ後のスケジューリング層で降格を行う点が異なる。両者を比較すると、過負荷対応は「入り口で断る」と「実行中に降格する」という 2 つの制御点で実装しうる。 - **オンライン推論最適化(TTFT/TPOT の SLO)とオフライン・大規模バッチ推論最適化(スループット)は、同じ推論エンジンでも異なる設計原理を要求する。** - 根拠: [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]] — Goodput、PD 分離、chunked-prefill、QoS co-scheduling 等の知見の多くがストリーミングサービスの SLO 達成を主眼にする一方、BatchLLM は検索エンジンのスニペット生成やオフラインランキングのような、スループットのみが指標となる大規模バッチ推論に特化する。バッチ全体が事前に既知であるという前提を利用してプレフィックスを大域的に事前識別し、リクエストを decode/prefill 比で並べ替え、KV メモリ制約のみで token バッチを拡大することで vLLM・SGLang に対し 1.3〜10.8 倍のスループット向上を達成する。この設計は個々のリクエストのレイテンシを犠牲にしうるため、著者自身がレイテンシ重視のオンラインサービスには不向きと明言しており、推論の最適化空間が「オンライン SLO 志向」と「オフラインスループット志向」の 2 つの独立した設計軸に分岐していることを裏付ける。 - **BatchLLM が挙げる「オフラインランキング」の具体的な実例が、Netflix の GenRec によって報告された。** - 根拠: [[@2026__Netflix TechBlog__GenRec - Towards LLM-native Recommendation at Netflix]] — BatchLLM の知見は「検索エンジンのスニペット生成やオフラインランキング」を大規模バッチ推論の応用例として抽象的に挙げるにとどまるが、[[Netflix]] の GenRec は自己回帰デコードを一切行わない**prefill-onlyモード**でカタログ全体を1回のフォワードパスでスコアリングする、より極端な形の「オフラインスループット志向」推論を報告する。BatchLLM がプレフィックス共有とトークンバッチングでデコード込みの推論を高速化するのに対し、GenRec はそもそもデコードフェーズを持たず(生成せずカタログ対応スコアリングヘッドでスコアのみ出力)、prefill 計算そのものを唯一のコストとして最適化対象にする点が異なる。両者は「オンライン SLO 志向 対 オフラインスループット志向」という分岐軸のうち、後者をさらに「デコードを含む大規模バッチ」と「デコードを持たないスコアリング専用ワークロード」の2種に細分化しうることを示す。 ## KVキャッシュのアーキテクチャと本番運用課題 - **KV キャッシュが LLM 推論システムの共通制御対象になった。** - 根拠: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]] — vLLM/PagedAttention は KV キャッシュを GPU 内のページ化メモリとして管理する。 - 根拠: [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]] — SGLang/RadixAttention は prefix 木として再利用する。 - 根拠: [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]] — LMCache は GPU 外の階層ストレージと推論エンジン間転送対象にする。 - 根拠: [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]] — P/D-Serve は RoCE 上の D2D 転送を本番 MLOps に組み込む。LLM 推論最適化は attention kernel だけでなく、KV キャッシュの配置・転送・共有・退避・ルーティングをどう制御するかへ広がった。 - **Structured LM programs は推論サービングのキャッシュ単位を「リクエスト」から「プログラム構造」へ変える。** - 根拠: [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]] — SGLang は ReAct、Tree-of-Thought、Skeleton-of-Thought、LLM judge、RAG、multi-turn chat を、複数 generation call と制御フローを持つ LM プログラムとして扱う。RadixAttention は `fork` や共通 system prompt から prefix 木を作り、cache-aware scheduling で平均 96% の最適 hit rate に近づく。これは、LLM 推論の効率化単位が単一 API request ではなく、アプリケーションワークフロー全体へ移ることを示す。 - **スパースアテンションが MoE + MLA アーキテクチャの推論コストを長コンテキストで大幅に削減する。** - 根拠: [[@2025__arXiv__DeepSeek-V3.2 - Pushing the Frontier of Open Large Language Models]] — DeepSeek Sparse Attention(DSA)は、ライトニングインデクサ(FP8・ReLU 活性化の軽量モジュール)でトークン間の関連度をスコアリングし、top-k のキーバリューエントリのみにアテンションを適用することでコアアテンション複雑度を O(L²) から O(Lk) に削減する。128K コンテキストでプリフィルコストが DeepSeek-V3.1-Terminus の約 1/4 に低下し、デコードコストも同様に削減される。 - 関連: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] が示す Prefill=計算バウンド/Decode=メモリバウンドのフェーズ差に対し、DSA は Prefill の計算バウンドを構造的に緩和するアーキテクチャ的解である。短系列ではマスク付き MHA モードで DSA をシミュレートし効率を維持する点で、系列長に応じた推論戦略の動的切替が実装レベルで実現されている。 - **ハイブリッド圧縮アテンションが KV キャッシュ問題を構造的に解決し、100 万トークンコンテキスト推論を実用化した。** - 根拠: [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]] — CSA(4 トークン→1 圧縮 + top-k スパース選択)と HCA(128 トークン→1 高圧縮 + 密アテンション)のインターリーブ構成に混合精度格納(RoPE 次元 BF16 / その他 FP8)と FP4 インデクサ演算を組み合わせ、100 万トークンで BF16 GQA8 比約 2% の KV キャッシュサイズ、DeepSeek-V3.2 比 10%(Pro)に圧縮した。 - 関連: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]] が「KV Cache を設計の中心に据える」と述べた設計原則を、V4 はアーキテクチャレベルで KV キャッシュの絶対量を桁違いに削減することで問題構造そのものを変えている。PagedAttention / H₂O / StreamingLLM がメモリ管理・退避で対処するのに対し、V4 のアプローチは圧縮でキャッシュ量自体を減らす方向。 - **推論フレームワークの KV キャッシュ管理は、ハイブリッドアテンションにより PagedAttention の前提を覆した。** - 根拠: [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]] — PagedAttention(vLLM)は均質な KV キャッシュを仮想ページで管理するが、DeepSeek-V4 のハイブリッドアテンション(CSA / HCA / SWA の異種 KV エントリ)は層ごとにキャッシュサイズ・更新規則・ヒット/退避ポリシーが異なり、PagedAttention の基本仮定を破る。V4 はステートキャッシュ(SWA + 未圧縮テール)と圧縮 KV キャッシュの 2 系統を分離し、スパースアテンションカーネルと協調設計することでこの問題を解決した。さらにオンディスク KV キャッシュ(完全 SWA キャッシュ / 周期チェックポイント / ゼロ SWA キャッシュの 3 戦略)で共有プレフィックスの再プリフィルを回避する。 - 関連: [[Towards Efficient Generative Large Language Model Serving]]。 - **本番 KV キャッシュのワークロード特性は合成トレースの前提を覆す。** - 根拠: [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]] — Aliyun 本番トレースは理想ヒット率 to-C 62%/to-B 54%(合成 80% 超を大幅に下回る)、to-B の KV 再利用 97% がシングルターン起因(マルチターン支配仮定の反証)、KV ブロック寿命が指数分布にフィット(LFU 不適の根拠)を示した。ワークロード対応エビクションで LRU 比最大 41.4% の QTTFT 改善を達成。 - 関連: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]。合成ベンチマーク結果を本番の設計根拠に直接使えないことを実データで裏付けた。 - **RAG/マルチテナントでの非プリフィックス KV キャッシュ再利用は、選択的再計算の発展段階に入った。** - 根拠: [[@2025__EuroSys__CacheBlend - Fast Large Language Model Serving for RAG with Cached Knowledge Fusion]] — 非プリフィックスチャンクの KV 偏差が高い 10〜20% トークンの選択的再計算で TTFT 2.2〜3.3 倍削減を達成(EuroSys 2025 Best Paper)。 - 根拠: [[@2025__arXiv__KVShare - An LLM Service System with Efficient and Effective Multi-Tenant KV Cache Reuse]] — アテンション重み×KV 偏差の積で優先トークンを選ぶ DHD とデコードフェーズのアテンション・ドリフト対処で SOTA 比精度 20.38% 向上を示した。プリフィックスキャッシングの限界が RAG/エージェントワークロードで明確になり、「再利用可能な KV キャッシュの同定」と「偏差補正の範囲」が新しい設計軸として確立しつつある。 - **長コンテキスト手法の評価は KV キャッシュライフサイクル全体で行う必要がある。** - 根拠: [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]] — 既存ベンチマークが単一リクエスト評価に留まることを指摘し、KV キャッシュ生成・圧縮・検索・ローディングの 4 フェーズを共有コンテキストモードで評価する。sub-O(n) メモリ手法はマルチターン復号で破綻し、O(n) メモリ + 動的スパースアテンションが堅牢、レイヤーレベルのスパース性がメモリ効率と精度を両立するという知見を示した。これは推論フレームワークのベンチマークを「単一推論速度」から「キャッシュ再利用を含むライフサイクル性能」へ再定義する必要を示唆する。 - **長コンテキスト推論の高速化は、計算削減だけでなく「どこから KV を読むか」の問題へ移る。** - 根拠: [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]] — LMCache + NIXL は、長コンテキストで Prefill が TTFT を支配するため、一度作った KV キャッシュをリアルタイムに保存・共有する「You Only Prefill Once」の発想を前面に出す。VAST Storage を使った Qwen3-235B-A22B-Instruct-2507-fp8 / 8×H100 例では、ISL 224K 付近で KV 再計算の TTFT が約 36 秒に達するのに対し、ストレージから KV を取得する場合は約 4 秒弱に抑えられている。推論最適化の焦点は、アテンション計算を速くするだけでなく、HBM・ホストメモリ・ローカル SSD・ネットワークストレージのどこに KV を置き、どの転送抽象で読むかに広がる。 - **ハイブリッドアーキテクチャの推論実装では、KV キャッシュだけでなく再帰状態も一級の管理対象になる。** - 根拠: [[@2025__arXiv__PLaMo 2 Technical Report]] — PLaMo 2.0-31B の vLLM 実装では、通常の Transformer 前提の KV キャッシュ管理に加え、Mamba state を別機構で扱う必要がある。PLaMo 2 固有の Mamba 層は標準実装と異なり、causal conv1d と selective scan の間の線形射影、selective scan 後の RMSNorm 非搭載を持つためカスタム層が必要になった。これは、vLLM/PagedAttention 型の推論基盤がハイブリッドモデルへ拡張されると、アテンションの KV だけでなく状態空間モデル側の状態ライフサイクルも設計対象になることを示す。 - 関連: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]]。 - **本番 MaaS は「全リクエスト処理」を前提できず、過負荷指向スケジューリングが必要になる。** - 根拠: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]] — DistServe・P/D-Serve・SGLang はいずれも「十分な資源があれば全リクエストを処理できる」前提で効率化を論じるが、Mooncake は GPU 供給が制限的で常に過負荷になる商用 MaaS の現実から出発する。過負荷では「どのリクエストを受け入れるか」が「受け入れたリクエストをどう速く処理するか」と同等に重要な設計軸になり、PD 分離固有の時間差問題(Prefill 後に Decode が拒否)、Early Rejection 後の Prefill/Decode 間振動が新たな制御問題として生じる。予測ベース Early Rejection により基準比 14%(4183→3589 件拒否削減)の改善が得られた。 - **LLM インスタンスのコールドスタート時間がサービスレベル管理の設計原則を変える。** - 根拠: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]] — Azure 本番分析によると DeepSeek-R1(6,710 億パラメータ)のコールドスタートは数十〜数百秒に達する。このため「KPI 閾値超えで反応的スケールアップ」という従来のマイクロサービス管理が LMaaS では機能せず、10 分先読みの mLSTM ワークロード予測による先行インスタンス起動が不可欠になる。 - 関連: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]] が「過負荷受け入れ制御」で問題を設定するのに対し、PreServe は「先行プロビジョニング」で問題を回避する方向を取る——両者のアプローチは相補的だ。 - **リクエスト間の応答長ばらつきが、KV キャッシュ管理とロードバランシングの両方に波及する。** - 根拠: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]] — ShareGPT 分析では応答長が 5〜632 トークン(中央値 87)と約 126 倍の幅を持つ。短い応答はすぐに KV メモリを解放し次のリクエストを受け入れられるが、長い応答はインスタンスの KV メモリを長時間占有し実質的な並列可能数を減らす。 - 関連: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]] が KV キャッシュ断片化を解決しても残る問題であり、「どのインスタンスへ振り向けるか」というルーティング層でも応答長予測が必要な理由となる。 ## 通信最適化・アクセラレータ・エンジン選定 - **GPU 世代がサービング用途の並列スケール可否を決定する。** - 根拠: [[@2025__ペパボ研究所__gpt-ossモデルのサービング性能評価]] — [[三宅悠介]]([[GMOペパボ]] ペパボ研究所)による gpt-oss 評価は、H100 では並列数増加に伴って RPS が有意に向上する一方、A100/L4 では並列スケーリングがほとんど効かないことを示した。「推論は動く」と「サービング用途に使える」は異なる条件であり、**H100 以上がサービング実用の実質的な最低ライン**とされる。 - **Reasoning effort はモデルサイズと独立して出力レイテンシを決定する。** - 根拠: [[@2025__ペパボ研究所__gpt-ossモデルのサービング性能評価]] — gpt-oss の評価では、Reasoning effort を `high` に設定した場合の性能低下が、モデルサイズ切り替えより大きい場合があることが示された。モデルサイズ間の差は「2 倍以上にはならない」傾向に対し、**大規模モデル + medium effort が応答安定性の点で優位**。ISL/OSL プロファイル([[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]])上「推論タスク」(OSL≈1000〜10000)ではこの判断が特に重要になる。 - **IO-aware アテンションアルゴリズムが、推論のアテンション計算律速を世代横断で追跡・解消してきた。** - 根拠: [[@2022__arXiv__FlashAttention - Fast and Memory-Efficient Exact Attention with IO-Awareness]], [[@2023__arXiv__FlashAttention-2 - Faster Attention with Better Parallelism and Work Partitioning]], [[@2024__arXiv__FlashAttention-3 - Fast and Accurate Attention with Asynchrony and Low-precision]], [[@2026__arXiv__FlashAttention-4 - Algorithm and Kernel Pipelining Co-Design for Asymmetric Hardware Scaling]] — [[FlashAttention]] シリーズは GPU メモリ階層のボトルネックを世代ごとに特定して解消する。FA1(2022、A100)は N×N アテンション行列の HBM 読み書きをタイリング＋オンライン softmax で排除し 2-4 倍の高速化、FA2(2023)は非 MMA FLOP 削減とシーケンス長並列化で 225 TFLOP/秒(73% 利用率)、FA3(2024、H100)はワープ特化＋FP8 ブロック量子化で 740 TFLOP/秒(75%)、FA4(2026、B200)は非対称ハードウェアスケーリングの協調設計で 1613 TFLOP/秒(71%)を達成した。ボトルネックは「HBM 帯域 → 非 MMA 演算 → 指数関数ユニット」へと移動しており、推論の算術演算密度向上はハードウェア世代ごとの律速資源追跡に他ならない。 - 関連: [[Efficient Large Language Models - A Survey]] が FlashAttention を効率的アーキテクチャに位置づけたのは、アテンション計算のメモリ律速がモデル圧縮とは独立した最適化軸だからである。 - **クラウドネイティブ推論基盤は、Kubernetes の粗粒度管理と推論エンジンの細粒度制御のギャップを埋める。** - 根拠: [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]] — [[AIBrix]] は [[Kubernetes]](CRD / Service / Autoscaler)と [[Ray]](高性能タスク制御)のハイブリッド設計で、LLM 固有メトリクス(KV キャッシュ利用率等)に基づく second-level オートスケーリング、分散 KV キャッシュ(scan-resistant eviction)、LoRA 多重化、SLO 駆動 GPU 最適化を統合する。[[vLLM]]・[[SGLang]]・[[NVIDIA Dynamo]] 等の推論エンジンを vendor-neutral sidecar に収容し、効率化技術を組み合わせるオーケストレーション層として設計されている。分散 KV キャッシュ最適化で 50% スループット向上・70% レイテンシ削減を報告。 - 関連: [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]]。DistServe(research-first PD 分離)・NVIDIA Dynamo(full-stack hardware co-design)とは異なるクラウドネイティブ・アーキタイプとして、既存クラウドエコシステム(Istio・Prometheus・AWS EKS)との統合を前提とする。 - **推論専用フレームワーク群は、学習機能を持たないことで「サービング特化」の機能集合に収斂する。** - 根拠: [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]] — Table 2 は [[vLLM]]・[[TensorRT-LLM]]・[[Text-Generation-Inference (TGI)]]・[[RayLLM]]・MLC LLM・Sax・Mosec という 7 フレームワークが揃って Training・Fine-Tuning に非対応(Inference のみ対応)であることを示し、これらが PagedAttention・継続バッチング・量子化を共通基盤として共有しつつ、コンパイラ最適化(MLC LLM の TVM 基盤)・エコシステム統合(TensorRT-LLM の Triton、RayLLM の Ray、Sax の Pax/JAX/PyTorch マルチフレームワーク対応)で差別化するという分業構造を可視化する。 - 根拠: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]] — [[Netflix]] が TensorRT-LLM から vLLM へ移行した理由が性能でなく運用適合性だったのは、この「共通基盤+周辺差別化」という構造の下では機能差よりも運用要因がエンジン選定を支配しうることの一次事例と整合する。 - **エンジン選定は性能ベンチマークではなく運用適合性で決まる場合がある。** - 根拠: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]] — Netflix の本番事例は、TensorRT-LLM から vLLM への移行理由として、推論速度そのものではなく「カスタムモデルの多段階コンパイル不要」「カスタムデコード拡張フック」「デバッグ性」「研究本番間の移行コスト」を挙げた。 - 関連: GPU 世代がサービング可否を決める([[@2025__ペパボ研究所__gpt-ossモデルのサービング性能評価]])、Goodput が SLO 達成スループットを示す([[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]])といった既存の知見が主に定量的性能を扱うのに対し、エンジン選定という上流の意思決定が定性的な運用要因に支配されうることを示す一次事例である。 - **アクセラレータ選択とオフライン並列化戦略は、エネルギー効率とスループットのトレードオフを内包する。** - 根拠: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]] — データフローアクセラレータは小バッチ性能で GPU を圧倒するがエネルギー効率(tok/J)は低い(CS-3: 0.15 tok/J vs H100: 0.91 tok/J)。一方、GPU は W8A8 量子化と大バッチ運用でエネルギー効率を改善できる(H100 で FP8 により +47%)。同実測では、オフライン推論ではデータ並列(DP)がテンソル並列(TP)より高スループット・高エネルギー効率であることも示された。DP 構成が TP=2 比 20%・TP=4 比 32〜140% を上回る。TP は all-gather 通信オーバーヘッドでスケーリング効率が最大 60% 止まりだが、DP は ~100% のスケーリングを達成する。例外はモデル重みが GPU メモリの 80% 超を占める場合で、TP で KV キャッシュ領域を確保する必要がある。 - 関連: この DP/TP の知見は [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]] が Prefill/Decode に最適な並列化を段階別に選ぶべきと論じた方向性を裏付ける。また「推論コスト最適化は信頼性低下として現れる場合がある」([[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]])という観点と組み合わせると、エネルギー制約下でのアクセラレータ選択が品質劣化リスクも含む多軸問題になることを示す。 - **電力制約下の LLM 推論は、リクエストルーティングと KV キャッシュ配置を同時に扱う。** - 根拠: [[@2026__arXiv__XWind - A Cross-site Router for Large Language Model Inference Serving at Renewable Energy Farms]] — [[XWind]] は再生可能エネルギーサイトの可変電力に合わせて LLM 推論リクエストをクロスサイトルーティングする。 - 根拠: [[@2025__MPLSJapan__A study on accelerating LLM inference using KV cache sharing with IOWN APN]] — 田仲顕至の MPLS JAPAN 2025 資料は、小規模データセンターを再生可能電源近傍にも分散配置し、[[IOWN APN]] でリクエストルーティングと KV キャッシュ共有を行う構想を示す。両者を並べると、電力インフラ制約下の推論基盤では「どこで計算するか」と「どこに KV キャッシュを置くか」が分離できない制御問題になる。 - **長文脈・小バッチのデコードでは、集合通信のマイクロ秒単位のレイテンシがトークン生成のクリティカルパスを直接支配する。** - 根拠: [[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]] — テンソル並列(TP)デコードの各ステップに埋め込まれた AllReduce が、長文脈でバッチサイズが KV キャッシュ容量制約により縮小されるほど支配的なボトルネックになる(帯域ではなくレイテンシが律速)ことを実測で示す。GB200 の barrier-free 低レイテンシ AllReduce カーネルにより inter-token latency(ITL)を Llama-3.1-70B で最大 13%・DeepSeek-V3 で 11.4% 削減し、出力 100 万トークンあたり $11 超のコスト削減を推定した。 - 関連: 既存の LLM 推論最適化(PagedAttention のメモリ管理、chunked-prefill のスケジューリング、PD 分離のリソース分離)がいずれも GPU 内のメモリ・スケジューリングを対象にするのに対し、本研究は GPU 間通信そのものの物理下限(Speed-of-Light)に迫るという異なるレイヤーの最適化軸を提示する。 - **テンソル並列推論の通信最適化は decode 側と prefill 側で異なる技術が必要であり、TokenWeave はトークンレベルの計算-通信オーバーラップでこれを実用化する。** - 根拠: [[@2025__arXiv__TokenWeave - Efficient Compute-Communication Overlap for Distributed LLM Inference]] — [[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]] が barrier-free カーネルで AllReduce 単体のレイテンシを Speed-of-Light 下限近くまで削るのに対し、TokenWeave は AllReduce を RMSNorm と融合しつつ計算とオーバーラップさせることで通信そのものを「隠す」方向を取る。実運用では decode-only の小バッチ(前者が有効)と prefill-only/hybrid の中規模バッチ(後者が有効)で使い分ける余地があり、TokenWeave 自身も disaggregated serving で decode には融合カーネル単体、prefill にはフル overlap を推奨する。 - 根拠: 既存の tile-level 融合手法(Flux・TileLink)は GEMM 限定・RS/AG 分割オーバーヘッド・小粒度通信の非効率という 3 つの構造的限界を持つが、TokenWeave は通信オーバーラップの粒度をトークンレベルへ引き上げることでこれを同時に解消する。Attention のような非 GEMM 演算もオーバーラップ対象にでき、AllReduce を RS+AG に分割せず単一融合カーネルに保つことで分割オーバーヘッドを避け、大きな単一 AllReduce を維持することで小粒度通信の帯域劣化も回避する。TileLink が小トークン域(1K)でネット悪化するのに対し TokenWeave が同域で 1.20 倍を達成する(Figure 14)という定量差は、粒度選択(tile vs token)が通信オーバーラップの適用可能範囲を直接左右することを示す。vLLM V1 実装で最大 1.28 倍のレイテンシ改善を達成した。 - **マルチテナント推論では、メモリ容量制約と計算共有制約を別々に最適化する必要がある。** - 根拠: [[@2026__SIGCOMM__DynamoServe - A Distributed Tiered Memory System for Multi-tenant LLM Serving|DynamoServe]] — NVLink ピア GPU の遊休 HBM をプールしてテンソル並列や CPU オフロードを回避しつつ、NVIDIA MPS のプロファイリング誘導 SM 割当で CNN と LLM をコロケーションする。メモリ集約型 LLM と計算集約型 CNN が同一 GPU で非対称なリソース需要を持つ場合、メモリ階層最適化(LMCache/Mooncake 系)と GPU 共有最適化(MPS/MIG 系)は独立した設計軸であり、統合コントローラが両方を同時に扱う必要がある。 ## 未解決の問い - 推論ステップの動的ルーフラインと演算子レベル PMC を同一の本番診断パイプラインへ統合した場合、追加オーバーヘッドと診断精度はどの程度変化するか。 - DeepSeek-V4 の圧縮アテンション（CSA / HCA）は KV キャッシュサイズを劇的に削減するが、圧縮による情報損失が長コンテキスト検索精度にどの程度影響するか（MRCR 1M で Claude Opus 4.6 の 92.9% に対し 83.5%）。圧縮率と検索精度のパレートフロンティアはどこにあるか。 - DeepSeek-V4 のオンディスク KV キャッシュ 3 戦略（完全/周期/ゼロ SWA キャッシュ）の最適な切り替え基準は、ISL/OSL プロファイルや共有プレフィックスの比率にどう依存するか。 - エッジ(ProfInfer)で得た段階別・演算子別の知見は、サーバ/大規模モデル(eInfer・NCCLX)へどこまで外挿できるか。 - speculative decoding や継続バッチングなど、さらに動的な実行に演算子レベル観測を一般化できるか。 - 推論の GPU 常駐コレクティブ(NCCLX の AllToAllvDynamic)は AllToAllv 以外の操作にも広げられるか。 - RTX 5080 の TensorRT における FP4/FP8 の電力・スループット・品質を、H100/B200 など同一モデルの条件で比較したとき、推論設定の選択を決める最小の測定指標集合は何か。 - Miao+ が指摘するリカレントユニット(RWKV・RetNet・状態空間モデル)は Transformer を完全に代替できるか。特に長シーケンスでの品質比較が不足している。 - Prefill-Decode 分離アーキテクチャ(Splitwise・DistServe)の最適な分離粒度と、弾性的シーケンス並列(LoongServe)との統合はどこまで進んでいるか。 - 包括的で再現可能な LLM サービングベンチマーク（モデル構成×ハードウェア×リクエスト負荷の全組み合わせ）は依然として未確立。 - KV Cache の転送帯域(GB オーダー)が PD 分離の律速になるという道下の指摘に対し、NIXL や LMCache は単一資料上ではストレージ取得による TTFT 改善を示すが、マルチテナント負荷、tail latency、障害時再送まで含めるとどこまで緩和できるか。 - リモート KV Cache Reuse/Sharing で完全ヒット近傍でも読み込みコストが TTFT の約 1/4 を占める要因は何か。Mooncake Store、LMCache、ネットワーク、vLLM 側のどの層が支配的か。 - RAG やエージェント型ワークロードでは Prefix の前方一致性が崩れやすい。CacheBlend のような技術は、TTFT 改善とキャッシュ読み込みコストのどちらにどの程度効くか。 - DistServe は FCFS を採用し、高度なプリエンプションや耐障害性を実装していない。Decode インスタンスが複数 Prefill インスタンスに対応する構成で、障害波及をどう局所化するか。 - PreServe の KV メモリ使用率先読みマップは 100 イテレーション先を予測するが、DistilBERT による応答長予測に最大 APE 24.4% の誤差がある。動的な誤差補正(予測短縮時の減算・予測超過時の仮想延長)は残差をどこまで吸収できるか。実際の KV キャッシュ枯渇発生率との定量的な関係は未報告。 - LMaaS インスタンスのオートスケーリングと推論エンジン内の PD 分離(DistServe 方式)を同時に使う場合、「スケールの単位」が Prefill インスタンス/Decode インスタンス/完全インスタンスの 3 通りになる。どの粒度でスケールを判断するのが最適か。 - INLG 2025 サーベイが挙げる「小型 LLM で大型 LLM 推論基盤を最適化する」方向は、配置・スケジューリング・ストレージ管理をどこまで安全に自動化できるか。 - XWind が示した「KV キャッシュ利用率を電力制御シグナルとして使う」設計は、vLLM 等の推論フレームワークがテレメトリ API を標準化すれば電力管理との統合がより容易になる可能性がある。そのような標準化の議論はあるか？ - DSA([[@2025__arXiv__DeepSeek-V3.2 - Pushing the Frontier of Open Large Language Models]])のライトニングインデクサは O(L²) を維持するが主アテンションより大幅に軽い。インデクサ自体をさらに疎化・近似する設計は可能か。また DSA の top-k 選択がエージェント型ワークフロー（ツールコール履歴の参照パターン）でどの程度有効かは未検証。 - 可変再生可能エネルギー下での LLM 推論サービングは「電力バジェット制約下での推論 SLO 維持」という新たな制御問題を生む。[[XWind]]（[[@2026__arXiv__XWind - A Cross-site Router for Large Language Model Inference Serving at Renewable Energy Farms]]）は KV キャッシュ利用率（先行指標）と TBT（遅行指標）をデュアルシグナルとして使うサイトローカルコントローラで、オフラインプロファイリング不要のワークロード非依存設計を実現した。KV キャッシュ利用率が周波数しきい値以下で急増し TBT 劣化に先行するという特性（O3）は、推論フレームワーク内部の性能特性が電力制御シグナルとして使えることを示す点で、電力・性能の統合制御という新しい設計軸を開く。（Source: [[@2026__arXiv__XWind - A Cross-site Router for Large Language Model Inference Serving at Renewable Energy Farms]]） - コスト起因劣化を防ぐには、Goodput や TTFT/ITL の SLO に加えて、出力の意味的品質、再現性、フォーマット安定性、ツール呼び出し成功率を同じ制御ループで扱う必要がある。推論システムの標準ベンチマークは、どのように費用、レイテンシ、品質劣化を同時評価できるか。 - KV キャッシュの page/chunk/object 粒度を、自動的にワークロード、ネットワーク、ストレージ、モデル構成へ適応させる制御ループは作れるか。 - Mamba state と KV キャッシュを同時に持つハイブリッドモデルでは、PagedAttention 的なページ化・退避・再利用を状態空間モデル側へどう拡張すべきか。 - SGLang 型の LM プログラム構造、LMCache 型の階層ストレージ、P/D-Serve 型の scenario group を同時に使う場合、cache hit、fairness、SLO、tenant isolation の目的関数はどう定義すべきか。 - P/D-Serve が示す「pending tokens や SSE connection では Prefill 状態が分からない」問題に対し、推論基盤はどのテレメトリ API を標準化すべきか。 - IOWN APN のような広域低遅延ネットワークを使う場合、KV キャッシュヒット率、ネットワーク距離、電力価格/電源種別、データ所在制約を同時に考慮するルーターはどの目的関数で設計すべきか。 - AMD/Intel GPU は vLLM のソフトウェア成熟度差により NVIDIA 比で性能が大きく劣る。このギャップはソフトウェアで埋まるのか、それともハードウェアアーキテクチャの差か。特に AMD MI300X の 192 GB VRAM を活かすには vLLM の統合メモリサポートが必要だが、現時点では未実装。 - データフローアクセラレータのバッチサイズ固定制約(プリコンパイル)は動的バッチング要求と相容れない。TTFT 起因のバッチ崩れを防ぐ推論システム設計はどうあるべきか。 - エネルギー効率の比較に電力測定粒度の差(NVIDIA: 0.5秒, Intel: 1.9秒, Cerebras: 系統レベル)がどの程度影響するか。統一的な電力測定フレームワークは存在するか。 - Niyama のハイブリッド優先度付けパラメータ α は静的な deployment パラメータとして評価されている。負荷変動に応じて α を自動調整する仕組みは有効か。また non-interactive リクエストの decode 長予測(過去統計 + 標準偏差 2 個分の上振れ)の予測誤差はどの程度で、KV メモリ枯渇率にどう影響するか。 - Niyama のような同一レプリカ co-scheduling(QoS 差別化)と DistServe のような Prefill/Decode 物理分離は、直接比較評価されていない。同一ワークロード・同一 GPU 予算で両アプローチを比較した場合、どちらが Goodput・コストの両面で優れるか。マルチレプリカ環境で両者を組み合わせる設計(分離した Prefill プール内で QoS co-scheduling を行う等)は可能か。 - BatchLLM のオフライン・大規模バッチ前提の最適化(グローバル prefix 事前識別、prefix-sharing グループ単位のスケジューリング)を、リクエストが継続的に到着するオンラインストリーミング環境やハイブリッド(バッチ+ストリーミング混在)環境へどう適応させられるか。著者は動的なモード切替を将来課題として挙げているが具体的な設計は示していない。 - TokenWeave の smart-splitting はオフラインプロファイリングで split offset を事前計算するが、モデルアーキテクチャ(Attention 変種・MoE ルーティング等)や GPU 世代が変わるたびに再プロファイリングが必要になる。Every Microsecond Matters の Speed-of-Light 下限のような解析的モデルと統合し、split offset をプロファイリングなしで導出できないか。また TokenWeave は disaggregated serving で decode に融合カーネル単体・prefill にフル overlap を使い分けると提案するが、この住み分けを動的に(負荷やバッチ形状に応じて)切り替える設計は検証されていない。 - Wan+ の「介入点による3分類(モデル・データ・フレームワーク)」、Miao+ の「アルゴリズム/システム2軸」、Zhou+ の「data/model/system 3層」という3つの異なる taxonomy を統合するメタ分類は存在するか。同じ手法(例: efficient inference)が複数の taxonomy でどう対応づくかを整理すれば、サーベイ横断での手法比較が容易になる可能性がある。 - 推論専用フレームワーク 7 種(vLLM・TensorRT-LLM・TGI・RayLLM・MLC LLM・Sax・Mosec)のうち、コンパイラベース最適化(MLC LLM の TVM)とランタイムスケジューリング最適化(vLLM の PagedAttention・継続バッチング)のどちらが長期的に優勢になるか。本サーベイの機能比較(2024 年 5 月時点)以降、vLLM が事実上の標準になりつつある([[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]] 等の移行事例)動きは、この設問にどう答えるか。 - Zhou+ の first/per-output token latency と NVIDIA・道下の TTFT/TPOT/ITL/E2EL/Goodput の間には、用語だけでなく計算方法の差異(ITL が TTFT を含むか等)が存在しうる。両者の指標体系を正式に対応づけるマッピング表は作れるか。また Zhou+ が2024年時点で示した8指標体系(first/per-output token latency・generation latency・token/request throughput・model size・KV cache size・peak memory)は、2025〜2026年の Goodput・SLO 志向の指標体系(TTFT/ITL の SLO 制約付きスループット)へどのように拡張されたと整理できるか。 ## 未編纂の観察 > [!note]- 編纂前の観察 2026-09 > - **Prefill=計算バウンド/Decode=メモリバウンドの段階差が観測の基本軸**: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] はオンデバイス推論で「このワークロードはメモリバウンドか計算バウンドか」という問いに演算子レベル PMC で答え、Decode の行列ベクトル乗算では CPU サイクルの 50% 超(4 スレッドで 80% 超)が stall するメモリ帯域ボトルネックを示す。フェーズごとに律速資源が変わることが、推論最適化と観測設計の出発点になる。(Source: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) > - **ボトルネックは「帯域」と思われがちだが実際は別所にあることが多い**: ProfInfer は MoE のボトルネックがメモリ帯域でなく**ディスク I/O**(evict されたエキスパートの fetch)だと結論し、[[@2025__arXiv__Collective Communication for 100k+ GPUs]] は推論のボトルネックが帯域でなく **CPU 準備オーバーヘッド**や CUDA Graph 由来のパディングだと特定する。細粒度観測は「帯域が足りない」という素朴な見立てを反証する点で価値を持つ。(Source: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]]) > > - **推論最適化は、モデル・GPU・ネットワークの単一層でなく要求からカーネルまでの統合分析を要する**: [[Zoomer]] は推論要求レート、サーバーレイテンシ、アクティブ要求、GPU メモリ割り当て、サービングパラメータを [[Crochet]] と Thrift リクエストプロファイリングで取得し、[[Kineto]]／PyTorch Profiler のカーネル・メモリ転送トレースや [[Dynolog]] のホストメトリクスと合わせて分析する。単一 GPU の細粒度プロファイリングを扱う [[ProfInfer]]・[[eInfer]] に対し、Zoomer は要求単位の QPS 最適化と自動負荷試験まで含む本番運用ループを示す。(Source: [[@2025__EngineeringAtMeta__Zoomer - Powering AI Performance at Meta's Scale Through Intelligent Debugging and Optimization]]) > - **同じ LLM 推論でもスケールで観測対象が変わる**: eInfer・NCCLX はサーバ/分散規模で CPU・GPU・ネットワーク・ノード横断のリクエスト追跡や GPU 常駐コレクティブを扱い、ProfInfer はエッジ(Orange Pi・Rubik Pi)で演算子オフロード・スレッド偏り・干渉タスクを扱う。スケールの違いがボトルネックの所在(通信か・I/O か・スレッド偏りか)を変える。(Source: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) > - **MoE ルーティングが観測の難所として共通する**: eInfer は MoE のルーティング挙動と通信ボトルネックを、ProfInfer は活性化エキスパート ID と「距離」(前回活性化からのトークン距離)を追跡する。動的にエキスパートが選ばれる MoE は静的なグラフ解析では捉えられず、実行時計装の主対象になる([[Mixture-of-Experts]])。(Source: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) > - **LLM 推論効率化はアルゴリズムレベルとシステムレベルの二重構造をなす**: [[Efficient Large Language Models - A Survey]] は推論最適化をアルゴリズムレベル（投機的復号、KV キャッシュ最適化）とシステムレベル（FlexGen、Orca、vLLM、DeepSpeed-Inference、Flash-Decoding）に二分する。投機的復号は小型ドラフトモデルから木構造候補を生成し棄却サンプリングで品質を保持する唯一の手法であり、SpecInfer（トークン木検証）・Medusa（追加ヘッド方式）・BiLD（フォールバック/ロールバック方策）の 3 設計が立つ。KV キャッシュ最適化は圧縮系（KIVI: 2 ビット量子化でピークメモリ 2.6 倍削減）と退避系（H₂O: 動的劣モジュラ退避、StreamingLLM: アテンションシンク+ウィンドウで一定メモリの無限系列長）に分かれる。システムレベルでは Orca の反復レベルスケジューリング（FasterTransformer 比 36.9 倍スループット）から vLLM の PagedAttention（2–4 倍スループット）へ、メモリ管理の OS 的仮想化が進む。Miao+ のサービングサーベイ [[Towards Efficient Generative Large Language Model Serving]] が推論フレームワーク 10 種の横断比較に特化するのに対し、Wan+ は推論をモデル圧縮・効率的アーキテクチャ（FlashAttention、MoE、状態空間モデル）を含むモデル中心手法全体の一部として位置づけ、より広い文脈で推論最適化を整理する。(Source: [[Efficient Large Language Models - A Survey]], [[Towards Efficient Generative Large Language Model Serving]]) > - **モデル圧縮が推論効率化の前段として機能し、両者は直列に組み合わさる**: [[Efficient Large Language Models - A Survey]] は[[モデル圧縮]]（量子化・プルーニング・低ランク近似・知識蒸留）を推論とは独立のセクションで扱うが、実際にはモデル圧縮後のモデルが推論パイプラインに投入される。PTQ の重み限定量子化（GPTQ: 175B を 3–4 ビット化）と KV キャッシュ量子化（KIVI: 2 ビット）は推論のメモリ律速を異なるレイヤーで緩和する。この直列最適化の実効性は FlexGen が「重み+KV キャッシュの 4 ビット量子化で OPT-175B を単一 16GB GPU で推論」した例で示される。(Source: [[Efficient Large Language Models - A Survey]]) > - **低レイテンシと高スループットは双対最適化目標であり、同時最適化は原理的に困難**: Miao+ のサーベイはサービングシステム 10 種を横断比較し、FlexFlow-Serve は SpecInfer による投機的復号でレイテンシに特化し、vLLM はページドアテンションによる KV キャッシュ効率化でスループットに特化するという設計の分岐を明示した。ProfInfer が示す Prefill=計算バウンド/Decode=メモリバウンドのフェーズ差は、この双対性の物理的根拠と一致する——Prefill の高速化(TTFT 削減)とバッチ効率(スループット)は異なる資源を律速とするため。(Source: [[Towards Efficient Generative Large Language Model Serving]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) > - **投機的復号は出力品質を保持できる唯一のアルゴリズム的高速化手法**: Miao+ は非自己回帰復号・早期脱出・カスケード推論がいずれも品質劣化を伴うのに対し、投機的復号は木構造検証で LLM の出力分布を保存することを示す。eInfer が分散推論で speculative decoding のトレース可能性を問うのは、この品質保証前提を運用で検証する必要があるからだ。(Source: [[Towards Efficient Generative Large Language Model Serving]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) > - **Goodput は SLO 達成スループットを示す実用的指標**: 生のスループット(TPS/RPS)は SLO を無視した指標だが、実際の運用では TTFT・ITL の制約が満たせないリクエストは実質的に無効になる。道下幹也の解説([[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]])では、秒間 10 RPS のシステムが TTFT 200 ms 以下・ITL 50 ms 以下の SLO 制約により Goodput が 3 RPS まで低下する例を示している。Goodput は「SLO を満たすスループット」として設計の評価指標に据える必要がある([[サービスレベル目標]])。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) > - **PD 分離はテイルレイテンシを改善するが KV Cache 転送がボトルネックになる**: Prefill ノードと Decode ノードを物理分離すると ITL のテイルレイテンシが改善されるが、GB オーダーの KV Cache をノード間で転送する必要が生じる(Llama-3.1-405B で入力 8k トークン時に約 4 GB/リクエスト)。100 並行リクエスト時の転送は高速ネットワーク(400 Gbps NIC + GPUDirect RDMA)なしには成立しない。「KV Cache を設計の中心に据える」ことが分散推論基盤の定石とされる理由がここにある。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) > - **ユースケースの ISL/OSL プロファイルがベンチマーク設計の前提となる**: NVIDIA の公式解説([[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]])は、翻訳（ISL≈OSL≈500〜2000）・生成（ISL≈100、OSL≈1000）・要約（ISL≈1000、OSL≈100）・推論（ISL≈100、OSL≈1000〜10000）の 4 パターンを定義する。同じハードウェアとモデルでも ISL/OSL 比が変わればベンチマーク結果は大きく変わるため、実用目的に合わせたプロファイル選択が不可欠。(Source: [[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]]) > - **ITL・TPS の計算方法はツール間で異なり、直接比較には正規化が必要**: Kazuki Fujii の解説([[@2026__Zenn__MLエンジニアのための本質から理解するLLM推論]])および NVIDIA の公式ドキュメントが共通して指摘する。具体的には [[GenAI-Perf]] の ITL は TTFT を含まないが、LLMPerf は含む。TPS の分母定義もツールにより異なる。(Source: [[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]], [[@2026__Zenn__MLエンジニアのための本質から理解するLLM推論]]) > - **スパースアテンションが MoE + MLA アーキテクチャの推論コストを長コンテキストで大幅に削減する**: [[@2025__arXiv__DeepSeek-V3.2 - Pushing the Frontier of Open Large Language Models]] の DeepSeek Sparse Attention(DSA)は、ライトニングインデクサ（FP8・ReLU 活性化の軽量モジュール）でトークン間の関連度をスコアリングし、top-k のキーバリューエントリのみにアテンションを適用することでコアアテンション複雑度を O(L²) から O(Lk) に削減する。128K コンテキストでプリフィルコストが DeepSeek-V3.1-Terminus の約 1/4 に低下し、デコードコストも同様に削減される。ProfInfer が Prefill=計算バウンド/Decode=メモリバウンドのフェーズ差を示したのに対し、DSA は Prefill の計算バウンドを構造的に緩和するアーキテクチャ的解である。短系列ではマスク付き MHA モードで DSA をシミュレートし効率を維持する点で、系列長に応じた推論戦略の動的切替が実装レベルで実現されている。(Source: [[@2025__arXiv__DeepSeek-V3.2 - Pushing the Frontier of Open Large Language Models]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) > > - **ハイブリッド圧縮アテンションが KV キャッシュ問題を構造的に解決し、100 万トークンコンテキスト推論を実用化した**: KV キャッシュの肥大化は長コンテキスト推論の中心課題であるが、[[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]] は CSA（4 トークン→1 圧縮 + top-k スパース選択）と HCA（128 トークン→1 高圧縮 + 密アテンション）のインターリーブ構成に混合精度格納（RoPE 次元 BF16 / その他 FP8）と FP4 インデクサ演算を組み合わせ、100 万トークンで BF16 GQA8 比約 2% の KV キャッシュサイズ、DeepSeek-V3.2 比 10%（Pro）に圧縮した。道下([[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]])が「KV Cache を設計の中心に据える」と述べた設計原則を、V4 はアーキテクチャレベルで KV キャッシュの絶対量を桁違いに削減することで問題構造そのものを変えている。PagedAttention / H₂O / StreamingLLM がメモリ管理・退避で対処するのに対し、V4 のアプローチは圧縮でキャッシュ量自体を減らす方向。(Source: [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]], [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) > - **推論フレームワークの KV キャッシュ管理はハイブリッドアテンションにより PagedAttention の前提を覆した**: PagedAttention（vLLM）は均質な KV キャッシュを仮想ページで管理するが、DeepSeek-V4 のハイブリッドアテンション（CSA / HCA / SWA の異種 KV エントリ）は層ごとにキャッシュサイズ・更新規則・ヒット/退避ポリシーが異なり、PagedAttention の基本仮定を破る。V4 はステートキャッシュ（SWA + 未圧縮テール）と圧縮 KV キャッシュの 2 系統を分離し、スパースアテンションカーネルと協調設計することでこの問題を解決した。さらにオンディスク KV キャッシュ（完全 SWA キャッシュ / 周期チェックポイント / ゼロ SWA キャッシュの 3 戦略）で共有プレフィックスの再プリフィルを回避する。(Source: [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]], [[Towards Efficient Generative Large Language Model Serving]]) > - **本番 LLM の品質劣化はルーティング・推論設定・コンパイラの 3 層で独立して発生しうる**: [[Anthropic]] の 2025 年 8〜9 月の 3 件の障害事例（[[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]]）は、同一の「出力品質低下」という症状が (1) コンテキストウィンドウのサーバールーティングエラー、(2) TPU サーバーの誤設定によるトークン生成エラー、(3) XLA:TPU コンパイラの混合精度演算バグ、という全く異なる層に起因しうることを示す。これは [[ICSE 2026|@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] が定量化した「症状と根本原因の多対多関係」を、LLM 推論システムの具体例として裏付ける。(Source: [[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]]) > - **近似 top-k と厳密 top-k の精度不一致がトークン選択を変化させる可能性がある**: Anthropic の XLA:TPU コンパイラバグ事例では、混合精度（異なる浮動小数点精度で動作する演算間）のトークン確率計算が不一致を起こしトークン選択に影響した。修正は近似的 top-k から厳密な top-k への切り替えと精度処理の標準化だった。LLM 推論における数値精度の差異が出力に与える影響は、モデル評価の文脈ではほとんど考慮されない。(Source: [[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]]) > - **推論コスト最適化は信頼性低下として現れる場合がある**: [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] は、短いコンテキストウィンドウ、小型モデルへの切り替え、低サンプリング、積極的なキャッシュ利用などのコスト制約が、サービスエラーを出さずに推論品質を劣化させる失敗モードを「コスト起因劣化」として扱う。これは本ページで扱ってきた TTFT/ITL/Goodput や KV キャッシュ最適化の効率指標に、意味的正しさと安定性の制約を重ねる必要があることを示す。(Source: [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]], [[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]], [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) > > - **GPU 世代がサービング用途の並列スケール可否を決定する**: [[三宅悠介]]（[[GMOペパボ]] ペパボ研究所）による gpt-oss 評価([[@2025__ペパボ研究所__gpt-ossモデルのサービング性能評価]])は、H100 では並列数増加に伴って RPS が有意に向上する一方、A100/L4 では並列スケーリングがほとんど効かないことを示した。「推論は動く」と「サービング用途に使える」は異なる条件であり、**H100 以上がサービング実用の実質的な最低ライン**とされる。(Source: [[@2025__ペパボ研究所__gpt-ossモデルのサービング性能評価]]) > - **Reasoning effort はモデルサイズと独立して出力レイテンシを決定する**: gpt-oss の評価では、Reasoning effort を `high` に設定した場合の性能低下が、モデルサイズ切り替えより大きい場合があることが示された。モデルサイズ間の差は「2 倍以上にはならない」傾向に対し、**大規模モデル + medium effort が応答安定性の点で優位**。ISL/OSL プロファイル([[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]])上「推論タスク」(OSL≈1000〜10000)ではこの判断が特に重要になる。(Source: [[@2025__ペパボ研究所__gpt-ossモデルのサービング性能評価]]) > - **PD 分離は「同じ GPU 枚数での役割分割」としても ITL テイルを改善しうる**: さくらのナレッジ vol.3 は H100 HGX の PD 分離検証を詳細化し、今回の SpeakerDeck は同じ論点を SLO ベース最適化の文脈に置き直す。入力 8k・出力 1k・4 GPU 条件では、32 同時接続で Aggregated が ITL P99 100 ms 以内に収まらない一方、PD 分離は 30 ms 以内に収まる。これは「GPU を増やす」だけでなく「Prefill と Decode のリソースを分ける」こと自体が SLO 達成に効くことを示す。(Source: [[@2026__さくらのナレッジ__高火力PHYを利用した分散推論基盤の性能検証]], [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]]) > - **KV Cache Reuse は TTFT を下げるが、Prefix 構造とストレージ読み込みコストに制約される**: DeepSeek-V4 はオンディスク KV キャッシュで共有プレフィックス再プリフィルを避ける方向を示し、今回の SpeakerDeck は Mooncake Store を用いたリモート KV Cache Reuse/Sharing で、8k 入力のキャッシュヒット量を増やすほど TTFT が最大 1.75 倍程度削減されることを実測した。一方で、完全ヒット近傍でも KV Cache 読み込みが TTFT の約 1/4 を占める観察があり、KV Cache は「再計算を避ける」だけでなく「読み込みをどう安くするか」が制御対象になる。(Source: [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]], [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]]) > - **DistServe は PD 分離を Goodput 最適化として定式化した一次論文である**: DistServe は Prefill と Decode の同居が TTFT/TPOT 干渉と資源・並列化結合を生むことを示し、段階別の GPU 割当・テンソル並列・パイプライン並列探索で per-GPU Goodput を最大化する。vLLM 比でチャット 2.0〜4.6 倍、コード補完 5.7 倍、要約 4.3 倍のリクエスト率を達成し、DeepSpeed-MII 比では最大 7.4 倍高いリクエスト率を示した。これは従来の「PD 分離は KV キャッシュ転送が難点」という議論に対し、配置制約とノード内 NVLINK を使えば OPT-175B でも転送を総レイテンシ 0.1% 未満に抑えられることを示す。(Source: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]], [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) > - **2025 年時点の推論サービングサーベイは、単一フレームワーク比較から新興シナリオの運用問題へ広がった**: Miao+ CSUR はアルゴリズム/システムの 2 軸で効率化を整理したが、Zhen+ INLG はモデル配置・スケジューリング・KV キャッシュ・PD 分離・マルチプレクシングをインスタンス内軸、異種 GPU 配置・ロードバランシング・クラウド/エッジ協調をクラスタ軸、長コンテキスト/RAG/MoE/LoRA/投機的復号/エージェント/マルチモーダルを新興シナリオ軸として整理する。推論サービングは「単一モデルを速く動かす」段階から「複数段階・複数モダリティ・外部ツールを SLO 下で調停する」段階へ移っている。(Source: [[Towards Efficient Generative Large Language Model Serving]], [[@2025__INLG__Taming the Titans - A Survey of Efficient LLM Inference Serving]]) > - **KV キャッシュが LLM 推論システムの共通制御対象になった**: vLLM/PagedAttention は KV キャッシュを GPU 内のページ化メモリとして管理し、SGLang/RadixAttention は prefix 木として再利用し、LMCache は GPU 外の階層ストレージと推論エンジン間転送対象にし、P/D-Serve は RoCE 上の D2D 転送を本番 MLOps に組み込む。LLM 推論最適化は attention kernel だけでなく、KV キャッシュの配置・転送・共有・退避・ルーティングをどう制御するかへ広がった。(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]]) > - **電力制約下の LLM 推論は、リクエストルーティングと KV キャッシュ配置を同時に扱う**: XWind は再生可能エネルギーサイトの可変電力に合わせて LLM 推論リクエストをクロスサイトルーティングする。一方、田仲顕至の MPLS JAPAN 2025 資料は、小規模データセンターを再生可能電源近傍にも分散配置し、[[IOWN APN]] でリクエストルーティングと KV キャッシュ共有を行う構想を示す。両者を並べると、電力インフラ制約下の推論基盤では「どこで計算するか」と「どこに KV キャッシュを置くか」が分離できない制御問題になる。(Source: [[@2026__arXiv__XWind - A Cross-site Router for Large Language Model Inference Serving at Renewable Energy Farms]], [[@2025__MPLSJapan__A study on accelerating LLM inference using KV cache sharing with IOWN APN]]) > - **2024 年型の三層タクソノミーは、2025 年型の分離・永続化・cache-aware orchestration で拡張される**: Zhou+ のサーベイは LLM 推論効率化を data-level、model-level、system-level に整理し、system-level を推論エンジン、offloading、投機的復号、メモリ管理、バッチング、スケジューリング、分散システムへ分ける。今回の PagedAttention、SGLang、LMCache、P/D-Serve を並べると、この system-level の中で「KV キャッシュ管理」が独立した横断軸として成長し、単一エンジン内メモリ管理から分離型クラスタのデータプレーンへ拡張したことが分かる。(Source: [[A Survey on Efficient Inference for Large Language Models]], [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]]) > - **Structured LM programs は推論サービングのキャッシュ単位を「リクエスト」から「プログラム構造」へ変える**: SGLang は ReAct、Tree-of-Thought、Skeleton-of-Thought、LLM judge、RAG、multi-turn chat を、複数 generation call と制御フローを持つ LM プログラムとして扱う。RadixAttention は `fork` や共通 system prompt から prefix 木を作り、cache-aware scheduling で平均 96% の最適 hit rate に近づく。これは、LLM 推論の効率化単位が単一 API request ではなく、アプリケーションワークフロー全体へ移ることを示す。(Source: [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]]) > - **本番規模の分離型推論では、scheduler の観測信号そのものが不完全になる**: P/D-Serve は Prefill queue の pending token 数や SSE connection 数が実 TTFT を十分に説明しないと述べる。Prefix hit ratio、batch size、scenario ごとの prompt 分布が Prefill 能力を変えるため、グローバルスケジューラだけでは idle Prefill を正確に把握できない。これは [[GPU観測性]] や [[LLM学習モニタリング]] と同様、推論サービングでも「正しい制御信号をどう観測するか」が設計問題になることを示す。(Source: [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]]) > - **LLM 推論の発展史は attention 最適化から disaggregation へ読めるが、一次根拠は個別システム論文で補強すべきである**: Aravilli+ は KV Cache、FlashAttention、Continuous Batching、Speculative Decoding、PagedAttention、RadixAttention を、分離型推論へ向かう発展線として整理する。この視点は有用だが、CAP 定理などの説明は比喩として注記されているため、性能・実装根拠は vLLM、SGLang、LMCache、P/D-Serve、DistServe の各論文へ遡る必要がある。(Source: [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]], [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]], [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]]) > - **本番 MaaS は「全リクエスト処理」を前提できず、過負荷指向スケジューリングが必要になる**: DistServe・P/D-Serve・SGLang はいずれも「十分な資源があれば全リクエストを処理できる」前提で効率化を論じるが、Mooncake は GPU 供給が制限的で常に過負荷になる商用 MaaS の現実から出発する。過負荷では「どのリクエストを受け入れるか」が「受け入れたリクエストをどう速く処理するか」と同等に重要な設計軸になり、PD 分離固有の時間差問題(Prefill 後に Decode が拒否)、Early Rejection 後の Prefill/Decode 間振動が新たな制御問題として生じる。予測ベース Early Rejection により基準比 14%(4183→3589 件拒否削減)の改善が得られた。(Source: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) > - **LLM インスタンスのコールドスタート時間がサービスレベル管理の設計原則を変える**: PreServe の Azure 本番分析によると DeepSeek-R1(6,710 億パラメータ)のコールドスタートは数十〜数百秒に達する。このため「KPI 閾値超えで反応的スケールアップ」という従来のマイクロサービス管理が LMaaS では機能せず、10 分先読みの mLSTM ワークロード予測による先行インスタンス起動が不可欠になる。Mooncake が「過負荷受け入れ制御」で問題を設定するのに対し、PreServe は「先行プロビジョニング」で問題を回避する方向を取る——両者のアプローチは相補的だ。(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]], [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) > - **リクエスト間の応答長ばらつきが KV キャッシュ管理とロードバランシングの両方に波及する**: PreServe の ShareGPT 分析では応答長が 5〜632 トークン(中央値 87)と約 126 倍の幅を持つ。短い応答はすぐに KV メモリを解放し次のリクエストを受け入れられるが、長い応答はインスタンスの KV メモリを長時間占有し実質的な並列可能数を減らす。これは PagedAttention（[[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]]）が KV キャッシュ断片化を解決しても残る問題であり、「どのインスタンスへ振り向けるか」というルーティング層でも応答長予測が必要な理由となる。(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]], [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]]) > - **本番 KV キャッシュのワークロード特性は合成トレースの前提を覆す**: Aliyun 本番トレース([[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]])は理想ヒット率 to-C 62%/to-B 54%（合成 80% 超を大幅に下回る）、to-B の KV 再利用 97% がシングルターン起因（マルチターン支配仮定の反証）、KV ブロック寿命が指数分布にフィット（LFU 不適の根拠）を示した。ワークロード対応エビクションで LRU 比最大 41.4% の QTTFT 改善を達成。合成ベンチマーク結果を本番の設計根拠に直接使えないことを実データで裏付けた。(Source: [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]], [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) > - **RAG/マルチテナントでの非プリフィックス KV キャッシュ再利用は選択的再計算の発展段階に入った**: CacheBlend は非プリフィックスチャンクの KV 偏差が高い 10〜20% トークンの選択的再計算で TTFT 2.2〜3.3 倍削減を達成し(EuroSys 2025 Best Paper)、KVShare はアテンション重み×KV 偏差の積で優先トークンを選ぶ DHD とデコードフェーズのアテンション・ドリフト対処で SOTA 比精度 20.38% 向上を示した。プリフィックスキャッシングの限界が RAG/エージェントワークロードで明確になり、「再利用可能な KV キャッシュの同定」と「偏差補正の範囲」が新しい設計軸として確立しつつある。(Source: [[@2025__EuroSys__CacheBlend - Fast Large Language Model Serving for RAG with Cached Knowledge Fusion]], [[@2025__arXiv__KVShare - An LLM Service System with Efficient and Effective Multi-Tenant KV Cache Reuse]]) > - **長コンテキスト手法の評価は KV キャッシュライフサイクル全体で行う必要がある**: SCBench([[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]])は既存ベンチマークが単一リクエスト評価に留まることを指摘し、KV キャッシュ生成・圧縮・検索・ローディングの 4 フェーズを共有コンテキストモードで評価する。sub-O(n) メモリ手法はマルチターン復号で破綻し、O(n) メモリ + 動的スパースアテンションが堅牢、レイヤーレベルのスパース性がメモリ効率と精度を両立するという知見を示した。これは推論フレームワークのベンチマークを「単一推論速度」から「キャッシュ再利用を含むライフサイクル性能」へ再定義する必要を示唆する。(Source: [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]]) > - **IO-aware アテンションアルゴリズムが推論のアテンション計算律速を世代横断で追跡・解消してきた**: [[FlashAttention]] シリーズは GPU メモリ階層のボトルネックを世代ごとに特定して解消する。FA1（2022、A100）は N×N アテンション行列の HBM 読み書きをタイリング＋オンライン softmax で排除し 2-4 倍の高速化、FA2（2023）は非 MMA FLOP 削減とシーケンス長並列化で 225 TFLOP/秒（73% 利用率）、FA3（2024、H100）はワープ特化＋FP8 ブロック量子化で 740 TFLOP/秒（75%）、FA4（2026、B200）は非対称ハードウェアスケーリングの協調設計で 1613 TFLOP/秒（71%）を達成した。ボトルネックは「HBM 帯域 → 非 MMA 演算 → 指数関数ユニット」へと移動しており、推論の算術演算密度向上はハードウェア世代ごとの律速資源追跡に他ならない。Wan+ のサーベイ([[Efficient Large Language Models - A Survey]])が FlashAttention を効率的アーキテクチャに位置づけたのは、アテンション計算のメモリ律速がモデル圧縮とは独立した最適化軸だからである。(Source: [[@2022__arXiv__FlashAttention - Fast and Memory-Efficient Exact Attention with IO-Awareness]], [[@2023__arXiv__FlashAttention-2 - Faster Attention with Better Parallelism and Work Partitioning]], [[@2024__arXiv__FlashAttention-3 - Fast and Accurate Attention with Asynchrony and Low-precision]], [[@2026__arXiv__FlashAttention-4 - Algorithm and Kernel Pipelining Co-Design for Asymmetric Hardware Scaling]]) > - **クラウドネイティブ推論基盤は Kubernetes の粗粒度管理と推論エンジンの細粒度制御のギャップを埋める**: [[AIBrix]] は [[Kubernetes]]（CRD / Service / Autoscaler）と [[Ray]]（高性能タスク制御）のハイブリッド設計で、LLM 固有メトリクス（KV キャッシュ利用率等）に基づく second-level オートスケーリング、分散 KV キャッシュ（scan-resistant eviction）、LoRA 多重化、SLO 駆動 GPU 最適化を統合する。[[vLLM]]・[[SGLang]]・[[NVIDIA Dynamo]] 等の推論エンジンを vendor-neutral sidecar に収容し、効率化技術を組み合わせるオーケストレーション層として設計されている。分散 KV キャッシュ最適化で 50% スループット向上・70% レイテンシ削減を報告。DistServe（research-first PD 分離）・NVIDIA Dynamo（full-stack hardware co-design）とは異なるクラウドネイティブ・アーキタイプとして、既存クラウドエコシステム（Istio・Prometheus・AWS EKS）との統合を前提とする。(Source: [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]], [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]]) > - **長コンテキスト推論の高速化は、計算削減だけでなく「どこから KV を読むか」の問題へ移る**: LMCache + NIXL の PyTorch Conference 2025 資料は、長コンテキストで Prefill が TTFT を支配するため、一度作った KV キャッシュをリアルタイムに保存・共有する「You Only Prefill Once」の発想を前面に出す。VAST Storage を使った Qwen3-235B-A22B-Instruct-2507-fp8 / 8×H100 例では、ISL 224K 付近で KV 再計算の TTFT が約 36 秒に達するのに対し、ストレージから KV を取得する場合は約 4 秒弱に抑えられている。推論最適化の焦点は、アテンション計算を速くするだけでなく、HBM・ホストメモリ・ローカル SSD・ネットワークストレージのどこに KV を置き、どの転送抽象で読むかに広がる。(Source: [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]]) > - **データフローアクセラレータの優位はデコードフェーズ(メモリバウンド)に限定され、プリフィルフェーズ(計算バウンド)では GPU と大差ない**: ALCF での実測([[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])では Cerebras CS-3 の ITL が A100 比 18.8× 短縮する一方、TTFT の改善は 35% にとどまる。ProfInfer([[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]])がプリフィル=計算バウンド・デコード=メモリバウンドと区別したことと整合し、アーキテクチャの物理的優位性の限界を示す。デコード律速が大きいオンライン推論ではデータフローが有効だが、大バッチオフライン推論では GPU の柔軟なバッチ拡大が優位に転じる。(Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) > - **推論専用フレームワーク群は学習機能を持たないことで「サービング特化」の機能集合に収斂する**: 本ページは vLLM の PagedAttention・TensorRT-LLM のカーネル統合を個別に深掘りしてきたが、[[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]] の Table 2 は [[vLLM]]・[[TensorRT-LLM]]・[[Text-Generation-Inference (TGI)]]・[[RayLLM]]・MLC LLM・Sax・Mosec という 7 フレームワークが揃って Training・Fine-Tuning に非対応(Inference のみ対応)であることを示し、これらが PagedAttention・継続バッチング・量子化を共通基盤として共有しつつ、コンパイラ最適化(MLC LLM の TVM 基盤)・エコシステム統合(TensorRT-LLM の Triton、RayLLM の Ray、Sax の Pax/JAX/PyTorch マルチフレームワーク対応)で差別化するという分業構造を可視化する。[[Netflix]] が TensorRT-LLM から vLLM へ移行した理由が性能でなく運用適合性だった([[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]])のは、この「共通基盤+周辺差別化」という構造の下では機能差よりも運用要因がエンジン選定を支配しうることの一次事例と整合する。(Source: [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]], [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]) > - **アクセラレータ選択はエネルギー効率とスループットのトレードオフを内包し、ユースケースが判断を分ける**: データフローアクセラレータは小バッチ性能で GPU を圧倒するがエネルギー効率 (tok/J) は低い(CS-3: 0.15 tok/J vs H100: 0.91 tok/J)。一方、GPU は W8A8 量子化と大バッチ運用でエネルギー効率を改善できる(H100 で FP8 により +47%)。これは「推論コスト最適化は信頼性低下として現れる場合がある」([[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]])という観点と組み合わせると、エネルギー制約下でのアクセラレータ選択が品質劣化リスクも含む多軸問題になることを示す。(Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]]) > - **オフライン推論ではデータ並列(DP)がテンソル並列(TP)より高スループット・高エネルギー効率である**: ALCF の実測では DP 構成が TP=2 比 20%・TP=4 比 32〜140% を上回る。TP は all-gather 通信オーバーヘッドでスケーリング効率が最大 60% 止まりだが、DP は ~100% のスケーリングを達成する。例外はモデル重みが GPU メモリの 80% 超を占める場合で、TP で KV キャッシュ領域を確保する必要がある。この知見は DistServe([[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]])が Prefill/Decode に最適な並列化を段階別に選ぶべきと論じた方向性を裏付ける。(Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]]) > - **ハイブリッドアーキテクチャの推論実装では KV キャッシュだけでなく再帰状態も一級の管理対象になる**: PLaMo 2.0-31B の vLLM 実装では、通常の Transformer 前提の KV キャッシュ管理に加え、Mamba state を別機構で扱う必要がある。PLaMo 2 固有の Mamba 層は標準実装と異なり、causal conv1d と selective scan の間の線形射影、selective scan 後の RMSNorm 非搭載を持つためカスタム層が必要になった。これは、vLLM/PagedAttention 型の推論基盤がハイブリッドモデルへ拡張されると、アテンションの KV だけでなく状態空間モデル側の状態ライフサイクルも設計対象になることを示す。(Source: [[@2025__arXiv__PLaMo 2 Technical Report]], [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]]) > - **エンジン選定は性能ベンチマークではなく運用適合性で決まる場合がある**: Netflix の本番事例([[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]])は、TensorRT-LLM から vLLM への移行理由として、推論速度そのものではなく「カスタムモデルの多段階コンパイル不要」「カスタムデコード拡張フック」「デバッグ性」「研究本番間の移行コスト」を挙げた。これは、GPU 世代がサービング可否を決める([[@2025__ペパボ研究所__gpt-ossモデルのサービング性能評価]])、Goodput が SLO 達成スループットを示す([[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]])といった既存の知見が主に定量的性能を扱うのに対し、エンジン選定という上流の意思決定が定性的な運用要因に支配されうることを示す一次事例である。(Source: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]) > > - **同一レプリカ内での QoS 差別化 co-scheduling は、PD 分離とは異なる軸でサイロ非効率を解消する**: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]] は、既存の LLM サービングが interactive/batch の二値サイロ(専用 GPU クラスタ)に依存し、負荷変動でリソースが偏在すると指摘する。Niyama は Prefill/Decode を同一レプリカに同居させたまま(chunked-prefill、[[Sarathi-Serve]] 拡張)、複数 QoS クラスのリクエストを 1 つの共有クラスタで co-schedule することでこれを解消し、SOTA サイロ構成比で GPU 必要台数を 13〜32% 削減した。これは [[DistServe]] が Prefill/Decode を物理的に分離してリソースを最適化するのと対照的に、「分離せず共有インフラ上でスラックを再配分する」という逆方向のアプローチであり、LLM サービング効率化には「分離してそれぞれ最適化する」路線と「共有して動的に配分する」路線の 2 系統が並立していることを示す。(Source: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]], [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]]) > - **チャンクサイズは固定パラメータでなく、デッドラインスラックに基づき動的に決定すべき制御変数である**: chunked-prefill([[Sarathi-Serve]])は固定チャンクサイズを前提とするため、最も厳格な QoS クラスの TBT 制約に合わせると全体スループットが低下する(Niyama 論文では固定チャンクサイズ 330 で 50ms SLO を満たすとスループットが 28% 低下する例を示す)。Niyama は decode queue 内リクエストの次トークンデッドラインまでの残り時間(スラック)を毎イテレーション計算し、デッドラインを侵害しない範囲でチャンクサイズを機会的に拡大する。これは PagedAttention・RadixAttention 等がメモリ管理を制御対象にしたのと同様に、チャンクサイズという実行時パラメータ自体がスケジューリングの一級市民になったことを示す。(Source: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]]) > - **EDF と SRPF の線形補間が、LLM 推論スケジューリングにおける低負荷/高負荷のトレードオフを解消する**: Niyama の評価では、EDF(Earliest Deadline First)は低負荷で違反ゼロだが負荷がしきい値を超えると違反率がほぼ 100% に急騰し、SRPF(Shortest Remaining Prompt First)は高負荷に強いが長いリクエストのデッドラインを低負荷でも不公平に犠牲にする。Niyama のハイブリッド優先度式(デッドライン項 + α × 残処理時間項)はこの 2 極を補間し、最大 40% 高い負荷までテールレイテンシ SLO を維持した。既存のクラウド QoS スケジューリング(Paragon・Quasar)は LLM 推論の二段階実行モデル・高いプリエンプションコストを前提としておらず、この補間設計は LLM 推論固有の解決策として位置づけられる。(Source: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]]) > - **過負荷対応は「一部リクエストを早期に諦める」設計が全体最適になりうる**: Niyama の積極的降格(eager relegation)は、デッドラインをすでに違反した/違反しそうなリクエストを relegated queue へ先回りして降格させ、5% 程度の犠牲で残り 95% のリクエストの中央値レイテンシを安定させる。これは Mooncake の Early Rejection(過負荷指向スケジューリング)と同じ問題意識(全リクエスト処理を前提としない)を持つが、Mooncake が受け入れ制御(admission control)として過負荷を扱うのに対し、Niyama は受け入れ後のスケジューリング層で降格を行う点が異なる。両者を比較すると、過負荷対応は「入り口で断る」と「実行中に降格する」という 2 つの制御点で実装しうることが分かる。(Source: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]], [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) > > - **長文脈・小バッチのデコードでは、集合通信のマイクロ秒単位のレイテンシがトークン生成のクリティカルパスを直接支配する**: [[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]] は、テンソル並列(TP)デコードの各ステップに埋め込まれた AllReduce が、長文脈でバッチサイズが KV キャッシュ容量制約により縮小されるほど支配的なボトルネックになる(帯域ではなくレイテンシが律速)ことを実測で示す。GB200 の barrier-free 低レイテンシ AllReduce カーネルにより inter-token latency(ITL)を Llama-3.1-70B で最大 13%・DeepSeek-V3 で 11.4% 削減し、出力 100 万トークンあたり $11 超のコスト削減を推定した。既存の LLM 推論最適化(PagedAttention のメモリ管理、chunked-prefill のスケジューリング、PD 分離のリソース分離)がいずれも GPU 内のメモリ・スケジューリングを対象にするのに対し、本研究は GPU 間通信そのものの物理下限(Speed-of-Light)に迫るという、これまでの LLM 推論最適化の知見群とは異なるレイヤーの最適化軸を提示する。(Source: [[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]]) > > - **オンライン推論最適化(TTFT/TPOT の SLO)とオフライン・大規模バッチ推論最適化(スループット)は、同じ推論エンジンでも異なる設計原理を要求する**: 本ページの多くの知見(Goodput、PD 分離、chunked-prefill、QoS co-scheduling 等)はストリーミングサービスの SLO 達成を主眼にするが、[[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]] は検索エンジンのスニペット生成やオフラインランキングのような、スループットのみが指標となる大規模バッチ推論に特化する。BatchLLM はバッチ全体が事前に既知であるという前提を利用してプレフィックスを大域的に事前識別し、リクエストを decode/prefill 比で並べ替え、KV メモリ制約のみで token バッチを拡大することで vLLM・SGLang に対し 1.3〜10.8 倍のスループット向上を達成する。この設計は個々のリクエストのレイテンシを犠牲にしうるため、著者自身がレイテンシ重視のオンラインサービスには不向きと明言しており、[[LLM推論]] の最適化空間が「オンライン SLO 志向」と「オフラインスループット志向」の 2 つの独立した設計軸に分岐していることを裏付ける。(Source: [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]]) > > - **本番グレード推論エンジン上での投機的復号ベンチマークは、レイテンシ・スループット双対性([[Towards Efficient Generative Large Language Model Serving]] が指摘)がバッチサイズという単一パラメータの内部でも成立することを定量的に示した**: [[@2026__arXiv__Speculative Decoding - Performance or Illusion?]] は vLLM 上で [[Speculative Decoding]] の速度向上がバッチサイズ増加とともに縮小する(検証段階のコスト支配が強まるため)ことを実測し、この減衰率がモデルサイズに応じて増幅されることを示した(Llama3.1-8B の 4.3% に対し Llama3-70B は 14.0%)。これは ProfInfer が示す Prefill=計算バウンド/Decode=メモリバウンドという段階間の律速資源の違いとは別軸で、同一 Decode フェーズ内でもバッチサイズが「メモリ余剰を使った投機」から「計算律速による投機コスト増」へ連続的に遷移することを示す。(Source: [[@2026__arXiv__Speculative Decoding - Performance or Illusion?]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) > - **「Every Microsecond Matters」が長文脈・小バッチ decode でのマイクロ秒通信最適化を示したのに対し、TokenWeave は小トークン prefill/hybrid バッチでの計算-通信オーバーラップを実用化する——テンソル並列推論の通信最適化は decode 側とprefill 側で異なる技術が必要**: [[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]] は barrier-free カーネルで AllReduce 単体のレイテンシを Speed-of-Light 下限近くまで削るのに対し、[[@2025__arXiv__TokenWeave - Efficient Compute-Communication Overlap for Distributed LLM Inference]] は AllReduce を RMSNorm と融合しつつ、計算とオーバーラップさせることで通信そのものを「隠す」方向を取る。両者は同じ TP AllReduce のボトルネックを、前者は「削る」、後者は「隠しつつ隣接演算も削る」という異なる戦略で攻めており、実運用では decode-only の小バッチ(前者が有効)と prefill-only/hybrid の中規模バッチ(後者が有効)で使い分ける余地がある——TokenWeave 自身も disaggregated serving で decode には融合カーネル単体、prefill にはフル overlap を推奨しており、この住み分けと整合する。(Source: [[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]], [[@2025__arXiv__TokenWeave - Efficient Compute-Communication Overlap for Distributed LLM Inference]]) > - **推論での compute-communication overlap は、既存の tile-level 融合手法(Flux・TileLink)の 3 つの構造的限界——GEMM 限定・RS/AG 分割オーバーヘッド・小粒度通信の非効率——を、通信オーバーラップの粒度をトークンレベルへ引き上げることで同時に解消できる**: TokenWeave は Attention のような非 GEMM 演算もオーバーラップ対象にでき(トークン単位の粗粒度分割のため)、AllReduce を RS+AG に分割せず単一融合カーネルに保つことで分割オーバーヘッドを避け、大きな単一 AllReduce を維持することで小粒度通信の帯域劣化(Figure 6)も回避する。TileLink が小トークン域(1K)でネット悪化するのに対し TokenWeave が同域で 1.20 倍を達成する(Figure 14)という定量差は、粒度選択(tile vs token)が通信オーバーラップの適用可能範囲を直接左右することを具体的に示す。(Source: [[@2025__arXiv__TokenWeave - Efficient Compute-Communication Overlap for Distributed LLM Inference]]) > - **マルチテナント推論では、メモリ容量制約と計算共有制約を別々に最適化する必要がある**: [[@2026__SIGCOMM__DynamoServe - A Distributed Tiered Memory System for Multi-tenant LLM Serving|DynamoServe]] は、NVLink ピア GPU の遊休 HBM をプールしてテンソル並列や CPU オフロードを回避しつつ、NVIDIA MPS のプロファイリング誘導 SM 割当で CNN と LLM をコロケーションする。メモリ集約型 LLM と計算集約型 CNN が同一 GPU で非対称なリソース需要を持つ場合、メモリ階層最適化(LMCache/Mooncake 系)と GPU 共有最適化(MPS/MIG 系)は独立した設計軸であり、統合コントローラが両方を同時に扱う必要がある。(Source: [[@2026__SIGCOMM__DynamoServe - A Distributed Tiered Memory System for Multi-tenant LLM Serving]]) > > - **BatchLLM が挙げる「オフラインランキング」の具体的な実例が、[[Netflix]] の GenRec によって報告された**: 上記の BatchLLM の知見は「検索エンジンのスニペット生成やオフラインランキング」を大規模バッチ推論の応用例として抽象的に挙げるにとどまるが、[[@2026__Netflix TechBlog__GenRec - Towards LLM-native Recommendation at Netflix]] は自己回帰デコードを一切行わない**prefill-onlyモード**でカタログ全体を1回のフォワードパスでスコアリングする、より極端な形の「オフラインスループット志向」推論を報告する。BatchLLM がプレフィックス共有とトークンバッチングでデコード込みの推論を高速化するのに対し、GenRec はそもそもデコードフェーズを持たず(生成せずカタログ対応スコアリングヘッドでスコアのみ出力)、prefill 計算そのものを唯一のコストとして最適化対象にする点が異なる。両者は「オンライン SLO 志向 対 オフラインスループット志向」という本ページの分岐軸のうち、後者をさらに「デコードを含む大規模バッチ」と「デコードを持たないスコアリング専用ワークロード」の2種に細分化しうることを示す。(Source: [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]], [[@2026__Netflix TechBlog__GenRec - Towards LLM-native Recommendation at Netflix]]) > > - **Wan+ の「介入点による3分類」(モデル中心・データ中心・フレームワーク中心)は、efficient inference を model-centric(§2.4)の一部門としてモデル圧縮・効率的事前学習・効率的ファインチューニング・効率的アーキテクチャと並置する——この切り口は Miao+ のアルゴリズム/システム2軸、Zhou+ の data/model/system 3層タクソノミーとは分類原理が異なる**: [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 1 Introduction]] が示す taxonomy は「何を対象に手を入れるか(モデル自体・データ・実行基盤)」という観点で切るのに対し、[[Towards Efficient Generative Large Language Model Serving]](Miao+)はアルゴリズムレベル/システムレベルという実装レイヤーで切り、[[A Survey on Efficient Inference for Large Language Models]](Zhou+)は data-level/model-level/system-level というパイプライン段階で切る。同じ efficient inference という主題が、サーベイごとに異なる上位構造の下へ配置されることが分かる。(Source: [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 1 Introduction]], [[Towards Efficient Generative Large Language Model Serving]], [[A Survey on Efficient Inference for Large Language Models]]) > - **フレームワークの「対応タスク(Training/Fine-Tuning/Inference)」という切り口は、Miao+・Zhou+・Wan+ Chapter 1 のいずれの taxonomy にも現れない別の分類軸である**: 既存 3 サーベイの taxonomy は「何を最適化するか(アルゴリズム/システム、data/model/system、モデル/データ/フレームワーク)」で切るのに対し、[[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]] の Table 2 は同じフレームワーク中心の主題を「そのフレームワークがどのタスクに対応するか」という運用上の軸で再整理する。この軸は、Miao+ が挙げる推論フレームワーク横断比較(FlexFlow-Serve・vLLM 等)の背後にある「なぜこれらが推論専用ツールとして独立に存在するのか」という問いに対する一次的な説明になる。(Source: [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]], [[Towards Efficient Generative Large Language Model Serving]]) > - **Zhou+ の "first token latency" / "per-output token latency" は、後発コミュニティ用語 TTFT / TPOT・ITL が指すのと同一の指標を、指標体系として先に定式化したものである**: [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 2 Preliminaries]](§2.2 Inference Process of LLMs)は、Prefilling 段階の遅延を **first token latency**、Decoding 段階の1トークンあたり平均遅延を **per-output token latency** と定義し、これらに generation latency・token throughput・request throughput・model size・KV cache size・peak memory を加えた8指標の体系を提示する(2024年4月)。この用語系列は、本ページが別に挙げる NVIDIA の ISL/OSL ベンチマーク解説や道下([[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]])が使う TTFT・TPOT・ITL・E2EL・TPS・RPS・Goodput という後発の実務コミュニティ用語と概念的に対応するが、後者は SLO(サービスレベル目標)との結びつきや ITL の TTFT 包含/非包含といったツール依存の計算差異まで踏み込む点で発展している。Zhou+ の指標定義自体は、ProfInfer が実測で示す「Prefill=計算バウンド・Decode=メモリバウンド」というフェーズ差の**測定対象を先に切り分けた**理論的土台であり、Zhou+ の第2.3節が挙げる3根本原因(モデルサイズ・注意演算の二乗複雑度・自己回帰復号のメモリアクセスコスト)は ProfInfer の実測結果を後から説明する形になっている。(Source: [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 2 Preliminaries]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]], [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) > > - **オンライン推論の性能診断は、フェーズごとに異なる観測粒度を組み合わせる必要がある**: StriaTrace は本番サービングで TTFT/TPOT と推論ステップのトークン数を対応づけ、Prefill/Decode のテイル異常を検知する。一方 ProfInfer はオンデバイス推論で演算子レベルの PMC を用いてメモリ帯域やディスク I/O の律速を特定する。前者のステップ・リクエスト粒度と後者の演算子・ハードウェア粒度は代替関係ではなく、SLO 違反を検知してから内部律速を掘り下げる階層として接続できる。(Source: [[@2026__OSDI__StriaTrace - Efficient Tracing and Diagnosis for Online LLM Inference]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) > - **推論電力の低下と実効性能の向上は別の評価軸である**: Blackwell の RTX 5080 は GPT-NeoX の FP8 推論で45.14 Wまで電力が下がったが、FP8 D-GEMM の大規模形状では H100 より低いスループットだった。推論エンジンの精度設定は電力を下げても、レイテンシ・スループット・出力品質を同時に改善するとは限らない。(Source: [[@2025__arXiv__Dissecting the NVIDIA Blackwell Architecture with Microbenchmarks]]) ## 関連 - ソース: [[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]] / [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]] / [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] / [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] / [[@2025__arXiv__Collective Communication for 100k+ GPUs]] / [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]] / [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]] / [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]] / [[@2025__INLG__Taming the Titans - A Survey of Efficient LLM Inference Serving]] / [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]] / [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]] / [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]] / [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]] / [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]] / [[A Survey on Efficient Inference for Large Language Models]] / [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]] / [[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]] / [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]] / [[@2026__arXiv__XWind - A Cross-site Router for Large Language Model Inference Serving at Renewable Energy Farms]] / [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] / [[@2025__MPLSJapan__A study on accelerating LLM inference using KV cache sharing with IOWN APN]] / [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]] / [[@2026__arXiv__KVCache Cache in the Wild - Characterizing and Optimizing KVCache Cache at a Large Cloud Provider]] / [[@2025__EuroSys__CacheBlend - Fast Large Language Model Serving for RAG with Cached Knowledge Fusion]] / [[@2025__arXiv__KVShare - An LLM Service System with Efficient and Effective Multi-Tenant KV Cache Reuse]] / [[@2025__ICLR__SCBench - A KV Cache-Centric Analysis of Long-Context Methods]] / [[@2025__arXiv__PLaMo 2 Technical Report]] / [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]] / [[@2025__arXiv__TokenWeave - Efficient Compute-Communication Overlap for Distributed LLM Inference]] / [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]] / [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 2 Preliminaries]] - 概念: [[GPU観測性]] / [[Mixture-of-Experts]] / [[ハードウェアカウンタ]] / [[集合通信]] / [[動的計装]] / [[サービスレベル目標]] / [[Prefill-Decode分離]] / [[KVキャッシュ管理]] / [[GPUクラスタスケジューリング]] / [[FlashAttention]] / [[GPU最適化]] / [[AIアクセラレータ]] / [[テンソル並列]] - エンティティ: [[llama.cpp]] / [[GGML]] / [[Llama4]] / [[Orange Pi]] / [[Rubik Pi]] / [[vLLM]] / [[SGLang]] / [[LMCache]] / [[P-D-Serve]] / [[DistServe]] / [[高火力 PHY]] / [[GenAI-Perf]] / [[TensorRT-LLM]] / [[NVIDIA NIM]] / [[CacheBlend]] / [[KVShare]] / [[SCBench]] / [[Cerebras]] / [[SambaNova]] / [[Sarathi-Serve]] / [[Text-Generation-Inference (TGI)]] / [[RayLLM]] - エンティティ: [[TensorRT]] / [[RTX 5080]] / [[GPT-NeoX]] / [[NVIDIA Blackwell]] - 関連 MOC: [[LLM4SRE - MOC]] / [[AI Infra Telemetry - MOC]] / [[Systems for ML - MOC]] ## 出典 - [[@2026__arXiv__Speculative Decoding - Performance or Illusion?]](vLLM 上での SD 体系的ベンチマーク、バッチサイズ増加による速度向上の減衰とモデルサイズ依存の増幅、検証コスト支配) - [[@2025__arXiv__TokenWeave - Efficient Compute-Communication Overlap for Distributed LLM Inference]](テンソル並列推論の融合 AllReduce–RMSNorm カーネル・wave-aware smart-splitting・1K トークンでも通信オーバーラップを実用化・vLLM V1 実装で最大 1.28× レイテンシ改善) - [[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]](GB200 scale-up ネットワークで barrier-free 低レイテンシ AllReduce・vLLM 推論 ITL 最大 13% 削減・出力 100 万トークンあたり $11 超のコスト削減) - [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]](Prefill/Decode・PMC・MoE ボトルネック=ディスク I/O) - [[@2026__OSDI__StriaTrace - Efficient Tracing and Diagnosis for Online LLM Inference]](本番サービングでの TTFT/TPOT とステップトークン数の対応づけ、Prefill/Decode テイル異常検知) - [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]](分散推論のリクエスト追跡・MoE ルーティング) - [[@2025__arXiv__Collective Communication for 100k+ GPUs]](推論ボトルネック=CPU 準備オーバーヘッド・GPU 常駐コレクティブ) - [[Towards Efficient Generative Large Language Model Serving]](アルゴリズム/システム 2 軸タクソノミー、投機的復号の品質保持、レイテンシ/スループット双対性、フレームワーク横断比較) - [[Efficient Large Language Models - A Survey]](§2.4 推論効率化のアルゴリズム/システム二重構造、モデル圧縮→推論の直列最適化、§2.5 効率的アーキテクチャとの統合) - [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]](性能指標体系 TTFT/ITL/TPOT/E2EL/TPS/RPS/Goodput、バッチ戦略 4 種、PD 分離、KV Cache 転送ボトルネック、「KV Cache を設計の中心」の定石) - [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]](SLO ベース推論基盤最適化、PD 分離の同一 4 GPU 条件比較、Mooncake Store による KV Cache Reuse/Sharing と読み込みコスト) - [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]](PD 分離の Goodput 最適化、段階別資源割当、配置制約、OPT-175B KV キャッシュ転送評価) - [[@2025__INLG__Taming the Titans - A Survey of Efficient LLM Inference Serving]](インスタンス/クラスタ/新興シナリオの階層型サーベイ、PD 分離カテゴリ、エージェント・マルチモーダル・テスト時推論への拡張) - [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]](PagedAttention、vLLM、KV キャッシュページ化管理、2-4 倍スループット改善) - [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]](RadixAttention、frontend/runtime 協調、structured LM programs、最大 6.4 倍スループット改善) - [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]](GPU 外 KV キャッシュ退避・転送・階層ストレージ、最大 15 倍スループット改善) - [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]](数万 NPU 規模の PD 分離、細粒度 P/D group、on-demand forwarding、block-free D2D transfer) - [[A Survey on Efficient Inference for Large Language Models]](data/model/system 三層タクソノミー、推論フレームワーク比較) - [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]](attention 最適化から disaggregation への発展史、DistServe/AIBrix/Dynamo のアーキタイプ整理) - [[@2025__NVIDIA__LLM-Inference-Benchmarking-Fundamental-Concepts]](ユースケース別 ISL/OSL プロファイル、GenAI-Perf vs LLMPerf のメトリクス計算差異、ロードテスト vs パフォーマンスベンチマークの区別) - [[@2025__arXiv__DeepSeek-V3.2 - Pushing the Frontier of Open Large Language Models]](DSA: ライトニングインデクサ + top-k トークン選択で O(L²) → O(Lk) のコアアテンション複雑度削減。128K プリフィルで約 4 倍のコスト削減) - [[@2025__DeepSeek__DeepSeek-V4 - Towards Highly Efficient Million-Token Context Intelligence]](§2.3 CSA + HCA ハイブリッド圧縮アテンションによる KV キャッシュ BF16 GQA8 比 2% 圧縮、§3.5 異種 KV キャッシュ管理とオンディスク KV キャッシュ 3 戦略、FP4 インデクサ・混合精度 KV 格納) - [[@2026__arXiv__XWind - A Cross-site Router for Large Language Model Inference Serving at Renewable Energy Farms]](KV キャッシュ利用率の先行指標性・GPU 周波数と推論性能の非線形関係・可変電力下でのワークロード非依存サービング) - [[@2025__MPLSJapan__A study on accelerating LLM inference using KV cache sharing with IOWN APN]](IOWN APN による分散小型データセンター間 KV キャッシュ共有、100 km 圏内の TTFT/電力効率評価) - [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]](コスト起因劣化、コンテキスト境界劣化、ツール/API 呼び出しエラー、評価ギャップ) - [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]](Kimi 本番 MaaS の KVCache 中心 3 プール分離、Conductor スケジューラ、CPP、Layer-wise Prefill、過負荷指向スケジューリング、vLLM 比 75% 多いリクエスト処理) - [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]](LMCache + NIXL による KV キャッシュ転送/ストレージ抽象、VAST Storage での長コンテキスト TTFT 削減例) - [[@2025__arXiv__PLaMo 2 Technical Report]](vLLM Model API、Mamba state 管理、チャンク化プリフィル、INT4 重み量子化、FP8 KV キャッシュ量子化) - [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]](6 GPU + 2 データフローアクセラレータ + 14 LLM 横断実測; DP vs TP 推論スケーリング; FP8 量子化効果; データフローの Decode フェーズ優位とエネルギー効率劣位) - [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]](QoS 駆動 co-scheduling、動的チャンキング、EDF/SRPF ハイブリッド優先度付け、積極的降格、SOTA サイロ比 GPU 台数 13〜32% 削減) - [[@2024__arXiv__BatchLLM - Optimizing Large Batched LLM Inference with Global Prefix Sharing and Throughput-oriented Token Batching]](大規模バッチ・オフライン LLM 推論に特化したグローバルプレフィックス共有・スループット指向 token バッチング。vLLM/SGLang 比 1.3〜10.8 倍のスループット向上) - [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 1 Introduction]](「介入点による3分類」taxonomy: モデル中心・データ中心・フレームワーク中心。efficient inference を model-centric §2.4 として位置づける) - [[@2024__TMLR__Efficient Large Language Models - A Survey - Chapter 4 LLM Frameworks]](Table 2:推論専用フレームワーク 7 種(vLLM・TensorRT-LLM・TGI・RayLLM・MLC LLM・Sax・Mosec)の機能比較。PagedAttention・継続バッチング・量子化の共通基盤とコンパイラ/エコシステム統合による差別化) - [[@2024__arXiv__A Survey on Efficient Inference for Large Language Models - Chapter 2 Preliminaries]](§2.2 Inference Process of LLMs: Prefilling/Decoding の2段階定義。§2.3 Efficiency Analysis: first token latency・per-output token latency・generation latency・token/request throughput・model size・KV cache size・peak memory の8指標体系、モデルサイズ・注意演算の二乗複雑度・自己回帰復号の3根本原因) - [[@2025__arXiv__Dissecting the NVIDIA Blackwell Architecture with Microbenchmarks]](RTX 5080/H100 の GPT-NeoX Transformer 推論、精度設定ごとの電力)