SageMaker AI支持SOCI索引镜像：训练作业懒加载镜像，AWS称镜像拉取期间GPU空闲最多减少90%

AWS 于 2026 年 10 月 29 日宣布，Amazon SageMaker AI 的训练和处理作业支持 SOCI（Seekable OCI）索引的容器镜像。AWS 称，这能让训练容器在几秒内启动，把拉取镜像期间的 GPU 空闲时间最多减少 90%，训练性能除首个 epoch 的一次性代价外不受影响。90% 是 AWS 在自己的基准测试中得出的“最多”值，不是对所有作业的保证。

问题出在作业开始之前。SageMaker AI 要先把容器镜像整个下载到实例上，解压并写入每一层，深度学习镜像常常超过 10 GB，这一步给每个作业增加几分钟，而且这段时间要计费。超参数搜索要跑成百上千个作业、短实验和短处理作业受影响最大，因为下载可能占掉大部分运行时间。

SOCI 是一项开源的懒加载技术。SOCI 索引是一份映射镜像内每个文件的元数据，作为符合 OCI 标准的工件存放在 Amazon ECR 中并关联到原镜像，所以镜像摘要和既有签名仍然有效。作业带有索引时，SageMaker AI 只取启动容器所需的文件，其余部分在代码运行时在后台流式加载。系统会自动检查镜像有没有索引：有就懒加载；没有就按原样完整下载；索引不可用或懒加载失败时，作业回退到标准下载并继续运行，所以加索引不会让作业跑不起来。

使用有两种方式。一是用 AWS 已预先建索引的深度学习容器，把镜像标签改成带 -soci 后缀的版本；AWS 的发布博客说目前有 PyTorch 训练、TensorFlow 训练、vLLM 和 SGLang，部分框架还有 arm64 版本。二是给自己的镜像加索引：需要一台装有 containerd、SOCI snapshotter 以及 Finch 或 nerdctl 的 Linux 主机，不必重建镜像。作业定义、入口点和数据通道都不用改。需要留意，基于 DLC 基础镜像自己构建的镜像必须为最终镜像单独建索引，基础镜像的索引不会传递给衍生镜像，镜像还必须放在私有 ECR 仓库里。该功能在所有提供 SageMaker AI 的区域可用，可通过 API、CLI、SDK 和控制台使用。

AWS 在发布博客中给出了自己的测量。测试使用 8 个压缩后 1.8 至 35.4 GB 的镜像，覆盖 ml.g4dn 到 ml.p5 等多种实例，在美国西部（俄勒冈）和美国东部（弗吉尼亚北部）两个区域运行，数字为多次运行的中位数。1.8 GB 的镜像从 48 秒降到 3 至 11 秒，13.2 GB 从 3 分 42 秒降到约 6 秒，35.4 GB 从 7 分 17 秒降到 3 至 11 秒。同一个 13.2 GB 镜像在 13 种实例类型和规格上，标准下载为 3 分 16 秒至 4 分 20 秒，懒加载稳定在 6 至 8 秒。博客自己的概述对倍数的写法并不一致，分别出现约 10 倍、8 倍和 8 至 46 倍，表格里是约 8 倍到约 38 倍，引用时以具体秒数为准。

训练本身有一次性的代价。AWS 用 ResNet-50（Imagenette，9,469 张图）和对 Qwen2.5-0.5B 在 51,760 个样本上的全参数微调做了对比：从第二个 epoch 起每个 epoch 耗时相同，第一个 epoch 要多花 3 至 16 秒，用来按需取回首次访问的文件，每个作业总体提前约 1 至 6 分钟结束。如果入口程序在训练前就读取镜像的大部分内容，比如扫描、校验或预加载，收益会变小。AWS 的测试里，torch.compile 和即时编译的 CUDA 扩展让首个 epoch 增加 7 至 15 秒，一个 6 GB 的模型打包进镜像并在加载时流式读取，增加 2 至 3.5 分钟，作业仍早结束 2 至 2.5 分钟。

AWS 的测试细节也值得看。图像分类用 ResNet-50 在 Imagenette 的 9,469 张图片上训练，使用 13.2 GB 的 PyTorch DLC 和 9.9 GB 的 TensorFlow DLC，实例包括 ml.p5.48xlarge、ml.p4d.24xlarge、ml.g7e.48xlarge、ml.g7.48xlarge 和 ml.g6e 的几种规格；大模型微调用 9.4 GB 的 Hugging Face PyTorch DLC，在 ml.p5.48xlarge、ml.p4d.24xlarge 和 ml.g6.48xlarge 上运行。AWS 还提醒，懒加载在第一个训练步只需要镜像一小部分时最划算，其余部分边训练边下载；这也意味着它对超参数搜索和短作业最有价值，对本来就很小的镜像价值有限。

博客还补充了前置条件下的数字：即使入口程序在训练前就做了大量工作，AWS 的测试仍然显示净收益。torch.compile 加上即时编译的 CUDA 扩展让首个 epoch 多出 7 至 15 秒，作业的净节省仍有 3 分 25 秒至 3 分 56 秒；把 6 GB 的模型权重打包进镜像、在加载时流式读取，首个 epoch 多出 2 至 3.5 分钟，作业仍早结束 2 至 2.5 分钟。AWS 同时指出，这对包含数百个作业的超参数搜索、快速实验和短处理作业价值最大，因为下载时间在其中占比最高。另外，AWS 的页面把适用范围写得很明确：训练作业和处理作业都支持，只需在 API、CLI、SDK 或控制台里引用带索引的镜像，不必改动作业定义、入口点或数据通道，这也是迁移成本低的原因。

这些都是 AWS 在两类工作负载上的测量，首个 epoch 的代价取决于你的镜像和启动时访问的文件，建议在自己的作业上实测。