HAMi GPU虚拟化实践：EKS环境下显存隔离与算力共享部署指南

AI/ML工作负载的GPU资源困境

当前AI/ML应用实践中，两股截然不同的技术趋势正在并行演进，对GPU资源管理提出了差异化的挑战。

传统小模型推理与部署场景依然活跃——推荐系统、实时预测、路径优化等业务对GPU单卡资源的共享与隔离需求日益精细化。一张T4或A10 GPU往往需要同时承载多个独立的推理服务，如何在保证显存隔离的前提下实现算力共享，成为提升资源利用率的关键。

与此同时，以大语言模型为代表的大模型部署正在快速兴起。这类工作负载对GPU多卡资源的算力弹性要求越来越高，单个推理任务可能需要跨越4张甚至8张GPU卡协同工作，对底层虚拟化与调度机制提出了全新挑战。

正是基于这两类场景的实际需求，GPU虚拟化解决方案的选型与落地成为云原生AI平台建设的核心议题。

项目需求与技术目标

项目的核心目标是基于Kubernetes构建统一的GPU资源申请与管理平台。应用端只需提交标准化的GPU资源需求（包括GPU数量与显存大小），平台即可根据需求自动完成资源分配，实现GPU算力共享与显存严格隔离，从而提升GPU集群的整体利用效率。

小模型部署场景

• 资源需求：典型模型规模对显存需求约4-5GB，T4/A10机型单卡即可满足算力需求，每个模型独立部署为一个Pod
• 隔离需求：单卡并行多个模型时，需保证显存隔离以避免OOM或性能抖动；同时支持算力共享，避免GPU算力空闲浪费

大模型（LLM）部署场景

• 资源隔离需求：支持多卡部署以及固定显存配额分配，确保大模型运行过程中的资源稳定可控
• 弹性扩展需求：能够根据模型规模灵活申请2卡、4卡或更多GPU资源

NVIDIA原生GPU虚拟化方案的局限性分析

在评估开源方案之前，有必要深入理解NVIDIA提供的三种主流虚拟化方案及其在生产环境中的实际局限。

MIG（Multi-Instance GPU）

MIG是NVIDIA针对A100、H100等新一代GPU提供的软硬件一体化隔离技术。硬件层面，可以将SM、L2 Cache、内存控制器与IO通道切割成多个独立MIG单元，每个单元作为独立的GPU实例对外暴露；软件层面，通过nvidia driver中的MIG driver实现对隔离硬件的调用。

该方案在多租户场景下能够保证显存和算力的强隔离，但存在明显的硬件限制——仅支持A100/H100等高端GPU，对企业广泛使用的T4、A10机型完全不适用。这一限制在成本敏感的生产环境中尤为突出。

MPS（Multi-Process Service）

MPS的核心是在CUDA Runtime和CUDA Driver之上引入服务层，将多个进程的CUDA内核请求合并后下发给GPU，使多个CUDA进程能够共享GPU的SM资源，避免CUDA Context频繁上下文切换，从而提升GPU利用率。

然而，MPS在显存分配层面存在根本性缺陷：每个进程仍然直接向CUDA Driver独立申请显存，不会被MPS统一调度。所有进程共享同一显存地址空间，任何进程OOM都可能导致整个GPU崩溃，无法满足生产环境对显存隔离的刚性需求。

Time Slicing（时间片调度）

Time Slicing是最基础的GPU资源复用方式，通过时间片轮转在多个应用之间共享GPU，每个应用在分配的时间片内独占GPU资源。

该方案仅能作为”最低成本的GPU复用手段”，适合对延迟不敏感的批处理任务。但Time Slicing既不能在小模型场景提供显存隔离，也不能在大模型场景实现跨卡部署，无法满足精细化资源管理的需求。

HAMi方案原理深度解析

HAMi（Heterogeneous AI Computing Virtualization Middleware）是一个开源的异构计算虚拟化中间件，专为Kubernetes环境设计。根据官方文档的设备支持说明，HAMi能够为NVIDIA GPU提供内存隔离、核心隔离和多卡支持能力。

对于需要在多云环境中部署AI工作负载的团队，选择合适的多云账单代付解决方案可以有效降低跨区域GPU资源采购的复杂度。

Pod调度阶段的工作机制

在Kubernetes集群中，HAMi扩展了Pod的调度与运行流程，整个过程可分为以下几个关键阶段：

1. Pod提交与MutatingWebhook拦截

