NPU 芯片架构，用一句话就能讲清楚

这两年只要聊到 AI 电脑、AI 手机，就一定绕不开“NPU”这个词。Intel 在酷睿 Ultra 里塞了 NPU，高通在骁龙芯片里塞了 NPU，苹果的 A 系列和 M 系列也把 Neural Engine 当作核心卖点。很多人第一次听到“NPU 芯片架构”时，脑子里冒出来的问题通常是：这和 CPU、GPU 到底有什么区别？为什么不能直接用显卡跑 AI，非得单独做一块芯片？最关键的是，各家发布会都在讲“TOPS 算力”，这个数字到底是怎么来的？

我先给结论。NPU 芯片架构，用一句话就能讲清楚： NPU 就是把成千上万个“乘加运算单元”排成阵列，让数据像流水线一样从一头灌进去、从另一头流出结果，并且在整个计算过程中尽量让数据待在离计算单元最近的地方，减少来回搬运。 这句话看着简单，但拆开之后，整个 NPU 的设计逻辑、性能指标、功耗控制，甚至开发者的优化思路，全都藏在里面。这篇文章就把这句话展开讲透，顺便把“TOPS 是怎么算的”“为什么 TOPS 高不代表体验好”“开发者怎么上手调 NPU”这些实际问题一次说清。

无论你是想搞懂 NPU 的普通用户，还是要做端侧 AI 开发的工程师，只要能把上面这句话理解透，再看任何一款 NPU 芯片的架构图，都不会觉得懵。

1. 一句话背后的三个关键词：乘加、阵列、数据流

1.1 神经网络里 90% 的计算，本质是“乘加”

先回到最底层的问题：NPU 到底在算什么？

无论大语言模型、人脸识别、图像分割还是语音转写，神经网络的基本运算是神经元之间的加权求和。一个神经元接收多个输入，每个输入乘以对应的权重，然后累加起来，再加一个偏置，最后通过激活函数输出。这个“权重×输入+累加”的过程，在数学上叫乘加运算，英文缩写是 MAC。

我举个具体的例子。假设你有一个全连接层，输入是 256 个数字，输出是 256 个数字，那这一层就要做 256×256 = 65536 次乘加。如果图像是 224×224 的彩色图，卷积核是 3×3，那第一层卷积跑下来的乘加次数直接就是百万级别。大模型动辄几十亿、上百亿参数，推理时每生成一个 Token，就要把全部参数和输入特征做一次乘加。你要是拿一个普通 CPU 来硬算这些，不是不能算，但算得很亏：CPU 的强项是复杂逻辑控制，而不是海量重复运算。

NPU 的思路很简单：既然 AI 计算里绝大多数都是乘加，那我干脆设计一大片硬件，专门干“乘加”这一件事。这片硬件不折腾复杂的分支预测、乱序执行，也不用管操作系统调度，它就像一个只做乘加的“专用工厂”。这就是 NPU 芯片架构最底层的设计哲学：用专用硬件换效率。

1.2 把乘加单元排成阵列，一秒钟算几十万亿次

单个乘加单元算一次乘加，速度再快也是有限的。NPU 的做法是堆数量：在一块芯片上摆上几百个、几千个甚至上万个乘加单元，让它们同时工作。

这里有个很关键的概念叫 MAC 阵列，也叫脉动阵列。你可以把它想象成一条多车道的生产流水线：输入数据从左边灌进来，权重数据从上方灌进来，每一排的乘加单元同时算完一次乘加之后，把结果往右传给下一个单元。数据像在“脉动”一样在阵列里有节奏地流动，所以早期 Google TPU 里采用的就是这种设计思路。后来 Intel、高通、苹果以及国内做 AI 加速芯片的厂商，在做 NPU 的时候基本都沿用了“大规模乘加阵列+数据流水”的底子，只是具体微架构各有差异。

