NPU数据流设计：从HBM到Shared Memory的带宽优化实战

做NPU开发这几年，我越来越觉得一个朴素的道理：计算引擎永远在等数据。主频、MAC阵列规模决定了理论算力，但实际跑一个卷积层，吞吐多少往往由数据能不能按时喂到位决定。这个“喂数据”的链路，就是本系列第三章要聊的核心——NPU的data flow，从HBM开始，经过DMA搬运，落到多bank Shared Memory，最后才轮到计算单元。这条链路设计得好不好，直接决定利用率是30%还是90%。

这一章内容会比较长，因为链路上有太多细节值得展开：HBM为什么采用三维堆叠而不是简单加宽总线，DMA描述符怎么配置才能把带宽跑满，多bank Shared Memory为什么反而会带来bank冲突，等等。适合读的人面很宽——做AI芯片架构的、写算子库和底层库的、搞编译器优化和后端的，还有对体系结构感兴趣的读者都可以参考。下面进入正题。

1. 为什么NPU的数据流这么难设计——整体思路拆解

1.1 计算引擎的“喂饭”问题

打个比方。你去餐馆，厨师手艺再高，如果配菜小哥不能按时把菜送到灶台边上，出菜速度照样上不去。NPU里的MAC阵列就是那位厨师，HBM是仓库，Shared Memory是案板，DMA就是那个配菜小哥。很多人在评估NPU性能时只盯着算力数字，比如多少TOPS、主频多少，但真正跑起来你就会发现，计算单元经常在空转——不是不想算，是数据没到。

这其实就是冯·诺依曼瓶颈的延续。CPU时代我们就在跟内存墙作斗争，到了NPU这里问题更严重，因为卷积和矩阵乘法这类操作的数据复用性极强，同一个权重可能被几百个激活像素复用。如果每一份数据都从外部内存现取，外部内存的带宽根本扛不住。做个简单估算：一个典型的3x3卷积层，假设某个特征图是64通道、128x128分辨率，权重量大约就是64x64x3x3，约14.7万个数，激活量更大。如果这些全部实时从外部取，再快的总线也会被压垮。

所以NPU设计的第一原则就是：能放片上就放片上，能搬一次就不搬两次。数据流设计解决的就是“什么数据、什么时候、放在哪、谁负责搬”这四个问题。思路清楚了，后面所有优化都是围绕这四个问题展开的。

1.2 数据流三件套：HBM、DMA、多bank Shared Memory

整条链路可以拆成三段。第一段是HBM，它是外部存储的顶级形态，负责把海量权重和激活放在离计算引擎不太远的地方；第二段是DMA引擎，它负责执行实际的搬运动作，把HBM里的数据块搬进片上；第三段就是多bank Shared Memory，它是片上数据的中转站和缓存区，计算阵列直接从这里面取数。

一条典型的数据流是这样走的：权重从HBM通过DMA搬运到Shared Memory的权重区，激活图通过DMA搬运到激活区，计算阵列从这两个区取数做乘加，中间结果写入Shared Memory的临时区，最后再由DMA把输出结果写回HBM。

注意一个关键点：搬运和计算要重叠。最理想的状态是DMA在搬下一块权重的时候，MAC阵列正在算当前这块数据。如果搬运和计算串行执行，也就是先搬完再算、算完再搬下一步，那性能会非常难看。比如某层计算只需要5微秒，搬运要花4微秒，串行做是9微秒，但重叠后总耗时可能只有5微秒多一点点，接近翻倍性能。流水设计就是整个数据流的灵魂。

1.3 为什么不能直接照搬CPU的缓存方案

有人会问：CPU不是有cache吗？GPU不是有庞大的线程池来掩盖延迟吗？NPU直接照搬不就行了？

