技术分享

个人总结

🎯 2024年终总结

💯 CKA ✅

✨ Star原则

🧿 【转】如何阅读源码

♦️在k8s环境中使用vgpu | HAMI

type

status

date

slug

summary

如何使用GPU？

省流版本：

对于裸机环境，只需要安装对应的 GPU Driver 以及 CUDA Toolkit 。

对应 Docker 环境，需要额外安装 nvidia-container-toolkit 并配置 docker 使用 nvidia runtime。

对应 k8s 环境，需要额外安装对应的 device-plugin 使得 kubelet 能够感知到节点上的 GPU 设备，以便 k8s 能够进行 GPU 管理。

一大堆必要的概念

如何理解CUDA？

是什么：Compute Unified Device Architecture 是NVIDIA 推出的一种并行计算和平台和编程的模型。简单理解，ta是一套软件（API、驱动程序、工具包）和硬件（Nvida GPU）集成的技术。

为什么需要CUDA ：CUDA的核心目标能够让开发者用类似C++的编程语言直接调用GPU核心进行并行计算，将 GPU 从一个图形加速器，转变为一个通用的并行计算平台，彻底改变了高性能计算和人工智能领域。

CUDA 主要包含三个核心部分：

CUDA 硬件架构：这是 NVIDIA GPU 的物理设计。每个 GPU 都包含大量的流式多处理器（SM），每个 SM 中又包含成百上千个 CUDA 核心，这些核心就是并行计算的执行单元。
CUDA 编程模型：这是为开发者设计的并行编程抽象。它将大量的并行任务组织成网格（Grid）和线程块（Block）的层次结构，让开发者可以轻松地将任务分配到 GPU 的不同核心上。
CUDA API 和库：这是一系列软件工具，包括编译器（nvcc）、驱动程序、以及各种高度优化的库（如用于深度学习的 cuDNN、用于线性代数的 cuBLAS）。这些工具和库极大地简化了 GPU 编程，让开发者可以直接调用现成的函数，而无需从头编写并行代码

Golang vs. CUDA 对比分析

组件	Go 语言软件生态 (CPU)	GPU 软件生态 (CUDA)
底层硬件	CPU 处理器：擅长串行和通用任务处理。	NVIDIA GPU 处理器：擅长并行和大规模数据计算。
系统核心	操作系统内核：负责硬件资源管理、内存分配和进程调度。Go Runtime 依赖并运行在操作系统内核之上。	GPU Driver (驱动程序)：直接与 GPU 硬件通信，提供底层的硬件抽象和 API。CUDA Runtime 依赖并运行在驱动程序之上。
编译工具	go 编译器：将 Go 源码编译成 CPU 可执行的机器码。	nvcc 编译器：将 CUDA C/C++ 代码编译成 GPU 可执行的指令集。
标准库/框架	Go 标准库：提供基础的编程功能，如网络、文件 I/O、并发原语等。	CUDA 库：提供高度优化的并行计算算法，例如 cuBLAS (线性代数) 和 cuDNN (深度学习)。
开发环境	Go SDK：一个完整的开发套件，包含编译器、标准库、格式化工具和依赖管理工具。	CUDA Toolkit：一个完整的 GPU 开发套件，包含 nvcc、各种库、调试器和性能分析工具。

裸机环境使用GPU

裸机中使用GPU 需要安装这两个组件

GPU Driver

CUDA Toolkit

GPU Driver包括了 GPU驱动和CUDA驱动，CUDA ToolKit包含了 CUDA Runtime

GPU 作为一个 PCIE 设备，只要安装好之后，在系统中就可以通过 lspci 命令查看到，先确认机器上是否有 GPU：

安装NVIDIA驱动

https://www.nvidia.cn/drivers/lookup/

可以通过nvidia-smi 命令查看显卡是否安装好了

安装CUDA ToolKit

对于深度学习程序，一般都要依赖 CUDA 环境，因此需要在机器上安装 CUDA Toolkit

https://developer.nvidia.com/cuda-toolkit-archive

可以使用以下py代码检测CUDA环境

Docker环境中使用GPU

环境准备流程

