企业官网建设流程全解析

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 调度语义的演进方向

2.3 为什么现在才发生转变

三个驱动力推动了这一转变：

1. 大模型训练与推理的规模化：单任务动辄需要数十甚至上千张 GPU，整卡分配的资源浪费变得不可接受；
2. GPU 供给的多样化：A100、H100、L40S、国产加速卡并存，异构调度成为刚需；
3. 成本压力：企业开始精打细算 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 和调度器扩展实现自动分配。

apiVersion:v1kind:Podmetadata:name:inference-podspec:containers:-name:inferenceimage:my-inference:latestresources:limits:hami.io/vgpu:1# 申请 1 个虚拟 GPUhami.io/vgpu-memory:8# 显存上限 8GB

3.3 KAI Scheduler：面向 AI 工作负载的调度器

KAI Scheduler 是 NVIDIA 开源的 Kubernetes 调度器，专为 AI 工作负载设计，核心特性：

• 精细化资源分配：支持 GPU 显存、算力等细粒度资源的调度；
• 拓扑感知：优先将多卡任务调度到 NVLink 互联的 GPU 上；
• 优先级与抢占：支持基于优先级的调度和抢占，保障关键任务；
• 与 Volcano 兼容：可作为 Volcano 的替代或补充。

3.4 两者对比与选型

实际生产中，两者往往配合使用：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 即自动就绪”成为可能。

# 通过 Helm 安装 GPU Operatorhelminstallgpu-operator nvidia/gpu-operator\--namespacegpu-operator\--create-namespace

4.2 第二层：DRA（Dynamic Resource Allocation）——资源分配的新范式

DRA 是 Kubernetes 1.26 引入的 Alpha 特性，在 1.29+ 逐步成熟。它取代了传统的 Device Plugin 模型，提供了更灵活、更细粒度的资源分配方式：

• 资源以“资源实例”而非“数量”暴露：调度器可以感知每个 GPU 的属性（显存、算力、拓扑）；
• 支持复杂的分配约束：如“必须分配在同一 PCIe 交换机下”；
• 由 Driver 决定分配细节：DRA 的 Driver 负责具体的设备选择和配置。

apiVersion:resource.k8s.io/v1beta1kind:ResourceClaimmetadata:name:gpu-claimspec:resourceClassName:nvidia-gpuparameters:apiVersion:resource.k8s.io/v1beta1kind:GpuParametersmemory:16Gicount:2

4.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：

apiVersion:scheduling.volcano.sh/v1beta1kind:PodGroupmetadata:name:training-jobspec:minMember:4# 最少需要 4 个 Pod 同时调度queue:default

apiVersion:v1kind:Podmetadata:name:worker-0annotations:scheduling.k8s.io/group:training-job# 关联 PodGroupspec:containers:-name:workerimage:pytorch:latestresources:limits:nvidia.com/gpu:1

5.3 工作负载队列：资源配额与优先级管理

队列（Queue）机制为多团队、多任务共享集群提供了资源配额和优先级管理：

• 资源配额：每个队列有独立的资源上限，避免某个团队耗尽集群资源；
• 优先级：高优先级队列的任务可以抢占低优先级队列的资源；
• 公平性：支持基于权重的公平调度。

apiVersion:scheduling.volcano.sh/v1beta1kind:Queuemetadata:name:ai-trainingspec:weight:10capability:cpu:"100"memory:200Ginvidia.com/gpu:32

5.4 避免浪费的完整链路

6. 实战案例：深信服基于 Volcano + HAMi 构建企业 AI 计算平台

6.1 背景与挑战

深信服在构建企业级 AI 计算平台时面临三大挑战：

1. GPU 利用率低：传统整卡分配导致大量显存浪费；
2. 多团队资源竞争：不同业务部门共享集群，缺乏资源隔离和配额管理；
3. 分布式训练效率差：部分调度导致 GPU 空转。

6.2 架构设计

深信服采用 Volcano + HAMi 的组合方案：

6.3 关键实施步骤

第一步：部署 Volcano

# 安装 Volcanokubectl apply-fhttps://raw.githubusercontent.com/volcano-sh/volcano/main/installer/volcano-tools.yaml

第二步：部署 HAMi

# 通过 Helm 安装 HAMihelm repoaddhami https://project-hami.github.io/HAMi helminstallhami hami/hami--namespacekube-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 基础设施的团队，建议从以下路径切入：

1. 先用 GPU Operator 打好底座，实现 GPU 节点的自动化就绪；
2. 引入 HAMi 或 MIG 做 GPU 切分，提升资源利用率；
3. 部署 Volcano 或 KAI Scheduler，实现 Gang Scheduling 和队列管理；
4. 逐步演进到 DRA，拥抱 Kubernetes 资源管理的新范式。

GPU 调度的精细化时代已经到来，尽早构建面向 AI 的调度能力，将在未来的算力竞争中占据先机。