KVキャッシュルーティング：なぜ標準的なロードバランサーがプレフィックスキャッシュを破壊するのか（そしてその解決策）

プレフィックスキャッシュにより、vLLMとSGLangはモデルが既に処理したトークンの再計算をスキップできます。ただし、次のリクエストが同じGPUレプリカに到達した場合に限ります。標準的なラウンドロビンルーティングでは、マルチレプリカデプロイメントにおけるキャッシュ局所性が大幅に低下し、ルーティングがキャッシュアウェアでない限り、プレフィックスキャッシュの利点が制限されます。プレフィックスアウェアなスティッキールーティングがこの問題を解決します。この記事では、そのメカニズム、無視した場合のコスト、および3段階の高度化レベルでの実装方法について説明します。

推論は、AIコンピューティング需要の増加する割合を占めています。一部の業界予測では、生成AIワークロードが成熟するにつれて、推論がAIコンピューティング消費の大部分を占める可能性があるとされています。そして、そのかなりの部分が冗長な作業です。つまり、モデルが数秒前に処理したトークンのアテンション状態を再計算しているのです。問題はGPUやモデルではありません。推論クラスターの前に配置されたロードバランサーが、どこに何がキャッシュされているかを認識せずに各リクエストをルーティングしていることが原因です。

LLM推論エンジンと最適化の手段に関するより広範な概要については、以下をご覧ください。 LLM推論：AIの速度、コスト、スケーラビリティを最適化する.

プレフィックスキャッシュが重要な理由

すべてのLLM推論リクエストは、2つの異なるフェーズで実行されます。 プリフィルでは、モデルは入力シーケンス全体を処理し、キーバリュー（KV）キャッシュ（GPU VRAMに保存される、トークンごとに1エントリのアテンション状態の行列）を構築します。 デコードでは、モデルは出力トークンを一度に1つずつ生成し、入力を再読み込みすることなく、キャッシュされた状態を参照します。

プリフィルはコストがかかります。その計算コストは入力長に対して二次関数的に増加します。プロンプトを2倍にすると、アテンション計算は4倍になります。1時間あたり1,000リクエストで、1リクエストあたり1回処理される2,000トークンのシステムプロンプトの場合、これは1時間あたり200万トークンのプリフィル作業に相当します。これは毎日、毎時間発生します。

プレフィックスキャッシュは、その作業の冗長な部分を排除します。リクエストBが以前に処理されたリクエストAとプレフィックスを共有している場合、エンジンは共有トークンに対してキャッシュされたKVブロックを再利用し、新しいサフィックスのみを計算します。この節約効果は、以下の3つの一般的なワークロードパターンで複合的に現れます。

• RAGパイプライン：取得されたドキュメントチャンクは、特に多くのユーザーが同じナレッジベースや頻繁に参照されるドキュメントにアクセスする場合、クエリ間で重複することがよくあります。
• マルチターンチャット：各フォローアップメッセージは、モデルが既にエンコードした会話履歴に追加されます。
• Few-shotプロンプティング：すべてのリクエストの前に固定された一連の例を追加することで、プリフィル計算はN回ではなく1回で済みます。

vLLMは、ハッシュベースのブロックマッチングを介してプレフィックスキャッシュを実装しています。各KVブロックは、それを生成したトークンのハッシュによって識別されます。SGLangはRadixAttentionを使用しており、これはすべてのアクティブなリクエスト間で最長一致プレフィックスを見つけ、それらのブロックを直接再利用するラディックスツリーです。プレフィックスが多用されるワークロードでは、SGLangのRadixAttentionはキャッシュを考慮しないサービングと比較して数倍のスループット向上をもたらすと報告されており、LMSYSは代表的なベンチマークで最大約5倍の改善を報告しています。自動プレフィックスキャッシュが有効なvLLMは、マルチターンワークロードにおける冗長なプリフィルの大部分を排除します。

リクエストに安定した共有プレフィックスがあり、再利用可能なブロックを保持するのに十分なKVキャッシュ容量がある場合、これは単一インスタンスで最も効果的です。複数のレプリカを持つフリートにスケールアウトした途端、問題が発生します。

