多规格GPU混部调度公平性探讨：为何你的K8s集群总在“掐架”
多规格GPU混部时，调度公平性的核心答案在于：不能只看显存和算力做平均分配，必须引入带权重的配额机制、节点拓扑感知和可抢占的弹性调度策略，否则混部集群必然陷入“大卡饿死、小卡挤爆”的资源错配困境。
想象一个真实的机房场景：机架上同时躺着A100 80GB、V100 16GB和RTX 4090 24GB三种卡，业务方都觉得自己分到的“不公平”训练团队抱怨大卡被推理任务占着，推理团队说训练任务把显存吃光了导致自己频繁排队，这不是运维执行力的问题，是调度器没想明白“公平”二字在异构场景下的新定义。
影响多规格GPU混部调度公平性的关键因素
传统Kubernetes调度器对GPU资源只认“数量”，不认“型号”，你把A100和4090都标成nvidia.com/gpu: 1，调度器就默认它们等值，这相当于把保时捷和五菱宏光都叫“汽车”，按辆分配，行业共识认为，这种粗粒度模型是公平性崩坏的起点。
资源异构引起的“短板效应”
当调度器把一个需要30GB显存的推理任务放到V100上,任务直接OOM；放到4090上勉强能跑，但性能只有A100的六成，另一种情况更隐蔽：某任务申请1张卡，调度器把4090分给它，但任务实际只用8GB显存，剩下的16GB就浪费了，而旁边排队的任务还在等着用A100。
- 显存碎片化：大卡被小任务占着，小卡被大任务挤爆。
- 算力错配：计算密集型的任务跑到游戏卡上，吞吐掉得厉害。
- 显存带宽瓶颈：A100的HBM2e带宽是4090的GDDR6X的两倍多，任务跑在慢卡上，时长翻倍。
优先级与抢占机制的缺失
多数混部集群沿用K8s默认的PriorityClass,但这个机制对GPU资源并不敏感，高优先级任务被调度后，低优先级任务只能无限等待，没有抢占通道，你想让一个低优先级的离线推理任务在训练任务间隙“捡漏”用卡？默认调度器做不到。
这就好比你按“先来后到”排队进停车场，不管你是停五分钟买杯咖啡，还是停一整天上班，五分钟后想走的人出不去，外面急着停的人等不到车位。
节点拓扑与网络拓扑的隐性不公平
GPU混部不只是卡的问题,A100所在的节点大概率配有高带宽的NVLink和InfiniBand网卡，而4090所在的机器可能只有千兆以太网，调度器只看显卡资源，不看网络拓扑，导致部分任务虽然分到了卡，却被网络带宽拖累，实际完成时间比预期多出数倍。
节点资源碎片化
当集群里只有少数几台A100节点,调度器会把不同任务尽量“填满”这些节点，导致大卡节点上的CPU和内存被快速耗尽，后续即使有新的高优先级任务需要A100，调度器也会因为节点CPU不足而拒绝分配。
如何为多规格GPU混部设计公平的配额体系
公平不是“平均分配”，而是“按权重分配”，你需要把GPU资源抽象成可量化的计算单元，而不是简单地数卡。
引入规范化算力单位
建议为每种GPU卡赋予一个“算力分”：
| GPU型号 | 显存 | 相对算力权重 | 适用场景 |
|---|---|---|---|
| A100 80GB | 80GB | 10 | 大模型训练、科学计算 |
| V100 16GB | 16GB | 4 | 中等规模训练、特征工程 |
| RTX 4090 24GB | 24GB | 2 | 推理、小批量微调 |
调度器不再按nvidia.com/gpu: 1分配，而是按算力权重动态计算，比如某任务申请“20个算力单位”，调度器可以给它2张A100，或5张4090，或1张A100加5张4090的组合（如果网络拓扑允许）。
分池配额与弹性借调
把集群按GPU型号分为多个资源池：
- 训练池：A100为主，允许V100补充。
- 推理池：4090和V100为主，按需借用A100。
- 混合池：接受任意卡型，适合无状态批处理任务。
每个池子有保底配额,但允许超额申请，例如训练池保底100个A100算力单位，但在推理高峰时段，推理池可以临时借用训练池50个单位的算力，只要训练池当前空闲，借用超过30分钟仍未归还，调度器强制抢占。
在Kubernetes中落地Quota
用ResourceQuota或LimitRange对象，结合自定义调度器扩展点，给每个命名空间设定GPU算力上限，实际操作路径如下：
- 为每个GPU型号创建自定义资源名称,例如
gpu.example.com/a100。 - 在调度器配置中启用
NodeResourceFit插件，并写入自定义资源的权重。 - 修改节点的
capacity与allocatable字段，上报每张卡的显存与算力权重。 - 使用
descheduler定期扫描节点，把可压缩任务迁移到低负载节点，释放大卡资源。
为何默认调度器无法满足异构GPU混部需求
K8s默认调度器对GPU的支持停留在“扩展资源计数”层面，它只能做三件事：看节点剩余卡数、看请求卡数、看节点标签，无法感知任务的显存需求是否匹配卡型，也无法感知任务之间的通信拓扑。
你需要的调度策略
- Binpack（装箱）策略：对相同卡型的节点优先分配，减少碎片，适用于训练集群，任务长时间占用。
- Spread（打散）策略：将任务分散到不同节点，降低单点故障风险，适用于在线推理，任务之间互相独立。
- 拓扑感知调度：结合
nvidia.com/gpu.memory和nvidia.com/gpu.product标签，让调度器优先选择显存恰好匹配的节点。
业内专家指出,异构GPU混部场景下，单一调度策略注定失败，必须组合使用以上策略，并且把“节点真实负载”作为调度决策的输入项。
避免“少数大卡被锁死”的局面
生产环境有个常见坑：某个加了GPU整卡调度器（如NVIDIA K8s Device Plugin）后，任务只要申请了A100，就默认独占整卡，哪怕它只用了一半显存，这导致大量A100被半闲置，而其他任务又在排队。
建议启用虚拟化或分片能力（如MIG或vGPU），把A100切成2-3个实例，调度器看到的不是一张卡，而是多个可分配的“GPU切片”，这样一个小型推理任务可以只占1/3的A100，剩余2/3留给别的任务，集群实际利用率能上来30%以上。
如何实施多规格GPU混部调度的操作步骤
纸上谈兵没用,直接给可执行的路径。
第一步：节点分组与标签规划
# 为A100节点打标签 kubectl label node node-a100-01 gpu-type=a100 gpu-memory=80g gpu-weight=10 # 为4090节点打标签 kubectl label node node-4090-01 gpu-type=gamer gpu-memory=24g gpu-weight=2 # 为V100节点打标签 kubectl label node node-v100-01 gpu-type=legacy gpu-memory=16g gpu-weight=4
第二步：配置自定义调度器策略
修改KubeSchedulerConfiguration文件,加入nodeAffinity和podAntiAffinity规则：
plugins:
filter:
enabled:
- name: "NodeResourceFit"
weight: 70
score:
enabled:
- name: "NodeResourcesBalancedAllocation"
weight: 30
第三步：设置Pod的调度约束
spec:
containers:
- name: training-job
resources:
requests:
cpu: 8
memory: 32Gi
nvidia.com/gpu: 1
limits:
nvidia.com/gpu: 1
nodeSelector:
gpu-type: a100
tolerations:
- key: "dedicated"
operator: "Equal"
value: "training"
effect: "NoSchedule"
第四步：监控与反馈调优
部署Prometheus + Grafana，重点监控三个指标：
- 每种GPU型号的实际利用率（利用
DCGM-Exporter获取）。 - 节点的GPU调度失败次数（查看kube-scheduler日志）。
- 任务的排队等待时长（通过自定义Exporter上报）。
当发现某型号GPU的等待队列超过10个任务,而另一型号空闲率高于40%，你需要调整算力权重或修改节点亲和规则。
多规格GPU混部调度的实际挑战与应对思路
网络域公平性如何保证
大模型训练任务卡间通信频繁,如果A100和4090混插在同一台物理机上，NVSwitch的带宽会被不同速度的卡同时抢占，即便调度器给了任务合理的卡型，网络层面的“慢速卡拖累快速卡”仍然存在。
应对思路：用topologyManager的best-effort模式，让调度器在带状拓扑中选择同一NUMA节点下的GPU，同时为训练任务单独划分专属网络策略（NetworkPolicy），限制推理任务的带宽上限。
国内互联网公司常见的混部场景是怎样的
以国内某云厂商的实际环境为例：同一个K8s集群里跑着数据 preprocessing 任务（用CPU+少量GPU）、在线推荐系统（用4090推理）、以及大模型SFT微调（用A100训练），他们的做法是设计三级优先级：
- P0：在线推荐，固定预留A100的30%算力，总配额不变。
- P1：SFT微调，使用A100剩余算力，可被P0抢占。
- P2：数据预处理，使用V100或4090余量，可被P0和P1共同抢占。
调度器每30秒检查一次节点水位,当P0任务需要更多资源时，通过Descheduler把P2的Pod驱逐到低负载节点。
训练与推理混部时多久调整一次算力权重
不用频繁调整,设置成每小时或每天固定时间点即可，训练任务通常是长时间占用的，推理任务波动大在分钟级，你可以写一个CronJob读取Prometheus的GPU利用率指标，动态修改调度器的score插件权重，但改动频次过高会造成调度震荡，任务反复重启。
推荐的做法是：只在“推理任务等待数超过阈值”或“训练任务在队列中的时间超过1小时”时，触发一次权重调整，而不是持续微调。
Q&A：多规格GPU混部调度常见的三个问题
多规格GPU混部调度是否需要专门硬件支持
不需要专门硬件,但依赖NVIDIA的软件生态，最新的K8s Device Plugin已经原生支持nvidia.com/gpu.memory和nvidia.com/gpu.product标签，配合MIG可以支持A100和H100的显存隔离，如果是跨厂商的GPU混部（比如某国产加速卡加A100），则需要额外开发自定义调度插件，因为不同厂商的设备插件实现方式不同。
如何保证混部调度的公平性度量可量化，而不是拍脑袋
可用“任务完成时间中位数”和“任务排队时间P99”作为核心指标，具体做法是让集群中的任务带上时间戳，通过Prometheus记录任务从创建到运行的时间差，公平意味着两个算力权重相同的任务，在不同时间段提交，排队等待时间的分布应当接近，如果P99排队时间持续高于P50的两倍以上，说明有严重的头部占坑问题，需要引入更积极的可抢占策略。
在只有一个GPU型号的集群中，这些方案还能用吗
能用的部分是“带权重的配额管理”和“按优先级的抢占策略”，节点分组和拓扑感知这两块可以简化，因为你不需要区分卡型，但建议保留算力权重概念，因为后续若升级GPU型号，调度策略的平滑迁移会容易得多，行业共识认为，调度公平性设计应当超前于硬件迭代，不要等到集群里出现A100再补调度逻辑，那往往已经晚了。
多规格GPU混部的调度公平性,本质上是让不同代际、不同算力的GPU在同一个集群里“各尽所能，各取所需”，你不能指望一张4090干完A100的活，也不能放任A100被低负载任务长期占用，通过规范化算力权重、设计弹性配额池、组合运用Binpack与Spread策略，并让调度器感知节点真实负载，混部集群能做到运行均衡、队列稳定，每个任务都有一个更合理的等待时间。
公平调度的终点不是让所有任务平均等待，而是让每个任务按自身的重要程度和资源需求，获得尽量接近其预期的等待结果。