那一片 NPU 到底能堆多少个乘加单元？以 Intel Core Ultra 里的 NPU 为例，它在 Meteor Lake 这一代大约是 11 TOPS 的算力；到 Lunar Lake 这一代直接把 NPU 算力提到了 40 多 TOPS。手机端的 NPU 更夸张，高通的 Hexagon NPU、联发科的天玑 9300 那套 APU，算力都已经到了 40 TOPS 以上。这些数字的背后，都是几百上千个乘加单元在高速运转的成绩。

这里我顺手把 TOPS 的单位说清楚，因为后面要反复用到。TOPS 是 Tera Operations Per Second 的缩写，意思是“每秒万亿次操作”。 对整数精度而言，一次乘加操作算两次运算（一次乘法、一次加法），所以 TOPS = MAC 数量 × 工作频率 × 2。 举个例子：假设一块 NPU 有 2048 个乘加单元，频率跑到 1.2GHz，那它的算力就是 2048 × 1.2 × 10^9 × 2 = 4915.2 × 10^9，大概 4.9 TOPS。你拿这个公式去套各家芯片的数据，会发现基本都能对上，因为 INT8 精度下 TOPS 就是这么算出来的。

1.3 越大的模型越怕“搬运数据”，这才是 NPU 架构的精髓

很多人看 NPU 架构图时只盯着“算力有多强”，结果忽略了 NPU 设计里最核心的瓶颈：数据搬运。

我刚才说 NPU 是一排乘加阵列，但你得想一想，数据是从哪儿来的？权重存在哪里？如果每算一次乘加，都要从内存里把数据取出来，再送到计算单元，那大部分时间都浪费在“路上”了。芯片界管这叫“存储墙”：计算单元越来越快，但内存的读取速度远远赶不上计算速度，最终整体性能被数据搬运卡死。

NPU 是怎么解决的？主要有两招。

第一招，把权重和中间结果放在离计算单元非常近的片上存储里，比如 SRAM 或者专用的暂存缓冲区。片上存储的读写速度比外接内存（比如 LPDDR5 或者 HBM）快很多，但容量小，所以 NPU 的数据流架构会尽量让数据复用：同一个输入数据，要参与多个乘加时，让它在阵列内部流转，而不是反复从内存读取。

第二招，用高带宽内存搭配。像 Intel 酷睿 Ultra 里的 NPU 走的是系统内存，和 CPU 共享带宽，这样做的好处是功耗低、成本低，适合笔记本这种设备；而数据中心里的 AI 加速芯片，比如 AMD 的 MI300 系列、NVIDIA 的 H100，走的是 HBM 高带宽内存，带宽能达到几 TB/s，因为服务器端的模型实在太大，光靠片上缓存根本塞不下整个模型参数。

所以一句话里“减少数据搬运”这六个字，其实是 NPU 芯片架构设计中最费心思的地方。你去看各家 NPU 的白皮书，会发现它们花了大量篇幅描述“数据流”“片上缓存”“带宽优化”，而不是单纯吹算力，原因就在这里。

2. 为什么 CPU 和 GPU 都不行，必须单独做 NPU

2.1 CPU 是“全能杂工”，GPU 是“并行包工头”

既然 NPU 的本质是堆乘加单元，那 GPU 不也是堆了一堆算数单元吗？为什么不直接用 GPU 跑 AI？

这话得分两面看。GPU 确实擅长并行计算，NVIDIA 的 CUDA 生态也让 GPU 成为当前 AI 训练和推理的主力。但 GPU 在做神经网络推理时有一个隐含问题：它的计算单元有自己的调度逻辑、寄存器文件和复杂的缓存层级，执行一个矩阵乘法时，需要先把数据加载到寄存器或共享内存，再让各个 SM 里的 CUDA core 并行算，算完之后还要把结果写回显存。这一套流程对图形渲染很友好，因为图形任务变化多、类型杂；但对“反复做同样乘加”的神经网络来说，GPU 的架构还是太“重”了。

