HAMI 入门必知：新手必读的 9 个关键问题
前言
🚀告别 GPU 资源管理困境，HAMI 助你掌控异构集群
您是否正面临以下挑战？
- GPU 资源利用率低下：昂贵的 GPU 设备时常闲置，投资回报率难以提升？
- 异构设备难管理：集群中存在 NVIDIA、昇腾等多种算力设备，管理协调难度倍增？
- 资源分配和使用状况“黑箱”：无法实时掌握集群 GPU 资源分配和使用情况，优化无从下手？
HAMI 专为解决以上痛点而生！它专注于 GPU 共享与隔离，完美支持包括 NVIDIA、昇腾在内的异构算力设备，并配合 HAM-WebUI 可视化管理平台，助您大幅提升算力资源利用率，简化异构集群管理，实现集群资源分配和使用状况的可视化。
为了让您快速了解 HAMi 的核心价值和使用方法，我们精心打造了这篇《HAMi 入门必知：新手必读的 9 个关键问题》，让我们从社区常见的 9 个关键问题出发，扫清入门障碍，轻松应对异构算力资源管理挑战！
问题一：HAMI 支持哪些"硬件搭子"？
问题二：什么是 vGPU？为什么明明看到 10 个 vGPU，却不能在一张卡上“多开”？
简单来说：
- vGPU 不是“虚拟的显卡”，而是“显卡的虚拟视图”！
devicesplitcount: 10指的是一张物理 GPU 最多可以被 10 个任务“看到”和“共享”，而不是在一个任务里申请多个 vGPU。
更详细地解释：
- vGPU 是同一张物理 GPU 的不同任务视图，它们共享的是底层的物理资源，而不是独立的物理分区。
- 当你申请
nvidia.com/gpu: 2时，系统会理解为你需要两个物理 GPU 才能满足需求，而不是同一张 GPU 的两个 vGPU。 - 资源分配机制决定了 vGPU 的用途：多任务共享一张卡，而不是“单任务独占一张卡的多个视图”。
- 容器内看到的 GPU UUID 和物理节点上的 UUID 一致，也证明了 vGPU 只是逻辑上的超配视图，而非实际上的独立的资源。
总而言之，vGPU 超配的意义在于提高 GPU 的整体利用率，让更多任务可以“雨露均沾”，而不是为了增加单个任务的资源。
问题三：HAMI 可以和哪些“开源搭子”联动？
目前支持的“搭子”有：
- Volcano：可以与 Volcano 联动，但需要使用 HAMI 项目下的
volcano-vgpu-device-plugin来支持 GPU 的资源调度和管理。Volcano 是一个 K8s 原生的批调度系统。与 HAMI 结合，可以实现更高效的 AI 任务调度。
目前暂不支持的“搭档”有：
- KubeVirt & Kata Containers：这两者都使用虚拟化技术隔离资源，而 HAMI 的 GPU Device Plugin 依赖直接挂载 GPU 到容器的机制，与虚拟化层的设备分配（如 PCI Passthrough 或 Virtio）存在架构上的不兼容。虽然技术上存在适配的可能性，但考虑到性能开销和实现复杂度，HAMI 目前聚焦于直接挂载 GPU 的高性能场景，因此暂未支持虚拟化方案。
问题四：分布式训练“势在必行”HAMI 支持多机多卡分布式训练吗？支持跨主机和跨卡吗？
在 AI 训练领域，单机单卡往往难以满足大型模型的资源需求，分布式训练成为提升训练效率的“必选项”。那么，HAMI 能否胜任分布式训练的重任呢？
当然可以！HAMI 完美支持多机多卡分布式训练。
- 多机多卡：通过 K8s 调度多个 Pod 到不同节点，每个 Pod 使用自己的 GPU 资源，并通过分布式计算框架（如 PyTorch、TensorFlow、Horovod 等）实现跨主机和跨卡的协作。
- 跨主机：多个 Pod 运行在不同节点上，节点间通过高性能网络（如 NCCL 或 RDMA）进行高效通信，同步梯度和更新参数。
- 跨卡：单个 Pod 可以使用同一节点上的多个 GPU，并行计算，加速训练过程。
不支持“单 Pod 跨主机”的场景：
- K8s 的设计原则：Pod 必须运行在单个节点上，无法跨多个机器分布。
- HAMi 的实现方式：HAMi 目前不是远程调用算力的方案。
- 解决方案：如果需要跨主机资源协作，应该采用多 Pod 分布式训练模式，由分布式框架协调跨主机的任务执行。
问题五：GPU 资源能“说变就变”吗？HAMI 支持动态调整 GPU 资源吗？
在某些场景下，我们可能希望在 Pod 运行过程中动态调整 GPU 资源，例如从无卡到有卡，或者动态调整算力、显存。HAMI 能满足这种需求吗？
暂不支持真正的“动态调整”。
原因分析：
- 底层原理限制：容器的 GPU 资源分配，在启动时就是静态的。K8s 的设计原则也是声明式资源管理，这种规范性保证了 K8s 资源管理的可预测性和可维护性。
- K8s 框架的限制：虽然 K8s 社区也在探索资源动态调整的可能性（例如 InPlacePodVerticalScaling 特性），但目前仅支持 CPU 和内存的动态调整。GPU 等设备资源的动态调整仍然面临挑战。
- 资源透明性问题：任何在 Pod 创建后调整资源的方案，都会降低 K8s 的资源透明度。
未来展望：
- 如果“动态限制算力显存”的需求特别强烈，HAMI 可以考虑在“程序行为限制”方面做更多尝试。
- 但在 K8s 框架内实现真正的 GPU 资源动态调整仍然是一个长期目标，需要社区的共同努力。
这里有人会问 DRA（Dynamic Resources Allocation），或许名字有点误导性，让人觉得是原地的，实时的。DRA 只是想让 K8s 能理解和管理其他一些参数更复杂更不标准的资源、用来支持一些异构设备，不是提供即时的资源调整能力。
问题六：Device Plugin 五花八门？为什么有的 DP 用户商的，有的是 HAMI 自己实现的？
在 Device Plugin 的实现上，不同厂商也展现出不同的技术路线。有的厂商会直接使用官方提供的 Device Plugin，有的则会自己实现。这又是为什么呢？
为什么有的国产厂商安装时不需要 Runtime：
- 国产厂商“All-in-one”策略：有些国产厂商（如天数智芯、海光、寒武纪）的 DevicePlugin 已经“身兼数职”，直接完成了设备发现和挂载等功能。因此，不需要额外的 Runtime 来辅助。
- NVIDIA 和昇腾采用“分工协作”模式：NVIDIA 和华为均采用“分工协作”模式。Device Plugin 专注于资源上报和分配，Runtime 则负责环境配置、设备节点挂载和高级功能支持。这种模式更加模块化，职责更清晰。
为什么有的 Device Plugin 用官方的，有的需要 HAMI 自己实现的：
- 官方 Device Plugin 的“局限性”：官方的 Device Plugin 所提供的资源信息可能“不够用”，无法满足 HAMI 某些高级特性的需求，或者官方 Device Plugin 的接口设计，会给 Scheduler 的适配带来额外的复杂度。
- HAMI“自力更生”的必要性：为了灵活地控制 Device Plugin 的行为，获取更丰富的资源信息，简化 Scheduler 的适配工作，HAMI 选择“自力更生”，自己实现了同卡不同分 Device Plugin。
举例说明：
-
昇腾官方的 Device Plugin：每种卡类型都需要对应的 Device Plugin 管理复杂。于是，HAMi 抽象出各种卡类型的切分模版，自己实现了一个 Device Plugin 来处理不同卡不同模版的情况，方便与 Scheduler 进行协同。
-
NVIDIA 官方的 Device Plugin：提供的资源信息有限，HAMi 为了实现更多更高级特性（如算力显存限制、超配、NUMA 感知等），需要更多资源信息，因此也需要自己实现 Device Plugin。
总结：选择 Device Plugin 的实现方式，取决于厂商的技术路线、对功能和灵活性的权衡、以及与 K8s 生态的集成策略。HAMi 在 Device Plugin 的实现上，也是根据自身的需求和目标，做出了最优的选择。
问题七：vGPU 切分数量失效？算力显存“刹不住车”？如何排查？
- 切分数量失效：可能因为安装了 NVIDIA 官方 Device Plugin 或 devicePlugin.deviceSplitCount 设置不当；
- 算力未限制：需添加 GPU_CORE_UTILIZATION_POLICY=force，否则单卡上仅一个容器时算力不限制；
- 显存未限制：可能因特权模式或容器内自带环境变量 NVIDIA_VISIBLE_DEVICES=all；
- 解决建议：排查插件冲突、调整环境变量。
⚠️关于算力限制：比如限制 50% 算力，某一时刻显卡的算力使用率是有可能大于 50%，但是长期来看该任务的平均算力使用会是在 50%
问题八：GPU Pod 里执行 nvidia-smi 怎么没有进程信息？
PID Namespace 隔离机制，导致容器内 nvidia-smi 看不到进程信息。如果需要查看 GPU 进程，可关闭 PID Namespace 隔离（设置 hostPID=true），但务必注意这会带来安全风险。请谨慎使用。
问题九：HAMI 未来“进化”路线图？下一代版本规划前瞻
HAMI 项目始终在不断演进和完善。在即将到来的几个版本中，我们将重点关注以下几个关键方向，为用户带来更强大、更易用、更智能的 GPU 资源管理体验：
核心技术升级：全面拥抱 DRA（Dynamic Resources Allocation）
- 实现 HAMi DRA Driver：全面拥抱 K8s 原生 DRA 框架，开发 HAMI DRA Driver，将 HAMI 的 GPU 虚拟化和资源管理能力迁移到 DRA 框架下。
WebUI 全面重构：打造更强大、更易用的可视化管理平台
- 支持国际化（i18n）与多主题（Dark Mode）
- 增强对更多异构设备的支持（如 Ascend）的抽象能力，降低接入成本
- 更全面的监控指标，并支持 iframe 嵌入
更丰富的功能扩展（部分功能可能在后续版本中实现，具体计划以实际发布为准）：
- 配置得更细：支持紧凑/均衡调度策略（节点/显卡维度），节点超配比，节点使用模式（如 hami-core，mig，mps）和显卡 filter 等配置，提供更丰富的调度策略的调整操作，例如 节点紧凑调度（尽量将 Pod 调度到资源利用率高的节点）和 显卡均衡调度（尽量将 Pod 均匀分配到各个显卡），满足不同场景下的调度需求。
- 虚拟机监控管控：将虚拟机纳入 HAMI 的监控范围，并通过特殊的标记区分集群内部节点和集群外部虚拟机，实现对更广泛的计算资源的统一运营。
- 多集群统一仪表板：构建多集群统一仪表盘，集中展示和统计多集群的 GPU 资源分配和使用情况，方便用户进行跨集群的资源管理和优化。
- 快捷 YAML 生成：可视化 YAML 生成工具，用户可以通过勾选选项，填写参数等方式，快速生成符合需求的 K8s YAML 清单。例如，用户可以通过 WebUI 勾选“节点离散调度”、“指定显卡调度”等选项，即可一键生成包含对应 Annotation 的 Deployment YAML。