华为昇腾达芬奇架构NPU原理

可视化演示

展示达芬奇Cube矩阵乘法单元原理、存储层次数据搬运优化与NPU-GPU架构差异对比，切换模式理解国产AI芯片核心技术路线。

架构设计理念

蓉城小馆的老板翻完三个月的流水，发现一个规律：十桌客人有九桌都点水煮鱼。他没想着多雇几个帮厨，而是做了一件大胆的事——把整个厨房按水煮鱼的流程重新设计：灶台、案板、调料架全为这道菜服务，还请来一位只练“颠勺”这一招的神级大厨。这个决策，就是达芬奇架构的第一条设计理念：认清主力负载，然后为它量身定制。

AI 计算的世界里藏着同样的规律：卷积神经网络靠卷积核做矩阵乘，全连接层做矩阵乘，Transformer 的注意力机制里的 Q、K、V 变换还是矩阵乘——矩阵乘加操作占了神经网络计算量的绝大部分。华为工程师因此决定：不为所有场景造一个“万金油”芯片，而是为矩阵运算修一条专用“快车道”。

这就是达芬奇架构（DaVinci Architecture）的出发点：围绕矩阵乘这个核心负载做软硬协同设计。每个 AI Core 就像一个小厨房，内部集成三类单元——Cube 专心做矩阵乘，Vector 处理逐元素运算，Scalar 负责流程控制。配套的 CANN 软件栈（编译器、算子库）在设计之初就和硬件对表，让“菜谱”和“锅”一起定做，而不是先造锅再编菜谱。

$$\displaystyle \text{单条矩阵指令的乘加数} = 16 \times 16 \times 16 = 4096$$

1. 第一个 16（行数）：Cube 一次从矩阵 A 中取 16 行数据，这是大厨一次捧起的“食材行数”。

$$16_{\text{行}}$$

2. 第二个 16（列数）：Cube 同时处理矩阵 B 的 16 列数据，对应大厨一次铺开的“锅位列数”。

$$16_{\text{列}}$$

3. 第三个 16（深度）：乘积累加的共享维度 K，即 A 的列与 B 的行重叠的深度，相当于“夹心层数”。

$$16_{\text{深度}}$$

4. 连乘等于 4096：三个维度同时展开，得到一条指令触发的乘加单元总数，这就是 16×16×16 Cube 名字的由来。

$$16 \times 16 \times 16 = 4096$$

老板的“水煮鱼专线”改造完成后，大厨一次颠勺能让 4096 份食材同时入味。这条专线，就是矩阵世界里的“下单速度”——别人一道菜一道菜地炒，它一次炒一整锅。

计算单元组成

回到蓉城小馆的后厨，你会发现真正运转的是三个人的配合：大厨只负责颠勺炒大锅菜，一勺下去十几份同时熟；配菜师傅站在旁边，把每片鱼、每根豆芽单独切片、码味；前厅经理则拿着点菜单指挥节奏，决定下一道菜做什么、什么时候喊“出锅”。三个人各管一段，谁也不抢谁的活。

一个 AI Core 就是这样的“AI 厨房三人组”。大厨对应 Cube 单元，配菜师傅对应 Vector 单元，前厅经理对应 Scalar 单元。三者共用一套案板和储物架（片上存储缓冲），通过内部总线交换数据，完成一个算子的完整流水线。

• Cube 单元：16×16×16 的矩阵乘加阵列，处理卷积、全连接、注意力矩阵乘这类“大锅菜”。

• Vector 单元：向量流水线，擅长激活函数（ReLU）、归一化（BatchNorm）、逐元素加乘这类“每片食材单独处理”的活。

• Scalar 单元：标量运算，负责地址计算、循环控制、分支判断，是整个厨房的“指挥调度”。

$$\displaystyle \text{AI Core} = \text{Cube} + \text{Vector} + \text{Scalar} + \text{本地存储}$$

1. Cube（矩阵引擎）：承担乘累加密集计算，是算力主力，对应大厨的颠勺手艺。

