AI INFRAAWS2026.09.10

AWS、SageMaker Inferenceにprefix-aware routingを追加

AWSはAmazon SageMaker Inferenceのreal-time endpoints向けにprefix-aware routingを発表しました。同じprompt prefixを持つLLM requestを同じinstanceへ送り、KV cacheを活用しやすくします。

ROOT AI EDITORIAL

ここがポイント

LLM latency対策はmodel serverだけでなく、routing、request serialization、tenant分離、cache監視まで含む設計課題になります。RAGや長いsystem promptを使う企業は、prompt構造とendpoint運用を同時に見直す必要があります。

同じprompt prefixを同じinstanceへ送るroutingです

AWSは2026年9月10日、Amazon SageMaker Inferenceのreal-time endpoints向けにprefix-aware routingを発表しました。LLM requestの先頭にある共通promptを見て、同じprefixを持つrequestを同じinstanceへ送り、serving framework側のKV cacheを温めやすくする仕組みです。RAG、multi-turn conversation、長いsystem promptを持つassistant、code completionなど、同じ文脈が繰り返し使われるworkloadを対象にしています。

Llama 3.1 70BでTTFTとcache hit rateを検証しています

AWSのbenchmarkでは、Llama 3.1 70B Instructを7台のml.p5.48xlarge instancesとvLLMで動かし、default random routingと比較しました。8,000-tokenの共通prefixを1時間維持するlong-context workloadでは、P50 time-to-first-tokenが最大77%低下し、throughputは最大16%向上したと説明しています。KV cache hit rateは約25%から80%超へ上がり、routing overheadは1.3から1.9 millisecondsとされています。

cacheはmodel側だけでなくrouting層の設計問題になります

prefix cachingを有効にしていても、fleet内でrequestがばらけると同じprefixを各instanceが繰り返し計算します。prefix-aware routingは、RANDOM、LEAST_OUTSTANDING_REQUESTSに続くrouting strategyとしてproduction variant単位で設定できます。PrefixLengthは1024から65536、ConcurrencyThresholdは1から1024で指定し、instanceが混雑した場合は別instanceへ逃がすoverload protectionも持ちます。

導入時はserializationとmulti-tenant分離を先に確認します

実務では、単にstrategyを変えるだけでは十分ではありません。native Invoke APIではrequest bodyのbyte列、OpenAI-compatible APIではmessage textからrouting prefixを扱うため、JSONの空白やkey順が揺れるとcache効果が落ちます。tenantごとに分けたい場合はX-Amzn-SageMaker-Prefix-Aware-Id headerやprompt_cache_keyを使います。LLM servingのlatency対策は、model選定だけでなくrequest整形、routing、cache監視を含む運用設計になります。

公式発表を読む