随着大模型训练、后训练、推理和评估任务的规模不断扩大，AI 集群逐渐从单机多卡走向多机多卡、多机房甚至多云环境。此时，资源调度系统不再只是简单的"找一台有空闲 GPU 的机器"，而是需要同时处理 GPU、CPU、RDMA 网络、本地存储、并行文件系统、任务优先级、队列配额、故障隔离和利用率优化等一系列问题。
本文从工程实践角度，梳理大规模 AI 训练与推理集群资源调度系统的关键设计点，涉及 Kubernetes、容器、分布式系统、GPU/RDMA/存储协同等方向。
一、资源抽象与拓扑感知
AI 集群中的资源类型远比普通 Web 集群复杂。调度系统首先要解决资源抽象问题。
常见资源包括：
GPU：型号、显存、算力、MIG 切分、NVLink 拓扑、PCIe 位置；
CPU：核数、NUMA 节点、大页内存、绑核能力；
网络：RDMA 网卡、IB/RoCE、带宽、交换机层级；
存储：本地 NVMe、并行文件系统、对象存储、缓存盘；
其他异构硬件：NPU、FPGA、专用推理卡等。
在 Kubernetes 中，可以通过 Device Plugin 上报 GPU、RDMA 等扩展资源，通过 Node Label 标识机型、机房、网络拓扑和存储类型。调度器在做决策时，不能只看"剩余数量"，还要看资源之间的亲和关系。
例如，同一训练任务的多个 Pod 如果被分散到跨 Spine 的节点上，NCCL 通信效率会明显下降。因此，拓扑感知调度是大规模 AI 集群的基础能力。
二、Kubernetes 调度扩展与 Gang Scheduling
原生 Kubernetes 调度器适合通用工作负载，但在 AI 场景下有几个明显不足：
缺少 Gang Scheduling：一个分布式训练任务需要所有 Worker 同时启动，否则容易死锁；
队列与配额能力弱：多团队共享集群时，需要队列、配额、公平共享；
抢占与回填不够灵活：高优先级任务需要快速获得资源；
拓扑感知不足：GPU、RDMA、NUMA 之间的亲和关系难以表达；
异构资源编排复杂：GPU、CPU、存储、网络需要联合调度。
常见做法是基于 Kubernetes Scheduler Framework 扩展 Filter、Score、Reserve、Permit、Preempt 等阶段，或者使用 Volcano、Kueue、YuniKorn 等调度组件。通过 CRD 定义 Queue、PodGroup、ElasticQuota 等对象，可以实现队列配额和组调度。
示例：
yaml
apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
name: llm-training-job
spec:
minMember: 8
queue: research
priorityClassName: high
这个 PodGroup 表示一个训练任务至少需要 8 个 Pod 同时满足条件后才能启动，避免部分 Worker 长期占用资源却无法推进任务。
三、容器运行时与 GPU 支持
AI 训练任务通常运行在容器中。常见容器运行时包括 Docker、Containerd、Kata、Podman 等。
Containerd：轻量、稳定，适合作为 Kubernetes 默认运行时；
Docker：生态成熟，但 Kubernetes 已逐步转向 Containerd；
Kata：提供更强隔离，适合多租户安全场景；
Podman：无守护进程，适合某些边缘或特殊环境。
GPU 容器需要 nvidia-container-toolkit 等组件支持。RDMA 场景还需要挂载 IB 设备、配置 IPC_LOCK、共享内存和大页内存。对于训练任务，容器内还需要关注：
NCCL 环境变量；
GPU 可见性；
RDMA 设备亲和；
共享内存大小；
Checkpoint 写入路径；
数据缓存目录。
容器运行时选择不只是"能跑就行"，它会直接影响启动速度、隔离性、GPU 性能和故障恢复能力。
四、GPU、RDMA 与存储协同调度
在大模型训练中，计算、通信、存储三者必须协同。
- GPU 与 RDMA 亲和
同一通信组的 GPU 和 RDMA 网卡应尽量位于同一 NUMA 节点或同一 PCIe 拓扑下。调度器可以通过 Node Label 和 Device Plugin 获取这些信息，在打分阶段优先选择通信代价低的节点组合。
- 数据本地性
训练数据集往往很大。如果每次任务启动都从远端对象存储拉取数据，GPU 会长时间等待 I/O。调度时可以优先选择已经缓存数据集的节点，或者结合缓存系统做数据预热。
- Checkpoint 优化
大模型训练需要定期保存 Checkpoint。Checkpoint 写入慢会阻塞训练。调度系统可以感知存储带宽和本地 NVMe 容量，把 Checkpoint 压力分散到不同存储层。
- 避免资源碎片
GPU 任务对资源组合要求高。如果调度器只做简单装箱，容易产生"有 GPU 但缺 RDMA"或"有 GPU 但 CPU 不足"的碎片。需要通过 bin packing、拓扑打分和重调度来减少碎片。
五、多机房、多地域与多云调度
当集群扩展到多机房、多地域或多云时，调度问题会更加复杂。
需要考虑：
数据合规与地域限制；
跨机房带宽成本；
网络延迟；
故障隔离；
统一配额与权限；
多集群控制面；
任务迁移与重调度。
常见方案是使用多集群调度框架，例如 Karmada、Clusternet，或自研联邦调度层。核心思路是：控制面统一，数据面分散；任务尽量靠近数据；跨云资源作为弹性补充，而不是默认选择。
六、在离线混布与潮汐资源
AI 集群中既有在线推理服务，也有离线训练、评估和后训练任务。在线服务对延迟敏感，离线任务对吞吐敏感。通过混布可以提高整体利用率。
关键机制包括：
QoS 分级；
优先级与抢占；
资源超卖；
潮汐资源回收；
驱逐前通知；
Checkpoint 后抢占。
训练任务通常可以容忍一定中断，只要支持 Checkpoint 和恢复。但 GPU 显存不可压缩，抢占代价高，因此不能简单照搬 CPU 混布策略。调度器需要评估抢占成本，选择合适 victim，并尽量避免频繁抖动。
七、排队、优先级与抢占
大规模集群中，排队策略直接影响公平性和利用率。
常见策略包括：
FIFO；
优先级队列；
公平共享；
DRF；
配额与弹性配额；
回填调度；
Gang Scheduling；
抢占与驱逐。
回填调度可以在大任务等待资源时，先运行小任务，提高利用率。但回填必须保证不会导致大任务无限等待。抢占则需要结合优先级、运行时长、Checkpoint 成本和队列配额综合判断。
八、利用率优化的关键指标
利用率优化不能只看 GPU 使用率。更合理的指标包括：
GPU SM 活跃度；
显存占用；
RDMA 带宽利用率；
存储 I/O 等待；
队列等待时间；
任务排队时长；
资源碎片率；
有效算力产出；
任务失败率；
Checkpoint 恢复时间。
高 GPU 利用率不一定代表高吞吐。例如，GPU 在等待数据时也可能显示较高占用。真正需要关注的是有效计算时间和端到端任务效率。
九、工程实现建议
实现一个可用的 AI 调度系统，通常需要多种语言和组件配合：
Go：编写 Controller、Operator、Scheduler Plugin；
Python：策略分析、离线评估、任务模板；
Shell：自动化运维和初始化；
Kubernetes：CRD、Device Plugin、Scheduler Framework；
Prometheus + Grafana：监控与告警；
OpenTelemetry：链路追踪；
日志系统：审计与问题定位。
工程上建议从单集群调度开始，逐步引入队列、优先级、Gang Scheduling、拓扑感知、混布和多集群能力。不要一开始就追求大而全，而应优先解决最影响任务效率和稳定性的瓶颈。
十、总结
大规模 AI 训练与推理集群的调度系统，是 Kubernetes、容器、分布式系统、GPU、RDMA、存储和队列策略的综合工程。它的核心目标可以概括为：
稳定：任务能跑起来，故障能恢复；
高效：GPU、网络、存储利用率高；
公平：多团队多队列资源共享合理；
可观测：问题能定位，容量能规划；
可扩展：从单集群走向多机房、多云。
对于从事 AI 基础设施方向的工程师来说，理解资源抽象、拓扑感知、Gang Scheduling、抢占、混布和利用率闭环，是构建大规模训练平台的重要基础。
做猎头这些年攒了不少行业洞察，好机会也会第一时间分享，主页经常更新，有缘的话，锁定我🔒，不迷路。