当Pod提交到集群时，HAMi的MutatingWebhook会自动完成以下操作：

• 设置schedulerName=hami-scheduler
• 注入runtimeClassName=nvidia
• 为容器补齐必要的GPU资源字段和环境变量
• 通过环境变量和容器启动参数注入LD_PRELOAD，为后续CUDA API劫持预埋钩子

2. HAMi Scheduler调度决策

Pod被送入HAMi Scheduler后，经历三个核心阶段：

• Filter阶段：解析Pod的资源需求，筛选出满足显存、算力等要求的候选节点
• Score阶段：对候选节点进行多维度打分，包括资源利用率、碎片化程度、拓扑结构等
• Bind阶段：选择最优节点，将Pod绑定到该节点

3. HAMi Device Plugin与环境变量注入

当Pod被分配到节点后，HAMi Device Plugin接管容器与GPU的连接过程。与NVIDIA官方插件相比，HAMi Device Plugin新增了以下能力：

• 为容器注入显存、算力、任务优先级等控制参数
• 挂载HAMi Core库，实现GPU虚拟化控制
• 精细化配置CUDA_MEM_LIMIT、CUDA_CORE_LIMIT等环境变量

Pod持续运行阶段的资源管控

Pod启动后，HAMi Core通过Linux的LD_PRELOAD机制直接嵌入到应用进程中。LD_PRELOAD允许在运行时指定自定义动态链接库，使其在系统标准库之前被加载，从而实现函数劫持。

关键工作流程如下：

1. 拦截调用：当应用尝试调用cudaMalloc申请显存时，请求首先进入HAMi Core的拦截逻辑
2. 资源校验：HAMi Core读取Pod下发的GPU配置（如显存上限），检查本次申请是否超限
3. 严格控制：若超出限制则直接拒绝分配并返回错误码；若合法则放行并记录分配情况
4. 持续监管：所有显存分配和释放都经过拦截校验，形成完整的Pod级资源沙盒

与NVIDIA MPS仅能在GPU核心算力维度做时间片调度不同，HAMi Core能够在显存维度上实现细粒度隔离。即便某个应用因显存泄漏或异常崩溃，也不会拖垮同节点的其他应用。

基于EKS的HAMi部署实践

HAMi组件安装步骤

参考官方安装文档进行HAMi的安装部署。

标记GPU节点

通过添加标签gpu=on来标记需要管理的GPU节点，以便HAMi调度。没有此标签的GPU节点将无法被HAMi进行调度管理：

kubectl label nodes {nodeid} gpu=on

也可以在创建GPU节点组时直接打上该标签。

安装HAMi组件

在helm中添加仓库：

helm repo add hami-charts https://project-hami.github.io/HAMi/

使用以下命令进行部署：

helm upgrade -i hami hami-charts/hami -f my-values.yaml -n kube-system

在my-values.yaml中配置hami-scheduler-device ConfigMap，具体配置参数说明请参见配置文档。

验证安装状态

安装完成后检查HAMi组件运行状态：

kubectl get pods -n kube-system | grep hami
kube-system hami-device-plugin-64gb4 2/2 Running 0 18s
kube-system hami-device-plugin-rrwcb 2/2 Running 0 18s
kube-system hami-scheduler-5c4d5f76f5-j27w6 2/2 Running 0 18s

重要注意事项：Device Plugin冲突处理

如果使用eksctl方式创建集群，EKS在检测到GPU机型时会自动安装NVIDIA Device Plugin，这时会同时存在hami-device-plugin和nvidia-device-plugin。这两个plugin只能保留一个，因为hami-device-plugin是对nvidia-device-plugin的扩展。根据官方FAQ说明，HAMi Device Plugin和NVIDIA Official Device Plugin不应共存以避免资源冲突。

实际场景部署验证

场景一：小模型部署（显存隔离+算力共享）

多个推理任务需要在同一张GPU上运行，要求显存严格隔离但共享GPU算力。

场景二：大模型部署（多卡扩展+显存隔离）

单个任务需要占用多个物理GPU，同时能够进行显存隔离。

针对场景二，一个关键问题是：对于具有4个物理GPU卡的机型，当deviceSplitCount=2时会虚拟出8张vGPU。这时如果申请GPU资源nvidia.com/gpu: 2，实际资源分配会如何？是分配到一张物理GPU卡的两个vGPU，还是落在两张物理卡上？

