摘要： AWS 在 2026 年 9 月 10 日發表的 SageMaker prefix-aware routing，會把相同開頭的請求固定送到同一台 instance，讓 KV cache 得以累積。對長共用前綴的 RAG、多輪對話或模板機器人可望降低延遲，但 AWS 的 benchmark 是特定配置下的結果，自己工作負載的命中率仍要實測。
同一段開頭，被重複計算了一千遍
只要你的 LLM 應用帶著固定的 system prompt、一成不變的政策說明，或是 RAG 檢索回來的那份文件，那麼每一次請求最前面那幾千個 token 基本上完全一樣。AWS Machine Learning Blog 在 2026 年 9 月 10 日刊出的文章中拿客服機器人當例子：開場的指令約 3,000 tokens，而使用者真正問的問題只佔 50 tokens。
這類難題在 vLLM、TensorRT-LLM 等 serving framework 裡早有對策，也就是 prefix caching：把算過的 KV pair 保存下來，下一次遇到相同開頭直接沿用，只計算後面追加的 token，time-to-first-token（TTFT）因此能明顯下滑。
麻煩出現在規模擴大之後。endpoint 後方一旦排上一整隊機器，請求會被平均打散到 A、B、C 各台，同一段 3,000-token 前綴在每台機器上僅出現寥寥數次，沒有任何一台能養出可靠快取。功能確實開著，效果卻幾乎等於零。
SageMaker 讓路由決策改看請求內容
Amazon SageMaker Inference 端出的 prefix-aware routing，作法是檢視每個請求的開頭，把開頭一致的請求一律導向同一台 instance。如此一來，同一前綴的 KV cache 才真的能建立起來並被反覆取用。你無須自行為請求貼標籤或維護 affinity，該送到哪裡由 endpoint 依請求內容判斷。
AWS 公布的 benchmark 條件為 Llama 3.1 70B Instruct、7 台 ml.p5.48xlarge、vLLM 開啟 prefix caching，並與預設的隨機路由相互對照：
- 共享前綴 8,000 tokens、持續 1 小時：P50 TTFT 降低 71–77%，P90 降低 33–37%，KV cache 命中率由約 25% 上升到 82%，吞吐量增加 15–16%。
- ShareGPT 風格、長度不固定的短對話、30 分鐘：P50 TTFT 降低 13–16%，P90 降低 24–37%，命中率由約 30% 上升到 80%，吞吐量增加 1.7–2.0%。
路由邏輯本身為每個請求多帶來 1.3–1.9 毫秒，而測試中模型的 TTFT 落在 63–280 毫秒之間。流量分布同樣沒有出現熱點，7 台各自承接 13.3–15.4% 的請求。
兩道保險機制，以及三種路由策略怎麼選
前綴感知路由內建兩道保險。第一道是過載保護：萬一某個前綴特別熱門，作為目標的 instance 已經到頂，請求就會轉往較閒的機器。concurrency 上限由你設定，endpoint 照著遵守；付出的代價是那一次可能少掉一次 cache hit，換來的是單機不會被壓垮。第二道是擴縮容期間的穩定行為：instance 增減時，多數請求依舊送往原本的機器，僅有少部分流量被重新分配，快取不會每逢擴容就被清空。
SageMaker 目前提供三種策略。RANDOM 是預設值，適合請求彼此可互換、沒有特定親和需求的一般工作負載；LEAST_OUTSTANDING_REQUESTS 把請求送到 in-flight 最少的機器，適合處理時間變異大、想避免慢請求堆積的情境；PREFIX_AWARE 則針對共享開頭、且 serving framework 已開啟 prefix caching 的 LLM 工作負載。策略設定在 production variant 上，只要更新 endpoint configuration 就能切換，模型不必重新部署。
哪些工作負載才真的吃得到
AWS 點名的情境都具備同一個特徵：開頭很長，而且一再重複。RAG 應用把檢索到的文件擺在問題前面，多位使用者問同一份文件時便共用同一段前綴；多輪對話每一輪都帶上完整歷史，愈聊愈長；固定模板的機器人每次都送出同一套政策與格式規則；coding assistant 則把檔案內容當成 context，同一個檔案裡的每一次補全都共享它。
反過來說，假如你的請求彼此之間沒有共用開頭，這套策略就幫不上忙。
實際設定時最容易出錯的三個環節
啟用時會碰到兩個參數。PrefixLength（1024–65536）決定要拿多少內容來做路由判斷：原生 Invoke API 算的是 request body 開頭的 bytes，OpenAI 相容 API 算的則是抽取出來的訊息文字字元數。ConcurrencyThreshold（1–1024）代表目標 instance 的 in-flight 上限，一旦超出便溢出到較閒的機器。
aws sagemaker create-endpoint-config \
--endpoint-config-name example-llm-config \
--production-variants '[{
"VariantName": "AllTraffic",
"ModelName": "example-llm-model",
"InitialInstanceCount": 3,
"InstanceType": "ml.p5.48xlarge",
"RoutingConfig": {
"RoutingStrategy": "PREFIX_AWARE",
"PrefixAwareRoutingConfig": {
"PrefixLength": 4096,
"ConcurrencyThreshold": 10
}
}
}]'第一個坑是序列化的一致性。原生 Invoke API 的 PrefixLength 作用在原始 bytes 上，JSON 的空白、key 順序與格式都會左右路由結果。同一個 prompt 若以不同方式序列化，就可能被送往不同機器。
第二個坑是如何拿捏 PrefixLength 的長度。設得太短，所有共享短前綴的請求會全擠向同一台，觸發溢出；設得太長，連 temperature 這種小差異都會把本該同路的請求拆散。AWS 的建議是從共享前綴長度再加上一點緩衝開始。
第三個坑是別漏掉 serving framework 那一側。路由只負責把重複前綴導向同一台，容器本身必須開啟 prefix caching，KV pair 才會真的被存下並重用；vLLM 近期的版本預設開啟，其他框架可能得明確設定。此外至少要有兩台 instance，只有一台時無論選哪種策略都送往同一個地方。
「把請求送往正確機器」這條思路
前綴感知路由說到底，是在路由層做一個理解內容的判斷，而不是把請求當成可互換的單位平均分派。這條思路與我們先前寫過的區域路由：關鍵不是在哪推論，而是請求在哪解密屬於同一類問題：當請求被送往何處會直接牽動成本與延遲，路由策略便從維運細節升級為產品決策。
對產品開發者而言，實際的下一步不是先改架構，而是先量測：開啟 SageMaker detailed observability，盯著模型層級的 KV cache 命中率，確認你的工作負載是否真的有共享前綴。若是命中率本來就低，換策略也變不出快取；若是命中率明顯偏低、但前綴確實重複，那才值得動手調整 PrefixLength 與序列化方式。AWS 的 benchmark 是在特定模型、特定 instance 與 vLLM 配置下跑出來的，你自己的數字仍然得自己量。