昇腾NPU核心Da Vinci架构深度解析：从硬件到软件栈

说实话，这几年搞AI部署和端侧推理，我越来越觉得单纯盯着英伟达那一套不太够。尤其是接触到昇腾系列之后，华为的Da Vinci架构让我重新想明白了一件事：NPU不是GPU的简单模仿，它是一套从头开始为张量计算设计的专用硬件方案。这篇文章不聊跑分，不写PPT，只拆硬件本身的设计逻辑。我会从计算单元、存储层次、数据流调度这些底层细节入手，尽量用大白话把华为昇腾AI处理器背后的Da Vinci架构讲清楚。适合正在用昇腾做推理部署的工程师，也合适想转AI芯片方向、但对硬件细节还没完全串起来的朋友。

1. Da Vinci架构的整体设计思路与核心突破

1.1 为什么华为要自研一套NPU架构，而不是直接跟风GPU

先看一个常识：通用GPU为了兼容图形渲染和通用计算，内部塞了大量复杂的调度逻辑。以SIMT（单指令多线程）模型为基准，GPU需要处理线程块（Thread Block）、束（Warp）调度、内存合并访问等一堆问题，核心设计目标其实是“大规模并行地做任何事”。

但AI计算不一样，尤其是深度神经网络的卷积、矩阵乘、Transformer里面的QKV投影和注意力分数计算，本质就是密集的张量运算。这类运算有一个明显特征：任务结构极其规整，几乎没有复杂分支，数据复用性高，不需要像CPU那样做复杂的分支预测和乱序执行，也不需要像GPU那样协调几千个独立线程的调度。

华为做Da Vinci架构时，走的路线是DSA（Domain-Specific Architecture，领域专用架构），也就是专门为一个领域设计一套硬件。这套东西的目标非常纯粹：把矩阵乘、向量运算、标量控制三类操作在硬件上安排得明明白白，让芯片面积和功耗尽量用来做计算和搬数据，而不是“管闲事”。与GPU通用并行不同，Da Vinci用了一种更极端的思路：既然张量运算足够规整，那就直接把硬件做成一个“超级算盘”，每个时钟周期都尽可能地保证数据喂进算盘里，不停顿、不等数据。

1.2 从宏观到微观：AI Core、AI CPU与片上网络的协同

Da Vinci架构在芯片层面并不复杂，核心可以抽象成几个大块：AI Core集群、AI CPU、片上存储（L2 Buffer与Unified Buffer），以及连接这些模块的NoC（片上网络）和总线结构。

AI Core是真正的计算主力，专门执行矩阵和向量计算；AI CPU是精简控制核心，负责执行流程控制、数据搬运指令、标量运算，以及一些不适合AI Core处理的短小算子。很多人一开始可能会误解，以为昇腾的CPU就是拿一个ARM核跑业务，实际上AI CPU是专门为计算流控制设计的，与外部通用CPU（Host侧CPU）严格区分，Host CPU负责操作系统的任务分发，AI CPU负责芯片内部的具体执行流程。

这种“异构计算单元+分级存储”的结构，本质上是模仿了一家公司内部的分工：AI CPU是项目经理，只管规划流程和派活；AI Core是干活的工人，只知道闷头做矩阵乘法；L2 Buffer和Unified Buffer是仓库，数据必须先放到手边，工人才能开工。整个Da Vinci架构要做的最重要事情，就是让项目经理的派活节奏、工人的计算节奏、仓库的补货节奏完美对齐，任何一环跟不上，芯片性能就会出现断崖式下跌。

2. AI Core内部结构拆解：Cube、Vector、Scalar如何各司其职

2.1 Scalar单元：整个AI Core的“总指挥”

如果把AI Core当成一个微型工厂，Scalar单元就是工厂里的总控台。它做的事情包括循环控制、地址计算、分支跳转，以及控制Vector和Cube单元的启动和结束。Scalar单元的基本设计比较像一颗精简的RISC处理器，指令集不大，重点在于确定性：每一拍做什么都提前排好，不能出现乱序。

