1. 背景
一句话理解：K8s 原生调度器是为 CPU/内存设计的“可分配即可调度”，而 GPU 是 all-or-nothing、拓扑敏感、显存硬墙、多租户争抢的稀缺资源——不理解 AI 负载的这四条特征，就无法解释为什么 Device Plugin、GPU Operator、Gang 调度、队列调度会相继出现。
版本现状（2026-10）：DRA（Dynamic Resource Allocation）已于 Kubernetes 1.34（2025-09）GA，1.35 起特性门锁定常开，1.37（2026-08）又把“扩展资源映射”推向 GA——Device Plugin 时代开始过渡到声明式设备分配时代；Kubernetes 1.37 原生 Gang 调度（Workload/PodGroup API，KEP-4671）进入 Beta；GPU Operator 26.7 起内置 DRA 支持（
GPUClusterCR）；NVIDIA 把 KAI Scheduler（2025-04 开源，源自 Run:ai 调度引擎）与 DRA GPU driver 捐入 CNCF，llm-d（推理解耦框架）也于 KubeCon EU 2026 进入 CNCF——GPU 调度格局正在从“Device Plugin + 第三方调度器”演进到“DRA + 多调度器共存”。
1.1 AI 训练与推理的四个本质特征
all-or-nothing：要么全员就位，要么全部白跑
分布式训练作业（DDP、FSDP、Megatron、DeepSpeed）通常由若干 worker 组成，每个 worker 都需要一张或多张 GPU。如果 scheduler 一个个地分配，会出现：
worker-0 worker-1 worker-2 worker-3 worker-4 worker-5 worker-6 worker-7
✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗前 7 个 Pod 已经拿到卡开始初始化，第 8 个因为集群没卡而永远 Pending。前 7 个要么 hang 在 init_process_group，要么把显存占着却没有任何有效计算。这就是 Gang 调度要解决的问题：8 个 Pod 必须同时被调度，否则一个都不调。
显存墙：OOM 不是“内存不够”，而是“任务进不来”
GPU 显存（VRAM）是硬资源。一张 80GB 的 A100 在加载 70B 模型时，权重、优化器状态、激活值、KV Cache 会把显存吃得干干净净：
模型参数 优化器状态 激活值 KV Cache 可用余量
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
70 GB 14 GB 8 GB 6 GB 2 GB ← 余量极小K8s 原生只认识 nvidia.com/gpu: 1，不认识“这张卡还剩多少显存”。两个都请求 1 卡的 Pod 可以落在同一张卡上，但如果它们各自都需要 48GB，而卡只有 80GB，就会出现 CUDA OOM。解决方向有两个：
- 在 Pod 里显式声明显存需求（通过 Device Plugin 的扩展资源或第三方调度器）。
- 使用 MIG 等硬切分，把一张物理卡切成多张逻辑卡，每张逻辑卡有固定显存。
拓扑敏感：NCCL 性能不是只看卡数
多机训练的性能由 NVLink、PCIe switch、NUMA、NIC 位置共同决定：
| 拓扑因素 | 影响 |
|---|---|
| NVLink | 同一 NVLink domain 内的 GPU 之间带宽最高，适合张量并行 |
| PCIe Switch / Root Complex | 跨 switch 的 P2P 带宽下降，延迟上升 |
| NUMA | GPU 与 CPU 内存、NIC 是否在同一 NUMA node，影响数据拷贝 |
| NIC 位置 | GPU Direct RDMA 要求 GPU 与 RDMA NIC 在同一 PCIe switch 下或同一 NUMA node |
原生 K8s scheduler 看不到这些拓扑信息，它只数“这张节点有几张卡”。结果一个需要 8 卡 NVLink 亲和的训练 Job 可能被拆到两台 4 卡机器上，或者 8 张卡跨了两个 PCIe switch，NCCL 性能大打折扣。
多租户公平性：训练 Job 与推理服务抢同一张卡
AI 平台往往同时跑：
- 长时间、高优先级、需要多卡的训练 Job；
- 短生命周期、低延迟要求、需要快速扩缩容的推理服务；
- 开发调试用的 Jupyter Notebook。
如果没有任何排队与配额机制，就会出现“谁手快谁抢到卡”。训练 Job 把资源占满，推理服务 Pending；推理服务把资源占满，训练 Job 永远排不上。平台需要的不是“先到先得”，而是：
- 队列（Queue）：把未满足的资源需求按优先级和配额排队。
- 公平调度（Fair Sharing）：保证不同团队/业务按权重获得资源。
- 抢占（Preemption）：高优先级任务可以抢占低优先级任务。
- 资源预留/借用（Lending）：团队 A 的空闲配额可以借给团队 B，但 A 有任务时收回。
1.2 原生 Kubernetes 调度为什么不够
Kubernetes 的默认调度器非常擅长 CPU/内存调度：它看 requests/limits，跑 Filter → Score → Bind， kubelet 负责实际执行。但面对 GPU，它缺少以下能力：
| 缺失能力 | 原生行为 | GPU 场景需要的 |
|---|---|---|
| 设备发现 | 不认识 GPU | 通过 Device Plugin 把 GPU 注册为 nvidia.com/gpu |
| 显存感知 | 只数卡，不看显存 | 知道每张卡还剩多少显存，或按 MIG 实例分配 |
| 拓扑感知 | 看不到 NUMA/PCIe/NVLink | 把 Pod 调度到拓扑最优的 GPU 组合 |
| Gang 调度 | 逐个 Pod 调度 | 一组 Pod 同时满足才绑定 |
| 队列公平 | 没有队列概念 | 多租户排队、配额、抢占、借用 |
| 动态切分 | 资源是整数 | MIG/MPS/time-slicing 的细粒度共享 |
| 故障隔离 | 节点级 | 单卡故障时不要把新 Pod 调度到该卡 |
这些缺口不是 K8s 设计错误，而是 K8s 故意把“异构资源怎么暴露”交给 Device Plugin，把“复杂调度规则怎么实现”交给调度框架扩展点。GPU 调度主题就是研究怎么把这些扩展点串起来。
1.3 GPU 在 K8s 上的演进路线
2016 Kubernetes 1.4 Device Plugins 设计讨论开始
2017 Kubernetes 1.8 Device Plugins alpha
2018 Kubernetes 1.10 Device Plugins beta
2018 Kubernetes 1.11 scheduler-plugins / Coscheduling 雏形
2019 Kubernetes 1.14 Device Plugins GA
2019 Volcano 0.1 面向 AI/HPC 的批处理调度器
2020 NVIDIA GPU Operator 1.0 自动化节点 GPU 组件
2021 scheduler-plugins NodeResourceTopology
2022 Kueue 0.1 面向 Job 的队列与公平调度
2023 Kueue 进入 Kubernetes SIG-scheduling 子项目
2025-04 NVIDIA 开源 KAI Scheduler（源自 Run:ai 调度引擎，基于 kube-batch）
2025-09 Kubernetes 1.34 DRA GA（resource.k8s.io/v1：ResourceClaim / DeviceClass / ResourceSlice）
2025-12 Kubernetes 1.35 DRA 特性门锁定常开；KAI Scheduler 进入 CNCF Sandbox
2026-03 KubeCon EU 2026：NVIDIA DRA GPU driver 捐入 kubernetes-sigs；llm-d 进入 CNCF
2026-04 Kubernetes 1.36 DRA 分区设备 / 设备污点（beta）；GPU Operator 26.3 动态 MIG 配置
2026-08 Kubernetes 1.37 DRA 扩展资源映射 GA；原生 Gang 调度（KEP-4671）Beta
2026-08 GPU Operator 26.7 内置 DRA 支持（GPUCluster CR、ComputeDomain 多机 NVLink）这条演进线可以分成三层：
- 设备发现与分配层：Device Plugin 让 kubelet 能“看见”GPU 并分配给容器；DRA（1.34 GA）则把这层升级为声明式的 ResourceClaim + DeviceClass 模型，支持按属性（型号、显存、NUMA）选择设备，而非只数个数。
- 节点组件自动化层：GPU Operator 把驱动、container-toolkit、Device Plugin、监控、MIG 配置等组件打包成节点就绪流水线；26.x 起又接管 DRA driver 与多机 NVLink ComputeDomain 的生命周期。
- 调度策略增强层：scheduler-plugins、Volcano、Kueue、KAI Scheduler 分别在默认调度器之上或之外提供 Gang、拓扑、队列能力；1.37 起 K8s 原生也开始内建 Workload/PodGroup 的 Gang 语义。
1.4 AI Infra 视角：为什么 GPU 调度格外重要
训练场景
| 场景 | 调度需求 | 相关技术 |
|---|---|---|
| 大模型预训练（千卡级） | Gang、拓扑、容错 | Volcano / Kueue + NodeResourceTopology |
| 微调（数十卡） | 队列、抢占、显存切分 | Kueue + MIG / MPS |
| 分布式 RL | 多角色 PodGroup、异构资源 | Volcano Job + PodGroup |
| 开发/调试 Notebook | 单卡、快速借用、低优先级 | Kueue LocalQueue + 抢占 |
推理场景
| 场景 | 调度需求 | 相关技术 |
|---|---|---|
| 大模型单实例多卡推理 | 拓扑、NVLink | NodeResourceTopology + exclusive GPU |
| 小模型高密度推理 | GPU 共享、隔离、Latency SLO | time-slicing / MPS + HPA |
| Serverless 推理 | 缩容到零、快速扩容 | Kueue + Knative / KServe |
| 多租户隔离 | 硬隔离、配额、排队 | MIG + Kueue ClusterQueue |
一张 GPU 卡的价格往往是同代 CPU 服务器的数倍。如果调度做得不好，要么利用率低（卡闲着），要么效率低（Job 跑得慢），要么公平性差（团队互相抢）。这三种浪费都会直接转化为成本。
1.5 本章小结
| 阶段 | 问题 | 解决方案 |
|---|---|---|
| K8s 早期 | 不认识 GPU | Device Plugin（1.14 GA）把 GPU 注册为扩展资源 |
| 节点运维 | 驱动/toolkit/plugin 手动安装困难 | NVIDIA GPU Operator 自动化节点组件 |
| 调度语义 | 只数卡、无 Gang、无拓扑 | scheduler-plugins / Volcano / Kueue |
| 多租户 | 抢资源、无配额公平 | Kueue Queue + Volcano Queue + 抢占机制 |
| 设备模型升级 | Device Plugin 只有“数量”，没有属性 | DRA（1.34 GA）：ResourceClaim + DeviceClass，按型号/显存/NUMA 选设备 |
| 未来 | 更细粒度、更动态的资源模型 | DRA 扩展资源映射（1.37 GA）、原生 Gang 调度（1.37 Beta）、显存/算力分数化、KAI Scheduler / llm-d 推理调度新范式 |
GPU 在 K8s 上的落地，本质上是在**“K8s 通用资源抽象”与“GPU 异构硬件现实”之间搭一座桥**。下一章我们将进入这座桥的核心概念：extended resource、Device Plugin、GPU 切分模型与调度语义。
参考来源
- Kubernetes v1.34：DRA 正式 GA（resource.k8s.io/v1 API 稳定）
- Kubernetes v1.37：DRA Updates（扩展资源映射 GA、设备污点 GA、KEP-5729 等）
- Kubernetes v1.37 Release（Garhwal）（原生 Workload/PodGroup Gang 调度 Beta，KEP-4671）
- NVIDIA GPU Operator Release Notes（26.7 DRA、25.10 Blackwell）
- KAI Scheduler（CNCF Sandbox）、llm-d（KubeCon EU 2026 进入 CNCF）