问题在于NPU的应用场景和设计目标跟CPU、GPU有很大的差异。CPU追求通用性，跑的程序五花八门，所以用硬件自动帮你缓存、预取，你写代码不用关心数据在哪一层cache里；GPU追求高吞吐，靠成千上万个线程轮换着访问内存，单个线程延迟高没关系，整体吞吐照样能拉满。但NPU不一样，NPU面向的是相对固定的深度学习算子，追求确定性和能效比。它没有那么多线程来轮换，也不希望硬件做太多不可控的预取决策，因为深度学习计算的数据访问模式是高度规律、完全可预测的。

所以绝大多数NPU都走“显式数据搬移”的路子：编译器或算子库明确告诉DMA要搬哪块数据、搬到哪个缓冲区，计算引擎就在那里等。这种设计的代价是软件变得复杂，对工程师要求更高，但收益是性能和功耗都可预测。你写算子时，每一轮数据在哪、什么时候到位是清清楚楚的，不会出现CPU上那种“明明数据在内存里，却因为cache miss卡一下”的不可控情况。

2. HBM：把存储墙往前提一层的高带宽内存

2.1 HBM到底解决了什么

传统DRAM的问题可以总结为“位宽上不去、频率也上不去”。DDR内存走的是内存条上的一根根走线，接口宽度有限，要提升带宽只能靠提高频率，而频率越高信号完整性和功耗问题越严重。HBM的思路完全不一样：它把多层DRAM裸片垂直堆叠在一起，通过硅通孔（TSV）从每一层直接穿透连接到下方的逻辑基片上，于是接口宽度可以做得很宽——远超过传统DDR总线。

怎么理解这件事？你可以想象一排抽屉立在墙边，每次只能用两只手取一本文件；HBM则是把抽屉竖着堆起来，每层抽屉都开着口，你的一整只手臂能同时伸进去抓一叠文件出来。传统DDR是频率快但每次拿得少，HBM是频率不那么夸张但一次拿一大把，综合下来带宽高得多，而且因为不用疯狂拉频率，功耗也相对友好。

落到数字上：常见规格的HBM2E单颗理论带宽就能到400GB/s以上，HBM3还能翻倍到800GB/s甚至更高。这对NPU意味着什么呢？意味着一个20MB的权重矩阵，用1TB/s左右的有效带宽搬运，20微秒出头就能进片上内存。这个量级对计算单元来说是能喂饱的。

2.2 带宽、伪通道与读写延迟的权衡

HBM内部并不是一块完整的大内存，它被切成很多个“伪通道”（pseudo channel）。每个伪通道有独立的命令和数据接口，可以独立响应访问请求。这样设计，访问并行度大幅提升，多个请求可以同时分散在不同伪通道上执行，互相不干扰。

但伪通道的引入也让地址映射变得讲究。如果你把连续数据一股脑塞进同一个伪通道，那这个通道会成为热点，其他通道闲着，总带宽大打折扣。所以HBM控制器会在地址上做交叉（interleaving），让连续地址均匀分布在各个伪通道之间。比如地址每隔几个KB切换一个伪通道。这样CPU或DMA发起的连续大块访问，实际会被HBM控制器拆成多个并行小事务，带宽自然就上去了。

另外还有一个绕不开的物理现实：延迟。HBM虽然带宽高，但访问延迟依然在几百纳秒的量级。你可能觉得几百纳秒没什么，但NPU片上SRAM的访问延迟是几个纳秒，差了差不多两个数量级。这意味着计算单元完全没有办法直接从HBM取数来计算，必须经过片上Shared Memory做缓冲，一次把一大块数据搬到离计算单元很近的地方，后续计算全部命中片上内存。

2.3 HBM控制器与访存效率

HBM控制器不是简单的“来一个请求发一个命令”，它会做调度：排队、合并、重排，尽量让总线上一次burst尽可能长、方向切换尽可能少。

