推論基礎設施
SageMaker 以提示前綴分流維持 KV cache，Llama 3.1 70B 首 token 延遲最多降 77%
SageMaker 即時推論端點新增 `PREFIX_AWARE`，讓相同系統提示、文件或對話歷史盡量落到同一實例。官方七節點測試顯示長前綴工作負載明顯受益，但序列化差異、熱門前綴與快取容量仍會左右實際成效。
Amazon SageMaker Inference 新增前綴感知路由，處理多實例 LLM 服務中「框架支援 prefix caching，負載平衡器卻讓快取失效」的問題。傳統隨機或最少未完成請求路由，可能把帶有相同系統提示、RAG 文件或對話歷史的請求分散至不同 GPU；每個實例因而重新執行 prefill，無法重用已計算的注意力 key-value 張量。
新的 `PREFIX_AWARE` 策略會依請求開頭建立穩定映射，將共享前綴送往同一實例。工程師可設定 `PrefixLength`，原生 Invoke API 以 1,024 至 65,536 bytes 計算，OpenAI 相容介面則以訊息文字字元計算；`ConcurrencyThreshold` 可設為 1 至 1,024，當目標實例過載時犧牲一次快取命中、改送較空閒節點。多租戶服務另可用 `X-Amzn-SageMaker-Prefix-Aware-Id` 或 `prompt_cache_key` 隔離路由群組，功能亦能與 inference components 及動態 LoRA adapter 共用。
AWS 以七部 `ml.p5.48xlarge`、vLLM 和 Llama 3.1 70B 測試。8,000-token 共用前綴情境中，P50 首 token 時間降低 71% 至 77%，P90 降低 33% 至 37%，KV cache 命中率約由 25% 升至 82%，吞吐量增加 15% 至 16%；較短、長度不一的 ShareGPT 型對話，吞吐增益只有 1.7% 至 2.0%。路由本身增加約 1.3 至 1.9 毫秒。
這不是自動保證的模型加速：容器仍須啟用 prefix caching，而且原生 API 直接比較請求 bytes，JSON 空白、欄位順序或把取樣參數放在前方，都可能拆散本應共享的流量。前綴設太短也可能形成熱點。部署者應按真實提示分布調整兩項參數，並同時監控命中率、溢流比例、TTFT 尾延遲與擴縮容後的快取暖機時間。