HAMi：可声明共享的虚拟化数据平面
让 GPU 共享成为可声明、可治理的工程能力，而非“能跑就行”的经验主义。
HAMi 的一句话定位
HAMi 是一个面向 Kubernetes 的 GPU 虚拟化与切分数据平面。它致力于将“GPU 共享”从经验主义的“能跑”提升为工程语义上的“可声明、可调度、可治理”。HAMi 的核心并非重写调度器，而是将 GPU 的可用资源单位从“整卡整数”扩展为“可切分的份额（core/memory 等）”，并将这些份额暴露为 Kubernetes 可理解的资源请求与分配路径。
为什么 HAMi 必须出现在数据平面
Kubernetes 对设备类资源的默认语义是“整数、不可超卖、调度时做计数”。这套模型非常适合网卡、FPGA、整卡 GPU，但对于可共享、可切分且隔离与干扰复杂的 GPU，会自然推向两种极端：
- 要么继续整卡分配，把利用率问题交给业务侧自己排队；
- 要么把共享做成容器内自觉，但无法声明与治理，难以实现队列、配额、优先级等上层策略闭环。
HAMi 的选择是：在不要求应用改代码的前提下，将“共享”做成数据平面能力，并把更细粒度的资源表达暴露为 Kubernetes 可调度资源。
组件视图：HAMi 是一条“分配链路”
理解 HAMi 最好的方式，是将其视为一条从“声明”到“生效”的分配链路。典型链路可拆为四层（实现细节随版本演进，但职责基本稳定）：
在介绍各层职责前，先说明：每一层都围绕资源声明、调度、兑现与观测展开，形成完整的治理闭环。
下图概括 HAMi 从声明到兑现的分配链路与治理闭环。
HAMi 分配链路示意图：展示从节点侧发现与汇报、调度侧绑定与落位、容器内资源控制到观测与计量的完整四层架构。每一层都围绕资源声明、调度、兑现与观测展开，形成完整的治理闭环。Device Plugin 负责声明，Scheduler 负责落位，容器内控制层负责兑现，监控负责将兑现程度转化为可运营数据。
节点侧发现与汇报（Device Plugin 侧）
- 负责发现 GPU，并将“可分配资源”汇报给 Kubelet/调度器可见的资源视图。
- 与默认整卡模型相比，HAMi 会把物理 GPU 映射为可被多 Pod 共享的更细粒度资源单元，并暴露相应资源名（如 core / memory 维度）。
调度侧绑定与落位（Scheduler 扩展/策略侧）
- 负责将“请求”落到具体哪张卡、哪类卡、哪组份额。
- 关键在于将拓扑、碎片、同卡干扰等数据平面约束转化为调度可见的约束条件。
容器内资源控制（HAMi-core / vGPU 控制层）
- 负责让“声明的份额”在容器内尽可能生效。例如对 core 份额采用 time-slicing 实现配额效果，并解释为何在
nvidia-smi里看到的利用率会波动。 - 工程实现上，通常通过拦截 CUDA Runtime 与 Driver 之间的调用链路实现控制与计量（产物多以注入动态库形式出现）。
观测与计量（vGPUmonitor / metrics 导出）
- 负责将“共享后到底谁占了多少”转化为 Prometheus 可抓取的指标，形成治理闭环的基础数据。计量缺失意味着无法计费、无法做容量评估，也无法做 SLO。
你可以将这条链路概括为：Device Plugin 负责声明，Scheduler 负责落位，容器内控制层负责兑现，监控负责将兑现程度转化为可运营数据。
资源表达：从"整卡"到"可声明共享"的关键语义
HAMi 的工程收益，核心在于引入了更细粒度的资源表达方式，使 Kubernetes 调度与上层控制面能够"看到"你真正需要的资源。
HAMi 资源表达示意图：对比传统整卡分配模型和 HAMi 可声明共享模型，展示如何通过 GPU 份额（虚拟 GPU/slice）、Core 份额（nvidia.com/gpucores）和 Memory 份额（nvidia.com/gpumem）实现显存与 core 份额可声明，使"同卡复用"更可控。图中还包含 Pod 资源声明示例 YAML。
典型做法是让 Pod 在资源请求里同时声明：
- GPU 份额（虚拟 GPU / slice）：让一张物理卡可被多个 Pod 分配。
- core 份额（如
nvidia.com/gpucores）：用 time-slicing 近似实现计算份额控制。 - memory 份额（如
nvidia.com/gpumem）：将“显存第一约束”显式化，避免仅按整卡计数导致的资源错配与碎片放大。
这里有一个重要边界需明确：“可声明”不等于“强隔离”。HAMi 在 core 维度更接近“可控的时间片分配”；在显存维度则更接近“配额化的分配与失败策略（超额时的表现）”。因此，HAMi 提供的是“比整卡更强的治理语义”，而非类似 MIG（Multi-Instance GPU, Multi-Instance GPU）那样的硬切分级别隔离。
关键取舍：HAMi 解决的是“运营问题”，不是“物理隔离问题”
从工程视角看，HAMi 的核心价值不在于“能否共享”，而在于是否让以下问题具备可操作性：
可声明：把共享从“隐性行为”变成“显式契约”
有了契约，才有治理。HAMi 的资源表达让你能在 YAML 里明确声明：需要多少 core、多少显存、是否允许与别人同卡。
可调度：把碎片与落位变成系统责任
资源单位变细后，碎片必然增多。HAMi 的价值之一，是让“碎片管理/落位策略”进入调度责任域，而非留给业务侧碰运气。
可观测：共享后的 P99 才是问题本体
GPU 共享的难点不在平均吞吐，而在尾延迟与抖动。HAMi 通过监控与计量组件，将共享后的使用情况导出为指标，为后续“验收与容量”章节铺路。
可协同：为 Volcano/Kueue 提供“可用的资源语义”
Volcano/Kueue 解决队列、配额、公平性、优先级、准入与抢占等控制面问题；HAMi 解决“节点 GPU 能怎样切分、切完如何落位、如何兑现”的数据平面问题。两者叠加，才能形成完整的 GPU 资源运营系统。
适用场景与反模式
在实际应用中，HAMi 更适合以下场景：
- 多租户推理、批量小模型推理：显存与 core 份额可声明，使“同卡复用”更可控。
- 研发/测试/POC 环境：需要快速提升 GPU 利用率，并积累计量与基线数据。
- 平台化团队：可将 HAMi 语义与企业内部队列/配额体系打通，形成治理闭环。
需要谨慎的场景或需额外验收门槛：
- 强隔离/强确定性 SLO 的关键在线业务：如需接近物理级隔离（尤其尾延迟敏感），建议优先考虑 MIG 或整卡池化。
- 对驱动/运行时链路极其敏感的生产环境：任何“容器内拦截/注入”方案都要求完善升级验证、兼容性矩阵与故障回滚机制。
如何把 HAMi 放进本书的“决策轴”
你可以用以下结论，将 HAMi 快速回填到“决策轴矩阵”中（后续实验章节会用数据验证）：
- 资源单位：从整卡扩展到 core/mem 份额与共享 slice。
- 隔离强度：总体偏“软隔离/工程约束”，非硬切分。
- 动态调整成本：通常低于 MIG（无需重切分设备），但依赖控制链路与策略配置成熟度。
- 性能与干扰：平均吞吐通常可接受，关键在 P99 与干扰控制，需要用 Lab 体系验收。
- 可观测与计量：具备导出指标的路径，是实现运营闭环的重要加分项。
- 兼容性/侵入性：对应用代码侵入低（无需改代码），但对运行时/驱动链路与运维流程有要求。
总结
HAMi 的本质是将 GPU 共享变成工程语义的虚拟化数据平面。它让资源可以被声明、调度、计量，从而让控制面（如 Volcano、Kueue）有机会将队列、配额、优先级等治理能力落到 GPU 这一类复杂资源上。HAMi 并不承诺 MIG 级别的强隔离，而是用更低的重配置成本与更强的运营语义，换取更高的整体利用率与可治理性。
下一章“生态放置”将把 HAMi、MIG、Volcano、Kueue 及典型推理/训练栈放入同一张拼装图，明确每一层的职责，避免“用数据平面能力替代控制面治理”的常见误区。