多租户 GPU 池化：算力切分、隔离与计费
一张 H100 大部分时间利用率不到三成，是很多企业 GPU 平台的常态——整卡分发的模式对小任务极不友好。GPU 池化就是要把一张卡切成多份安全地分出去，核心矛盾在三个词：切分粒度、隔离强度、计费公平。
五条切分路线，三种隔离等级
业界主流的切分技术可以按隔离强度分成三档：硬件级、软件级和无隔离。
| 技术 | 隔离级别 | 切分粒度 | 厂商绑定 | 适用场景 |
|---|---|---|---|---|
| MIG | 硬件级，独立显存控制器与计算核 | 固定档位，A100/H100 最多 7 实例 | 仅 NVIDIA 数据中心卡 | 不可信租户、有合规要求的场景 |
| vGPU | 虚拟化层，hypervisor 隔离 | 灵活，可热迁移 | NVIDIA 且需授权 | 云桌面、VM 形态的多租户 |
| HAMi | 软件级，CUDA 调用拦截限流 | 显存可到 GB 级、算力可到百分比 | 跨厂商，支持 NVIDIA、昇腾、寒武纪等 | 企业内部混部、开发测试 |
| 时间分片 | 无显存隔离，轮流占卡 | 整卡轮转 | 各家均有 | 内部可信批量任务 |
| MPS | 无隔离，共享上下文 | 并发进程共享算力 | NVIDIA | 大量小型协作进程 |
MIG 是唯一提供真正硬件隔离的方案：每个实例有独立的显存控制器与计算引擎，一个实例内存溢出不可能波及邻居。但它的限制同样明确：只支持较新的数据中心卡、档位固定不可在线调整、NVLink 不跨实例，而且改档位需要整节点排空重启。时间分片最省事也最危险——显存是共享池，一个租户的显存泄漏可以砸掉同卡所有邻居，绝不能当作租户边界。HAMi（已进入 CNCF 孵化阶段）走中间路线：在调度层做细粒度虚拟化，通过拦截 CUDA 调用强制执行显存与算力上限，对业务代码透明，且是五条路线里唯一跨芯片厂商的。
信任边界决定技术选型
选型的第一问不是"哪个性能好"，而是"租户之间信不信任"。同一公司内部团队共享一张卡，软件级限流足够；面向外部客户的推理平台，租户与租户之间只有整卡或 MIG 才够格——因为共享的不只是 GPU，还有内核驱动、宿主机内核与控制平面，软件拦截层挡不住恶意工作负载。CNCF 相关指南的表述很直白：同一信任域内才共享硅片，跨信任域只共享整卡。
还有一个常见误区值得点名：部署了 HAMi 但资源申请只写整卡数、不写显存与算力限额，结果每张卡还是被一个任务独占，池化等于没做。此外，混合策略往往是最优解：生产推理用 MIG 保隔离，内部开发测试走 HAMi 提灵活性，老卡开时间分片充分利旧。调度协议层面，Kubernetes 的 DRA（动态资源分配）已在 1.34 版本转正，用结构化的 ResourceClaim 取代整数计数，是各家方案正在迁移的统一底座。
计费：按分配开票，按用量审计
池化之后最麻烦的是"钱怎么算"。成熟的做法是双轨制：计费以分配量为准（租户占了多少 GB 显存、多少比例算力、占了多长时间），与队列和配额联动，这是账单的依据；同时用 DCGM 之类工具采集实际利用率，做成本审计与容量规划，识别"占着不用"的僵尸配额。OpenCost 等开源方案可以把这笔账对齐到团队与项目维度。没有这层计量，池化平台最终会退化成"先到先得的公共冰箱"。
写在最后
三条建议：第一，先画信任边界再选技术，外部租户只用 MIG 或整卡，内部混部才上软件切分；第二，上池化的同时上计量，分配量开票、用量对账，缺一边都会引发结算纠纷；第三，关注 DRA 的落地进度，把自有平台的资源申请结构化，为跨厂商调度留好接口。GPU 太贵，贵到不该让任何一张卡闲着——但切分的前提，是切得安全、算得清楚。