AI芯片软硬件协同设计：从Roofline模型到算子融合的实战指南

做AI芯片这个方向的人应该都有类似的瞬间：拿到一片标称算力很高的AI加速芯片，把真实网络接上去一跑，端到端吞吐连理论峰值的三成都不到。按设计文档看，仿真明明挺好看，为什么一落到真实系统就掉链子？等到一层层查下去才发现，问题很少出在单个计算单元上，而是出在软硬件设计之间的缝隙里——数据怎么排、循环怎么分、指令怎么发、buffer怎么用、运行时要跟驱动握手多少次，每一个环节都在悄悄吃性能。

这个系列写到第三篇，前两次分别聊了AI芯片的计算单元设计和存储层次的基本取舍，这次专门聊一个更得罪人的题目：软硬件协同设计到底怎么做才不空谈。换句话说，一块AI芯片从规格定义到软件栈落地，真正起决定作用的那些细节究竟是什么。这篇文章没有一次性的万能配方，但会给你一套可以带到项目里用的分析方法，还有一些我实际调过、修过、也被坑过的真实路径。

1. 一块理论上很强的AI芯片，为什么跑网络时那么慢

1.1 标称算力高，不代表你能用上

很多芯片的第一版规格书都挺漂亮：某平台峰值算力100TOPS，片上SRAM几百KB，支持主流卷积和Transformer结构。可等板卡到手，把MobileNet一类轻量网络接上去，帧率却低得让人怀疑拿错了板子。频繁定位时你会发现，计算单元大部分时间在“空转”，等数据、等指令、等同步，真正干活的cycle连一半都不到。

这类问题最典型的来源有三个：输入数据的排列跟硬件期望的排布不一致，导致DMA搬运量成倍放大；算子的分块粒度跟片上存储容量不匹配，导致数据在一个K维度循环里反复进出DDR；运行时调度没有把计算和拷贝重叠起来，每一层都严格串行执行。更麻烦的是这类问题很难靠单边优化解决，硬件说“我接口都留了”，软件说“我没法让编译器知道硬件想要什么”，最后只能靠人工算子库去填坑。

1.2 判断一块AI芯片好不好用的三个切入点

我的习惯是拿到芯片后不急着看benchmark，先看三件事：第一，理论算力到可实现算力之间隔了几层开销，包括取指、搬运、片内路由、同步障碍；第二，配套算子库或者编译器的成熟度，尤其是一些非矩阵乘的算子比如Softmax、LayerNorm、动态形状分支，它们往往才是真实模型的性能杀手；第三，端到端测试是不是有人做，如果只跑单算子峰值而没人跑整个计算图，那些跨算子的中间张量访存开销很容易在规格阶段就被忽略。

这三件事本质上都在说同一个道理：AI芯片的性能不是一个数字，而是一条链路的产物。链路里任何一环没对齐，芯片就算长了金刚石脑袋也扛不住。

2. 先把算术强度算明白：算力、带宽与数据复用怎么权衡

2.1 用Roofline模型先给芯片“称重”

聊AI芯片软硬件设计，绕不开一个概念：算术强度，也就是每字节数据搬运对应多少次运算。芯片算力再高，如果访存带宽跟不上，最终性能会被带宽死死摁住。

举个例子更直观。假设某加速器峰值算力是100TOPS，片外存储带宽是1.2TB/s。那么临界算术强度就是100TOPS除以1.2TB/s，约等于83Ops/Byte。意思是，一个算子只有在每读取1字节数据后完成83次以上运算，才算跑进算力受限区。如果某个卷积实际算术强度只有30Ops/Byte，那么理论上限就是30乘以1.2TB/s，约36TOPS。也就是说这块芯片跑这个算子，峰值算力再高也会被访存拖到只剩三成多。

这个模型的价值不是精确预测性能，而是帮你判断瓶颈到底在哪一侧。软硬件设计争论不休的问题，比如“要不要堆更多MAC阵列”“SRAM做多大”“片上网络要不要更宽”，其实都能落到一个Roofline框架里讨论：先把工作负载的算术强度算清楚，再决定把资源花在算力还是带宽上。

2.2 三种主流数据流：到底把谁固定住

有了算术强度的“秤”，下一步就是数据流设计。矩阵乘和卷积的基本循环都有三个操作数：输入激活、权重、输出部分和。数据流设计本质上就是选一个操作数尽量留在片上，让另外两个操作数沿着计算阵列流动，从而最大化数据复用。