很多人看AI Core的资料时容易忽略Scalar单元，觉得它就是个控制大脑，没有太多可讲的。但实际写算子、做Tiling切分时，Scalar指令的排布直接影响整个算子的利用率。如果Scalar单元计算地址太慢，Cube单元就会干等着，出现“计算等数据”的窘境。在昇腾的架构文档里，SC（Scalar）指令跑在标量流水线上，与向量流水线、矩阵流水线并行执行，所以好的算子实现应该尽量让复杂的地址计算和循环判断在Scalar单元提前算好，而不是每次循环都从头推断。

我发现一个特别直观的类比：你在厨房做饭，Cube是那个最快的切菜机器人，Vector是你自己动手处理琐碎配菜，Scalar是站在旁边不断看菜谱、安排下一步动作的大厨。大厨反应慢了，切菜机器人再快也只能等着，锅瓢碗盏摆得再齐也白搭。

2.2 Cube单元：矩阵计算的硬件加速核心

Cube单元是Da Vinci架构最核心的部分，专门做矩阵乘加运算。在昇腾910上，一个AI Core内部包含多个Cube Core，而Cube Core的基本计算阵列是16x16x16的三维结构。也就是说，一个Cube指令可以一次完成16x16矩阵乘以16x16矩阵的主要计算，中间累加维度也是16。

我最初看到16x16这个尺寸时心里嘀咕了一句：为什么是这个数字？后来自己推演了一遍才发现，这背后有很实际的硬件考量。16这个维度在FP16精度下，一个值占2个字节，16x16的矩阵就是512字节，正好可以放入一个较小的高速缓存块；同时，一次乘累加涉及16次乘法和16次加法，硬件布线可以做得非常规整，不需要太复杂的跨行跨列交叉开关。更深一点看，16x16的矩阵块可以做到“一行数据完全复用”，对内存带宽的要求更低。

Cube单元工作时的数据流路径是这样的：输入矩阵A和矩阵B的切片会先被搬运到Cube旁边的L0 Buffer里，然后Cube单元直接从L0 Buffer取数计算，计算结果写到另一个L0 Buffer（或者统一缓冲UB，具体根据算子不同有差异）。这样一来，Cube计算单元自身不需要访问L1或L2缓存，就如同一个只埋头干活的工人，原料送到手边就开始算，算完的成品放在手边。所有去仓库取料的活，都不需要Cube操心，全由数据搬运单元负责。

从性能角度看，Cube单元的峰值利用率能达到相当高的水平，前提是你把数据切分和搬运安排得足够好。这就引出了昇腾调优里经常听说的“流水线编排”。早期的算子实现往往是先搬运一整块数据、算一整块、再搬运下一块，这会导致Cube算一会儿歇一会儿；优化之后的实现会把数据搬运拆成多份，让搬运和计算重叠，Cube几乎每个周期都有活干。实操中这一点区别很大，我在后文会专门讲。

2.3 Vector单元：处理非矩阵运算的“多面手”

深度网络里不只有矩阵乘。激活函数、归一化、逐元素乘加、Pooling、Cast这些操作，都是逐元素或者逐向量的操作，用Cube单元跑反而浪费。Da Vinci架构为此单独设计了一条Vector流水线，与Cube单元并行工作。

Vector单元的核心能力是做向量运算，处理长度从8比特到64字节不等的向量数据。它支持的操作包括定点和浮点加减乘、比较、选择、逻辑运算、类型转换等。由于AI 网络里常出现一部分输出走Cube计算，另一部分需要走Vector处理的场景，Vector和Cube能否真正并行是关键。在昇腾中，Vector单元和Cube单元的指令可以同时下发、同时执行，只要没有数据依赖，硬件就能让它们各干各的。