$$\text{Cube} \to \text{矩阵乘加}$$

2. Vector（向量引擎）：处理逐元素操作，为矩阵结果做“精加工”，对应配菜师傅的刀工。

$$\text{Vector} \to \text{逐元素运算}$$

3. Scalar（标量引擎）：执行循环、跳转、地址运算，控制数据流向，对应前厅经理的调度。

$$\text{Scalar} \to \text{流程控制}$$

4. 本地存储：L0/L1 等片上缓冲，为三大单元就近供料，避免频繁跑外部内存。

$$\text{本地存储} \to \text{数据中转}$$

这三个人在同一个案板上配合：经理喊单，配菜师傅备料，大厨颠勺。AI Core 之所以高效，正因为三类单元各司其职、并行运转，让“指挥、加工、爆炒”同时进行。

Cube矩阵运算

大厨的“一次颠勺”到底神奇在哪？颠勺时，一锅 16 行、16 列的食材，每一格都要和调料层逐一接触、融合——食材是矩阵 A 和矩阵 B，融合的结果就是输出矩阵 C。这个动作在数学上叫“矩阵乘累加”，昵称 MAC（Multiply-Accumulate）。

Cube 是达芬奇架构的灵魂，它把 4096 个乘加器排成一个三维阵列，一次执行一个 16×16×16 的矩阵乘累加块。每个乘加器负责结果矩阵 C 中的一个元素，把 16 层乘积逐层“叠”进去。值得注意的是，这些乘加器全程并行：大厨不是一格一格地炒，而是整锅同时翻。

矩阵乘法 C = A × B 的规则是：结果里第 i 行第 j 列的元素，等于 A 的第 i 行与 B 的第 j 列逐对相乘后求和。卷积核滑动、全连接权重计算、注意力打分，本质上都在反复做这个动作——这也是为什么 Cube 能通吃主流神经网络。

$$\displaystyle C_{i,j} = \sum_{k=1}^{K} A_{i,k} \times B_{k,j}$$

1. C(i,j) 是结果格子：位于结果矩阵第 i 行第 j 列，它的值由 A 的第 i 行和 B 的第 j 列共同决定，相当于出锅后盘子里那一格菜。

$$C_{i,j}$$

2. 求和符号 Σ：从 k=1 扫到 K，把 K 个乘积全部加起来，相当于把 16 层夹心逐一压实。

$$\displaystyle \sum_{k=1}^{K}$$

3. A(i,k)×B(k,j)：A 的第 i 行第 k 列与 B 的第 k 行第 j 列相乘——k 是 A 和 B 共用的“媒人维度”，这一格乘积就是一层夹心。

$$A_{i,k} \times B_{k,j}$$

大厨每颠一次勺，等于把一锅食材按 16 层“夹心”压入、融合。层数越多，这道菜的味道层次越丰富；同理，K 越大，矩阵乘的信息融合越深。

指令集设计

后厨墙上贴着一张“标准动作手册”：颠勺、切丝、报单。大厨听到“颠勺”两个字，整条手臂的动作一次到位——他不需要听到 4096 个微小的指令，比如“动一下左手”“再动一下右手”。“颠勺”两个字，就是一条指令。

达芬奇架构的指令集也分成三类，对应三类单元：矩阵指令（给 Cube，一条指令驱动整个矩阵阵列）、向量指令（给 Vector，一条指令处理一组数据）、标量指令（给 Scalar，做循环和跳转）。最特别的是矩阵指令——它属于典型的“单指令多数据”风格，一条指令管住一整块 16×16 的数据。

为什么这很重要？因为指令本身有开销：取指、译码、发射都要花时间和功耗。如果一条指令只算两个数，指令开销占比就很高；如果一条指令算 4096 个数，指令开销就被摊薄到几乎可以忽略。达芬奇选择“把指令做宽”，让最频繁的矩阵乘每一趟都满载运行。CANN 工具链的任务，就是把神经网络算子编译成这些宽指令序列。