没有一种数据流绝对最优，完全取决于网络形态。例如全连接和卷积核权重复用程度高，权重固定数据流就很合适；而那些深度可分离卷积、逐点卷积，激活复用方式不同，反而更适合输出固定或行静态。历史上很多加速器之所以“跑经典网络不错、跑新结构拉胯”，就是因为在数据流选择上押错了方向。

2.3 访存受限向算力受限转变，靠的是“片上多留一层”

我在某个加速器项目里处理过一个很典型的算子，单看MAC阵列利用率只有20%出头，但DDR带宽已经接近饱和。解决思路并不复杂：把原本从DDR反复读取的激活块，通过调整循环顺序先搬进片上SRAM，再让PE阵列从SRAM里取数。仅仅这样改动，访存请求少了近一半，算子层面的利用率立刻跳到60%以上。

这就是数据复用的价值所在。算力是“发动机”，带宽是“油管”，SRAM是“油箱”。只加大油箱不加宽油管，续航和爆发力都上不去；只加宽油管却不安排复用，数据搬进来一次只用一遍，带宽照样烧得飞快。软硬件设计做得好不好，很大程度上就是看这一层“油箱”有没有被精确用在刀刃上。

3. 循环分块与PE阵列映射：把矩阵乘法拆进空间维

3.1 一个可算的例子：1024×1024×1024怎么铺

很多人觉得矩阵乘法在加速器上就是PE阵列各自算一行乘一列，事实远没那么简单。以M=N=K=1024的一次矩阵乘为例，总计算量是10亿次乘加。如果采用最笨的方法，每个乘加操作都需要从DDR读取两个FP16数据，那光取操作数就要搬4GB以上，任何芯片都扛不住。实际做法是把计算切成多个小block，让每个block在片上完成足够多的复用后再写回。

考虑一个16×16的PE阵列，片上SRAM约256KB。一种常规铺法是：把输出矩阵分成多个64×64的小块，每个小块由16×16个PE共同计算。对每个输出块，再在K维方向上以64为步长切块，循环累加。这样每次加载一个64×64的激活块、一个64×64的权重块，留在片上反复使用，最后把64×64的部分和写回累加。总访存从4GB级别降到几十MB级别，差别是上百倍。

3.2 分块尺寸不是越大越好，SRAM和PE之间要“预算”

选分块尺寸时有个经典约束：假设TM、TN是输出分块的行列大小，TK是K维分块大小，FP16下需要片上空间约等于2×(TM×TK+TN×TK+TM×TN)字节。如果256KB SRAM要放得下这些块，还得留出DMA乒乓缓冲的空间，那么TM、TN、TK都不能拍脑袋定。

我在实际调参时习惯先按“存储预算表”来：SRAM总容量，减去指令缓冲和运行时开销，剩下可分配给激活、权重、输出缓冲的额度；再根据PE阵列规模和数据类型反推最大TK。很多第一版算子库性能上不去，并不是算法思路错了，而是分块参数把SRAM塞得太满，没有余量做双缓冲，导致计算和搬运串行化。这属于典型的“硬件上限没算进软件设计”的案例。

3.3 循环顺序的优先级，决定片外流量

循环嵌套的顺序也会显著改变访存行为。对于同一个分块逻辑，如果最内层循环遍历的是K维，PE能连续累加同一组部分和，写回次数少；如果最内层反而在遍历输出空间，那么每换一个输出位置就要把部分和从SRAM搬进搬出，流量立刻暴涨。优先把K维放在最内层、把输出空间映射在PE阵列的两个空间维度上，这条规则能覆盖绝大多数稠密矩阵运算。

从编译器的角度看，循环层级的调度就是“时间维”和“空间维”的划分。空间维决定“哪些输出由哪个物理PE算”，时间维决定“单个PE内部按什么顺序循环”。软硬件协同设计在这个层面最直接的体现就是：编译器必须知道自己有多少个PE、每个PE的寄存器深度和SRAM分区，才能生成最优的循环分块。指令集设计时如果没把这些参数暴露给编译器，工具栈永远只能靠猜测做优化。

4. 算子融合与内存规划：编译器要替硬件算好每一笔账

4.1 算子融合为什么是省带宽的第一招

