開源 vGPU 方案 HAMi

一、k8s 環(huán)境下 GPU 資源管理的現(xiàn)狀與問題

（一）資源感知與綁定

在 k8s 中，資源與節(jié)點緊密綁定。對于 GPU 資源，我們依賴 NVIDIA 提供的 device-plugin 來進行感知，并將其上報到 kube-apiserver。例如，通過執(zhí)行 kubectl describe node gpu01|grep Capacity -A 7 命令，我們可以看到節(jié)點上的資源信息，其中包括 nvidia.com/gpu: 8，這表明該節(jié)點上有 8 個 GPU。這一機制使得 k8s 能夠?qū)?GPU 資源有一定的了解，但也帶來了后續(xù)的調(diào)度問題。

（二）資源申請與調(diào)度限制

當我們創(chuàng)建一個 Pod 并申請 GPU 資源時，如以下示例：

apiVersion: v1
kind: Pod
metadata:name: gpu-pod
spec:containers:- name: gpu-containerimage: nvidia/cuda:11.0-baseresources:limits:nvidia.com/gpu: 1command: ["nvidia-smi"]restartPolicy: OnFailure

kube-scheduler 會根據(jù) Pod 的資源請求將其調(diào)度到擁有足夠 GPU 資源的 Node 上。但這里存在一個關鍵問題，一旦 GPU 資源被某個 Pod 申請，在 k8s 中就被標記為已消耗，后續(xù)創(chuàng)建的 Pod 可能會因為資源不足而無法調(diào)度。實際上，GPU 的性能可能足以支持多個 Pod 共同使用，但 k8s 的這種調(diào)度限制導致了資源利用率不高的情況。

二、HAMi 方案的引入：GPU 資源管理的新希望

（一）什么是 HAMi

HAMi 全稱為 Heterogeneous AI Computing Virtualization Middleware，是一個異構算力虛擬化平臺。它最初源自第四范式的 k8s-vgpu-scheduler，如今不僅開源，還將核心的 vCUDA 庫 libvgpu.so 開放出來。當前，HAMi 在 NVIDIA GPU 的 vGPU 方案方面表現(xiàn)出色，為我們提供了一種有效的 GPU 資源共享和切分解決方案。

（二）HAMi 的特性：細粒度 GPU 隔離

HAMi 的一大亮點是能夠?qū)崿F(xiàn) GPU 的細粒度隔離，可對 core 和 memory 使用 1% 級別的隔離。例如，在創(chuàng)建 Pod 時，我們可以通過以下方式指定 vGPU 的資源請求：

apiVersion: v1
kind: Pod
metadata:name: gpu-pod
spec:containers:- name: ubuntu-containerimage: ubuntu:18.04command: ["bash", "-c", "sleep 86400"]resources:limits:nvidia.com/gpu: 1nvidia.com/gpumem: 3000nvidia.com/gpucores: 30

在這個示例中，nvidia.com/gpu: 1 表示請求 1 個 vGPU，nvidia.com/gpumem: 3000 表示每個 vGPU 申請 3000m 顯存，nvidia.com/gpucores: 30 表示每個 vGPU 的算力為 30% 實際顯卡的算力。這種細粒度的資源控制能力，使得我們能夠更精準地分配 GPU 資源，滿足不同任務的需求。

三、HAMi 的工作原理：基于 vCUDA 方案的創(chuàng)新

（一）軟件層面的驅(qū)動重寫

HAMi 通過軟件層面的 vCUDA 方案，對 NVIDIA 原生的 CUDA 驅(qū)動進行重寫（libvgpu.so）。它將改寫后的驅(qū)動掛載到 Pod 中進行替換，從而在自己實現(xiàn)的 CUDA 驅(qū)動中對 API 進行攔截。這一攔截機制是實現(xiàn)資源隔離和限制的關鍵。例如，原生的 libvgpu.so 在進行內(nèi)存分配時，只有在 GPU 內(nèi)存真正用完時才會提示 CUDA OOM，而 HAMi 實現(xiàn)的 libvgpu.so 則不同，當檢測到 Pod 中使用的內(nèi)存超過了 Resource 中的申請量時，就會直接返回 OOM，從而有效地限制了資源的使用。

（二）資源信息的隔離展示

在執(zhí)行 nvidia-smi 命令查看 GPU 信息時，HAMi 也只會返回 Pod Resource 中申請的資源，進一步實現(xiàn)了資源的隔離展示。這使得用戶在查看 GPU 資源使用情況時，看到的是經(jīng)過隔離后的準確信息，避免了不同 Pod 之間資源信息的混淆。

四、HAMi 的部署與配置：輕松上手的實踐指南

（一）部署前的準備

1. 部署 GPU Operator
   由于 HAMi 依賴 NVIDIA 的相關組件，推薦先部署 GPU Operator，為后續(xù) HAMi 的部署打下堅實的基礎。