$$\displaystyle \text{单指令操作数} = 16 \times 16 = 256$$

1. 16×16 操作数：一条矩阵指令同时把 A 的一个 16×16 数据块和 B 的一个 16×16 数据块送入 Cube，共 256 个输入数。

$$16 \times 16 = 256$$

2. 累加深度 16：每个输出元素还要沿共享维度做 16 次乘积累加，把三维阵列填满。

$$\times 16_{\text{深度}}$$

3. 最终效果：指令数量大幅减少，指令发射和译码开销占比显著下降，这正是“宽指令”设计的收益。

$$\text{指令数} \downarrow \Rightarrow \text{开销占比} \downarrow$$

“颠勺”两个字管住 4096 个动作——这就是指令集设计的精髓：让最常做的动作，用最短的命令完成。矩阵指令越宽，指令流水线越省，Cube 的利用率就越高。

存储与数据流

大厨颠勺再快，如果每次要一勺调料都得跑到三条街外的批发市场去买，锅早就烧穿了。所以蓉城小馆设计了三级存放：手边调料盒（L0）、厨房冰箱（L1）、后院仓库（L2）。出菜速度的秘密，一半在颠勺，一半在“备料”。

达芬奇架构的存储层次正是这个思路。芯片外的 HBM 内存是“批发市场”，容量大但远；芯片上则铺开 L0/L1/L2 三级缓冲，越靠近 Cube 越贵越快。L0 紧贴 AI Core 内部，延迟最低；L1 在一个 AI Core 集群内共享，缓存算子中间数据；L2 是多个核心共享的大容量片上缓存，用来减少 HBM 访问。

真正考验功力的是数据搬运优化。工程师常用三招：一是数据分块，把大矩阵切成 16×16 的小块，让数据在缓存里反复复用；二是乒乓缓冲，准备两个缓冲区交替使用——Cube 算这一块时，搬运引擎同时预取下一块，把等待时间“藏”起来；三是算子融合，把多个算子的中间结果留在片上，避免写回又读出的来回折腾。

$$\displaystyle \text{有效算力} = \frac{\text{计算量}}{\text{计算时间} + \text{搬运时间}}$$

1. 分子：计算量：矩阵乘总共要做的乘加次数，这是大厨必须完成的“炒菜总量”。

$$\text{计算量}$$

2. 分母第一项：计算时间：Cube 阵列满载执行这些乘加所需的时间，对应大厨颠勺的时间。

$$\text{计算时间}$$

3. 分母第二项：搬运时间：数据从各级存储送到 Cube 的时间，对应备料和端菜的时间。

$$\text{搬运时间}$$

4. 整体含义：只要搬运时间不可忽略，有效算力就必然低于峰值——所以“备料”和“炒菜”一样重要。

$$\text{有效算力} < \text{峰值算力}$$

备料备得好，大厨不停勺。好的存储设计，就是让食材永远在触手可及的地方——这是达芬奇架构能把理论算力变成真实吞吐的关键所在。

GPU架构对比

隔壁开了一家西式快餐厨房，老板的思路完全不同：他雇了一万个小工，每人只守一个巴掌大的烤位，操作简单、动作统一。什么菜来了都能做，但一道菜要动员大量人手。蓉城小馆则相反：一位神级大厨配一条专线，在招牌菜上快到极致。这就是 GPU 与达芬奇 NPU 的路线分叉。

GPU（比如 NVIDIA A100）走的是“众核”路线：集成数千个通用小核心，每个核心一次处理少量数据，靠成千上万的线程并行取胜。这种设计非常灵活，既能做图形渲染，也能跑科学计算，连游戏都能管。而达芬奇架构走的是“大核”路线：AI Core 中的 Cube 占据主导面积，一条矩阵指令完成 4096 次乘加，矩阵密集计算效率极高。

两种路线各有天地：在卷积、全连接、注意力这类高度规则、矩阵密集的 AI 负载上，NPU 的算力密度（每平方毫米或每瓦的算力）更高；但在任务多变、算子零散、分支繁多的场景，GPU 的通用性和灵活性更从容。这也是为什么业界常说“GPU 是全能选手，NPU 是专才”。