实际写算子时最影响效率的错误是：强制同步。有的开源代码在每个计算块结束后调用了一次同步Barrier，让Cube算完、Vector算完、搬运也全部落定，再开始下一块任务。这样做逻辑完全正确，但性能极其拉胯，因为同步等于让所有单元一起“停下来集合”。正确做法是尽量解除依赖：让Cube计算A块的同时，Vector处理B块的激活，搬运单元提前预取C块的输入。硬件本身支持这种级别的并行，关键是软件实现有没有把它排出来。

3. 存储层次与数据搬运设计：硬件性能的真正瓶颈

3.1 从L2 Buffer到L0 Buffer：每一级缓存都带着明确分工

很多搞软件优化的同学一看“L0、L1、L2”就以为是CPU缓存那一套，在Da Vinci架构里可不能这么简单理解。CPU缓存对软件完全透明，程序员不用手动搬数据；而昇腾NPU的各级存储，在设计上大量依赖显式的数据搬运指令，甚至在更高层的编程模型里，开发者需要明确知道“数据从Global Memory搬到L2，再从L2切块搬到L0”，才能写出高性能算子。

我整理了一个简化的存储层次表，方便大家对照理解：

这个结构很有意思的地方在于：越往底层越靠近计算单元，容量越小，但访问延迟越低。任何数据在进入Cube单元计算前，都必须已经在L0 Buffer里等好了。所以每执行一次Cube计算，数据至少要从L2或更低层搬一次到L0，这个搬运成本是不可忽视的。

3.2 Tiling切分策略：为什么大矩阵不能一次性算完

假设现在要算一个超大矩阵乘，矩阵A是4096x4096，矩阵B也是4096x4096。如果放在GPU的编程模型里，通常就是开一个足够大的Grid，让所有线程块并行处理；而昇腾NPU这边并没有那么宽松的线程调度机制。

Da Vinci架构里，AI Core的L0 Buffer就那么大，你不可能把4096x4096的全部数据装进去。所以必须把大矩阵按一定规则切成小块，例如按16的倍数切分出若干小Tile，依次搬入、依次计算。这个过程在昇腾工具链里叫Tiling。Tiling参数（切块大小、循环步长、UB缓冲区占用比例）极大影响最终性能。切大了，缓冲区装不下，搬运次数没有减少反而触发频繁搬运；切小了，计算单元吃不满，单位数据搬运带来的计算量太低。

实操中我一般先按L0 Buffer容量确定单个Cube计算块的最大尺寸，再倒推一个循环里能放几块，最后用性能分析工具检查Cube利用率。如果Cube利用率长期低于80%，先别怀疑硬件差，多半是Tiling切分没切好，或者数据搬运没流水起来。很多人从CUDA切过来时习惯性地“开大块、多并行”，到了昇腾上第一件事就是要转变思路：硬件给你的并行空间是有上限的，真正能拉开差距的是在有限缓冲里把数据复用和流水安排到极致。

3.3 数据搬运的“隐藏成本”与同步开销

数据搬运是AI Core性能的大头成本，但往往最容易被忽略，因为它不像运算单元有一个明确的峰值FLOPS让你权衡。搬运成本包括两部分：一是数据从Global Memory到L2再到L0的时延，二是各级存储之间的带宽占用。只要带宽被打满，计算单元再闲，也得等数据。

举个例子，一个卷积层输出通道是512，输入特征图是112x112x128。如果朴素地把整个输入特征图先搬进L2，再慢慢切给AI Core，会发现L2容量根本不够，甚至还会因为反复搬运同一块数据而白白消耗带宽。正确做法是分析数据复用关系：输入特征图的每一块会被多个输出通道复用多次，所以要尽量在L2中保留这一块输入，让多次复用在片上完成，而不是每次从HBM重新读取。

另一个容易踩的坑是同步屏障。数据搬运、Cube计算、Vector处理三者在同一个AI Core里共享部分资源，所以硬件提供了事件同步机制。如果你在代码里到处加同步，例如每次数据搬运完成都要等Cube算完才能继续搬，那流水线就被迫中断。真正合格的算子实现，应该把同步控制在“不得不等”的时刻，例如当L0 Buffer即将被覆盖而Cube确实还没算完时。其余时间尽量让搬运和计算独立推进。