为了让 Docker 容器中也能使用 GPU，大致步骤如下：

0) 宿主机安装NVIDIA 驱动

1）安装 nvidia-container-toolkit 组件

2）修改docker的 runtime为 nvidia-runtime

3）启动容器时增加 -gpu 参数

Nvidia-container-toolkit 的作用

这个ToolKit是让容器与宿主机上的NVDIA Driver进行通讯的关键工具，它有包含 nvidia-container-runtime的运行时，它将必要的 NVIDIA 驱动库和设备文件映射到容器内部，这样容器内的应用程序才能看到并使用 GPU。

-gpu 参数可选值：

-gpus all：表示将所有 GPU 都分配给该容器

-gpus "device=<id>[,<id>...]"：对于多 GPU 场景，可以通过 id 指定分配给容器的 GPU，例如 –gpu “device=0” 表示只分配 0 号 GPU 给该容器

调用链从 containerd –> runC 变成 containerd –> nvidia-container-runtime –> runC 。

nvidia-container-runtime 在中间拦截了容器 spec，就可以把 gpu 相关配置添加进去，所以runC 的 spec 里面就包含 gpu 信息了。

k8s环境使用GPU

Manual install

在 k8s 环境中使用 GPU，需要在集群中部署以下组件：

gpu-device-plugin 用于管理 GPU，device-plugin以 DaemonSet 方式运行到集群各个节点，以感知节点上的 GPU 设备，从而让 k8s 能够对节点上的 GPU 设备进行管理。

gpu-exporter：用于监控 GPU

运行一个有gpu需求的pod

大致工作流程如下：

每个节点的 kubelet 组件维护该节点的 GPU 设备状态（哪些已用，哪些未用）并定时报告给调度器，调度器知道每一个节点有多少张 GPU 卡可用。

调度器为 pod 选择节点时，从符合条件的节点中选择一个节点。

当 pod 调度到节点上后，kubelet 组件为 pod 分配 GPU 设备 ID，并将这些 ID 作为参数传递给 NVIDIA Device Plugin

NVIDIA Device Plugin 将分配给该 pod 的容器的 GPU 设备 ID 写入到容器的环境变量 NVIDIA_VISIBLE_DEVICES中，然后将信息返回给 kubelet。

kubelet 启动容器。

NVIDIA Container Toolkit 检测容器的 spec 中存在环境变量 NVIDIA_VISIBLE_DEVICES，然后根据环境变量的值将 GPU 设备挂载到容器中。

在 Docker 环境我们在启动容器时通过 --gpu 参数手动指定分配给容器的 GPU，k8s 环境则由 device-plugin 自行管理。

使用 GPU-Operator自动安装

如果集群节点很多，一个个手动安装很麻烦，不同节点之间容易造成NVIDIA驱动不一致导致容器运行失败问题。GPU Operator 可以自动化完成 GPU Driver、NVIDIA Container Toolkit、device-plugin、exporter 等组件的部署，快速实现在 k8s 环境中使用 GPU。

https://github.com/NVIDIA/gpu-operator

小结

对于裸机环境，只需要安装对应的 GPU Driver 即可。

对应 Docker 环境，需要额外安装 nvidia-container-toolkit 并配置 docker 使用 nvidia runtime。

对应 k8s 环境，需要额外安装对应的 device-plugin 使得 kubelet 能够感知到节点上的 GPU 设备，以便 k8s 能够进行 GPU 管理。

Device Plugin

为什么需要device plugin？

k8s的原生调度器天生就能“看到”并理解通用资源，比如CPU和内存信息，这些信息是k8s通过kubelet直接获取的，并将其作为决策的基础。

对于常规资源

Kubelet 会从节点本地的操作系统中收集资源使用情况：

CPU：读取 /proc/stat 文件，或者通过系统调用获取 CPU 核心数量、使用率等信息。
内存：读取 /proc/meminfo 文件，获取内存的总量和可用量。
存储：通过文件系统 API 获取磁盘容量和使用情况。
网络：读取网络接口统计信息。

容器层的资源监控：

