Subaru 云原生 AI 案例为什么把镜像分发作为重点

Subaru 的云原生 AI 案例把镜像分发放在显眼位置，原因很直接：大型 ML/CUDA 镜像处在训练和推理任务启动前的关键路径上。镜像没有拉完，GPU Pod 就不能真正进入计算；当单个镜像超过 30GB、一次拉取可能持续数小时，后面的数据处理、训练和推理优化得再快，也会被启动等待抵消。

CNCF 案例显示，Subaru 将这类大型镜像的拉取时间从约 3 小时缩短到约 3 分钟，约为原来的 1/60。这个结果比“换了哪些云原生组件”更值得注意：它说明 AI 平台的首要瓶颈未必在 GPU 算力，也可能在每次任务开始前重复发生的制品交付。

官方案例地址：https://www.cncf.io/case-studies/subaru/

案例中最显著的变化不是模型，而是启动等待

这项案例面向 Subaru 下一代 EyeSight 的 AI 研发。团队在本地 GPU 环境中反复进行图像数据处理、模型训练、制品生成和推理，需要快速、可重复地启动大量工作负载。平台使用 Kubernetes，并引入 Argo CD、Argo Workflows、Envoy Gateway、MetalLB、Helmfile 与 Harbor 等组件。

如果只看工具清单，很容易把重点理解成“又一个 Kubernetes 平台案例”。但 CNCF 公布的三个结果其实对应三类不同问题：

镜像分发之所以排在前面，是因为它最先阻塞工作负载，也是案例中改善幅度最直观的一项。GitOps 和工作流编排解决的是一致性与可重复性，但在 Pod 连镜像都拿不到时，这两层能力还无法进入真正的执行阶段。

大镜像为什么会卡住 AI 迭代

普通 Web 服务的镜像通常不会装入完整 CUDA 运行时、大量系统库和深度学习依赖。AI 研发镜像则可能包含 GPU 驱动兼容层、CUDA 库、Python 环境、框架及项目依赖，体积很容易膨胀。Subaru 案例中的 ML/CUDA 镜像经常超过 30GB。

镜像大本身不是唯一问题，更重要的是它会放大三个工程效应：

• 启动延迟进入每次迭代。训练任务、推理任务或流水线阶段调度到尚无镜像的节点时，必须先完成拉取。
• 等待状态难判断。案例中团队提到，超过 3 小时的拉取让工程师难以分辨系统仍在正常工作，还是已经发生故障。
• GPU 资源被动空转。昂贵的 GPU 节点虽然已分配给任务，但任务可能还在等待制品，实际计算尚未开始。

因此，镜像拉取不是“平台外围的运维细节”，而是 AI 开发周期的一部分。只要任务调度频繁、节点缓存命中不稳定或镜像更新较多，这段等待就会不断出现。优化它，等于直接缩短工程师从提交任务到开始计算的时间。

Subaru 做的不是简单换仓库，而是缩短整条网络路径

按照 CNCF 的描述，Subaru 使用 Harbor 作为容器镜像仓库，并通过 Envoy Gateway 与 Gateway API 管理镜像仓库流量。关键点不只是“有一个私有仓库”，而是让镜像数据从仓库到节点的路径更直接。

案例列出的架构动作包括：

1. 将 Envoy Gateway 以 hostNetwork 模式部署，减少镜像拉取路径上的网络开销。
2. 尽可能把需要相互通信的工作负载调度到同一节点，让流量保持在本地。
3. 结合基于 MetalLB 的 LoadBalancer 配置，改善本地环境中的流量入口与带宽利用。

这里最值得迁移的不是某一条 YAML，而是优化顺序：先画出镜像从仓库到工作节点的真实路径，再确认数据经过多少转发、负载均衡与节点网络边界。若瓶颈来自绕行、转发开销或带宽利用不足，只压缩镜像层并不能完全解决问题。

同时也要避免过度解读。公开案例没有把改进归因于 P2P 分发、镜像预热或外部 CDN，因此不能擅自把这些方案写成 Subaru 的实践。案例明确强调的是 Harbor、Envoy Gateway、hostNetwork、同节点通信倾向和 MetalLB 共同形成的更高效网络路径。

