开源 vGPU 方案 HAMi
一、k8s 环境下 GPU 资源管理的现状与问题
（一）资源感知与绑定
在 k8s 中，资源与节点紧密绑定。对于 GPU 资源，我们依赖 NVIDIA 提供的 device-plugin 来进行感知，并将其上报到 kube-apiserver。例如，通过执行 kubectl describe node gpu01|grep Capacity -A 7 命令，我们可以看到节点上的资源信息，其中包括 nvidia.com/gpu: 8，这表明该节点上有 8 个 GPU。这一机制使得 k8s 能够对 GPU 资源有一定的了解，但也带来了后续的调度问题。
（二）资源申请与调度限制
当我们创建一个 Pod 并申请 GPU 资源时，如以下示例：
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
spec:
containers:
- name: gpu-container
image: nvidia/cuda:11.0-base
resources:
limits:
nvidia.com/gpu: 1
command: ["nvidia-smi"]
restartPolicy: OnFailure
kube-scheduler 会根据 Pod 的资源请求将其调度到拥有足够 GPU 资源的 Node 上。但这里存在一个关键问题，一旦 GPU 资源被某个 Pod 申请，在 k8s 中就被标记为已消耗，后续创建的 Pod 可能会因为资源不足而无法调度。实际上，GPU 的性能可能足以支持多个 Pod 共同使用，但 k8s 的这种调度限制导致了资源利用率不高的情况。
二、HAMi 方案的引入：GPU 资源管理的新希望
（一）什么是 HAMi
HAMi 全称为 Heterogeneous AI Computing Virtualization Middleware，是一个异构算力虚拟化平台。它最初源自第四范式的 k8s-vgpu-scheduler，如今不仅开源，还将核心的 vCUDA 库 libvgpu.so 开放出来。当前，HAMi 在 NVIDIA GPU 的 vGPU 方案方面表现出色，为我们提供了一种有效的 GPU 资源共享和切分解决方案。
（二）HAMi 的特性：细粒度 GPU 隔离
HAMi 的一大亮点是能够实现 GPU 的细粒度隔离，可对 core 和 memory 使用 1% 级别的隔离。例如，在创建 Pod 时，我们可以通过以下方式指定 vGPU 的资源请求：
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
spec:
containers:
- name: ubuntu-container
image: ubuntu:18.04
command: ["bash", "-c", "sleep 86400"]
resources:
limits:
nvidia.com/gpu: 1
nvidia.com/gpumem: 3000
nvidia.com/gpucores: 30
在这个示例中，nvidia.com/gpu: 1 表示请求 1 个 vGPU，nvidia.com/gpumem: 3000 表示每个 vGPU 申请 3000m 显存，nvidia.com/gpucores: 30 表示每个 vGPU 的算力为 30% 实际显卡的算力。这种细粒度的资源控制能力，使得我们能够更精准地分配 GPU 资源，满足不同任务的需求。
三、HAMi 的工作原理：基于 vCUDA 方案的创新
（一）软件层面的驱动重写
HAMi 通过软件层面的 vCUDA 方案，对 NVIDIA 原生的 CUDA 驱动进行重写（libvgpu.so）。它将改写后的驱动挂载到 Pod 中进行替换，从而在自己实现的 CUDA 驱动中对 API 进行拦截。这一拦截机制是实现资源隔离和限制的关键。例如，原生的 libvgpu.so 在进行内存分配时，只有在 GPU 内存真正用完时才会提示 CUDA OOM，而 HAMi 实现的 libvgpu.so 则不同，当检测到 Pod 中使用的内存超过了 Resource 中的申请量时，就会直接返回 OOM，从而有效地限制了资源的使用。
（二）资源信息的隔离展示
在执行 nvidia-smi 命令查看 GPU 信息时，HAMi 也只会返回 Pod Resource 中申请的资源，进一步实现了资源的隔离展示。这使得用户在查看 GPU 资源使用情况时，看到的是经过隔离后的准确信息，避免了不同 Pod 之间资源信息的混淆。
四、HAMi 的部署与配置：轻松上手的实践指南
（一）部署前的准备
- 部署 GPU Operator
由于 HAMi 依赖 NVIDIA 的相关组件，推荐先部署 GPU Operator，为后续 HAMi 的部署打下坚实的基础。 - 获取 k8s 版本
在安装过程中，需要根据集群服务端版本来指定调度器镜像版本，因此要先通过kubectl version命令获取 k8s 版本信息。
（二）HAMi 的部署步骤
- 添加 repo 仓库
执行helm repo add hami-charts https://project-hami.github.io/HAMi/命令，添加 HAMi 的 Helm Chart 仓库。 - 安装 HAMi
根据获取到的 k8s 版本，使用如下命令进行安装（假设集群服务端版本为 v1.27.4）：
helm install hami hami-charts/hami --set scheduler.kubeScheduler.imageTag=v1.27.4 -n kube-system
安装完成后，可以通过 kubectl get pods -n kube-system|grep hami 命令查看 vgpu-device-plugin 与 vgpu-scheduler 两个 pod 的状态，若状态为 Running，则表示安装成功。
（三）自定义配置参数
HAMi 提供了丰富的自定义配置选项，通过在安装过程中使用 -set 参数来修改。例如：
devicePlugin.deviceSplitCount：整数类型，预设值是 10，用于设置 GPU 的分割数，每个 GPU 上最多可同时存在指定数量的任务。devicePlugin.deviceMemoryScaling：浮点数类型，预设值是 1，可设置 NVIDIA 装置显存使用比例，大于 1 时启用虚拟显存（实验功能）。devicePlugin.migStrategy：字符串类型，支持 “none” 与 “mixed” 两种工作方式，用于指定是否使用 MIG 设备。devicePlugin.disablecorelimit：字符串类型，“true” 为关闭算力限制，“false” 为启动算力限制，默认为 “false”。scheduler.defaultMem：整数类型，预设值为 5000，表示不配置显存时使用的默认显存大小，单位为 MB。scheduler.defaultCores：整数类型（0 - 100），默认为 0，代表默认为每个任务预留的百分比算力。scheduler.defaultGPUNum：整数类型，默认为 1，用于在 pod 资源中未设置nvidia.com/gpu时，根据其他相关资源键的值添加默认的nvidia.com/gpu键和值。resourceName、resourceMem、resourceMemPercentage、resourceCores、resourcePriority等：分别用于设置申请 vgpu 个数、显存大小、显存比例、算力、任务优先级的资源名，均有默认值。
此外，容器中也有对应配置，如 GPU_CORE_UTILIZATION_POLICY（字符串类型，“default”、“force”、“disable” 分别代表不同的容器算力限制策略）和 ACTIVE_OOM_KILLER（字符串类型，“true” 或 “false” 表示容器是否会因超用显存而被终止执行）。
五、HAMi 的验证：确保资源管理的有效性
（一）查看 Node GPU 资源
在部署 HAMi 后，虽然环境中可能只有一个物理 GPU，但 HAMi 默认会对其进行扩容。例如，通过执行 kubectl get node xxx -oyaml|grep capacity -A 7 命令，我们可以查看 Node 的资源信息，理论上能看到 nvidia.com/gpu 的数量有所增加（默认扩容 10 倍），这表明 HAMi 已经成功对 GPU 资源进行了虚拟切分。
（二）验证显存和算力限制
使用以下 YAML 文件创建一个 Pod 来验证显存和算力限制：
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
spec:
containers:
- name: ubuntu-container
image: ubuntu:18.04
command: ["bash", "-c", "sleep 86400"]
resources:
limits:
nvidia.com/gpu: 1
nvidia.com/gpumem: 3000
nvidia.com/gpucores: 30
创建完成后，通过 kubectl exec -it gpu-pod -- bash 进入 Pod，执行 nvidia-smi 命令。从输出结果中，我们可以看到 GPU 的内存使用情况和算力使用情况是否符合我们在 Pod 资源请求中设定的限制。例如，在上述示例中，我们期望看到 GPU 内存使用量不超过 3000MiB，算力使用不超过 30%。同时，注意到命令执行后的日志中会有 HAMi 的 CUDA 驱动打印信息，如 [HAMI-core Msg(16:139711087368000:multiprocess_memory_limit.c:434)]: Calling exit handler 16，这也进一步证明了 HAMi 在资源管理方面的作用。
通过以上对 HAMi 方案的全面介绍，我们可以看到它在 k8s 环境下 GPU 资源管理方面具有显著的优势和实用性。无论是解决资源利用率不高的问题，还是实现细粒度的资源隔离与限制，HAMi 都为我们提供了一种可行的解决方案。希望这篇博客能够帮助大家更好地理解和应用 HAMi，在实际工作中充分发挥 GPU 资源的潜力，提升计算任务的执行效率。
