SageMaker HyperPod模型缓存：冷启动从分钟级降至秒级

当你在 Amazon SageMaker HyperPod 上部署大语言模型（LLM）进行推理时，从请求 Pod 到 Pod 真正可以服务流量之间存在一段空档期。这段空档主要由两次顺序执行的下载构成：从 Amazon Elastic Container Registry（Amazon ECR）下载推理服务器容器镜像，以及从存储源（可以是 Amazon Simple Storage Service (Amazon S3)、Amazon FSx for Lustre 或 HuggingFace Hub）下载模型权重。对于较小的模型，这可能需要几分钟；对于像 DeepSeek-R1 这样 600+ GB 的大模型，单个请求可以开始服务之前需要等待 30 分钟甚至更久。每次扩容事件都会经历同样的下载周期，这意味着你的自动扩缩容响应时间受限于存储后端的网络吞吐量。

今天，我们为 Amazon SageMaker Inference on HyperPod 推出了模型缓存功能。模型缓存会在 Pod 需要之前预先将模型权重和容器镜像加载到集群节点上。启动 Pod 时，它可以从本地 NVMe 存储读取数据，速度约为 7 GB/s，而无需通过网络下载。启用模型缓存后，Pod 通常可以在几秒钟内开始服务流量，而不是几十分钟。在这篇文章中，我们将深入探讨冷启动问题、解释模型缓存的工作原理、展示如何启用它，并分享基准测试结果。

冷启动问题的详细解析

要理解模型缓存的重要性，先来看一下没有缓存时推理 Pod 启动所经历的过程。Kubernetes 调度器将 Pod 调度到某个节点上。Kubelet 开始从 ECR 拉取容器镜像。对于 vLLM 或 LMI 等推理服务器镜像，这些镜像体积庞大（数 GB），拉取需要 5–7 分钟。它们打包了 GPU 驱动、CUDA 库和服务框架。镜像就绪后，容器启动，推理服务器开始从配置的源下载模型权重。对于存储在 Amazon S3 上的 145 GB 模型，根据网络条件和可用带宽，这可能需要另外 20 分钟以上。对于像 DeepSeek-R1 这样 600+ GB 的模型，这需要 30 分钟以上。

在扩容期间，每个新 Pod 都会重复相同的过程。如果流量突增，HorizontalPodAutoscaler 请求五个新 Pod，这五个 Pod 都会独立地执行这个下载序列。自动扩缩容策略可能在几秒内做出反应。然而，实际服务额外流量所需的时间是 25–30 分钟以上，因为每个新 Pod 都要等待下载完成后才能接收请求。

模型缓存的工作原理

模型缓存通过在 Pod 被调度之前将数据预先加载到节点上来消除这两个延迟来源。它引入了两个独立的功能，可以单独启用，也可以同时启用。

权重缓存（weights cache）提前将模型权重下载到每个节点的本地 NVMe 存储上。启用后的工作流程如下：

你在 InferenceEndpointConfig 或 JumpStartModel 资源中添加 modelCacheConfig 并启用 weightsCache，然后应用配置。

HyperPod Inference Operator 自动创建一个 ModelDataCacheConfig 资源，并开始从配置的源（Amazon S3、Amazon FSx for Lustre、HuggingFace Hub 或 JumpStart）将模型权重下载到所有目标节点的本地 NVMe。

节点完成下载后，Operator 会将该节点标记为 cache-ready（缓存就绪）。

Operator 会等待所有目标节点都变为 cache-ready 后才创建推理部署，这样你的 Pod 始终可以访问本地数据。

启动 Pod 时，它从本地 NVMe 存储读取数据，速度约为 7 GB/s，而不是通过网络下载。

配置的缓存在同一节点上 Pod 重启后仍然可用。在扩容期间，如果新 Pod 被调度到已经缓存了权重的节点上，它们可以立即启动。

镜像缓存（image cache）将推理服务器容器镜像预先拉取到节点上，这样 Pod 不必等待 ECR 下载。启用后的工作流程如下：

你在资源中添加 modelCacheConfig 并启用 imageCache，然后应用配置。

Operator 创建一个 DaemonSet，将容器镜像拉到所有目标节点上。

Operator 立即创建推理部署。与权重缓存不同，镜像缓存不会阻止部署创建。

当启动一个镜像已经缓存的 Pod 时，它完全跳过 ECR 拉取，节省 5–7 分钟。

当在节点上的镜像缓存尚未完成时启动 Pod，它会正常从 ECR 拉取。

多个使用相同容器镜像的部署共享同一个镜像缓存资源。Operator 会跟踪引用关系，只有当没有部署再引用该缓存镜像时才会清理。

