【昇腾】解读一张NPU卡的内部结构

子非鱼eva

13人浏览 · 2026-09-20 17:36:42

子非鱼eva · 2026-09-20 17:36:42 发布

【昇腾】-把 npu-smi 当解剖图读: 从整机信息拆到 HBM 的六层

一句话让Agent变成昇腾专家，昇腾任务轻松搞定。评测入口：请按这个开源仓接入昇腾图谱 https://gitcode.com/agent0/kg-tools

适用: 手里有一台昇腾机器 (物理机或云实例), 想真正看懂它的开发者
验证环境: 8 x Ascend 910B3 (64G HBM, npu-smi 25.5.0) + 一台 A2 云实例交叉对照
方法: 每层从一个 npu-smi 字段出发下钻, 全部结论带实测输出

npu-smi info 的输出像一份体检报告: 型号, 温度, 功耗, 频率, 显存, 一屏放完。多数开发者扫两眼就关掉。这份输出其实是一张解剖图, 每个字段背后对应一层硬件, 从整机, 单卡, 管理芯片, 算力 SoC 到显存颗粒, 一共六层。

只拆层还不够。静态拆解回答"有什么", 回答不了"怎么协作"。本文用两条线索交叉: 横向逐层解剖 (一, 二, 三, 五, 六节), 纵向跟踪一个 GEMM 算子流过全部层的过程 (第四节)。横切给地图, 纵切给血流。读完后再面对一行云服务器规格, 也能反推出这台机器长什么样。

一、整机层: 五条命令建立全景

拿到一台陌生昇腾机器, 先跑五条命令:

npu-smi info                       # 总览: 卡数, 健康, 功耗, 温度
npu-smi info -m                    # 芯片映射: 每卡芯片名 (910B3/310P...)
npu-smi info -l                    # 拓扑: 卡间是 HCCS/UB 直连还是走 PCIe
npu-smi info -t board -i 0         # 板卡档案: 板号, PCIe 位点, 厂商
dmidecode -t system | grep Product # 整机型号 (物理机可用)

实测输出 (8 卡机, 节选):

$ npu-smi info -t board -i 0
  Product Name                   : IT21HMDC_Bin6
  Manufacturer                   : Huawei
  PCIe Bus Info                  : 0000:C1:00.0
  PCI Vendor ID                  : 0x19E5

$ npu-smi info -m
  Chip Name                      : Ascend 910B3

这层有一个高频踩坑点: 芯片名不等于平台。看到 910B3 就断定机器是 A3, 是错的。同一颗 910B3 既装在 A2 整机里, 也装在 A3 整机里, 判断平台要看系统产品信息 (dmidecode 或 npu-smi info -t product), 不看芯片名。官方 npu-smi 参考文档对此有一句明确的告诫: 芯片名指示处理器型号, 服务器平台由系统产品信息决定。

另一条经验: 解析脚本不要抓 npu-smi info 主表, 主表格式随版本漂移。抓 -t 类查询的 key:value 输出, 稳定得多。

二、卡层: MCU 与它的同事, 一张卡是一台小型计算机

主表里有一行 NPU Real-time Power(W), 这是板级瞬时功耗, 由卡上的传感器阵列采集。它不是 TDP, 不是功耗墙, 是实时读数。查每张卡的通用信息, 会先撞见功耗读数的来源:

$ npu-smi info -t common -i 0
  Chip ID                        : 0
  Aicore Count                   : 20
  Aicore Freq(MHZ)               : 1800
  Aicore curFreq(MHZ)            : 1800
  NPU Real-time Power(W)         : 100.2
  Temperature(C)                 : 39

  Chip Name                      : mcu      # 同一设备下的另一个"芯片"
  Temperature(C)                 : 35

