Kubernetes 中的 GPU 调度与虚拟化手册 — 精炼总结

来源：jimmysong.io/zh/book/gpu-infra/ | 作者：Jimmy Song 核心命题：GPU 资源问题正在从"单机性能优化"迁移为"平台治理问题"

一、全书架构总览

本书以 Kubernetes 为基座，系统梳理 GPU 资源的控制面与数据平面，分六大模块：

| 模块 | 核心关注点 | 关键项目/概念 | |------|-----------|-------------| | 基础认知与问题定义 | 认知框架、异构生态、治理难点 | AI 加速芯片图谱、GPU 硬件基础、控制面/数据面分工 | | 数据平面技术 | GPU 资源切分与共享的底层机制 | MIG、HAMi、DRA、CUDA MPS、时间片 | | 控制面治理 | 调度策略、配额、队列 | Volcano、Kueue、Kthena | | 工作负载实践 | 实际 AI 负载的调度实践 | vLLM、PyTorch、Ray/KubeRay | | 可观测与验收 | 监控、计量、容量规划 | DCGM、Prometheus 指标 | | 生态与趋势 | 长期演进方向 | DRA 标准化、异构调度 |

二、GPU 基础认知：从硬件到 K8s

2.1 CPU vs GPU：工程特性对比

| 维度 | CPU | GPU | |------|-----|-----| | 设计目标 | 低延迟、强控制流 | 高吞吐、弱控制流 | | 并行模型 | 少量复杂核心（十级） | 大量简单核心（千级） | | 主要瓶颈 | 指令路径 / Cache | 显存容量与带宽 | | 调度主体 | OS（CFS 等） | 驱动 + Runtime（CUDA） | | 虚拟化成熟度 | 极高 | 天然较弱，需专门方案 |

核心结论：Kubernetes 天生擅长管理 CPU，却难以直接表达 GPU 的内部资源。

2.2 GPU 五类核心部件

计算单元（SM / Tensor Cores）— 算力来源
显存（HBM / GDDR）— 第一约束
片上缓存（L2 / Shared Memory）
互联（PCIe / NVLink / NVSwitch）— 多卡关键
驱动与固件（Driver / Firmware）

2.3 显存 vs 算力：最关键的区别

算力是软约束 → 决定跑得快不快（可时间片共享，关注干扰控制与 QoS）
显存是硬约束 → 决定能不能跑（连续分配、不可分页、与进程强绑定）

典型现象：节点显示还有剩余显存，但新任务无法启动 → 显存碎片/连续分配失败。

2.4 GPU 互联拓扑

| 互联方式 | 带宽 | 延迟 | 适用场景 | |---------|------|------|---------| | PCIe 4.0 | ~64 GB/s（x16） | 高 | 入门/推理 | | NVLink 3.0 | ~60 GB/s/link，总计 ~600 GB/s | 低 | A100 TP 训练 | | NVLink 4.0 | ~900 GB/s | 极低 | H100 大模型训练 | | NVSwitch | 全互联 NVLink | 极低 | 8卡+ 服务器内部 | | InfiniBand | ~400 Gb/s | 极低 | 跨节点训练（高性能） | | RoCE v2 | ~400 Gb/s | 低 | 跨节点训练（成本更低） |

调度启示：TP 训练需确保所有 GPU 在同一 NVLink 域内；PP/DP 可跨节点但需低延迟网络。

2.5 GPU 资源使用层级

| 层级 | 调度变量 | 复杂性来源 | |------|---------|-----------| | 单节点单卡 | 驱动+运行时 | CUDA 上下文、显存分配 | | 单机多卡 | 互联拓扑 | PCIe vs NVLink/NVSwitch | | 多节点 | 跨节点通信 | 调度放置 + NCCL 通信效率 |

2.6 Kubernetes GPU 使用最小链路

Device Plugin → 报告设备数量
    ↓
容器工具链（NVIDIA Container Toolkit）→ 注入驱动与用户态库
    ↓