镜像加速只是第一层，另外两层补齐可重复性

如果只有镜像加速，训练任务会更快开始，但部署状态和机器学习流程仍可能依赖人工操作。Subaru 同时处理了另外两个问题。

第一层是应用发布。原来的部署依赖人工执行调用 Helm 的 Shell 脚本，开发与生产环境差异也需要手动处理。团队使用 Argo CD 配合 Helmfile，把应用定义放入 Git，通过声明式方式管理环境状态。CNCF 案例显示，目前有 25 个应用定义通过这套 GitOps 流程管理。

第二层是机器学习工作流。数据准备、预处理、校验、训练、模型转换、制品存储和后续处理之间存在依赖，单纯启动一个 Pod 并不能表达完整关系。Argo Workflows 让这些阶段成为 Kubernetes 原生工作流，可以显式管理依赖，并在适合的环节并行执行。

三层能力的边界可以这样理解：镜像分发负责“制品能否及时到节点”，GitOps 负责“平台应用是否按声明保持一致”，工作流编排负责“训练过程能否按依赖重复执行”。它们不是互相替代的工具，而是分别消除启动等待、部署漂移和人工流程三类摩擦。

已有平台会受到什么影响

这个案例并不意味着所有 AI 团队都应立即复刻相同组件。如果镜像已经常驻节点，或者任务主要在固定节点运行，拉取时间可能不是首要矛盾；如果环境漂移频繁，GitOps 反而可能先带来更大收益；如果训练链路靠大量人工衔接，那么工作流编排可能最紧迫。

判断优先级时，可以先采集下面几组数据：

• 从 Pod 创建到容器真正开始运行的 P50、P95 和最大等待时间。
• 不同节点上的镜像缓存命中率，以及冷节点第一次拉取的耗时。
• 镜像大小、层复用情况、仓库出口带宽和工作节点入口带宽。
• GPU 已分配但任务尚未开始计算的空闲时长。
• 手工部署次数、环境配置漂移和机器学习阶段的人工交接次数。

如果“镜像拉取时间”占任务启动总时间的大头，就有理由先治理镜像路径；如果它只占很小比例，就不该因为一个成功案例而忽略调度、存储、数据读取或 GPU 利用率等更真实的瓶颈。

迁移时先做小范围验证，再决定是否扩展

比较稳妥的做法是选一类代表性的 ML/CUDA 镜像和一组 GPU 节点，建立冷启动基线，再逐项改变路径。验证时不要只看单次最快值，而要覆盖冷节点、并发拉取、不同镜像大小和网络高峰。

Subaru 案例真正传递的信号是：云原生 AI 平台不能只盯着模型训练框架和 GPU 调度。一个位于关键路径、每天反复发生的基础设施等待，可能比更换模型或增加算力更影响研发节奏。镜像分发被重点呈现，是因为它既是启动前置条件，又在该案例中给出了最明确的量化改善。

常见问题

镜像越小，就一定不需要优化分发路径吗？

不一定。镜像大小只是变量之一，并发拉取数量、节点缓存、仓库吞吐、网络绕行和跨节点流量同样会影响启动时间。应以冷启动和并发拉取数据判断。

GitOps 能替代机器学习工作流编排吗？

不能直接替代。GitOps 主要维护声明式应用状态，工作流编排负责表达数据准备、训练、转换和制品处理等阶段依赖，两者解决的问题不同。

是否应该照搬 hostNetwork 配置？

不建议直接照搬。它会改变网络与安全边界，需要结合集群网络、端口冲突、策略控制和运维方式评估。案例给出的是架构思路，不是适用于所有环境的默认配置。

这项优化是否等同于模型分发？

不是。案例重点是 ML/CUDA 容器镜像到 Kubernetes 节点的交付；模型权重、训练数据和其他制品可能走不同存储与分发路径，应分别测量。

参考资料

• CNCF Case Study：Subaru