HAMi 在 2024 年 8 月进入 CNCF Sandbox 后，于 7 月 2 日正式晋升为 CNCF Incubating 项目，并获得 CNCF 技术监督委员会 TOC 全票通过。对做 AI 平台、GPU 集群和 Kubernetes 资源管理的团队来说，这不是一个普通的项目状态更新：它意味着“异构 AI 算力如何被 Kubernetes 稳定、可观测、可共享地使用”这个问题，正在进入更主流的工程讨论区。
HAMi 解决的不是“有没有 GPU”，而是“怎么分、怎么管”
HAMi 的全称是 Heterogeneous AI Computing Middleware，2021 年 7 月 12 日首次开源。仅从名字就能看出它面对的核心场景：AI 计算资源已经不再是单一 GPU 型号、单一厂商、单一使用方式。
在真实集群里，平台团队经常会遇到这些问题：
- 不同节点挂载不同类型的 AI 加速卡；
- 训练、推理、批处理任务对算力和显存的需求差异很大；
- 业务希望“申请一部分 GPU”而不是独占整张卡；
- 多租户环境下，需要限制资源用量，避免一个任务吃满整机；
- Kubernetes 原生资源模型对异构 AI 设备的表达能力有限。
HAMi 作为面向 Kubernetes 的异构 AI 计算中间件，价值就在于把这些设备和调度问题尽量收敛到 Kubernetes 用户熟悉的工作流里。开发者继续提交 Pod、Job 或推理服务，平台侧则通过设备插件、调度扩展和资源抽象来管理底层差异。
从 Sandbox 到 Incubating，信号比标签更重要
CNCF 项目成熟度分为不同阶段。Sandbox 更偏早期探索，Incubating 则意味着项目已经证明了更强的社区活跃度、用户价值和治理基础。
这次 HAMi 晋升孵化项目，有几个值得工程团队关注的信号：
- 它不是刚出现的实验项目，而是从 2021 年开源后持续演进；
- 它已经在 CNCF 流程中完成从 Sandbox 到 Incubating 的跃迁；
- TOC 全票赞成，说明项目方向和社区治理获得了较明确认可；
- 异构 AI 算力管理正在从“各家平台自研脚本”走向更标准化的云原生组件。
这并不等于所有团队都应该立刻生产启用 HAMi。更现实的判断是：如果你的 Kubernetes 集群已经开始承载 AI 工作负载，尤其是 GPU 利用率、多租户隔离、异构设备管理开始变成日常问题，HAMi 值得进入技术选型列表。
可以这样实践：用 Kubernetes 资源声明表达 AI 任务需求
下面的示例是一个可改造的 Kubernetes Job 模板，用来表达“AI 任务向集群申请加速资源”的基本形态。不同 HAMi 版本、不同设备类型和安装方式可能使用不同的资源名与参数，运行前需要根据你集群中实际暴露的资源名称调整 resources.limits。
先查看集群节点上有哪些可申请资源：
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, allocatable: .status.allocatable}'
如果你的集群已经安装了 HAMi，并且节点暴露了类似 GPU/vGPU 的扩展资源，可以基于下面的 Job 改造：
apiVersion: batch/v1
kind: Job
metadata:
name: ai-smoke-test
spec:
backoffLimit: 0
template:
spec:
restartPolicy: Never
containers:
- name: cuda-check
image: nvidia/cuda:12.4.1-base-ubuntu22.04
command: ["bash", "-lc"]
args:
- |
echo "Allocated AI device resources:"
env | sort | grep -E 'CUDA|GPU|NVIDIA|HAMI' || true
nvidia-smi || true
sleep 10
resources:
limits:
# 按你的集群实际资源名修改；下面只是常见写法示例
nvidia.com/gpu: "1"
提交并观察调度结果：
kubectl apply -f ai-smoke-test.yaml
kubectl get pod -l job-name=ai-smoke-test -o wide
kubectl logs job/ai-smoke-test
kubectl describe pod -l job-name=ai-smoke-test
如果你使用的是 HAMi 提供的 vGPU 或其他异构设备资源，实践时重点检查三件事：
kubectl describe node中资源是否被正确注册；- Pod 的
limits是否使用了 HAMi 对应的资源名； - 调度失败时，事件里是资源不足、节点不匹配，还是运行时设备注入失败。
平台团队真正要评估的四个问题
引入 HAMi 这类组件时，不能只看“能不能把任务跑起来”。AI 算力调度一旦进入生产环境，问题通常出现在边界条件上。
资源抽象是否匹配业务模型。 训练任务、推理服务、Notebook、批处理作业对 GPU 的使用方式不同。平台需要确认 HAMi 暴露的资源粒度，是否能覆盖你的租户配额、优先级和成本分摊模型。
异构设备是否真的被纳入统一运维。 如果集群里同时存在多种 AI 加速设备，调度只是第一步。监控、故障定位、驱动版本、节点池管理和镜像兼容性都要进入同一套运维流程。
多租户隔离不能只依赖资源声明。 Kubernetes 的 limits 是入口，但生产环境还需要配合命名空间配额、准入控制、镜像策略、节点污点与容忍，以及审计日志。
升级路径要提前演练。 HAMi 已进入 CNCF Incubating，但你的集群版本、设备驱动、容器运行时和调度器扩展点仍然可能形成组合风险。建议先在独立节点池做灰度，而不是直接覆盖核心训练集群。
落地建议：先用小集群验证资源模型
HAMi 晋升 CNCF 孵化项目，是异构 AI 算力管理云原生化的一个明确信号。对已经在 Kubernetes 上运行 AI 工作负载的团队，它值得被认真评估；对还在用人工分配 GPU、静态节点绑定或零散脚本管理任务的团队，它提供了一个更工程化的方向。
采用时可以按这个顺序推进：
- 在测试集群安装并确认设备资源能被 Kubernetes 发现；
- 用最小 Job 验证资源申请、调度、设备注入和日志；
- 接入监控，观察 GPU/vGPU 使用率、失败调度事件和节点健康；
- 用命名空间配额和准入策略约束多租户使用；
- 再考虑迁移训练平台、推理平台或 Notebook 平台的真实工作负载。
CNCF Incubating 不是生产可用性的替代证明，但它说明 HAMi 已经走过了早期项目最不稳定的阶段。接下来真正的价值，要在你的设备类型、任务模式和平台治理要求里验证出来。