kube-scheduler → 节点级放置（只看"有没有"，不管"怎么用"）

K8s 能力边界：负责节点级放置，不负责 GPU 内部的显存、算力、公平性与干扰控制。

三、AI 加速芯片生态图谱

3.1 四象限分类

| 芯片类型 | 核心特征 | K8s 集成难度 | 典型玩家 | |---------|---------|-------------|---------| | 通用 GPU | 兼容 CUDA/ROCm，通用计算 | 低 | NVIDIA、AMD、沐曦、摩尔线程、壁仞、天数智芯 | | 专用 AI 加速器 | 自研架构，针对推理/训练优化 | 中 | 华为昇腾、寒武纪、燧原、昆仑芯、Google TPU | | 云厂商自研芯片 | 服务自有业务，不对外销售 | 不适用 | 平头哥含光、腾讯紫霄 | | 垂直场景芯片 | 面向特定终端或场景 | 高/不适用 | 地平线征程、黑芝麻、Apple Neural Engine |

3.2 K8s 集成成熟度速查

| 厂商 | Device Plugin | 共享/隔离 | DRA 驱动 | HAMi 支持 | |------|-------------|----------|---------|----------| | NVIDIA | 官方，成熟 | MIG/vGPU/时间片/MPS | Beta（CDI-based） | 完善 | | AMD | 官方，可用 | SRIOV 部分支持 | 开发中 | 有限 | | Intel | 官方，可用 | 整卡直通为主 | 探索中 | 有限 | | 华为昇腾 | 官方，可用 | 静态/动态虚拟化 | 未公开 | 已支持 | | 寒武纪 | 官方，可用 | HAMi 集成 | 待推进 | 已支持 | | 摩尔线程 | 自有插件 | HAMi 接入 | 未公开 | 部分支持 |

3.3 选型框架

预算充足 + 最低风险 → NVIDIA（默认选项，CUDA 护城河深）
降低 NVIDIA 依赖 → AMD（ROCm + PyTorch 已可用，CUDA→HIP 迁移成本）
信创/国产化 → 昇腾（部署规模最大）、摩尔线程/沐曦（通用 GPU 进展快）
多云混合 → 评估 DRA 成熟度和 HAMi 适配广度

四、数据平面核心技术

4.1 GPU 并发机制全景（NVIDIA）

从硬件到软件五层并发机制：

| 机制 | 分区类型 | 最大分区数 | SM 隔离 | 显存保护 | 错误隔离 | 适用场景 | |------|---------|-----------|--------|---------|---------|----------| | CUDA Streams | 单进程内 | 无限 | ❌ | ❌ | ❌ | 单应用内并发优化 | | CUDA MPS | 多进程逻辑分区 | 48 | ⚠️（百分比限制） | ✅ | ❌ | 多进程并行，可接受有限容错 | | 时间片 | 时间配额 | 无限 | ✅ | ✅ | ✅ | 延迟不敏感，开发/测试/CI/CD | | MIG | 硬件物理分区 | 7 | ✅ | ✅ | ✅ | 多租户强隔离，生产环境 | | vGPU | VM 虚拟化（SR-IOV） | 可变 | ✅ | ✅ | ✅ | 需 VM 管理（迁移/混合负载） |

选型原则：隔离要求高→MIG/vGPU；成本低/开发用→时间片；单应用优化→CUDA Streams。

4.2 CUDA MPS（Multi-Process Service）

允许多个进程的 CUDA kernel 并行执行（不是时间片轮转）
支持限制：CUDA_MPS_PINNED_DEVICE_MEM_LIMIT（显存）和 CUDA_MPS_ACTIVE_THREAD_PERCENTAGE（算力）
局限：错误隔离弱，一个进程崩溃可能影响其他 MPS 客户端
适用于：MPI 并行计算、多进程推理共享

4.3 时间片（Time-Slicing）

自 Pascal 架构起支持（compute preemption），CUDA 11.1+ 可配时间片长度
K8s Device Plugin 0.12+ 支持声明式配置：

