1. 痛点分析：Kubernetes管理GPU时算力都浪费在哪了
先说个我见过很多次的场景：一个中等规模的AI团队，K8s集群里挂着几十张GPU卡，任务却经常排队，新来的训练任务死活调度不上去。可你要是真去GPU节点上看一眼会发现，不少卡的内存占用只有一半，算力更是跑不满。这种“有钱花不出去、买了不用”的状态，在Kubernetes默认调度器的管理体系里几乎是必然结果。
默认的kube-scheduler在设计时主要面向的是CPU、内存这类通用资源，调度粒度是节点级别的“够用就行”。它会把每个Pod当作独立单元，逐个找一台满足资源请求的节点塞进去。这种思路跑Web服务没问题，但放到GPU训练场景里，问题马上暴露出来。
最典型的一个浪费是显存和算力不对齐。一张GPU卡既有显存又有计算核心，训练任务通常两者都要。K8s默认只认识nvidia.com/gpu这个资源，而且是以“张”为单位，一申请就是整卡。可实际任务呢，有的吃显存不吃算力，有的吃算力不吃显存。整卡分配意味着只要显存满足，算力再闲也得把整张卡锁给你；反过来，算力需求大但显存需求小的任务，又会白白占着大量显存。这种“按最大需求分配整卡”的模式，在混合负载的集群里，资源浪费率30%以上非常常见。
第二个问题是调度器眼里只有Pod，没有“任务”的概念。深度学习训练经常要拉起一个包含PS和Worker的分布式任务，多个Pod之间有严格的启动顺序和数量要求。默认调度器是一个Pod一个Pod安排，Pod一多就开始出现死锁：任务A的三个Worker占了三台机器，任务B的两个Worker也在等，结果谁的资源都不够凑齐完整任务，大家都堵在那里空转。更麻烦的是，这些Pod如果被调度到不同机器上，跨节点通信的开销会直接影响训练效率，但默认调度器根本不管这些。
第三个问题是K8s的默认调度策略完全不做区分。训练任务有优先级高低，有些是线上推理必须随时响应，有些是离线实验跑几个小时无所谓。kube-scheduler只有一个简单的优先级字段，没有队列概念，也没有抢占回收机制。高优任务来了，如果集群里全是低优任务占着资源，它只能干等。低优任务反过来也不会主动腾地方，大家互相耗着，GPU算力就这么白白浪费了。
我最初接手这类集群的时候，想的还是“是不是业务方申请资源太贪心了，总是多要”。后来仔细排查才发现，问题根本不在业务方，而是调度这一层完全没有针对GPU场景做优化。你要让业务方精确预估一趟训练到底吃多少显存和算力，本身就不现实，他们按整卡申请是K8s机制下唯一稳妥的做法。
所以省GPU算力的核心，不是靠人肉逼业务方少申请资源，而是要让调度器具备更精细的分配能力、队列化的资源管理能力和任务级别的调度能力。Volcano调度器干的就是这件事。
2. Volcano调度器核心机制拆解：它凭什么能省资源
2.1 Volcano的三级模型：Queue、Job、Task分别解决什么问题
Volcano是云原生计算基金会（CNCF）旗下的批量计算调度器，专门为AI、大数据、高性能计算这类负载设计。它的核心模型分三层：Queue（队列）、Job（任务）、Task（任务内子任务）。
Queue是资源管理的顶层单元，你可以理解成给不同的业务线或项目组划分的几个“资源池”。比如算法部一个队列、数据组一个队列，每个队列可以设置资源上限（capability）和最低保障份额（deserved）。队列之间可以设置share权重，权重高的队列在资源紧张时能分到更多算力，权重低的队列在空闲时也能借用别的队列的闲置资源。这个机制很好用，它允许你在保证核心业务不出问题的前提下，把空置算力让给非核心任务去“捡漏”跑。
Job对应一个完整的训练任务，比如一次分布式训练，它包含了多个Pod（Task）。Volcano的Job模型下，这批Task会被当成一个整体来调度，要么全部满足资源条件一起启动，要么一个都不启动，这就是gang scheduling（全员调度）的语义。这种All-or-Nothing的调度方式，直接消灭了前面说的分布式任务互相等资源导致死锁的问题，也避免了部分Worker先启动后空转等待浪费算力。
Task是Job里的最小调度单位，对应一个Pod。但Volcano对Task的资源描述比K8s原生更丰富，可以细化到单卡的显存粒度，也可以支持多卡组合，比如一个Task需要2张卡，它会尝试把这2张卡分配到同一台机器上，减少跨节点通信开销。
这一层模型解决了资源管理的结构性问题。原来你用namespace隔离不同团队的资源，其实是没法精细控制的——namespace本身没有资源配额的概念，你只能用ResourceQuota，但ResourceQuota只能限制总量，控制不了优先级、共享和弹性借用。Queue直接把这些能力做进去了，调度器在分配资源时先看队列的权重和额度，再看具体任务的需求，整体上有了“先分池子、再分任务”的清晰逻辑。
2.2 为什么“排队”机制比“抢资源”更能提高GPU利用率
Kubernetes默认的调度行为是“能调度就调度”，所有任务全是硬塞。这带来的直接后果是集群里塞满了“僵尸资源”——任务已经跑完了但还没释放、任务在等待从节点但节点资源被占、低优任务把高优任务的资源占了等等。我在实际运维中见过，一个集群名义上利用率80%，但真正在有效计算的GPU只有不到50%。
Volcano通过Queue实现了“排队+弹性”的资源分配模式。每个队列有一个deserved（保障额度）和一个capability（最大额度），调度器会优先保证每个队列至少拿到deserved的资源，然后根据任务的优先级和队列的share权重来分配超出部分。
这个机制在工作流上的价值是：高优任务不会被低优任务堵死——低优任务只能使用队列额度内的资源，而且随时可以被高优任务抢占；低优任务也不会让资源闲着——当队列额度没被用完时，任何任务都可以先跑起来，利用闲置的GPU算力，等高优任务需要时再让出来。这种“先到先得、大任务让路”的模式，比默认调度器的“死等”能多压榨出大量空闲算力。
加一个实际参数帮助理解。比如队列A的capability是20张卡，deserved是10张卡。当A队列只有1个任务申请2张卡时，它最多可以用到20张卡的额度，把其他队列空闲的卡借过来跑。等高优任务来了，调度器按优先级把资源收回。这个过程中，GPU始终在干活，而不是空转等待。
2.3 调度策略里的省资源主力：binpack与拓扑感知
Volcano不像kube-scheduler只用一种默认策略，它把调度拆成了多个可插拔的动作（actions），你可以在配置里按需组装。其中和GPU省算力关系最直接的是binpack和allocate。
默认的kube-scheduler倾向于把Pod分散到不同节点，这叫spread策略。但对于GPU集群，我们希望反过来：尽可能把任务紧凑地塞进少数节点，空出更多节点留给大任务，或者直接让空节点关机休眠省电。Volcano的binpack策略就是干这个的，它会计算每个节点的资源碎片率，优先选择“放进去后剩余资源最难放下别的任务”的节点，从而把资源尽量压实。
配合binpack的还有拓扑感知能力。Volcano能感知GPU所在节点的PCIe、NUMA拓扑，在建图时优先把同一个任务需要的多张卡分配到同一台机器甚至同一块PCIe交换机下。这样做带来的收益很直接：降低了跨节点通信的带宽瓶颈，单机多卡训练的吞吐量明显提升，任务跑得快了，占用的总时长短了，算力自然就省下来了。
3. 通过Volcano落地GPU资源优化：配置详解与实操记录
3.1 环境准备：Volcano调度器的部署与启用
讲原理讲了一堆，现在上实操。我下面的步骤基于一个相对标准的Kubernetes环境，如果你已经装了Helm，用Helm安装Volcano是最快的。
# 添加Volcano Helm仓库 helm repo add volcano https://volcano-sh.github.io/charts # 安装Volcano调度器，默认会创建volcano-system命名空间 helm install volcano volcano/volcano --namespace volcano-system --create-namespace安装完成后，验证核心组件是否正常：
kubectl get pods -n volcano-system正常情况下会看到volcano-scheduler、volcano-controller、volcano-admission这几个Pod在运行。volcano-scheduler负责调度决策，volcano-controller负责监听PodGroup等自定义资源，volcano-admission是准入控制器，会自动给符合条件的Pod补上PodGroup配置。
Volcano不替代kube-scheduler，它是以第二个调度器的方式接入集群的。用户在创建负载时通过schedulerName: volcano指定使用哪个调度器。这个设计我一开始觉得绕，后来发现很有用——你完全可以让普通Web服务继续走默认调度器，只让训练任务走Volcano，避免互相影响。
3.2 配置Queue：给不同业务线划分GPU资源池
Queue是Volcano资源优化的基础单元，配置方式很直接。我拿一个实际场景举例：集群一共有30张GPU卡，两条业务线，核心训练队列（train-prod）和非核心实验队列（train-dev）。
apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: train-prod spec: weight: 2 capability: gpu: 20 deserved: gpu: 15 --- apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: train-dev spec: weight: 1 capability: gpu: 10 deserved: gpu: 5解释一下这几个字段的含义：
capability：该队列最多能使用多少资源，这是硬上限，防止某个业务线把所有算力吃光。deserved：该队列最少保障多少资源，只要集群资源够，这部分算力优先给这个队列。weight：资源有富余时，各队列按权重比例竞争额外资源。train-prod权重是2，train-dev是1，意味着集群空闲时train-prod可以比train-dev多分到一倍的空闲算力。
注意这里的资源单位是gpu，这是Volcano支持的扩展资源名，和K8s标准的nvidia.com/gpu不同。你可以通过volcano.sh/...这种命名来定义自己需要的资源类型，比如把显存定义成volcano.sh/vGPU-memory然后按MB粒度分配。这点在后面细讲。
队列配好之后，还要给具体业务绑定队列。有两种方式，一种是在创建Job时指定spec.queue，另一种是给Pod所在命名空间加annotation，让该命名空间下所有负载默认进入指定队列。推荐用命名空间绑定，省去每个任务单独配置的麻烦：
kubectl annotate namespace ai-training volcano.sh/queue=train-prod3.3 让训练任务走Volcano调度：PodGroup绑定两种常用方式
要让任务真正用上Volcano的调度能力，需要让负载变成“可被Volcano识别”的结构。Volcano的调度对象是PodGroup，一个PodGroup对应一个Job或一组Pod，调度器按PodGroup整体调度。
这里介绍两种绑定方式，按业务场景选择。
方式一：如果业务方已经用K8s的Job或Deployment管理训练任务，可以直接加一个annotation，让Volcano控制器自动创建PodGroup。这个方式对业务方代码完全无感。
apiVersion: batch/v1 kind: Job metadata: name: bert-train-job annotations: volcano.sh/job-min-available: "4" # 最少需要4个Pod成功调度才会启动任务 volcano.sh/job-queue: "train-prod" # 指定队列 spec: template: spec: schedulerName: volcano containers: - name: trainer image: registry.example.com/bert-trainer:v1 resources: limits: nvidia.com/gpu: 1volcano.sh/job-min-available这个annotation对应的是gang调度中的“最少可用Pod数”。比如一个分布式训练任务有8个Worker，你希望至少4个就绪后整个任务才启动，可以设成4。极端追求完整性的可以设成和Pod总数一致，但这会降低调度容错性，一旦某个Pod因资源不足失败，整个任务会一直等待。我的建议是：如果是短任务、对启动成功率要求高的，设成Pod总数的80%左右；如果是长任务、一致性要求高的，设成100%。
方式二：直接使用Volcano的原生Job资源类型。这种方式功能最全，支持任务模板、依赖关系、错误处理策略等，适合从零开始建设的新业务。
apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: bert-train-job spec: schedulerName: volcano minAvailable: 4 queue: train-prod policies: - event: PodFailed action: RestartJob tasks: - name: worker replicas: 4 template: spec: containers: - name: trainer image: registry.example.com/bert-trainer:v1 resources: limits: nvidia.com/gpu: 1spec.minAvailable就是gang调度需要的最少Pod数，调度器会等到该Job下至少4个Pod的资源都能满足时，才一次性创建并调度它们。这样彻底避免了“只启动一半，另一半卡住”的尴尬。
3.4 binpack配置与显存级GPU切分：省卡的两个杀手锏
接下来是资源优化最核心的部分。默认情况下Volcano的调度策略包（actions）长这样：
actions: "enqueue, allocate, backfill" tiers: - plugins: - name: priority - name: gang - name: preempt你需要把binpack插件加进去，并在调度器配置里打开它。修改volcano-scheduler-configmap中的配置：
actions: "enqueue, allocate, backfill" tiers: - plugins: - name: priority - name: gang - name: preempt - name: binpack arguments: binpack.weight: 1 binpack.cpu: 10 binpack.memory: 10 binpack.gpu: 1binpack.weight是binpack策略在综合评分中的权重，数字越大，调度器越倾向于紧凑放置。binpack.cpu、binpack.memory、binpack.gpu分别表示这三类资源在打分时的权重，一般建议CPU和内存权重高一些，GPU权重看集群情况。因为GPU更容易成为瓶颈，权重太低会优先塞满CPU而忽略GPU分布，权重太高又容易导致GPU算力碎片化。我实测下来，GPU权重设成1、CPU和内存设成10，在大多数集群里效果都不错。
修改配置后需要重启volcano-scheduler让配置生效。这个操作在低峰期做，因为调度器重启期间新任务的调度会有短暂延迟，已经在跑的任务不受影响。
另一个杀手锏是显存级GPU切分。默认nvidia.com/gpu: 1的语义是申请一张完整的GPU卡，哪怕任务只需要20GB显存中的12GB，剩下的8GB也归你独占。解决思路是引入显存维度的自定义资源，让任务按显存大小申请。
在K8s中注册一个扩展资源，比如volcano.sh/gpu-memory：
kubectl patch node gpu-node-01 -p '{"status":{"capacity":{"volcano.sh/gpu-memory": "80240"}}}'上面这是把一个本来没有volcano.sh/gpu-memory的GPU节点注册成总显存80GB（约80万个MB，注意单位）。实际部署中更推荐用Device Plugin的框架来做，这里只是为了演示手动注册的可行性。
然后在业务方申请资源时，不再整卡申请，而是精确申请显存：
resources: limits: nvidia.com/gpu: 0 volcano.sh/gpu-memory: 12 # 12GB显存当多个任务都按显存粒度申请时，调度器就能在单张GPU卡上叠加多个任务。原来只能跑一个20GB大任务的卡，现在能同时跑一个12GB和一个8GB的任务，GPU利用率直接翻倍。这套方案需要业务方明确知道自己的显存峰值大概在什么水平，同时要接受一定的显存超卖风险。后面我会专门讲这个坑的处理方法。
3.5 抢占与回填：让低优任务利用空闲算力，但不影响主任务
省算力除了“压得更紧”，还要“填得更满”。集群里的GPU不会时刻都有任务在跑，总有某些时段、某些节点处于空闲。传统的做法是让低优任务排着队等，等到资源空闲了再调度上去。但这样会有一个问题：低优任务启动之后，高优任务来了怎么办？如果驱逐机制做得不好，高优任务照样被堵住，低优任务也白启动了。
Volcano的preempt插件解决了这个循环。它允许低优先级任务使用队列的空闲额度，一旦高优先级任务需要资源，低优任务会被驱逐（Pod被删除，任务状态保留），把资源让出来。业务方看到的现象是：低优任务跑着跑着没了，但重启后可以从checkpoint继续，不会白跑。
配置抢占的方式是在调度器tiers里启用preempt插件，然后在任务上配置优先级。工作中我习惯给训练任务定义三个优先级等级。
apiVersion: scheduling.volcano.sh/v1beta1 kind: PriorityClass metadata: name: production-high value: 100 globalDefault: false --- apiVersion: scheduling.volcano.sh/v1beta1 kind: PriorityClass metadata: name: batch-normal value: 50 globalDefault: true --- apiVersion: scheduling.volcano.sh/v1beta1 kind: PriorityClass metadata: name: offline-low value: 0 globalDefault: false线上推理任务和核心训练任务用production-high，普通任务用默认的batch-normal，跑批处理和实验任务用offline-low。调度器在发现高优任务无法调度时，会自动寻找占用资源但优先级更低的任务并驱逐，腾出位置。
当然，实际操作中“驱逐”这个词听起来很吓人，业务方总会担心训练任务被杀了进度就丢了。我在落地时会在业务方约定：低优任务必须支持断点续训，训练框架每隔一定步数自动保存checkpoint。这样即使被抢占，重新调度后从最近的checkpoint恢复，损失也就是十几分钟的算力。长期看，换来的是集群整体利用率提升，业务方实际跑完一个实验的时间反而变短了。
4. Volcano优化前后效果对比：30%的算力是怎么省出来的
聊完配置，用一组真实数据看看效果。我在一个内部集群做过对比测试，集群配置是10台物理机，每台8张A100 GPU，总共80张卡。负载是三类任务：32卡的大型预训练任务、8卡的微调任务、单卡的小实验。
改动前的调度方式是默认kube-scheduler，所有任务按整卡申请，调度策略是默认的spread。结果很典型：集群名义上跑着50多个任务，看起来挺忙，但实际GPU平均利用率只有43%。原因主要有几类：显存不够但算力富余的任务，整卡分配导致算力闲置；分布在不同节点上的多卡任务，通信等待时间占比高；高优任务被低优任务堵着，只能排队等待。
改动后切换到Volcano，做了三件事：一是所有任务按显存粒度拆分申请而不是整卡；二是开启binpack策略，让任务尽量紧凑放；三是配置了Queue，区分核心和非核心任务，开启抢占机制。运行一周后统计，GPU平均利用率升到了77%。也就是说，原来100张卡才能干完的活，现在70张卡出头就能干完，省下来的比例接近30%。
再说一个更细的优化点。binpack策略让任务集中放置之后，集群里开始出现“完全空闲”的节点。我在运维层面做了一个自动缩容脚本，检测到节点连续N小时GPU利用率低于阈值时，就把它从调度器中封锁并标记为可下线状态（实际操作中需要配合节点池管理工具做缩容）。云上这样做的收益非常直接：节点停了，账单就停了。如果是自建机房，空出来的机器也能挪给别的业务用。
这个案例不是个例。很多将K8s跑AI训练的团队反馈，云上的GPU实例按小时计费，binpack+缩容组合起来，账单可以直接砍掉三分之一。这也是为什么能在标题里写“省下30%GPU算力”——这不是标题党的营销数字，而是通过调度优化让硬件物尽其用之后自然产生的效果。
5. 实战中容易踩的坑与排查技巧
5.1 任务一直Queued不调度，日志里也没报错
这是Volcano上手时最常见的坑。你的Job提交了，状态一直显示Queued，但schedulerName明明指定了volcano，Pod的Events里也没有明显错误。
首先确认调度器是否真的认到了这个任务。查看PodGroup的状态：
kubectl get podgroup -n your-namespace如果PodGroup不存在，说明任务根本没有被Volcano控制器接管。原因九成是annotation没写对，或者命名空间没有绑定Queue。Volcano的admission组件默认会给指定了schedulerName: volcano的Pod自动创建PodGroup，但如果你用的是Job这一类工作负载，建议显式加上PodGroup annotation，避免控制器残留的偶发问题。
如果PodGroup存在但状态一直是Pending，再查Queue的资源额度是否充足：
kubectl describe queue train-prod看一下Queue的Allocated和Deserved字段，有时候是某个队列的capability已经打满，新任务进了队列也排不上调度。
5.2 binpack配了但资源利用率没有明显变化
很多人在配置里加了binpack插件，重启后看统计数据，发现利用率变化不大。这种情况通常是两个原因。
一是业务方的资源申请本身就卡死了binpack的发挥空间。比如所有任务都申请整卡nvidia.com/gpu: 1，调度器的binpack再怎么排，一张卡也只能跑一个任务，利用率上限卡在50%以下。解决方案是先做显存粒度的资源切分，让任务能共享物理卡。
二是binpack的权重设置不合理。binpack.gpu权重过小，调度器综合评分时优先考虑了节点内存分布，GPU的紧凑排列没有成为决定性因素。建议先调binpack.gpu的权重，观察调度后的Pod分布，如果一张节点上Pod数量明显变多了，说明binpack生效了。
5.3 显存切分之后，任务OOM如何兜底
显存粒度申请听起来很美好，但业务方对自己的显存峰值预估并不会总是精确。一个任务申请12GB，实际跑起来吃到16GB，如果这张卡上还叠加着别的任务，直接OOM把整张卡打挂。
我的处理方式是在GPU节点部署一个显存监控Pod，通过nvidia-smi的定时采集把每张卡的显存占用、算力利用率和温度写入Prometheus。配置告警规则，当显存占用连续5分钟超过阈值的90%时报警。这样业务方可以提前感知风险，而不是等OOM崩了再补救。同时在训练框架层面开启显存动态分配（比如PyTorch的gpu_mem_limit），让显存有增长余量的任务自行兜底，而不是把所有风险交给调度器。
如果你觉得这套显存切分方案太复杂，也有更轻的替代：按整卡申请，但让多个不同Pod通过Volcano的taskGroup机制共享一张卡。这个方案不需要改资源模型，但是需要业务方把共享的Pod写进同一个TaskGroup，灵活性差一些，适合快速验证时用。
5.4 低优任务总被抢占，反复重启
抢占机制上线后，低优任务被反复杀掉重跑，这种情况说明优先级配置或者队列额度分配不合理。检查两个位置：低优任务的PriorityClass是否确实设置成了低于高优任务的值，命名空间默认PriorityClass是否覆盖了任务显式指定的优先级。
另外队列deserved和weight的配比也会影响抢占频率。如果train-prod的deserved设得过高，train-dev的额度就经常被压到很小，低优任务的生存空间变窄，频繁被抢占几乎必然。我的建议是deserved总和控制在整个集群资源的60%左右，留出40%的弹性空间给各队列按权重共享，这样低优任务有足够的闲时窗口运行，高优任务也不至于没资源可用。
6. 运维视角：从调度优化延伸到集群治理的几点体会
Volcano给我最大的感受是，它把“资源调度”这件事从“能调度就行”变成了“高效调度才算数”。但工具只是第一步，真正要省下那30%算力，还需要在整个集群治理链条上做配套。
第一，资源配额必须量化到业务方。有了Queue之后，每条业务线能用到多少GPU算力变成了一件可度量、可审计的事。业务方再也不会因为抢不到资源而互相扯皮，运维也能通过队列的使用率报表来判断资源分配是否合理。
第二，调度策略要和任务特性匹配。批量训练任务适合gang调度和binpack，在线推理服务追求的是低延迟和隔离性，不适合和训练任务混在一个队列里。如果你一个队列里既有训练又有推理，建议按优先级把两者区分开，推理服务用高优，训练用普通优先级。
第三，监控和告警体系要比调度器本身先行一步。Volcano带了基本的metrics端口，建议接入Prometheus，关注volcano_schedule_podgroup_*系列指标。这样你能直观看到每个PodGroup的调度耗时、调度失败次数、排队时延，遇到问题可以快速定位是资源不足还是调度器配置有误。
坦白说，Volcano的学习曲线不算陡，但真正让它发挥作用需要你对集群里的业务负载有清晰的认知——哪些任务能吃显存红利，哪些任务不能碰，哪些任务容忍被抢占，哪些必须保证连续性。这些判断做透了，调度器就是一个帮你把每张GPU卡的价值都榨干的好帮手。
最后分享一个小技巧：在配置PodGroup的minAvailable时，别盲目追求“完整”，稍微放宽到任务总数的80%往往能让调度成功率大幅提升。训练编排出错、某个Worker初始化失败这类问题在真实集群里太常见了，一个卡住的Pod拖垮整个任务，省下的算力全浪费在等待上了。学会给调度器留一点弹性空间，是我在实际运维里最大的心得之一。