$$\displaystyle \text{算力密度} = \frac{\text{每周期 MAC 数}}{\text{核心面积}}$$

1. 分子：每周期 MAC 数：一个时钟周期内，所有乘加单元完成的总乘加次数，相当于一次颠勺的“出菜量”。

$$\text{每周期 MAC 数}$$

2. 分母：核心面积：单个计算核心占用的芯片面积，相当于大厨灶台占的厨房面积。

$$\text{核心面积}$$

3. 比值意义：同样的晶体管预算，谁在单位面积里塞进更多有效乘加器，谁的算力密度就更高。

$$\frac{\text{MAC}}{\text{面积}}$$

一万个小工和一位神级大厨，没有绝对优劣，只有“招牌菜”之争。GPU 的灵活让它无处不在，而达芬奇 NPU 在矩阵乘这条赛道上，把“专”字发挥到了极致。

AI 应用场景

Python 演示

# DaVinci Cube simulator: tiled matmul + data movement statsclass CubeUnit:    def __init__(self, size=16):        self.size = size        self.mac_times = 0   # 累计乘加次数        self.move_count = 0  # 累计数据搬运次数     def one_instruction(self, a, b):        # 一条矩阵指令: C[16][16] = A[16][16] x B[16][16]        c = [[0 for _ in range(self.size)] for _ in range(self.size)]        for i in range(self.size):            for j in range(self.size):                acc = 0                for k in range(self.size):                    acc += a[i][k] * b[k][j]  # 乘累加核心动作                c[i][j] = acc        self.mac_times += self.size * self.size * self.size        return c     def matmul(self, a, b):        # 大矩阵按 16x16 分块, 每块对应一次 Cube 指令        n = len(a)        c = [[0 for _ in range(n)] for _ in range(n)]        for i0 in range(0, n, self.size):            for j0 in range(0, n, self.size):                for k0 in range(0, n, self.size):                    self.move_count += 1  # 记录一次数据搬运                    a_block = [row[k0:k0 + self.size] for row in a[i0:i0 + self.size]]                    b_block = [row[j0:j0 + self.size] for row in b[k0:k0 + self.size]]                    c_block = self.one_instruction(a_block, b_block)                    for i in range(self.size):                        for j in range(self.size):                            c[i0 + i][j0 + j] += c_block[i][j]  # 累加各块结果        return c  def main():    n = 32    # 构造两个可验证的矩阵: b 是 a 的转置    a = [[i * n + j for j in range(n)] for i in range(n)]    b = [[i * n + j for i in range(n)] for j in range(n)]    cube = CubeUnit()    c = cube.matmul(a, b)    # 用朴素三重循环校验分块结果    expect = [[sum(a[i][k] * b[k][j] for k in range(n)) for j in range(n)] for i in range(n)]    ok = c == expect    print("Result check:", "OK" if ok else "FAIL")    print("Total MACs:", cube.mac_times)    print("Move counts:", cube.move_count)    print("MACs per move:", cube.mac_times // cube.move_count)  if __name__ == "__main__":    main()

1. class CubeUnit:用 16×16 的“虚拟 Cube”模拟真实硬件，所有乘加走“一条指令”。
2. def one_instruction(self, a, b):对应真实 Cube 的矩阵指令，一次算完一个 16×16 输出块。
3. acc += a[i][k] * b[k][j]乘累加核心动作，神经网络里反复发生的基本运算。
4. self.mac_times += self.size * self.size * self.size每执行一条指令就积累 4096 次乘加。
5. for k0 in range(0, n, self.size):大矩阵按 16×16 分块，沿共享维度 k0 循环切块。
6. self.move_count += 1记录每次从缓存把数据块搬进 Cube 的动作。
7. expect = [[sum(...) for j in range(n)] for i in range(n)]用朴素三重循环校验分块结果是否正确。

常见误区

面试题