ラウンドロビンルーティングがキャッシュヒット率をいかに低下させるか

標準的なKubernetesサービス配下に8つのvLLMレプリカを持つデプロイメントを考えてみましょう。レプリカ1が2,000トークンのシステムプロンプトを含むリクエストを処理し、KVキャッシュを計算してVRAMに保存します。同じプロンプトを持つ次のリクエストが到着すると、ラウンドロビンはそれをレプリカ2に送信します。レプリカ2はそのプレフィックスのキャッシュを持っていないため、完全なプリフィルを最初から再計算します。3番目のリクエストはレプリカ3に送られ、これも同様にキャッシュミスとなります。

有用なプレフィックスキャッシュが単一のレプリカにのみ存在するワークロード（例えば、増え続けるチャット履歴やテナント固有のコンテキストなど）では、フリートサイズが増加するにつれて、ラウンドロビンルーティングはキャッシュを所有するレプリカに到達する確率を低下させます。この影響により、キャッシュ局所性が大幅に低下し、冗長なプリフィル計算が増加する可能性があります。

プレフィックスが多用されるワークロードでは、ルーティングがキャッシュアウェアでない限り、単純なスケールアウトはキャッシュ局所性を低下させ、冗長なプリフィルを増加させる可能性があります。

その結果は歴然としています。Red HatのKubernetesネイティブ分散推論フレームワークであるllm-dプロジェクトは、8ポッド/16基のH100 GPUでプレフィックスキャッシュアウェアなルーティングとラウンドロビンを比較ベンチマークし、 同じハードウェアで最初のトークンまでの時間が57倍高速化され、スループットが2倍に向上しました。 4基のAMD MI300X GPUでLlama 3.1 70Bを対象に実施した別のベンチマークでは、 出力トークン/秒が3倍、TTFTが2倍削減されることが示されました ルーティング戦略を切り替えた後、同じプリミティブに基づいて構築されたDigitalOceanの推論ゲートウェイでは、最大で 108%のスループット向上 が、同じハードウェア構成でキャッシュアウェアなルーティングとランダムルーティングを比較した場合に達成されました。

経済的影響は、リクエスト量、モデルサイズ、GPUの種類、ワークロードの特性によって異なりますが、一般的にキャッシュヒット率が高いほど、インフラコストの削減と既存ハードウェアのより良い活用につながります。

課題は、純粋なキャッシュ局所性と純粋な負荷分散が相反する方向にあることです。そこで問題となるのは、負荷分散を犠牲にすることなくキャッシュ局所性をどのように維持するかです。

プレフィックスアウェアなルーティングの3つのレベル

これらのアプローチは、最も単純なものから最も正確なものへと順に並べられています。

レベル1 — セッションアフィニティ

最も手っ取り早い解決策は、ロードバランサーを、セッションまたはユーザー識別子に基づいてハッシュするように設定し、同じセッションからのリクエストを常に同じレプリカにルーティングすることです。これは、ほとんどのロードバランサーでスティッキーセッションまたはコンシステントハッシュポリシーとしてネイティブに利用可能であり、カスタムルーティングロジックは必要ありません。

セッションアフィニティは、同じユーザーが増え続ける会話履歴を持つ連続したリクエストを生成するマルチターンチャットでうまく機能します。これには2つの構造的な制限があります。レプリカを追加するとハッシュリングが再シャッフルされ、既存のアフィニティが破棄され、フリートが再ウォームアップするまでキャッシュミスが発生します。

これは、シングルテナントまたは低並行性のデプロイメント、あるいはより正確なソリューションに投資する前に手早く成果を出したいあらゆる場所で、迅速な初期改善策として利用できます。

レベル2 — プレフィックスハッシュルーティング

リクエストを送信したユーザーではなく、リクエストの内容に基づいてハッシュ化します。具体的には、プロンプトの最初のN個のトークン（ユーザー間で同一の安定したプレフィックス）をハッシュ化し、同じプレフィックスハッシュを持つすべてのリクエストを同じレプリカにルーティングします。

