0
0

读懂昇腾 A3 的设备层级：双 Die、davinci 节点与空闲 HBM 排查

2026-10-17
硬件、算子与编译

整理日期：2026-09-14。来源：当天可见聊天摘要；原理说明为整理时补充，非完整对话逐字稿。未取得的设备参数与未验证的结论明确保留为待核实。

今天的困惑

A3 容器为什么要映射两个设备节点？npu-smi 里的 NPU、Chip、Phy-ID 分别是什么？没有模型运行，为什么还看到约 3 GB 占用？

先分清五个层级

  • 产品：Atlas 是产品系列名，Atlas 900 A2 PoD 属于集群级产品语境，不能把整套 PoD 当作一张卡；具体节点数与组网规格需要相应型号资料。
  • 物理模组或卡：采购、机箱安装与供电层面的单位。
  • Die/芯片：模组内部的硅片计算单元。
  • 运行时设备：框架选择和建立执行上下文的对象。
  • Linux 设备节点：用户态程序通过驱动访问设备的入口。

这些编号不保证一一相同。官方工具文档区分 Chip Logic ID 等编号，应通过映射信息对照，不应凭第一列自行推导全部设备关系。昇腾工具文档

/dev/davinci0 到底是什么

它是设备节点，不是存模型的目录。容器里的 --device 映射让容器进程能够访问相应宿主设备。

对于当天引用的“A3 双 Die，需要两个节点”部署说明，应理解为该部署单元需要暴露配对的计算设备。双 Die 不意味着任意单进程一定自动使用两份 HBM，也不意味着两块内存无成本合成一整块。

实际映射还可能包括管理节点、驱动库和通信设备。应使用当前产品、容器运行时和推理框架给出的完整配置，不能把两个 davinci 参数当作通用完整启动命令。

对“空闲约 3 GB”的修正

目前证据不足，不能确认这 3 GB 全是 Driver、Firmware 或 CANN 固定占用。

当天可见输出只有部分表格，尚不能完整确认对应字段、所有设备、进程列表与初始化状态。

可能原因包括系统保留、已初始化的运行时资源、其他进程或容器、缓存分配器保留，以及工具统计范围差异。这些是排查假设，不是这台机器的已证实原因。

只读排查顺序

npu-smi info
npu-smi info -m
ls -l /dev/davinci*

先保存完整表格，区分 Memory-Usage 与 HBM-Usage，再核对逻辑设备映射；若本机版本不支持映射命令，查看其帮助。结合宿主机进程和容器列表，判断是否存在看不见的其他工作负载。

建立三个观测点：未启动目标程序、仅初始化运行时、加载模型后。比较每个阶段的增量比孤立看一个数字更有解释力。共享机器上不能为确认基线擅自重启或重置设备。

与 CUDA 的有效比较

比较时应对齐：整设备统计还是进程统计、是否创建上下文、是否加载通信库、缓存是否保留、是否存在其他进程。不能仅凭两张不同工具截图断言某平台固定多耗几 GB。

**复习问题：**为什么一张物理模组可以对应两个设备节点，但每个 Rank 仍可能分别 OOM？

合并补充：产品映射与退出后的 HBM 观察

Ascend 是处理器系列，Atlas 是硬件产品系列；A2 PoD 的名称不能证明它与 A3 SuperPoD 具有相同拓扑。华为产品入口；vLLM Ascend 安装指南。

若 8 个物理模组各暴露 2 个计算设备，框架可能看到 16 个设备；这是条件示例，不是当前机器的已确认拓扑，TP=16 不自动等于 16 张物理卡。资产记录应同时保存物理模组数、逻辑设备数、每设备 HBM 和互联。

HBM 对照实验再增加“进程退出后”观测点，并比较同机未使用设备。如果占用持续累积，再检查退出状态、日志和版本说明。进程表为空既不能证明 HBM 必须为零，也不能证明非零占用一定正常；Memory-Usage 与 HBM-Usage 不应相加。当前仍不能判断约 3GB 是否正常、可释放或属于泄漏。