AI辅助整理：本文基于下方列出的公开原始来源改写，不代替原文。
核心摘要： AWS官方博客宣布，Amazon SageMaker Inference on HyperPod正式推出模型缓存功能，把模型权重与推理容器镜像提前预载到集群节点本地NVMe。官方称，启用后Pod通常可在数秒内开始服务流量，而非数十分钟；权重缓存让扩容速度约提升60%，镜像缓存相比每次从ECR拉取最多减少约97%的冷启动时间。对600GB以上的DeepSeek-R1级模型，相当于省掉原本30分钟以上的下载等待。
业务背景：扩容策略很快，接流量很慢
在SageMaker HyperPod上部署大模型推理时，从请求Pod到真正能服务流量之间存在一段空档。官方指出，这段空档主要由两次串行下载构成：从Amazon ECR拉取推理服务容器镜像，以及从S3、FSx for Lustre或HuggingFace Hub下载模型权重。
小模型可能只需几分钟，但像DeepSeek-R1这样600GB以上的模型，官方称要等30分钟甚至更久才能服务第一个请求。每一次扩容事件都会重复同样的下载周期，自动扩缩容的响应速度实际上被存储后端的网络吞吐卡住。
问题：扩容请求发出后，流量仍在排队
官方给出的典型场景是：流量突增时HorizontalPodAutoscaler请求五个新Pod，五个Pod各自独立走一遍下载流程。扩缩容策略可能几秒内就做出反应，但真正能承接额外流量的时间是25到30分钟以上。
对客服、营销活动或经营看板这类有明显高峰的业务，这段等待直接表现为排队、超时或转化流失，而不是一个纯粹的技术指标。
AI怎么落地：把权重和镜像提前放到本地NVMe
模型缓存提供两个可独立启用的能力。权重缓存会提前把模型权重下载到每个节点的本地NVMe，节点下载完成后被标记为cache-ready，运维组件会等所有目标节点就绪后再创建推理部署，确保Pod总能读到本地数据。
镜像缓存则通过DaemonSet把推理服务镜像预拉到目标节点，与权重缓存不同，它不会阻塞部署创建。Pod启动时若镜像已在本地，就完全跳过ECR拉取。两种缓存都采用优先调度而非强制调度，即使Pod落到没有缓存的节点，也会回退到正常下载路径，不会失败。
实施步骤：改一段配置即可启用
官方说明，启用方式是在现有的InferenceEndpointConfig或JumpStartModel资源中增加modelCacheConfig段落，分别打开weightsCache与imageCache，无需额外搭建基础设施。运维组件会自动创建并管理ModelDataCacheConfig与ModelImageCache两类资源。
权重缓存支持可选的hostPath覆盖，默认路径为/opt/dlami/nvme。当模型来源变更时，系统会创建新缓存、滚动更新部署并清理旧缓存，官方称可实现零停机切换且不残留旧数据。
结果证据与边界
官方基准显示，57至145GB模型启用权重缓存后扩容速度约提升60%；镜像缓存可省去两分钟以上的镜像拉取时间，相比每次从ECR拉取最多减少约97%。对600GB以上模型，相当于省掉原本30分钟以上的下载等待。
边界同样明确：权重缓存按节点存储，NVMe占用随节点数增长；首次启用仍需支付一次下载成本；NVMe容量不足时缓存无法工作；同一S3路径更新模型文件不会被自动识别，必须修改配置才能生效。
可复制动作
第一，按模型体积核对实例NVMe容量，避免出现300GB模型配250GB存储的情况。第二，先在非生产环境启用缓存，测量首次填充耗时与后续扩容表现。第三，把模型更新流程与配置变更绑定，避免缓存版本与预期不一致。
证据与边界
- 官方称启用模型缓存后，Pod通常可在数秒内开始服务流量，而非数十分钟。
- 官方基准显示，57至145GB模型启用权重缓存后扩容速度约提升60%。
- 官方称镜像缓存相比每次从ECR拉取最多减少约97%的冷启动时间。
- 官方称对600GB以上模型如DeepSeek-R1，相当于省掉原本30分钟以上的下载等待。
- 官方提示权重缓存按节点存储，NVMe容量随节点数增长，实例类型需按模型体积选择。
企业今天可以做什么
建议先盘点现有推理实例的NVMe容量与模型体积是否匹配，再在非生产环境启用权重缓存与镜像缓存，观察首次缓存填充的下载成本与后续扩容表现。同时注意官方提示：若在同一个S3路径更新模型文件而不修改配置，系统会继续使用缓存版本，必须通过修改路径或加版本后缀来触发更新。