CPU 呢？CPU 的优势是低延迟、强逻辑，但它每个核心的 ALU（算术逻辑单元）数量很少，大多数面积都分给了控制单元、缓存和分支预测器。拿 CPU 来跑大模型推理，会陷入“计算单元不够多、并行度上不去”的尴尬。

NPU 走的是另一条路：它把控制逻辑简化到极致，把版图面积几乎全部让给算数单元和片上缓存。没有复杂流水线，没有乱序执行，没有为了兼容各种指令集而保留的冗余逻辑。就是一块纯粹的、为矩阵乘法定制的工厂。这也是为什么同样是跑 ResNet 这种经典网络，NPU 的能效比往往比 CPU 高一个数量级、比 GPU 也高好几倍的原因。

2.2 从 GPU 到 NPU：算力数字游戏背后的精度差异

这里插一个很多人踩过的坑：看芯片算力时，一定要分清精度。GPU 标称的算力通常是 FP32（单精度浮点）或 FP16（半精度浮点）下的算力，而 NPU 标称的算力往往是 INT8（8 位整数）下的算力。同样是 10 TOPS，FP16 和 INT8 的计算量差别很大，因为整数运算在硬件上要比浮点运算简单，能塞进去的乘加单元更多、跑得也更快。

实际做端侧 AI 推理时，除非模型严格要求高精度，否则模型都会做量化：把 FP32 的权重压成 INT8，甚至 INT4。量化之后的模型体积变小、计算变快，精度损失通常在可接受范围内，这是 NPU 能跑到“几十 TOPS”的重要前提。你会发现很多 NPU 在支持 INT4 之后，标称算力还能翻倍，原因就在于数据位宽小了，同一批硬件单元单位时间内能处理的数据元素更多了。

所以在对比芯片编号里的 AI 算力时，一定先看精度条件。Intel 酷睿 Ultra 的 NPU 在 INT8 下是 11 TOPS，到了酷睿 Ultra 200V 这一代官方标称 INT8 下的 NPU 算力达到 48 TOPS，数字大了不少，但架构改动其实并不是推倒重来，更多是：阵列规模扩大、频率提升、内存带宽加宽、数据复用逻辑优化。这背后就是“TOPS = MAC 数量 × 频率 × 2”这个公式在起作用。

2.3 脉动阵列与近存计算：NPU 架构的两种流派

说到 NPU 架构的具体实现，行业内大致能分成两类思路：脉动阵列派和近存计算派。

脉动阵列派，代表是 Google TPU 和不少国内 AI 芯片公司的产品。这种架构的特点是乘加单元之间直接相连，数据按固定节奏从一个单元传到下一个单元。好处是数据复用率高、功耗低，特别适合卷积运算；坏处是对不规则模型（比如稀疏矩阵、动态形状的网络）支持不够灵活，一旦某个计算路径不是标准的矩阵乘加，脉动阵列的利用率会大幅下降。

近存计算派，更强调“计算靠近数据”。比如把存储单元和计算单元做到同一个裸片上，或者用先进的 2.5D/3D 封装把高带宽内存和 NPU 紧贴在一起。华为昇腾、AMD 的 CDNA 架构、以及国内 BR100 系列芯片架构这类偏数据中心的产品，走的都是“大算力+高带宽内存”的路线。BR100 系列在做架构设计时就把“存算一体”和“片内互联”当作重点，因为这类芯片跑的是千亿参数模型，模型权重根本放不进片上缓存，内存带宽几乎决定了下限。

这两种流派没有绝对优劣，更多是设计目标差异：终端设备里的 NPU 追求低功耗、小面积，脉动阵列更合适；云端 AI 芯片追求超大算力、超大带宽，近存计算和 HBM 才是主流。你只要记住“计算单元+存储层次+数据流动方式”这三位一体的框架，再看任何一张 NPU 架构图，都能快速摸清它到底属于哪个流派。

