LLM推論 - yuuk1's Digital Garden

# LLM推論 ## 定義 LLM推論(LLM inference / serving)とは、学習済み大規模言語モデルでトークンを生成する実行過程で、入力を一括処理する Prefill フェーズと、トークンを 1 つずつ生成する Decode フェーズに分かれる。Prefill は TTFT(Time To First Token)、Decode は TPOT(Time Per Output Token)で評価される。([[@2026__arXiv__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=メモリバウンドの段階差が観測の基本軸**: [[@2026__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] はオンデバイス推論で「このワークロードはメモリバウンドか計算バウンドか」という問いに演算子レベル PMC で答え、Decode の行列ベクトル乗算では CPU サイクルの 50% 超(4 スレッドで 80% 超)が stall するメモリ帯域ボトルネックを示す。フェーズごとに律速資源が変わることが、推論最適化と観測設計の出発点になる。(Source: [[@2026__arXiv__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__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]]) - **同じ 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__arXiv__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__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) - **LLM 推論効率化はアルゴリズムレベルとシステムレベルの二重構造をなす**: [[@2024__TMLR__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+ のサービングサーベイ [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving]] が推論フレームワーク 10 種の横断比較に特化するのに対し、Wan+ は推論をモデル圧縮・効率的アーキテクチャ（FlashAttention、MoE、状態空間モデル）を含むモデル中心手法全体の一部として位置づけ、より広い文脈で推論最適化を整理する。(Source: [[@2024__TMLR__Efficient Large Language Models - A Survey]], [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving]]) - **モデル圧縮が推論効率化の前段として機能し、両者は直列に組み合わさる**: [[@2024__TMLR__Efficient Large Language Models - A Survey]] は[[モデル圧縮]]（量子化・プルーニング・低ランク近似・知識蒸留）を推論とは独立のセクションで扱うが、実際にはモデル圧縮後のモデルが推論パイプラインに投入される。PTQ の重み限定量子化（GPTQ: 175B を 3–4 ビット化）と KV キャッシュ量子化（KIVI: 2 ビット）は推論のメモリ律速を異なるレイヤーで緩和する。この直列最適化の実効性は FlexGen が「重み+KV キャッシュの 4 ビット量子化で OPT-175B を単一 16GB GPU で推論」した例で示される。(Source: [[@2024__TMLR__Efficient Large Language Models - A Survey]]) - **低レイテンシと高スループットは双対最適化目標であり、同時最適化は原理的に困難**: Miao+ のサーベイはサービングシステム 10 種を横断比較し、FlexFlow-Serve は SpecInfer による投機的復号でレイテンシに特化し、vLLM はページドアテンションによる KV キャッシュ効率化でスループットに特化するという設計の分岐を明示した。ProfInfer が示す Prefill=計算バウンド/Decode=メモリバウンドのフェーズ差は、この双対性の物理的根拠と一致する——Prefill の高速化(TTFT 削減)とバッチ効率(スループット)は異なる資源を律速とするため。(Source: [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving]], [[@2026__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) - **投機的復号は出力品質を保持できる唯一のアルゴリズム的高速化手法**: Miao+ は非自己回帰復号・早期脱出・カスケード推論がいずれも品質劣化を伴うのに対し、投機的復号は木構造検証で LLM の出力分布を保存することを示す。eInfer が分散推論で speculative decoding のトレース可能性を問うのは、この品質保証前提を運用で検証する必要があるからだ。(Source: [[@2025__ACM Computing Surveys__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__arXiv__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]], [[@2025__ACM Computing Surveys__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: [[@2025__ACM Computing Surveys__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: [[@2024__arXiv__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+ のサーベイ([[@2024__TMLR__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__arXiv__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__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) - **アクセラレータ選択はエネルギー効率とスループットのトレードオフを内包し、ユースケースが判断を分ける**: データフローアクセラレータは小バッチ性能で 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]]) ## 未解決の問い - 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 以外の操作にも広げられるか。 - 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 を行う等)は可能か。 ## 関連 - ソース: [[@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__arXiv__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]] / [[@2024__arXiv__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]] - 概念: [[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]] - 関連 MOC: [[LLM4SRE - MOC]] / [[AI Infra Telemetry - MOC]] / [[Systems for ML - MOC]] ## 出典 - [[@2026__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]](Prefill/Decode・PMC・MoE ボトルネック=ディスク I/O) - [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]](分散推論のリクエスト追跡・MoE ルーティング) - [[@2025__arXiv__Collective Communication for 100k+ GPUs]](推論ボトルネック=CPU 準備オーバーヘッド・GPU 常駐コレクティブ) - [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving]](アルゴリズム/システム 2 軸タクソノミー、投機的復号の品質保持、レイテンシ/スループット双対性、フレームワーク横断比較) - [[@2024__TMLR__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) - [[@2024__arXiv__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% 削減)