HAMi 进入 CNCF 孵化阶段：GPU 共享与碎片治理走向云原生主航道

预计阅读时间：9 分钟

CNCF 技术监督委员会（TOC）已投票接纳 HAMi 成为 CNCF 孵化项目。对 AI 基础设施团队来说，这不仅是一次项目状态升级，也意味着一个长期存在的问题获得了更明确的云原生治理路径：昂贵的 GPU 虽然已经被 Kubernetes 纳管，却仍可能因为分配粒度过大、工作负载需求不均而产生资源碎片。

GPU 数量充足，不等于可用容量充足

传统 Kubernetes 调度通常把扩展资源视为不可分割的整数。例如，一个节点有 8 张 GPU，某个推理任务实际只消耗一部分显存，但只要它申请并独占一张卡，剩余容量就很难继续分配给其他任务。

这种碎片会表现为几个常见现象：

节点显示 GPU 已分配，但设备利用率和显存利用率并不高；
小型推理服务排队等待，集群中却仍存在零散容量；
训练、推理和交互式开发混部后，资源需求难以用整数 GPU 准确描述；
为了保证关键任务可运行，平台团队只能保留冗余节点，抬高基础设施成本。

HAMi 面向的正是这类 GPU 共享与异构 AI 设备调度问题。进入 CNCF 孵化阶段说明该项目已经通过 TOC 的相关评估，并进入更成熟的社区治理阶段。不过，孵化并不等于平台可以跳过验证直接全量上线；设备插件、驱动、容器运行时以及工作负载行为仍会共同决定最终效果。

孵化状态对平台团队意味着什么

CNCF 孵化项目通常已经超越早期概念验证阶段。对采用方而言，更值得关注的不是徽章本身，而是项目能否被纳入正式的平台工程流程。

团队可以围绕以下问题展开评估：

治理是否可持续：维护者结构、版本发布、问题响应和路线图是否清晰。
接口是否稳定：升级 HAMi、Kubernetes、GPU 驱动或设备插件时，资源声明是否需要迁移。
隔离是否满足业务要求：共享 GPU 后，显存、计算能力、故障和性能干扰能否被控制在可接受范围。
可观测性是否完整：平台能否同时看到 Kubernetes 资源申请、设备实际利用率、调度失败原因和租户归属。
故障处置是否明确：调度器、设备插件或节点组件异常时，任务如何降级、迁移或恢复。

HAMi 的价值不能只用“单卡能运行更多 Pod”衡量。真正有意义的指标包括任务排队时间、GPU 有效利用率、单位推理成本、作业失败率，以及共享前后的尾延迟变化。

先做一次 GPU 资源盘点

在引入共享调度前，可以先找出集群中由设备插件暴露的 GPU 类资源。下面的命令只读取 Kubernetes Node 状态，不依赖 HAMi 的特定资源名称；运行前需要配置好 kubectl，本机还需要安装 jq。

kubectl get nodes -o json | jq -r '
  .items[] as $node
  | $node.status.capacity
  | to_entries[]
  | select(.key | ascii_downcase | contains("gpu"))
  | [$node.metadata.name, .key, .value] | @tsv
'

接着检查工作负载声明了哪些 GPU 资源：

kubectl get pods -A -o json | jq -r '
  .items[] as $pod
  | $pod.spec.containers[]
  | (.resources.limits // {})
  | to_entries[]
  | select(.key | ascii_downcase | contains("gpu"))
  | [
      $pod.metadata.namespace,
      $pod.metadata.name,
      .key,
      .value
    ] | @tsv
'

这两份结果可以回答两个基础问题：集群暴露了哪些 GPU 资源名称，以及哪些命名空间正在申请它们。它们不能代替设备侧监控，因为 Kubernetes 的申请量不等于显存或算力的实际使用量。生产评估还应结合厂商监控工具和 Prometheus 指标。

可以这样设计 HAMi 试点

由于来源摘要没有给出具体版本、安装方式和资源字段，下面给出的是一个可改造的试点骨架，不把示例中的占位资源名当作 HAMi 的固定 API。部署前应根据所安装 HAMi 版本的文档替换 EXAMPLE_HAMI_RESOURCE，并确认对应资源的单位和语义。

apiVersion: v1
kind: Namespace
metadata:
  name: gpu-sharing-pilot
  labels:
    platform.example.com/experiment: hami
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-pilot-quota
  namespace: gpu-sharing-pilot
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 32Gi
    limits.cpu: "16"
    limits.memory: 64Gi
    EXAMPLE_HAMI_RESOURCE: "4"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-canary
  namespace: gpu-sharing-pilot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: inference-canary
  template:
    metadata:
      labels:
        app: inference-canary
    spec:
      containers:
        - name: workload
          image: YOUR_GPU_IMAGE:TAG
          command: ["sh", "-c", "exec YOUR_INFERENCE_COMMAND"]
          resources:
            requests:
              cpu: "1"
              memory: 2Gi
              EXAMPLE_HAMI_RESOURCE: "1"
            limits:
              cpu: "2"
              memory: 4Gi
              EXAMPLE_HAMI_RESOURCE: "1"

需要修改三个位置：

将 EXAMPLE_HAMI_RESOURCE 替换为当前 HAMi 安装实际暴露的资源键；
将 YOUR_GPU_IMAGE:TAG 换成经过验证的 GPU 工作负载镜像；
将 YOUR_INFERENCE_COMMAND 换成能够持续输出延迟、吞吐量和错误率的测试命令。

应用前先让 API Server 做服务端校验：

kubectl apply --server-side --dry-run=server -f hami-pilot.yaml
kubectl apply -f hami-pilot.yaml
kubectl -n gpu-sharing-pilot get pods -o wide
kubectl -n gpu-sharing-pilot describe pod -l app=inference-canary

试点应至少覆盖独占基线、两个共享任务并发、显存压力、任务退出后资源回收，以及节点重启这几种场景。不要只观察平均吞吐量；共享环境中的 P95/P99 延迟和显存不足错误往往更能暴露隔离问题。

上线前的边界与检查项

HAMi 成为 CNCF 孵化项目，为 GPU 共享调度提供了更强的社区与治理信号，但生产采用仍应分阶段推进。

从非关键推理或开发环境开始，保留独占 GPU 作为对照组；
固定并记录 Kubernetes、HAMi、驱动和容器运行时版本；
同时采集资源申请量、设备利用率、显存占用和业务延迟；
为训练任务、在线推理和开发任务建立不同的共享策略；
验证资源超卖、节点故障和组件升级时的行为；
确认多租户场景中的安全边界与性能干扰是否符合要求；
用排队时间和单位任务成本评估收益，而不是只看 GPU 使用率峰值。

这次进入 CNCF 孵化阶段，值得平台团队重新评估 GPU 调度方案。更稳妥的采用路径不是立刻扩大共享比例，而是先建立可观测基线，用受控试点证明资源碎片确实减少，同时业务延迟、稳定性和隔离水平没有越过红线。