FlameサービングのチューニングでスタンドアロンvLLMのスループットに匹敵する性能を実現

研究者らは、PythonベースのサービングフレームワークであるFlame（vLLMを組み込み）と、スタンドアロンのvLLMインスタンスのパフォーマンスを比較しました。2026年10月24日に公開されたこの研究では、特定のチューニング戦略により、FlameがNVIDIA B200 GPU 2枚構成で参照エンジンとほぼ同等の性能を達成した方法について詳述されています。結果は、大規模言語モデル（LLM）のデプロイにおけるオーバーヘッド最小化にとって、プレフィックスキャッシュと非同期リクエスト受け入れが重要であることを浮き彫りにしています。

何が起きたか

評価では、Llama 3.1 8B Instructモデルを使用し、2つの異なるワークロードに焦点を当てました。最初のワークロードはドキュメント再利用なしで64件のリクエストを処理し、2番目のワークロードは4つのドキュメントそれぞれに対して4つの質問を行うことでプレフィックス再利用を可能にし、合計256件のリクエストを処理しました。両方のシナリオにおいて、システムは持続的な定常状態の負荷ではなく、短く有限なバースト状のトラフィックを処理しました。目的は、Flameが慎重に設定されたスタンドアロンvLLM環境が達成するスループットの少なくとも99%を維持できるかどうかを判断することでした。

初期テストでは、デフォルトの設定を使用した場合に大きなギャップがあることが明らかになりました。しかし、キャッシュ再利用を改善するために永続的なワーカー配置を実装した後、研究者らはその差の大部分を縮めることに成功しました。さらなる最適化には、バッチサイズの増加、非同期エンジン受け入れへの切り替え、入力に対する可逆圧縮の適用が含まれました。最終的な設定では、Flameの中央値完了スループットは、ドキュメント再利用なしの場合でスタンドアロンvLLMよりわずか0.55%低く、プレフィックス再利用ありの場合で0.86%低いのみでした。再利用テスト中の5組のうち2組は厳格な99%目標を下回りましたが、最悪ケースでの乖離はわずか2.03%でした。

仕組み

両システムの性能向上の中核となるメカニズムは、プレフィックスアフィニティです。アシスタントが同じドキュメントについて複数の質問に回答する場合、同じ初期トークンを繰り返し処理します。そのプレフィックスを単一のGPU上に保持することで、システムはアテンションキーと値を一から再構築することを回避できます。研究者らは、トークンブロックをハッシュ化して、推定プリフィル作業量が最も少ないシャードに見知らぬプレフィックスを割り当てるクライアントサイドマップを実装しました。これにより、特定のドキュメントに関する後続の質問は常に同じワーカーに到達することが保証され、vLLMは resident KV ブロックを効果的に再利用できるようになりました。

キャッシュに加え、チームは推論エンジンへのリクエスト受け入れ方法にも対処しました。元のFlameアダプターはバッチを同期的に渡していたため、後のタスクは現在の呼び出しが完了するのを待たなければなりませんでした。最適化されたバージョンでは、非同期APIを使用してバッチ内のすべてのリクエストを同時に受け入れました。また、zlibレベル1圧縮を採用して送信される入力のサイズを削減しました。これはテキスト主体のプロンプトに対して特に有効です。最後に、Python起動ヒープをフリーズすることで、推論中のガベージコレクションによる一時停止を減らし、スループットをさらに安定させました。

主要な詳細

• 実験では、vLLM 0.28.0およびTorch 2.13.0+cu130を実行するNVIDIA B200 GPU 2枚が使用されました。
• プレフィックスアフィニティにより、再利用シナリオにおいてスタンドアロンvLLMの中央値スループットが77.5%、Flameのそれが73.4%向上しました。
• Flameの最終的な中央値スループットは、再利用なしで7.586リクエスト/秒、再利用ありで28.350リクエスト/秒でした。
• 入力圧縮により、再利用バーストのエンコードされたサービス入力サイズは6 MB以上から約388 KBに削減されました。
• 起動ヒープのフリーズにより、ワーカーごとの最大ガベージコレクション一時停止時間が8.80 msから4.59 msに短縮されました。
• この研究では、これらの特定のテストにおいてFlameのデータ認識型スケジューラーによるパフォーマンス上の優位性は実証されませんでした。

なぜ重要なのか

本番環境用のLLMサービスを構築するエンジニアにとって、この比較はラップされたサービングフレームワークにおけるオーバーヘッドの実態を明確にします。Flameのような高レベルのオーケストレーションレイヤーを使用することによるペナルティはアーキテクチャ固有のものではなく、最適でないバッチングや同期デフォルトに起因することが示されています。プレフィックス局所性と非同期受け入れが重要であることを理解することで、開発者は自身のスタックをチューニングし、レイテンシスパイクを最小限に抑え、GPU利用率を最大化することができます。

また、この発見は、フレームワークの機能が自動的にパフォーマンス向上につながると仮定することへの警告でもあります。Flameのデータ認識型スケジューラーは、テストで使用されたより単純な明示的なクライアントマッピングを上回ることはありませんでした。これは多くのユースケースにおいて、複雑なスケジューリングアルゴリズムよりも、ストレートフォワードなルーティング戦略と慎重なリソース管理の組み合わせの方が効果的である可能性を示唆しています。チームは、理論上のスケジューリング上の利点よりも、キャッシュヒット率やバッチ占有度といった測定可能な要因を優先すべきです。

実行できること

• クライアントルーティングにプレフィックスアフィニティを実装し、コンテキストを共有するリクエストが同じGPUレプリカに届くようにしてください。
• エンジン受け入れに非同期APIに切り替え、バッチ処理が新しいリクエストをブロックしないようにしてください。
• テキスト主体の入力に対して可逆圧縮を有効にし、転送時のネットワークおよびメモリオーバーヘッドを削減してください。
• トラフィックパターンに基づいてレイテンシとスループットのバランスを取るよう、バッチ形成ウィンドウと制限をチューニングしてください。
• ガベージコレクションの一時停止を監視し、ワーカー初期化中に長寿命オブジェクトをフリーズすることを検討してください。
• プレフィックス再利用シナリオを含め、実際の使用パターンを模倣した有限バーストテストでパフォーマンスを検証してください。