4. 从硬件到软件：CANN、AscendCL与torch_npu的那层薄纱

4.1 统一编程框架CANN到底做了什么事

硬件设计得再好，没有编译器把算子翻译成底层的Cube/Vector/Scalar指令，也是白搭。华为昇腾的软件栈叫作CANN（Compute Architecture for Neural Networks），它做的事情非常多，但核心两条线：一条线是从AI框架前端（PyTorch、MindSpore等）接收计算图，做图优化和算子选择；另一条线是把优化后的算子编译成适配AI Core的指令序列，也就是完成“计算图到硬件指令”的翻译工作。

CANN内部最重要的一层是AscendCL，这是面向开发者的统一API层。它屏蔽了AI Core、AI CPU以及各级Buffer的细节，向开发者提供“申请设备内存、传输数据、加载模型、下发执行”这一类粗粒度接口。绝大多数用昇腾做推理的工程师，日常工作接触到的其实都是AscendCL和配套的ACL模型转换工具，而不需要直接写底层汇编。

不过，如果想做高性能自定义算子，CANN也提供了TBE（Tensor Boost Engine）和Ascend C这样的编程接口。用它们可以在高层描述算子的切分逻辑和计算逻辑，然后由编译器生成底层指令。我个人的体会是：能用框架自带算子解决，就不要轻易写自定义算子，因为自定义算子的性能调优周期真的不短。只有在框架算子融合不到位、性能瓶颈明显时，才有必要下场手写。

4.2 开发环境适配：torch_npu常见坑与排查思路

现在很多人的实际工作流程是：在GPU上训练好模型，然后拿到昇腾NPU上做推理或继续精调。这个流程中，最常遇到的环境问题就是装了PyTorch之后发现设备选择不对，或者torch_npu没有正确加载。结合我自己调试过的经验，专门整理一下关键点。

“npu is selected as device, but torch_npu is not available”这类错误，听起来像是昇腾设备没接好，但九成情况下是torch_npu这个插件根本没装，或者版本和当前PyTorch不匹配。检查顺序我一般是这样：

1. 先看物理设备：执行npu-smi info，确认驱动和固件正常识别NPU。如果连npu-smi都报错，优先重装驱动，而不是去纠结PyTorch配置。
2. 再看CANN版本：torch_npu通常依赖CANN的工具包，例如CANN Toolkit，版本不对会在import阶段直接报错。这个坑最常见，尤其是本机装了多个CANN版本时，环境变量稍微一乱就完蛋。
3. 再看torch_npu版本：每个torch_npu版本明确对应一个PyTorch版本，比如torch_npu 2.1.0对应PyTorch 2.1.0。严格按官方对应表安装，不要自己混搭。
4. 最后看加载顺序：如果代码里用了import torch_npu，要确保它在torch之后导入，且不要被其他覆盖了设备后端的库干扰。

还有一种情况是在容器里跑。昇腾的容器通常需要在启动时挂载/dev/davinci设备和驱动目录，例如将/etc/ascend、/usr/local/Ascend等目录映射到容器里。漏了挂载就会出现“有设备但无法访问”的诡异表现，典型现象是npu-smi在宿主机正常，进到容器里却看不到卡。遇到这种问题别急着重装，先看看容器启动参数和docker run命令是否挂全了设备。

4.3 昇腾上跑Swift与Megatron的实战注意点

最近也在关注“昇腾npu swift+megatron实战”这类话题，说明已经有不少人开始尝试在昇腾上做大模型训练和微调了。这个方向算是目前生态里最硬核的一块，因为它同时涉及分布式训练框架、通信库（HCCL）、以及高度定制化的融合算子。

