# vLLM LLM 推論で標準的地位を確立しつつあるオープンソースの推論フレームワーク。ページドアテンション(Paged Attention)による KV キャッシュのメモリ効率化を特徴とし、OpenAI API 互換のサーバーを提供する。([[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) `vllm bench serve` などのベンチマークツールも同梱されており、推論サービングの性能評価にも広く用いられる。 Miao+ のサーベイ([[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving]])では、スループット特化の代表システムとして位置づけられている。ページドアテンションにより KV キャッシュのメモリ断片化を抑制し、高いメモリ利用効率とスループットを達成する。一方でレイテンシ特化のシステム(例: FlexFlow-Serve の投機的復号)とは設計上の方向性が異なり、レイテンシとスループットの双対性を体現する一例でもある。 Kimi k1.5 の RL インフラストラクチャでは、[[Megatron-LM]] と vLLM を同一 Pod 内の Kubernetes Sidecar コンテナに配置し、訓練と推論のハイブリッドデプロイメントを実現している。[[Mooncake]] 経由の RDMA で重みを転送し、切り替えは訓練→推論が 1 分未満([[@2025__arXiv__Kimi K1.5 - Scaling Reinforcement Learning with LLMs]])。 ペパボ研究所の三宅悠介による gpt-oss サービング評価([[@2025__ペパボ研究所__gpt-ossモデルのサービング性能評価]])では、vLLM を Google Cloud H100/A100/L4 上で運用した際の比較が行われ、H100 でのみ並列スケーリングが有効に機能することが確認された。出力トークン数がスループットの律速要因であることも示されており、vLLM の continuous batching がデコードフェーズに依存することと整合する。 道下幹也の SpeakerDeck 資料では、`vllm bench serve` を使って PD Disaggregation と KV Cache Reuse/Sharing を評価している。KV Cache Reuse/Sharing の測定では gpt-oss-120b を 2 GPU で動かし、Mooncake Store を別サーバー上の KV Cache Store として利用する。([[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]]) [[DistServe]] 論文では、vLLM は連続バッチングとページドアテンションを備える代表的ベースラインとして評価された。OPT-13B/66B/175B のチャット、コード補完、要約タスクで、Prefill と Decode を同居させる vLLM は TPOT 側の SLO 達成が制約となり、DistServe は vLLM に対して最大 5.7 倍(コード補完)・4.3 倍(要約)の per-GPU リクエスト率を示した。(Source: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]]) SOSP 2023 論文 [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]] では、vLLM は PagedAttention を実装する LLM サービングシステムとして提案された。KV キャッシュを固定サイズブロックに分け、論理ブロックを非連続な物理 GPU メモリへ写像することで、既存システムの予約・内部断片化・外部断片化を抑える。評価では FasterTransformer / Orca に対して同等レイテンシで 2-4 倍のスループット改善を示した。(Source: [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]]) 後続の [[SGLang]] と [[LMCache]] は、vLLM のページドメモリ前提をそれぞれ異なる方向へ拡張する。SGLang は RadixAttention を vLLM 比較対象として用い、LMCache は vLLM の KV connector を通じて GPU 外キャッシュ退避・再読込・PD 分離転送を行う。(Source: [[@2024__NeurIPS__SGLang - Efficient Execution of Structured Language Model Programs]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]]) vLLM 内部の EngineCore は、リクエストの待ち行列を管理する Scheduler、KVCache の空き状況を管理する KVCacheScheduler、forward 実行と CUDAGraph キャプチャを担当する ModelExecutor の 3 コンポーネントで構成される。Super Sequence によりリクエストのトークン列を 1 次元に連結して扱うため Prefill と Decode を区別なくスケジューリングでき、割り込んだ Prefill が全体の処理時間を圧迫しないように Prefill を分割する Chunked Prefill 機能を持つ(デフォルトでは無効)。KVCache の物理ブロックが尽きたときは一部リクエストを Preempt して KV ブロックを解放し、後からきたリクエスト順に Preempt を行う Scheduler Class が中断(再計算 or CPU への KVCache オフロード)を担当する。(Source: [[@2026__SpeakerDeck__LLM高速化(勉強会)]]) [[MLCommons Chakra]]論文では、当初訓練ワークロード向けだったトレース収集機能をvLLM v1のprefill/decode disaggregation構成へ統合し、MoEトークンルーティングの不均衡、KVキャッシュのCPU-GPUオフロード(Memcpy DtoH回数がベースライン比15倍以上に増大)、Prefill-Decode分離間のKVキャッシュ転送レイテンシ(層ごとに約110〜190µs)をChakra ETとして定量分析した事例が報告されている。(Source: [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]]) [[Netflix]]は2026年夏、既存の[[TensorRT-LLM]]ベースの本番サービング基盤から、運用適合性(カスタムモデルのロード容易性・カスタムデコード拡張フック・デバッグ性・研究本番間の移行コスト)を根拠にvLLMをpaved-pathエンジンとして採用した。[[Triton Inference Server]]への統合ではPythonバックエンドでなくvLLMバックエンドを既定とし、Triton/vLLMのバージョン整合固定という運用課題が生じた。制約付きデコーディング(logits processorベースの状態機械)は、vLLM V0のGIL律速per-requestロジックからV1のbatch-level API(`update_state(batch_update)`)への移行で、CPU処理時間のバッチサイズ比例増大というテイルレイテンシ問題を解消した。(Source: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]) [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving|Niyama]] は、vLLM 上に構築された [[Sarathi-Serve]] のスケジューラを拡張し、QoS 駆動の動的チャンキング・ハイブリッド優先度付け・積極的降格を追加することで、interactive/batch のサイロを廃した複数 QoS クラス co-scheduling を実現した。vLLM API を拡張して各リクエストに TTFT/TBT/TTLT の QoS 要件と優先度レベルを紐づけている。(Source: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]]) ## 関連 - 概念: [[LLM推論]] / [[KVキャッシュ管理]] / [[Prefill-Decode分離]] / [[制約付きデコーディング]] - 本番導入事例: [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]([[Netflix]] / [[Triton Inference Server]]) - 本ソース: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]] - サーベイ: [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving]] - RL インフラ: [[@2025__arXiv__Kimi K1.5 - Scaling Reinforcement Learning with LLMs]] - 性能評価: [[@2025__ペパボ研究所__gpt-ossモデルのサービング性能評価]] / [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]] - ベースライン評価: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model 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]] - アーキテクチャ・Contribute 方法: [[@2026__SpeakerDeck__LLM高速化(勉強会)]] - トレース分析統合: [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]] - QoS 駆動スケジューリング拡張: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]]([[Sarathi-Serve]])