HAMi 社区正式发布 HAMi v2.10.0。本次发布在三个方向上取得进展：更灵活的调度策略、更广泛的异构加速器覆盖，以及更加丰富的调度器生态。
v2.10.0 引入了动态 Flexible MIG、全新的 mutex 调度策略、社区期待已久的 NUMA 排序修复、可组合调度策略、PodGroup（gang-scheduling） 支持，以及更准确的 init 容器 资源计量。在设备侧，新增了 AMD MI300X 与壁仞支持、让基于模板的 vNPU 与 HAMi-core 节点在同一集群共存的昇腾异构管理能力，以及 vNPU HAMi-core 监控。同时通过全新的 KAI Resource Isolator 伴随项目，首次实现了 KAI Scheduler + HAMi-core 集成。
本文将对 v2.10.0 的主要更新进行详细说明。
本文译自 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 这套栈需要什么。
Volcano 是很多 AI 集群的批量调度器首选，HAMi-core 则是让共享加速器"守规矩"的运行时。本文关注两者在昇腾硬件上的交汇点：在 Volcano 调度器下运行 hami-vnpu-core 软切分的 vNPU，让批量调度语义（队列、Gang、binpack）与容器级隔离（在昇腾 API 层强制生效的显存与算力上限）协同工作。
我们在一台昇腾 310P3 aarch64 服务器的单节点 Kubernetes 集群上验证了完整链路：源码编译 Volcano 镜像、部署官方 ascend-device-plugin v1.4.0 镜像，并确认申请 8192 MiB 切片的容器恰好只能看到这么多显存；同时第二个 Pod 以 binpack 方式落到同一张物理卡上、拿到独立切片，插件的 Prometheus 端点也如实上报了两个容器的配额。完整步骤（含每条命令与真实输出）见 实验 13：用 Volcano + HAMi-core 软切分昇腾 310P3 vNPU。
这个话题里混着好几个经常被混为一谈的概念，所以本文先把层次分开：vNPU 是什么、硬切分和软切分有何不同、Volcano 集成相比已有的 HAMi 调度器路径到底新增了什么。
本文所有输出均采集自真实的昇腾 310P3 物理服务器，截至撰写本文时已在真机上验证：麒麟 V10 aarch64 节点、2× 昇腾 310P3（驱动/npu-smi 25.5.1）、Kubernetes v1.28.15、containerd 1.7.1。其他集群中的 UUID、IP、Pod 后缀会不同；请对比组件名、调度位置与测量值。
上一篇 《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 实测。资源后缀和地址在不同集群中会变化。
Linux Foundation LFX Mentorship Program 2026 第三期（Term 3）正式启动，HAMi 将在 9 月至 11 月期间指导四个开源课题。
mentee 申请通道于 2026 年 8 月 3 日开启，8 月 18 日截止。无论你钟情底层 C/C++ 性能优化、GPU 可观测性、容器隔离安全，还是开发者教育与文档，都能找到适合你的方向。
KubeCon + CloudNativeCon 日本 2026 于 7 月 28 至 30 日在 Pacifico Yokohama 举办。HAMi 以一场主舞台分享和 Project Pavilion 的展台参与本届大会。Reza Jelveh 登台分享，并在展台值守。
完整的回顾、演讲幻灯片与 SNOW 案例，请见 KubeCon 日本 2026 专页。
2026 年 7 月 16 日，密瓜智能（Dynamia）联合创始人兼 CTO、HAMi 作者 李孟轩 在 vLLM Meetup 上做了一场关于 vLLM 部署与算力优化 的技术分享。围绕一个直击痛点的问题：「你的算力用的好么？」，他系统梳理了 vLLM 推理集群从"能跑起来"到"把算力榨干"的演进路径，把整个优化过程拆解为清晰的三个阶段。
本文结合分享 PPT 与现场纪要，带大家完整回顾这场干货满满的分享。
我们很高兴地宣布：2026 年 7 月 2 日，HAMi 正式晋升为 CNCF Incubating（孵化）项目，CNCF 技术监督委员会以全票赞成通过了本次孵化投票。
这是 HAMi 继 2024 年 8 月作为 Sandbox 项目加入 CNCF 后的又一个重要里程碑，意味着 CNCF 技术监督委员会（TOC）认可 HAMi 已具备成熟的技术与安全实践、活跃的社区、真实的生产采用与开放的生态集成。
2026 年 6 月 18-19 日，KubeCon + CloudNativeCon India 2026 在印度孟买举行，来自云原生生态的实践者、平台工程师、AI 基础设施团队和开源贡献者齐聚一堂。随着 AI 成为本届大会最重要的主题之一，HAMi 展示了 Kubernetes 原生 GPU 共享如何帮助组织提升加速器利用率，同时保持工作负载隔离和运维灵活性。
从开场 Keynote 到展台现场演示，再到与工程团队的技术讨论，本次活动凸显了一个越来越明确的行业关注点：让昂贵的 GPU 基础设施真正适用于多租户 AI 工作负载。
本文中的集成对象严格来说是 HAMi-core，而非完整 HAMi 平台。KAI Scheduler 保留自身调度能力，引入 HAMi-core 提供 GPU Memory Isolation 能力。
2026 年 6 月，两项核心 PR 正式合并进入 NVIDIA KAI Scheduler 主干。HAMi 的 GPU 显存硬隔离能力已作为内置特性随 KAI Scheduler v0.16.4 发布，云原生 GPU 资源调度正式从「软共享」迈入「硬隔离」时代。