输出末尾多出一个 mcu 域, 各卡独立存在, 各报各的温度。这是 MCU (Management Control Unit, 管理控制单元): 每张卡都有一颗, 卡上的管理微控制器, 跑独立固件 (npu-smi upgrade -b mcu -i 0 可查版本)。温度, 功耗, 健康状态这类非算力读数都经它上报。

curFreq 与 Freq 两个字段构成一条降频证据链: curFreq 长期低于 Freq, 温度或功耗至少一个顶到阈值, 芯片在降频。做 benchmark 前看一眼, 避免把降频期的数据当基线。

把视角拉到整张卡, 组件按四个面分:

┌────────────────────── 一张 Atlas NPU 卡 ──────────────────────┐
│                                                              │
│  算力面   AI SoC (910B3) ── HBM 64GB                         │
│  互连面   PCIe Gen5 x16 (对 host) / UB 端口 (卡间直连)        │
│  存储面   Flash 64MB (固件+配置)                              │
│  管理面   MCU / Bootloader / VRD / AO 常电区 / 温度传感器阵列  │
└──────────────────────────────────────────────────────────────┘

管理面除了 MCU 还有两位同事, 按固件升级参考文档:

组件	全称	职责
MCU	Management Control Unit	卡级管理: 传感, 健康, 带外通道
Bootloader	-	引导固件, 上电后最先执行
VRD	Voltage Regulator Device	供电: 多相电压调节 (实测核心电压 0.82V)

三者各有独立固件版本线, npu-smi upgrade 可分别升级。温度功耗读数异常这类不像驱动问题的怪象, 查 MCU 固件版本是否匹配是常规排查项。

存储面与带外管理也有实测线索:

$ npu-smi info -t flash -i 0
  Flash Count                    : 1
  Capacity(MB)                   : 64
  Manufacturer ID                : 0xC8

Atlas 350 技术方案文档记载: 卡上电时 AO 区 (Always-On, 常电域) 从 Flash 读卡间互连配置, 与整机 BMC 经 SMBus 下发的配置比对, 校验失败会要求重发。host 关机后仍带电的部分就是 AO 区, 这是带外管理的物理基础。

对推理调优, 这层最重要的认知是两条带宽不对称的通路: 对 host 只有 PCIe 一条 (模型加载, 请求出入), 卡间是 UB 直连 (多卡 TP 通信)。多卡推理里 TP 通信开销远小于 host-NPU 数据搬运, 直觉依据在这里。第四节末尾会沿着这条路走一遍。

三、芯片层: 910B3 SoC 里的部门分工

SoC (System on Chip, 片上系统) 内部, 官方硬件架构课程文档给出逻辑架构。用一张全景图把部门和数据流放在一起:

各部门职责速查:

部门	职责
Control CPU	系统控制: 时钟, 电源, 调度
AI Core x 20	达芬奇架构计算核, 算力主体 (实测 Aicore Count=20)
AI CPU	非矩阵算子与系统任务, Host 与 Device 间通信管理
SDMA	系统级搬运: HBM 与全局缓冲间, 跨核, 集合通信数据面
CCU	集合通信单元: AllReduce 等协议与同步
DVPP	数字视觉预处理 (解码, 缩放, 多模态场景)

计算核内部值得单独说。910B 属于 A2 系列, 采用分离架构: 矩阵计算 (AIC, AI Cube) 与向量计算 (AIV, AI Vector) 拆成两种独立的核, 各自带 Scalar 单元, 独立加载代码段。官方给的理由直接指向大模型: 矩阵与向量解耦, 更适应 Transformer 的算力结构。

每个核里的四个工种:

Cube: 矩阵乘 (GEMM), QKV 投影和 FFN 大矩阵乘靠它, 芯片标称 TFLOPS 基本是它的峰值
Vector: 向量与逐元素运算, RMSNorm, Softmax, GELU, RoPE
Scalar: 一次算一个数, 管地址生成, tiling (算子分块) 循环计数, 分支与同步
MTE (Memory Transfer Engine, 搬运引擎): 核内数据搬运, 与计算并行

