第四范式:HAMi 设备插件新功能介绍

作为一个活跃的开源项目，HAMi 由来自 16+ 国家、360+ 贡献者共同维护，已被 200+ 企业与机构在实际生产环境中采纳，具备良好的可扩展性与支持保障。

在国产算力规模快速增长的背景下，越来越多的团队开始在集群中接入昇腾等设备。但在默认使用方式下，这类设备通常以整卡独占形式运行，资源抽象粒度较粗，难以纳入统一的调度体系，从而导致整体资源利用率不高。

另一方面，部分设备插件在向 Kubernetes 注册资源时，仅上报设备数量，未包含显存、算力等关键指标。这种资源表达方式会影响资源监控、容量规划以及调度决策，使平台侧难以进行统一管理。在显存容量较大的场景下，还可能出现资源值注册后显示异常的问题，进一步影响资源模型的准确性。

在此背景下，第四范式平台工程师 James在本次分享中介绍了 HAMi 与 Volcano 的集成方式，以及在设备能力补齐与资源注册方面的实现思路和实践细节。

James HAMi Meetup 北京站分享

HAMi 与 Volcano 的插件式集成

Volcano 作为 CNCF 体系内面向高性能计算与批调度场景的项目，提供了队列、调度策略与资源管理等能力。在该方案中，HAMi 的设备调度能力通过插件方式集成进 Volcano，使其能够同时支持英伟达与华为昇腾等不同类型的加速设备。

在实现层面，引入了 HAMi Ascend device 模块。该模块在初始化阶段读取设备型号、显存大小和卡数量等信息，并根据资源申请情况选择合适的设备进行分配；在分配完成后，再将相关信息反馈给 Kubernetes，使上层调度与资源管理系统能够感知设备的实际分配结果。

在使用方式上，用户只需在 YAML 配置中开启 HAMi 的 GPU 共享能力并选择相应策略；在资源申请时，仅需指定设备类型，例如 NVIDIA GPU 或 Ascend 310P 和 910 系列设备。在昇腾场景下，资源申请将匹配至合适的模板级别。

设备资源补齐与注册策略

在设备能力补齐方面，方案引入了 Device Resource Padding 机制。该机制通过读取节点上的设备信息，将显存、算力等关键资源补充注册到 Kubernetes 中，并将 NVIDIA、昇腾以及海光 DCU 等设备按照型号分别映射到一套统一的资源标识命名体系中，便于调度器与上层系统统一使用。

针对“超大显存注册后显示为 0”的边界问题，方案中进一步引入了 Scale Factor 机制：在资源注册阶段按比例缩放资源值，在资源申请阶段再按相同比例进行换算。该方式可用于规避显示限制，但同时会影响 limit、quota 等相关配置，因此在使用前需要进行整体评估。