推理网络里Conv后面接ReLU、再后面接Add残差连接，是再常见不过的结构。如果每个算子独立实现，那么Conv的输出、ReLU的输出、Add的输出都要先写回DDR，再由下一个算子读出来。一次残差结构多出三四次整张特征图的片外访问，而模型越深，这种开销越致命。

算子融合的思路很简单：把Conv、ReLU、Add合并成一个融合kernel，在同一个循环里完成“计算→激活→残差加→写回”。中间结果留在寄存器或者片上SRAM，完全不落DDR。实测中单是融合残差块就能让访存流量下降30%到50%，端到端延迟改善非常明显。这也是为什么我总跟团队说，编译器优化的第一优先级不是指令重排，而是尽量减少张量生命周期里的DDR停留。

4.2 内存布局与缓冲规划：NCHW/NHWC的隐性代价

数据布局是AI编译器最容易出暗坑的地方。同一个算子，输入按NCHW排列和按NHWC排列，在硬件上的访存效率可能差出好几倍。原因在于向量化：很多向量处理器一次要连续处理多个通道的数据，NHWC布局把通道放在最内层，正好能批量读取；NCHW布局则把宽高放在内层，通道维度跨行，每次取数都可能变成离散访问。

这不只是软件层的格式转换问题。如果硬件设计时把DMA引擎、片上路由和PE数据输入格式都按NHWC优化，而编译器前端生成的计算图仍是NCHW，就必须在中间插一个layout转换算子。这个转换往往是一次完整的数据重排，成本可能比融合算子省下来的还高。所以layout选择要在一开始就参与软硬件联合决策，不能在硬件定型后再由编译器单独扛。

4.3 指令调度的“前门”与“后门”：编译器要替硬件算账

做指令调度时，我喜欢把它拆成两个方向看。前门是“喂”：数据尽量提前加载到SRAM，计算单元要取数时立刻能拿到。后门是“收”：计算结果尽快安排DMA搬运出去，不让输出缓冲积压。真正的流水线高手会把这两个方向重叠起来。

伪代码层面，双缓冲调度的常见写法是这样：

// 伪代码：以卷积算子为例，表达双缓冲思路 load_buffer(0); // 预取第一块输入 for (int t = 0; t < num_tiles; t++) { if (t + 1 < num_tiles) start_dma_load(t + 1); // 搬下一块 compute_buffer(t); // 同时计算当前块 if (t > 0) start_dma_store(t - 1); // 回写完成块 } wait_all_dma_done();

这个结构看起来很朴素，但真实编译器要处理的变体非常多：SRAM分几个bank、DMA能否同时访问两个bank、计算模块是否允许读未对齐地址、store的带宽是否会跟load抢占。任何一个参数没有暴露给调度器，编译器就只能按最保守的顺序执行，结果就是计算和搬运像排队过闸一样一卡一顿。

5. 量化、稀疏化与硬件配合：模型压缩的最后一公里在电路里

5.1 对称量化的三步走与硬件算子设计

深度学习推理现在很少有不量化的。以INT8对称量化为例，核心变换是：q = clamp(round(x / s), -128, 127)，其中s是缩放因子。量化后的两个整数做乘加，累加器必须用INT32保留精度，等累加完再乘回“双缩放因子”，最后做一次移位和截断输出INT8。

硬件实现里常见做法是：MAC阵列内部天然支持INT8乘-INT32累加；量化参数scale和shift由指令字直接携带，写入累加结果后生效。看起来简单，坑在于很多网络层的输入和权重scale不一样，有的还跨通道共享一个scale，有的则每个通道独立。如果硬件只支持张量级统一scale，某些模型量化误差就会被明显放大。软硬件协同在这里的含义是：量化器要了解硬件的粒度限制，而硬件又要保留足够的灵活性，让量化器不必为了配合电路而牺牲精度。

5.2 稀疏化的“硬件接住率”才是关键

模型剪枝之后权重出现大量零值，理论上跳过这些零乘加能让算力翻倍。但能不能兑现，得看硬件能不能优雅地“接住”稀疏。常见的支持方式有细粒度零值检测、2:4结构化稀疏、块稀疏跳过几种。