根据HAMi官方FAQ的解释：

vGPU represents different task views of the same physical GPU. It is not a separate partition of physical resources. When a task requests nvidia.com/gpu: 2, it is interpreted as requiring two physical GPUs, not two vGPUs from the same GPU.

vGPU并不代表对物理GPU的分割，而是从任务视角定义一个GPU上可以运行几个任务。因此申请nvidia.com/gpu: 2会实际分配两张物理GPU卡，这正是大模型部署所需要的行为。

场景二资源分配验证

测试环境：g4dn.12xlarge，4× T4 GPU（16GB/GPU，总64GB）

模拟任务，启动两个task，每个申请4 vGPU + 4GB显存。

观察HAMi组件日志，可以看到4个物理GPU的对应ID、可提供的vGPU数量和显存数量等信息。

观察每个Pod的GPU分配情况，输出结果验证每个Pod都分配了4张物理GPU卡：

=== Pod 1 GPU分配 ===
GPU-32bd4a3b-xxxx-b734-938af0bb5125,NVIDIA,4000,0
GPU-exxxxxxx-9f8c-af12-5dc0-6f1e851eca21,NVIDIA,4000,0
GPU-12041b93-e3ec-d354-b8e2-7f4dc39c8fe7,NVIDIA,4000,0
GPU-d1bc9932-e9bd-206a-aecc-63c2eb4dacd1,NVIDIA,4000,0

=== Pod 2 GPU分配 ===
GPU-32bd4a3b-xxxx-b734-938af0bb5125,NVIDIA,4000,0
GPU-exxxxxxx-9f8c-af12-5dc0-6f1e851eca21,NVIDIA,4000,0
GPU-12041b93-e3ec-d354-b8e2-7f4dc39c8fe7,NVIDIA,4000,0
GPU-d1bc9932-e9bd-206a-aecc-63c2eb4dacd1,NVIDIA,4000,0

进入Pod后查看GPU资源占用情况，验证每GPU上申请到4GB显存。

典型场景下的性能测试验证

在功能验证通过后，需要进一步评估HAMi在多任务并行场景下对GPU资源管理过程中的性能损耗。

测试环境与场景设计

测试环境：g4dn.xlarge，1× T4 GPU（16GB/GPU），启用HAMi GPU资源管理

• 场景一：15GB显存分配给一个Pod
• 场景二：7GB显存分配给一个Pod
• 场景三：同时运行两个Pod，每个Pod分别分配7GB显存，计算资源共享

使用GPU压力测试脚本，通过执行大规模矩阵乘法运算（8192×8192，torch.float32）持续负载GPU，测量计算吞吐量，目标运行时间300秒。

测试结果

测试结果分析

该测试为算力密集型场景，实际内存需求不超过1GB：

• 从场景1、2的对比可以看出，资源分配实现了显存隔离，但算力是可以共享的
• 从场景3可以看出两个Pod对算力的使用是抢占式的，且基本均分
• 多个Pod并发执行时存在算力损耗，约18%左右

生产环境落地建议

基于实际部署经验，在生产环境落地HAMi时需要关注以下几个方面：

容量规划考量

• 根据18%的并发算力损耗，在容量规划时需要预留相应的性能余量
• 对于延迟敏感型推理服务，建议在负载测试中验证P99延迟是否满足SLA要求
• 合理设置deviceSplitCount参数，避免过度切分导致调度复杂度上升

监控与告警配置

• 配置GPU显存使用率、算力利用率的监控指标
• 设置HAMi组件健康检查告警，确保调度器和Device Plugin的高可用
• 监控Pod级别的GPU资源分配情况，及时发现资源碎片化问题

升级与维护策略

• HAMi版本升级时需要注意与Kubernetes版本、NVIDIA驱动版本的兼容性
• 建议在非生产环境充分验证后再进行生产环境升级
• 保留回滚方案，确保升级失败时能够快速恢复

方案价值与适用场景

HAMi在Kubernetes上实现了显存与算力的精细隔离与共享，能够满足小模型和大模型部署的细粒度隔离需求。实测显示，多个Pod并发使用HAMi时算力虽有下降，但整体GPU利用效率显著提升——这是一种在可控开销下提升资源利用率的实用折中方案。

对于无法使用MIG硬件特性的T4、A10等主流GPU机型，HAMi提供了一条可行的虚拟化路径，使得企业能够在现有硬件基础上实现更精细的GPU资源管理。