2. 獲取 k8s 版本
   在安裝過程中，需要根據(jù)集群服務端版本來指定調(diào)度器鏡像版本，因此要先通過 kubectl version 命令獲取 k8s 版本信息。

（二）HAMi 的部署步驟

1. 添加 repo 倉庫
   執(zhí)行 helm repo add hami-charts https://project-hami.github.io/HAMi/ 命令，添加 HAMi 的 Helm Chart 倉庫。
2. 安裝 HAMi
   根據(jù)獲取到的 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 的狀態(tài)，若狀態(tài)為 Running，則表示安裝成功。

（三）自定義配置參數(shù)

HAMi 提供了豐富的自定義配置選項，通過在安裝過程中使用 -set 參數(shù)來修改。例如：

• devicePlugin.deviceSplitCount：整數(shù)類型，預設值是 10，用于設置 GPU 的分割數(shù)，每個 GPU 上最多可同時存在指定數(shù)量的任務。
• devicePlugin.deviceMemoryScaling：浮點數(shù)類型，預設值是 1，可設置 NVIDIA 裝置顯存使用比例，大于 1 時啟用虛擬顯存（實驗功能）。
• devicePlugin.migStrategy：字符串類型，支持 “none” 與 “mixed” 兩種工作方式，用于指定是否使用 MIG 設備。
• devicePlugin.disablecorelimit：字符串類型，“true” 為關閉算力限制，“false” 為啟動算力限制，默認為 “false”。
• scheduler.defaultMem：整數(shù)類型，預設值為 5000，表示不配置顯存時使用的默認顯存大小，單位為 MB。
• scheduler.defaultCores：整數(shù)類型（0 - 100），默認為 0，代表默認為每個任務預留的百分比算力。
• scheduler.defaultGPUNum：整數(shù)類型，默認為 1，用于在 pod 資源中未設置 nvidia.com/gpu 時，根據(jù)其他相關資源鍵的值添加默認的 nvidia.com/gpu 鍵和值。
• resourceName、resourceMem、resourceMemPercentage、resourceCores、resourcePriority 等：分別用于設置申請 vgpu 個數(shù)、顯存大小、顯存比例、算力、任務優(yōu)先級的資源名，均有默認值。

此外，容器中也有對應配置，如 GPU_CORE_UTILIZATION_POLICY（字符串類型，“default”、“force”、“disable” 分別代表不同的容器算力限制策略）和 ACTIVE_OOM_KILLER（字符串類型，“true” 或 “false” 表示容器是否會因超用顯存而被終止執(zhí)行）。

五、HAMi 的驗證：確保資源管理的有效性

（一）查看 Node GPU 資源

在部署 HAMi 后，雖然環(huán)境中可能只有一個物理 GPU，但 HAMi 默認會對其進行擴容。例如，通過執(zhí)行 kubectl get node xxx -oyaml|grep capacity -A 7 命令，我們可以查看 Node 的資源信息，理論上能看到 nvidia.com/gpu 的數(shù)量有所增加（默認擴容 10 倍），這表明 HAMi 已經(jīng)成功對 GPU 資源進行了虛擬切分。

（二）驗證顯存和算力限制

使用以下 YAML 文件創(chuàng)建一個 Pod 來驗證顯存和算力限制：

apiVersion: v1
kind: Pod
metadata:name: gpu-pod
spec:containers:- name: ubuntu-containerimage: ubuntu:18.04command: ["bash", "-c", "sleep 86400"]resources:limits:nvidia.com/gpu: 1nvidia.com/gpumem: 3000nvidia.com/gpucores: 30

創(chuàng)建完成后，通過 kubectl exec -it gpu-pod -- bash 進入 Pod，執(zhí)行 nvidia-smi 命令。從輸出結果中，我們可以看到 GPU 的內(nèi)存使用情況和算力使用情況是否符合我們在 Pod 資源請求中設定的限制。例如，在上述示例中，我們期望看到 GPU 內(nèi)存使用量不超過 3000MiB，算力使用不超過 30%。同時，注意到命令執(zhí)行后的日志中會有 HAMi 的 CUDA 驅(qū)動打印信息，如 [HAMI-core Msg(16:139711087368000:multiprocess_memory_limit.c:434)]: Calling exit handler 16，這也進一步證明了 HAMi 在資源管理方面的作用。

通過以上對 HAMi 方案的全面介紹，我們可以看到它在 k8s 環(huán)境下 GPU 資源管理方面具有顯著的優(yōu)勢和實用性。無論是解決資源利用率不高的問題，還是實現(xiàn)細粒度的資源隔離與限制，HAMi 都為我們提供了一種可行的解決方案。希望這篇博客能夠幫助大家更好地理解和應用 HAMi，在實際工作中充分發(fā)揮 GPU 資源的潛力，提升計算任務的執(zhí)行效率。