AI芯片软硬件协同：有效算力与存储墙的瓶颈解析

提到AI芯片，很多人第一反应是去看规格表上的TOPS数字。我最初也是这么干的，但真正把模型从通用平台搬到AI加速卡上之后，才意识到一个残酷事实：纸面算力只是理论峰值，实际跑出来的性能，可能连一半都不到，有时候甚至跑不过原来的通用处理器。问题多数不在芯片本身，而在于软硬件之间没有对齐。这篇是AI芯片软硬件设计系列的开篇，我先把两个最基础也最关键的概念——有效算力和存储墙——讲透，同时把软件侧需要配合的编译、调度、量化这些问题放进同一张图里讲。适合刚接触芯片设计、正在做推理加速或边缘部署的人参考，也适合从应用层往底层走的工程师建立整体认知。

1. 单卡算力都去哪了：从峰值算力到有效算力

1.1 算力规格书为什么经常“虚标”

我在跟同行交流时经常听到一句话：“这块卡标称算力那么高，怎么换上之后反而变慢了？”这里有个容易忽略的细节：规格书上的算力是峰值算力，也就是所有计算单元同时跑到最高频率、数据通路完全无冲突的理论上限。真实场景里，数据要一层一层搬运、指令要排队、缓存会写满、某些算子形状根本不匹配硬件布局，这些都会让实际吞吐量打折扣。

有效算力的公式大致是：

有效算力 = 峰值算力 × 实际利用率

而实际利用率受三件事影响：数据搬运是否顺畅、计算单元是否被喂饱、算子映射是否贴合硬件结构。这三件事恰好对应了软硬件协同设计的主要战场。你光看算力表，完全看不到存储带宽是多少、片上缓存多大、编译器能把循环优化成什么样，自然也就无法判断这块芯片在具体模型上能发挥几成功力。

1.2 真正吃掉时间的三个环节：取数、计算、存回

用一个很基础的例子：卷积操作。假设输入特征图是256×256，卷积核是3×3，输出也是256×256。每个输出点需要9次乘法累加，整体大约60万次乘加操作。听起来不大，但如果每次乘加都要从外部内存取数据，那就有几十万次内存访问。访问延迟是片上缓存的几十倍，功耗更是高出好几个量级，整个流水线就被卡在取数上，计算单元大部分时间在空转。

这就是所谓的“存储墙”：不是算不快，而是数据喂不进来。我常把AI芯片比喻成一家餐厅：后厨的锅灶能力再强，如果食材只能靠一辆小推车从仓库一点点运，那翻台率必然上不去。软硬件设计的核心任务之一，就是把这条“运货通道”加宽、缩短，并且让食材在被运进来之后尽量多被用几次。

2. AI芯片的计算引擎：从MAC单元到脉动阵列

2.1 神经网络的计算核心为什么是MAC

神经网络里最常见的操作是矩阵乘法加偏置加激活。矩阵乘法最底层的动作就是乘累加运算（MAC）：把一个输入值与一个权重值相乘，再把结果累加。业界统计算力时用的TOPS，其实就是每秒万亿次MAC操作。

如果用通用处理器去执行MAC，开销不只是乘法本身。处理器要取指令、译码、读寄存器、写寄存器，每一层都有额外功耗和延迟。后果就是大量算力和能量浪费在“指挥”而不是“干活”上。专用AI芯片的思路很直接：把成千上万个MAC单元做成固定阵列，让控制逻辑尽量简化，把能量集中花在乘累加这个动作本身。

2.2 脉动阵列的核心思想：数据像流水一样流动

讲脉动阵列之前，先看一个生活场景：汽车装配线上，每个工位只做一种动作，车架沿轨道依次流过各个工位，零件从旁边不断送到工位附近。这样整个生产线可以连续出车，而不是每辆车都绕回仓库取件再回来装。

脉动阵列的电路结构与此类似。内部有大量处理单元（PE），相邻PE之间直接相连。输入特征图数据和权重数据各自沿着规定的方向流动，在每个PE里做一次乘累加，再把中间结果传给下一个PE。这样，从外部存储取进来的每一个数据，都会被多个计算单元重复使用，而不是只算一次就丢掉。

我在实际对比过这种设计与普通ALU阵列的区别：两条路都能算卷积，但脉动阵列的数据复用率更高，对外部访存的压力更小。代价是灵活性受限，某些不规则的网络结构会映射得很吃力，这时候就需要编译器去“改写”计算顺序来适配硬件。

2.3 硬件架构反过来决定软件怎么写

很多软件工程师习惯把硬件当成一个黑盒子，觉得上层代码只要符合接口规范就行。但在AI芯片领域，这条假设不成立。如果底层是脉动阵列，数据布局必须是分块的、对齐的，循环的顺序可能要从数据流方向反向推导；如果是多核并行的设计，还得考虑怎么把不同的算子分配到不同核心上，保证负载均衡。