3. 开发者视角：NPU 不是“怼上去就能用”，得按规则办事

3.1 笔记本和手机里的 NPU 到底在跑什么任务

很多人以为自己电脑里的 NPU 会主动帮自己跑大模型，日常使用就能体会到“AI 加速”。实际上，NPU 只负责“低功耗、持续运行”的 AI 推理任务，大规模计算仍然主要靠 GPU。那它到底在跑什么？

以装了 Intel NPU 的笔记本为例，最典型的应用是视频会议背景虚化、眼神修正、语音降噪。这类任务需要在视频通话全程持续运行，如果用 GPU 来跑，功耗会明显拉高、风扇狂转；用 NPU 跑，功耗只有几瓦，后台挂着完全不打扰。Windows 11 里的 Studio Effects、Camera Effects，还有剪映、Adobe 这些软件里的 AI 特效，在 Intel 的 AI PC 上都会优先调度到 NPU 执行。手机端的 NPU 也是类似逻辑：人脸解锁、夜景拍照、语音助手唤醒、输入法预测，基本都是 NPU 在后台默默算。

所以别指望 NPU 能替代 GPU 跑 Stable Diffusion 或者大语言模型的本地推理。端侧大模型确实也在往 NPU 上迁移，但目前大部分本地大模型跑的推理（比如用 Ollama 跑 Llama 3）主要调用的还是 GPU 或 CPU，NPU 只参与部分算子。Intel 的 OpenVINO 工具链一直在做 NPU 推理优化，支持的模型也越来越多，但要真正“让 NPU 跑满”，还需要模型本身针对 NPU 的指令集和内存布局做适配。

3.2 开发者怎么调用 NPU：OpenVINO、ONNX Runtime 与厂商 SDK

这里分享几个实际的开发路径，方便想自己上手调 NPU 的人参考。

如果你的设备是 Intel 平台，建议从 OpenVINO 开始。OpenVINO 是 Intel 开源的推理工具套件，它的工作方式是把训练好的模型（比如 ONNX、PyTorch、TensorFlow 格式）通过模型优化器转换成一个中间表示，然后让 runtime 根据底层硬件自动选择 CPU / GPU / NPU。你只需要在代码里设置 device_name = "NPU" ，OpenVINO 就会尝试把模型编译到 NPU 上。我在实际测试里发现，OpenVINO 跑一些经典分类模型到 NPU 上是比较省心的，但如果是结构特别复杂、有不规则算子的模型，编译时间会变长，偶尔还要手动关掉某些“不支持的算子”才能跑通。

如果你不想绑定某家平台，可以走 ONNX Runtime 的通用路径。ONNX Runtime 有 NPU execution provider，但最终是否生效仍取决于芯片厂商有没有提供对应的 backend。Intel 的 OpenVINO EP 就允许你在 ONNX Runtime 里把部分算子上推到 NPU，但配置步骤比直接用 OpenVINO API 要繁琐一些。

还有一个比较通用的方案是 Windows ML 。Windows 11 的 DirectML API 本身支持 NPU，微软和 Intel、高通、AMD 都有合作。很多 Windows AI 应用最终调的是 WinML 或 DirectML，系统会按照算子的支持情况自动分配到 CPU、GPU 或 NPU。用这种方式开发的优点是兼容性好，缺点是“谁能跑在 NPU 上”完全取决于系统驱动和厂商支持，可调性不高。

我给新手的建议是：先看厂商的 SDK（Intel OpenVINO、高通 AI Engine Direct、苹果 Core ML），模型先用 ONNX 作为中转格式，推理框架不要一上来就选“全自动调度”，要手动看一眼日志里到底哪些算子落到了 NPU 上。别问我怎么知道的，我在调试时见过太多“代码里写明了用 NPU，结果调度器一声不吭全塞给 CPU”的场面。

3.3 为什么说“TOPS 高≠体验好”：软硬协同才是关键