对于运行中的 Pod，Kubelet 会通过容器运行时接口（CRI）和 cgroup（控制组）收集容器的 CPU 和内存资源使用情况。
它会将这些资源限制、使用信息与 Pod/容器绑定，定期上报给 API Server。

上报到 API Server：

Kubelet 将节点的资源总量（如 CPU 总核数、内存总大小）和使用情况通过心跳（NodeStatus）上报给 Kubernetes 的 API Server。
API Server 将这些信息存储在 Node 对象的 status.capacity 和 status.allocatable 字段中。

对于非常规资源

但是对于非常规资源，比如GPU、NPU、DCU甚至是FPGA等非常规资源，调度器无法感知某个node上的xx资源的可分配、可调度信息，也就是对他来说是不可见的。

Device Plugin正是为了解决这个挑战而诞生的。它作为一种扩展机制，将操作系统层面的硬件设备，桥接到Kubernetes 调度器和容器运行时之间，使其成为可被集群统一管理的资源。

Device Plugin 仅负责非标准资源的上报，例如：

GPU（nvidia.com/gpu）

FPGA（xilinx.com/fpga）

TPU（google.com/tpu）

自定义设备（example.com/custom-device）

Device plugin实现了什么？

Device Plugin 的工作原理其实不复杂，可以分为 插件注册 和 kubelet 调用插件两部分：

插件注册：Device Plugin 启动时会向节点上的 Kubelet 发起注册，这样 Kubelet 就可以感知到该插件的存在了

kubelet 调用插件：注册完成后，当有 Pod 申请对于资源时，kubelet 就会调用该插件 API 实现具体资源分配

非常规资源的整体调度使用流程（以GPU举例）

调度流程

pod指定资源的gpu卡

scheduler进行调度，选择一个最优的节点，调用devide_plugin 的allocate方法，分配一个卡给pod，将卡的信息写入pod的环境变量中

containerd启动容器，由于配置了 nvidia-container-runtime，所以会调用nvidia-container-shim来为这个pod增加一个hook

runc执行时，首先执行prestart-hook，其中就会包含nvidia-container-hook

从容器 Spec 的 mounts 或者 env 中解析 GPU 信息
调用 nvidia-container-cli 命令，将 NVIDIA 的 GPU Driver、CUDA Driver 等库文件挂载进容器，保证容器内可以使用被指定的 GPU以及对应能力

核心就是两个部分

device plugin 根据 GPU 资源申请为容器添加 NVIDIA_VISIBLE_DEVICES环境变量

nvidia-container-toolkit 则是根据 NVIDIA_VISIBLE_DEVICES环境变量将 GPU、驱动等相关文件挂载到容器里。

云原生时代GPU共享的主流实现方式

Time-slicing

NVIDIA GPU Time-Slicing 的核心是一种“资源虚拟化”技巧。NVIDIA Device Plugin 读取配置后，会向 Kubernetes “谎报”资源，将一块物理 GPU 虚拟成多份（例如 4 份），并为每一份生成一个唯一的虚拟 ID。当 Pod 请求 GPU 时，Kubernetes 的调度器会愉快地将它分配到这些看似独立的虚拟 GPU 上。最后，在容器启动前，Device Plugin 会将这个虚拟 GPU 的请求“翻译”回它所对应的原始物理 GPU，通过设置 NVIDIA_VISIBLE_DEVICES 环境变量，让所有 Pod 最终都共享同一块物理 GPU。

暂时无法在飞书文档外展示此内容

如何理解Time-Slicing

Time-Slicing 的本质不是由 Device Plugin 来“切分时间”，而是“允许多个进程同时访问”。

Device Plugin 的角色: 扮演一个“资源欺骗”和“请求翻译”的角色。它欺骗 K8s，让一个物理 GPU 看起来像多个，然后在分配时将对虚拟 GPU 的请求翻译回对那个物理 GPU 的访问授权。

真正处理并发的角色: 当多个 Pod 里的程序都向同一块物理 GPU 提交计算任务时，真正的并发处理、上下文切换和任务调度是由 NVIDIA 的 CUDA 驱动和 GPU 硬件本身来完成的。这和在单台物理机上同时运行多个 CUDA 程序是完全一样的。

优缺点

