vLLMは連続バッチ処理とPagedAttentionでGPUの非効率性をどう解決するか

大規模言語モデル（LLM）はサーバーではなく予測エンジンであるため、大量のリクエストを処理する際には根本的なミスマッチが生じます。これらのモデルを1リクエストずつ実行すると、GPUの計算能力の大部分がアイドル状態となり、コストが増加し、AI製品を開発するエンジニアにとってスケーラビリティが制限されます。

背景

オープンウェイトモデルを大規模に提供するという課題に対し、エンジニアたちは高スループット環境向けに設計された推論サーバーおよびフレームワークであるvLLMを採用しています。2023年にUC BerkeleyのSky Computing Labから生まれたvLLMは、リクエストのバッチ処理方法とGPU上のメモリ管理方法を再考することで、標準的なLLMデプロイメントにおける核心的な非効率性に対処します。

従来の推論手法では、リクエストを逐次的に処理するか、グループ全体が同時に開始・終了する静的バッチ処理を使用するため、苦戦を強いられています。このアプローチではLLMレスポンスの長さが可変であることを考慮していないため、速いリクエストが遅いリクエストの完了を待たされることになり、計算サイクルが大きく無駄になります。vLLMは、GPUを常にフル稼働させるために、連続バッチ処理とPagedAttentionという新しいメモリ管理技術を導入しました。

このフレームワークは、コスト効率とスループットが極めて重要となる本番環境における定番ソリューションとなっています。リクエストの完了とバッチの実行を切り離すことで、vLLMはすべてのフォワードパスが有用な作業を行うことを保証し、追加のハードウェアなしに毎秒生成されるトークン数を劇的に増加させます。

仕組み

LLM推論には2つのフェーズがあります。入力プロンプトをモデルが処理する「プリフィル」フェーズと、出力トークンを1つずつ生成する「デコード」フェーズです。標準的なセットアップでは、単一のトークン生成ごとにモデル全体の重みをロードする必要があるため、デコードフェーズは非効率になります。静的バッチ処理は複数のリクエストを同時に処理することでこれをわずかに改善しますが、短いレスポンスが長いレスポンスの新規バッチ開始をブロックする「ストラングラー効果」に苦しみます。

vLLMは静的バッチ処理を連続バッチ処理に置き換えます。バッチ内のすべてのリクエストが完了するのを待つ代わりに、スケジューラーは既存のリクエストが完了した瞬間に、次のフォワードパスへ新規リクエストを即座に挿入します。これによりGPUは常に稼働し、スループットが最大化されます。しかし、連続バッチ処理では効率的なメモリ管理が必要となります。アクティブな各リクエストは、生成されたトークン数に応じて成長するキー・バリュー（KV）キャッシュを保持するためです。

メモリ断片化の問題を解決するために、vLLMはPagedAttentionを使用します。従来のフレームワークでは、各リクエストのKVキャッシュに対して最悪ケースのメモリを予約するため、大きな無駄が生じます。PagedAttentionはOSの仮想メモリと同様にKVキャッシュを扱い、それを非連続なブロックに格納します。これによりシステムは動的にメモリを割り当て、可能であればリクエスト間でブロックを共有できるようになり、GPUメモリが予約済みの潜在領域ではなく、アクティブなデータのためにのみ使用されることを保証します。

主要なポイント

• vLLMは、2023年にUC BerkeleyのSky Computing Labの研究チームによって発表された論文で紹介されました。
• このフレームワークは連続バッチ処理を使用し、以前のリクエストが完了した直後に新しいリクエストをフォワードパスに追加します。
• PagedAttentionは、OSの仮想メモリページングと同様に、KVキャッシュメモリを非連続なブロックで管理します。
• 標準的な静的バッチ処理では、同じバッチ内の速いリクエストが遅いリクエストを待たなければならないため、計算資源が無駄になります。
• KVキャッシュはすべてのトークンのキーとバリューペアを保存し、生成ステップごとにサイズが増加します。
• vLLMは、既存アプリケーションへの統合を容易にするOpenAI互換APIエンドポイントを公開しています。

重要性

ソフトウェアエンジニアや技術系創業者にとって、GPUの使用率はインフラコストに直接結びついています。モデルが1リクエストずつ実行されると、デコードフェーズ中に高価なハードウェアの大部分がアイドル状態のままになります。vLLMを導入することで、チームは同じハードウェア予算でより多くのユーザーに対応でき、低遅延と高並行性が求められる本番アプリケーションにおいてオープンウェイトモデルを実用的なものにします。

静的バッチ処理から連続バッチ処理への移行は、待ち時間を短縮することでもユーザー体験を向上させます。静的システムでは、短いクエリを送信したユーザーが、長く複雑なリクエストを含む前のバッチによって遅延を受ける可能性があります。連続バッチ処理により、他のリクエストが完了している間にリクエストがアイドル状態になることはなく、より予測可能で応答性の高いAPIパフォーマンスが実現されます。この信頼性は、体感速度がエンゲージメントに影響を与えるコンシューマー向けAI機能にとって不可欠です。

さらに、PagedAttentionによるメモリ効率の向上は、スケーリングにおける大きな障壁を取り除きます。これがない場合、エンジニアは最悪ケースの長さに対応するためにメモリを過剰に確保する必要があり、単一GPUが処理できる同時リクエスト数が制限されます。vLLMの動的割り当てにより高密度なデプロイメントが可能になり、キャパシティプランニングが簡素化され、バッチサイズの複雑な手動最適化の必要性が減ります。

実践的なアドバイス

• 高スループットが必要なオープンウェイトモデルのデプロイメントでは、標準的なHugging FaceパイプラインをvLLMに置き換えてください。
• GPUのアイドル時間を削減するために、推論サーバーの設定を静的バッチ処理から連続バッチ処理に変更してください。
• メモリ圧力を理解し、最大モデル長の設定を適切に調整するために、KVキャッシュの使用状況を監視してください。
• クライアント側コードの変更を最小限に抑えるために、vLLMが提供するOpenAI互換APIエンドポイントを使用してください。
• 現在の静的バッチ処理セットアップとvLLMをベンチマーク比較し、毎秒トークン数の改善度を定量化してください。
• 連続バッチ処理により遅延プロファイルが変化する可能性があるため、アプリケーションが可変レスポンスタイムを柔軟に処理できるようにしてください。