KVキャッシュルーティング：冗長なLLMプリフィル作業を削減

KVキャッシュルーティングは、LLMトラフィック全体で繰り返しプロンプトのプレフィックスが表示される場合に重要です。適切なリクエストが適切なレプリカに到達すると、サービングエンジンはキャッシュされたアテンション状態を再利用し、同じプレフィルトークンを何度も再計算する必要がなくなります。.

それはインフラの詳細のように聞こえますが、すぐに製品の問題になります。長いシステムプロンプト、RAGコンテキスト、少数ショットの例、マルチターンのチャット履歴は、プレフィル作業を高コストにします。すべてのレプリカが同じプレフィックスを再計算すると、チームはレイテンシ、GPU時間、キャパシティプランニングのコストを支払うことになります。.

ShareAIは、150以上のモデル、マーケットプレイスの可視性、ルーティング、フェイルオーバーのための1つのAPIを開発者に提供します。KVキャッシュルーティングは、モデルサービングインフラ内の1層下に位置します。ShareAIの読者にとっての有用なポイントはシンプルです：ルーティングの決定は、モデル選択から繰り返しプロンプトを処理するGPUレプリカまで、AIスタックのすべての層で重要です。.

なぜKVキャッシュルーティングが重要なのか

LLM推論中、モデルはまずプレフィルフェーズで入力プロンプトを処理します。これにより、通常KVキャッシュと呼ばれるキー・バリューキャッシュを構築し、後で生成されるトークンがすでに処理されたコンテキストに戻ってアテンションを向けることができます。.

プレフィックスキャッシングにより、サービングエンジンは後のリクエストが同じプロンプトの冒頭を共有している場合にそのキャッシュを再利用できます。 vLLMの自動プレフィックスキャッシングのドキュメント は、共有されたプレフィックスのためにKVキャッシュを再利用し、新しいリクエストが共有部分の計算をスキップできるようにすることを説明しています。. SGLangのプレフィックスキャッシング は、共通のトークンシーケンスのためにKVキャッシュを共有する関連アイデアを使用しています。.

これは、多くのリクエストが同じ方法で始まるワークロードに特に重要です：大規模なシステムプロンプトを持つサポートエージェント、繰り返しのドキュメントチャンクを使用するRAGアプリケーション、リポジトリ指示を持つコーディングエージェント、またはターンをまたいで会話履歴を保持するチャット製品などです。.

ラウンドロビンが破綻する場合

プレフィックスキャッシングは1つのレプリカで最も簡単です。同じプロセスが繰り返されるプレフィックスを認識し、メモリが利用可能であればそのキャッシュを再利用できます。問題は、サービスが水平スケールする場合に発生します。.

標準的なラウンドロビンロードバランサーでは、リクエスト1がレプリカAでキャッシュをウォームアップする一方で、同じプレフィックスを持つリクエスト2がレプリカBに到達します。レプリカBにはそのキャッシュされた状態がないため、同じプレフィル作業を再計算します。リクエスト3はレプリカCに行き、再びキャッシュミスが発生する可能性があります。.

レプリカの数が増えるにつれて、単純なロードバランシングは関連するリクエストをより多くのマシンに分散させる可能性があります。モデルサービングフリートはバランスが取れているように見えるかもしれませんが、プレフィックスキャッシュのヒット率は低下します。これがKVキャッシュルーティングが埋めようとするギャップです。.

実用的なルーティングの3つのレベル

1. セッションアフィニティ

セッションアフィニティは、同じユーザー、ワークスペース、テナント、または会話からのトラフィックを同じレプリカにルーティングします。これは、マルチターンチャットの最初のステップとして最も簡単です。なぜなら、フォローアップのプロンプトが以前のコンテキストを共有することが多いためです。.

トレードオフとして、ユーザーの識別が必ずしもプロンプトの類似性と一致するわけではありません。2人のユーザーが同じ長いシステムプロンプトを共有していても、異なるレプリカにルーティングされる可能性があります。また、レプリカが追加または削除されると、セッションアフィニティが乱れることもあります。.

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