セッションアフィニティとの主な違いは、共有システムプロンプトを正しく処理することです。ルーティングキーが安定した共有プレフィックスから計算される場合、同じシステムプロンプトを持つユーザーは同じレプリカにルーティングできます。レプリカはプレフィックスKVキャッシュを一度計算し、以降の一致するすべてのリクエストをキャッシュから提供します。

適切なプレフィックス境界を選択することは、ハッシュメカニズム自体よりも重要です。RAGパイプラインの場合、境界はプロンプトの最も長い安定した部分をカバーする必要があります。これはシステムプロンプトのみの場合もあれば、一般的に再利用される取得されたコンテキストを含む場合もあります。Few-shotプロンプティングの場合、それは例ブロックの終わりです。マルチターンチャットの場合、それは前のターンの終わりです。境界を短すぎると、ハッシュ領域内に可変コンテンツが残り、誤ったキャッシュミスが発生します。長すぎると、リクエスト間で異なるコンテンツが含まれ、ルーティングが多くのレプリカに分散されてしまいます。

レベル3 — KVイベントアウェアルーティング

最も正確なアプローチは、ルーターが各推論エンジンから発行されるKVブロックの割り当ておよび削除イベントを購読し、どのブロック（コンテンツハッシュで識別される）がどのレプリカに常駐しているかのリアルタイムマップを維持することです。各受信リクエストに対して、リクエストのプレフィックスのどれだけがすでにキャッシュされているか、および各レプリカの現在の負荷を考慮して、すべての適格なレプリカをスコアリングし、最もスコアの高いオプションにルーティングします。

スコアリング関数は2つのシグナルをバランスさせます。キャッシュオーバーラップスコアは、受信リクエストのプレフィックスブロックのうち、特定のレプリカにすでに常駐している割合を測定します。ロードスコアは、そのレプリカが現在どれだけ飽和しているかを測定します。ルーターは、ルーティングの決定を行う際に、キャッシュの局所性と現在のレプリカの負荷をバランスさせます。

これは、llm-dのEndpoint Pickerコンポーネントで広く使用されているアーキテクチャです。このコンポーネントは、キャッシュの状態と負荷情報を使用して、リクエストを転送する前にターゲットレプリカを選択します。ルーティングのオーバーヘッド自体は、それがもたらすプリフィルによる節約と比較して無視できるほどです。

プレフィックスアウェアルーティングをスキップすべき時

プレフィックスアウェアルーティングは、ワークロードに真のプレフィックスの重複がある場合にのみ、その複雑さに見合う価値があります。次の3つのシナリオでは、ルーティングの決定とブロック状態のルックアップをすべてのリクエストに追加しても、見返りはありません。すべてのプロンプトがユニークな場合（ドキュメント要約、多様な入力によるクリエイティブ生成）、プロンプトが短い場合（約200トークン未満で、プリフィルコストが取るに足らない場合）、または、バッチワークロードが構造的な繰り返しなしに完全に異なる入力を処理する場合です。

実用的な診断方法：vLLMのキャッシュイベントメトリクスまたはSGLangのRadixAttention統計から直接キャッシュヒット率を測定します。Ifヒット率がキャッシュアウェアルーティング後も低い場合は、まずプロンプト構造を調査してください。

TrueFoundryがKVキャッシュスティッキールーティングを実装する方法

TrueFoundryのAI Gatewayとモデルデプロイメントレイヤーは、KVキャッシュ最適化のためのスティッキールーティングをネイティブに実装しています。TrueFoundryを介してモデルがデプロイされると、一致するプレフィックスを持つリクエストは同じvLLMまたはSGLangレプリカにルーティングでき、これにより、同じプリフィルトークンを繰り返し再計算する代わりに、既存のKVキャッシュ状態を再利用できます。

ルーティングレイヤーは、キャッシュの局所性を維持することと、レプリカ全体で健全な負荷分散を維持することという、2つの相反する目標のバランスを取るように設計されています。レプリカがすでに該当するプレフィックスキャッシュを含んでいる場合、ルーティングはそのレプリカを優先して再利用を最大化できます。レプリカが飽和状態になった場合、ゲートウェイは代替レプリカにフォールバックして、キャッシュの局所性がボトルネックになるのを防ぐことができます。