优点 (Advantages)	缺点 (Disadvantages)
极高的资源利用率允许多个负载不高的任务共享 GPU，避免了“一个任务占用整卡”造成的巨大浪费。	完全没有隔离性所有任务共享计算、显存和带宽资源，没有任何硬件或软件层面的隔离。
灵活性和高兼容性无需特殊硬件，几乎支持所有 NVIDIA GPU，包括不支持 MIG 的旧型号和消费级显卡。	性能无法保障 (无 QoS) “吵闹的邻居”问题严重，一个高负载任务会抢占资源，导致其他任务性能急剧下降、延迟飙升。
支持高密度用户相比 MIG 最多 7 个实例的硬性限制，Time-Slicing 理论上可以支持非常多的用户或任务共享。	存在显存溢出风险 (OOM) 由于不隔离显存，一个“贪婪”的任务可能会耗尽全部显存，导致共享该卡的其他所有任务因内存不足（Out of Memory）而崩溃。
配置相对简单在 Kubernetes 等环境中，通常只需修改 Device Plugin 的一个配置文件即可启用，比配置 MIG 更直接。	存在故障传递风险一个任务的程序 Bug 导致 GPU 驱动崩溃，会影响到共享该卡的所有任务，无法做到故障隔离。
适合突发性负载非常适合负载呈阵发性、非持续性的任务，如开发、测试、轻量级推理等。	存在性能开销 GPU 在不同任务之间进行上下文切换（Context Switch）本身会消耗一定的计算资源，带来性能开销。

MPS

MPS（Multi-Process Service，多进程服务）是 NVIDIA 提供的一种 GPU 共享技术，它是一种替代性的 CUDA API 实现。

要理解 MPS，首先要知道在默认情况下，GPU 如何处理多进程任务：

默认模式（时间分片）：当多个进程向 GPU 提交任务时，GPU 硬件一次只能处理一个进程的上下文（Context）。它会执行进程 A 的任务，然后进行一次昂贵的上下文切换（保存 A 的状态，加载 B 的状态），再执行进程 B 的任务。这就像一个单核 CPU 在多个程序间快速切换，无法真正实现并行。

MPS 通过引入一个“服务端-客户端”架构改变了这一模式：

MPS 服务端 (Server)：当第一个 CUDA 程序启动时，一个 MPS 服务端进程会被启动。这个服务端会在 GPU 上创建一个单一的、可共享的 GPU 上下文。

MPS 客户端 (Clients)：之后，所有其他的 CUDA 进程（客户端）启动时，它们不再创建自己的 GPU 上下文，而是直接连接到这个已存在的 MPS 服务端。

并发执行：所有客户端都通过 MPS 服务端，将自己的计算任务（Kernel）提交到那个共享的上下文中。因为所有任务现在都位于同一个上下文里，GPU 的硬件调度器就可以将来自不同进程的多个计算任务同时调度到不同的计算单元（SM）上执行，实现了真正的硬件并发

MPS VS Time-Slicing

特性	MPS (Multi-Process Service)	Time-Slicing (时间切片)
核心原理	共享 CUDA 上下文 (Context) 允许多个进程的计算任务在硬件上并发执行，消除上下文切换开销。	分时复用 (Time-Division Multiplexing) GPU 在极短的时间内快速地在不同进程间轮流切换，每个进程在自己的时间片内独占 GPU。
隔离性	弱隔离进程间有一定隔离，但共享同一个上下文，一个进程的严重错误可能影响其他进程。显存不隔离。	完全无隔离所有进程完全共享计算、显存和带宽。一个进程的错误或高负载会直接影响所有其他进程。
性能特点	高吞吐量、低延迟适合计算密集型任务，通过并行执行提升总体效率。	性能抖动、有开销上下文切换本身有性能开销，且当多个重负载任务共享时，每个任务的性能都会下降且不稳定。
资源管理	由 CUDA 驱动和 MPS 服务端管理在更底层的 CUDA API 层面实现共享。	由上层调度器（如 K8s Device Plugin）管理在软件层面“虚拟化”GPU 数量，欺骗调度器。
适用场景	高性能计算 (HPC)、MPI 作业、小批量推理多个协作进程或负载不饱和的任务需要同时运行以提升整体效率。	开发测试、轻量级或突发性负载大量负载不高的任务需要共享 GPU，追求极致的资源利用率，且对性能抖动不敏感。