顺带纠正一个流传的说法: 有公众号文章称 AI CPU 在 host 侧, 不在芯片内。官方课程文档写明 AI CPU 是芯片上面向非矩阵任务的处理器。两说冲突时, 取官方口径。

静态地图到此完整。下一节让一个算子从这张地图上走一遍。

四、纵切: 一个 GEMM 算子的完整流水

拆解是横切, 理解是纵切。取大模型里最典型的一个 GEMM 算子 (一个 Transformer 层的 FFN 权重乘), 跟着它从 host 代码走到显存再回来。六步流水, 每一步落在上一节地图的具体组件上:

4.1 六步逐个说

第一步, 任务下发。 Host 侧框架 (torch_npu 或 MindSpore) 把算子编成任务描述, 经 CANN Runtime 与驱动, 走 PCIe 到达设备侧。AI CPU 解析参数, 选中目标核, 派发。算子的机器码此前已加载到核上, 这一步只发"开工令"。

第二步, 数据预取。 GEMM 的两个输入矩阵此前已在 HBM (权重常驻, 激活是上一个算子的输出)。数据按需经 L2 进入核内。MTE1 负责 L2 与 UB 之间, MTE2 负责 UB 与 L0 之间, 接力搬运。Scalar 已按 tiling 方案算好每一块的源地址与目的地址。

第三步, 计算。 Cube 从 L0B 取输入做乘加, 结果写 L0C。这一步对外表现为主频乘阵列规模的峰值算力。Scalar 在后台管循环计数与同步信号。

第四步, 结果回写。 L0C 的结果经 Fixpipe 流水处理: 查 FP Buffer 里的量化参数, 查 BT Buffer 里的 bias, 完成变换后写回 L2。需要进下一个核的数据经 L2 转运。

第五步, 同步。 Scalar 确认所有分块完成, 通知 AI CPU。

第六步, 返回。 AI CPU 汇报 Host, 或者直接衔接下一个算子的下发 (图模式下任务已排队, 无需往返 host)。

4.2 数据阶梯: 每一级谁在搬

六步流水的背后是一条存储阶梯。容量每级差 2-3 个数量级, 带宽每级差 1-2 个数量级, 越靠近计算单元, 越小越快:

HBM 64GB ──HBM控制器──> L2 (MB 级, 全核共享) ──MTE1──> UB (百 KB 级, AIV 侧)
                                                             │ MTE2 (排布转换由 NDDMA 类指令下沉硬件)
                                                             v
                                              L0A/L0B (数十 KB) → Cube/Vector → L0C
                                                              │ Fixpipe (bias/量化)
                                                              v
                                                            回 L2

Ascend C 算子代码里的 DataCopy 系列 API, 调用的就是这条阶梯上的 MTE。写算子时的 Double Buffer (双缓冲) 技巧, 本质是给这条阶梯加两级交替缓冲: 算法在算 Buffer A 时, 搬运已经在装 Buffer B。

4.3 重叠: 性能的隐藏开关

把时间轴摊开看搬运与计算的关系:

时间 ──────────────────────────────────────────→
搬运(MTE):  [取块1][取块2     ][取块3     ][取块4     ]
计算(Cube):       [算块1     ][算块2     ][算块3     ]

理想状态是两条流水线全重叠, 计算永远不等数据。现实里常见的劣化是 tiling 切得太碎 (搬运启动开销占大头) 或切得太大 (UB 装不下, 停等)。这一节解释了一个反直觉现象: 算子吞吐上不去, 瓶颈经常不在 Cube 算力, 在搬运。对应到 Profiler 的读法:

Profiler 主耗时	瓶颈落点	优化方向
GEMM	Cube	tiling 方案, 低精度格式 (BF16→FP8)
RMSNorm / Softmax	AIV (Vector)	Vector 利用率, 与 GEMM 融合
搬运 / 地址计算	MTE / Scalar	数据排布, Double Buffer, 算子融合
调度与启动开销	AI CPU	图模式 (ACLgraph), 算子融合

