在大规模GPU集群中运行AI训练任务时，分布式作业往往由多个进程组成，例如PyTorch的DDP模式会启动若干个Pod分别占用一张或几张显卡。如果这些Pod不能在同一时间全部获得资源，已经启动的Pod会空等尚未调度的同伴，造成显存和算力的浪费。Gang Scheduling（ gang调度）正是为了解决这类“全有或全无”的分配问题而提出的机制。它不是单纯按顺序调度单个容器，而是把一组存在依赖关系的Pod看作一个整体，只有当集群能够满足整组资源需求时才统一放行。
为什么原生调度器难以支撑AI训练的Gang需求
Kubernetes默认的kube-scheduler采用逐Pod决策模式，每个Pod独立排队、独立绑定节点。在GPU资源紧张的多租户集群里，假设一个训练任务需要八张卡，但集群剩余资源分散在八个节点各一张，原生调度器可能先给其中三个Pod做了绑定，剩下五个因为瞬时被其他小任务抢走而Pending。此时那三个已绑定Pod对应的进程会启动并阻塞在集合通信原语上，直到超时或人工干预，这段时间显卡利用率几乎是零。
更麻烦的是，这种部分分配会加剧资源碎片。其他用户提交的单卡推理服务可能因为碎片空间不足而被迫等待，集群整体吞吐下降。原生调度器虽然支持PriorityClass和Preemption，但抢占也是以单个Pod为粒度，无法保证抢占后刚好凑齐一整组训练所需的全部GPU。因此，仅靠原生能力无法表达“组”的语义，必须引入具有Gang能力的调度插件。
从架构角度看，原生调度器的设计目标是通用工作负载的公平与稳定，而不是高性能计算的批量协同。AI训练属于典型批处理与HPC混合场景，对启动一致性的敏感度远高于普通微服务。理解这一差异，是后续选型与配置的基础。
基于Volcano的PodGroup落地方式
Volcano是CNCF旗下的批调度项目，它在Kubernetes之上增加了Queue、PodGroup等CRD。使用Volcano时，我们首先创建队列并设定资源配额，然后把训练任务的多个Pod通过volcano.sh/queue-name和volcano.sh/podgroup注解关联到同一个PodGroup。调度器在决策时会检查该Group的minMember字段，只有可分配节点能满足minMember数量时才触发绑定。
下面给出一个简化的PodGroup与训练Job的配套示例，注意XML式标签在代码中已转义：
apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
name: train-gang-demo
spec:
minMember: 8
queue: default
---
apiVersion: batch/v1
kind: Job
metadata:
name: pytorch-train
spec:
parallelism: 8
completions: 8
template:
metadata:
annotations:
volcano.sh/queue-name: default
volcano.sh/podgroup: train-gang-demo
spec:
containers:
- name: trainer
image: ipipp.com/ai/pytorch:2.1
resources:
limits:
nvidia.com/gpu: 1
在这个配置中，如果集群任意时刻拿不出八张离散或连续的GPU，Volcano不会让任何一个Pod先行启动，从而避免了半吊子状态。当资源回收或扩容发生后，八张卡一次性分配，训练进程几乎同时拉起，集合通信初始化顺畅。相比原生调度，这种方式把等待成本从“运行时空转”转移到了“排队期”，对集群全局更高效。
需要注意的是，minMember不一定等于任务副本总数。例如容错训练允许一个副本失败后重算，可把minMember设为总数的八成，其余Pod作为弹性补充。但这种宽松设定会降低严格Gang的益处，平台团队应结合任务特性权衡。
生产环境中的优先级与队列隔离策略
当集群跑多个团队的训练任务时，仅靠Gang还不够，还要防止低优任务长期饿死。Volcano的Queue支持capability和weights，可以限制某队列最多用多少GPU，同时按权重分配空闲资源。配合PriorityClass，关键实验能优先凑齐PodGroup，而探索性任务在资源不足时整组等待，不占用零散卡。
以下片段展示队列的权重与上限配置：
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
name: team-a
spec:
capability:
nvidia.com/gpu: 32
weight: 80
---
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
name: team-b
spec:
capability:
nvidia.com/gpu: 16
weight: 20
上述设定下，team-a在争抢碎片资源时拥有更高权重，但其绝对使用量被capability锁死，避免挤压他人。若team-a提交了一个需要四十张卡的Gang任务，因超过capability而整组挂起，此时team-b的十六卡任务若能满足minMember仍可运行，保证集群不空白。
此外，监控上建议采集PodGroup的等待时长与绑定成功数，用Prometheus记录volcano_podgroup_scheduling_duration类指标。当某个Group等待超过阈值，可告警并建议用户降低minMember或错峰提交。通过调度语义、配额、监控三段配合，Gang Scheduling才能从概念落地为稳定的生产实践。
Gang_SchedulingKubernetesAI_training修改时间：2026-08-16 08:46:29