AWS 以 HyperPod 模型快取與前綴路由，瞄準 SageMaker 推論延遲
AWS 為 SageMaker HyperPod 加入模型快取，並為 SageMaker Inference 加入前綴感知路由，以追求更快的擴展與更低的 LLM 延遲。
AWS 正在新增兩項基礎架構功能，分別針對大型語言模型服務中的兩個相關但不同的瓶頸：Amazon SageMaker HyperPod 的模型快取，以及 SageMaker Inference 的前綴感知路由。前者旨在縮短將新的推論 Pod 上線所需的時間；後者則希望透過讓經常重複使用的 prompt 計算留在同一個執行個體上，來降低回應延遲。
這些變更對於在變動流量下營運大型模型的團隊最為重要。若沒有快取，擴展事件可能會要求新節點先下載數 GB 的容器映像與模型權重，才能開始服務請求。若路由未考量 prompt 內容，某個 serving framework 的前綴快取可能會因為相同的 prompt 區段分散到整個機群而使用率不高。
這兩項公告都來自 AWS Machine Learning Blog，因此效能數據與營運主張是由 AWS 提供，而非獨立驗證。整體而言，它們描繪出一種更協調的方法，用以同時降低推論冷啟動與穩態下首個 token 的時間。
HyperPod 快取解決擴展落差
AWS 表示，SageMaker HyperPod 上的模型部署可能因兩次連續下載而延遲。Kubernetes 會先從 Amazon Elastic Container Registry 拉取推論伺服器映像，之後伺服器再從 Amazon S3、Amazon FSx for Lustre、Hugging Face Hub 或 JumpStart 等來源下載模型權重。
對較小的模型來說，這個流程可能需要數分鐘。AWS 舉例指出，一個 145 GB 的模型，其權重下載依網路狀況可能需要超過 20 分鐘。對於像 DeepSeek-R1 這類在引述情境中被 AWS 描述為超過 600 GB 的模型，整個流程可能需要 30 分鐘或更久。僅容器映像的拉取，AWS 估計典型的多 GB 推論映像就要五到七分鐘。
這種延遲使 autoscaling 與實際容量產生落差。HorizontalPodAutoscaler 可能很快請求額外的 Pod，但這些 Pod 在映像與權重可用之前無法接收流量。因此，突發請求高峰可能觸發一個營運回應，卻要晚了數十分鐘才到。
新的模型快取能力會將權重預先載入到目標節點的本機 NVMe 儲存中。AWS 表示，HyperPod Inference Operator 會事先下載權重、將節點標記為可用快取，並在目標節點完成該流程後才建立推論部署。當 Pod 在準備好的節點上啟動後，它可以以約每秒 7 GB 的速度本機讀取，而不必透過網路下載模型。
AWS 也提供獨立的映像快取。DaemonSet 會先將推論容器映像預拉到節點上，讓後續 Pod 跳過從 Amazon Elastic Container Registry 的下載。使用相同映像的多個部署可以共享該快取，而 operator 則負責參照與清理。
兩種快取系統在生產環境中的行為
權重快取與映像快取並不具有相同的部署語意。AWS 表示，權重快取可能會延後推論部署的建立，直到所有目標節點都準備好；而映像快取則不會阻擋部署建立。因此，某個 Pod 可能在特定節點的映像快取尚未完成前就啟動，並回退到一般的映像拉取。
這兩種機制都採用偏好式而非強制式排程。Pod 會在可能時被導向具有暖資料的節點，但不會被禁止在其他地方執行。如果快速擴展超過已準備節點數量，Pod 仍可使用原始模型來源並正常拉取映像。取捨是啟動較慢，而不是部署失敗。
Operator 管理兩個底層自訂資源：用於模型權重的 ModelDataCacheConfig，以及用於容器映像的 ModelImageCache。使用者不是直接管理這些生命週期物件，而是透過 InferenceEndpointConfig 或 JumpStartModel 資源中的 modelCacheConfig 來啟用快取。
AWS 也表示，當模型來源或映像變更時，會處理快取更新。operator 會建立新的快取、推出更新後的部署，然後移除舊快取。這是為了避免過時權重，同時支援零停機轉換，不過實際結果仍取決於節點可用儲存空間，以及填充替代快取所需的時間。
前綴感知路由讓 LLM prompt 快取持續有用
第二項 SageMaker 變更瞄準的是 serving stack 的另一層。許多 LLM 請求都包含長而重複的前綴——例如系統指令、檢索文件、對話歷史或原始碼——後面接著一個短的使用者專屬後綴。像 vLLM 與 TensorRT-LLM 這類 framework 可以重用針對該重複前綴計算出的 key-value，或 KV 快取。
在多執行個體端點中，隨機分配請求會削弱這項優勢。若連續的相同前綴請求落到不同機器上，每個執行個體都可能必須重新計算共享上下文。SageMaker Inference 的新前綴感知路由策略會檢查請求開頭，並持續將匹配的前綴送到同一個執行個體。
AWS 表示，這項功能也能保護機群免於某個過於熱門的前綴。如果偏好的執行個體達到其設定的 concurrency 上限，請求可以改送到較不忙碌的執行個體。這可能會讓單一請求失去一次 cache hit，但可避免流量集中到單一機器。AWS 進一步表示，新增或移除執行個體時，應只移動有限比例的流量，有助於在擴展期間維持快取局部性。
此策略可針對每個 production variant 設定，並可透過端點設定變更，而無需重新部署模型。AWS 仍將隨機路由作為預設，同時也提供 least-outstanding-requests routing，適用於請求時間長度會變動的工作負載。前綴感知路由則是專門針對具有共享起始上下文且已啟用前綴快取的 LLM 工作負載。
證據、基準測試與限制
AWS 以 Llama 3.1 70B Instruct 在七台啟用 vLLM 與前綴快取的 ml.p5.48xlarge 執行個體上，比較前綴感知路由與隨機路由。在涵蓋不同端點與 API 配置的 16 組測試設定中，AWS 報告 median 首 token 時間最多降低 77%、吞吐量最高提升 16%，以及 KV 快取命中率從約 25% 提升到 80% 以上。
這些是供應商提供的基準測試結果，並非獨立評估。AWS 表示，在測試中流量保持平衡，每個執行個體收到 13.3% 到 15.4% 的請求。AWS 也報告每次請求額外的路由成本為 1.3 到 1.9 毫秒，相較之下，測試配置中的模型首 token 時間介於 63 到 280 毫秒。
效益大小高度取決於工作負載形態。AWS 表示，共享前綴越長，因為可跳過的計算越多，收益就越大。AWS 點名的使用情境包括：反覆查詢同一文件的 RAG 系統、多輪對話、範本式助理，以及程式碼補全。對於 prompt 較短或大多唯一的工作負載，價值應較低。
HyperPod 的主張同樣依賴一些來源中未完全說明的條件，包括節點可用性、快取填充時間、儲存容量、模型格式，以及初次預載期間的網路效能。從數十分鐘轉為數秒的說法，適用於 Pod 落在已經快取相關資料的節點上；未準備好的節點仍會走正常下載路徑。
這些變更對 AI 基礎架構團隊的意義
對建置者與企業平台團隊而言，這些公告把經常被當成單一延遲問題的兩個決策分開了。模型快取改善彈性：當流量增加時，它可以讓新容量更快派上用場。前綴感知路由改善請求效率：它可以在容量已經上線後，減少重複的 prefill 工作。
這種組合對既有突發流量又有大量重複上下文的 RAG 應用與助理可能很有幫助。團隊可以用 HyperPod 快取為擴展準備節點，同時使用前綴感知路由，讓文件或對話前綴在活躍機群中保持溫熱。不過，這並不能取代對本機 NVMe 容量的規劃、concurrency 上限設定，以及在真實流量下衡量 cache hit rate 的需求。
買家也應測試成本與可靠性問題。在每個目標節點上保留權重會消耗本機儲存，並可能增加部署就緒前的準備時間。前綴親和性可改善延遲，但也引入內容相依的路由行為，團隊應將其與佇列深度、執行個體使用率、快取佔用與尾延遲一起觀察。隱私與資料治理審查也可能很重要，因為路由決策會檢查請求負載的開頭，即使 AWS 是自動處理路由。
接下來要關注什麼
評估這些功能的團隊，應尋找在 AWS 的 Llama 3.1 70B 測試之外、針對不同模型、硬體與 prompt 分布的獨立重現結果。最有用的指標將包括 p95 與 p99 的首 token 時間、擴展期間的快取命中率，以及落到未準備節點上的請求比例。
關於本機 NVMe 容量規劃、快取預熱編排，以及多模型叢集的營運指引也會很重要。買家應驗證快取準備如何影響部署 rollout、節點替換、spot 或中斷情境，以及超出預載機群的快速擴展。
最後，隨著代管 serving 平台的競爭不再只看模型存取，而更看重可預測延遲，AWS 的端點層級路由控制可能會變得更加重要。接下來要看的訊號是，客戶是否能在不增加大量排程複雜性或犧牲平衡 GPU 使用率的情況下使用這些控制。
Creati.ai 觀點
AWS 正在處理 LLM 營運中的兩個實際弱點，而不是引入新的模型能力。HyperPod 模型快取降低了新增容量的代價，而前綴感知路由則讓既有的 serving 最佳化——KV 快取重用——在多個執行個體之間更可靠。
最有力的案例是可預期、且具有重複上下文的工作負載，只要流量足以證明預載大型模型的合理性。對於多數 prompt 都是唯一內容或部署不頻繁的團隊而言，儲存與準備的額外成本可能會超過收益。AWS 的基準數據令人鼓舞，但在把快取視為保證改善之前，基礎架構買家應先以自己的 prompt 重疊、擴展模式與延遲目標來驗證。
