阿里云 PAI 超大规模集群：大模型训练的调度、容错与资源管理实践
本文整理自 AICon 上海分享「大模型云上训练工程突破：阿里云PAI在超大规模集群下的调度与容错实践」（演讲者：贾珂），通过AI音视频总结工具Ai好记进行视频转文字整理，以下为精炼整理后的内容。
大模型时代，AI 平台的核心使命变了
大模型训练给 AI 基础设施带来了全新的挑战。一个模型跑 30-60 天是常态，万卡级别的集群规模下，故障变得极其频繁——Meta 训练 Llama 3 时报告的每日故障就有 8-9 次。
阿里云 PAI 平台的产品负责人给出了两个核心定位：
- 如何更好地用上 AI：从本地开发到云上训练的无缝体验
- 如何做好大规模分布式训练：让小团队也能跑超大规模训练任务
围绕这两点，PAI 走了从内部孵化到对外服务的完整路径。2015 年阿里内部就有了雏形，到 2022-2023 年实现了 PAI Serverless 的突破，现在的卡规模已经达到数十万级别，支持传统 NVIDIA 卡和国产化卡。
大模型时代的三大挑战
| 挑战 | 具体表现 |
|---|---|
| 分布式难度激增 | 万卡集群下的通信拓扑、版本管理、异构适配 |
| 硬件可靠性 | 资源利用率要求从 65-70% 提升到 90% 以上 |
| 生态成本 | 模型版本多，框架多，国产芯片适配成本高 |
特别是「烧机」问题：新卡上线需要跑一段时间才能稳定，而云上环境分秒必争，稳定性要求极高。
PAI 平台架构：一个平台，两个服务
PAI 的整体架构设计围绕三层展开：
底层：异构算力 + 网络（传统 N 卡 + 国产化卡） ↓ 中间层：训练服务 ↔ 推理服务（资源共享） ↓ 上层：ModelScope（魔搭社区）+ ModelStudio（阿里云百炼）关键设计思路是训练和推理资源共享。在云化和 K8S 环境下，训练和推理集群可以统一管理，弹性分配算力。
稳定性保障：事前-事中-事后的三层防护
大模型训练的稳定性是最头疼的问题。PAI 的应对方案可以概括为「三层防护」：
第一层：事前检查（SanityCheck）
在任务正式开跑前，做一次全面体检：
| 检查项 | 说明 | 耗时 |
|---|---|---|
| 网络连通性 | 检查 RDMA、TCP 等链路 | ~1 分钟 |
| 算力可用性 | 每个 GPU 的状态检测 | ~1 分钟 |
| 存储挂载 | 检查 OSS 等存储读写 | ~1 分钟 |
| 内存/CPU | 基础硬件检测 | ~1 分钟 |
总共包含 30-50 项指标，大约 1 分钟完成。同时，机器入集群时也做预检，自动把有问题的节点拉黑替换，缩短「烧机」时间。
第二层：事中容错（AImaster）
训练过程中，AImaster 实时监控所有节点的状态：
- 自动检测故障节点（硬件故障、通信异常、OOM 等）
- 自动拉黑故障节点，不再调度新任务到该节点
- 快速替换新节点，让训练任务继续运行
关键指标是「故障发现到恢复的时间」，PAI 的目标是做到分钟级修复，而不是等 Checkpoint 恢复。
第三层：事后恢复（EasyCKPT 异步快照）
即使有前两层防护，硬故障还是会发生。PAI 的 EasyCKPT 技术做了几件事：
| 技术点 | 解决的问题 |
|---|---|
| 异步快照 | 不阻塞训练进程，在后台完成模型状态保存 |
| 增量 Checkpoint | 只保存变化的部分，而非全量 |
| 自动恢复 | 检测到可用 Checkpoint 后自动拉起 |
传统做法是整任务重启，耗时可能超过 1 小时。EasyCKPT 实现了分钟级重启，大幅降低故障影响。
高性能调度：Serverless 和拓扑感知
Serverless 架构
PAI 的调度核心是 Serverless——客户购买的是「算力承诺」而非固定机器。平台负责：
- 资源的弹性调度
- 故障的自动屏蔽
- 云上分布式训练的统一体验
好处是客户不需要自己管理集群，平台通过资源池化摊薄了单位计算成本。
拓扑亲和性调度
大模型训练对通信带宽极度敏感。同一机柜内 NVLink 连接的 GPU 和跨交换机连接的 GPU，通信时延可以相差 3-5 倍。
PAI 与阿里云网络团队深度集成，将底层高性能网络的拓扑信息纳入调度决策：
| 调度策略 | 效果 |
|---|---|
| 随机调度（不感知拓扑） | 性能基线 |
| 拓扑感知调度 | 性能提升 3%-40%（取决于模型架构） |
| NUMA 感知 | 额外优化内存访问 |
调度器会尽可能将通信密集的 GPU 任务调度到网络距离最近、带宽最优的节点组上。
灵活的排队与抢占
支持多种排队和抢占策略：
- 按优先级排队：高优任务优先获取资源
- 可抢占模式：低优任务可被高优任务抢占释放资源
- 闲时资源池：未使用的承诺资源池化给其他团队使用
效率优化：QuotaTree 和闲时资源
QuotaTree（配额树）
将总的计算资源按照组织架构划分成树状结构：
总资源池 ├── 基础架构团队 │ ├── 训练组（40%） │ └── 推理组（30%） ├── 算法团队 │ ├── NLP 组（15%） │ └── CV 组（15%） └── 公共配额（弹性池）每个节点代表一个独立配额，支持资源的隔离、预留、共享和抢占策略。
闲时资源机制
各团队未使用的承诺资源被池化成「闲时资源」，允许其他团队以「可被抢占」的模式使用。当资源所有者需要时，可以抢占回收。
效果：在不增加额外采购的情况下，集群整体资源利用率提升了约 5-6 个百分点，相当于「免费」的额外算力。
多框架融合与异构计算
Ray 框架支持
PAI 同时支持任务级和集群级部署 Ray 框架：
| 部署方式 | 使用场景 |
|---|---|
| 任务级 Ray | 单任务内需要分布式调度的场景 |
| 集群级 Ray | 全局统一的 Ray 集群，多任务共享 |
GPU + CPU 异构协同：RemoteDataLoader
有一个非常实际的问题：某些高密度 AI 芯片（比如 16 卡配置）的 CPU 核数与 GPU 算力配比失衡。做数据预处理时，CPU 成为瓶颈，GPU 经常空转。
PAI 的 RemoteDataLoader 方案是这样解决的：
传统模式： GPU 等待 CPU 做数据预处理 ↓ RemoteDataLoader：将 CPU 密集型的数据预处理调度到独立的 ECS 节点 GPU 只专注模型计算实测效果：GPU 利用率从 40-50% 提升至 90% 以上。
统一管控：多云纳管
PAI 通过 K8S Vnode 技术，能够将客户在其他云（AWS、Azure）或自有数据中心的算力「纳管」进来。
客户可以在阿里云 PAI 的统一控制台上，以完全相同的操作方式提交和管理跨云任务，实现算力资源的「一处管控，多处执行」——这对混合云和多云场景特别实用。
总结
阿里云 PAI 的超大规模集群实践可以总结为三点：
- 稳定性是底线：三层防护体系让 30-60 天的长周期训练成为可能
- 调度效率决定成本：Serverless + 拓扑亲和 + 闲时资源，显著提升资源利用率
- 生态融合降低门槛：支持 Ray、魔搭社区，纳管多云资源，降低客户迁移成本
对于正在搭建或选型 AI 训练平台的技术团队来说，这三个方向都是必须考虑的「必答题」。
FAQ
Q：PAI 是否支持国产芯片的大规模训练？
A：支持。PAI 同时纳管传统 N 卡和国产化卡，是国内云厂商中覆盖最全面的之一。
Q：Small Checkpoint 怎么做增量保存？
A：通过监控模型参数的变更量，只保存发生变化的部分。结合异步写入技术，对训练性能影响控制在 5% 以内。
Q：闲时资源抢占时，被抢占的任务会丢失进度吗？
A：不会。EasyCKPT 的异步快照会定期保存训练状态，被抢占任务恢复时会自动从最近的 Checkpoint 继续。
以上内容由 Ai好记 转录整理。
Ai好记是一款音视频转图文笔记的AI音视频总结助手，支持解析B站、小红书、抖音、小宇宙等平台链接及本地、网盘的音视频文件，转录后自动生成精华速览、思维导图和结构化笔记等内容，帮助你把几小时的视频内容变成可搜索、可复习的图文笔记。