NPU和GPU差别--AI算力对比

微信视频号：sph0RgSyDYV47z6

快手号：4874645212

抖音号：dy0so323fq2w

小红书号：95619019828

B站1：UID:3546863642871878

B站2：UID: 3546955410049087

NPU就像个从小就被培养成"AI专家"的孩子。他从出生开始就专攻"矩阵乘法"（GEMM）这个AI核心技能，后来才慢慢学了点"标量"和"向量"处理这些附加技能。他走的是"先专精，再扩展"的路线。npu是“去肥增瘦”，将有限的芯片面积和功耗预算极致地投入到AI计算最核心的运算单元上，例如大规模乘加器阵列，用于高效执行矩阵乘法和卷积运算。所以NPU在能效比上表现不错。但这种高度专用化也带来了代价，NPU控制单元非常简单甚至缺失，更像一个受CPU严格指挥的“协处理器”。它的片内存储层级（如L0A/L0B/L0C、UB等）通常是静态划分的，虽然为特定计算路径做了优化，但也可能导致数据流转不够灵活，存在瓶颈。

而GPU呢？它本来是个搞图形渲染的"全能选手"，就像个啥都懂的老师傅。后来AI火了，他就在原来的基础上加了个"AI加速器"（Tensor Core），但还是保留了他原来那些"基本功"——那些CUDA核心。他走的是"先通用，再加AI"的路线。它拥有数千个计算核心（CUDA Core）和复杂的控制逻辑（如Warp Scheduler）。虽然最初为图形渲染设计，但其大规模并行能力恰好契合了AI训练的需求。GPU架构是“CPU + GPU + DSA”的层级模式。在通用CUDA Core之上，又增加了专为张量计算设计的Tensor Core，形成了通用计算与专用加速的协同体系。其存储层次主要基于Cache（缓存），对程序员更友好。

下面从四个角度阐述一下npu和gpu的差别，包括硬件架构、编程模型、访存时延方差、内存管理。

一、硬件架构

NPU和GPU的硬件设计思路完全不同，这直接框定了它们的“能力上限”。简单说，NPU走的是“数据流/脉动阵列”路线，也就是“矩阵计算单元”，主打“让数据批量并行跑”；而GPU用的是咱们熟悉的“冯·诺依曼架构”，靠“SIMT（单指令多线程）”堆并行能力，主打“让线程批量并行跑”。这两个在物理设计上差别是比较大的，可以说是完全不同的两个芯片，之所以将NPU和GPGPU放在一起对比，纯粹只是因为它们都是用在大模型上的。

hw910C：流水化操作，专算矩阵

• 它的达芬奇架构里藏着3D Cube计算单元，靠多维指令把矩阵运算速度拉满。每个AI Core里有三个“干活的单元”：标量、向量、矩阵计算单元，还有个DMA单元专门负责搬数据。它的工作流程特像流水线：标量单元先读指令，再把“算向量”“算矩阵”“搬数据”的活分给对应单元，各单元同时开工。

NVIDIA H100：靠多线程“堆火力”

• H100用的是SIMT架构，每个“流式多处理器（SM）”里塞了128个FP32 CUDA核心、4个Tensor Core，还有一堆内存控制器。一个SM又分成4个相同的“分区”，共享L1缓存和256KB的共享存储，每个分区还有自己的小缓存、调度器和寄存器。

再说说内存设计，二者存数据的思路也是不一样的：

• NPU是“固定路线”：比如昇腾的 data 得走“DRAM→UB→L0A/L0B→Cube→L0C→核外存储”这条路，还得按特定格式切块（比如切成16×16的矩阵），像你坐地铁必须按站点走，灵活度差，但特定场景下数据复用率特别高，但片上缓存小，得手动切块数据。
• GPU可以理解为打车：H100用HBM3配合L1、L2缓存，能自动预取数据、合并访问请求，打车能绕路也能抄近道。

二、编程模型

GPU的SIMT模型

• GPU用的是SIMT（单指令多线程）模型，线程按32个一组（叫Warp）打包，遇到数据访问慢的时候，能自动切换Warp干活，把延迟“藏起来”。比如写CUDA代码，你不用管并行怎么实现，就写普通的标量代码，硬件自己搞定。像H100，靠Warp调度器切来切去，让CUDA核心一直忙，不会因为等数据就闲着；Tensor Core算矩阵的时候，也靠调度器自动分资源，不用我们操心。
• GPU的内存模型特别像一个多层仓库： 全局内存：大仓库，所有线程都能用，但有点远 共享内存：每个线程块的小仓库，速度快 寄存器：每个线程的小口袋，最快

NPU的SIMD模型

• NPU用的是SIMD（单指令多数据）模型，比如昇腾的AI Core，得靠标量单元控制向量、矩阵单元干活，数据还得自己切成块（比如Cube要16×16的矩阵），再用队列管理任务流程。这就麻烦多了：你得明确告诉数据怎么切、走哪条内存路径，稍微没弄好就影响性能。比如在昇腾上写算子，块切太小了，数据就得频繁搬来搬去，算力直接浪费。

还有个关键差别：GPU能自动“掩盖延迟”，比如处理非结构化数据、预测分支的时候，Warp调度器一换就能适应；但NPU没这本事，得你提前把数据预处理好，不然就容易卡壳。这就是下面的“如何解决访存时延方差？”。

三、如何解决访存时延方差？

工艺的进步让堆砌计算单元（如Tensor Core、Cube）变得相对直接，但让成千上万个计算核心同时满负荷运转，关键就在于如何持续、高效地为计算单元“喂数据”，这就是著名的“内存墙”问题。

“访存时延的方差”可以理解为数据在“仓库”（如显存/HBM）和“车间”（计算单元）之间运输时间的不确定性。