换句话说，芯片的设计者不能只交付一块裸芯片，还要交付配套的算子库、编译器、运行时系统。这也是为什么很多AI芯片团队里，做编译器的人比做电路的人还多。软件不是硬件的下游，而是同一条流水线上不可分割的一部分。

3. 存储墙：数据搬运比计算本身更贵

3.1 取一次数，比算一次数贵两个数量级

有组经典数据我一直拿来讲给新同事听：一次32位整数乘累加运算消耗的能量大约在0.2到1pJ（皮焦耳）之间；访问一次片上SRAM缓存大概需要几pJ；访问一次外部DRAM却要上百pJ。也就是说，算一次的成本，还没把数据从内存里取一次的成本零头高。

这个数字背后藏着一个反直觉的结论：AI芯片的性能优化，很多时候不是优化“怎么算”，而是优化“怎么不搬数据”。只要能让一个数据被反复复用，减少从DRAM到计算单元的搬运次数，功耗和延迟都会显著下降。这也是为什么所有现代AI芯片都在拼命堆片上SRAM——不是为了显摆容量，而是为了把更多数据留在离计算单元近的地方，反复使用。

3.2 量化不是玄学，是一笔带宽账

量化为什么有效？很多人只记住“INT8比FP32快”，但没真正理解原因。FP32是32位，INT8只有8位，同样一个权重数据，体积缩小到四分之一。假如芯片的存储带宽是有限的，每秒钟能搬运的总位数就那么多，那么改用INT8之后，相同带宽下每秒能搬运的权重数量是FP32的四倍。

换一个直观的说法：量化不是让计算单元算得更快，而是让同样宽度的数据通道能喂进来更多的数据，同时减少了对缓存的占用。对访存受限的模型来说，这种效果是整体吞吐量的成倍提升。当然，量化也会牺牲一定精度，所以现在大家喜欢混合精度：关键层保留FP16或FP32，非关键层用INT8甚至INT4。这是典型的软硬件协同取舍，不只是模型侧的事。

3.3 算子融合与内存布局：让中间数据少“落地”

如果把一次推理过程完整展开，你会发现有大量中间张量生成后被立刻用作下一个算子的输入。按照普通流程，算子A的结果要写回DRAM，算子B再从DRAM里读出来。这一写一读，浪费的带宽和能耗非常大。

算子融合的做法是：把A、B、C这些原来是独立函数的算子合成一个大算子，中间结果只留在片上寄存器或SRAM里，直到最后一个阶段才写回DRAM。比如原地融合卷积、批归一化和ReLU，以前是三个内核，现在变成一个。我在实际项目中做过统计，仅这一项优化，端侧推理的整体访存时间就下降了大约三成。

内存布局同样影响显性。通常我们习惯把图像数据排成NCHW或者NHWC，不同硬件对布局有不同偏好。布局选错，编译器要做大量重排数据，重排本身就是一次大规模搬运。所以写算子实现之前，先查清楚目标芯片对张量维度的排布要求，能省掉很多看不见的拷贝开销。

4. 编译器才是AI芯片的半条命：从图优化到指令调度

4.1 一块没有编译器的AI芯片只是砖头

很多小白认为芯片只要做出来，放上驱动就能跑，做编译器纯属多余。实际上，神经网络模型是用深度学习框架写的，框架只认识通用的计算图，而芯片底层只认特定的指令和数据流。中间这层翻译，就是编译器的活。

编译器做的事大致分几层：第一层是图优化，融合算子、消除无用计算；第二层是把算子映射到硬件指令，这步骤要根据芯片的MAC阵列尺寸、SRAM容量、访存通道数去做循环变换；第三层是内存分配和指令调度，决定哪些数据常驻片上、哪些变量该复用、哪些流水线阶段该错开执行。每一层选错了，性能都能相差数倍。

4.2 Roofline模型：快速判断瓶颈在哪

调试AI算子性能时，我喜欢先用Roofline模型把问题定性。这个模型很简单：横轴是计算强度，表示每搬运一字节数据对应多少次运算；纵轴是实际性能。画出一条斜线，斜线的斜率表示存储带宽，横过来的一条水平线是峰值算力。落在斜线上的点，说明性能被访存限制住了；已经顶到屋顶的点，说明被算力限制住了。

拿计算强度区分的两类算子：卷积类型的算子相对偏算力密集型，可以多压缩数据搬运、利用量化来减轻带宽压力；而类似某些归一化、维度变换类的算子则偏访存密集型，主要优化目标是减少读次数、增加数据复用。先用这个模型看指标，再决定优化方向，比盲目调参数高效太多。

不同优化手段的侧重点和典型收益，我整理了一个表格：

4.3 一个循环分块的调度实例

