摘要

  • AWS 于 9 月 11 日推出 HyperPod 模型缓存，权重缓存与镜像缓存可以分别启用，文档中的默认值均为关闭。
  • 权重副本保存在节点本地；调度优先选择已预热节点，但不强制只选热节点。冷节点和替换节点仍需要准备自己的数据。

推理扩容购买的不只是算力，还包括让新增副本具备服务能力之前的准备时间。容器镜像和模型权重如果都要重新下载，机器已经加入集群，也未必马上能接住请求。Amazon SageMaker HyperPod 的新缓存功能，试图减少同一个节点上重复发生的这部分工作。

9 月 11 日的公告把能力分成两项。权重缓存把模型文件放在节点本地的 NVMe 存储中，避免反复从 Amazon S3 或 Amazon FSx 搬运。镜像缓存则提前拉取推理容器镜像，使后续启动避开冷态的镜像下载。客户通过推理操作器选择开启其中一项或两项；配置存在，并不表示默认已经开启。

AWS 称，在使用 57 GB 至 145 GB 模型的基准测试中，扩容速度提升约 60%；镜像缓存另将镜像拉取阶段缩短两分钟以上，该阶段耗时下降 97%。两个数字的分母不同，不能相加，也不能直接写成用户请求延迟下降或客户已经实现的账单节省。本篇没有独立复现这些测试。

权重缓存有明确的硬件前提。实例需要在指定路径提供本地 NVMe，并有足够空间容纳模型。仅使用 EBS 的实例不支持这一权重缓存；本地存储条件不符合时，部署可能仍从远端加载，而不会真正获得热缓存。镜像缓存可以独立启用，因此镜像已经准备好，也不能证明权重已就位。

更值得关注的是调度选择。操作器会在符合部署调度条件的节点上预热，并给完成准备的节点加上标记。推理部署优先调度到这些节点，但也允许放到其他节点。Kubernetes 对这类优先亲和性的解释是：它属于结合其他调度要求使用的偏好，不是禁止替代位置的硬性规则。这里引用的是通用机制，不据此推定 HyperPod 使用哪个 Kubernetes 版本。

所以，同一个启用了缓存的部署中，仍可能同时存在本地复用和冷态回源两条路径。如果副本落到尚未缓存权重的节点，它会从原始来源加载。这个退路使热缓存不成为启动的强制前提，却没有消除源端可达性的依赖。AWS 的故障排查说明仍列出了下载失败，以及无法访问 S3 或 FSx 的情况。

节点替换也会改变已准备容量的分布。新节点需要重新预热；文档描述的情况下，既有热节点继续提供服务。但本地文件已经存在，不等于模型已装入 GPU 显存，更不等于为下一次流量突增预留了足够推理能力。只数缓存就绪标记，无法独立证明服务容量也已就绪。

目录隔离还不等于存储容量隔离。每个部署使用自己的缓存目录，同一节点上的多个部署各自消耗 NVMe 空间。AWS 对磁盘压力的建议包括分开实例组或减少并发缓存部署。这是文档提示的运营条件，不是本篇发现了某个客户的故障。

按照公告，功能已在所有提供 HyperPod 的区域正式可用。它最终能带来多少商业价值，取决于工作负载能多频繁地复用合格、已准备的节点，而不是配置开关本身。

来源