两种缓存功能都使用优先调度（preferred scheduling）而非强制调度（required scheduling）。Pod 优先调度到有缓存数据的节点，但绝不会因为缺少缓存而被阻塞。当调度器将 Pod 调度到没有预热缓存的节点上时（例如， rapid scale-out 期间新 Pod 数量超过了有缓存节点的数量），它会从原始的 Amazon S3/Amazon FSx 源读取权重，并从 Amazon ECR 拉取镜像。这与未启用缓存的 Pod 行为相同。不会失败、不需要用户干预、不会出现降级行为——只是需要正常的下载时间。

架构与 CRD

Operator 引入了两个自定义资源定义（CRD）来管理缓存生命周期。启用缓存时，Operator 会自动创建和管理这些资源。你不需要直接创建它们。

ModelDataCacheConfig 管理模型权重缓存的完整生命周期。Operator 为每个启用了权重缓存的 InferenceEndpointConfig 或 JumpStartModel 创建一个。它控制以下操作：从源将权重下载到目标节点的本地 NVMe；下载完成后将节点标记为 cache-ready；监控缓存健康状态并在缓存不健康时移除节点标签；当父资源被删除时从所有节点清理缓存文件。

你可以随时查看权重缓存的状态：

kubectl get modeldatacacheconfig -n <namespace>

NAME                  STATE   TARGET   READY   AGE
example-model-cache   Ready   10       10      5m

ModelImageCache 管理容器镜像缓存的生命周期。它控制以下操作：将推理服务器镜像预先拉到所有目标节点；拉取完成后将节点标记为 image-ready；报告每个节点的拉取状态；当没有部署再引用缓存镜像时进行清理。

kubectl get inferenceimagecache -n hyperpod-inference-system

NAME                                  PHASE      CACHED   TARGET   AGE
iic-vllm-openai-ml-g5-24xlarge-a1b2   Complete   10       10       3m

当你更改模型源时（例如，指向带有更新权重的新 Amazon S3 路径），Operator 会创建一个新缓存、推出更新后的部署，然后清理旧缓存。镜像更改同理，确保零停机切换且没有残留数据。

如何启用模型缓存

通过在现有的 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"

JumpStartModel 示例

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: JumpStartModel
metadata:
  name: example-jumpstart-model
  namespace: default
spec:
  model:
    modelId: "meta-textgeneration-llama-3-1-8b-instruct"
    acceptEula: true
  server:
    instanceType: ml.g5.24xlarge
  modelCacheConfig:
    weightsCache:
      enabled: true
    imageCache:
      enabled: true

你可以独立启用任一功能。如果你只想缓存镜像，可以省略 weightsCache 或将其设为 false。权重缓存还支持可选的 hostPath 覆盖，如果你想使用非默认的 NVMe 挂载路径（默认是 /opt/dlami/nvme）。如果在 Amazon SageMaker JumpStart 上配置，该配置会在来自 Amazon SageMaker JumpStart 的每个部署中继承。

支持的模型源

模型缓存支持 HyperPod Inference 支持的所有模型源：

基准测试

针对 57–145 GB 模型的基准测试表明，启用权重缓存后，扩容速度提升约 60%。镜像缓存可以消除超过两分钟的冷镜像拉取时间，相比每次 Pod 启动时从 ECR 全新拉取，通常可以实现高达 97% 的时间节省。收益随模型大小而增长，因为需要通过网络下载的数据量相应更大。对于 DeepSeek-R1 等 600+ GB 范围的模型，你消除了原本需要 30 分钟以上的下载时间。

实例存储参考

由于模型缓存将权重存储在本地 NVMe 上，你的实例类型需要有足够的存储容量来容纳你的模型：

需要注意的限制

权重缓存是按节点划分的，这意味着每个节点维护自己的一份模型权重副本。这是设计如此，因为每个节点都需要本地访问，但 NVMe 消耗量会随节点数量增长。

初始缓存填充仍然需要从远程源下载。首次为某个模型启用缓存时，你需要支付一次下载成本。此后，该节点上的 Pod 从本地存储启动。

NVMe 存储是有限的。如果你的模型是 300 GB 而你的实例类型只有 250 GB 的 NVMe，缓存将无法工作。选择实例类型时要考虑模型大小。

源更新不会自动检测。如果你更新了同一 Amazon S3 路径上的模型文件但没有更改 InferenceEndpointConfig spec，Operator 将继续提供缓存版本。要获取新权重，请更新 spec（例如，更改模型路径或添加版本后缀）。

当你删除 InferenceEndpointConfig 或 JumpStartModel 资源时，Operator 会自动从集群中移除所有缓存数据、DaemonSet 和节点标签。无需手动清理，NVMe 存储会被释放给其他工作负载使用。

适用于 Amazon SageMaker HyperPod 上 Amazon SageMaker Inference 的模型缓存现已正式发布，在所有 Amazon SageMaker HyperPod 可用的区域均可使用。要开始使用它，请在现有部署 spec 中添加 modelCacheConfig 部分并应用即可。Operator 会处理其余工作。

完整文档请参阅 SageMaker HyperPod Inference 文档。