很多用户在选 AI PC 或 AI 手机时，只对比 TOPS 数字：这个是 40 TOPS，那个是 48 TOPS，就觉得后者一定更强。这个想法在真机实测中经常翻车。

原因有三个。第一，TOPS 是理论峰值，实际利用率要看模型形状和 NPU 阵列是否匹配。如果模型是稀疏的或者形状不规则，乘加阵列的利用率可能只有 50% 甚至更低。第二，内存带宽常常是瓶颈。一款 NPU 就算算力再高，如果内存带宽跟不上，数据搬运时间会轻松超过计算时间。这就像一条高速流水线，接口太窄，原料送不进去，机器再快也没用。第三，软件栈成熟度非常关键。同一颗 NPU，在不同驱动版本、不同工具链下，性能差距可以很夸张。Intel 在 Lunar Lake 上 NPU 算力翻了四倍多，但实际 AI 应用能不能把 48 TOPS 用满，还得看开发者有没有针对 NPU 做算子融合和量化优化。

所以选设备或做开发时，别只盯 TOPS 这个数字，更要看三件事：内存带宽是多少，NPU 支持哪些精度（INT8 / INT4 / FP16），厂商的软件工具链支持的模型算子有多全。这三项才是决定日常体验的硬指标。

4. 存储架构与高带宽设计：NPU 性能的真实瓶颈

4.1 “存储墙”问题：算得再快，也要等数据

我之前提到 NPU 的重点是“减少数据搬运”，现在展开说说为什么这个问题的优先级比提升算力还要高。

芯片内部数据的读取速度，大致是这个趋势：寄存器 > 一级缓存 > 二级缓存 > 三级缓存 > 内存 > 硬盘。每往下一层，容量变大，但延迟也大幅增加。NPU 和 CPU 完全不一样：CPU 对单线程低延迟有强烈的需求，所以设计了很多层缓存，但 NPU 对单次读取延迟没那么敏感，它更关心“吞吐量”——也就是单位时间内能读取多少数据。

如果一个 NPU 的算力是 40 TOPS，意味着每秒要执行四万亿次乘加操作。哪怕每次乘加只需要读取 4 字节的数据，每秒要搬进搬出的数据量也是非常恐怖的数量级。如果这些数据全部走内存，内存接口的带宽会立刻被打爆。所以 NPU 的片上缓存设计必须保证“热点数据”能尽量留在片内，比如常用的权重切片、上一层的激活输出，一旦用完之后再丢弃，避免重复从内存读取。

这就是为什么 Intel 在 Lunor Lake 的 NPU 里加大了片上存储，同时让系统内存带宽跟上；这也是为什么数据中心 AI 芯片一定要配 HBM。HBM 不是普通内存，它通过硅中介层和 NPU 紧贴，用 2.5D 封装做到 TB/s 级别的带宽。 闪存芯片架构 虽然看着跟 NPU 无关，但本质上也是存储层次设计的问题：存储介质离计算单元越近，数据交换越快，系统整体的有效算力才越高。你只要把 NPU 想成一个“吃数据怪兽”，就会明白带宽和存储架构的重要性完全不亚于计算单元本身。

4.2 数据流架构怎么决定 NPU 的“脾气”

NPU 架构里还有一个很影响实际性能的设计叫“数据流”（dataflow）。同样是做矩阵乘法，不同数据流模式会带来完全不同的功耗和性能。

常见的三种数据流是：

• 权重固定（weight stationary）：权重预先加载到乘加阵列里，输入数据流过来，权重留在原地被反复复用。适合卷积层，因为同一组卷积核要和很多输入位置做乘加。
• 输入固定（input stationary）：输入数据留在阵列内，权重流式传入。适合某些整形算子多的网络。
• 输出固定（output stationary）：累加结果留在阵列内，每次乘加都是往同一个地方累加，减少写回内存次数。适合全连接层和矩阵乘法。

