1. 引言
过去十年，Kubernetes 的调度器主要围绕 CPU 和内存做资源分配，GPU 往往只是"插在节点上的特殊设备"，需要管理员手工打标签、用 device plugin 勉强接入。但随着大模型训练、推理服务、科学计算全面拥抱 GPU，这种"二等公民"的地位已经难以为继。
2026 年，GPU 在 Kubernetes 调度体系中的地位正在发生根本性转变：它不再是需要特殊照顾的稀缺外设，而是与 CPU 同等重要的一等调度对象。本文将从趋势、技术栈、调度策略到企业实战，系统梳理 Kubernetes 上 AI 工作负载调度的完整图景。
2. 2026 年 GPU 调度趋势：GPU 已与 CPU 同等重要的调度对象
2.1 从"附属资源"到"一等公民"
在传统 Kubernetes 集群中，GPU 通过 nvidia.com/gpu 这类扩展资源暴露给调度器。调度器只把它当作一个"数量"来计数，无法感知 GPU 的拓扑、显存、算力类型，更无法做精细的分配决策。这导致：
- 整卡分配造成大量显存浪费；
- 无法感知 GPU 之间的 NVLink 拓扑，多卡任务可能被调度到跨 PCIe 的卡上，通信效率低下；
- 缺乏对 MIG（Multi-Instance GPU）等切分能力的原生支持。
2026 年的趋势是：GPU 成为调度器的一等对象，具备与 CPU 同等的资源建模能力------可量化、可切分、可感知拓扑、可参与复杂的调度约束。
2.2 调度语义的演进方向
| 维度 | 过去（GPU 作为外设） | 2026（GPU 作为一等公民） |
|---|---|---|
| 资源模型 | 整卡计数 | 分数 GPU、显存、算力、MIG 实例 |
| 拓扑感知 | 无 | NVLink、PCIe 交换机拓扑感知 |
| 分配粒度 | 整卡 | 分数 GPU、多实例共享 |
| 调度策略 | 简单过滤 | Gang Scheduling、队列、优先级、抢占 |
| 生态集成 | Device Plugin 单点接入 | GPU Operator + DRA + 高级调度器协同 |
2.3 为什么现在才发生转变
三个驱动力推动了这一转变：
- 大模型训练与推理的规模化：单任务动辄需要数十甚至上千张 GPU，整卡分配的资源浪费变得不可接受；
- GPU 供给的多样化：A100、H100、L40S、国产加速卡并存，异构调度成为刚需；
- 成本压力：企业开始精打细算 GPU 利用率，分数 GPU 共享成为降本的关键手段。
下面是 2026 年 GPU 调度语义演进的整体脉络：
3. 从整卡分配到分数 GPU：HAMi 与 KAI Scheduler 的精细化调度
3.1 为什么需要分数 GPU
一个典型的推理服务可能只需要 2GB 显存，却因为只能整卡分配而占满一张 80GB 的 A100。这种浪费在大规模推理场景下是灾难性的。分数 GPU（Fractional GPU）允许一张物理 GPU 被多个工作负载共享，显著提升利用率。
3.2 HAMi：异构 AI 计算设备虚拟化中间件
HAMi（Heterogeneous AI Computing Virtualization Middleware）是一个开源的 GPU 虚拟化方案，核心能力包括：
- 显存与算力切分：将一张物理 GPU 按显存和算力比例切分为多个虚拟 GPU；
- 设备隔离：每个虚拟 GPU 拥有独立的显存空间和算力配额；
- 异构支持：不仅支持 NVIDIA，还支持昇腾、寒武纪等国产加速卡；
- Kubernetes 原生集成：通过 Device Plugin 和调度器扩展实现自动分配。
yaml
apiVersion: v1
kind: Pod
metadata:
name: inference-pod
spec:
containers:
- name: inference
image: my-inference:latest
resources:
limits:
hami.io/vgpu: 1 # 申请 1 个虚拟 GPU
hami.io/vgpu-memory: 8 # 显存上限 8GB3.3 KAI Scheduler：面向 AI 工作负载的调度器
KAI Scheduler 是 NVIDIA 开源的 Kubernetes 调度器，专为 AI 工作负载设计，核心特性：
- 精细化资源分配：支持 GPU 显存、算力等细粒度资源的调度；
- 拓扑感知：优先将多卡任务调度到 NVLink 互联的 GPU 上；
- 优先级与抢占：支持基于优先级的调度和抢占，保障关键任务；
- 与 Volcano 兼容：可作为 Volcano 的替代或补充。
3.4 两者对比与选型
| 维度 | HAMi | KAI Scheduler |
|---|---|---|
| 定位 | GPU 虚拟化/切分 | 调度策略引擎 |
| 核心能力 | 显存/算力切分、异构支持 | 拓扑感知、优先级、抢占 |
| 与 K8s 集成 | Device Plugin + 调度扩展 | 独立调度器 |
| 适用场景 | 提升 GPU 利用率 | 大规模 AI 训练/推理调度 |
实际生产中，两者往往配合使用：HAMi 负责把 GPU 切细，KAI Scheduler 负责把切好的 GPU 智能地分给任务。
HAMi 与 KAI Scheduler 的协作关系如下图所示：
4. NVIDIA GPU 技术栈三层架构：GPU Operator、DRA、KAI Scheduler
4.1 第一层：GPU Operator------集群 GPU 就绪的自动化
GPU Operator 是 NVIDIA 提供的集群级运维组件，自动化完成 GPU 驱动、容器运行时、Device Plugin、DCGM 监控等组件的部署与升级。它让"节点插入 GPU 即自动就绪"成为可能。
bash
# 通过 Helm 安装 GPU Operator
helm install gpu-operator nvidia/gpu-operator \
--namespace gpu-operator \
--create-namespace4.2 第二层：DRA（Dynamic Resource Allocation）------资源分配的新范式
DRA 是 Kubernetes 1.26 引入的 Alpha 特性，在 1.29+ 逐步成熟。它取代了传统的 Device Plugin 模型，提供了更灵活、更细粒度的资源分配方式：
- 资源以"资源实例"而非"数量"暴露：调度器可以感知每个 GPU 的属性（显存、算力、拓扑）；
- 支持复杂的分配约束：如"必须分配在同一 PCIe 交换机下"；
- 由 Driver 决定分配细节：DRA 的 Driver 负责具体的设备选择和配置。
yaml
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
name: gpu-claim
spec:
resourceClassName: nvidia-gpu
parameters:
apiVersion: resource.k8s.io/v1beta1
kind: GpuParameters
memory: 16Gi
count: 24.3 第三层：KAI Scheduler------智能调度决策
KAI Scheduler 作为调度层，消费 DRA 暴露的细粒度资源信息，结合拓扑、优先级、队列等策略做出最优调度决策。三层架构的分工清晰：
5. Gang Scheduling 与工作负载队列：避免部分调度的 GPU 浪费
5.1 什么是 Gang Scheduling
分布式训练任务（如 PyTorch 的 DDP、Megatron）通常由多个 Pod 组成，它们需要同时启动才能正常工作。如果调度器只启动了其中一部分 Pod，其余 Pod 因资源不足而等待，那么已启动的 Pod 会白白占用 GPU 却无法工作------这就是"部分调度"造成的浪费。
Gang Scheduling（成组调度）要求一个任务的所有 Pod 要么全部调度成功，要么全部不调度，从根本上避免部分调度。
5.2 Volcano 的 Gang Scheduling 实现
Volcano 是 CNCF 孵化的 Kubernetes 批处理调度器，其 podgroup 机制实现了 Gang Scheduling：
yaml
apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
name: training-job
spec:
minMember: 4 # 最少需要 4 个 Pod 同时调度
queue: default
yaml
apiVersion: v1
kind: Pod
metadata:
name: worker-0
annotations:
scheduling.k8s.io/group: training-job # 关联 PodGroup
spec:
containers:
- name: worker
image: pytorch:latest
resources:
limits:
nvidia.com/gpu: 15.3 工作负载队列：资源配额与优先级管理
队列（Queue）机制为多团队、多任务共享集群提供了资源配额和优先级管理：
- 资源配额：每个队列有独立的资源上限，避免某个团队耗尽集群资源；
- 优先级：高优先级队列的任务可以抢占低优先级队列的资源；
- 公平性：支持基于权重的公平调度。
yaml
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
name: ai-training
spec:
weight: 10
capability:
cpu: "100"
memory: 200Gi
nvidia.com/gpu: 325.4 避免浪费的完整链路
6. 实战案例：深信服基于 Volcano + HAMi 构建企业 AI 计算平台
6.1 背景与挑战
深信服在构建企业级 AI 计算平台时面临三大挑战：
- GPU 利用率低：传统整卡分配导致大量显存浪费；
- 多团队资源竞争：不同业务部门共享集群，缺乏资源隔离和配额管理；
- 分布式训练效率差：部分调度导致 GPU 空转。
6.2 架构设计
深信服采用 Volcano + HAMi 的组合方案：
6.3 关键实施步骤
第一步：部署 Volcano
bash
# 安装 Volcano
kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/main/installer/volcano-tools.yaml第二步：部署 HAMi
bash
# 通过 Helm 安装 HAMi
helm repo add hami https://project-hami.github.io/HAMi
helm install hami hami/hami --namespace kube-system第三步：配置队列与配额
为不同业务部门创建独立队列，设置 GPU 配额和优先级。
第四步：业务接入
业务方在 Pod 中声明 hami.io/vgpu 资源，并关联 PodGroup 实现 Gang Scheduling。
深信服企业 AI 计算平台的落地路径可概括为：
6.4 收益与效果
- GPU 利用率提升：通过分数 GPU 共享，利用率从不足 30% 提升到 70% 以上；
- 训练效率提升：Gang Scheduling 消除了部分调度导致的 GPU 空转；
- 多团队隔离：队列机制实现了资源配额和优先级管理，避免资源争抢。
7. 总结与展望
2026 年，GPU 在 Kubernetes 中已经成为真正的一等公民。从 GPU Operator 的自动化运维，到 DRA 的细粒度资源建模，再到 KAI Scheduler、Volcano、HAMi 等组件的精细化调度，整个技术栈正在快速成熟。
对于正在构建 AI 基础设施的团队，建议从以下路径切入：
- 先用 GPU Operator 打好底座，实现 GPU 节点的自动化就绪；
- 引入 HAMi 或 MIG 做 GPU 切分，提升资源利用率；
- 部署 Volcano 或 KAI Scheduler，实现 Gang Scheduling 和队列管理；
- 逐步演进到 DRA，拥抱 Kubernetes 资源管理的新范式。
GPU 调度的精细化时代已经到来，尽早构建面向 AI 的调度能力，将在未来的算力竞争中占据先机。