公開：2026年9月11日, 最終更新：2026年9月11日
30秒サマリー
- SageMaker推論エンドポイントに「PREFIX_AWARE」ルーティング戦略が追加された
- 同一プレフィックスのリクエストを同一インスタンスへ集約し、KVキャッシュ再利用率を高める
- Llama 3.1 70Bのベンチマークで初回トークン生成時間（TTFT）のP50を最大77%削減
何が起きたか
Amazon SageMaker推論エンドポイントに、新しいルーティング戦略「PREFIX_AWARE」が追加された。AWSの公式ブログが詳細を解説している。
LLMを使ったアプリケーションでは、リクエストの冒頭に「システムプロンプト」や「検索結果文書」など、共通する大量のテキスト（プレフィックス）を付与するケースが多い。vLLMやTensorRT-LLMなどのサービングフレームワークはこの部分をKV（キー・バリュー）キャッシュとして保存し再利用する「プレフィックスキャッシング」機能を持つ。しかし複数インスタンスで構成されるエンドポイントでは、従来のランダムルーティングによってリクエストが分散されるため、各インスタンスでキャッシュが蓄積されず、機能が活かしきれない課題があった。
プレフィックス対応ルーティングはリクエスト先頭のバイト列を参照し、同一プレフィックスを持つリクエストを常に同一インスタンスへ転送する。ターゲットインスタンスが上限同時接続数（ConcurrencyThreshold）に達した場合は自動的に負荷の低いインスタンスへ退避させる過負荷保護と、スケールイン・アウト時の経路安定性も備える。
AWSが公開したベンチマークでは、Llama 3.1 70B Instructを7台のml.p5.48xlargeインスタンス上でvLLMを用いて検証。8,000トークンの共有プレフィックスを持つ長文脈ワークロードでは、P50 TTFTが71〜77%削減、スループットが15〜16%向上、KVキャッシュヒット率が約25%から82%へ改善した。短文脈ワークロードでも13〜16%のP50 TTFT削減とキャッシュヒット率約30%→80%の改善が確認されている。ルーティング処理のオーバーヘッドは1リクエストあたり1.3〜1.9ミリ秒で、トラフィック分散の偏りは理想均等配分から1%以内に収まっている。
原典ハイライト
AWSの公式ブログは「KVキャッシュヒット率が約25%から80%超へ上昇し、P50 TTFTを最大77%削減した」と記述。設定はエンドポイント構成に`RoutingStrategy: PREFIX_AWARE`と`PrefixAwareRoutingConfig`を追加するだけで、モデルコンテナや呼び出しAPIへの変更は不要だと明示している。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
RAG・マルチターン会話・テンプレートBotなど「共通プレフィックスが長い」LLMユースケースでは、インスタンス構成やモデルを変えることなく、ルーティング設定の変更だけでレイテンシーとスループットを大幅に改善できる可能性がある。エンドポイント設定の更新のみで切り替えられるため、移行コストは低い。
日本企業への示唆
SageMaker上でLLMを本番運用している日本企業は、まずワークロードのプレフィックス共有率を確認することが出発点となる。RAGシステムや社内Chatbotのように同一文書・同一ガイドラインを繰り返し付与する設計であれば、PREFIXAWAREへの切り替えがコスト削減に直結する。ただし効果を得るにはサービングフレームワーク側でもプレフィックスキャッシングを有効にする必要があり、vLLMは最新版でデフォルト有効、他フレームワークは個別確認が必要。また`PrefixLength`の設定値が短すぎると単一インスタンスへの過集中が生じるため、実際のプレフィックス長に合わせた調整とSageMakerの詳細オブザーバビリティによるキャッシュヒット率モニタリングを推奨する。
背景・経緯
SageMaker推論エンドポイントはこれまで「RANDOM」と「LEAST_OUTSTANDING_REQUESTS」の2つのルーティング戦略を提供していた。今回の追加により3戦略体制となった。vLLMをはじめとするLLMサービングフレームワークのプレフィックスキャッシング機能自体は既存の技術だが、マルチインスタンス環境でその恩恵を享受するためのインフラ側の対応が今回の発表の核心となる。