拿Megatron-LM来说，它原本是为GPU集群设计的，大量使用了NCCL做集合通信，并且依赖Tensor Parallel和Pipeline Parallel的特定切分方式。迁移到昇腾上，通信这块需要从NCCL切换到HCCL，数据并行的AllReduce逻辑本身变化不大，但通信算子底层完全不一样。实际跑起来你会发现，如果不加修改直接用GPU版配置，很容易因为通信库和拓扑识别差异导致剧烈掉速，甚至直接hang住。

Swift则更像一套面向PyTorch的轻量训练和推理工具，优点是工程化程度高，和HuggingFace生态衔接紧密。在昇腾上跑Swift微调，我建议先确认你用的模型算子都被CANN的算子库覆盖，如果某些自定义算子缺失，框架会自动回退到CPU执行，那个性能就完全没法看。我的经验是先跑一遍小规模样例，用profiling工具看算子落点，把所有回退CPU的算子全部排查一遍，再上正式规模。

5. Da Vinci架构与GPU对比：为什么说它不是“又一个GPU”

5.1 指令驱动与线程驱动的本质差别

这一节我想深入对比一下Da Vinci NPU和NVIDIA GPU在设计哲学上的根本差异。GPU的核心思路是“线程驱动”：同一条指令被大量线程同时执行，靠线程规模和硬件线程调度器隐藏时延。每个线程很小，资源占用也不大，换来的是极高的并发度和生态兼容性。程序员写CUDA时，脑子里默认是一堆线程块并行跑。

Da Vinci NPU则是“指令驱动”的架构，更接近传统VLIW（超长指令字）和脉动阵列的混合体，或者说，它把并行度放在数据流水线上，而不是线程数量上。AI Core内部的Cube、Vector、Scalar各执行各的指令流，彼此之间通过事件同步来协调，而不是通过线程调度器去切换上下文。所以，在GPU上常用的“用更多线程压榨并行度”的思路，在昇腾上并不成立；昇腾要的是把数据在各级缓冲中精准排布，让流水线不断流。

这种差别直观地反映在“模型迁移”的成本上。同一套模型从GPU迁到昇腾，如果只是把 model.to('npu') 改一下，那是做梦。底层算子必须经过CANN的适配和重编译，部分子图还需要被切成更细粒度的小算子，才能让Da Vinci硬件跑出接近峰值的性能。这也是很多团队感慨“昇腾上手门槛高”的原因——门槛确实高，但高在思维方式不同，而不一定是硬件本身不行。

5.2 从昇腾310到昇腾910：同一架构下的不同定位

Da Vinci是一个架构系列，不是单款芯片。昇腾310主打边缘推理，功耗低、成本低、单芯片AI Core数量少，适合视频分析、智能安防、工业检测这类对时延和功耗敏感的场景。昇腾910则面向训练和数据中心推理，AI Core数量多得多，HBM带宽也更高，能支撑大型Transformer模型训练。

很多人有个误区：“910比310强，那直接把910的软件搬到310上不就行了？”不行。两者虽然是同一代Da Vinci架构，但因为AI Core数量和缓存容量差异巨大，Tiling策略、并行切分和算子融合都要重新做。在实际项目中，我通常建议团队先明确目标产品规格，再选择计算平台。如果目标是边缘盒子，那就要为310的小缓存设计轻量化算子，尽量压缩单算子开销；如果目标是训练集群，就要围绕910的HBM带宽和大AI Core规模去优化通信与切分。

这种“一个架构、多款芯片”的策略，其实和GPU产品线的思路类似，但华为把边界切得更细：推理向和训练向是两个明显分支，硬件资源配置完全不同。对软件开发者来说，这既是好事也是坏事。好事是同一套CANN工具链和开发经验基本可以迁移；坏事是，你在310上调优出来的那套Tiling参数，换到910上可能要推翻重来。

6. 实战避坑指南：从环境到性能调优的独家经验

6.1 常见开发环境问题速查表

结合我自己的踩坑经历，把昇腾开发环境里最常碰到的问题整理成一张速查表，方便大家按图索骥：