ルーティングはモデルデプロイメントと統合されているため、チームはスティッキーセッション、プレフィックスハッシュ、またはカスタムの負荷分散ポリシーのために個別のインフラストラクチャを構築する必要がありません。モデルを水平にスケールするために使用されるのと同じデプロイメントワークフローは、レプリカが追加または削除されてもキャッシュアウェアなルーティング動作を維持します。

長いシステムプロンプト、マルチターンチャットアプリケーション、RAGワークロード、またはfew-shotプロンプティングパイプラインを実行しているチームにとって、これは、繰り返されるプレフィックスが、後続のリクエストを処理する可能性が最も高いレプリカ上でウォーム状態に保たれる可能性を高めます。その結果、アプリケーションレベルのルーティングロジックを必要とせずに、キャッシュ利用率の向上、冗長なプリフィル計算の削減、GPU効率の向上が実現します。

ベストプラクティス

• ルーティングに手を加える前にプロンプト構造を修正してください。 すべての静的コンテンツ（システムプロンプト、few-shotの例、取得されたチャンク）を各プロンプトの先頭に配置します。可変コンテンツ（ユーザーメッセージ、リクエストID、タイムスタンプ）は、安定したプレフィックスの後に続く必要があります。システムプロンプトの前に動的フィールドが1つでも誤って配置されると、ルーティング戦略に関係なく、キャッシュ可能性が完全に失われます。
• プレフィックス境界は推測ではなく、実際のトークン数に基づいて設定してください。 典型的なシステムプロンプトと例のブロックをトークン化し、トークン数を数え、その境界をプレフィックスハッシュに利用します。任意の固定長では、可変コンテンツの途中で文が切れたり、安定した領域全体を捉えきれないことがよくあります。
• まずレベル2から始め、測定し、その後、レベル3の価値があるかどうかを判断してください。 ラウンドロビンからプレフィックスハッシュルーティングに移行することで、カスタムルーティングインフラストラクチャなしで、利用可能な利点の大部分を獲得できます。レベル3は、複数のレプリカを継続的な同時実行で実行し、プレフィックスキャッシュミスが測定されたボトルネックである場合に評価する価値があります。
• キャッシュヒット率をダッシュボードのメトリックとしてだけでなく、本番アラートとして監視してください。 開発者がシステムプロンプトに動的フィールドを密かに追加すると、ヒット率は即座に低下します。誰かがログを確認する前に、レイテンシーの低下が現れます。設定したベースラインを下回るヒット率の低下をアラートとして通知してください。
• ローカリティの重みはグローバルにではなく、ワークロードタイプごとに調整してください。 マルチターンチャットやRAGパイプラインは、強力なキャッシュローカリティの優先順位付けから恩恵を受けます。多様な入力に対するバッチ推論は、純粋なロードバランシングから恩恵を受けます。ゲートウェイが混在するトラフィックを処理する場合、両方を妥協するのではなく、ワークロードクラスごとに個別のルーティング設定を実行してください。
• ヒット率と並行してVRAM使用率を監視してください。 プレフィックスキャッシュは、GPUメモリをプリフィル節約のために利用します。高い同時実行性では、キャッシュされたブロックがアクティブなリクエストとVRAMを競合し、LRUエビクションをトリガーしてヒット率を低下させます。正しいルーティングにもかかわらず負荷がかかるとヒット率が低下する場合、メモリ圧力が原因である可能性が高いため、ルーティングの問題と仮定する前に、推論エンジンのメモリ使用率の上限を調整してください。

まとめ

ほとんどのチームにとって、ラウンドロビンからプレフィックスハッシュルーティングへの移行は、最も効果の高い最適化です。フリートサイズ、同時実行性、キャッシュの再利用が増加するにつれて、より洗練されたキャッシュ認識ルーティングの価値はますます高まります。

TrueFoundryのAI Gatewayが、単一のコントロールプレーンでモデルデプロイメントと並行してプレフィックス認識ルーティングをどのように処理するかをご覧ください → truefoundry.com/ai-gateway