我在实际调系统时发现，HBM的访存效率对访问模式极其敏感。连续且对齐的4KB块访问，效率可以接近峰值带宽的90%甚至95%；但如果DMA把大搬运拆成很多个64B的小块随机撒在不同伪通道里，效率可能直接掉到50%以下。另外，读写方向切换是有代价的——总线从读切到写，需要额外的切换周期清空数据线，如果软件让DMA频繁做“读一点、写一点、再读一点”的操作，总线上大量周期就浪费在切换上了。HBM还要定期做DRAM刷新，刷新时那部分存储区域无法被访问，又是一个隐藏的损耗。

所以软件层做数据流规划时，有几个经验值得记一下：

这一层是很多人容易忽略的。HBM指标再漂亮，也只是一个“上限”，真正能用多少，取决于DMA怎么搬、地址怎么排。

3. DMA搬运引擎：数据流中的无名功臣

3.1 DMA的职责边界

很多初学者会把DMA理解成一个“更快的内存拷贝”，这么说不完全错，但掩盖了它真正的价值。DMA是个独立的硬件搬运引擎，它可以脱离主控核运行。主控核只需要把搬运任务描述清楚，比如“把地址A到地址B之间这段数据搬到SMEM地址C”，然后启动DMA，DMA就自己完成剩下的所有动作，搬完之后再通知主控核。

为什么不直接让主控核用load/store指令搬数据？原因有两点。一是主控核有自己的一套指令流水和取指逻辑，让它逐字拷贝数据会占用大量指令周期，直接影响它下发控制命令的效率；二是主控核的访存带宽通常远不如专门优化的DMA引擎，DMA可以一次发起很长的突发传输，而CPU/控制器微核的load宽度有限。一句话：专业的事交给专业的引擎。主控核是调度员，DMA是运输队。

3.2 二维描述符与Tile搬运

实际搬运里最有价值的是二维DMA。深度学习算子里，数据大多是矩阵或特征图。特征图在内存里是连续存放的不假，但如果你想搬一个子区域——比如从一个大的特征图中取出一个tile，它的行与行之间是有地址间隔的。如果DMA只支持一维搬运，软件只能循环发N次一维请求，每次都要配置寄存器、启动、等结束，控制开销极大，而且HBM侧的访问也被切成碎片，带宽利用率很差。

二维描述符一次就能描述一个矩形区域。描述符核心字段就这几个：