我特别想强调一点：昇腾的环境问题，有一大半都出在版本对应关系上。CANN、torch_npu、PyTorch、驱动固件，这四个版本必须锁死。很多人习惯“自己看着装”，结果版本一乱，错误信息五花八门，最终浪费一两天时间去排查一个根本不需要排查的问题。建议每台机器固定一套经过验证的版本组合，用容器镜像固化下来，别让团队成员各装各的。

6.2 从GPU迁移到昇腾时最容易踩的三个调优坑

第一坑：闭眼沿用GPU的Batch Size和算子融合策略。GPU上Batch Size往往可以开得很大，因为线程调度器能轻松隐藏时延；昇腾上Batch Size会影响L2缓冲的占用和Tiling切分，随意加大Batch很可能导致缓存溢出或频繁搬运。我建议迁移后用profiling逐层看，找到性能异常的层再反向调整。

第二坑：忽略了数据排布格式。GPU上习惯用NCHW或NHWC，到了昇腾上，CANN为了匹配Cube单元的16对齐要求，往往需要将数据转换为NC1HWC0之类的5D格式。转换本身是有开销的，如果布局切换太频繁，性能损失非常明显。理想做法是在网络入口统一转一次5D格式，中间尽量保持，减少来回切。

第三坑：轻视了HCCL通信拓扑。多卡训练时，GPU生态里NCCL会自适应拓扑选择最好路径，昇腾上的HCCL虽然也能做拓扑检测，但集群组网结构不同，效果会有差异。实测下来，HCCL对环型拓扑和树型拓扑的敏感度更高，如果发现多卡加速比不理想，先检查服务器内部的NPU互联组网和外部交换机的实际结构，再调整通信策略。

6.3 用profiling定位性能瓶颈的心法

昇腾工具链里有一整套profiling工具，比如msprof、MindStudio Profiler等。很多人的做法是跑完训练、拿到性能数据后直接盯着算子耗时看，哪个算子耗时最长就优化哪个。这个思路不能说错，但经常抓不到重点。

我更推荐按“计算利用率、数据搬运比例、同步等待比例”三个维度去分析。计算利用率如果偏低，说明Cube没有吃满，大概率是Tiling或者流水线问题；数据搬运比例如果偏高，说明数据复用没做好，优化点应在缓存重排；同步等待比例高，则是算子指令排布有问题，可能存在不必要的Barrier。先定位瓶颈属于哪一类，再下钻到具体算子去分析，效率会高很多。

我自己有一个心得：在昇腾上做性能调优，最忌讳的就是凭感觉猜。每一次改动都最好记录Tiling参数、吞吐量、利用率三组数据，对着历史曲线看变化。调优不是一个玄学问题，而是把数据搬移和计算重叠做到极致的工程问题，只要工具链能给出准确的profiling数据，大多数瓶颈都能被挖出来。

7. 写在最后的个人体会与学习建议

我自己从最初接触Da Vinci架构时的陌生，到慢慢理解这套硬件的设计逻辑，中间花了很长时间。现在回头看，最深的感受是：Da Vinci架构和GPU的设计思路，就像两条路，一条是“用通用的大量并行线程去硬刚所有问题”，另一条是“用足够专用的流水线和缓冲设计去把张量运算做到极致”。没有谁绝对更好，只看你手里的场景更适合哪条路。

如果大家想深入学习，我建议不要只看公开博客和PPT，有条件就上手真机实验。昇腾的AI Core内部细节，很多时候只有亲自写一两个算子、跑一遍profiling、对比不同Tiling参数下的性能曲线，才能真正理解为什么硬件手册要那样设计。网上资料再多，也替代不了“调一个算子的性能几小时”之后突然顿悟的快乐。

最后再分享一个小技巧：调试低层算子时，不要一开始就上大模型。先构造一个极小的输入，例如16x16的矩阵，把流程跑通，确认正确性，再逐步加大到512x512、4096x4096。这个习惯帮我排查了大量“看起来像是硬件问题，实际是自己切分逻辑写错”的坑，也希望对你有所帮助。