• 理想世界：每次数据搬运都像在空旷的高速公路上行驶，耗时固定。程序员可以像排班一样，精确地安排计算任务，让计算时间刚好掩盖住数据搬运的时间，实现流水线永不间断。

• 现实世界：这条数据高速公路会堵车。 traffic jam 可能源于多个计算单元同时抢用带宽（拥塞），也可能因为内存自身需要“休息”（如DRAM Refresh），还可能遇到需要绕行的“复杂路口”（如复杂的算子融合）。这就导致访存延时从一个固定值，变成了一个波动巨大的变量——其最坏情况（P90/P99延时）可能是平均延时的数倍。

处理这种巨大的方差，NPU的Dataflow架构和GPU的SIMT架构采取了不同的思路。

• NPU/Dataflow：走精确调度路线

NPU（如谷歌TPU、hw昇腾）采用的Dataflow架构，NPU的架构是"固定时延"的，要你提前规划好每一步，数据怎么走、什么时候走，都得算得明明白白。它希望数据来得稳稳当当，不带波动。让编译器或开发者提前算好，把数据分块、预处理、安排好时间，就像提前算好堵车时间，绕道走一样。现实的堵车是随机的啊！DRAM可能因为refresh暂停响应，访存时延就变得忽快忽慢。在训练的过程中，大量数据需要在GM以及 UB之间搬移，如果带宽不足，Cube kernel训练效率就没那么高了。这就是NPU的痛点，它需要提前知道数据什么时候来，而现实是数据来得没准儿。所以NPU得做很多"最坏情况"的准备，导致它需要更大的片上SRAM，还要考虑Prologue和Epilogue。

在编译阶段就静态地规划好所有数据的流动路径和时机。它假设数据搬运的延时是基本可控的。通过复杂的编译器技术，将计算分解成一系列步骤，让数据在计算单元和片上缓存（如Unified Buffer）之间高效流转，尽可能复用数据，减少去“很远的仓库”（全局内存）取数的次数。

在理想情况下，这种静态规划能达到极高的能效和计算密度，因为几乎没有调度开销。然而，一旦现实偏离预设（访存延时出现巨大波动），整个精心编排的流水线就会被打破。一个环节的延迟会迅速波及后续所有环节，计算单元只能停工待料，导致效率骤降。这要求我们必须手动优化，门槛极高。

这也是为什么NPU的软件要求简直比硬件还难搞。地址控制简单得连个线程延迟隐藏机制都没有，防存延迟全靠程序员自己硬扛——内存切分得像走钢丝，L1小块还带bank冲突，切大了卡死，切小了性能掉链子。hw虽把软件生态做得最好，但比起GPU的CUDA，还是得自己搭桥铺路：编译器团队在硬磕，TVM/MLIR饼画得再大，也比不上手写算子的流畅。

• GPU/SIMT：搞人海战术

GPU的SIMT（单指令多线程）架构，是用“人海战术”掩盖这个问题的。

Warp调度器：这是GPU的秘密武器。它将大量线程（如32个）打包成一个Warp（线程束）。当某个Warp因为等待数据而“卡住”时，硬件调度器会立刻将其挂起，并迅速切换到另一个已经数据就绪的Warp执行计算。gpu把32个线程打包成一个Warp（就像32个司机组成一个车队），当一个司机在等红灯（访存延迟）时，GPU立马让另一个司机先走，32个司机轮着来，把堵车时间完美掩盖过去。

这种动态的、硬件级的线程切换机制，使得GPU能够主动地“隐藏”访存延迟，而不是被动地“预测”它。无论某个数据搬运因为什么原因被延迟，计算单元几乎总能有其他准备好的任务可以执行，从而保持忙碌。这本质上是用硬件的复杂度（额外的调度器、巨大的寄存器文件来保存大量线程的上下文）来换取软件的简易性和架构的稳健。

说白了，GPU的SIMT就是"让硬件来扛堵车"，而NPU的Dataflow是"让软件来扛堵车"。

四、内存管理

数据怎么存、怎么传，NPU和GPU的策略也完全不同：NPU要“按硬件规矩预处理”，GPU则能“动态调整”，这直接关系到AI模型跑起来快不快。

NPU的“固定路线”：一步都不能错

• 昇腾的数据得走固定的“多级Buffer路线”：DRAM→UB→L0A/B/C→Cube→L0C→核外存储，少一步都不行。更麻烦的是，Cube算出来的结果，不能直接给下一个Cube用，必须先传到UB中转，你从厨房拿了菜，不能直接放餐桌，得先放客厅茶几，灵活性差一点。比如没做“算子融合”的时候，卷积算完的结果得传到核外存储，等做批量归一化的时候，又得把数据搬回AI Core，来回折腾，计算单元就得等着，性能自然掉下来。

GPU的“灵活调度”：能省则省

• GPU用的是动态缓存，能自动预取数据、合并访问请求，比如Tensor Core算的时候，会把多个线程的请求整合起来，一次传一大块数据，省不少时间。H100的TMA引擎还能异步传数据给Tensor Core，不会让计算单元等数据。比如跑反向传播这种“数据依赖多”的任务，GPU的缓存能自动复用数据，减少延迟；而NPU呢，数据搬运的功耗甚至比计算本身还高，能效比就容易出问题——比如昇腾没做算子融合时，反向传播要多次访问全局内存，性能一下就下来了，而GPU靠共享内存合并请求，能少跑好几趟。

 

 

微信视频号：sph0RgSyDYV47z6

快手号：4874645212

抖音号：dy0so323fq2w

小红书号：95619019828

B站1：UID:3546863642871878

B站2：UID: 3546955410049087

 

参考文献链接

https://mp.weixin.qq.com/s/9IgmTIlL28g7QxrUMXqcHA