typedef struct { uint64_t src_addr; // HBM源地址（或SMEM源地址） uint64_t dst_addr; // 目的地址 uint32_t width; // 每行搬多少字节 uint32_t height; // 一共搬多少行 uint32_t src_stride; // 源端相邻两行的首地址间距（字节） uint32_t dst_stride; // 目的端相邻两行的首地址间距（字节） } dma_desc_t;

比如我要从HBM地址0x80000000处搬运一个64行、每行128字节的矩阵，但源端每两行之间实际地址距离是256字节（因为行间还夹着别的通道数据），那我设置width=128、height=64、src_stride=256。目的端如果希望矩阵在SMEM里紧密排列，dst_stride就设成128。DMA硬件会自动按照这个几何信息完成搬运，你在描述符里写“矩形”，硬件就知道怎么跳地址。

再进一步，多个描述符可以串成描述符链，DMA搬完一个自动从链上取下一条继续搬。这样主控核一次下发一整条链，后续完全不需要干预。我在实际工程里接一个多分支网络时，经常给每个分支准备一条独立的描述符链，同步信号靠链尾的标记来做，软件开销非常小。

3.3 DMA带宽的计算与匹配

要判断数据流设计好不好，一个简单的方法是把搬运时间和计算时间放到一张表里对比。假设某层权重20MB，HBM有效带宽1TB/s，搬运耗时约为20微秒；MAC阵列做这层乘加消耗的逻辑耗时估算为40微秒，那搬运是追不上计算的，来得及。反过来，如果权重是80MB而计算耗时只有30微秒，那不管怎么优化指令流水，计算引擎必然挨饿，因为饭根本送不到。

这时候就要做“分块流水”：把80MB权重拆成例如8个10MB的块，DMA先把第1块搬进SMEM，MAC开始算第1块的同时，DMA搬运第2块；等MAC算完第1块，第2块已经就位。只要单块搬运时间小于单块计算时间，流水就能一直保持打满状态。这就是双缓冲（double buffering）的基本原理——SMEM里准备两块缓冲区，DMA写A区时MAC读B区，下一轮交换，两边互不踩脚。

DMA配置上还有个容易被忽略的点：描述符里的width、src_stride、dst_stride最好都按HBM的burst长度对齐。比如HBM控制器一个burst是256B，你每个描述符的行宽只有64B，效率会明显往下掉。对齐到256B或512B，效率立刻不一样。我见过太多系统带宽不达标，最后查下来根本不是硬件弱，而是描述符把块切得太碎。

4. 多bank Shared Memory：片上数据的中转站

4.1 为什么要多bank

Shared Memory在NPU里通常用SRAM实现，SRAM速度极快，但面积大、功耗高，所以片上容量不可能做得太大。更关键的是：一块大的单端口SRAM，每个时钟周期只能响应一次读或一次写。MAC阵列通常有几十上百个处理单元，同一周期想读几十个数据，如果Shared Memory只有一个端口，那就只能排队，性能完全不可接受。

这就是引入多bank的原因。把一块SRAM逻辑上划分成多个独立的bank，每个bank都有自己的读写端口和地址解码逻辑。只要多个访问请求落在不同的bank上，它们就能在同一个周期内并行完成。打个比方：一个厨师做菜需要同时拿油、盐、酱、醋，如果你把所有调料放在一个大抽屉里，一次只能伸一只手进去拿一样，那就慢了；如果把调料分装到几个独立的小抽屉，就能多只手同时取。

实际芯片里bank数量常见的是8到32个，每个bank的宽度可能是一百多字节到几KB。bank越多并行度越高，但面积和布线复杂度也跟着涨。设计目标很朴素：让MAC阵列同一周期发起的访问，尽量均匀散落在不同bank上。

4.2 Bank冲突：最容易被忽略的性能杀手

多bank能提升并行度，但绝不意味着没有冲突了。所谓bank冲突，就是两个访问地址在同一个周期落到了同一个bank上，然后硬件只能串行处理，其中一个请求被延迟一拍。

bank索引的映射方式通常是对地址取某些位段。比如有16个bank、每bank宽度32B，那地址的某个位段就决定bank编号。这种情况下，如果软件里两个缓冲区的基址安排得不巧，矩阵相邻行的起始地址都可能落到同一bank，MAC阵列一访问就是连环冲突，性能和预期差一大截。

我在调一个卷积算子时遇到过很典型的情况：卷积滑窗每轮要读一个3x3的窗口，9个数据在SMEM里的地址若集中分布在少数几个bank上，乘法阵列就在那里不断地等。解决办法看起来很简单——给每行末尾加padding字节，让相邻行的起始地址相对偏移一个bank宽度，或者把某个缓冲区的基址整体往后挪动一个bank对齐的偏移。效果立竿见影，算子整体性能能提升20%到30%。

需要特别提一句：bank冲突不是只在芯片设计阶段要关心的事，到了软件优化阶段，它往往是性能分析工具里最容易定位到的热点。如果你跑算子时发现MAC利用率上不去，先别急着怀疑计算单元，去查一查访存trace里bank访问分布是不是集中了。

4.3 容量与带宽的平衡规划

Shared Memory容量有限，规划时要做预算。我常用的分配策略是按权重、激活、临时数据三块来分。权重占用往往最大，因为卷积层的权重会被反复复用；激活区的大小取决于tile尺寸；scratch区给中间结果和特殊算子用。

以一个256KB的Shared Memory为例，我会这么分：

带宽预算也要提前估算。如果MAC阵列每个周期需要从Shared Memory读一个权重和一个激活，都是fp16即2字节，总共4字节，主频1GHz，那就是4GB/s的读带宽。Shared Memory按16个bank、每bank每周期32B来算，总带宽是512B/周期，远高于需求。但要注意，这只是理想情况，一旦bank冲突发生，有效带宽会腰斩，所以规划时留出余量非常必要。

5. 最小数据流工程搭建全记录

5.1 工程结构与模块划分

说再多理论，不如搭一个最小验证工程跑一遍。我建议用模拟项目X来做这套数据流闭环验证，硬件平台可以是RTL仿真或FPGA原型，如果只是学习，写一个行为级仿真也完全够。

工程至少要包含这几个模块：HBM模拟器（可以用一块大数组+带宽模型来模拟）、DMA控制器（解析描述符并搬运数据）、Shared Memory（多bank数组）、MAC计算引擎（一组简单的乘加单元）、主控逻辑（负责下发描述符和触发计算）。模块之间用读/写接口连接，每个模块都要有状态寄存器和日志输出，这样出了问题才能定位。

模块划分的核心边界是：HBM和Shared Memory之间只通过DMA交换数据，主控核不直接读写Shared Memory的数据区，MAC只从Shared Memory取数，结果也只写回Shared Memory。这个边界划清晰以后，每一条数据路径都很好追踪。

5.2 DMA描述符配置示例

下面给一个可参考的配置示例。假设我们要从HBM地址0x80000000搬运一个64行、每行128字节的特征图tile到SMEM权重区基址0x00008000。源端由于特征图通道交织，相邻两行间距是256字节；目的端为了规避bank冲突，我们希望每行在SMEM里占用的地址间距是512字节，也就是让每行起始地址都能分散到不同bank上。

dma_desc_t desc = { .src_addr = 0x80000000, .dst_addr = 0x00008000, .width = 128, // 每行128字节 .height = 64, // 共64行 .src_stride = 256, // HBM侧行间距 .dst_stride = 512, // SMEM侧行间距，带padding };

为什么dst_stride要设512而不是128？因为SMEM有16个bank，每bank连续宽度假设是32B，那么512B正好是16个bank的一整个周期。如果每行只占128B，四行的起始地址都会落在bank0，访问时冲突非常集中。把行间距拉大到512B，每行的起始地址就会均匀落到不同bank位置，并行度立刻提上来。代价是SMEM利用率低了一点，但换来的是访问不冲突，这个交换非常划算。

另外要注意地址对齐。描述符的源地址和目标基址最好按256B或512B对齐，这样HBM的burst和SMEM的bank边界都能对齐，事务不会被拆分。

5.3 同步与启动顺序

数据流闭环的启动顺序是有讲究的，推荐按下面的顺序来：

1. 主控下发权重搬运描述符，启动DMA，把权重从HBM搬到SMEM权重区；
2. 主控等待权重搬运完成信号；
3. 主控下发激活搬运描述符，启动DMA，把输入特征图搬到SMEM激活区；
4. 等待激活搬运完成；
5. 主控触发MAC阵列开始计算；
6. 计算完成后，主控下发写回描述符，DMA把结果从SMEM写回HBM。

如果你的描述符链里已经包含了多个同步点，主控也可以一次启动整条链，DMA自动按序执行。但这里有个非常常见的坑：主控在第一个搬运还没完成时就下发了第二个针对同一缓冲区的搬运，造成数据覆盖。所以每个缓冲区一定要有状态机管理，比如“空闲、正在写、可读、正在读”四个状态，主控在发起DMA前检查缓冲区状态，搬运完成后再更新状态。

我在验证工程里习惯给每个同步事件加一个计数器。比如权重搬运分8个块，每块完成时计数器加1，主控轮询直到计数器等于8才触发计算。这样即使描述符链比较复杂，也不会出现漏同步的问题。

6. 实操中踩过的坑与排查方法

6.1 性能上不去先查bank冲突

我调一个模拟卷积算子时遇到过很典型的场景：理论上MAC利用率可以到85%，结果实测只有53%。第一反应是DMA带宽不够，结果搬运链路log显示带宽占用并不高；再查MAC阵列的等待周期，发现大量stall来自SMEM访问。后来用访存trace把每个周期所有SMEM请求的bank号打出来，发现访问特别集中地落在bank 6和bank 10上，其他bank大部分时间空着。

原因就是缓冲区的基址安排跟卷积窗口的数据访问pattern产生了固定相位关系，每轮访问都会撞在同一小撮bank上。解决方案就是我们前面提过的两个手段：把激活缓冲区基址向后挪一个bank宽度的偏移，再给行的步长做padding，让相邻行的起始地址错开bank。改动不大，但调整之后MAC利用率回到了79%左右。

这件事之后我的习惯就变了：新拿到一个NPU平台，先写一段测试代码往SMEM里灌数据，再用工具的访存分析看bank分布，而不是直接跑业务算子。

6.2 DMA传输停顿与死锁

双通道并行搬运是死锁高发场景。比如DMA0负责搬权重到bank区A，DMA1负责搬激活到bank区B，但如果A区和B区在物理bank划分上有重叠，两个DMA可能在某个bank上互锁：DMA0占着bank 5不放等bank 7，DMA1占着bank 7等bank 5，两边谁也无法向前走。

排查死锁要看每个DMA引擎的状态寄存器，里面通常有waiting_on字段，能告诉你它在等什么资源。根治办法一般有两个方向：一是给DMA通道建立固定优先级，低优先级通道遇到争用就让步重试；二是引入超时机制，任何DMA请求等待超过阈值就释放已占用的bank，重新排队。我实际验证下来，固定优先级在大多数深度学习场景下就够用了，代码比超时机制简单得多，也更容易保证时序确定性。

还有一个“伪死锁”问题：系统没死，但带宽慢得吓人。遇到过DMA块大小设置成了64B，导致HBM侧事务被拆得稀碎，每个burst都落不到满效率区间。改成连续4KB大块搬运后，带宽直接翻倍。这类问题不好查，建议在跑真实算子之前先做一个纯搬运benchmark，确认HBM到SMEM的实测带宽接近理论值再往下做。

6.3 数据一致性检查

数据流系统最隐蔽的问题是逻辑看起来全对、但结果偶尔错。我碰到过一次：卷积输出偶发某几行数据不对，查DMA描述符、查计算逻辑都没问题，后来发现是同一段SMEM地址被两个描述符复用了。原因是描述符链中没有加同步，第一个描述符还没搬完，第二个描述符已经启动并把数据写进了同一块缓冲区，后写覆盖了先写。

正确的做法是在每个缓冲区旁边维护状态位。比如“空闲、正在写、可读、正在读”四个状态，DMA和MAC都能查询和更新这个状态位，只有当缓冲区处于“空闲”或“可读”状态时才允许新的DMA写入。状态机看着额外开销不大，但对防错非常有效。

我再分享一个特别实用的测试技巧：在SMEM所有缓冲区的边界填上固定pattern（我习惯用0xEBEB），跑完一轮数据流之后检查这些pattern有没有被改动。如果边界值变了，说明有写入越界或者缓冲区复用出了问题，一步就能定位到具体区域。这个tripwire方法我用了很多年，简单、粗暴、好用。

做了几个NPU数据流方案之后，我现在拿到一个新架构，第一件事不是看主频和MAC数量，而是先画一遍数据流：HBM带宽多少、DMA描述符支持几维、SMEM分成几个bank、bank宽度多大。这几个数字对性能的影响，比任何指令集优化技巧都直接。如果你也在调NPU算子，建议先跑一个简单的搬运测试，把HBM到SMEM的实测带宽打满，再往下优化计算逻辑。数据通路顺了，计算效率就是水到渠成的事。