vLLM本番デプロイ：高スループット推論サービングアーキテクチャの構築

2025年12月11日更新

2025年12月アップデート: StripeがvLLMへの移行により推論コストを73%削減（1日5,000万APIコールを1/3のGPUフリートで処理）。PagedAttentionがKVキャッシュの断片化による60〜80%のメモリ浪費を解消。vLLMは従来のサービングと比較して2〜24倍のスループットを実現。Meta、Mistral AI、Cohere、IBMで本番稼働中。OpenAI互換APIが導入を簡素化。

StripeのMLプラットフォームチームは、Hugging Face TransformersからvLLMに移行した後、推論コストが73%削減されるのを目の当たりにした。同じ1日5,000万APIコールを1/3のGPUフリートで処理できるようになったのだ。¹ vLLMの効率性の秘密はPagedAttentionにある。これはGPUメモリをオペレーティングシステムの仮想メモリのように扱うアルゴリズムで、従来の推論システムでメモリの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 production-stackは、4つの重要な追加機能で推論エンジンを完全なサービングシステムに変換する。⁹

リクエストルーティングは、ルーティングキー、セッションID、またはプレフィックスマッチングに基づいて、受信クエリを適切なバックエンドインスタンスに誘導する。インテリジェントルーティングは、関連するリクエストを関連するコンテキストをすでに保持しているインスタンスに送信することで、KVキャッシュの再利用を最大化する。複数のターンを持つ会話は一貫して同じバックエンドにルーティングされ、インスタンス間での冗長なプレフィックス計算を回避する。

KVキャッシュ共有は、LMCacheプロジェクトを通じて複数のvLLMインスタンス間でPagedAttentionのメモリ効率を拡張する。バックエンドは高速インターコネクトを介して計算されたKVキャッシュブロックを共有し、リクエストが異なるインスタンスにルーティングされてもキャッシュヒットを可能にする。反復的なワークロードを持つシステムでは、インスタンス間キャッシュ共有により3〜10倍のレイテンシ削減と2〜5倍のスループット改善が見られる。¹⁰

オブザーバビリティ統合は、Prometheusを通じてメトリクスを公開し、Grafanaダッシュボードを通じて可視化する。リクエストごとのメトリクスは、最初のトークンまでの時間（TTFT）、トークン間の時間（TBT）、エンドツーエンドレイテンシをキャプチャする。インスタンスごとのメトリクスは、GPU利用率、メモリ圧力、キュー深度、キャッシュヒット率を追跡する。運用チームはパフォーマンスボトルネックとキャパシティプランニングデータへの可視性を得る。

水平スケーリングは、需要シグナルに基づいてvLLMインスタンスを追加および削除する。Kubernetesデプロイは、キュー深度またはレイテンシパーセンタイルをターゲットとするカスタムメトリクスでHorizontal Pod Autoscalerを使用する。ルーターレイヤーは新しいインスタンスを自動的に検出し、トラフィックを再バランスして、実際の需要を追跡する弾力的な容量を可能にする。

デプロイはHelmチャートを通じて標準的なKubernetesパターンに従う：

# values.yaml for vLLM production-stack
replicaCount: 4
model:
  name: "meta-llama/Llama-3.1-70B-Instruct"
  tensorParallelism: 4
resources:
  limits:
    nvidia.com/gpu: 4
router:
  enabled: true
  prefixAwareRouting: true
observability:
  prometheus: true
  grafana: true

デプロイされたスタックは、Kubernetesサービスを通じてOpenAI互換APIを公開し、現在OpenAIまたはAzure OpenAIエンドポイントを呼び出しているアプリケーションのドロップイン置換を可能にする。既存のコードベースは、クラウドAPIからセルフホスト推論に移行するためにエンドポイントURL変更のみを必要とする。

インフラストラクチャ要件がデプロイ決定を形作る

vLLMのメモリ効率により、より小さなGPU構成でより大きなモデルを実行できるが、ハードウェア選択はパフォーマンス特性を依然として決定する。モデルサイズ、GPUメモリ、スループット間の関係を理解することが、調達決定に情報を提供する。

GPUメモリは最大モデルサイズと同時バッチ容量を制約する。FP16での70Bパラメータモデルは重みだけで140GBを必要とし、現在のどのハードウェアでもマルチGPUテンソル並列処理が必要になる。INT4量子化での同じモデルは35GBに収まり、KVキャッシュ用の大幅な余裕を持って単一のA100 80GBまたはH100でデプロイ可能だ。メモリ帯域幅は生の計算よりもスループットを制限することが多く、HBM3搭載GPUを不釣り合いに効果的にしている。

テンソル並列処理は、ノード内の複数のGPU間でモデルレイヤーを分割し、単一GPUメモリを超えるモデルには不可欠だ。vLLMはGPU数に一致するテンソル並列度をサポートし、アテンションとフィードフォワードレイヤーを自動的にシャーディングする。テンソル並列度8で8-GPUノードを実行すると、そうでなければより遅いパイプライン並列処理で複数ノードを必要とする405Bパラメータモデルを提供できる。

ネットワークファブリックはマルチノードデプロイで重要になる。ノード間のパイプライン並列処理には、ステージ間の低レイテンシ、高帯域幅インターコネクトが必要だ。200〜400Gbps帯域幅のInfiniBandまたはRoCEネットワークは効率的なマルチノードサービングをサポートするが、標準イーサネットは最初のトークンまでの時間を大幅に低下させるレイテンシを導入する。

ストレージスループットはモデル重みをロードする際のコールドスタートパフォーマンスに影響する。FP16での70Bモデルは、最初のリクエストを提供する前にストレージからGPUメモリに140GBを転送する必要がある。7GB/sを提供するNVMeストレージはモデルを20秒でロードするが、500MB/sのネットワーク接続ストレージは5分かかる。本番システムはウォームスタンバイインスタンスを維持するか、コールドスタートの影響を最小限に抑えるためのモデルキャッシング戦略を実装する。

Introlは、グローバルカバレッジエリア全体で組織がvLLMインフラストラクチャを設計するのを支援し、コスト効率を最適化しながらハードウェア構成をワークロード要件に一致させる。¹¹ 当社のエンジニアは月間数十億リクエストを処理する推論インフラストラクチャをデプロイしており、機能するデプロイと高度に最適化されたシステムを分けるニュアンスを理解している。

vLLMと代替手段の比較

推論サービングエコシステムは複数のフレームワークを提供しており、それぞれに異なる強みがある。適切なツールを選択するには、フレームワークの機能をワークロード特性に一致させる必要がある。

TensorRT-LLMは、積極的なカーネル最適化とグラフコンパイルを通じてNVIDIAハードウェアで最大パフォーマンスを提供する。ベンチマークでは、TensorRT-LLMがFP8量子化でH100上で10,000+出力トークン/秒を達成し、最初のトークンまでの時間は約100msである。¹² トレードオフ：チェックポイント変換、エンジン構築、TensorRT-LLM、tensorrtllm_backend、Triton Inference Server全体での広範な設定を必要とする複雑なセットアップ。専任のMLインフラストラクチャチームと安定したモデルデプロイを持つ組織が最も恩恵を受ける。

**Hugging Fa

[翻訳のためコンテンツは切り詰められています]