本文评估口径：面向企业 AI 平台的 GPU 调度治理，重点讨论队列、配额、优先级、资源暴露和观测闭环，不展开具体训练框架调参。
GPU调度真正要回答的是：有限 GPU 资源如何在多个团队、多个任务类型和不同优先级之间分配。Kubernetes 默认调度能解决 Pod 放置问题，但企业 AI 平台还需要在这之上增加队列、公平性和配额治理。
图1：GPU调度从资源暴露、队列等待到配额消费的治理总览
先区分三类 GPU 调度问题
Kubernetes 官方文档说明，默认调度器负责把 Pod 放到合适节点上，调度决策会结合资源请求、约束和调度策略[1]。很多团队把 GPU 调度问题简化成“Pod Pending”，但实际原因可能完全不同；先分清问题类型，才能决定是改队列、改配额，还是优化资源池。
常见问题可以分成三类：
- 资源不可见：节点有 GPU，但集群没有暴露对应扩展资源，Pod 申请不到。
- 资源不可用：GPU 已被占用、碎片化或被节点约束限制，任务只能等待。
- 资源不可控：多个团队争抢 GPU，没有队列、优先级和配额，导致关键任务被低优先级任务挤占。
NVIDIA Kubernetes device plugin 的作用，是把节点上的 GPU 作为 Kubernetes 扩展资源暴露给工作负载使用[3]。这解决的是“资源能不能被 Kubernetes 看见”，并不自动解决“谁先用、用多少、何时回收”的治理问题。
队列配额是 GPU调度落地的核心
如果只有单个团队使用 GPU，按节点和资源请求调度通常可以起步；一旦进入多租户、多项目、多环境，队列配额就会成为核心治理对象。Kueue 面向批处理和 AI/ML 类工作负载，提供队列、准入控制和资源配额等能力，适合用来表达团队、项目和资源池之间的关系[2]。
图2：LocalQueue、ClusterQueue、Reso
| 治理对象 | 回答的问题 | 常见设计方式 | 风险点 |
|---|---|---|---|
| LocalQueue | 某个命名空间的任务从哪里排队 | 按团队、项目或环境划分 | 队列过细会增加维护成本 |
| ClusterQueue | 多个队列共享哪些资源 | 按资源池、业务域或租户组划分 | 配额过宽会影响公平性 |
| ResourceFlavor | 使用哪类 GPU 或节点 | 按 GPU 型号、区域、节点池区分 | 标签不一致会导致任务误入 |
| Priority | 谁应该先运行 | 按任务类型、业务等级定义 | 高优先级滥用会挤压常规任务 |
配额优化不能只看利用率
GPU 利用率高不一定代表调度健康。训练任务长时间占用 GPU、推理任务被延迟、短任务被大任务阻塞，都可能让利用率好看但体验很差。队列配额的目标是让资源使用可预期，而不是把所有 GPU 时刻打满。
落地 GPU 队列配额的5步路径
GPU 调度落地建议先从可观测、可约束、可回滚的小范围开始，不要一上来就调整全平台优先级。
- 盘点资源池。确认 GPU 型号、节点标签、拓扑、驱动版本、设备插件状态和可用容量。
- 划分队列层级。按团队、项目、训练 / 推理、生产 / 实验环境拆分 LocalQueue 和共享资源池。
- 定义配额口径。明确每个队列的名义配额、可借用范围、抢占策略和高峰期限制。
- 设置准入和优先级。把关键训练、在线推理和实验任务放入不同优先级，不让低价值任务长期占用关键卡。
- 建立观测闭环。持续跟踪排队时间、任务失败、配额使用、GPU 空闲、碎片和抢占事件。
这条路径和普通 Kubernetes 工作负载调度的差异在于，它不只关心 Pod 是否调度成功，还关心任务是否在合理时间、合理队列、合理资源池中运行。需要理解训练任务与 GPU 资源关系时，可延伸阅读站内的 Kubernetes 承载 AI 训练任务的调度实践 。
资源碎片与多租户隔离要提前设计
GPU 资源最容易出现“看似有卡，任务却调不上去”的情况。原因通常是显存、型号、拓扑、节点亲和、驱动版本和任务请求之间不匹配。NVIDIA MIG 等能力可以把部分 GPU 按实例切分，但是否启用要结合硬件型号、任务特征和隔离需求判断[3]。
设计资源池时建议记录这些字段：
- GPU 型号与规格：避免不同型号混入同一个无差别队列。
- 任务类型：训练、微调、批量推理、在线推理对延迟和占用时间不同。
- 隔离要求：生产推理、研发实验和共享训练是否允许共池。
- 回收策略：空闲 Notebook、失败任务和长期占用任务如何释放。
- 可观测指标：排队时长、运行时长、失败率、GPU 显存和利用率是否分队列展示。
图3：GPU调度上线前的队列、配额、资源池和观测检查清单
小结
GPU调度落地不能只靠“给 Pod 加 GPU request”。企业 AI 平台需要把设备暴露、队列准入、配额消费、资源池隔离、优先级和观测指标串起来，才能从“谁抢到卡谁运行”走向“算力使用可解释、可审计、可优化”。
如果只能先做一件事，建议先建立队列与资源池关系图，再定义配额和观测字段。这样即使暂时不引入复杂策略，也能让 GPU 资源治理从人工协调走向平台化。
参考资料
常见问题
1. GPU调度一定要引入 Kueue 吗？
不一定。单团队、小规模或主要运行在线推理的环境，可以先用节点池、资源请求、命名空间配额和基础监控起步。Kueue 更适合批处理、训练任务、多租户排队和配额治理明显的场景。
2. 队列配额应该按团队分，还是按任务类型分？
通常建议先按组织责任划分，再在队列内部区分任务类型。只按任务类型划分容易导致归属不清，只按团队划分又可能无法保障在线推理或关键训练任务。成熟平台会同时考虑团队、环境和任务优先级。
3. GPU 利用率低是否说明调度策略失败？
不一定。GPU 利用率低可能来自数据加载瓶颈、任务间歇、显存碎片、型号不匹配或队列策略保守。判断调度策略时应同时看排队时间、失败率、任务吞吐、显存占用和资源池空闲情况。
4. 多租户 GPU 调度最容易忽略什么？
最容易忽略回收和审计。Notebook、实验任务和失败 Job 如果不自动清理，会长期占用 GPU；高优先级队列如果没有审批和审计，也会让公平性失效。建议把资源回收、优先级变更和配额调整都纳入平台记录。