2:4结构化稀疏是相对折中的方案：每组4个权重里最多2个非零，权重矩阵可以按索引压缩存储。硬件读到非零值和对应索引后，只发起有效计算。这种方案访存减半、跳过逻辑简单，但要模型训练时配合微调结构。很多工程师只关注剪枝率，忽略硬件支持粒度，最后剪出来的网络在目标芯片上完全发挥不出稀疏收益，就是因为压缩格式跟片上跳过电路不匹配。模型侧做的量化、剪枝和稀疏，只有被硬件原样“理解”了，才算真正落地。

5.3 量化对端到端延迟的真实影响

量化带来的收益远不止模型体积缩小。一个FP16算子和一个INT8算子，在支持混合精度的芯片上，端到端差的是两类开销：一是MAC阵列单周期吞吐翻倍；二是访存流量减半。尤其对访存受限模型，INT8最大的价值不在算力提升，而在于同样的带宽能喂饱两倍的输出吞吐。

但也要泼一盆冷水：如果网络里插着几个FP16分支，或者量化层与反量化层散布得很碎，这些转换本身就会制造大量额外数据搬移。有时候跑完一遍profile发现，量化省下来的带宽又悄悄被laout转换和异步等待吃掉了。所以我一直强调，量化方案要跟着硬件算子的实际支持列表走，而不是只在训练框架里把精度调低就宣布“已优化”。

6. 仿真模型能信几分：性能验证的粒度与误差来源

6.1 验证金字塔里，哪一层最容易给你虚假信心

AI芯片性能验证一般分几层：纯算法级仿真、周期近似模拟器、周期精确RTL仿真、FPGA原型、流片后测试。每一层对性能的回答粒度完全不一样。

最容易“骗人”的是周期近似模拟器。它在建模内存带宽时经常只统计平均吞吐，忽略真实DDR的bank状态、刷新周期、访问冲突。我用模拟器做架构探索时，跑出来算子利用率能到85%，可同样的代码放到流片后的芯片上，只有55%。差别就来自那些“平均化”的假设。

6.2 一次流片后性能与仿真对不上的排查简记

那次性能对不上，排查了很久才发现问题出在多个PE同时访问DDR同一bank时的相互争抢。模拟器里每个PE的访存延迟是固定值，而真实内存控制器在有大量并发请求时会遇到bank conflict和排队，延迟不是线性增长，而是阶梯式恶化。十六个PE同时发起读请求时，最坏延迟比平均延迟高了将近三倍。

这个经历给我的教训是：硅前验证不能只跑“标准benchmark”，还要专门构造高并发随机访问模式，验证DRAM控制器在最坏情况下的行为。软件侧也一样，算子库发布前要用带随机抖动的访存模型做鲁棒性测试。软硬件协同不只是静态设计，更要在验证阶段把动态系统的“坏脾气”喂出来。

6.3 功耗与散热：标称频率下的真实吞吐

流片后测试还有一个容易被漏掉的变量：温度和功耗墙。很多芯片标称最高频率，但跑到重负载后温度很快逼近上限，动态调频会主动降频。功耗达标并不等于散热达标，现在不少加速板卡的性能瓶颈不在芯片核心，而在供电和散热设计。

我见过某块板子几乎是同一个程序，冬天跑和夏天跑帧率能差出10%以上。后面把所有性能测试都改成“先预热、再记录稳定频率下的结果”，数据才终于可复现。这也算软硬件系统设计的一个侧面：芯片、板卡、固件、驱动任何一个环节不给力，最终端的应用都吃不到完整性能。

7. 出了计算核之后还有半座山：片上网络、存储控制器与主机链路

7.1 核心之外的NoC与片外存储是一根水管

单看PE阵列的利用率很容易自嗨，但真实系统里数据要穿过NoC从SRAM到DDR控制器，再一路跑到主机内存。二维网格是最常见的片上网络结构，好处是布线规整、可扩展性强；坏处是远端核心访问片外存储的延迟明显高于近端核心，网络拥塞又会进一步拉开差距。

有些加速器出现“性能黑洞”并非算力不够，而是两个不同的计算模块同时向同一块DDR控制器猛灌请求。内存控制器只有那么大的并发能力，排队多了，整体带宽反而下降。设计阶段必须给NoC留出足够的自适应路由或者QoS优先级机制，同时让软件层的算子图调度意识到片上位置的亲缘性，尽量把连续数据放到相邻节点。两个设计配合起来，整颗芯片才会像一个整体，而不是一堆松散拼接的加速岛。

7.2 主机侧的软硬件协同：从驱动到运行时的开销

