模型天天要验证，30 GB 镜像却要拉三小时——怎么压到 3 分钟

• 2026/8/3
• 阅读时间 3 分钟

目录

KubeCon Japan 2026 刚落幕，CNCF 宣布 Subaru 拿下 End User Case Study 竞赛冠军——故事不是车企上云那一套，而是斯巴鲁怎么给下一代 EyeSight（ADAS 辅助驾驶）的 AI 研发平台减负

数字很扎眼：30 GB 以上的 ML/CUDA 镜像，pull 从约 3 小时 缩到约 3 分钟，官方口径 60 倍。同时用 GitOps 管 25 个应用定义，ML 流水线端到端自动化

完整架构和下游结果见 CNCF Case Study

为啥现在要关注

AI 训练/推理团队迟早会碰到同一组 基建问题，跟是不是造车无关：

1. 镜像越来越大——CUDA 基础镜像 30 GB 起步，Pod 起不来，工程师分不清「还在拉」还是「已经挂了」
2. 部署还在手工跑脚本——在命令行里敲 Helm，dev/prod 搞混是真实运营风险
3. ML 流水线阶段多、依赖杂——数据预处理、校验、训练、转模型、存 artifact、下游处理，缺统一编排就难谈可复现

斯巴鲁的场景是 on-prem GPU 集群 上做 EyeSight 下一代模型的数据→训练→推理闭环。瓶颈不在有没有 Kubernetes，而在 大镜像怎么快拉、应用怎么 declarative 交付、ML workflow 怎么在集群里串起来

这条 case 的价值：不是安利某一家云厂商，而是 CNCF 项目组合怎么解真实 AI 平台痛点——Envoy Gateway、Gateway API、MetalLB、Harbor、Argo CD、Helmfile、Argo Workflows 各干一段

三个坑，他们怎么填

坑一：大镜像 pull 拖垮开发节奏

现象：CUDA 镜像超 30 GB，Pod 启动前光 pull 就要 3 小时+，训练/推理周期变得不可预测。团队原话——「超过三小时的时候，很难判断系统是正常工作还是已经出错了」

解法不是换更大的盘，而是 缩短镜像从 Harbor 到节点的网络路径：

• Harbor 作容器 registry
• Envoy Gateway + Gateway API 管 registry 流量路由
• Envoy Gateway 以 hostNetwork 模式部署，减少路径上的网络开销
• 尽量把需要通信的工作负载 调度到同一节点，流量走本地
• MetalLB 提供 LoadBalancer，把路径和带宽利用做实

结果：同样 30 GB+ 镜像，pull 约 3 分钟。Pod 起得快，GPU 空转和干等不确定都少一截

坑二：部署靠手工脚本，GitOps 上不来

现象：部署流程是 手动执行 shell 调 Helm，能跑，但难标准化、难 declarative，dev/prod 差异靠人肉记，误部署是运营挑战

解法：Argo CD + Helmfile，在现有 Helm chart 资产上叠 GitOps——应用定义进 Git，Argo CD 负责同步。团队管 25 个应用定义，部署可复现、环境间一致性上去一截

坑三：ML 流水线缺统一编排

现象：数据准备、预处理、校验、训练、模型转换、artifact 存储、下游处理——阶段多、依赖明，但没有 Kubernetes 原生方式串起来

解法：Argo Workflows，把整条 ML 流水线定义成 K8s-native workflow，阶段依赖显式声明，可并行处并行，减少手工介入，为 可复现的模型迭代 打底

60 倍拉镜像：值得拆的网络直觉

这个数字最容易被写成斯巴鲁优化了 Kubernetes——说白一点，核心是 registry 到 kubelet 这条链路上的多余中转和带宽浪费

几个可操作点（case study 里写死的，不是猜的）：

如果你团队也在 on-prem GPU 集群上拉 10 GB～几十 GB 的训练镜像，先别急着加带宽——对照上面问：registry 流量是不是绕了远路？Gateway 是不是叠在 overlay 里白白耗？pull 和训练节点能不能同城同节点？

斯巴鲁是 ADAS 图像识别 + 立体相机技术栈，迭代节奏跟今天改一版模型、明天就要跑验证绑在一起；三小时 pull 一次，一天能丢几个有效实验窗口，业务侧会直接感受到

踩坑清单（对照自检）

镜像层

• ML 基础镜像是否 monolithic、是否该拆 runtime 与代码层（case 里没写拆镜像，但 30 GB 本身是信号）
• pull 慢时，监控能不能区分 ImagePullBackOff、registry 超时、还是节点磁盘 IO

交付层

• Helm 还在 SSH 上手敲，还是已经把 Git 当成单一事实来源
• dev/staging/prod 的 values 差异有没有被 Helmfile/类似工具 codify

流水线层

• 训练→转 ONNX/TensorRT→推 artifact→触发下游，是 cron + 脚本，还是 workflow CRD
• 失败重跑、依赖传递、并行 stage，有没有平台级答案

边界

• 案例环境是 on-prem GPU，不是上公有云就自动好
• 未来规划里提到 多节点分布式训练（高带宽 secondary network） 和 edge 部署自动化——说明当前优化聚焦在单集群交付与镜像 pull，分布式训练是下一章

要不要进你工具箱

按你现在痛不痛来分，别因为 CNCF 奖杯就整包搬：

不必迷信 60 倍——你的镜像体积、registry 拓扑、容器网络 / overlay 和斯巴鲁不一定一样。值得抄的是 问题分解：先量化 pull 耗时，再动网络路径，再 GitOps，再 workflow，而不是一上来堆项目名

CNCF 官方 stack 列表：Kubernetes、Argo CD、Argo Workflows、Envoy Gateway、Gateway API、MetalLB、Helm、Harbor。细节以 case study 原文 为准

和我自己做的事有什么关系

我这边在做开源集群控制台 CiliKube，也折腾 AI 调查、终端协作——Agent 和训练任务一旦要在集群里 真跑，最后都会落到同一问：环境多久就绪、部署能不能复现、流水线能不能重跑

斯巴鲁没造新框架，是用 已有 CNCF 拼图 把 ADAS AI 平台的基建问题一层层削掉。对做平台工程的人，这比又一家 Fortune 500 上 Kubernetes 更有参考价值——尤其是 on-prem GPU + 超大镜像 + GitOps + ML workflow 这条组合拳

术语速查

文中工具官网

类似的帖子

• Kubernetes v1.37 抢先看：弃用三件与升级前体检
• Agent Sandbox——给 AI Agent 用的 K8s 沙箱编排
• CiliKube 1.0.0：AI 是领航员，控制台仍是真相源