4.4 从单算子到一次推理

一个 decode 步骤是上述流水重复千百次: 每个 Transformer 层两次 GEMM 加一圈向量算子, 全部权重从 HBM 读一遍。串到第五节就明白, 为什么显存带宽决定 decode 吞吐。

多卡 TP (张量并行) 场景在流水末尾加一段接力: Cube 结果 → Fixpipe → L2 → SDMA 搬运 → CCU 做协议与同步 → UB 口 → 对卡。

这条路走的是第二节那条卡间直连, 不经过 host PCIe。AllReduce 的通信量与 TP 切分方式相关, 这是多卡推理里通信开销远小于直觉的架构原因。

五、显存层: HBM Clock 1600MHz 与 1.6TB/s 天花板

-t memory 输出里的 HBM Clock Speed(MHz): 1600 是显存接口时钟。HBM 是 DDR 接口, 时钟上下沿各传一次, 换算关系:

$ npu-smi info -t memory -i 0 -c 0
  HBM Capacity(MB)               : 65536
  HBM Clock Speed(MHz)           : 1600
  HBM Temperature(C)             : 34

1600 MHz 接口时钟 → 每引脚 3.2 Gbps 有效数据率
带宽 = 总位宽 x 数据率 ≈ 1.6 TB/s (多 stack 1024-bit 总线并联)

1.6TB/s 这个数字在多个官方示例与硬件规格文档中一致。HBM 的设计路线与 GDDR 相反: 不追单引脚高频, 靠超宽总线堆带宽。

接第四节末尾的问题: decode 阶段每生成一个 token, 几乎要把全部权重从 HBM 读一遍, 这是访存受限阶段的定义。由此推出三件事:

decode 吞吐上限 ≈ 1.6TB/s / 模型权重字节数。7B 模型 BF16 权重约 14GB, 单请求 decode 上限约 110 tok/s, 这个天花板由显存带宽决定, 加算力无用
Profiler 里 HBM 带宽占用接近满时, 优化方向只剩减少字节数: 量化 (W8A8 权重字节减半, 吞吐近翻倍), 增大 batch (多请求摊薄同一份权重的读取次数)
1600MHz 是固定规格, 不是调优旋钮。它的价值是当 roofline (性能上限) 分析的分母

另外注意 Aicore Freq 1800MHz 与 HBM 1600MHz 是两个独立时钟域, 核时钟与显存时钟各自浮动, 互不同步。

六、指纹与反推: 0x56 是谁, 一行规格能推出什么

厂商指纹: 查不到映射也有用

-t memory 还有一个字段 HBM Manufacturer ID, 实测两台机器不同: A2 云实例 0x56, 本机 910B3 卡 0x57。查证结果分三层: 官方知识库无此字段文档; JEDEC JEP106 公开表对不上 (主流 HBM 三家 Samsung 0x01, SK hynix 0xAD, Micron 0x2C); 大概率是内部供应商编码, 权威答案只能问厂商技术支持。

查不到名字, 不代表没用。同代芯片不同值, 这个字段可以当显存批次指纹: 多机基准对比或同型号卡之间出现无法解释的固定性能差异时, 把它记进硬件档案一起比对。

一行规格的反推游戏

云厂商只给一行字: 昇腾 A2, CANN 9.0.0, Ubuntu 22.04, 1 NPU, 32G 内存, 32 核 CPU, 300G 存储。能推出什么:

线索	推论	置信度
昇腾 A2	平台族确定, 芯片锁定 910B 家族 (正向成立, 反向不成立)	确定
1 NPU + 32G + 32 核	云上单卡实例: 宿主机是 8 卡 Atlas 800 A2 系整机, 切出 1 颗 NPU; 32G 是 host 内存不是显存	高
CANN 9.0.0 + Ubuntu 22.04	arm64 镜像, host CPU 是鲲鹏 920	高
综合	芯片大概率 910B3 (云上单卡主流), 20 核 1800MHz, HBM 64G	中高
300G 存储	云盘, 模型首次加载走网络, 慢是正常的	确定