# dp-example-config.yaml
version: v1
sharing:
  timeSlicing:
    resources:
    - name: nvidia.com/gpu
      replicas: 4  # 1 张 GPU 声明为 4 份

权衡：上下文切换开销增加延迟和抖动，OOM 风险随并发数增加
适合：Jupyter 开发、低并发推理、CI/CD 流水线

4.4 MIG（Multi-Instance GPU）

NVIDIA A100/H100 硬件级隔离方案
将一张 GPU 切分为最多 7 个独立实例，每个实例拥有独立的 SM、显存、L2 缓存
强隔离：故障不影响其他实例
约束：离散规格（不能任意切分）、重配置需停止工作负载、仅 A100/H100/B100 支持
MIG 实例内仍可使用 CUDA Streams、MPS、时间片

4.5 HAMi（CNCF Sandbox 项目）

HAMi（Heterogeneous AI Computing Virtualization Middleware）是 CNCF 沙箱项目，提供统一的异构算力虚拟化和调度。

架构组件：

Pod 提交 → Mutating Webhook → Scheduler Extender（filter/score/bind）
         → Device Plugin Allocate → 容器运行时环境注入 → Monitor 指标

核心能力：

显存隔离 — 按显存配额分配，容器内看到限制后的显存大小
算力限制 — 限制容器可用 SM 算力百分比
多厂商支持 — NVIDIA、华为昇腾、寒武纪、海光、摩尔线程、沐曦等
调度策略 — binpack（紧凑）、spread（分散）、拓扑感知、动态 MIG

Pod 资源请求示例：

resources:
  limits:
    nvidia.com/gpu: 1        # 1 张物理 GPU
    nvidia.com/gpumem: 3000  # 限制 3GB 显存

安装：

helm repo add hami-charts https://project-hami.github.io/HAMi/
helm install hami hami-charts/hami -n kube-system

定位：跨层系统（数据面+控制面），DRA 成熟后控制面职责可能逐步移出。

4.6 DRA（Dynamic Resource Allocation）— K8s v1.35 Stable

DRA 是 Kubernetes 原生的动态资源分配机制，类比动态 PV 供给，但面向 GPU 等硬件设备。

核心 API（resource.k8s.io/v1）：

| API | 角色 | 说明 | |-----|------|------| | ResourceSlice | 设备驱动创建 | 声明节点上可用的设备资源 | | DeviceClass | 管理员/驱动定义 | 设备分类（如 "高性能 GPU"、"通用 GPU"）| | ResourceClaim | 工作负载创建 | 请求特定设备配置 | | ResourceClaimTemplate | 工作负载创建 | 模板化，自动为每个 Pod 生成独立 Claim |

DRA vs Device Plugin 对比：

| 维度 | Device Plugin | DRA | |------|--------------|-----| | 资源粒度 | 整数（nvidia.com/gpu: 2） | 按属性过滤（CEL 表达式） | | 设备共享 | ❌ 不支持 | ✅ 多 Pod/容器共享 | | 调度可见性 | 黑盒 Allocate | 控制面可推理 | | 设备过滤 | 无 | CEL 表达式精细筛选 | | 成熟度 | K8s 1.8+ 已有 | v1.35 Stable |

ResourceClaim 示例：

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: gpu-claim
spec:
  spec:
    devices:
      requests:
      - name: gpu
        deviceClassName: nvidia.com/gpu
        selectors:
        - cel: "device.attributes['nvidia.com'].memory > 40000"

关键判断：DRA 成熟度将是未来 1-2 年区分芯片生态的关键指标。

五、控制面治理

5.1 控制面 vs 数据面分工

┌──────────────────────────────────────────────┐
│               控制面（Control Plane）          │
│  调度策略、配额管理、队列优先级、拓扑感知放置   │
│  Volcano · Kueue · Kthena                    │
├──────────────────────────────────────────────┤
│               数据面（Data Plane）             │
│  GPU 资源切分、共享执行、设备驱动、虚拟化       │
│  MIG · HAMi · DRA · CUDA MPS · 时间片        │
└──────────────────────────────────────────────┘

