HAMi-core 中 CUDA 劫持技术及 API 类型

要理解 HAMi-core 对 CUDA 相关 API 的 "劫持" 技术，需要先明确 CUDA-Runtime 与 CUDA-Driver 的层级关系，再拆解 "劫持" 的技术原理，最后区分 API 类型。以下是具体解释：

一、先明确基础：CUDA-Runtime 与 CUDA-Driver 的角色与调用关系

HAMi-core 劫持的是 CUDA-Runtime（libcudart.so ）和 CUDA-Driver（libcuda.so）之间的函数调用，这两个库是 NVIDIA CUDA 架构的核心组件，二者存在明确的 "上层调用底层" 关系：

组件	文件名	角色定位
CUDA-Driver（驱动层）	libcuda.so	底层核心库，直接与 GPU 硬件交互，提供最基础的 GPU 控制能力（如设备初始化、内存分配、算力调度），是 NVIDIA 闭源驱动的核心。
CUDA-Runtime（运行时）	libcudart.so	上层封装库，为开发者提供更易用的 API（如 `cudaMalloc`、`cudaMemcpy`），屏蔽了底层 Driver 的复杂细节。它本质是 "中间层"------ 开发者调用 Runtime API 时，Runtime 会间接调用 Driver API 完成实际硬件操作。

简单说：开发者代码 → CUDA-Runtime API（libcudart.so ） → CUDA-Driver API（libcuda.so） → GPU 硬件。

HAMi-core 要控制 GPU 资源（如限制某容器的显存 / 算力），就需要在 "Runtime 调用 Driver" 这个环节插入控制逻辑 ------ 这就是 "劫持" 的核心目标。

二、"劫持" 的技术原理：Linux 动态库劫持（LD_PRELOAD 机制）

HAMi-core 的 "劫持" 并非破坏或修改 NVIDIA 原生库（libcudart.so/libcuda.so，二者均为闭源），而是利用 Linux 系统的动态库加载优先级机制（LD_PRELOAD） 实现 "拦截调用"，具体流程如下：

1. 核心技术：LD_PRELOAD 环境变量的作用

在 Linux 中，LD_PRELOAD 是一个特殊的环境变量，它指定的动态库会优先于其他动态库被进程加载 。如果该库中实现了与后续加载的库（如 libcuda.so）同名的函数 ，进程会优先调用 LD_PRELOAD 库中的函数 ------ 这是 "劫持" 的技术基础。

HAMi-core 构建输出的 libvgpu.so，就是专门为 "劫持" 设计的动态库：它内部实现了 CUDA-Runtime 调用 CUDA-Driver 时用到的所有关键函数 （如 Driver 层的 cuMemAlloc、cuDeviceGet、cuLaunchKernel 等），且函数名与原生 libcuda.so 完全一致。

2. 劫持的完整流程（以 "显存分配" 为例）

假设某容器内的 CUDA 程序要调用 cudaMalloc（Runtime API）分配显存，正常流程是：

程序 → cudaMalloc（``libcudart.so``） → cuMemAlloc（``libcuda.so``） → GPU 分配显存

通过 HAMi-core 部署后（节点级 DaemonSet 会为所有 GPU 进程设置 LD_PRELOAD=``libvgpu.so），流程变为：

优先加载****libvgpu.so ：容器内的 CUDA 进程启动时，因 LD_PRELOAD 配置，先加载 HAMi-core 的 libvgpu.so。
拦截 Driver API 调用 ：程序调用 cudaMalloc（Runtime API），libcudart.so 会按原逻辑调用 Driver 层的 cuMemAlloc；但由于 libvgpu.so 已提前加载且实现了同名的 cuMemAlloc，进程会优先执行 libvgpu.so 中的 cuMemAlloc（而非原生 libcuda.so 的）。
插入资源控制逻辑 ：libvgpu.so 的 cuMemAlloc 会先执行 HAMi-core 的资源检查逻辑（如：当前容器的显存配额是否已用尽？是否超过算力限制？）。

若资源合规：libvgpu.so 会 "转发" 调用到 原生 libcuda.so 的 cuMemAlloc，让 GPU 完成实际的显存分配。
若资源超限：libvgpu.so 会直接返回错误（如 cudaErrorMemoryAllocation），阻止程序继续占用 GPU 资源。

返回结果：原生 Driver 的调用结果会通过 libvgpu.so 回传给 CUDA-Runtime，最终返回给应用程序。

3. 劫持的本质："透明拦截 + 逻辑插入"

这种劫持方式的核心优势是 无侵入性：

不需要修改 NVIDIA 原生的 libcudart.so 或 libcuda.so（闭源也无法修改）；
不需要修改用户的 CUDA 应用代码（开发者完全感知不到劫持存在）；
仅通过系统动态库加载机制，在 "Runtime → Driver" 的调用链中插入资源控制逻辑，实现 GPU 资源的精细化管控（如容器级的显存 / 算力隔离）。

三、劫持的 API 类型：不是 HTTP API，而是 "动态库函数级 API"

用户疑问的 "是否是 HTTP API"，答案明确：不是 HTTP API，二者本质完全不同。

1. 被劫持的 API 类型：CUDA Driver 导出的 "函数级 API"

HAMi-core 劫持的是 CUDA-Driver 库（libcuda.so）导出的 C 语言风格函数，属于 "本地进程内的函数调用接口"，特点是：

无网络交互：是同一进程内的动态库函数调用（地址空间内的代码执行）；
接口形式：以函数名 + 参数列表定义（如 cuMemAlloc(void** devPtr, size_t size)）；
用途：直接操作 GPU 硬件（如内存分配、核函数启动），是 CUDA 生态的底层核心接口。

常见的被劫持的 Driver API 包括：

设备管理：cuInit（初始化 Driver）、cuDeviceGet（获取 GPU 设备）；
内存管理：cuMemAlloc（分配显存）、cuMemFree（释放显存）、cuMemcpy（内存拷贝）；
算力调度：cuLaunchKernel（启动 CUDA 核函数）、cuStreamCreate（创建流）。

2. 与 HTTP API 的核心区别

对比维度	被劫持的 CUDA Driver API	HTTP API
通信方式	进程内动态库函数调用（无网络）	基于 HTTP 协议的网络通信（跨进程 / 跨机器）
接口形式	C 语言函数（如 `cuMemAlloc(...)`）	URL 路径 + 请求方法（如 `GET /api/gpu`）
底层依赖	Linux 动态链接器（ld.so）	TCP/IP 协议栈、HTTP 服务器 / 客户端
用途	本地 GPU 硬件操作	跨系统 / 跨服务的数据交互（如前后端通信）

四、总结

劫持技术本质 ：利用 Linux LD_PRELOAD 动态库优先级机制，通过 libvgpu.so 拦截 CUDA-Runtime 对 CUDA-Driver 的函数调用，插入 GPU 资源控制逻辑。
API 类型 ：劫持的是 CUDA-Driver（libcuda.so）导出的 函数级 API（本地进程内调用），而非基于网络的 HTTP API。
核心价值：在不修改原生库和应用代码的前提下，实现容器级 GPU 资源（显存、算力）的隔离与管控，这是 HAMi-core 作为 "容器内 GPU 资源控制器" 的关键技术底座。