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

前言

在越来越多的 AI 推理与训练场景中，华为昇腾（Ascend）已成为重要的算力选择。但在很长一段时间里，Kubernetes 体系中围绕 AI 加速器的调度与共享能力，主要还是以 NVIDIA GPU 为中心展开。

这带来的直接问题是：

• 调度模型默认以整卡独占为前提

• 资源抽象粒度偏粗

• 昇腾设备难以被纳入统一、细粒度的调度体系

在真实的昇腾集群中，这种差距会被进一步放大。

一方面，在 Embedding、Rerank、轻量推理等场景下，单个任务对算力和显存的需求并不高，但由于缺乏 vNPU 级别的资源建模，任务只能以整卡方式被分配，导致设备利用率长期偏低。

另一方面，当集群进入多团队、多任务并行阶段，如果没有显式的算力和显存上限约束，调度很容易退化为：谁先调度上去，谁就把设备“吃满”。而一旦资源被占满，调度层面往往只剩下一句熟悉的提示：no available node

昇腾设备“能跑任务”，但不好管、也不好算。这正是昇腾在 Kubernetes 里长期面临的核心问题：不是缺算力，而是缺一套真正理解设备使用边界的调度能力。

而这，正是 Volcano 与 HAMi 协作补齐昇腾调度能力的现实背景。

Volcano × HAMi，让昇腾进入“可调度、可共享”阶段

要真正解决昇腾在 Kubernetes 中“能跑但不好管”的问题，关键并不在于更换更大的设备，而在于调度体系是否真正理解设备的使用边界。

分工协作：Volcano 负责调度，HAMi 负责设备管理

在昇腾 vNPU 的调度体系中，Volcano 与 HAMi 并不承担相同职责，而是分别聚焦于调度策略与设备抽象两个层面：Volcano 负责“任务如何被调度”，HAMi 则提供“设备如何被安全拆分与约束”的能力。

Volcano：面向异构算力的批量调度器

Volcano 是 CNCF 官方接纳的批量调度项目，长期服务于 AI / 大数据 / HPC 等资源密集型负载。

Volcano 将在下个版本正式支持 Ascend 310 与 Ascend 910 的 vNPU 能力，并且可以统一管理 Ascend 集群，例如：

• Ascend 910A / 910B2 / 910B3

• Ascend 310P

• 多型号混合部署的昇腾集群

在 Volcano 的调度模型中，昇腾不再只是 “一个节点上的特殊设备”，而是被纳入统一的资源调度体系。

但要让这种调度真正落地，前提是：昇腾设备本身，必须具备可被调度器理解的资源抽象能力。

HAMi：提供昇腾 vNPU 的软件层能力

在这一能力背后，真正让调度“可行”的，正是 HAMi 提供的软件层设备抽象能力。

通过 使用 HAMi 提供的 ascend-device-plugin，可以将昇腾设备的使用方式显式化为：

• vNPU 实例数量

• 显存使用上限

• 设备几何与拓扑信息

这些信息被注入 Kubernetes 与 Volcano，使调度器第一次能够基于 “需要用多少”来做决策，而不仅仅是“有没有设备”。

至此，昇腾设备第一次进入了“可拆分、可约束、可调度”的状态。

当这些能力在调度器与设备层面就绪后，用户侧的使用方式反而变得非常简单。

如何启用：

启用 Ascend vNPU 调度

d vNPU 调度启用 Ascend vNPU 调度

在 Volcano 调度器中启用 Ascend vNPU 能力：

deviceshare.AscendHAMiVNPUEnable: true

并通过 部署HAMi社区下的ascend-device-plugin 将昇腾设备能力注册到集群中。

具体可以参考文档：https://github.com/volcano-sh/volcano/blob/master/docs/user-guide/how_to_use_vnpu.md

Pod 显式声明昇腾资源边界

业务侧只需要在 Pod 中声明所需的昇腾资源，例如：

apiVersion: v1
kind: Pod
metadata:
  name: ascend-pod
spec:
  schedulerName: volcano
  containers:
    - name: ubuntu-container
      image: swr.cn-south-1.myhuaweicloud.com/ascendhub/ascend-pytorch:24.0.RC1-A2-1.11.0-ubuntu20.04
      command: ["sleep"]
      args: ["100000"]
      resources:
        limits:
          huawei.com/Ascend310P: "1"
          huawei.com/Ascend310P-memory: "4096"

这段配置表达的含义非常清晰：

我需要 1 个 Ascend 310P 的 vNPU， 并且最多使用 4GB 显存。

调度器据此做决策，并且在运行时由 HAMi 保证资源隔离。

适合哪些场景？

这套基于 Volcano 与 HAMi 的昇腾 vNPU 调度方案，尤其适合：

• Ascend 310 / 910 推理集群

• 多模型并发的推理平台

• 多团队共享昇腾资源的 Kubernetes 集群

• 教学、测试、实验环境

• 设备紧张但单任务资源占用不高的场景

总结

当 Volcano 与 HAMi 在昇腾集群中协同工作之后，变化往往并不止体现在“能跑更多任务”。

在资源利用率层面，一张昇腾卡可以承载多个轻量任务，小模型不再被迫独占整卡，从而使得设备利用率显著提升。

在治理与运维层面，昇腾资源首次进入显式配额体系，并且调度失败原因更加可解释，多团队、多任务的边界更加清晰。

昇腾设备不再是“谁先上谁用”，而是进入了一个：可约束、可统计、可审计的云原生资源体系。

特别感谢

Volcano 中的 Ascend vNPU 能力落地，离不开开源社区的持续协作。这次开源协作实践的相关能力依托 HAMi 项目持续演进，通过 ascend-device-plugin将昇腾设备的虚拟化与调度能力引入 Kubernetes 与 Volcano 体系。

在这一过程中，来自不同背景的参与者围绕同一个技术目标展开协作：

HAMi Maintainer 李孟轩（密瓜智能）联合 HAMi 社区贡献者 James（第四范式），以及复旦大学学生 杨特，围绕昇腾设备在真实 Kubernetes 集群中的使用场景，共同参与了相关能力的设计、实现与持续演进，并最终以开源的方式，将相关能力沉淀到 HAMi 与 Volcano 社区中。

正是来自企业、高校在开源社区的持续协作，使昇腾相关能力得以在真实集群中不断验证、打磨与完善，并逐步走向稳定可用。

HAMi 与 Volcano 的演进并非某一个团队或组织的单点成果，而是开源生态持续协作的结果。我们也期待有更多开发者加入到 HAMi 社区中。

参考资料：

1.https://github.com/Project-HAMi/HAMi/blob/master/docs/how-to-use-volcano-ascend_cn.md

2.https://github.com/Project-HAMi/HAMi/blob/master/docs/how-to-use-volcano-ascend.md

3.https://github.com/volcano-sh/website/pull/430/files

---

上海密瓜智能科技有限公司专注于异构算力调度与统一管理，致力于为全球客户提供高效、灵活的算力解决方案。公司以“让异构算力因开源而好用”为使命，愿景是“构建全球领先的算力调度生态，赋能AI产业高效落地”。发起的CNCF 开源项目 HAMi，是唯一专注异构算力虚拟化的开源项目，通过灵活、可靠、按需、弹性的 GPU 虚拟化提升资源利用率，助力AI 时代算力效率提升。

官网：https://dynamia.ai

邮箱：info@dynamia.ai