分布式 AI 训练为什么正在改变云原生平台设计

分布式 AI 训练正在改变云原生平台设计，是因为训练作业的成功条件已经不再是“若干 Pod 能启动”。一个多节点训练任务只有在 worker 同时拿到合适的 GPU、处在可接受的网络拓扑中、能并发访问训练数据与检查点，并且通信链路真正达到预期时，才算进入可用状态。平台因此必须把调度、网络、存储和验证当成一个工作负载级产品，而不是四个互不相关的基础设施功能。

CNCF 案例文章：https://www.cncf.io/blog/2026/09/11/building-a-reliable-cloud-native-foundation-for-distributed-ai-training/

Kubernetes v1.37 发布说明：https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/

原来的 Pod 级成功标准不够用了

传统云原生平台擅长让大量相对独立的服务副本运行起来。调度器逐个放置 Pod，存活探针确认进程没有退出，网络和存储则由各自组件提供通用能力。对 Web 服务而言，一个副本晚一点启动通常只是容量暂时减少；对同步式分布式训练而言，少一个 worker 都可能让整组任务无法前进。

这会制造一种很难从普通面板看出的失败：部分 Pod 已经运行并占住 GPU，其他 Pod 仍在等待；或者所有容器都显示健康，但跨节点通信走了低效路径，训练吞吐远低于硬件能力。此时“Pod 状态正常”与“训练系统正常”已经是两个不同命题。

调度单元从单个 Pod 变成完整工作负载

第一个明显变化是 gang scheduling，也就是整组调度。分布式训练需要固定数量的 worker 协同运行，资源不足时，让少数 Pod 先占据 GPU 往往没有实际价值。工作负载级调度要求平台要么为整组 Pod 找到足够资源，要么让整组继续等待。

Kubernetes v1.37 把 gang scheduling 推进到 Beta，通过 Workload API 和 PodGroup 概念提供原生的整组调度能力，并增加工作负载感知抢占与 PodGroup 排队。这个变化意味着调度器开始显式理解“这些 Pod 属于一个不可拆分的计算任务”，而不再只处理彼此独立的容器。

拓扑也随之进入调度决策。两个 GPU 节点虽然规格相同，但所在机架、网络域和高速互联能力可能完全不同。随机找到足够数量的 GPU 不再是目标；找到能够高效通信的一组 GPU 才是目标。

高速网络和共享存储成为训练契约

CNCF 发布的分布式训练案例把通信性能、共享数据访问和运维可预测性列为三项核心要求。worker 之间要持续同步梯度、模型状态和集合通信结果，低延迟高吞吐的网络路径直接影响整个作业的步进速度。共享存储还要同时承受训练数据读取、检查点写入和中间产物访问，单节点看似正常的吞吐在多 worker 并发时可能迅速变成瓶颈。

因此，新平台不能只提供“集群里有 RDMA”或“已经挂载共享存储”这样的能力清单。它需要把节点池、网卡、网络映射、驱动、文件系统和训练模板绑定起来，并让作业在被接纳时自动获得正确配置。训练团队提交的是一个普通作业，平台负责吸收底层拓扑差异。

健康检查要从存活扩展到性能就绪

分布式训练平台还需要重写“就绪”的定义。容器进程存活，只能证明它没有崩溃；设备可见，只能证明运行时识别了 GPU；真正可训练还需要确认 worker 能互相发现、集合通信可用、共享目录一致、检查点可读写，以及实际链路没有退化。

平台可以把这些检查放在作业接纳和启动阶段：先核对硬件与驱动标签，再验证高速通信接口和共享存储，最后把结果写入工作负载状态。运行期间则同时观察 GPU 利用率、通信等待时间、数据加载停顿、训练步耗时和检查点时长。这样才能区分“资源拿到了但没有工作”“网络可达但性能异常”和“训练正常推进”。

平台 API 也会从资源参数转向训练意图

旧平台常让用户直接填写节点选择器、网卡注解、卷参数和大量环境变量。短期看很灵活，长期却会把基础设施知识复制到每个团队的作业文件里。随着硬件迁移、网络映射变化或驱动升级，这些配置很容易失效。

更适合分布式训练的接口应该表达意图，例如 worker 数量、GPU 类型、是否需要整组启动、允许的拓扑范围、数据集与检查点等级。平台再通过准入控制、控制器和标准化模板转换为具体 Pod 配置。这样既能控制复杂度，也给底层迁移留下空间。

采用时不要一次重做整个平台

更稳妥的路径是先选一个固定规模、问题明显的分布式训练作业做试点。第一阶段统一镜像、驱动、数据挂载和检查点位置，建立训练吞吐基线；第二阶段引入工作负载级排队、整组调度和拓扑约束；第三阶段再把网络与存储验证自动注入作业；最后才扩展多租户、公平配额、多集群和自动容量管理。

每一步都应使用训练指标而不是平台组件数量来判断价值。优先关注 GPU 有效利用率、排队时间、达到首个训练 step 的时间、稳定 step 耗时、检查点时长和故障恢复时间。只有这些指标改善，平台能力才真正转化为训练效率。

常见问题

有 GPU 资源配额为什么还需要 gang scheduling？

配额回答“最多能用多少”，整组调度回答“这批 worker 能否一起开始”。对紧耦合训练，两者解决的是不同问题。

所有 AI 工作负载都需要高速网络吗？

不需要。单机训练、小规模微调和许多推理任务未必受跨节点通信限制。是否引入 RDMA 等能力，应由模型规模、通信模式和基准测试决定。

平台改造最先应该补哪一层？

先补可观测性和工作负载级状态。如果无法看清排队、放置、通信、数据和训练进度，团队很难判断下一笔投入应该放在 GPU、网络、存储还是调度器。