实际设计时，NPU 往往不是只采用一种数据流，而是会根据算子类型动态调整。这个灵活性决定了它对不同模型的适配度。有些 NPU 跑 CNN 飞快，一跑 Transformer 就慢得要命，很可能就是因为它的数据流只针对卷积做了深度优化，而 Transformer 里大量的矩阵乘法（MatMul）需要完全不同的数据复用方式。

所以在做端侧 AI 开发时，我建议先把 NPU 的算子支持表和 benchmark 结果翻出来看一遍。如果你主要跑 Transformer 类模型，就重点看它在 MatMul、Softmax、LayerNorm 这些算子上的表现。不要只看厂商宣传的“XX 模型跑出 XX TOPS”，这个数字通常只挑了最合适的算子组合。

4.3 从 BR100 系列芯片架构看高性能 AI 芯片的设计方向

提到数据流和存储设计，很多人的第一反应是 NVIDIA、AMD 这些国外大厂。但这两年国内做 AI 加速芯片的公司也陆续推出了自己的产品，其中 BR100 系列芯片架构就是一个典型的“大芯片”思路：内部集成大规模计算阵列，利用类似 HBM 的超高带宽内存架构，目标是在服务器级别跑大规模 AI 推理和训练。

BR100 系列芯片架构给行业的一个启示是：超大规模 AI 芯片，瓶颈早已不是“能把多少计算单元塞进一块芯片”，而是“能为这些计算单元喂多少数据”。所以你看这类芯片的架构图，最显眼的部分除了计算核心，就是内存控制器、片上网络和高带宽接口。相对于终端 NPU 追求面积和功耗的平衡，数据中心芯片更倾向于“用大面积的存储和互连换取极高的有效算力”。

这也解释了为什么这两年“存算一体”“Chiplet 芯粒”“2.5D/3D 封装”这些词越来越热。它们本质上都在解决同一个问题：让计算单元周围的数据搬运距离更短、搬运通道更宽。对普通开发者来说，不需要直接接触这些底层设计，但理解这个趋势，能帮你更好地理解厂商 PPT 上那些天花乱坠的架构图背后到底在比什么。

5. 常见误区与实战排查：NPU 调试中的五个坑

5.1 别把所有 AI 任务都塞给 NPU，它不是“万能加速器”

我自己调试 NPU 时遇到的最典型误区，就是“只要模型能跑，就让它跑 NPU”。NPU 的真正优势是低功耗、持续推理，而不是低延迟、高吞吐。有些小模型（比如 1-2B 的大语言模型）在 GPU 上跑一次推理只要几百毫秒，搬到 NPU 上可能反而要好几秒，因为数据从系统内存搬到 NPU、算子编译、矩阵切分的开销非常大。

谁适合用 NPU？我给你一个简单判断标准：任务需要长时间运行、对功耗敏感、对单次延迟要求不极端。比如视频流里每一帧做人脸检测、录音时实时降噪、摄像头里做物体追踪，这些任务一开就是几小时，用 NPU 再合适不过。但如果你只是偶尔让 AI 画一张图、生成一段文字，直接让 GPU 干活省心得多，不要为了“用上 NPU”而强行分配任务。

5.2 跑分很高，实际应用却卡？先查数据搬运路径

一个很容易被忽视的排查点：数据在哪、怎么送进 NPU。在 Intel 平台上有时候会出现一种情况，模型编译是成功了，但每次推理时数据需要通过主机 CPU 拷贝到 NPU 驱动管理的内存区域，这一来一回多花好几毫秒。单次看不出问题，但如果模型是流式处理的，帧率就会被拖垮。

排查方法很简单，用厂商提供的 profiler 工具看每一层算子的时间分布。OpenVINO 有 benchmark_app，会输出每层在 NPU 上的耗时；如果在某个“copy”或“convert”节点上耗时特别大，说明数据布局和内存格式没对齐，需要在接入 NPU 前先做一次张量布局转换。这种“隐藏耗时”在官方跑分里通常不会体现，但在真实业务场景中非常致命。