5.2 关键项目

| 项目 | 角色 | 适用场景 | |------|------|---------| | Volcano | 批处理调度器 | AI 训练批量作业、gang scheduling | | Kueue | 配额准入控制器 | 多租户资源配额、队列管理 | | Kthena | 推理调度 | 在线推理负载的延迟感知调度 | | 组合架构 | 多项目协同 | 生产环境通常需要组合使用 |

六、工作负载实践

6.1 vLLM 推理实践

vLLM 是当前最主流的 LLM 推理引擎，在 K8s 中部署需关注：

PagedAttention — 核心创新，KV Cache 分页管理，显存利用率接近理论极限
Continuous Batching — 请求级动态批处理，替代传统 static batching
Tensor Parallelism — 多 GPU 并行，需 K8s 拓扑感知调度保证 NVLink 直连
显存规划 — gpu_memory_utilization 参数控制 KV Cache 占比（默认 0.9）

# vLLM on K8s 关键配置
resources:
  limits:
    nvidia.com/gpu: 2  # TP=2
env:
- name: CUDA_VISIBLE_DEVICES
  value: "0,1"
- name: VLLM_TENSOR_PARALLEL_SIZE
  value: "2"

6.2 分布式训练实践

| 策略 | 适用模型规模 | 通信模式 | K8s 调度要求 | |------|------------|---------|-------------| | DDP | 小于单卡显存 | AllReduce | 无特殊要求 | | TP（Tensor Parallelism） | 中等 | AllReduce/AllGather | 必须 NVLink 直连 | | PP（Pipeline Parallelism） | 大 | 点对点 | 节点间低延迟 | | TP+PP+DP（3D 并行） | 超大 | 混合 | 拓扑感知+gang scheduling |

NCCL — NVIDIA 集合通信库，训练通信核心，需正确配置 NCCL_SOCKET_IFNAME
KubeRay — Ray 的 K8s Operator，管理 RayCluster/RayJob
Volcano — 提供 gang scheduling，确保分布式训练所有 Pod 同时启动

七、可观测与验收

7.1 观测维度

| 指标 | 来源 | 含义 | 告警阈值建议 | |------|------|------|-------------| | DCGM_FI_DEV_GPU_UTIL | DCGM Exporter | GPU 计算利用率 | 持续 <20% 或 >95% | | DCGM_FI_DEV_FB_USED/TOTAL | DCGM Exporter | 显存使用率 | >90% | | DCGM_FI_DEV_GPU_TEMP | DCGM Exporter | GPU 温度 | >85°C | | DCGM_FI_DEV_POWER_USAGE | DCGM Exporter | 功耗 | 接近 TDP | | DCGM_FI_DEV_MEMORY_ERRORS | DCGM Exporter | 显存 ECC 错误 | >0 即告警 | | HAMi 共享指标 | HAMi Monitor (:31993) | vGPU 分配/使用 | 自定义 |

7.2 基准测试与容量规划

基准测试工具：

gpu-burn — 显存带宽压力测试
nccl-tests — 集合通信性能（AllReduce 带宽）
resnet_benchmark / bert_benchmark — AI 算力基准

容量规划公式：

推理：并发数 × 模型显存 + KV Cache ≈ 可用显存
训练：模型参数 × 20 bytes（混合精度）÷ DP × TP × PP
GPU 利用率陷阱：算力利用率高 ≠ 有效算力高（可能在等数据/通信）

八、知识速查

GPU 平台能力模型（7 维度）

粒度：整卡 → MIG 分区 → 显存配额 → 时间片
隔离：硬件级（MIG）→ 虚拟化（vGPU）→ 软件级（HAMi/MPS）→ 无隔离
干扰控制：QoS 策略、带宽限制、优先级
可观测：DCGM 指标、应用级 Metrics、计量计费
运维复杂度：驱动管理、固件升级、故障恢复
兼容性：CUDA 兼容、框架支持、容器运行时
异构扩展：多厂商混部、DRA 支持

