vLLM 本番デプロイメント: 高スループット推論サービングアーキテクチャの構築
2025年12月11日更新
2025年12月更新: StripeがvLLM移行により73%の推論コスト削減を実現(GPUフリートの1/3で日次5,000万API呼び出しを処理)。PagedAttentionがKVキャッシュの断片化による60-80%のメモリ浪費を除去。vLLMが従来のサービングと比較して2-24倍のスループットを実現。Meta、Mistral AI、Cohere、IBMで本番稼働。OpenAI互換APIが導入を簡素化。
Stripeの機械学習プラットフォームチームは、Hugging Face TransformersからvLLMに移行した後、推論コストが73%削減されるのを目の当たりにした。同じ日次5,000万API呼び出しを従来の3分の1のGPUフリートで処理している。¹ vLLMの効率性の秘密は、GPUメモリをオペレーティングシステムの仮想メモリのように扱うPagedAttentionアルゴリズムにあり、従来の推論システムでメモリの60-80%を浪費する断片化を排除している。² 本番LLMワークロードを運用する組織は、vLLMが従来のサービングフレームワークと比較して2-24倍のスループット改善を提供し、大規模な言語モデル展開の経済性を変革することを発見している。³
推論サービング環境は数十のオプションに分散している:TensorRT-LLMは最大限のNVIDIA最適化を約束し、Hugging Face TGIは馴染みのある統合を提供し、Ollamaはローカルデプロイメントを簡素化する。しかし、vLLMは本番ワークロードの主要選択肢として浮上し、Meta、Mistral AI、Cohere、IBMで推論を支えている。⁴ このフレームワークのPagedAttention、継続的バッチング、OpenAI互換APIの組み合わせは、生のパフォーマンスと運用の簡素性のバランスをとったデプロイメント体験を創出する。vLLMのアーキテクチャとデプロイメントパターンを理解することが、コスト効率的な推論を実現する組織とGPU費用に溺れる組織を分ける。
PagedAttentionがメモリ管理を変革
従来のLLM推論では、各シーケンスのキー・バリュー(KV)キャッシュに対して連続したメモリブロックを割り当て、実際の使用量に関係なく可能な最大シーケンス長のスペースを確保する。4,096トークン用に設定されたシステムは、100トークンの応答に対してもそのフルメモリを割り当て、予約容量の97%を浪費する。これに数百の同時リクエストを掛け合わせると、実際のシーケンスがリソースを待ってキューに並ぶ間に、GPUメモリは空の予約で満たされる。
PagedAttentionは、GPUメモリを固定サイズのページ(通常16トークンずつ)に分割することでこのアーキテクチャを再構築する。⁵ 各シーケンスは連続した割り当てではなくページ参照のリストを維持し、いくつかの画期的な機能を可能にする:
非連続ストレージにより、KVキャッシュブロックを利用可能なGPUメモリ全体に散らすことができる。システムはもはや大きな連続領域を必要とせず、従来のアロケーターを悩ます断片化を除去する。2,000トークンのシーケンスは、スペースが存在するところならどこでも分散した125ページにわたってキャッシュを格納する。
動的割り当ては、シーケンスが成長するときにのみメモリを提供する。最初のトークンは1ページを割り当てる。17番目のトークンは2番目のページ割り当てをトリガーする。メモリ消費は理論的な最大値ではなく実際の使用量を追跡し、効果的な容量を劇的に改善する。
メモリ共有により、同一のプロンプトプレフィックスがリクエスト間でKVキャッシュページを共有できる。同じシステムプロンプトのバリエーションを尋ねる10人のユーザーは、そのプレフィックスの単一キャッシュコピーを共有し、共通パターンでのメモリ消費を90%削減する。標準化されたプロンプトを持つ本番システムでは、400%を超える利用率改善が見られる。⁶
ほぼゼロの浪費により、静的割り当てでよくある内部断片化を除去する。従来のシステムでは、部分的に満たされたブロックでシーケンスあたり平均4.1トークンを浪費する。PagedAttentionのページレベル粒度は浪費をページの一部まで削減し、長さに関係なく通常シーケンスあたり8トークン未満にする。
このアルゴリズムは、オペレーティングシステムの仮想メモリから直接インスピレーションを得て、数十年のメモリ管理研究をGPU推論に適用している。現代のオペレーティングシステムが仮想アドレスを物理メモリページにマップするように、PagedAttentionは論理KVキャッシュ位置を物理GPUメモリブロックにマップする。変換オーバーヘッドは各アテンション計算にマイクロ秒を追加するが、ギガバイトのメモリ容量を節約する。
継続的バッチングがGPU利用率を最大化
静的バッチングは、固定数のリクエストを一緒に処理する前に待機し、バッチが部分的に満たされるときにレイテンシスパイクを作り、リクエストが不均等に到着するときにスループットが低下する。バッチサイズが32の場合、31番目のリクエストは処理が始まる前にもう1つの到着を待つことを意味し、トラフィックが少ない期間中に数秒のレイテンシを追加する可能性がある。
vLLMの継続的バッチングはバッチ境界を完全に除去する。⁷ スケジューラーはリクエストレベルではなく反復レベルで動作し、バッチごとではなく順伝播ごとに決定を行う。シーケンスが生成を完了すると、そのスロットは兄弟シーケンスの終了を待つことなく、すぐに新しいリクエストを受け入れる。GPUは各瞬間に存在するあらゆる作業を処理し、静的バッチングが空のままにするギャップを埋める。
実装には、メモリ管理とスケジューリング間の注意深い連携が必要:
反復レベルスケジューリングは、すべてのデコーダーステップでリクエストキューを評価する。完了したシーケンスはスロットを解放し、待機中のリクエストは利用可能な容量を要求し、次の反復は最適に満たされたバッチで進行する。リクエスト間のレイテンシ変動は増幅されるのではなく吸収される。
プリエンプション処理は、メモリ圧迫がシーケンス排除を強制する状況を管理する。低優先度のリクエストはKVキャッシュ状態をチェックポイントし、高優先度シーケンスにGPUメモリを譲る。容量が戻ると、プリエンプトされたシーケンスはゼロから再開するのではなく、チェックポイントから再開する。
プレフィックスキャッシングは、共通のプレフィックスを共有するリクエストを特定し、関連するKVキャッシュページをすでに保持しているインスタンスにルーティングする。すべてのリクエストが同じ500トークンのコンテキストで始まるカスタマーサポートシステムでは、キャッシュされた状態から後続のトークンを提供し、冗長なプレフィックス計算を除去する。
ベンチマークは影響を実証している:vLLMは同等の設定でOllamaの41トークン/秒と比較して793トークン/秒のスループットを実現し、P99レイテンシは673msと比較して80msである。⁸ 継続的バッチングアーキテクチャは、1から256の同時ユーザーまでの同時実行レベル全体でこれらの利点を維持する。
本番アーキテクチャがクラスター全体でスケール
単一ノードのvLLMデプロイメントは相当なトラフィックを処理するが、本番システムには信頼性、スケール、効率性のためのクラスター全体のオーケストレーションが必要である。vLLM本番スタックは、4つの重要な追加により推論エンジンを完全なサービングシステムに変換する。⁹
リクエストルーティングは、ルーティングキー、セッションID、またはプレフィックスマッチングに基づいて、着信クエリを適切なバックエンドインスタンスに誘導する。インテリジェントルーティングは、関連するコンテキストをすでに保持しているインスタンスに関連リクエストを送信することで、KVキャッシュ再利用を最大化する。複数のターンを持つ会話は一貫して同じバックエンドにルーティングされ、インスタンス間での冗長なプレフィックス計算を回避する。
KVキャッシュ共有は、LMCacheプロジェクトを通じて複数のvLLMインスタンス間でPagedAttentionのメモリ効率性を拡張する。バックエンドは高速インターコネクト上で計算されたKVキャッシュブロックを共有し、リクエストが異なるインスタンスにルーティングされてもキャッシュヒットを可能にする。反復的なワークロードを持つシステムでは、クロスインスタンスキャッシュ共有から3-10倍のレイテンシ削減と2-5倍のスループット改善が見られる。¹⁰
観測可能性統合は、Prometheusを通じてメトリクスを公開し、Grafanaダッシュボードを通じて可視化を行う。リクエストごとのメトリクスは、最初のトークンまでの時間(TTFT)、トークン間時間(TBT)、エンドツーエンドレイテンシを捕捉する。インスタンスごとのメトリクスは、GPU利用率、メモリ圧迫、キューの深さ、キャッシュヒット率を追跡する。運用チームはパフォーマンスボトルネックと容量計画データに可視性を得る。
水平スケーリングは、需要シグナルに基づいてvLLMインスタンスを追加および削除する。KubernetesデプロイメントはHorizontal Pod