Amazon SageMaker HyperPod 推出模型缓存功能，将推理冷启动从数十分钟压缩至秒级

大语言模型推理部署中，冷启动延迟一直是制约弹性扩容的核心瓶颈。当 Kubernetes 调度器将推理 Pod 分配至某个节点后，系统需要先从 Amazon ECR 拉取包含 GPU 驱动、CUDA 库和推理框架的多 GB 级容器镜像，这一步骤通常耗时 5 至 7 分钟。随后，推理服务器才开始从配置的存储源下载模型权重。对于 145 GB 的模型，下载时间可能超过 20 分钟；对于 DeepSeek-R1 等 600 GB 以上的超大模型，等待时间更可突破 30 分钟。

自动扩容场景下，上述问题被进一步放大。当流量峰值触发 HorizontalPodAutoscaler 同时创建多个新 Pod 时，每个 Pod 都需要独立完成完整的下载流程。尽管扩容策略本身可以在数秒内做出响应，但实际开始承接新流量的时间仍需等待所有 Pod 完成下载，整体延迟可达 25 至 30 分钟以上。这意味着自动扩容的策略灵敏度与实际服务能力之间存在严重的时间错位，在突发流量场景下尤为明显。

HyperPod 模型缓存功能引入了两项可独立启用的缓存机制。权重缓存由 HyperPod Inference Operator 自动创建 ModelDataCacheConfig 资源，提前将模型权重从 S3、FSx for Lustre、HuggingFace Hub 或 JumpStart 下载至各节点本地 NVMe 存储，并在下载完成后为节点打上缓存就绪标签。Operator 会等待所有目标节点均达到缓存就绪状态后，才创建推理部署，确保 Pod 始终能够访问本地数据，读取速度约为 7 GB/s。

镜像缓存机制则通过创建 DaemonSet 将推理服务器容器镜像预先拉取至所有目标节点，使 Pod 启动时可跳过 ECR 拉取步骤，节省 5 至 7 分钟。与权重缓存不同，镜像缓存不会阻塞部署的创建过程。若某节点在镜像缓存完成前就被调度了 Pod，系统会自动回退至从 ECR 正常拉取的流程，不会造成任何服务中断。多个使用相同容器镜像的部署可共享同一镜像缓存资源，Operator 会追踪引用关系，仅在无部署引用时才清理缓存。

两种缓存机制均采用优先调度而非强制调度策略，Pod 会优先被调度至已有缓存数据的节点，但不会因缓存未就绪而被阻塞启动。当快速扩容超出已缓存节点数量时，新 Pod 会自动回退至从原始存储源下载的方式，行为与未启用缓存时完全一致，不存在额外的故障风险。用户可通过 kubectl 命令随时查看 ModelDataCacheConfig 和 ModelImageCache 资源的状态，包括目标节点数、已就绪节点数及缓存阶段等信息，便于运维监控。

启用模型缓存只需在 InferenceEndpointConfig 或 JumpStartModel 资源中添加 modelCacheConfig 配置项，分别开启 weightsCache 和 imageCache 选项即可，其余生命周期管理均由 Operator 自动完成。当模型权重更新时，Operator 会创建新缓存、滚动更新部署，并在完成后清理旧缓存，整个过程对用户透明。这一功能对于需要频繁扩容或多模型并行部署的生产环境具有显著的工程价值，尤其适合对推理延迟和扩容响应速度有严格要求的业务场景。

要点

• HyperPod 模型缓存将推理 Pod 冷启动时间从 30 分钟以上压缩至数秒，核心原理是以约 7 GB/s 的本地 NVMe 读取替代网络下载
• 权重缓存与镜像缓存两项机制相互独立，可按需单独或组合启用，分别解决模型权重下载和容器镜像拉取两大延迟来源
• 两种缓存均采用优先调度策略，缓存未就绪时自动回退至正常下载流程，不影响服务可用性，无需人工干预
• 多个部署可共享同一镜像缓存资源，Operator 自动管理缓存生命周期，包括模型更新时的滚动替换与旧缓存清理
• 该功能对 DeepSeek-R1 等超大规模模型的弹性扩容场景价值尤为突出，可显著缩短自动扩容策略响应与实际服务能力之间的时间差