昇腾 vNPU：驱动硬切分与运行时软切分
昇腾生态把 GPU 世界里“硬件切分还是软件共享”的路线之争，在同一厂商内部重演了一遍，而且给了两个软件答案：一个来自华为自己，一个来自 HAMi 社区。
本章要解决什么
前面几章建立了数据平面谱系，并用它分析了 MIG（硬件切分）、HAMi（软件共享）和 DRA（资源分配 API）。这些分析都以 NVIDIA 生态为主。本章把同一组决策轴应用到昇腾（Ascend）NPU 生态，回答六个问题：
- 昇腾为什么叫 NPU？它的芯片谱系经历了怎样的演进，各代产品对应哪些芯片？
- NPU 与 NVIDIA GPU 在架构和生态上有何本质差异，这些差异如何决定“能切什么”？
- 昇腾官方的 vNPU 虚拟化到底是什么机制，隔离边界在哪里？
- 华为 2026 年推出的官方软切分（vCANN-RT）与 HAMi 的 libvnpu 是什么关系？
- 在 Kubernetes 里，Volcano 的 MindCluster 模式与 HAMi 模式有何区别，HAMi 对各代芯片的支持到什么程度？
- 一个真实的推理集群应该怎么选？
结论先行：昇腾生态当前存在三条可用的 vNPU 路径，它们在数据平面谱系上的位置如下图。驱动硬切分对应 NVIDIA 世界的 MIG，官方软切分 vCANN-RT 与 HAMi 软切分共同对应“HAMi 式运行时拦截”，三者共享同一套底层注入设施（Ascend Docker Runtime 与 ld.so.preload）。
昇腾谱系：从 310/910 到 910C
先厘清命名体系：昇腾（Ascend）是芯片品牌，覆盖推理与训练；Atlas 是硬件产品品牌（模块、板卡、服务器、集群）；软件栈是 CANN（Compute Architecture for Neural Networks，对标 CUDA）加框架 MindSpore，再往上是一直到 2024 年还叫 MindX DL、后来归一为 mind-cluster 的集群组件。所以“昇腾 310P3”是芯片，“Atlas 300I Duo”是用这颗芯片（的两颗）做成的推理卡。
芯片与产品的大事记：
| 时间 | 芯片与产品 | 定位与要点 |
|---|---|---|
| 2018-10 | 昇腾 310 发布（HC2018） | 12nm 达芬奇 Lite 架构 SoC，面向边缘与推理；同场预告 910 |
| 2019-08 | 昇腾 910 商用 | 7nm，32 个达芬奇 Max 核心，FP16 256 TFLOPS、INT8 512 TOPS；同场发布 MindSpore |
| 2019 至 2020 | 出口管制 | 华为 2019 年 5 月被列入美国实体清单，2020 年外国直接产品规则进一步限制先进制程代工，直接重塑了后续路线 |
| 2020 至 2022 | 910A 世代、310P 世代 | 910A 用于 Atlas 800 训练服务器；2022 年 310P 系列落地：Atlas 300I Duo（双芯，280 TOPS INT8，96GB LPDDR4X）与 300I Pro（单芯 140 TOPS，24GB），推理主力 |
| 2023 | 910B 家族与 Atlas A2 整机 | 910B1/B2/B3/B4/B4-1 等型号；Atlas 800T A2 训练服务器（8 颗 910B）、800I A2 推理服务器（910B4）、300I A2 推理卡，整体对标 A100 世代 |
| 2025 | 910C 与超节点 | 910C 采用双 die 封装（约 800 TFLOPS FP16）；CloudMatrix 384 超节点以 384 颗 910C 组成紧耦合逻辑节点，实现全域可寻址的统一内存池；9 月发布三年路线图 |
理解这张表对选型很关键：vNPU 能力只存在于推理形态的芯片上。310P 系列（300I Duo、300I Pro）与 910B4 代推理（300I A2、800I A2）有驱动切分模板；训练卡（910A、910B2/B3）没有。910C 目前以超节点整卡调度为主，HAMi v2.9.0 为其 SuperPod 场景加入了模块对分配，但同样没有切分模板。
从 GPU 到 NPU：架构与生态差异
为什么叫 NPU
NPU（Neural-network Processing Unit，神经网络处理器）这个名字传达的是领域专用：整颗芯片为张量计算设计，而不是像 GPU 那样从图形处理演化成通用并行处理器。GPU 的计算主力是流式多处理器里的 SIMT CUDA Core 加 Tensor Core；昇腾 NPU 采用达芬奇（Da Vinci）架构，每个 AI Core 由三部分组成：
- Cube 单元：专用矩阵乘引擎，一个时钟周期完成固定规模的乘加阵列，是卷积与 GEMM 的绝对主力
- Vector 单元：激活函数与逐元素运算
- Scalar 单元：标量与控制逻辑
AI Core 之外还有两类“陪跑”单元：AI CPU 承接未被 AI Core 加速的算子，DVPP 媒体引擎负责图像编解码。连管理工具的命名都在强调差异：NVIDIA 是 nvidia-smi，昇腾是 npu-smi。
| GPU（NVIDIA） | NPU（昇腾） | |
|---|---|---|
| 定位 | 通用并行处理器，图形血统 | 面向神经网络的专用处理器（达芬奇架构） |
| 计算单元 | 流式多处理器：SIMT CUDA Core 加 Tensor Core | AI Core：Cube 矩阵引擎加 Vector 加 Scalar |
| 算子兜底 | CUDA 库，跑在同样的核心上 | AI CPU，与 AI Core 并列的独立单元 |
| 媒体引擎 | 编解码模块，不是 MIG 的切分维度 | DVPP 引擎，vNPU 模板的显式切分维度 |
| 显存 | GDDR 或 HBM | 310P 用 LPDDR4X，910B 起用 HBM |
| 芯片间互连 | NVLink 与 NVSwitch | HCCS；910C 超节点升级为统一总线与统一内存 |
| 软件栈 | CUDA（加上十余年的库与工具积累） | CANN、MindSpore、MindIE，兼容 PyTorch（torch-npu） |
生态差异是比算力更深的鸿沟
CUDA 生态是 NVIDIA 真正的护城河：算子库、调试器、profiler、框架后端经过十余年积累。昇腾的对策是 CANN 提供 aclRuntime 与算子库，通过 torch-npu 适配 PyTorch 生态，同时自研 MindSpore 与推理引擎 MindIE。实际工程里这意味着两点：模型迁移需要验证算子覆盖与精度（部分算子会落到 AI CPU 上拉低性能），版本配套也更严格（驱动、CANN、框架、容器镜像常常要求成对匹配，本书实验中 libvnpu 与驱动版本必须匹配就是同一逻辑的缩影）。
差异如何决定“能切什么”
把架构差异投影到虚拟化上，就能解释两条生态各自的切分维度：
- NVIDIA 的 MIG 切的是 SM 与显存（连同 L2 缓存），编解码引擎不在切分维度里。
- 昇腾的驱动模板切的是 AI Core、AI CPU、显存、DVPP 四个维度，模板名直接编码了切法：
vir04_3c_ndvpp表示 4 个 AI Core、3 个 AI CPU、不含 DVPP。 - 软切分同理：GPU 侧拦截 CUDA 调用（HAMi 的
libvgpu.so），NPU 侧拦截 CANN/DCMI 调用（libvnpu.so与libvruntime.so）。
本章真机验证用的 310P3 报告 8 个 AI Core、7 个 AI CPU、21525 MB 可见显存。这组数字就是 vNPU 世界的“切分库存”：模板 vir01 到 vir04 分配 1 到 4 个 AI Core，HAMi 配置里的 aiCore、aiCPU、memoryAllocatable 字段对应的也是同一份清单。
什么是 vNPU
vNPU（虚拟 NPU）是 NPU 世界里的 vGPU：一张小于物理卡的逻辑 NPU，容器拿到它就像拿到一整颗设备。它有两种诞生方式，这个区别正是本章的主线：由昇腾驱动把硬件静态分区成模板大小的 vNPU（硬切分），或者由运行时拦截库在用户态改写设备视图并按容器强制配额（软切分）。下面依次展开三条路径。
路径一：驱动级模板硬切分
机制：模板就是静态分区表
昇腾驱动（npu-smi）提供 vNPU 切分能力：按“虚拟化实例模板”把一张物理 NPU 的 AI Core、AI CPU、显存和编解码引擎（VPC/VENC/VDEC/JPEGD/JPEGE/PNGD） 一次性静态分区，每个 vNPU 拿到独占的硬件份额，边界由驱动强制执行。这与 MIG 在谱系上完全同构：离散资源单位、强隔离、切分粒度受模板集合约束。
模板命名规则为 vir<AI Core 数>_<AI CPU 数>c_<显存>。以华为官方硬切分参考实践（2025 年 12 月发布，配套 Ascend HDK 25.5.0）列出的模板为例：
| 硬件 | 可用模板 |
|---|---|
| Atlas 300I Duo 96G（310P3 芯片，单卡双芯） | vir01、vir02、vir02_1c、vir04、vir04_3c、vir04_3c_ndvpp、vir04_4c_dvpp |
| Atlas 300I A2 / 800I A2 32G（910B4 代推理） | vir05_1c_8g、vir10_3c_16g、vir10_3c_16g_nm、vir10_4c_16g_m |
| Atlas 300I A2 / 800I A2 64G | vir05_1c_16g、vir10_3c_32g |
裸机操作命令：
npu-smi info -t template-info # 查询本机支持的模板
npu-smi set -t create-vnpu -i <id> -c <chip> -f <模板名> # 创建 vNPU
npu-smi set -t destroy-vnpu -i <id> -c <chip> -v <vnpu_id> # 销毁
npu-smi set -t vnpu-cfg-recover -d mode # 重启后恢复切分配置容器挂载有两种方式：原生 Docker 直接挂 /dev/vdavinci<id>；或通过 Ascend Docker Runtime，用 ASCEND_VISIBLE_DEVICES=<vNPU id> 加 ASCEND_RUNTIME_OPTIONS=VIRTUAL 注入，也可以用 ASCEND_VISIBLE_DEVICES=<物理卡号> 加 ASCEND_VNPU_SPECS=<模板> 在容器启动时按需切分。
硬约束
参考实践明确列出的限制，选型前必须知道：
- 仅支持推理场景。训练卡（如 800T A2 训练整机）没有 vNPU 模板能力。
- 物理 NPU 与 vNPU 不能混用，已切分的卡不能再整卡挂载。
- 同一台服务器必须插同规格卡（48G 与 96G 不可混插）。
- 一个推理服务只能绑定一个 vNPU。
- 容器重启后 vNPU 仍在（
vnpu-cfg-recover），但调整切分布局属于破坏性操作，需要业务侧配合。
Kubernetes 集成：静态与动态两条入口
手动 npu-smi 切分再挂载的方式对应华为云文档里的“静态虚拟化”。生产上更有价值的是动态虚拟化：Pod 调度到节点后，由设备插件按调度决策实时创建 vNPU，Pod 销毁后回收。这条路径依赖华为 mind-cluster 全家桶：
- ascend-device-plugin：发现并上报物理与虚拟设备，故障时换卡重建任务
- Ascend Docker Runtime：设备与库文件注入
- NodeD / ClusterD / Ascend Operator：节点与集群级运维
- Volcano：批量调度（MindCluster 模式即由此而来）
Volcano v1.14 起，MindCluster 的核心调度逻辑被原生集成进 deviceshare 插件（deviceshare.AscendMindClusterVNPUEnable: true），需要把初始化参数 presetVirtualDevice 设为 "false" 开启动态虚拟化。Pod 通过标签声明需求：ring-controller.atlas: ascend-310P、vnpu-level: low/high、vnpu-dvpp: yes/no，并请求 huawei.com/npu-core 资源；调度器按 AI Core 数、档位与 dvpp 维度匹配 vir 模板（high 档资源不足时可降级）。
按 Volcano 官方文档，MindCluster 模式当前只支持昇腾 310 系列，910 系列在计划中。这与其代码路径一致：Volcano 源码中 MindCluster 的 vNPU 实现位于 pkg/scheduler/api/devices/ascend/mindcluster/ascend310p/，模板常量正是上面 300I Duo 的 vir01 到 vir04_4c_dvpp 那一组。
路径二：官方软切分 vCANN-RT
华为在 2026 年发布的软切分参考实践中给出了第二条路径：vCANN-RT。它来自 openEuler 的 ubs-virt 仓库（ubs-virt-enpu/vcann-rt），核心是两个产物：
libvruntime.so：通过ld.so.preload预加载进业务容器，拦截昇腾 runtime 调用enpu-monitor：监控工具
机制要点：
- 算力按时间片轮转，每个时间片默认 100ms。申请 20% 算力的容器在每个轮转周期获得 20ms 使用权。
- 粒度极细：AI Core 配额 1 到 100（整数百分比），显存最小 1MB。
- 三种调度策略：
fixed-share（严格按配比，空闲也不让出）、elastic（推荐，跳过空闲容器的时间片）、best-effort（利用率最高，无 QoS 保证）。 - 每容器一份
npu_info.config，声明物理 NPU id、vNPU id、配额、共享内存 id 与调度策略。
支持范围与定位也很明确：面向 Atlas 300I A2 / 800I A2，要求 Ascend HDK 25.5.0、CANN 8.5.0 或 9.1.0、MindCluster 组件 26.0.0.0，节点需先执行 npu-smi set -t device-share 开启容器共享模式。单卡最多 63 个容器，单容器限一张物理 NPU，不支持特权容器。官方给的目标场景是成本敏感的教育实训，单卡同时跑至少 8 个实训任务，而不是生产多租户。
部署上，Ascend Deployer 工具提供 --install-scene=softshare（K8s 场景）和 --install-scene=vcannrt（纯 Docker 场景）一键安装；K8s 路径同样依赖 device plugin、Volcano、ClusterD、Ascend Operator 与 Ascend Docker Runtime，节点打 chip1softsharedev 标签。
注意这份参考实践声明“仅供用户参考使用”，不可直接用于商用产品。定位介于社区方案与正式产品之间。
路径三：HAMi 路径
HAMi 是 CNCF Sandbox 项目 Project-HAMi/HAMi（仓库创建于 2021 年 9 月，前身是 k8s-vgpu-scheduler），覆盖 NVIDIA、昇腾、寒武纪等十余类加速器。它在昇腾上实际提供两个子模式，容易混淆：
HAMi 模板模式：换调度器，不换数据面
HAMi 的 ascend 设备插件（Project-HAMi/ascend-device-plugin）读取 hami-scheduler-device ConfigMap 中的自定义模板，Pod 请求 huawei.com/Ascend310P 加 huawei.com/Ascend310P-memory。显存请求会自动对齐到最近的可满足模板（例如卡上有 1/4 和 1/2 档模板时，请求 1024MB 会按 1/4 档对齐）。数据面仍然是驱动级 vNPU：插件最终通过 ASCEND_VNPU_SPECS 让 Ascend Docker Runtime 按模板切分。所以 HAMi 模板模式与路径一的区别只在控制面（调度器、模板治理、异构集群支持），隔离强度相同。
HAMi-core 软切分：社区版的运行时拦截
HAMi v2.9.0（2026 年 5 月）引入 HAMi-core 模式，软切分引擎是 Project-HAMi/hami-vnpu-core，以子模块形式内嵌在 ascend-device-plugin 中，由其 CI 在 CANN 环境里编译出 ARM64 的 libvnpu.so。机制与 vCANN-RT 高度同构，细节上有自己的实现：
- 插件 DaemonSet 把
libvnpu.so与ld.so.preload放到宿主机/usr/local/hami-vnpu-core/，由 Ascend Docker Runtime 注入容器。 - 显存配额通过环境变量
NPU_MEM_QUOTA下发，npu-smi等设备查询被改写为配额视图。 - 算力通过共享内存注册表（
/hami-shared-region/0_global_registry）上的 Global Manager 协调。真机日志中的Compute limit: 1, Memory limit: 8192, FixedShare: false与 vCANN-RT 的 fixed-share 与 elastic 策略显然处在同一设计空间。 - Prometheus 指标暴露在插件 Pod 的
:9395，含每容器显存上限、用量与利用率。
约束：软切分仅支持 ARM 平台，要求 Ascend 驱动不低于 25.5、节点上有 npu-smi，且需 huawei.com/vnpu-mode: hami-core 注解显式开启。
2026 年 8 月 14 日在昇腾 310P3 ARM 服务器上的真机验证（麒麟 V10、驱动 25.5.1、Kubernetes 1.28、Volcano master）给出了完整证据链：申请 8192MB 切片的容器内 npu-smi 显示 0 / 8192，宿主机同卡显示 1848 / 21525；两个 Pod 以 binpack 落到同一张物理卡（同 Bus-Id），各自独立 8192MB 窗口；指标端点上报的 hami_vgpu_memory_limit_bytes 精确等于 8192MiB。完整过程见 HAMi 网站的博客与实验 13。
Volcano 里的 HAMi 模式
Volcano v1.14（2026 年 1 月）同样原生集成了 HAMi 模式：deviceshare.AscendHAMiVNPUEnable: true，配合 deviceshare.SchedulePolicy: binpack|spread 与指向 hami-scheduler-device ConfigMap 的 KnownGeometriesCMName。与 MindCluster 模式的差异：
| MindCluster 模式 | HAMi 模式 | |
|---|---|---|
| Volcano 开关 | AscendMindClusterVNPUEnable | AscendHAMiVNPUEnable |
| 设备插件 | 华为 mind-cluster ascend-device-plugin | Project-HAMi ascend-device-plugin |
| 芯片覆盖 | 仅 310 系列（910 计划中） | 310P、910A/B2/B3/B4/C，支持异构集群 |
| 资源名 | huawei.com/npu-core 加档位标签 | huawei.com/Ascend310P 加 -memory（及可选 -core） |
| 切分方式 | 驱动模板（动态虚拟化） | 模板模式为驱动模板；加注解后为 libvnpu 软切分 |
| 软切分支持 | 无 | 有（vnpu-mode: hami-core，需 Volcano 1.16 及以上） |
若同一 Volcano 集群同时跑 vGPU（NVIDIA）与 vNPU，需要把两边的模板 ConfigMap 合并为一个再供 KnownGeometriesCMName 引用。
按芯片看支持矩阵
路径层面的对比之外，选型时更常卡住的是“我这批卡到底支持什么”。把谱系、官方路径与 HAMi 支持历史合并成一张按芯片的矩阵（以 2026 年 8 月的公开信息为准）：
| 芯片 | 代表产品 | 驱动硬切分模板 | vCANN-RT 软切分 | HAMi 模板模式 | HAMi-core 软切分 | Volcano MindCluster |
|---|---|---|---|---|---|---|
| 310P3 | Atlas 300I Duo / 300I Pro | 有（vir01 到 vir04_4c_dvpp） | 无 | 有（v2.4.0 起） | 有（2026-08 真机验证） | 有（唯一支持的系列） |
| 910A | Atlas 800 训练服务器 | 无 | 无 | 有（整卡与显存调度） | 未标注支持 | 无 |
| 910B2 / 910B3 | Atlas 800T A2 训练整机 | 无 | 无 | 有（v2.6.0 起） | 未标注支持 | 无 |
| 910B4 / 910B4-1 | Atlas 800I A2、300I A2 推理 | 有（vir05、vir10 系列） | 有 | 有 | 有（官方标注 910B 验证） | 无（计划中） |
| 910C | CloudMatrix 384 超节点 | 无 | 无 | 模块对分配（v2.9.0） | 未标注支持 | 无 |
读表的方式：训练芯片（910A、910B2/B3）在数据平面上只有整卡分配，多租户要靠队列与配额在控制面解决；推理芯片是三条路径的主战场；910C 走的是“超节点统一内存池”的另一条扩展路线，切分不是它的重点。
支持历史与成熟度时间线
这套生态的分工不是设计出来的，而是近两年加速演化出来的。把芯片历史与虚拟化支持史放在同一条轴上看：
| 时间 | 事件 |
|---|---|
| 2018-10 | 昇腾 310 发布，910 预告（HC2018） |
| 2019-08 | 昇腾 910 商用（FP16 256 TFLOPS），MindSpore 同场发布 |
| 2019 至 2020 | 实体清单与代工限制重塑路线 |
| 2021-09 | HAMi 仓库创建（前身 k8s-vgpu-scheduler），初期聚焦 NVIDIA |
| 2021 至 2023 | MindX DL 私有化套件时代，昇腾虚拟化主要经华为云 CCE 等产品化路径交付 |
| 2022 | 310P 世代推理产品（300I Duo / 300I Pro）落地 |
| 2023 | 910B 家族与 Atlas A2 整机上市 |
| 2024-09 | HAMi v2.4.0：昇腾 310P 支持 GA，加入 NPU 虚拟化自定义配置；同月 ascend-device-plugin 独立仓库创建（2024-09-11，初建于 dynamia-ai 组织） |
| 2024 至 2025 | 华为将 MindX DL 各组件“代码仓归一”为开源的 mind-cluster 仓库 |
| 2025-02 / 2025-06 | HAMi v2.5.0 补齐 910B4 配置；v2.6.0 支持 910B2 |
| 2025 | 910C 与 CloudMatrix 384 超节点发布；9 月公布三年路线图 |
| 2025-12 | 华为发布 NPU 硬切分参考实践（HDK 25.5.0 基线） |
| 2026-01 | HAMi v2.8.0：ascend-device-plugin 迁入 Project-HAMi，同时服务 HAMi 与 Volcano；Volcano v1.14.0 原生集成两种 vNPU 模式（PR #4656、#4717） |
| 2026-05 | HAMi v2.9.0：HAMi-core 用户态虚拟化上线，增加 Ascendxxx-core 资源与 910C SuperPod 模块对分配 |
| 2026 年 | 华为发布 vCANN-RT 软切分参考实践；Volcano 1.16（alpha）为 HAMi 模式补上软切分调度支持 |
| 2026-08 | 310P3 真机全链路验证源码编译部署（HAMi 博客与实验 13） |
三条曲线的成熟度判断：
- 驱动硬切分最成熟，经由 CCE 与 MindX DL 商用多年，参考实践只是把既有能力文档化。短板是芯片与场景覆盖（仅推理系列）以及模板粒度固定。
- vCANN-RT 最新也最不成熟，参考实践定位非商用，且绑定 MindCluster 26.0.0 与 openEuler 环境。
- HAMi 路径介于两者之间：模板模式与华为路径同源同强度；HAMi-core 软切分已真机验证，但依赖 Volcano 1.16（尚未正式发布）且 ARM-only。
支持程度对比
把三条路径放回本书的决策轴：
| 决策轴 | 驱动硬切分（模板） | vCANN-RT 软切分 | HAMi 软切分（hami-core） |
|---|---|---|---|
| 资源单位 | 离散模板（核数、显存、编解码引擎组合） | 连续：算力 1%、显存 1MB | 连续：任意显存 MB，算力按比例 |
| 隔离强度 | 强，驱动级硬件分区 | 软件拦截，时间片调度 | 软件拦截，时间片调度 |
| 性能可预测性 | 高 | 中（elastic 策略下依赖邻居负载） | 中 |
| 重配置成本 | 高，创建或销毁 vNPU 是驱动级操作 | 低，改配额即可 | 低，改 Pod 申请即可 |
| 芯片覆盖 | 310P3、910B4 代推理系列，仅推理 | 300I A2、800I A2 | 310P、910A/B2/B3/B4/C |
| 算力平台 | 无限制 | ARM | 仅 ARM |
| 依赖栈 | Ascend Docker Runtime 与驱动 | mind-cluster 26.0.0、openEuler 组件 | ascend-device-plugin 与 Ascend Docker Runtime |
| 监控 | 整卡粒度（npu-smi） | enpu-monitor | 插件内嵌 Prometheus 端点（:9395） |
| 商用许可 | 随驱动与 CCE 商用 | 参考实践声明非商用 | Apache 2.0 开源 |
使用场景选型
结合决策轴与支持矩阵给出可操作的建议：
- 生产推理多租户，隔离优先：选驱动硬切分。它有最强的边界与最长的商用历史。已有华为栈的集群直接走 mind-cluster 加 Volcano MindCluster 模式（或 CCE）；模板粒度够用就不必引入软切分。注意先对照支持矩阵确认你的卡是 310P 或 910B4 推理形态。
- 教育实训与高倍超卖：vCANN-RT 是华为官方为此场景设计的答案，1% 算力粒度和 63 容器每卡的上限远超模板切分。接受其平台绑定与非商用声明的前提下可用。
- 异构集群统一管理，或需要任意显存粒度：HAMi 路径。一个调度器同时治理 NVIDIA 与昇腾，软切分可以精确申请 8192MB 这类非模板值。接受其较新的成熟度曲线。
- 已被 Volcano 约束的批量调度场景：两种模式都可与 gang 调度和队列组合。芯片是 310 系列且要强隔离选 MindCluster 模式；要 910 系列覆盖、binpack 共卡或软切分选 HAMi 模式。
- 训练集群：认清现实，数据平面没有切分选项。多租户靠整卡分配加队列配额（Volcano 队列、Kueue）解决，这正是控制面几章的主题。
一个务实的混合策略同样成立：核心付费推理流量跑硬切分保隔离，内部弹性与开发测试跑 HAMi 软切分保利用率，两者可以在同一集群不同节点池并存（注意一个节点同一时间只被一条设备插件路径管理）。
开放问题
- 训练场景仍然缺席：三条路径都只覆盖推理。训练卡的多租户目前只有整卡分配加调度层配额（队列、gang），没有数据平面切分选项。
- 两套软切分长期并存：vCANN-RT 与 libvnpu 机制同构、生态独立，是否同源没有公开说明。用户面临的是事实上的双栈，监控、配置与升级路径互不兼容。
- Volcano 1.16 尚未发布：HAMi 模式的软切分调度依赖 1.16，当前只能用 alpha chart 或源码编译（实验 13 采用后者），生产采用需等正式发布。
- MindCluster 模式覆盖窄：仅 310 系列，910 系列用户在 Volcano 里实际只有 HAMi 模式可选。
- 实现细节的坑：HAMi ascend-device-plugin v1.3.1 不注册
-core扩展资源、libvnpu 版本必须与驱动匹配（不匹配的表现是npu-smi卡死而非报错），这类问题在实验 13 的踩坑记录里有完整清单。
总结
昇腾是国产算力中谱系最完整、虚拟化路径最多的一条生态：芯片上从 2018 年的 310/910 演进到 2025 年的 910C 超节点，架构上用达芬奇的 Cube 矩阵引擎走领域专用路线，与 NVIDIA 的 SIMT 加 CUDA 生态形成从硬件到软件栈的全面差异。这些差异直接决定了 vNPU 的切分维度（AI Core、AI CPU、显存、DVPP）与软切分的拦截对象（CANN 而非 CUDA）。
三路径格局则是数据平面谱系的一次完整重演：驱动硬切分对应 MIG 的位置（强隔离、离散单位、高重配置成本），vCANN-RT 与 HAMi 软切分共同对应 HAMi 式运行时拦截的位置（连续粒度、低重配置成本、软件隔离）。选型因此可以完全复用谱系框架的判断方式：先问隔离边界要放哪里，再问粒度与重配置频率，最后才是生态与许可。
对平台工程师的实际建议：不要把“昇腾支持 vNPU”当作一个开关来评估，而是对照支持矩阵把它拆成“我这代芯片加这三条路径”分别评估。华为官方路径胜在边界与商用历史，HAMi 路径胜在异构统一治理与粒度自由，vCANN-RT 胜在教育场景的超卖倍数。真要做决策时，用与本书实验章一致的验收方法（容器内设备视图、越界分配行为、监控指标）去验证你选的那条路径，而不是依赖任何一方的宣传材料。
参考资料
- 昇腾计算官网 - 华为
- 昇腾 NPU 虚拟化硬切分参考实践 - 昇腾社区
- 昇腾 NPU 虚拟化软切分参考实践（vCANN-RT）- 昇腾社区
- 手动实现 NPU 静态虚拟化 - 华为云 CCE 文档
- NPU 算力切分概述 - 华为云 HCS 文档
- 破解华为达芬奇架构的密码 - 电子工程专辑
- 华为昇腾 AI 芯片三年路线图 - 证券时报
- 一文看懂华为昇腾芯片 - 36 氪
- Ascend vNPU 用户指南 - Volcano 官方文档
- Volcano v1.14.0 发布博客（Ascend vNPU Scheduling 一节）
- mind-cluster ascend-device-plugin - GitCode
- Project-HAMi/HAMi - GitHub
- Project-HAMi/ascend-device-plugin - GitHub
- Project-HAMi/hami-vnpu-core - GitHub
- HAMi v2.4.0 / v2.8.0 / v2.9.0 Release Notes - GitHub
- Soft-Slicing Ascend vNPU with Volcano and HAMi-core - HAMi 网站
- 实验 13：用 Volcano 与 HAMi-core 软切分昇腾 310P3 vNPU - HAMi 网站