Amazon Web Services（AWS）は2026年9月10日、Amazon SageMakerのリアルタイム推論エンドポイントにPrefix-Aware Routingを追加しました。

これは、同じプロンプト接頭辞を持つ要求を同じモデルインスタンスへ送り、GPU上のKVキャッシュを再利用しやすくするルーティング方式です。AWSのLlama 3.1 70Bベンチマークでは、長い共通文脈を使う条件でP50の初回トークン時間（TTFT）を最大77%短縮し、キャッシュヒット率を約25%から80%超へ高めました。

RAG、社内ボット、コード補完のように長い指示や文書を繰り返すサービスでは、モデルを変えずに応答性を改善できる可能性があります。ただし、効果は接頭辞の一致率とシリアライズの安定性に強く依存します。

背景：KVキャッシュが複数GPUで薄まる問題

LLMは入力トークンを処理するとき、Attention計算で使うKeyとValueを生成します。これを保持するKVキャッシュに同じ接頭辞が残っていれば、次の要求は共通部分を再計算せず、末尾の新しい部分から処理できます。

たとえば、カスタマーサポートの固定指示が3,000トークン、利用者の質問が50トークンなら、従来のランダム振り分けでは3,000トークンの計算が各GPUで繰り返されます。台数が増えるほど要求が分散し、個々のGPUではキャッシュが温まりにくくなります。

Prefix-Aware Routingは要求の先頭を見て、同じ接頭辞を同じインスタンスへ安定して割り当てます。モデルコンテナを改造する機能ではなく、エンドポイントの振り分け層でキャッシュ局所性を作る機能です。

何が新しいのか

SageMakerには従来、ランダムと最少未処理要求数のルーティングがありました。新方式を含めた使い分けは次のとおりです。

対象インスタンスが設定した同時実行上限に達した場合は、キャッシュヒットを諦めて余裕のある別インスタンスへ送ります。また、スケールアウト・イン時も多くの割り当てを維持し、全キャッシュが一度に無効になるのを防ぎます。

公開ベンチマークを正しく読む

AWSは7台のml.p5.48xlargeとvLLMを使い、16構成をテストしました。全テストは成功率100%だったと報告しています。

ワークロード	共通部分	P50 TTFT	P90 TTFT	ヒット率	スループット
長文	8,000トークン、1時間	71〜77%短縮	33〜37%短縮	約25%→82%	15〜16%増
短文	ShareGPT型、30分	13〜16%短縮	24〜37%短縮	約30%→80%	1.7〜2.0%増

長文では再利用できる計算が大きいため、中央値の改善が顕著です。一方、短文のスループット改善は最大2%にとどまります。「ヒット率80%なら処理能力も同じ比率で増える」わけではありません。

交通量は各インスタンス13.3〜15.4%で、7台の理想値14.3%からおおむね1ポイント以内でした。公式発表上はホットスポットを生じていません。ただし、これらはAWSによる特定構成の測定であり、第三者ベンチマークではありません。

有効化の例

本機能はエンドポイント設定のProduction Variantで指定します。PrefixLengthは1,024〜65,536、ConcurrencyThresholdは1〜1,024です。

{
  "RoutingConfig": {
    "RoutingStrategy": "PREFIX_AWARE",
    "PrefixAwareRoutingConfig": {
      "PrefixLength": 4096,
      "ConcurrencyThreshold": 10
    }
  }
}

ネイティブInvoke APIでは要求本文先頭のバイト数、OpenAI互換APIでは抽出されたメッセージ文字列がPrefixLengthの対象です。最低2インスタンスが必要で、vLLMなどモデルサーバー側でもprefix cachingを有効にします。

導入時の落とし穴

1. JSONの空白やキー順がキャッシュを壊す

ネイティブAPIは生のバイト列を見るため、内容が同じでもJSONの空白、改行、キー順が違えば別接頭辞になり得ます。固定部を先頭に置き、同じシリアライザーと設定で生成してください。

2. PrefixLengthは長すぎても短すぎても効かない

短すぎると異なる仕事が同じインスタンスへ集中し、上限超過が増えます。長すぎると利用者入力や温度設定などの差まで含み、同じ固定文が別扱いになります。共通指示の長さに小さな余裕を足した値から、負荷試験で調整します。

3. マルチテナント境界を明示する

異なる顧客が同じ指示を使っていても別々に割り当てたい場合、ネイティブAPIではX-Amzn-SageMaker-Prefix-Aware-Id、OpenAI互換APIではprompt_cache_keyを利用できます。これは振り分けの分離であり、認証・認可やデータ保護そのものの代替ではありません。

4. ヒット率だけを成功指標にしない

P50/P90 TTFT、出力トークン速度、要求成功率、GPU使用率、インスタンス別負荷、単位リクエスト費用を同時に見ます。高いヒット率でも、短い接頭辞では業務上の改善が小さい場合があります。

開発者・企業への影響

• RAG：同じ社内規程や製品マニュアルへの質問を集約し、文書部分を再利用できる。
• 会話AI：会話履歴の共通部分を同じGPUへ寄せ、ターンが長いほど恩恵が増える。
• コード補完：同じファイルを編集中の連続要求で、ファイル内容の再計算を減らす。
• 定型エージェント：長いシステム指示、ツール仕様、出力形式を繰り返す処理に向く。

編集上の推論として、この機能はGPUを追加する前の有力な最適化です。ただし、プロンプトの冒頭が頻繁に変わるサービスや単一インスタンス構成では効果が薄く、ルーティング方式を変えるだけで常に安くなるとは限りません。

今後注目すべき点

確認したいのは、モデルやGPUが違う場合の再現性、オートスケール直後のキャッシュ回復時間、ピーク時のオーバーフロー率、実請求額への影響です。また、長い接頭辞はKVメモリを消費するため、キャッシュの退避・削除方針と同時実行数のトレードオフも重要になります。

まず本番トラフィックの5〜10%で比較し、共通接頭辞の分布とTTFTを測ってから広げるのが安全です。

参照元

• AWS：Reduce LLM latency with prefix-aware routing on Amazon SageMaker Inference
• AWS API Reference：ProductionVariantRoutingConfig
• AWS Prescriptive Guidance：Generative AI inference architecture and best practices
• AWS：Managed Tiered KV Cache and Intelligent Routing for SageMaker HyperPod

最終確認日：2026年9月13日