1. 从"能跑就行"到"跑得省电"：AI芯片软硬件协同设计的核心命题做AI芯片这行的人都有一个共识：一颗芯片流片回来，能点亮、能跑通ResNet-50，这只是万里长征第一步。真正决定这颗芯片能不能被客户接受、能不能上量、能不能在功耗和成本上打得过竞品的，是软硬件协同设计做得到不到位。我见过太多团队，硬件指标看着漂亮，TOPS数字拉满，结果软件栈一塌糊涂，编译器生成的算子效率只有手写版本的30%，最后客户一测实际推理延迟，直接摇头走人。这个系列写到第六篇，我想把焦点收窄到一个最容易被忽视、但恰恰最致命的问题上：数据搬运。在AI芯片的软硬件设计里，计算单元的设计固然重要，但真正吃掉功耗和延迟的大头，往往是数据在片外存储和片内存储之间的来回搬运。有经验的架构师会告诉你，一颗AI芯片的功耗预算里，DRAM访问的功耗占比经常超过50%，在某些访存密集型的网络里甚至能到70%。这意味着什么？意味着你就算把MAC阵列的能效做到极致，只要数据搬运没优化好，整颗芯片的能效比照样难看。所以这篇内容，我想从软硬件协同的视角，把AI芯片里数据搬运这件事拆开来讲。从存储层次的设计取舍，到数据复用策略的硬件支撑，再到编译器怎么配合做调度，最后落到实际项目里怎么评估和迭代。适合正在做AI芯片架构设计、编译器开发、或者系统级优化的同行参考，也适合刚入行想理解"为什么AI芯片设计不能只盯着算力数字"的朋友。2. 存储层次设计：为什么AI芯片的SRAM比CPU金贵得多2.1 从冯诺依曼瓶颈说起，但不止于此传统CPU的存储层次大家都很熟：寄存器、L1/L2/L3 Cache、主存、外存。AI芯片虽然也遵循类似的分层逻辑，但设计哲学完全不同。CPU的Cache是为了降低平均访存延迟，靠的是时间局部性和空间局部性，硬件自动管理，软件不用操心。AI芯片不行，因为神经网络的计算模式太规整了——每一层的权重、输入特征图、输出特征图，访问模式在编译期就能确定，硬件自动管理的Cache反而会带来不必要的开销和不确定性。我参与过的一个边缘推理芯片项目，最初架构师直接照搬了CPU那套多级Cache方案，结果发现两个问题：一是Cache命中率虽然高，但每次miss带来的延迟抖动让实时性要求高的场景很难受；二是Cache的tag比较和替换逻辑占了不少面积和功耗，而这些开销在AI负载下完全是浪费。后来改成软件管理的Scratchpad Memory（SPM），编译器在编译期就把数据搬运指令排好，硬件只管执行，面积省了将近20%，功耗降了15%。这个经历让我深刻理解一件事：AI芯片的存储层次设计，核心不是"缓存命中率"，而是"数据复用距离"。什么意思？就是一份数据从片外搬进来之后，在被换出去之前，能被计算单元用多少次。用得多，搬运成本就被摊薄了；用得少，那搬运功耗就白花了。2.2 SRAM容量和带宽的取舍：一个真实的面积-功耗-性能三角做架构设计的人每天都在做取舍。SRAM这东西，容量每增加一倍，面积差不多翻倍，漏电功耗也线性增长。但容量不够，数据就得频繁往DRAM跑，动态功耗又上去了。这个平衡点怎么找？我的经验是分三步走：第一步，算清楚每个网络层的数据复用潜力。以卷积层为例，输入特征图的一个像素，会被多少个输出通道的卷积核用到？答案是输出通道数。权重的一个参数，会被多少个输出像素用到？答案是输出特征图的空间尺寸。这两个数字乘起来，就是这一层理论上的最大数据复用次数。复用次数越高，越值得为它多留SRAM。第二步，画出复用距离分布图。不是所有数据都能在SRAM里待到被充分利用。如果一层的数据量太大，SRAM装不下，就得切分（tiling）。切分之后，复用距离就受限于tile的大小。这时候要评估：在当前SRAM容量下，平均复用距离是多少？如果远小于理论最大值，说明SRAM容量是瓶颈，得加；如果已经接近理论值，说明再加SRAM收益递减。第三步，用功耗模型验证。片外DRAM访问的能耗大约是片内SRAM访问的100到200倍（具体取决于工艺节点和DRAM类型）。所以每减少一次片外访问，省下的功耗相当可观。但增加SRAM带来的漏电功耗也不能忽略。我通常会用一张表来对比不同SRAM容量方案下的总功耗：SRAM容量片外访问次数DRAM动态功耗SRAM漏电功耗总功耗256KB100%基准基准基准512KB65%-35%+18%-17%1MB48%-52%+40%-12%2MB42%-58%+85%+27%这张表是示意性的，但趋势很明确：SRAM容量存在一个最优区间，过了这个区间，漏电功耗的增长会超过动态功耗的节省。这个拐点在哪里，取决于工艺节点、SRAM的漏电特性、以及具体负载的访存模式。没有万能公式，只能针对自己的场景去算。2.3 多级SPM的划分逻辑：谁该放在离计算最近的地方确定了总容量之后，下一个问题是：这些SRAM怎么分层？我的做法是至少分两级：一级是紧挨着计算单元的寄存器文件或小型SPM，容量很小但带宽极高；二级是稍大一些的共享SPM，负责在多个计算单元之间共享数据。划分的依据是数据的使用频率和共享范围。权重数据通常被所有计算单元共享，放在二级SPM比较合适；输入特征图的某个tile可能只被一组计算单元使用，可以放在一级SPM；累加器这种每个周期都要读写的数据，必须放在寄存器文件里。这里有个容易踩的坑：一级SPM的带宽要跟计算单元的吞吐匹配。我见过一个设计，MAC阵列每个周期能算256次乘加，但一级SPM每个周期只能提供128个操作数，结果计算单元有一半时间在等数据。这种"算力饥饿"问题，根源就在存储层次设计时没有做带宽匹配分析。正确的做法是反推：先确定计算单元的峰值吞吐，然后算出每个周期需要多少操作数，再据此设计SPM的位宽和bank数量。3. 数据复用策略：硬件怎么给软件"搭台子"3.1 卷积中的数据复用维度：不只是权重和特征图讲数据复用，最经典的分析框架是卷积层的三种复用：权重复用、特征图复用、以及输入-输出通道间的复用。但实际做架构时，我发现很多团队只盯着这三种，忽略了跨层复用的可能性。什么叫跨层复用？在一些网络结构里，比如残差连接、密集连接，某一层的输出会直接作为后面某一层的输入。如果这两层在时间上挨得很近，那份数据完全可以在SRAM里多待一会儿，不用写回DRAM再读出来。这需要硬件支持"数据驻留"机制——编译器可以标记某些数据块为"常驻"，硬件在分配SRAM时优先保留这些块。我做过一个实验：在一个包含大量残差连接的网络上，开启跨层复用后，片外访问次数减少了22%，端到端延迟降低了18%。这个收益不需要增加任何SRAM容量，只需要硬件支持地址映射的灵活配置和编译器的配合调度。3.2 硬件复用器与数据广播：面积换带宽的经典交易数据复用要落地，硬件上得有相应的数据通路支持。最常见的是广播总线和交叉开关两种方案。广播总线简单：一份数据同时发给多个计算单元，面积小，但灵活性差，只适合所有计算单元需要同一份数据的场景。交叉开关灵活：任意输入可以路由到任意输出，但面积和功耗随端口数平方增长。我的经验是混合使用：在计算单元簇内部用广播，簇之间用交叉开关。比如一个256 MAC的阵列，分成4个簇，每簇64 MAC。簇内权重通过广播分发，簇间的输入特征图通过一个4x4的交叉开关路由。这样既保证了灵活性，又控制了面积开销。还有一个容易被忽视的细节：数据广播的时序。如果广播总线的延迟太大，计算单元就得插入等待周期，吞吐就下来了。所以在物理设计阶段，广播总线的走线要优先保证，必要时可以加流水线寄存器，但加寄存器又会增加延迟。这个平衡点需要在RTL设计阶段就通过时序分析来确定。3.3 双缓冲与乒乓操作：让搬运和计算重叠起来数据搬运和计算如果串行执行，那计算单元的利用率最多也就50%。双缓冲（Double Buffering）是解决这个问题的标准手段：把SRAM分成两块，一块在计算时，另一块在搬运下一批数据，通过乒乓切换实现重叠。但双缓冲不是万能的。它要求SRAM容量至少能放下两批数据，这对容量紧张的设计是个挑战。而且双缓冲的控制逻辑要处理好边界条件——如果搬运时间比计算时间长，那计算单元还是得等；如果计算时间比搬运时间长，那SRAM的利用率就不高。我通常会用多缓冲（Multi-Buffering）来进一步平滑：把SRAM分成N块，搬运和计算以流水线方式推进。N越大，对搬运延迟波动的容忍度越高，但SRAM开销也越大。实际项目中，N取3或4是比较常见的折中。这里有个实操心得：缓冲块的大小要跟DRAM的burst长度对齐。如果DRAM的burst是32字节，而缓冲块是30字节，那每次搬运都会浪费2字节的带宽，累积起来很可观。我见过一个设计，就因为没做这个对齐，有效带宽利用率只有78%。4. 编译器与硬件的握手：调度策略怎么决定实际能效4.1 算子融合的边界：什么时候该融，什么时候不该融算子融合是编译器优化里的重头戏。把多个算子合并成一个kernel，可以减少中间结果的写回和读取，理论上能大幅降低访存开销。但融合不是越多越好。我踩过的一个坑：在一个包含卷积、BN、ReLU的序列里，编译器把三个算子全融了。结果发现，融合后的kernel寄存器压力太大，导致occupancy下降，反而比不融合还慢。后来分析发现，BN和ReLU融合没问题，因为它们都是逐元素的，不增加额外的数据搬运；但卷积和BN融合时，BN的参数需要额外读取，如果这些参数不能常驻寄存器，就会引入新的访存。所以我的原则是：融合的收益要看"省下的访存"是否大于"增加的寄存器压力"。编译器在做融合决策时，应该有一个代价模型，估算融合前后的访存次数和寄存器使用量，只有收益为正才融合。4.2 内存分配与生命周期分析：别让数据"死"在SRAM里编译器做内存分配时，核心任务是分析每个数据块的生命周期——从什么时候产生，到什么时候最后一次被使用。生命周期不重叠的数据块可以共享同一块SRAM空间，这就是内存复用。但AI负载有个特点：数据块的生命周期往往很长，因为一份权重可能在整个推理过程中都要用。这时候如果SRAM不够，就得把一些权重换出去。换谁？我的策略是按访问频率排序，频率低的先换出。但频率是动态变化的，静态分析很难准确预测。所以有些设计会加入硬件计数器，运行时统计每个数据块的访问次数，动态调整换出策略。这个硬件计数器的开销很小，但收益很明显。我在一个项目里加了之后，SRAM的有效利用率从72%提升到了89%。4.3 指令调度与流水线填充：让每个周期都有活干编译器的指令调度决定了硬件流水线的填充效率。AI芯片的流水线通常比较深，因为要支持高频率。如果调度不好，流水线气泡会吃掉大量性能。一个实用的技巧是软件流水（Software Pipelining）：把循环的不同迭代重叠执行，让搬运、计算、写回三个阶段在时间上错开。这需要编译器能够识别循环的依赖关系，并重新排列指令顺序。但软件流水对编译器的要求很高，而且不是所有循环都能流水化。我的经验是，优先对最内层循环做软件流水，因为内层循环的迭代次数最多，收益最大。外层循环如果依赖关系复杂，可以保守一些，用简单的双缓冲就够了。5. 实测中的意外：那些仿真阶段发现不了的问题5.1 DRAM刷新带来的延迟抖动仿真的时候，我们通常把DRAM模型简化为固定延迟。但实际芯片上，DRAM需要定期刷新，刷新期间无法响应读写请求。如果刷新周期和计算周期发生共振，延迟抖动会非常明显。我遇到过一次：某个网络层的计算时间恰好是DRAM刷新周期的整数倍，导致每次计算到关键路径时都撞上刷新，延迟直接翻倍。解决办法是在编译器里加入刷新感知调度，把对延迟敏感的数据搬运安排在刷新窗口之外。这需要硬件提供刷新状态的指示信号，编译器据此调整指令顺序。5.2 电压降对SRAM时序的影响物理设计阶段，如果电源网络设计不当，局部电压降会导致SRAM时序违例。仿真时用的是理想电压，实际芯片上电压波动可能达到5%到10%。对于先进工艺节点，这个波动足以让SRAM访问失败。我的做法是在SRAM周围加去耦电容，同时在时序分析时留足够的margin。但去耦电容占面积，margin留太多又影响频率。这个平衡需要在项目早期就考虑，不能等到物理设计阶段再补救。5.3 温度对漏电功耗的反噬前面算功耗时用的是常温下的漏电数据。但芯片工作时温度会升高，漏电功耗随温度指数增长。如果散热设计没跟上，温度升高导致漏电增加，漏电增加又导致温度进一步升高，形成正反馈，严重时会导致热失控。所以在评估SRAM容量方案时，一定要用最坏情况下的温度来算漏电。我通常会在常温漏电数据上乘一个1.5到2.0的系数，具体取决于散热方案和工艺特性。6. 从项目迭代中沉淀下来的几条硬经验做了这么多颗芯片，有些教训是反复验证过的，我把它总结成几条，供参考。第一条：存储层次的设计要从负载出发，不要从工艺出发。先分析你的目标网络需要多少数据复用，再决定SRAM容量和层次。反过来做，先定工艺和SRAM容量，再去适配网络，往往会发现要么容量不够，要么浪费。第二条：编译器和硬件要一起设计，不能割裂。硬件提供什么粒度的数据搬运指令、什么级别的并行度，编译器才能做相应的调度。如果硬件设计完了再让编译器去适配，很多优化机会就错过了。第三条：仿真阶段就要把DRAM刷新、电压降、温度这些非理想因素考虑进去。等到流片回来再发现，代价太大。宁可仿真时保守一点，也不要流片后惊喜。第四条：数据复用不是越多越好，要看复用距离。一份数据在SRAM里待着不用，照样消耗漏电。复用的关键是让数据在被换出之前，尽可能多地被用到。第五条：留足够的验证余量。实际芯片的访存行为往往比仿真复杂，DRAM的bank冲突、刷新、温度影响，都会让实际带宽低于理论值。我在项目里通常会把仿真得到的带宽打八折来估算实际性能，这样流片回来才不会失望。最后分享一个我常用的评估方法：在项目早期，用访存字节数除以计算操作数得到一个"算术强度"指标。这个指标越高，说明计算越密集，对存储带宽的要求越低；指标越低，说明访存越密集，存储设计就越关键。对于典型的卷积网络，这个指标在10到100之间；对于Transformer类模型，因为注意力机制的存在，指标会低很多，这时候存储设计的重要性就更加突出。把这个指标作为架构设计的北极星，很多取舍就变得清晰了。
1. 从"能跑就行"到"跑得省电"：AI芯片软硬件协同设计的核心命题做AI芯片这行的人都有一个共识：一颗芯片流片回来，能点亮、能跑通ResNet-50，这只是万里长征第一步。真正决定这颗芯片能不能被客户接受、能不能上量、能不能在功耗和成本上打得过竞品的，是软硬件协同设计做得到不到位。我见过太多团队，硬件指标看着漂亮，TOPS数字拉满，结果软件栈一塌糊涂，编译器生成的算子效率只有手写版本的30%，最后客户一测实际推理延迟，直接摇头走人。这个系列写到第六篇，我想把焦点收窄到一个最容易被忽视、但恰恰最致命的问题上：数据搬运。在AI芯片的软硬件设计里，计算单元的设计固然重要，但真正吃掉功耗和延迟的大头，往往是数据在片外存储和片内存储之间的来回搬运。有经验的架构师会告诉你，一颗AI芯片的功耗预算里，DRAM访问的功耗占比经常超过50%，在某些访存密集型的网络里甚至能到70%。这意味着什么？意味着你就算把MAC阵列的能效做到极致，只要数据搬运没优化好，整颗芯片的能效比照样难看。所以这篇内容，我想从软硬件协同的视角，把AI芯片里数据搬运这件事拆开来讲。从存储层次的设计取舍，到数据复用策略的硬件支撑，再到编译器怎么配合做调度，最后落到实际项目里怎么评估和迭代。适合正在做AI芯片架构设计、编译器开发、或者系统级优化的同行参考，也适合刚入行想理解"为什么AI芯片设计不能只盯着算力数字"的朋友。2. 存储层次设计：为什么AI芯片的SRAM比CPU金贵得多2.1 从冯诺依曼瓶颈说起，但不止于此传统CPU的存储层次大家都很熟：寄存器、L1/L2/L3 Cache、主存、外存。AI芯片虽然也遵循类似的分层逻辑，但设计哲学完全不同。CPU的Cache是为了降低平均访存延迟，靠的是时间局部性和空间局部性，硬件自动管理，软件不用操心。AI芯片不行，因为神经网络的计算模式太规整了——每一层的权重、输入特征图、输出特征图，访问模式在编译期就能确定，硬件自动管理的Cache反而会带来不必要的开销和不确定性。我参与过的一个边缘推理芯片项目，最初架构师直接照搬了CPU那套多级Cache方案，结果发现两个问题：一是Cache命中率虽然高，但每次miss带来的延迟抖动让实时性要求高的场景很难受；二是Cache的tag比较和替换逻辑占了不少面积和功耗，而这些开销在AI负载下完全是浪费。后来改成软件管理的Scratchpad Memory（SPM），编译器在编译期就把数据搬运指令排好，硬件只管执行，面积省了将近20%，功耗降了15%。这个经历让我深刻理解一件事：AI芯片的存储层次设计，核心不是"缓存命中率"，而是"数据复用距离"。什么意思？就是一份数据从片外搬进来之后，在被换出去之前，能被计算单元用多少次。用得多，搬运成本就被摊薄了；用得少，那搬运功耗就白花了。2.2 SRAM容量和带宽的取舍：一个真实的面积-功耗-性能三角做架构设计的人每天都在做取舍。SRAM这东西，容量每增加一倍，面积差不多翻倍，漏电功耗也线性增长。但容量不够，数据就得频繁往DRAM跑，动态功耗又上去了。这个平衡点怎么找？我的经验是分三步走：第一步，算清楚每个网络层的数据复用潜力。以卷积层为例，输入特征图的一个像素，会被多少个输出通道的卷积核用到？答案是输出通道数。权重的一个参数，会被多少个输出像素用到？答案是输出特征图的空间尺寸。这两个数字乘起来，就是这一层理论上的最大数据复用次数。复用次数越高，越值得为它多留SRAM。第二步，画出复用距离分布图。不是所有数据都能在SRAM里待到被充分利用。如果一层的数据量太大，SRAM装不下，就得切分（tiling）。切分之后，复用距离就受限于tile的大小。这时候要评估：在当前SRAM容量下，平均复用距离是多少？如果远小于理论最大值，说明SRAM容量是瓶颈，得加；如果已经接近理论值，说明再加SRAM收益递减。第三步，用功耗模型验证。片外DRAM访问的能耗大约是片内SRAM访问的100到200倍（具体取决于工艺节点和DRAM类型）。所以每减少一次片外访问，省下的功耗相当可观。但增加SRAM带来的漏电功耗也不能忽略。我通常会用一张表来对比不同SRAM容量方案下的总功耗：SRAM容量片外访问次数DRAM动态功耗SRAM漏电功耗总功耗256KB100%基准基准基准512KB65%-35%+18%-17%1MB48%-52%+40%-12%2MB42%-58%+85%+27%这张表是示意性的，但趋势很明确：SRAM容量存在一个最优区间，过了这个区间，漏电功耗的增长会超过动态功耗的节省。这个拐点在哪里，取决于工艺节点、SRAM的漏电特性、以及具体负载的访存模式。没有万能公式，只能针对自己的场景去算。2.3 多级SPM的划分逻辑：谁该放在离计算最近的地方确定了总容量之后，下一个问题是：这些SRAM怎么分层？我的做法是至少分两级：一级是紧挨着计算单元的寄存器文件或小型SPM，容量很小但带宽极高；二级是稍大一些的共享SPM，负责在多个计算单元之间共享数据。划分的依据是数据的使用频率和共享范围。权重数据通常被所有计算单元共享，放在二级SPM比较合适；输入特征图的某个tile可能只被一组计算单元使用，可以放在一级SPM；累加器这种每个周期都要读写的数据，必须放在寄存器文件里。这里有个容易踩的坑：一级SPM的带宽要跟计算单元的吞吐匹配。我见过一个设计，MAC阵列每个周期能算256次乘加，但一级SPM每个周期只能提供128个操作数，结果计算单元有一半时间在等数据。这种"算力饥饿"问题，根源就在存储层次设计时没有做带宽匹配分析。正确的做法是反推：先确定计算单元的峰值吞吐，然后算出每个周期需要多少操作数，再据此设计SPM的位宽和bank数量。3. 数据复用策略：硬件怎么给软件"搭台子"3.1 卷积中的数据复用维度：不只是权重和特征图讲数据复用，最经典的分析框架是卷积层的三种复用：权重复用、特征图复用、以及输入-输出通道间的复用。但实际做架构时，我发现很多团队只盯着这三种，忽略了跨层复用的可能性。什么叫跨层复用？在一些网络结构里，比如残差连接、密集连接，某一层的输出会直接作为后面某一层的输入。如果这两层在时间上挨得很近，那份数据完全可以在SRAM里多待一会儿，不用写回DRAM再读出来。这需要硬件支持"数据驻留"机制——编译器可以标记某些数据块为"常驻"，硬件在分配SRAM时优先保留这些块。我做过一个实验：在一个包含大量残差连接的网络上，开启跨层复用后，片外访问次数减少了22%，端到端延迟降低了18%。这个收益不需要增加任何SRAM容量，只需要硬件支持地址映射的灵活配置和编译器的配合调度。3.2 硬件复用器与数据广播：面积换带宽的经典交易数据复用要落地，硬件上得有相应的数据通路支持。最常见的是广播总线和交叉开关两种方案。广播总线简单：一份数据同时发给多个计算单元，面积小，但灵活性差，只适合所有计算单元需要同一份数据的场景。交叉开关灵活：任意输入可以路由到任意输出，但面积和功耗随端口数平方增长。我的经验是混合使用：在计算单元簇内部用广播，簇之间用交叉开关。比如一个256 MAC的阵列，分成4个簇，每簇64 MAC。簇内权重通过广播分发，簇间的输入特征图通过一个4x4的交叉开关路由。这样既保证了灵活性，又控制了面积开销。还有一个容易被忽视的细节：数据广播的时序。如果广播总线的延迟太大，计算单元就得插入等待周期，吞吐就下来了。所以在物理设计阶段，广播总线的走线要优先保证，必要时可以加流水线寄存器，但加寄存器又会增加延迟。这个平衡点需要在RTL设计阶段就通过时序分析来确定。3.3 双缓冲与乒乓操作：让搬运和计算重叠起来数据搬运和计算如果串行执行，那计算单元的利用率最多也就50%。双缓冲（Double Buffering）是解决这个问题的标准手段：把SRAM分成两块，一块在计算时，另一块在搬运下一批数据，通过乒乓切换实现重叠。但双缓冲不是万能的。它要求SRAM容量至少能放下两批数据，这对容量紧张的设计是个挑战。而且双缓冲的控制逻辑要处理好边界条件——如果搬运时间比计算时间长，那计算单元还是得等；如果计算时间比搬运时间长，那SRAM的利用率就不高。我通常会用多缓冲（Multi-Buffering）来进一步平滑：把SRAM分成N块，搬运和计算以流水线方式推进。N越大，对搬运延迟波动的容忍度越高，但SRAM开销也越大。实际项目中，N取3或4是比较常见的折中。这里有个实操心得：缓冲块的大小要跟DRAM的burst长度对齐。如果DRAM的burst是32字节，而缓冲块是30字节，那每次搬运都会浪费2字节的带宽，累积起来很可观。我见过一个设计，就因为没做这个对齐，有效带宽利用率只有78%。4. 编译器与硬件的握手：调度策略怎么决定实际能效4.1 算子融合的边界：什么时候该融，什么时候不该融算子融合是编译器优化里的重头戏。把多个算子合并成一个kernel，可以减少中间结果的写回和读取，理论上能大幅降低访存开销。但融合不是越多越好。我踩过的一个坑：在一个包含卷积、BN、ReLU的序列里，编译器把三个算子全融了。结果发现，融合后的kernel寄存器压力太大，导致occupancy下降，反而比不融合还慢。后来分析发现，BN和ReLU融合没问题，因为它们都是逐元素的，不增加额外的数据搬运；但卷积和BN融合时，BN的参数需要额外读取，如果这些参数不能常驻寄存器，就会引入新的访存。所以我的原则是：融合的收益要看"省下的访存"是否大于"增加的寄存器压力"。编译器在做融合决策时，应该有一个代价模型，估算融合前后的访存次数和寄存器使用量，只有收益为正才融合。4.2 内存分配与生命周期分析：别让数据"死"在SRAM里编译器做内存分配时，核心任务是分析每个数据块的生命周期——从什么时候产生，到什么时候最后一次被使用。生命周期不重叠的数据块可以共享同一块SRAM空间，这就是内存复用。但AI负载有个特点：数据块的生命周期往往很长，因为一份权重可能在整个推理过程中都要用。这时候如果SRAM不够，就得把一些权重换出去。换谁？我的策略是按访问频率排序，频率低的先换出。但频率是动态变化的，静态分析很难准确预测。所以有些设计会加入硬件计数器，运行时统计每个数据块的访问次数，动态调整换出策略。这个硬件计数器的开销很小，但收益很明显。我在一个项目里加了之后，SRAM的有效利用率从72%提升到了89%。4.3 指令调度与流水线填充：让每个周期都有活干编译器的指令调度决定了硬件流水线的填充效率。AI芯片的流水线通常比较深，因为要支持高频率。如果调度不好，流水线气泡会吃掉大量性能。一个实用的技巧是软件流水（Software Pipelining）：把循环的不同迭代重叠执行，让搬运、计算、写回三个阶段在时间上错开。这需要编译器能够识别循环的依赖关系，并重新排列指令顺序。但软件流水对编译器的要求很高，而且不是所有循环都能流水化。我的经验是，优先对最内层循环做软件流水，因为内层循环的迭代次数最多，收益最大。外层循环如果依赖关系复杂，可以保守一些，用简单的双缓冲就够了。5. 实测中的意外：那些仿真阶段发现不了的问题5.1 DRAM刷新带来的延迟抖动仿真的时候，我们通常把DRAM模型简化为固定延迟。但实际芯片上，DRAM需要定期刷新，刷新期间无法响应读写请求。如果刷新周期和计算周期发生共振，延迟抖动会非常明显。我遇到过一次：某个网络层的计算时间恰好是DRAM刷新周期的整数倍，导致每次计算到关键路径时都撞上刷新，延迟直接翻倍。解决办法是在编译器里加入刷新感知调度，把对延迟敏感的数据搬运安排在刷新窗口之外。这需要硬件提供刷新状态的指示信号，编译器据此调整指令顺序。5.2 电压降对SRAM时序的影响物理设计阶段，如果电源网络设计不当，局部电压降会导致SRAM时序违例。仿真时用的是理想电压，实际芯片上电压波动可能达到5%到10%。对于先进工艺节点，这个波动足以让SRAM访问失败。我的做法是在SRAM周围加去耦电容，同时在时序分析时留足够的margin。但去耦电容占面积，margin留太多又影响频率。这个平衡需要在项目早期就考虑，不能等到物理设计阶段再补救。5.3 温度对漏电功耗的反噬前面算功耗时用的是常温下的漏电数据。但芯片工作时温度会升高，漏电功耗随温度指数增长。如果散热设计没跟上，温度升高导致漏电增加，漏电增加又导致温度进一步升高，形成正反馈，严重时会导致热失控。所以在评估SRAM容量方案时，一定要用最坏情况下的温度来算漏电。我通常会在常温漏电数据上乘一个1.5到2.0的系数，具体取决于散热方案和工艺特性。6. 从项目迭代中沉淀下来的几条硬经验做了这么多颗芯片，有些教训是反复验证过的，我把它总结成几条，供参考。第一条：存储层次的设计要从负载出发，不要从工艺出发。先分析你的目标网络需要多少数据复用，再决定SRAM容量和层次。反过来做，先定工艺和SRAM容量，再去适配网络，往往会发现要么容量不够，要么浪费。第二条：编译器和硬件要一起设计，不能割裂。硬件提供什么粒度的数据搬运指令、什么级别的并行度，编译器才能做相应的调度。如果硬件设计完了再让编译器去适配，很多优化机会就错过了。第三条：仿真阶段就要把DRAM刷新、电压降、温度这些非理想因素考虑进去。等到流片回来再发现，代价太大。宁可仿真时保守一点，也不要流片后惊喜。第四条：数据复用不是越多越好，要看复用距离。一份数据在SRAM里待着不用，照样消耗漏电。复用的关键是让数据在被换出之前，尽可能多地被用到。第五条：留足够的验证余量。实际芯片的访存行为往往比仿真复杂，DRAM的bank冲突、刷新、温度影响，都会让实际带宽低于理论值。我在项目里通常会把仿真得到的带宽打八折来估算实际性能，这样流片回来才不会失望。最后分享一个我常用的评估方法：在项目早期，用访存字节数除以计算操作数得到一个"算术强度"指标。这个指标越高，说明计算越密集，对存储带宽的要求越低；指标越低，说明访存越密集，存储设计就越关键。对于典型的卷积网络，这个指标在10到100之间；对于Transformer类模型，因为注意力机制的存在，指标会低很多，这时候存储设计的重要性就更加突出。把这个指标作为架构设计的北极星，很多取舍就变得清晰了。