MIG

NVIDIA 的 GPU的分类

分类	主要市场	核心优势	代表型号
GeForce	游戏、个人创作	极致游戏性能、性价比	RTX 4090, RTX 4070
NVIDIA RTX (Quadro)	专业设计、科学可视化	驱动稳定、高精度、大显存	RTX 6000 Ada
数据中心 / AI	AI 训练/推理、HPC	顶级算力、MIG、高速互联	H100, A100, B200
Jetson / DRIVE	机器人、自动驾驶	低功耗、嵌入式 AI 计算	Jetson Orin, DRIVE Thor

MIG是什么

Multi-Instance GPU (MIG) expands the performance and value of NVIDIA Blackwell and Hopper™ generation GPUs. MIG can partition the GPU into as many as seven instances, each fully isolated with its own high-bandwidth memory, cache, and compute cores. This gives administrators the ability to support every workload, from the smallest to the largest, with guaranteed quality of service (QoS) and extending the reach of accelerated computing resources to every user.

通过硬件级的完全隔离来实现有保障的服务质量 (QoS)

每个实例都拥有自己专属的高带宽内存、缓存和计算核心。这是一种物理层面的硬隔离，而非软件模拟

https://www.nvidia.com/en-us/technologies/multi-instance-gpu/

支持 MIG 的 GPU 型号

支持 MIG 的是 NVIDIA 高端数据中心级 GPU。消费级的 GeForce 游戏显卡不支持。

主要包括以下系列中的旗舰计算卡：

Blackwell 架构: NVIDIA B200, GB200

Hopper 架构: NVIDIA H100, H200

Ampere 架构: NVIDIA A100, A30

复杂案例分析：在单张 A100 80GB GPU 上支持混合 AI 工作负载

场景描述

一家中型科技公司拥有一台搭载了单张 NVIDIA A100 80GB GPU 的高性能服务器。这台服务器需要同时满足三个不同团队的需求，他们的工作负载特性和性能要求截然不同：

AI 训练团队 (Training Team):

任务: 运行周期较长的深度学习模型训练任务，需要较大的显存来容纳大模型和大的 Batch Size。
需求: 需要一块算力强劲、显存充裕的计算资源，可以容忍一定的任务排队时间，但一旦开始运行，不希望被其他任务干扰。

推理服务团队 (Inference Team):

任务: 部署两个已经训练好的 AI 模型（一个 NLP 模型，一个图像识别模型），对外提供低延迟的在线推理服务。
需求: 服务质量 (QoS) 是最高优先级。要求每个模型的响应延迟必须稳定且可预测，绝对不能因为其他高负载任务（如模型训练）而出现延迟抖动。

数据科学与研发团队 (R&D Team):

任务: 进行探索性数据分析 (EDA)、模型调试和算法原型验证，主要使用 Jupyter Notebooks。
需求: 需要一个交互式的、响应迅速的开发环境。他们的资源使用是突发性的，不需要一直占用，但需要时必须能立即获得一个算力适中的环境。

面临的挑战

如果不使用 MIG，直接让所有团队共享这块 A100，会产生一系列严重问题：

性能干扰：训练团队的重负载任务会严重抢占计算和显存带宽资源，导致推理服务的延迟急剧上升，无法满足 QoS 要求。

资源冲突：多个团队可能同时需要大量显存，导致 Out of Memory 错误。

无法隔离：一个研发人员在 Jupyter 中写的有 bug 的代码可能导致整个 GPU 驱动崩溃，中断所有人的工作，包括生产环境的推理服务。

MIG 解决方案：分区策略

为了解决以上问题，IT 部门决定启用 MIG，并根据 A100 80GB 的资源特性（7个计算实例/CI，8个显存实例/GI，每个10GB）设计如下分区策略：(CI 是compute instance GI是 GPU instance)

