多规格GPU混部时，调度公平性的核心答案在于：不能只看卡数，而必须按算力、显存、带宽三个维度加权分配，并配合动态抢占与排队机制。 混部场景下，A100和T4共处一池，如果调度器还按“一张卡”来平均分配，高规格卡被低负载任务占着，真正需要算力的任务反而排队，这种不公平会让整个集群的利用率与口碑一起崩盘，下面从痛点、策略、对比、实操和价格五个层面拆开讲。
GPU混部调度公平性如何保证？先看痛点在哪里
当A100和T4挤在同一台机器上
混部不是为了省电，而是为了把碎片化的算力拼起来，但问题来了：A100的算力大约是T4的8到10倍，显存容量也差出数倍，调度器如果是“平均主义”，每个任务分到一张卡，那么拿到T4的任务可能要等A100任务跑完才能吃上饭，而A100那张卡可能只跑了20%的利用率。
业内专家指出，这种不公平的根源在于调度模型把异构资源当成了同构资源，就像把货车和轿车放在同一条车道上按“一辆”来限行，结果就是货车堵车,轿车空驶。
不公平的调度会带来什么后果
后果不是慢一点那么简单,而是层层放大：
- 作业排队时间失控，SLA形同虚设
- GPU利用率虚高，实际算力产出却上不去
- 任务间相互干扰，显存溢出让节点直接重启
- 账单分摊扯皮，业务方觉得“我为没用的等待付了钱”
尤其是最后一条，混部通常涉及多个部门或多个客户，公平性一旦失守,信任就没了。
多规格GPU混部调度策略的三个关键维度
算力权重怎么算才公平
行业共识是引入“等效算力”概念，把不同GPU折算成统一单位，例如以T4为1个单位，V100计为3，A100计为8，H100计为16，调度时按这个权重分配任务，而不是按物理卡数，这样A100上跑一个大任务，相当于占用了8个单位的配额，而不是“一张卡”。
具体操作上，可以在资源模型里给每种GPU打标签，调度器读取标签后计算权重，Kubernetes环境下可以用nvidia.com/gpu-mig或自定义extended resource来实现。
显存与带宽的隔离策略
算力权重只是第一层，显存和带宽才是隐藏的坑，T4显存16GB，A100有40GB或80GB，如果任务显存需求是24GB，它只能落到A100上，但算力权重可能只需要2个单位，这会导致算力充足、显存紧张的局面。
推荐做法是双维度限额：
- 显存按绝对容量预留，使用cgroup或MIG切分
- 带宽按优先级限制，通过QoS或流量整形保护高优任务
在NVIDIA MIG模式下，可以把A100切成多个实例，每个实例拥有独立的显存和带宽，避免互相踩踏，调度器配置时，MIG实例的类型(如1g.5gb、2g.10gb)要作为独立资源上报,而不是笼统地报一张A100。
抢占与排队机制
即使有了权重和隔离，还是会出现“大任务占坑、小任务饿死”的情况,此时需要两层机制配合：
- 优先级队列：高优任务可以插队，但必须设置最大等待时间
- 抢占条件：当低优任务所在GPU空闲率超过阈值且高优任务等待超过时限，就触发抢占，低优任务被挂起并迁移
抢占不是暴力杀任务，而是先做checkpoint，保存中间状态，等资源空出后再恢复，这套机制在Volcano、KubeFlow等调度器中都有实现，配置时关键是设置好preemptionPolicy和queue参数。
多规格GPU混部性能对比：从基准测试看差异
空谈公平性没有说服力，我们看一组常见的混部测试场景：同一个深度学习训练任务，分别在独占T4、混部到T4(A100邻居)、独占A100三种情况下运行。
| 场景 | 单卡算力(FLOPS) | 显存带宽 | 任务完成时间 | 调度公平性评分 |
|---|---|---|---|---|
| 独占T4 | 1 TFLOPS | 320 GB/s | 基线(1.0x) | 高 |
| 混部T4(邻居A100) | 约7.8 TFLOPS | 300 GB/s | 约1.05x | 中 |
| 独占A100 | 156 TFLOPS | 1555 GB/s | 约0.15x | 高 |
数据来自常见公开benchmark的大致范围，不代表具体厂商，从中能看出，混部对性能的损伤其实很小，真正的问题不在算力而在调度，如果调度不像话，T4可能会被分配一个需要16GB以上显存的任务，直接失败,而不是慢一点这么简单。
所以性能对比不是要证明哪个卡更强，而是说明公平调度下混部的损耗可控制在5%左右，而调度失衡时任务失败率可能翻倍。
实操路径：在Kubernetes里配置公平调度
第一步：定义GPU资源模型
给每种GPU打上标签和权重：
gpu-type=a100，算力权重=8gpu-type=v100，算力权重=3gpu-type=t4，算力权重=1
然后在节点上配置extended resource，比如example.com/gpu-weight,调度器根据这个值做总量控制。
第二步：设置Pod的调度声明
在Pod的spec里，除了声明nvidia.com/gpu: 1，还需要声明example.com/gpu-weight: 8，这样调度器就知道这个Pod要占8个单位的算力，如果集群里只有一个T4(权重1),就不会把它调度过去。
第三步：开启队列与抢占
部署Volcano调度器，创建Queue对象，并设置capability，比如高优队列research可以占用最多80%的权重，低优队列batch最多50%,且允许被抢占。
Volcano的yaml配置大致如下：
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
name: research
spec:
capability:
example.com/gpu-weight: "800"
reclaimable: true
这里reclaimable: true表示队列中的任务可以被更高优先级任务抢占。
第四步：验证与监控
用kubectl top nodes看实时利用率，再用Prometheus监控GPU的DCGM_FI_DEV_GPU_UTIL指标，重点观察两个数：高优任务的平均等待时间和低优任务的被抢占次数，前者超过30秒说明优先级策略过松,后者频繁说明过紧。
多规格GPU混部价格计算：公平性如何影响账单
混部一定涉及成本分摊，如果按物理卡数计价，A100用户和T4用户付出同样的钱，但获得算力相差近10倍，这显然不合理，更公平的做法是按算力权重计费，即
单位价格 = 集群月度成本 / 总算力权重,然后每个任务按占用权重和使用时长付费。
举个例子：假设集群一个月总成本10万元，总算力权重为1000个单位，那么一个占用8权重、运行100小时的A100任务，费用就是 100000 / (1000 720) 8 100 ≈ 111元，而一个占用1权重、运行200小时的T4任务，费用约为 100000 / (1000 720) 1 200 ≈ 28元。
这种计费方式下，调度公平性直接影响财务模型，如果调度器不公平，权重明明没被占用却无法释放，那用户的账单就和实际获得的算力不匹配，久而久之就会出现“退租潮”。
所以价格规则要和调度规则绑定在一起，调度器上报的权重消耗数据，就是计费系统的输入，推荐用FinOps工具定期对账,确保每一笔账单都能追溯到具体的调度决策。
GPU混部调度公平性相关疑问解答
问：多规格GPU混部时，任务被抢占后进度会丢失吗？
不会，现代调度器在抢占前会触发checkpoint，保存模型权重和优化器状态，以PyTorch为例，torch.save配合分布式训练框架的弹性恢复机制，可以在新节点上继续训练，Volcano和KubeFlow都支持PodGroup级别的抢占恢复,关键是预先配置好共享存储和检查点目录。
问：混部场景下，小任务总是被大任务饿死，怎么调整？
先检查队列的capability是否设置过低，低优队列的权重份额不能小于任务峰值权重的两倍，否则永远没有空闲窗口，同时设置priorityClass，让小任务即使优先级不高，也能在等待超过5秒后触发抢占，如果队列已满，可以临时调高deserved值,但需要同步收紧大任务的超时限制。
问：国内哪家云厂商的GPU混部调度做得比较成熟？
简米云的ACK Pro版支持异构GPU混部，酷番云TKE和华为云CCE也提供了类似能力，据行业公开资料，三家都支持节点池级别资源隔离与权重调度，自建机房的话，Volcano加NVIDIA MIG是当前社区最稳妥的组合,配置成本低且没有绑定风险。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/624446.html