5.3 驱动版本和固件更新，直接影响 NPU 能不能正常工作

这个坑说出来可能显得很基础，但实际发生频率极高。NPU 不同于 CPU 和 GPU，它的指令集和功能实现高度依赖固件和驱动。我见过一个案例：某台 AI PC 刚到手时 NPU 在设备管理器里显示“未知设备”，Windows 的 Studio Effects 完全无法启用，折腾半天最后发现是厂商预装驱动版本太老，去官网更新了一个几十 MB 的驱动包，问题立刻解决。

另外，NPU 的算子支持表也经常随驱动版本更新而变化。同一个 ONNX 模型，旧驱动编译可能报“不支持某个算子”，更新驱动之后就正常了。所以在验证 NPU 功能时，第一步永远是确保驱动和 AI 推理框架版本最新。不要小看这一步，它能帮你省掉后面 80% 的疑难杂症排查时间。

5.4 量化精度要自己验证，别信“INT8 无损”的宣传

量化是把 FP32 模型转成 INT8 或 INT4 的常用手段，但量化一定会带来精度损失，只是损失大小因模型而异。我做图像分类模型量化时，Top-1 准确率掉 0.1% 以内很常见，但遇到注意力模块占比高、敏感度大的模型，掉 2% 也不奇怪。关键是一定要在你自己的测试集上做验证，而不是信“这个模型量化后无损”的传闻。

具体做法是：把原始模型和量化后的模型都在同一批测试样本上跑一遍，对比输出结果和置信度变化。如果精度损失超过业务容忍范围，可以考虑只对部分敏感层保留 FP16 计算，混合精度方案在 OpenVINO 和 ONNX Runtime 里都能配置。这属于比较精细的调优，但对质量要求高的业务很值得做。

5.5 内存带宽不够时，模型再小也可能跑不快

最后聊一个我在测试小模型时踩过的坑。有一次跑一个不到 100MB 的检测模型，心想 NPU 算力 40 TOPS，这模型顶多占几笔毫秒吧？结果实测延迟比预期高了一倍多。后来用 profiler 一看，瓶颈不是计算，而是权重反复加载：模型的某些层数据复用性差，每次都要从系统内存重新把权重拉回 NPU 片上缓存，内存带宽成了天花板。

解决办法有两个方向：一是改写模型结构，把连续计算的层尽量融合，减少中间结果的写回和重新读取；二是检查 NPU 驱动或推理框架是否做了权重常驻优化（weight caching）。Intel 的 OpenVINO 里有一个“模型缓存”选项，开启后能显著减少重复编译，某些场景对推理延迟也有帮助。这种问题没法靠买更高算力的芯片解决，必须从系统层面去优化数据流。

写在最后：NPU 架构没那么玄乎，核心是把数据喂饱

我接触 NPU 开发的时间越久，越觉得它不像想象中那样高深。芯片厂商的架构图动辄画几十个模块、标一堆缩写，但剥开外壳，你永远能回归到三件事：有多少乘加单元、数据用什么方式流进去、数据搬运的通道有多宽。只要把这三件事想明白，你就能理解为什么某些 NPU 跑 CNN 很强、跑 Transformer 却一般，为什么 TOPS 高不一定代表体验好，为什么内存带宽和数据流架构有时候比算力数字更重要。

如果你正打算基于 NPU 做开发，我的个人经验是：不要太早在不同硬件之间纠结“谁的 TOPS 更高”，先把某一家的工具链吃透，跑通一个真实任务的垂直打通，再做横向对比。算力数字可以帮你缩小选型范围，但真正决定项目成败的，永远是你对数据流的理解和软件栈的熟练度。这套思路，放到手机 NPU、PC NPU、甚至 BR100 系列那种大芯片上，都适用。