用一个矩阵乘法作为例子，假设A矩阵是M×K，B矩阵是K×N。朴素写法是三循环，内层反复做乘累加，每次都从内存取数据。如果M、N、K都很大，数据量远超SRAM容量，整个计算就在反复搬运数据。

分块优化的思路是：把大循环切小，比如按tile大小把A和B分别切成小块，让一个块里的数据能完整塞进SRAM，然后把这个块做完整。伪代码如下：

for (int i = 0; i < M; i += TILE_M) for (int j = 0; j < N; j += TILE_N) for (int k = 0; k < K; j += TILE_K) // 将A[i:i+TILE_M, k:k+TILE_K] 和 B[k:k+TILE_K, j:j+TILE_N] 载入SRAM // 在SRAM内完成TILE_M * TILE_K * TILE_N 次乘累加

这样每个数据从DRAM取进来之后，能在SRAM内被多次复用，访存次数大幅下降。这个循环变换本身不改变结果，但性能优化空间往往能达到数倍。在做这块优化时，一个好的profile工具会显示每个循环层级上的缓存命中率和总访存字节数，盯着这两项指标调tile尺寸是最有效的做法。

5. 软硬件协同的入门路径：从跑通到吃透

5.1 用仿真工具代替流片，先看清瓶颈再动手

对于刚接触软硬件协同设计的人来说，最忌讳一上来就想着写RTL代码去流片。成本高、周期长，而且大部分问题其实在架构设计阶段就已经能暴露出来。我建议的路径是先搭一套仿真环境：用开源全系统模拟器跑一段基准模型，观察缓存命中率、带宽利用率和计算单元占用率这些指标，先把“瓶颈到底在哪”这个问题回答清楚。

如果目标是做芯片设计，接下来可以用开源硬件仿真框架去编写一个简单的硬件加速模块，在仿真阶段就跑通整个软件栈。这一步虽然不会真的制造芯片，但能让你直观看到编译器生成的指令是如何驱动硬件单元的，软硬件接口到底长什么样。

5.2 入门项目怎么选，怎么设计

选项目时，不要贪大，选一个最简单的算子，比如卷积或矩阵乘法，结合一个小模型拍照识别之类的任务，搭一个完整的端到端流程。这里有一个我常用的虚拟案例：某开发者的图像分类加速器。硬件侧只有一个小的MAC阵列模块，128个PE，每个PE支持8次乘累加，整体是简化版脉动阵列；软件侧用编译框架把模型的计算图切分成子图，再映射到这块硬件上。

设计步骤大致是：

• 先用Roofline模型分析模型，确认算子是访存受限还是算力受限。
• 再确定任务需要的最小SRAM容量。计算峰值带宽和流水线延迟目标，不要盲目堆面积。
• 在模拟器上跑一个具体模型，统计各操作耗时。
• 调整tile大小和循环展开系数，观察有效利用率变化。
• 最后把验证好的模块综合到FPGA开发板上，比较实测与仿真数据的差异。

这个过程走通一遍，你对软硬件协同的理解会比读十篇论文都深。

5.3 几个容易踩的坑

第一，只看理论峰值去选型，不拿真实模型跑benchmark。一套推理框架在不同芯片上的表现差异极大，别省这一步。第二，忽略编译器。有些开发者在写算子实现时，完全不考虑编译器会怎么做循环变换，结果手工优化和编译器优化互相对冲，性能反而更差。第三，忽视片上存储容量。有人设计芯片时把算力堆得很高，却把SRAM做得特别小，结果数据来不及复用，算力全部浪费在空等上。第四，仿真环境与真实环境差异过大会误导设计。

我自己第一次做加速器时，就在tile尺寸选择上卡了很久。总觉得tile越大复用越多，结果反而占满了SRAM，导致缓存频繁溢出，性能比小tile还差。后来才意识到，tile尺寸要跟SRAM容量、数据宽度、流水线深度这些硬件参数联合调，不能只看一个维度。调参的过程很枯燥，但每找到一组合适参数，性能都能跨上一个台阶。

现在很多芯片设计已经走向专用化、异构化。模型结构在变，硬件架构也在变，但软硬件协同的核心逻辑——减少数据搬运、提升数据复用、让编译器了解硬件结构——一直没有变。

最后再分享一个小体会：真正理解AI芯片软硬件设计，最快的方式不是看你跑通了多牛的模型，而是把一个很小的算子从图优化、循环分块、内存分配、指令调度到硬件仿真的整个链路完整走一遍。走完以后，你再回来看任何一张AI芯片的规格表，都能分辨出哪些参数是真实有效的，哪些只是营销数据。下一篇我会拆解一个具体的端侧推理加速器案例，从编译器调度一路看到硬件的流水线握手信号，把这一篇里提到的思路落到一个能跑的项目里。