Ascend NPU 实战（一）：原生 Docker 与 Ascend Docker Runtime vNPU
内容提要
本文介绍昇腾Ascend 310P3 NPU的vNPU虚拟化使用方法。vNPU可将物理NPU划分为多个隔离实例，类比NVIDIA MIG。文章演示两种Docker运行方式：原生Docker需手动用npu-smi创建vNPU并挂载设备；Ascend Docker Runtime支持静态挂载（复用已创建vNPU）和动态虚拟化（启动时自动创建并释放实例）。通过环境变量指定设备与模板，容器内可正常使用npu-smi查看资源。
延伸解读
vNPU 与 MIG 的类比边界
文章将 Ascend vNPU 类比 NVIDIA MIG，但强调仅是概念参照。两者都通过硬件切分实现隔离，但命令、资源模型和实现方式不同。理解这一边界有助于避免将 MIG 的使用经验直接套用到 vNPU，例如创建方式、模板定义和容器内设备视角均有差异。
三种运行方式的职责划分
原生 Docker 要求用户手动创建 vNPU 并挂载设备；Ascend Docker Runtime 静态模式仍需预创建 vNPU，但注入由 Runtime 完成；动态模式则可在容器启动时自动创建并释放实例。集群调度则在此基础上由调度器统一管理资源。选择哪种方式取决于对自动化程度和资源生命周期的需求。
设备编号易混淆点
文中特别提醒区分物理 NPU ID、vNPU ID 和容器内设备编号。物理 NPU ID 用于宿主机 npu-smi 的 -i 参数；vNPU ID 是创建后返回的实例编号；容器内设备编号则是映射后的可见编号。三者不一定相同，混用可能导致操作失败或资源误用。
动态 vNPU 的配置前提
使用动态 vNPU 前需关闭 vNPU 配置恢复功能（npu-smi set -t vnpu-cfg-recover -d 0）。该步骤是动态实例自动创建和释放的前提，若未关闭可能导致动态实例无法正常管理。文章实测显示容器退出后 vNPU 数量归零，验证了动态实例的生命周期与容器绑定。
Q&A
什么是Ascend vNPU？它与NVIDIA MIG有何异同？
Ascend vNPU是昇腾的虚拟化实例（AVI），可将一个物理NPU按模板划分为多个隔离的vNPU，供容器使用。它与NVIDIA MIG类似，都能将物理加速卡切分为多个隔离实例，但命令、资源模型和实现方式不同。
在原生Docker下如何使用vNPU？
原生Docker下需手动操作：先用npu-smi创建vNPU（如npu-smi set -t create-vnpu -i 1536 -c 0 -f vir01），然后在docker run时用--device参数挂载vNPU设备节点（如/dev/vdavinci100:/dev/davinci100）及基础设备节点，并挂载npu-smi和Ascend驱动库。
Ascend Docker Runtime的静态vNPU和动态vNPU有什么区别？
静态vNPU需要提前用npu-smi创建vNPU，运行时通过ASCEND_VISIBLE_DEVICES指定vNPU ID，并设置ASCEND_RUNTIME_OPTIONS=VIRTUAL，由Runtime注入设备；动态vNPU则无需提前创建，启动容器时通过ASCEND_VISIBLE_DEVICES指定物理设备、ASCEND_VNPU_SPECS指定模板，Runtime自动创建并在容器退出后释放实例。
如何查询NPU支持的vNPU模板？
使用命令npu-smi info -t template-info -i <NPU ID>，例如npu-smi info -t template-info -i 1536，可查看当前产品支持的模板，如vir01、vir02等。
在容器内使用vNPU时，需要挂载哪些设备节点？
需要挂载vNPU设备节点（如/dev/vdavinci100）以及基础设备节点/dev/davinci_manager、/dev/devmm_svm、/dev/hisi_hdc。
如何安装Ascend Docker Runtime？
从MindCluster v6.0.0 Release下载对应架构的.run安装包（如Ascend-docker-runtime_6.0.0_linux-aarch64.run），赋予执行权限后运行./Ascend-docker-runtime_6.0.0_linux-aarch64.run --install，安装完成后重启Docker服务。
动态vNPU容器退出后，vNPU实例会自动释放吗？
会。动态vNPU由Runtime在容器启动时自动创建，容器退出后自动释放。文中示例容器退出后查询vNPU数量为0，证实了自动释放。