分配给	MIG 配置文件	资源分配	用途说明
训练团队	3g.40gb	3 个 CI (约43%算力)4 个 GI (40GB显存)	分配一个大实例，用于运行需要大显存和强算力的长周期训练任务。
推理团队 (模型 A)	1g.10gb	1 个 CI (约14%算力)1 个 GI (10GB显存)	为 NLP 推理模型分配一个完全隔离的小实例，保证低延迟。
推理团队 (模型 B)	1g.10gb	1 个 CI (约14%算力)1 个 GI (10GB显存)	为图像识别模型分配另一个隔离的小实例，确保服务稳定。
研发团队	2g.20gb	2 个 CI (约29%算力)2 个 GI (20GB显存)	分配一个中等大小的实例，为数据科学家提供一个强大的交互式环境。

资源盘点:

计算实例 (CI): 3 + 1 + 1 + 2 = 7 (全部用完)

显存实例 (GI): 4 + 1 + 1 + 2 = 8 (全部用完)

这个分区方案完美地利用了 A100 80GB 的全部硬件资源，并为每个团队量身定制了隔离的、大小合适的 GPU 实例。

实施命令行示例

IT 管理员通过以下 nvidia-smi 命令在服务器上实现该分区策略：

预期输出:

优势与成果

通过实施此 MIG 方案，该公司实现了：

100% 隔离：训练任务的满负荷运行，对推理服务的延迟零影响。研发人员的实验代码也不会影响到任何生产或训练任务。

QoS 保障：推理团队获得了两个性能稳定、可预测的专用 GPU 实例，能够向客户提供有 SLA 保障的服务。

资源最大化利用：一块昂贵的 A100 GPU 被充分利用，同时支持了四个独立的、性质迥异的工作负载，避免了资源闲置和争抢，实现了成本效益最大化。

提升敏捷性：不同团队可以并行工作，无需排队等待 GPU 资源，大大加快了从研发到部署的整个流程。

NVIDIA MIG 优缺点总结

优点 (Advantages)	缺点 (Disadvantages)
硬件级强隔离实例间资源完全独立，互不影响。	硬件要求苛刻且成本高昂仅限特定、昂贵的数据中心 GPU。
性能可预测，服务质量 (QoS) 有保障彻底解决“吵闹的邻居”问题。	配置僵化，缺乏灵活性只能从厂商预定义的 Profile 中选择，无法自定义实例大小。
高安全性为多租户环境提供可靠的数据和故障隔离。	禁用 NVLink 高速互联同一 GPU 上的实例之间无法通过 NVLink 通信，限制了性能。
提升小任务的资源利用率将大 GPU 切分给多个小任务，避免浪费。	管理和重配复杂更改 MIG 布局非动态，需要高权限且 GPU 须空闲。

HAMI (Heterogeneous AI Computing Virtualization Middleware)

异构AI计算虚拟化中间件（HAMi），前称为k8s-vGPU-scheduler，是一个设计用于管理k8s集群中异构AI计算设备的“全合一”图表。它可以提供在任务之间共享异构AI设备的能力。

使用HAMI有什么好处？

设备复用：每个任务可以只占用一部分显卡，多个任务可以共享一张显卡

可限制分配的显存大小：可以用显存值（例如 3000M）或者显存比例（例如 50%）来分配 GPU资源

指定设备型号：当前任务可以通过设置 annotation 的方式，来选择使用或者不使用某些具体型号的设备

设备指定 UUID：当前任务可以通过设置 annotation 的方式，来选择使用或者不使用指定的设备，比如："nvidia.com/use-gpuuuid" or "nvidia.com/nouse-gpuuuid"

无侵入：vGPU 调度器兼容 nvidia 官方插件的显卡分配方式，所以安装完毕后，你不需要修改原有的任务文件就可以使用 vGPU 的功能

调度策略：vGPU 调度器支持多种调度策略，包括节点、GPU 卡纬度的调度策略，可以通过调度器的参数来进行默认设置，同时也可以根据应用场景，通过设置 Pod 的 annotation 来选择，比如 "hami.io/node-scheduler-policy" 或 "hami.io/gpu-scheduler-policy"，两个纬度都支持 binpack 和 spread 两种策略。