8张国产GPU用HAMi承载30个开发环境的实践解析

8 张国产 GPU 装满 30 个开发环境这事听起来有点“挤”但电科云确实用 HAMi 做到了。最早我们团队拿到一批国产加速卡时第一反应也是头疼AI 开发环境每人都想要独立卡但物理卡就只有 8 张别说 30 人8 个人都不够分。HAMi 这个 GPU 虚拟化方案把整个资源盘活了让我意识到之前“一人一卡”的分配方式有多浪费。这篇文章就基于这次实践把 HAMi 承载 30 个开发环境的核心原理、资源分配思路和实操细节完整拆出来给正在折腾 GPU 虚拟化、开发环境交付的朋友做个参考。1. 为什么需要 HAMi先看 GPU 使用的真实困境1.1 一张卡只能给一个人用算力浪费的典型场景以前团队里的 GPU 使用方式非常粗放谁要训练模型就给他分一张卡其他人排队等着。但实际跑起来你会发现大部分开发场景根本不是“满负荷打满”的状态。比如一个数据科学家在调试 PyTorch 脚本他可能在写代码、看数据、调参真正让 GPU 跑起来的时间可能只占 20% 到 30%。模型推理服务在低峰期显存占用可能不到一半。我给团队做过一次峰值监控8 张卡同时段的平均利用率大约在 15% 到 25% 之间但显存碎片化却越来越多。这意味着物理 GPU 并没有真正“吃饱”只是被几个人“占着茅坑”。HAMi 解决的就是这个错配问题。它能把一张物理 GPU 按显存大小和算力比例切成多个虚拟设备分给不同开发环境使用。底层还是那张卡但上面同时跑着好几个人的任务互不干扰。听上去像“超卖”但它和超卖有本质区别——HAMi 做了隔离和调度不是你挤我我挤你地瞎抢。1.2 虚拟化切分的核心思路时间片、显存隔离、任务排队做 GPU 虚拟化业界通常有几种路径。第一种是纯时间片共享类似操作系统的 CPU 调度。多个人共用一张卡谁的任务来了就轮流算一段时间。优点是简单缺点是显存没有隔离一个人的显存爆了可能影响别人。第二种是显存硬隔离把物理显存划分成固定大小的块每个任务拿一块不能越界。这种隔离性好但算力可能还是共享的。第三种就是 HAMi 这种组合方案它通过 device plugin 上报虚拟 GPU 给 Kubernetes调度器负责把任务派到合适的物理卡上同时利用底层库实现显存隔离再配合 MPSMulti-Process Service或者类似的并发机制来切割算力。从资源分配角度看HAMi 的核心价值是“虚拟 GPU”这个抽象层。用户申请资源时看到的是一块 5GB 显存、50% 算力的虚拟 GPU而不是物理卡本身。管理员在后台定义好每种 vGPU 的规格用户按需申请平台按策略分配。这样既满足了多人共享又不会让一个人把整张卡独占太久。1.3 HAMi 在整个架构里的位置很多第一次接触 HAMi 的人会混淆它和 Kubernetes device plugin 的关系。实际上 HAMi 是基于 device plugin 机制做了扩展但它又在几个关键点上做得更多不只是“上报设备”而是支持把物理 GPU 切割成自定义大小的虚拟设备不只是“分配设备”而是在任务启动时注入必要的配置让容器里的 CUDA 程序感知到虚拟 GPU 的存在它还带一个调度器扩展组件能根据显存大小、算力比例、卡上已有任务数等因素决定把 vGPU 放到哪张物理卡上。所以 HAMi 的位置是在 Kubernetes 和 GPU 驱动之间的一层“中间件”。它向上承接用户的资源请求向下管理物理 GPU 的分片和隔离把原来“一张卡一个人独占”的粗粒度分配变成了“一张卡多人精细复用”的细粒度分配。2. 承载 30 个开发环境资源规划背后的一本账2.1 8 张卡怎么分给 30 个人先算显存与算力做资源规划第一步是搞清楚物理资源总量。我们手上的 8 张国产加速卡每张是 32GB 显存那么集群总显存就是 256GB。如果按传统方式30 个开发环境每个要一张卡显然不够。但开发环境并不是每个都需要整卡。我统计了一下团队实际需求大概的分布是这样的环境构建、代码编译、轻量模型调试这类任务对显存要求不高8GB 到 16GB 就够中小模型训练、微调实验可能需要 16GB 到 24GB大模型推理、全参微调才比较需要整卡的 32GB。按照这个比例我最初设计的三档规格是小规格 8GB 显存 30% 算力中规格 16GB 显存 60% 算力大规格 32GB 显存 100% 算力。理论上 8 张小卡可以切出 32 个 8GB 的 vGPU承载 30 个开发环境绰绰有余但如果有人申请大规格资源就要重新算。这里有一本很直观的账30 个环境如果全部用中规格 16GB需要 480GB 显存远超物理总量。所以必须保证大部分环境用小规格中规格和大规格按需分配。HAMi 允许不同规格的 vGPU 混合部署在同一张物理卡上比如一张 32GB 的卡可以切成 1 个 16GB 加 2 个 8GB这样资源利用率能比“统一规格”高不少。2.2 为什么开发场景特别适合 GPU 切分有人会问训练任务能切吗切了会不会变慢我的经验是开发和轻量训练场景非常适合全参大模型训练慎用。开发环境的典型特征是空闲等待时间长、偶发计算密集。比如工程师写代码的时候GPU 基本闲置跑一次单元测试或小批量验证时计算量又不是特别大。这样“间歇性突发”的负载和 GPU 切分的场景天然匹配。哪怕多个任务同时在跑只要不是同时打到峰值影响都相对可控。另外还需要考虑显存隔离的收益。没有隔离的时候一个开发环境里跑了个显存溢出的代码整张卡可能被 OOM 干翻别人也跟着遭殃。HAMi 做了显存隔离之后单个 vGPU 的显存使用超过限额会被拦截或报错但不会影响同一物理卡上的其他 vGPU。这一点对多租户的开发环境交付来说几乎是刚需。2.3 30 个环境需要的配置形态从 2GB 小卡到 20GB 大卡实际交付的时候30 个环境我们还分了更细的档位不完全是前面说的三档。有些场景比如环境初始化、依赖安装、CI 构建根本不需要 GPU 算力但用户希望环境里“有 GPU 可用”这种情况给一个 2GB 或 4GB 的小规格 vGPU 就够了。我们最终的规格表大概是这样的规格名称显存大小算力比例适用场景每卡可部署数量vgpu-small4GB20%环境初始化、轻量推理测试、编码开发8 个vgpu-medium8GB40%小模型训练、数据处理、中等负载4 个vgpu-large16GB70%中等模型微调、多任务并行2 个vgpu-xlarge32GB100%大模型推理、全参微调1 个最后 30 个环境里约 20 个选了 small8 个选了 medium2 个选了 large。这样一算显存总量是 20 乘以 4 加上 8 乘以 8 加上 2 乘以 16等于 176GB物理总量 256GB 完全装得下还留了 80GB 的余量给突发情况。HAMi 的好处就是“超卖可控”——你知道超了多少、超在哪里、还有多少余量而不是瞎赌运气。3. 核心细节解析HAMi 的关键机制与实操配置3.1 硬切与软切显存隔离和算力调度的区别HAMi 中有两个很容易混淆的概念显存隔离和算力调度。我刚开始部署时也差点理解偏了。显存隔离是硬性的“圈地”。每个 vGPU 会被限制在一个显存范围内程序想分配更多显存时底层会直接拦截。这意味着你的容器里看到的“总显存”就是申请的那个值比如 8GB 就是 8GB不会看到物理卡的完整 32GB。这个设计有好处也有坑好处是隔离性极强坏处是有些程序会主动探测显卡总显存并尝试占满如果探测到的是完整值但实际申请受限就可能报奇怪的错误。算力调度是软性的“限速”。它通过控制计算任务的并发度和时间片让每个 vGPU 大致只能使用设定比例的 GPU 算力。这个不是硬限制如果其他 vGPU 空闲你偶尔超过一点也是可能的但持续跑压力测试的话基本会被拉回设定值。从用户角度看显存隔离是“看得见的承诺”算力调度更多是“尽力而为的保障”。开发环境交付时我一般会把显存作为硬性 SLA算力作为软性参考这样既保证了稳定性又不会把 GPU 利用率卡得太死。3.2 Device Plugin Scheduler从调度到分配的完整链路一个带 HAMi 的 Kubernetes 集群请求 GPU 资源的完整链路大概是这样的用户创建一个 Pod声明nvidia.com/gpu: 1或者 HAMi 自定义的资源名比如hami.io/vgpu: 1。调度器发现这个 Pod 需要虚拟 GPU于是根据节点上已注册的 vGPU 规格、剩余资源、节点亲和性等条件选出一个最合适的节点。然后 device plugin 会接到“分配设备”的指令在节点上为这个容器创建对应的 vGPU 配置包括显存大小、算力比例、允许访问的物理卡编号。最后容器启动时HAMi 的注入组件会把 CUDA 环境变量和库文件路径写好让容器里的程序以为自己在使用一块完整的独立 GPU。这个链路里最关键的是“调度决策”。如果调度器分配得不好比如把两个大显存需求的 vGPU 放在同一张物理卡上可能单卡超卖严重影响体验。HAMi 的调度扩展会综合考虑节点上每张物理卡已有的分配情况尽量减少“热点卡”的出现。3.3 和自研调度器的连接方式电科云这套环境不是裸用开源 HAMi而是把它嵌入了自己的调度体系里。在这块我的实操经验是不要把 HAMi 当成一个“黑盒”而是要把它当成一个可扩展的调度组件来对接。HAMi 对外暴露了调度扩展接口自研调度器可以在决策前调用它查询每个节点的 vGPU 分布情况也可以在决策后把结果同步给它。这样一来用户侧的约束、租户的配额、资源池的优先级等都可以在自研层先过滤一遍再由 HAMi 做底层的设备切分。实际对接时需要注意接口版本要和 HAMi 的调度器版本严格一致。我踩过的一个坑是代码编译时的 protobuf 版本和集群上运行的不一致导致调度器之间无法通信Pod 一直 Pending。后来统一了镜像版本才恢复正常。3.4 国产 GPU 适配需要处理的问题国产 GPU 和 NVIDIA GPU 的适配最大的差异不在 HAMi 本身而在底层驱动。NVIDIA 有统一的 CUDA 生态很多虚拟化手段可以直接复用。国产 GPU 各有各的运行时和 SDK比如有基于类 CUDA 接口的也有自研编程框架的。HAMi 对国产卡的支持主要是在 device plugin 和调度层面做了适配但真正让容器里的程序跑起来还需要每个卡厂商提供对应的运行时注入方案。我们在部署时发现有些国产卡的驱动默认不支持 MPS 或者类似的并发机制算力切分只能退化为时间片轮转效果差一些。这个问题需要和厂商的驱动版本配合升级到较新的驱动版本后才支持算力切分。我的建议是在选型前先做一轮“虚拟化能力摸底”重点测试三件事——显存隔离是否可靠、算力切分是否生效、多任务并发时是否会出现锁死或驱动崩溃。如果这三项都过关再考虑大规模交付。4. 实操过程从裸机到 30 个开发环境4.1 环境准备与组件安装清单我会按下面的清单准备环境这里给出一个相对通用的参考版本组件版本/说明操作系统麒麟 V10 SP3 / 统信 UOS 均可内核 4.19 以上Kubernetes1.24 或 1.26 版本推荐 1.26 以上容器运行时containerd 1.6 / Docker 20.10GPU 驱动国产卡厂商提供的最新稳定版必须确认支持并发运行HAMi 调度器根据官方 release 安装调度器扩展组件HAMi device plugin每个节点部署 DaemonSet安装顺序上我习惯先装 GPU 驱动再做节点打标最后部署 HAMi 组件。如果顺序反了可能出现 plugin 注册时找不到驱动的情况Pod 创建后容器内部看不到 GPU 设备。4.2 关键配置示例如何定义 vGPU 规格HAMi 的 vGPU 规格通常在 device plugin 的 ConfigMap 里定义。下面是我们在生产环境用过的一个简化示例apiVersion: v1 kind: ConfigMap metadata: name: hami-device-plugin-config namespace: kube-system data: config.yaml: | vgpu: resourceName: hami.io/vgpu memoryUnit: 1 resourceMem: 4 resourceCores: 20这段配置的意思是以hami.io/vgpu作为资源名每个 vGPU 的最小显存单位为 1GB默认的 vGPU 规格为 4GB 显存、20% 算力。实际使用中更常见的做法是在 Pod 的 resources 里显式声明resources: limits: hami.io/vgpu: 1 hami.io/vgpu-memory: 8 hami.io/vgpu-core: 40这样就是申请一个 8GB 显存、40% 算力的 vGPU。你可以根据前面规格表里的不同档位动态创建不同的 Pod而不需要修改全局配置。这对我交付 30 个不同规格的开发环境特别有用——开一个 4GB 的环境和开一个 16GB 的环境只需改 requests 里的参数。4.3 验证与租户交付从 Pod 到真实可用配置好之后第一步是创建一个测试 Pod 验证 GPU 是否真实可见。进入到容器里用类似nvidia-smi的工具查看显存大小如果显示的值和申请的 vGPU 规格一致说明显存隔离生效了。但开发环境交付不只是“能看到 GPU”还要保证 SSH 登录、代码同步、Jupyter 之类的服务能正常跑。我们的 30 个环境交付时采用了“基础镜像 用户数据卷”的方式每个环境有独立的 home 目录镜像只包含基础工具链用户的数据通过 PVC 挂载。这样即使环境重建数据也不会丢。还有一个值得注意的点所有开发环境共享同一个基础镜像但 GPU 厂商的库文件版本可能不同。如果环境里需要编译 CUDA 扩展最好在镜像里固定运行时版本避免用户各自升级导致和宿主驱动不匹配。我们最开始没注意这个问题有几个人升级了厂商 SDK 后环境里的程序反而找不到设备了。5. 常见问题与排查技巧实录5.1 显存超卖导致程序报 OOM 怎么办这是最常遇到的问题。多个 vGPU 共享一张物理卡如果超卖比例太高某些任务的显存压力会传导到物理卡的总体使用上导致某个 vGPU 的实际可用显存低于申请值。排查思路是先看这张物理卡上同时部署了哪些 vGPU然后计算总显存需求。如果总需求明显大于物理显存就需要降低超卖比例或者把大规格的 vGPU 分散调度到不同物理卡上。还有一种情况是某个程序有显存泄漏长时间运行后越占越多这时候需要靠监控和限额来兜底而不是完全依赖调度器。5.2 容器里看不到 GPU 设备怎么定位这个问题的原因比较多常见的有三类device plugin 没有正确识别物理 GPUPod 调度到了没有安装驱动的节点镜像里的运行时库和宿主驱动不兼容。定位方法也很直接先看节点上的 device plugin 日志确认物理卡被识别并注册成功再检查节点标签确认调度器把 Pod 放到了正确的节点上最后在容器里查看设备文件是否存在以及能否正常加载厂商的运行时库。如果设备文件存在但调用报错八成是驱动版本和容器内 SDK 不匹配升级或降级其中一方解决。5.3 算力切分不生效多个任务互相抢占怎么办有些国产卡的驱动默认没有开启算力切分功能需要显式配置。比如某些卡需要设置环境变量或修改驱动参数允许进程在 GPU 上进行时间片轮转或并发执行。如果没有开启多个任务实际上是“串行排队”的一个任务不结束另一个任务根本不开始看起来就像算力切分没生效。解决方法是在部署 HAMi 之前先用厂商提供的多进程测试工具验证一下同时跑两个计算任务观察它们是并行还是串行。如果串行说明驱动层面没有开启并发需要查驱动文档打开对应开关。这一项如果一开始没做好后面交付多少个环境都会碰到性能问题。5.4 开发环境中的 PyTorch 报 CUDA 错误开发环境里跑 PyTorch 时可能遇到常见的 CUDA 错误比如CUDA error: out of memory或者CUDA driver version is insufficient。这里有一个容易被忽略的细节容器里看到的显存是 vGPU 的显存但 CUDA 驱动可能报告的是物理卡的总显存。某些程序会拿这个“物理总显存”和“实际可用显存”做比较导致预分配策略异常。我的处理方法是在开发环境的镜像里加入一层包装把 CUDA 的显存查询结果限制在 vGPU 允许范围内。从用户体验上讲这能让“容器里看到的环境”和“实际可用的资源”尽量一致避免程序在启动阶段就因为显存判断错误而崩溃。这个包装在官方文档里可能没有细讲但大规模交付开发环境时确实很重要。5.5 一张表速查常见问题现象可能原因排查方法解决办法Pod 一直 Pending调度器无法分配 vGPU查看 scheduler 日志和节点资源状态检查 vGPU 规格是否超过物理卡容量调整调度策略容器内看不到 GPUdevice plugin 未识别或节点无驱动检查节点标签和 plugin 日志重新部署 device plugin确认驱动正常程序报显存不足实际物理显存超卖严重查看单卡 vGPU 分布及总占用减少超卖比例或迁移部分 vGPU 到其他空闲卡多个任务串行执行驱动未开启并发/MPS用多任务并发测试工具验证按厂商文档打开驱动并发开关PyTorch 启动报 CUDA 错误容器内 SDK 与驱动不匹配对比驱动版本和 SDK 要求统一镜像内 SDK 版本或升级驱动写在最后的运维心得用 HAMi 承载 30 个开发环境做完之后回头看这件事的核心其实不是“装个开源组件”而是“把资源分配逻辑想透”。8 张国产 GPU 能撑起 30 个环境靠的是精细的规格设计、靠谱的显存隔离和可预期的调度策略。我个人在实际操作中的一个体会是不要一上来就把超卖比例拉满。刚开始部署时可以把超卖设得保守一些验证稳定之后再逐步调整。毕竟开发环境一旦跑起来用户就会在里面写代码、跑实验如果频繁 OOM 或者崩驱动运维压力会非常大。先稳后快是这套方案能顺利落地的主要原因。最后再分享一个小技巧给每个 vGPU 打上租户标签在监控面板上按标签聚合查看显存和算力使用率。这样一来哪个团队的环境闲置了、哪个环境长期高负载一眼就能看出来。后续做资源回收和扩缩容都有数据支撑不用靠猜。