GPU 管理技术深度解析

GPU 在 AI 基础设施中几乎是最昂贵的硬件,但它的设计初衷却是”独占使用”。把这种硬件放到多人共用、任务混跑的 AI 平台里,就会冒出一串很具体的问题:一张 80GB 显存的 H100 怎么让十个小推理任务共享?训练任务卡在一台机器上、别的机器 GPU 闲着怎么办?容器里怎么安全地看到 GPU 却又不越权?这一章就是围绕这些问题展开的。


1. 概述

要把 GPU 纳管起来,通常要同时解决四件事,它们环环相扣:

  • GPU 虚拟化:把一张物理卡抽象成多张”逻辑卡”。这一步有三条路径——硬件级(SR-IOV、MIG)靠芯片自身能力做隔离,内核级通过驱动层做拦截转发,用户态则在 API 层(如 CUDA API 劫持)做虚拟化。三条路径的隔离强度、性能损耗和部署门槛都不一样。
  • GPU 切分:虚拟化之后真正要做的是”按需分配”。时间片切分让多个任务轮流占用,物理分割(如 MIG)切出独立的算力与显存分区,而混合切分在时间与空间两个维度上同时切,换取更高的利用率。
  • 远程 GPU 调用:当本机没有 GPU 或本机 GPU 被占满,如何把算力”借”到其他节点?这就需要一层网络协议把 CUDA 调用转发到远端 GPU 上执行,并尽量压低延迟和序列化开销。
  • 容器化与 Kubernetes 编排:前面三件事解决了”一张卡怎么被多个任务共用”,这一层要解决的是”整个集群的 GPU 怎么被统一调度”。NVIDIA Container Toolkit、CDI 规范和 OCI 运行时负责把 GPU 安全地注入容器;Kubernetes Device Plugin 框架、MIG 集成和智能调度器则把这些容器摆到正确的节点、正确的卡上,并配上健康监控与故障恢复。

四件事合起来,才构成一个可以在生产环境稳定服役的 GPU 资源池。


2. GPU 管理技术

下面按“理论 → 实现 → 配置”三条线组织材料:先把概念和机制讲清楚,再用可运行的代码演示关键路径,最后给出可以直接套用的部署配置。

2.1 GPU 管理技术文档

这一部分是整个话题的主干,按从浅到深的顺序分为四篇——先理清传统模式为什么不够用,再分别深入虚拟化、资源切分与生产落地。

2.2 代码实现

光看文档很容易停留在概念层面,这里配套了一组可读、可编译的 demo 代码,把前面讲到的机制落到具体的数据结构和系统调用上——重点不是做一个完整产品,而是让关键路径可以被追踪和调试。

2.2.1 Demo 代码

按模块分组的 C/C++ 与 Go 参考实现,覆盖内存、调度、虚拟化、远程调用和 Kubernetes 集成等核心链路:

  • 内存管理 (code/memory/):
  • 调度系统 (code/scheduling/):
    • GPU 调度器 - 基于时间片与优先级的资源调度算法。
  • 虚拟化拦截 (code/virtualization/):
  • 远程调用 (code/remote/):
  • HAMi 集成 (code/hami/):

2.2.2 配置文件

从单机容器配置到多云 GPU 集群模板,这部分给出可以直接套用的 YAML 与脚本,省去“从零写一份生产配置”的心智负担:

  • 容器与编排
  • 监控与网络
  • 运维脚本 (configs/scripts/):
    • 提供从环境初始化、基准测试到故障排查的全套自动化 Shell 脚本(如 gpu-performance-test.sh)。

3. HAMi 专题

如果说前面讲的是“GPU 共享可以怎么做”,HAMi 就是一个把这些想法真正跑在 Kubernetes 集群里、并且已经在开源社区长期演进的参考实现。它在云原生环境中提供细粒度的 GPU 共享能力,这里专门拿出来讲它的核心机制、可观测性指标以及与其他调度方案的横向对比。


4. 相关资源

GPU 管理不是一个孤立的话题——往下会触到硬件和运维,往上会接到 Kubernetes 调度和推理框架。下面这些链接可以作为继续深挖的入口。

4.1 核心技术资源

支撑 GPU 高效运行的基础配套:集群通信、推理系统、底层运维,每一项都是 GPU 真正跑起来之后绕不开的环节。

4.2 容器化与编排

把视角拉回到平台侧:GPU 如何被容器和 Kubernetes 纳管,以及它底下的硬件长什么样。

4.3 官方文档

遇到细节争议时,以 NVIDIA 与 CNCF 这几份权威规范为准,避免被二手资料误导。