プレフィックスハッシュルーティングは、プロンプト自体をルーティングキーとして使用します。ルーターはプロンプトの安定した冒頭部分をハッシュ化し、一致するプレフィックスを同じレプリカに送信します。.

これは、繰り返されるシステムプロンプト、少数ショットの例、または共有された取得コンテキストがユーザー識別よりも重要な場合に適しています。難しいのはプレフィックスの境界を選ぶことです。ハッシュにタイムスタンプ、リクエストID、またはユーザー固有のフィールドが含まれる場合、ルーティングキーが分断され、キャッシュの再利用が崩壊します。.

3. キャッシュイベント対応ルーティング

最も高度なアプローチは、どのキャッシュブロックがどのレプリカに存在しているかを追跡し、負荷を考慮しながら最適なキャッシュオーバーラップを持つレプリカに各リクエストをルーティングします。 llm-d routerプロジェクト は、KVキャッシュの局所性、現在の負荷、優先順位を考慮してリクエストの送信先を選択するエンドポイントピッカーについて説明しています。.

これはより複雑ですが、キャッシュミスが測定可能で高コストかつ頻繁な高スループットフリートにとっては正しい方向性です。.

スキップすべき場合

KVキャッシュルーティングは、その複雑さに見合う価値が自動的にあるわけではありません。プロンプトが短く、ほとんどがユニークで、繰り返し構造が少ないバッチ処理の場合には適していません。.

ドキュメント要約、クリエイティブ生成、一回限りの抽出、多くの非同期バッチジョブでは、キャッシュ対応ルーティングを正当化するほどの共有プレフィックスの重複がない可能性があります。そのような場合、単純な負荷分散の方がより簡潔かもしれません。.

実用的なテストは測定です：キャッシュヒット率、最初のトークンまでの時間、スループット、キューの深さ、GPUメモリの負荷、完了したタスクごとのコスト。キャッシュ対応ルーティングがこれらの数値を動かさない場合、まずプロンプト構造を修正してください。.

ShareAIとの関連性

ShareAIはAIマーケットプレイスおよびAPIであり、GPUクラスター内のモデル提供ロードバランサーではありません。開発者はShareAIを使用して、1つのAPIを通じて多くのモデルにアクセスし、マーケットプレイスのシグナルを比較し、リクエストをルーティングし、使用状況を管理し、ルートが劣化した場合にフェイルオーバーを行います。.

それでもKVキャッシュルーティングは関連性があります。独自の推論スタックを運用している場合、より良いインフラストラクチャの質問をするのに役立ちます。ホストされたモデルを利用している場合、類似したモデル名を持つ2つのルートが実際のワークロードで異なる動作をする理由を評価するのに役立ちます。.

ビルダーにとって、これは価格設定にも関連します。長いプロンプト、繰り返されるRAGコンテキスト、またはエージェントループを持つアプリは、非常に不均一なAI使用を生み出す可能性があります。ShareAI Builderを使用すると、アプリケーション所有者はAI推論トラフィックをShareAI経由でルーティングし、マージンまたは追加料金を設定し、顧客がルーティングされた使用量に対してShareAIに支払い、生成された使用量に基づいて月次支払いを受け取ることができます。アプリケーション自体はShareAIの外部で構築されたままです。.

モデル選択とルート評価については、 ShareAIモデルマーケットプレイスから. 実装の基本については、 ShareAI APIリファレンス.

KVキャッシュルーティングチェックリスト

• 安定したプロンプトコンテンツを最初に配置してください：システムプロンプト、ツールルール、例、および繰り返されるコンテキスト。.
• 動的フィールドを後に移動してください：タイムスタンプ、リクエストID、ユーザー固有の事実、一度限りの指示。.
• ルーティング変更の前後でキャッシュヒット率を測定してください。.
• 最初のトークンまでの時間、スループット、キューの深さ、VRAMの負荷を一緒に監視してください。.
• キャッシュイベント対応ルーティングを構築する前に、プレフィックスハッシュルーティングから始めてください。.
• 1つのグローバルポリシーを強制するのではなく、ワークロードごとにルーティングルールを分割してください。.
• コストとレイテンシーを推論クラスター内だけでなく、アプリケーションレベルで可視化してください。.