很多AI加速卡标称带宽很高，但端到端吞吐死活上不去，瓶颈居然在主机侧。提交一个推理请求，系统要经过用户态到内核态、驱动队列入队、DMA描述符准备、中断或轮询通知、结果拷回主机内存这么多步。每一步单独看都是微秒级，累积起来却可能把延迟拖到几毫秒。

解决方向通常是重叠和复用：用绑定页面的主机内存减少地址转换开销；用异步提交让多个请求的搬运和计算重叠；驱动层提供批量提交接口，避免每个算子都走一次完整的软件握手。这些听上去像“纯软件优化”，但硬件设计时必须预留对应的能力——多个DMA队列、门铃寄存器、事件通知机制、缓存一致性接口——否则软件再怎么努力也只是隔靴搔痒。

7.3 用端到端剖析定位“半边天”瓶颈

我曾经给某个加速卡做过一次完整profile，发现整个请求里真正在计算单元上的时间只占四成，其余时间被数据搬运、主机同步、运行时调度分摊掉了。从那之后，我评估任何新的AI芯片平台，第一件事就是写一个最简单的“一次拷贝+一次计算+一次回传”的基准，看整链路延迟是什么量级。如果这个最简往返都做不到预期，后面再好的算子库也弥补不了。

这也是软硬件协同设计里最容易被忽略的层面：芯片之外的驱动、运行时、内存分配策略，和芯片内部一样决定最终体验。设计团队如果把软件工程当作“硬件出来后再说”，那流片后的六个月就会变成靠驱动补洞的长尾期。

8. 一整套可落地的软硬件协同流程，和几次流片后的教训

8.1 从需求到规格：先把瓶颈找在前面

我现在的推荐流程，已经不做“先出硬件规格、再让软件适配”这件事。第一步是收集目标网络家族，把常见算子的算术强度、访存总量、张量形状分布统计清楚；第二步用Roofline模型估算各类结构的瓶颈区间；第三步才定MAC阵列规模、SRAM容量、带宽指标和NoC拓扑，每个数字都要能追溯到某个工作负载特征。

这样定出来的规格，软件栈基本可以同步开工。硬件还在RTL阶段，编译器就能用同一个工作负载集做代码生成和性能预测；硬件架构调整时，软件模型可以当天改、当天重新评估。很多团队把这个过程叫“性能建模先行”，其实就是让软硬件在纸面上先交朋友，不等到流片后被迫生硬磨合。

8.2 一张性能误差清单就是团队的照妖镜

每次性能验证，我都要维护一张不同层次的误差清单：实测值与Roofline模型差多少、模拟器误差多大、RTL仿真与实际行为差多少。如果模拟器预测90%利用率但实测只有70%，那误差来源就要标记成红色，下一轮验证优先优化建模精度。

这张清单最有价值的地方是倒逼团队承认“并不是所有环节都像我们以为的那样精确”。比如一开始模拟器不建模DRAM刷新开销，每次都对不上，记录三次之后设计团队自然会把刷新模型补上。软的硬件协同设计不是某一次大版本的“完美一刀”，而是持续用测试结果校准设计假设的循环。

8.3 我踩过的坑与现在的推荐流程

最后分享几个我踩过、也看到周围团队反复踩的坑。第一个坑是优先优化单算子性能而忽略整图调度。单算子和整图的差距往往在中间张量访存上，这个教训我至今记得。第二个坑是让量化器完全自由发挥，没有事先对齐硬件支持粒度，导致模型精度上去了、芯片利用率下来了。第三个坑是验证环境没有加入随机访存冲突和温度压测，流片后才发现真实系统比模拟“脾气”大得多。

现在的推荐流程很朴素：先建Roofline模型，再定数据流和分块策略，让编译器从第一天就跟架构规格对齐，验证时用完整系统级测试喂高并发和极端温度，最后在板卡上用“最简往返基准”检验链路健康度。每一步都像在给一颗芯片写手术方案，提前知道问题在哪、哪些地方会被压力击穿，比“等芯片回来再跑分评好坏”要靠谱得多。

做AI芯片，真正的门槛从来不是某一个算力数字，而是把一堆聪明但各说各话的模块捏成一台能稳定卖货的机器。越是往后走，越觉得软硬件协同不是一道可选的加分题，而是进考场前就必须写完的答卷。