官方学习仓库的 CANNLab 环境记载了同族规格: 镜像 cann_9.0.0_py3.11-A2-arm, 配置 1*NPU 910B3 16vCPUs 32GiB。交叉印证了这条推理链。

三条命令拿到权威指纹:

npu-smi info -m             # 芯片名
npu-smi info -t common -i 0 # Aicore Count=20 坐实 910B3
uname -m                    # aarch64 = 鲲鹏 host

收束: 一横一纵带走

静态六层, 每层一个代表字段与一条命令:

层	代表字段	一条命令
整机	Product Name	dmidecode -t system
卡	PCIe Bus Info	npu-smi info -t board -i 0
管理面	mcu 域温度, Power	npu-smi info -t common -i 0
芯片	Aicore Count/Freq	npu-smi info -t common -i 0
显存	HBM Clock/Capacity	npu-smi info -t memory -i 0 -c 0
指纹	HBM Manufacturer ID	npu-smi info -t memory -i 0 -c 0

动态一条流: Host → AI CPU → Scalar 编排 → MTE 阶梯搬运 → Cube 计算 → Fixpipe 回写 → (多卡: SDMA/CCU/UB) → 下一个算子。横切答"机器由什么构成", 纵切答"它怎么干活"。

三条查证习惯贯穿全文: 芯片名不等于平台, 判断依据永远选系统产品信息; 拿不准的规格查官方文档而不是凭记忆; 查不到的内容明确标注未核实, 留一个批次指纹的用途。硬件认知的复利不在记住多少命令, 在每个字段都知道它连着哪一层, 每个算子都知道它流过哪些组件。

接入昇腾知识图谱 https://gitcode.com/agent0/kg-tools

参考

昇腾异构编程基础课程, 第 1 章硬件架构介绍 (SoC 逻辑架构, 分离架构)
npu-smi 设备查询参考 (平台判别方法, -t 查询清单)
npu-smi 固件升级参考 (MCU/Bootloader/VRD 组件定义)
Atlas 350 加速卡产品参考技术方案 (UB 端口, AO 区与 BMC 交互)
昇腾 AI Core 拆解文章 (Cube/Vector/Scalar 分工, MTE 与 SDMA 搬运体系, 计算搬运流水线)
官方高性能矩阵乘示例 (910B HBM 带宽约 1.6TB/s)
cann-learning-hub 仓库 CANNLab 环境说明 (1*NPU 910B3 16vCPUs 32GiB)

人工智能6S服务平台

作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。

更多推荐

从级联架构到生成式推荐：推荐算法演进与昇腾落地

本文按"算法演进 → 工程落地"的主线，系统梳理生成式推荐（Generative Recommendation, GR）这一方向的发展脉络。第一部分回顾传统级联推荐架构的系统性瓶颈；第二部分以 Meta GR（HSTU）和快手 OneRec 为代表，剖析两条主流的生成式推荐技术路线；第三部分聚焦工程落地，介绍 TorchRec 生态以及基于昇腾 NPU 打造的 RecSDK 框架，展示从算法到生产

人工智能6S服务平台

slime 源码走读：SGLang-Native 推理架构解析（下）

昇腾平台当前已支持slime框架本文是 slime 源码走读系列的推理架构部分的下篇。上篇介绍了 slime 的推理整体架构——服务化推理、四级层级、三条通信路径、SGLangEngine 遥控器、sgl-router 等。如果还没读过、强烈建议先读上篇，本文会反复引用其中的设定。如果不想跳回去翻，简单复述一下走读配置和架构骨架。走读配置--actor-num-gpus-per-node 4 \