如果你的团队在 Kubernetes 上跑 AI 工作负载，大概率见过这样的场景：监控面板上所有 GPU 都显示"已分配"，nvidia-smi 里的实际利用率却只有个位数。一个只要 4GB 显存的推理服务，被调度的那一刻起就整张占住一块 80GB 的 H100，直到生命周期结束。知乎为峰值流量买的卡，在低谷期几乎整天空转，而新的算力预算申请还在不断提上来。
GPU 很贵，一张 A100 80GB 要十几万，L40S 也要大几万。知乎所以社区里那句话才格外扎心：卡闲着，账单没闲着。这既是最近一个月 GPU 共享话题密集升温的最大动力，也是今天要聊的这条新闻的背景。
晋升 CNCF 孵化只是新闻本身，更有意思的是后面那一问
7 月 2 日，HAMi 通过 CNCF 技术监督委员会（TOC）的全票投票，正式从沙箱（Sandbox）晋升为孵化（Incubating）项目。知乎距离它 2024 年 8 月进入沙箱，差不多两年。在 CNCF 的成熟度体系里，孵化意味着项目在技术成熟度、安全实践、社区治理、生产采用和生态集成上都过了评审——不再是"有潜力"，而是"真的被用起来"。
随后的动作也很密集：6 月，NVIDIA 的 KAI Scheduler 把 HAMi-core 采纳为 GPU 显存硬隔离的内置能力；7 月中旬，CNCF 正式发布招商银行基于 HAMi 构建 AI 算力调度平台的案例研究。知乎再往前，KubeCon EU 阿姆斯特丹的主论坛上，HAMi 团队在一块 GPU 上并发跑起了 YOLO 推理和 Qwen3-8B 大模型推理。对一个 2021 年首次开源、由中国团队发起、被数百家组织采用、贡献者遍布全球 20 多个国家和地区的项目来说，这份履历足够有说服力。
但今天不只是来道贺的。社区里反复被问到一个更现实的问题，HAMi 维护者自己也在正面回答：Kubernetes 原生的 DRA 来了，HAMi 是不是要被取代了？
"切卡"这件事，之前为什么那么难
要回答这个问题，先得明白 Kubernetes 原生的 GPU 词汇有多贫乏。设备插件（device plugin）接口能做的就是数卡：nvidia.com/gpu: 1，意思是一整张，爱要不要。你不能要半张卡，也不能说"只给我 8GB 显存加 10% 算力"。
于是 HAMi 用一整套"绕路"补上了这个缺口：变更 Webhook 把 Pod 改道到自己的调度器扩展器，扩展器过滤节点、给每张卡打分、挑出具体的设备 UUID，决策写进 Pod 注解；节点上的设备插件读取注解，把限额环境变量注入容器，同时预加载 libvgpu.so——这个 C 库拦截 CUDA 和 NVML 调用，容器想超额分配显存时，直接收到一个 OOM。粒度细到 1MiB 显存、1% 算力。
这套机制已经在生产规模上被验证过，DaoCloud 在 10 多个数据中心、10000 多张 GPU 上跑着它。知乎招商银行的 AI 调度平台同样建在这套机制之上。不过说句公道话，整个设计里全是绕路：注解是只有 HAMi 自己的组件才读得懂的地方，每换一个第三方调度器都要做专属集成，社区里每个切卡项目都有自己的私有注解方言。
DRA 改了词汇，但只改了一半
动态资源分配（DRA）在 Kubernetes v1.34 中正式发布（GA），自 v1.35 起默认锁定开启。知乎它借鉴 PVC 的思路，用 ResourceClaim 声明对象取代整数计数，"哪张卡、多少量"第一次成为 kubectl 能读、RBAC 能守的类型化 API 对象，而不是躺在一条注解字符串里。
关键的扩展叫可消费容量（consumable capacity）：Pod 可以原生地向调度器申请"某张卡上显存的一个切片"。这个特性在 v1.36 进入 beta 后，调度器开始给设备显存记账，已承诺的容量不会再被二次许诺。HAMi 用户熟悉的 nvidia.com/gpumem: 8000，几乎可以机械地映射成一条容量请求；过去那种 CardInsufficientMemory 的拒绝，则变成一次标准的不可调度 Claim。
那 HAMi 是不是就此退场？8 月 7 日 CNCF 博客上那篇由 HAMi 贡献者（同时也是 CNCF TAG Infrastructure 的 Tech Lead）撰写的文章，给的是一个拆分式的答案。
DRA 会吸收掉的，是 HAMi 的"编码层"——把碎片化请求翻译成调度器能听懂的形式那部分。这本来就是 DRA 被造出来要终结的局面，HAMi 的 2026 路线图也把"完成 DRA 标准适配"列为目标。这一侧的动作已经在路上：k8s-dra-driver 把每张 GPU 的显存和算力以可消费容量的形式发布出来；HAMi-DRA 的 Webhook 把按老写法写就的清单即时翻译成 ResourceClaim，存量 YAML 一行不用改；伴随 HAMi v2.9，HAMi-DRA v0.2.0 宣布生产就绪，支持名单也从 NVIDIA 扩到了昇腾和燧原。
DRA 不做、而且设计上就不打算做的，是运行时强制执行。DRA 是一个承诺跟踪器，它保证调度器不会许诺超过设备拥有的容量，但 CUDA 才不管 ResourceClaim 里写了什么，一个贪婪的 cudaMalloc() 循环会高高兴兴地吃掉邻居正指望的那块显存。知乎拦截 CUDA 调用、把配额真正执行到位，仍然是 HAMi-core 的活，DRA 里没有任何东西能替代这一层。
一句话总结：请求的语言变了，运行时的契约没变。
选型表：动手之前先看这个
方案 | 隔离能力 | 超卖 | 门槛 | 适合场景 |
|---|---|---|---|---|
时间分片 | 无，显存无上限 | 伪超卖，易拖垮 | 任意 GPU | 基本不推荐 |
MPS | 无，提升并发效率 | 不支持 | 任意 GPU | 信任团队提吞吐 |
HAMi 软件拦截 | 软隔离，配额强制 | 显存算力都支持 | CUDA 生态 | 内部团队共享、国产卡 |
NVIDIA vGPU | 驱动级硬隔离 | 不支持 | 特定卡+付费 License | 传统虚拟化 |
MIG | 物理分区 | 不支持 | 仅 A100/A30/H100 等 | 多租户硬隔离 |
按场景给几个直接结论：
内部互信团队、几张卡跑一堆推理服务：HAMi 传统模式仍是最省心的选择。零侵入、镜像不用改，还支持超卖——显存可以放大上报，算力用令牌桶分时共享，最坏的结果是变慢而不是崩。
想靠向 K8s 原生、集群已经在 1.36 及以上：可以试点 k8s-dra-driver + HAMi-DRA。但记住三个前提：可消费容量在上游还没 stable，k8s-dra-driver 的 Helm chart 仍标注 work in progress，DRA 侧的厂商覆盖比传统模式小得多。
多租户、有安全合规要求：软件拦截不够，静态链接 CUDA 的程序和容器套容器都能绕过预加载，需要 MIG 这类物理分区。好在 HAMi 本身也能动态调度 MIG，两者不冲突。
避坑清单，这些都是真会踩的
传统模式和 DRA 模式，绝对不能在同一个集群里同时跑。两个记账人会各自以为拥有同一份显存，谁也看不到对方的承诺。每个集群只选一种模式。
软件隔离是栅栏，不是墙。配额按容器生效，但共享卡上一个挂起的进程、一次驱动重置、一个 XID 错误，照样会波及卡上所有租户。关键业务记得留余量。
走 HAMi-DRA，就要接受它不做拓扑感知调度。哪两张卡走 NVLink、哪一对带宽更高，Webhook 表达不了，得靠懂拓扑的调度器。
切模式之后别忘观测。DRA monitor 默认开启，通过 Prometheus 31995 端口暴露逐容器的设备指标，原来基于 exporter 建的仪表盘大多能沿用。
现在该等，还是该上
我的判断是：两边方向都已经明确，不用赌方向，但节奏值得盯。三个信号可以持续跟：上游的可消费容量什么时候从 beta 走到 stable；k8s-dra-driver 的 Helm chart 什么时候摘掉 WIP 标记；DRA 模式的厂商覆盖——尤其是国产卡——什么时候追上传统模式。这三件事齐了，新集群可以直接从 DRA 模式起步。
存量集群也不用急着迁移。无论走哪条路，容器里跑 nvidia-smi 看到的都只是被授权的那个切片，而不是整张物理卡。知乎HAMi 留下的，是最有价值的强制执行层；编码层交还给上游，恰恰是一个绕路方案最好的结局——你解决的问题，被写进了标准。
最后给正在纠结"利用率这么低，要不要加卡"的同学一个建议：提预算之前，先把卡切开试试。8 张卡，不一定只能跑 8 个服务。
你所在团队的 GPU 利用率现在是多少，切卡用的哪套方案？评论区聊聊。