决策流程（一句话版）

选芯片 → 看 CUDA 兼容性和 K8s 集成成熟度
选共享方案 → 看隔离要求和运维成本
选调度器 → 看负载类型（训练=Volcano，推理=Kthena，配额=Kueue）
选可观测 → DCGM + Prometheus 是起点

NVIDIA 数据中心 GPU 代际速查

| 代际 | 代表型号 | 显存 | FP16 算力 | 关键特性 | |------|---------|------|----------|----------| | Volta | V100 | 16/32 GB HBM2 | 125 TFLOPS | Tensor Core 起源 | | Ampere | A100 | 40/80 GB HBM2e | 312 TFLOPS | MIG 支持，训练规模化 | | Hopper | H100 | 80 GB HBM3 | 990 TFLOPS | Transformer Engine，FP8 | | Blackwell | B200 | 192 GB HBM3e | 4.5 PFLOPS(FP4) | 双 die 设计，NVLink 5.0 |

GPU 共享方案速查

| 方案 | 隔离强度 | 运维成本 | 延迟影响 | 最佳场景 | |------|---------|---------|---------|---------| | 整卡独占 | ★★★★★ | 低 | 无 | 单租户/关键训练 | | MIG | ★★★★★ | 高 | 无 | 多租户生产 | | HAMi 显存隔离 | ★★★ | 中 | 低 | 多租户推理/开发 | | 时间片 | ★★ | 低 | 有抖动 | CI/CD/开发 | | MPS | ★★ | 中 | 无（并行） | MPI 并行计算 |

九、参考资源

在线阅读：jimmysong.io/zh/book/gpu-infra/
HAMi 项目：github.com/Project-HAMi/HAMi | project-hami.io
DRA 文档：kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/
NVIDIA GPU Operator：docs.nvidia.com/datacenter/cloud-native/gpu-operator
NVIDIA MIG 用户指南：docs.nvidia.com/datacenter/tesla/mig-user-guide/
Volcano：volcano.sh
KubeRay：github.com/ray-project/kuberay

本文基于 Jimmy Song GPU 基础设施教程框架，补充了 NVIDIA 官方文档、HAMi 项目文档和 K8s DRA 文档。教程原文仍在草稿阶段（2/26 篇已完成），后续更新可重新采集。

📚 喵喵的笔记库

探索

Kubernetes 中的 GPU 调度与虚拟化手册 — 精炼总结

Kubernetes 中的 GPU 调度与虚拟化手册 — 精炼总结

一、全书架构总览

二、GPU 基础认知：从硬件到 K8s

2.1 CPU vs GPU：工程特性对比

2.2 GPU 五类核心部件

2.3 显存 vs 算力：最关键的区别

2.4 GPU 互联拓扑

2.5 GPU 资源使用层级

2.6 Kubernetes GPU 使用最小链路

三、AI 加速芯片生态图谱

3.1 四象限分类

3.2 K8s 集成成熟度速查

3.3 选型框架

四、数据平面核心技术

4.1 GPU 并发机制全景（NVIDIA）

4.2 CUDA MPS（Multi-Process Service）

4.3 时间片（Time-Slicing）

4.4 MIG（Multi-Instance GPU）

4.5 HAMi（CNCF Sandbox 项目）

4.6 DRA（Dynamic Resource Allocation）— K8s v1.35 Stable

五、控制面治理

5.1 控制面 vs 数据面分工

5.2 关键项目

六、工作负载实践

6.1 vLLM 推理实践

6.2 分布式训练实践

七、可观测与验收

7.1 观测维度

7.2 基准测试与容量规划

八、知识速查

GPU 平台能力模型（7 维度）

决策流程（一句话版）

NVIDIA 数据中心 GPU 代际速查

GPU 共享方案速查

九、参考资源

关系图谱