本文译自 CNCF 博客（2026 年 8 月 7 日），原文作者系 HAMi 项目贡献者。HAMi 已于 2026 年 7 月 15 日被 CNCF 技术监督委员会（TOC）接收为孵化项目。
想在一个 Kubernetes 上共享 GPU 的项目，长期以来只能「绕开」API 去工作，而不是「顺着」API 来工作。设备插件（device plugin）接口能做的事就是数设备，这就是它的全部词汇：nvidia.com/gpu: 1，意思是一整张卡，爱要不要。
HAMi 正是在这个词汇贫乏的基础上，构建了一整套流水线（变更型准入 Webhook、调度器扩展器、注解、容器内强制限制），去表达那些词汇表达不了的需求：「给这个 Pod 8000 MiB 显存和 10% 的算力，而且要把限制落到实处。」
后来，词汇变了。动态资源分配（Dynamic Resource Allocation，DRA） 在 Kubernetes v1.34 中正式发布（GA），并在 v1.35 起默认开启。借助其中的可消费容量（consumable capacity）特性，一个 Pod 现在可以越过任何注解，直接向调度器原生地申请一张设备显存的一个切片。
所以，HAMi 社区里反复被问到的问题是：DRA 会让 HAMi 过时吗？
简短的回答是：不会。但完整的回答取决于你指的是 HAMi 的哪项职责。其中一项，把碎片化请求编码成调度器看得懂的形式，恰恰是 DRA 要吸收掉的；另一项，在容器内以 CUDA 调用粒度强制执行这些配额，则是 DRA 从设计上就无意承担的工作。HAMi 的应对之策也顺势分成了两半：保留强制执行层，并在 DRA 之上用 3 个仓库重建编码层。
下面我们就把这两半拆开看清楚，再看如今跑通 DRA 这套栈需要什么。
上一篇 《HAMi-core 被 NVIDIA KAI Scheduler 采用》已经介绍了 KAI Scheduler 和这项集成的协作背景。本文不再重复铺垫，只回答一个问题：KAI Scheduler 把两个 Pod 调度到同一张 GPU 后，HAMi-core 是否真的能限制每个 Pod 的显存用量？
我们在 GKE 1.35/COS/CDI 上验证了当前文档支持的组合：KAI Scheduler v0.17.0 与 kai-resource-isolator 1.1.0-chart。两个 Pod 共享同一张 NVIDIA T4，各自看到 4147 MiB 上限；申请 3 GiB 成功，累计申请 5 GiB 失败。可选的 monitor 也导出了两个 Pod 的实时显存上限与用量。
下文的 UUID、显存上限、CUDA 分配结果和 monitor 指标均来自该次 GKE 实测。资源后缀和地址在不同集群中会变化。
2026 年 7 月 16 日，密瓜智能（Dynamia）联合创始人兼 CTO、HAMi 作者 李孟轩 在 vLLM Meetup 上做了一场关于 vLLM 部署与算力优化 的技术分享。围绕一个直击痛点的问题：「你的算力用的好么？」，他系统梳理了 vLLM 推理集群从"能跑起来"到"把算力榨干"的演进路径，把整个优化过程拆解为清晰的三个阶段。
本文结合分享 PPT 与现场纪要，带大家完整回顾这场干货满满的分享。
本文中的集成对象严格来说是 HAMi-core，而非完整 HAMi 平台。KAI Scheduler 保留自身调度能力，引入 HAMi-core 提供 GPU Memory Isolation 能力。
2026 年 6 月，两项核心 PR 正式合并进入 NVIDIA KAI Scheduler 主干。HAMi 的 GPU 显存硬隔离能力已作为内置特性随 KAI Scheduler v0.16.4 发布，云原生 GPU 资源调度正式从「软共享」迈入「硬隔离」时代。
