摘要： AWS 在 2026 年 9 月 10 日為 SageMaker HyperPod 推出模型快取，事先把模型權重與容器映像放進節點 NVMe。權重快取會等目標節點 cache-ready 才建立部署，映像快取則不阻擋部署，兩者都採偏好排程並保留冷節點回退。AWS 基準顯示 57 到 145 GB 模型的擴容速度約提升 60%，映像拉取減幅最高 97%。
冷啟動為何慢：兩次下載串在前面
在 Amazon SageMaker HyperPod 上部署大型語言模型時，Pod 被排到節點上，並不代表馬上就能服務流量。前面卡著兩段依序發生的下載：第一段是從 Amazon ECR 拉取推論伺服器的容器映像，第二段才是模型權重，來源可能是 Amazon S3、Amazon FSx for Lustre 或 HuggingFace Hub。AWS Machine Learning Blog 給的數字是：小模型幾分鐘就能完成，但像 DeepSeek-R1 這類超過 600 GB 的模型，權重光下載就要 30 分鐘以上。
而這個循環在每次擴容時都得重跑一遍。假設 HorizontalPodAutoscaler 因為流量尖峰決定增加五個 Pod，這五個 Pod 會各自跑完一次同樣的下載流程，結果是真正能接流量的時間取決於網路吞吐量，而不是排程器多快做出決定。
模型快取的作用機制
AWS 在 2026 年 9 月 10 日發表模型快取功能，做法是事先把權重與容器映像放進節點本地的 NVMe 儲存。Pod 啟動後直接向 NVMe 讀取，速度約 7 GB/s，不必再走網路。啟用之後，Pod 通常幾秒內就能開始服務流量。
這項功能由兩個彼此獨立的能力組成，可以單獨啟用，也可以同時開啟：
權重快取：操作員會建立 ModelDataCacheConfig 資源，把權重從來源下載到每一個目標節點的 NVMe。某個節點下載完成後就會被標記為 cache-ready，而操作員會等所有目標節點都就緒，才建立推論部署。這份快取在 Pod 重啟後依然保留，因此擴容時若新 Pod 排到已經有快取的節點，就能立刻啟動。
映像快取：操作員改以建立 DaemonSet，將推論伺服器的容器映像預先拉進所有目標節點。它的行為和權重快取不同，不會擋住部署建立；若 Pod 啟動時映像已經快取好，就跳過 ECR 拉取，可省下 5 到 7 分鐘。多個部署若共用同一個映像，也會共用同一份映像快取，操作員會一路追蹤引用狀況，直到沒有任何部署引用它才進行清理。
兩種快取走的都是「偏好排程」而非「強制排程」。Pod 會盡量排到有快取的節點上，但不會因此被擋住；萬一落到沒有暖快取的節點，就回頭走原本的下載流程，表現和完全沒啟用快取時一樣。
怎麼啟用，支援哪些來源
啟用的門檻不高：只要在現有的 InferenceEndpointConfig 或 JumpStartModel 資源裡補上 modelCacheConfig 區段即可，不需要另外準備基礎設施。以下是一段 InferenceEndpointConfig 範例：
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
name: example-model
namespace: default
spec:
modelName: example-model
modelSourceConfig:
modelSourceType: s3
s3Storage:
bucketName: example-bucket
region: us-west-2
modelLocation: "models/example-model"
modelCacheConfig:
weightsCache:
enabled: true
imageCache:
enabled: true
instanceType: ml.g5.24xlarge
worker:
image: vllm/vllm-openai:latest
modelInvocationPort:
containerPort: 8000
modelVolumeMount:
name: model-weights
mountPath: /opt/ml/model
resources:
limits:
nvidia.com/gpu: "4"模型快取的支援範圍涵蓋 HyperPod Inference 所有可用的模型來源，包含 Amazon S3、Amazon FSx for Lustre、HuggingFace Hub，以及 Amazon SageMaker JumpStart（含 gated 模型）。
基準數據與必須留意的限制
根據 AWS 的基準測試，模型大小落在 57 到 145 GB 時，開啟權重快取能讓擴容速度提升約 60%。映像快取則能省下超過兩分鐘的冷映像拉取時間，相較於每次 Pod 啟動都重新從 ECR 拉取，減幅最高可達 97%。模型體積越大，好處越明顯，因為能省下的下載量本來就更多。
不過有幾項限制必須先想清楚：
- 權重快取以節點為單位，每個節點各存一份，NVMe 用量會隨節點數量呈線性成長。
- 快取第一次建立時，仍得向遠端來源完整下載一次，之後才能改讀本地。
- NVMe 容量是硬限制，模型大小不能超過執行個體提供的 NVMe。以 ml.g5.xlarge 為例，它只有 250 GB，300 GB 的模型就放不下。
- 來源端的更新不會被自動偵測。若你在同一條 Amazon S3 路徑覆蓋權重檔，卻沒有更動 InferenceEndpointConfig spec，操作員會繼續提供快取中的版本。想拿到新權重，就必須更新 spec，例如改路徑或加上版本後綴。
對打造產品的人來說意味著什麼
模型快取處理的是推論擴容延遲中的「最後一哩」。以往就算 autoscaler 幾秒內就做出反應，真正能接流量的時間還是被下載拖著走。如今權重與映像都預載到節點上，擴容的瓶頸從「等網路」換成了「等排程」。對於需要迅速吸收流量尖峰的產品，例如即時對話或批次推論服務，這個差別特別有感。
如果你正在評估 SageMaker HyperPod 的推論部署，不妨一併看看前綴感知路由：讓 KV cache 不再被隨機打散，那篇文章談的是另一個降低推論延遲的機制。兩者並不衝突，反而互補：冷啟動交給模型快取，熱啟動時的 cache 效率交給前綴感知路由。
在正式採用之前，建議先確認執行個體的 NVMe 容量足以容納模型權重，同時把權重更新的流程規劃好，免得快取反而造成版本不一致。