よくある質問

KVキャッシュルーティングとは何ですか？

KVキャッシュルーティングは、繰り返されるプロンプトの接頭辞を持つリクエストを、対応するKVキャッシュを既に保持している可能性が高いレプリカに送るルーティング戦略です。目的は冗長なプリフィル計算を減らすことです。.

KVキャッシュルーティングは接頭辞キャッシュとどう違いますか？

接頭辞キャッシュは、共有されたプロンプト接頭辞に対してキャッシュされた状態を再利用するモデル提供エンジンの機能です。KVキャッシュルーティングは、キャッシュされた状態が既に存在する場所に一致するリクエストを誘導するトラフィック配置戦略です。.

ラウンドロビンルーティングは接頭辞キャッシュにどのように悪影響を与えますか？

ラウンドロビンルーティングは、どのレプリカがどのキャッシュされた接頭辞を持っているかを知らずにリクエストをレプリカ間で分散させます。繰り返されるプロンプトが異なるレプリカに着地するだけでキャッシュを逃す可能性があります。.

どのワークロードがKVキャッシュルーティングから最も恩恵を受けますか？

マルチターンチャット、RAG、コーディングエージェント、サポートエージェント、少数ショットプロンプティング、長い共有システムプロンプトを持つアプリが最も適しており、これらはかなりのプロンプト接頭辞を再利用します。.

チームがKVキャッシュルーティングをスキップすべき場合はいつですか？

プロンプトが短く、ほとんどがユニークであるか、繰り返し構造が少ないバッチ指向の場合はスキップしてください。その場合、ルーティングの複雑さがほとんど価値を追加しない可能性があります。.

vLLMとSGLangは接頭辞キャッシュをサポートしていますか？

はい。vLLMは自動接頭辞キャッシュを文書化しており、SGLangは一般的なトークンシーケンス間で共有KVキャッシュの接頭辞キャッシュを文書化しています。複数のレプリカが関与する場合、提供エンジンは依然としてルーティングの支援を必要とします。.

KVキャッシュルーティングはセマンティックキャッシュと同じですか？

いいえ。KVキャッシュルーティングは推論提供内で正確またはほぼ構造的な接頭辞の再利用に対応します。セマンティックキャッシュは通常、埋め込みや類似性の閾値を使用して、意味に基づいて応答や中間結果を保存および再利用します。.

ShareAIはKVキャッシュ対応のロードバランサーを置き換えますか？

いいえ。ShareAIは、モデルアクセス、ルーティング、フェイルオーバー、使用状況、請求のためのAIマーケットプレイスおよびAPI層です。KVキャッシュ対応ルーティングは、推論レプリカを運用するチーム向けの低レベルモデル提供インフラストラクチャです。.

ビルダーはKVキャッシュルーティングについてどのように考えるべきですか？

ビルダーは、キャッシュの動作をAIを多用するアプリ内のコスト要因の1つとして扱うべきです。アプリケーションの使用状況が不均一である場合、ShareAIはそのAIトラフィックをルーティングおよび収益化するのを支援し、アプリはShareAIの外部で構築および所有されたままになります。.

ルーティングを変更する前にチームは何を測定すべきですか？

キャッシュヒット率、最初のトークンまでの時間、スループット、キュー深度、VRAM負荷、タスクごとのコスト、出力品質を測定してください。ルーティングの変更は、ダッシュボードだけでなくワークロードを改善するべきです。.

KVキャッシュルーティングはAI APIのコストを削減できますか？

チームが自分たちでモデルを提供している場合、冗長なプリフィル作業が減ることでGPU効率が向上し、インフラコストを削減できます。ホストされたAPIの場合、その効果はプロバイダーが価格やパフォーマンスにその節約を反映させるかどうかに依存します。.