1. 从算力焦虑说起为什么第八代设计思路必须换脑子做AI芯片这行的人最近两年普遍有一种感觉架构图越画越复杂流片一次比一次贵但客户拿回去跑真实模型反馈依然是带宽不够利用率上不去功耗压不住。问题出在哪不是某一项技术不行而是软硬件之间的那道墙越来越厚。做硬件的按峰值算力指标交差做软件的按框架层能跑通验收中间那片真实负载下的效率成了三不管地带。我参与过几个不同规模的AI加速项目从边缘端的小算力推理芯片到数据中心级的训练加速卡踩过的坑几乎都指向同一个结论第八代AI芯片的设计重心已经从堆算力转向软硬件协同定义。这个转变不是口号它直接决定了架构怎么定、工具链怎么搭、验证怎么做。这篇文章适合三类人看一是正在做AI芯片架构定义、想知道别人怎么权衡取舍的硬件工程师二是负责编译器、算子库、运行时调度的软件工程师想理解底层硬件到底给了什么约束三是技术管理者需要判断团队在软硬件协同上该投入多少资源。我会把为什么这样设计讲透把具体怎么做落到可操作的层面同时分享一些只有真正流过片、调过板子的人才会遇到的细节问题。先给一个核心判断AI芯片的软硬件设计本质是在灵活性和效率之间找一个可验证的平衡点而这个平衡点必须用真实模型负载来标定不能靠纸面参数拍脑袋。2. 架构定义阶段先想清楚给谁用、跑什么、怎么扩2.1 从目标负载反推计算阵列规模很多团队一上来就讨论做多少个MAC单元支持不支持稀疏计算这是典型的顺序错误。正确的做法是先把目标负载画像做出来。你需要回答几个具体问题主要跑的是Transformer类模型还是CNN类推理还是训练batch size的典型分布是什么序列长度集中在哪个区间举个例子如果目标场景是边缘端视觉推理典型模型是轻量级CNN和少量ViT变体那么计算阵列的设计重点应该放在高利用率的中小规模MAC阵列上而不是盲目追求峰值TOPS。因为边缘场景的batch通常很小甚至batch1大阵列在这种负载下利用率可能只有百分之十几面积和功耗全浪费了。反过来如果是数据中心级训练加速矩阵乘的维度大、batch大那就需要更宽的阵列和更高的片上带宽。但即便如此也要考虑矩阵乘的尾块问题——当矩阵维度不能被阵列尺寸整除时边缘计算单元的空转怎么处理。这个细节在架构阶段不考虑后面软件再怎么优化也补不回来。我的经验是计算阵列的规模应该由目标负载中出现频率最高的矩阵维度区间来决定而不是由理论峰值来倒推。具体做法是拿几个代表性模型统计所有矩阵乘操作的维度分布画出直方图取覆盖80%操作的那个区间作为设计基准。2.2 存储层次的设计比计算单元更考验功力AI芯片的性能瓶颈十有八九出在存储上。计算单元再快数据喂不进去就是白搭。第八代设计里存储层次的设计有几个关键决策点。第一个决策是片上缓存的分级策略。常见的有两种思路一种是统一的大容量SRAM池靠交叉开关连接另一种是分级缓存L1靠近计算单元、L2共享。统一SRAM池的优点是灵活性高任何计算单元都能访问任意地址缺点是交叉开关的面积和功耗随容量增长很快而且访问延迟不均匀。分级缓存的优点是局部性好、延迟可控缺点是需要软件显式管理数据搬运对编译器要求高。我倾向于在训练芯片上用分级缓存因为训练时数据复用模式相对规整编译器可以做很好的分块和调度在推理芯片上如果模型结构变化大统一SRAM池的灵活性更划算。但这个选择没有绝对答案关键看你的软件团队能不能把对应的数据搬运策略做出来。第二个决策是片外带宽的预算分配。这里有个容易犯的错误把片外带宽当成越大越好的指标去堆。实际上片外带宽的功耗占比很高而且很多时候瓶颈不在总带宽而在访问模式的效率。比如同样是读取一个矩阵按行连续读和按列跳跃读实际有效带宽可能差好几倍。所以架构阶段就要和软件团队一起确定权重、激活、梯度分别用什么访问模式需不需要硬件支持转置或重排。2.3 可扩展性从单芯片到多芯片的接口预留第八代设计里单芯片算力再强也有限多芯片互联几乎是必选项。但互联接口的设计不能等到最后再加必须在架构阶段就预留。关键问题是芯片间通信的粒度是什么是粗粒度的参数同步还是细粒度的激活值交换这直接决定了互联带宽和延迟的要求。如果是训练场景的梯度同步通信量大但可以批量做对延迟相对宽容如果是推理场景的流水线并行中间激活值要实时传递延迟就非常敏感。我的建议是在架构阶段至少预留两种互联模式——一种高带宽低频率的批量传输通道用于参数和梯度一种低延迟的细粒度通道用于流水线激活传递。具体协议可以根据目标场景选但物理层和接口逻辑要提前规划好不然后面想加都加不进去。3. 软件栈的隐形契约编译器到底需要硬件提供什么3.1 指令集设计别让编译器猜你的心思做AI芯片的硬件团队经常忽略一件事编译器不是万能的它需要硬件提供明确的契约。这个契约就是指令集和硬件暴露给软件的控制接口。我见过一些设计硬件功能很强大但指令集设计得很含蓄——比如一个复杂的矩阵运算硬件内部做了很多优化但指令只给了一个启动和完成信号中间的状态、分块策略、数据预取全让编译器自己猜。结果就是编译器只能保守处理硬件能力发挥不出来。好的做法是把硬件的关键控制点显式暴露给编译器。比如数据预取的触发条件和粒度计算单元的分块模式和累加器分配片上缓存的替换策略和锁定机制多计算单元之间的同步原语这些控制点不需要全部暴露给上层框架但必须让编译器能拿到。编译器根据这些信息做调度决策才能把硬件用满。3.2 算子库的最后一公里手写汇编什么时候必须上自动代码生成再厉害总有一些算子是编译器搞不定的。这些最后一公里的算子往往决定了整个芯片在实际模型上的表现。哪些算子容易成为瓶颈根据我的经验主要有三类非规则访存的算子比如稀疏矩阵乘、变长序列的注意力计算需要特殊数值处理的算子比如LayerNorm、Softmax里的归约操作融合后的复杂算子比如FlashAttention这种把多个操作揉在一起的对于这些算子手写汇编或内联函数是必要的。但手写不是乱写要遵循几个原则首先手写算子的接口要和自动生成的算子保持一致方便上层调用其次手写算子要有对应的参考实现方便验证正确性最后手写算子要针对目标硬件的特性做优化比如利用特定的寄存器分配、流水线排布。我个人的经验是一个AI芯片的软件栈里手写算子的比例控制在5%到10%比较合理。太少说明编译器不够强太多说明硬件设计对软件不够友好。3.3 运行时调度动态形状和静态图的折中AI模型部署时动态形状是个绕不开的问题。NLP模型里序列长度变化、视觉模型里输入分辨率变化都会导致计算图在运行时才确定。但硬件往往更喜欢静态的、可预测的负载。第八代设计里运行时调度需要在动态和静态之间找一个折中。常见的做法是**静态为主、动态为辅**把模型里形状固定的部分编译成静态执行计划把形状变化的部分做成动态调度的算子。动态部分的开销要控制住不能因为一个动态算子把整个流水线拖慢。具体实现上可以用形状分桶的策略把可能的输入形状分成几个桶每个桶对应一套预编译的执行计划。运行时根据实际输入选择最近的桶桶内的差异用padding补齐。这样既保留了动态性又避免了完全动态调度的开销。4. 验证与调优怎么证明你的软硬件真的合拍4.1 功能验证从单元测试到全模型回归AI芯片的验证工作量巨大但很多团队把精力花在了错误的地方。我的观点是验证要分层每层的目标和手段不同。第一层是计算单元的功能验证。这一层用形式化验证和随机测试结合确保每个MAC、每个累加器、每个存储单元的行为符合规格。这一层的覆盖率要尽可能高因为底层错误后面很难查。第二层是算子级的验证。每个算子要有独立的测试用例输入输出和参考实现比如CPU上的NumPy实现对比。这一层的关键是边界条件的覆盖极小的矩阵、极大的矩阵、非对齐的维度、特殊值0、NaN、Inf都要测到。第三层是全模型回归。拿几个代表性模型端到端跑一遍对比输出精度和性能指标。这一层最容易暴露软硬件协同的问题比如某个算子的调度策略导致整体流水线停顿。我踩过的一个坑是算子级验证全过了但全模型跑出来精度不对。查了很久才发现是两个算子融合后中间结果的数值精度损失超出了预期。这个问题在算子级测试里发现不了因为融合是编译器做的。所以全模型回归必须做而且要用真实的模型权重不能用随机初始化。4.2 性能调优从能跑到跑满的排查链路性能调优是最考验软硬件协同能力的环节。我总结了一个排查链路按顺序走下来基本能定位大部分性能问题。第一步看计算单元的利用率。如果利用率低先查是不是数据供给跟不上。用性能计数器看片上缓存的命中率、片外带宽的实际使用率。如果缓存命中率低说明数据复用没做好需要调整分块策略。第二步看流水线的气泡。如果计算单元利用率高但整体性能还是不行查流水线里有没有停顿。常见的停顿来源包括算子之间的同步等待、动态形状导致的重新编译、内存分配的开销。这些停顿在profiler里通常能看到明显的空隙。第三步看访存模式。如果前两步都没问题查访存效率。同样的数据量不同的访问模式实际耗时可能差很多。重点看有没有跨bank冲突、有没有非对齐访问、有没有可以合并的访问被拆散了。第四步看功耗和频率。如果性能达标但功耗超标查是不是频率拉太高了。有时候降一点频率性能损失很小但功耗下降明显整体能效反而更好。这个链路我用了很多次大部分问题在前两步就能定位。关键是每一步都要有数据支撑不能靠猜。4.3 精度与性能的权衡什么时候该差不多就行AI芯片设计里有一个永恒的张力精度和性能。浮点运算精度高但慢定点运算快但精度损失。第八代设计里混合精度已经是标配但怎么混、混到什么程度需要仔细权衡。我的经验是不要追求全模型统一的精度策略要按层、按算子来定。比如卷积层和矩阵乘层对精度相对宽容可以用低精度如FP16或BF16归约操作如Softmax、LayerNorm对精度敏感需要保留较高精度累加器通常要用比输入更高的精度避免累加溢出具体到实现上可以用精度传播分析的方法从模型输出往回推看每一层的精度损失对最终结果的影响有多大。影响小的层用低精度影响大的层用高精度。这样能在保证模型精度的前提下最大化性能。还有一个实用技巧在训练阶段就引入精度模拟。让模型在训练时就适应低精度推理的数值特性这样部署时精度损失会小很多。这个做法在业界已经比较成熟但需要训练框架和推理框架的配合。5. 那些只有流过片才懂的细节几个真实踩坑记录5.1 时钟域 crossing 的隐蔽 bugAI芯片里通常有多个时钟域计算阵列一个域、存储接口一个域、主机接口一个域。跨时钟域的信号同步如果没做好会出现非常隐蔽的bug——大部分时候工作正常偶尔在特定温度、特定电压下出错。我遇到过一次芯片在实验室跑了一周都没问题到了客户现场跑了两天就挂。查到最后是一个跨时钟域的FIFO在特定读写节奏下会出现亚稳态。这个问题在仿真里很难复现因为仿真器的时序模型和真实硅片有差异。教训是跨时钟域的设计要保守再保守。能用异步FIFO就用异步FIFO能用握手协议就用握手协议不要为了省面积或省延迟走捷径。而且跨时钟域的路径要做充分的时序约束和形式化验证不能只靠仿真。5.2 电源管理的最后一瓦AI芯片的功耗里动态功耗占大头但静态功耗漏电在先进工艺下越来越不可忽略。特别是大芯片静态功耗可能占到总功耗的20%到30%。电源管理不是简单地把不用的模块关掉。关断和唤醒的时序、关断时的状态保持、唤醒后的状态恢复每一个环节都有坑。我见过一个设计关断逻辑没问题但唤醒后某个寄存器的值丢了导致计算单元从一个错误的状态开始工作结果就是偶发的计算错误。实用的做法是电源管理策略要在架构阶段就定义好哪些模块可以独立关断、关断的粒度是什么、状态保存在哪里。而且要有完整的验证方案包括关断-唤醒的循环测试、边界条件下的状态检查。5.3 散热与频率的动态平衡高性能AI芯片的散热是个系统工程。芯片内部的温度分布不均匀热点区域的温度可能比平均温度高十几度。如果频率策略是全局统一的热点区域会先触发降频拖累整体性能。更好的做法是分区频率控制把芯片分成几个区域每个区域独立监测温度、独立调频。这样热点区域降频时其他区域还能保持高频。但分区调频需要硬件支持多个时钟域而且软件要能感知到频率变化并调整调度策略。我实测下来的经验是分区调频能把持续性能提升10%到20%代价是设计复杂度增加。对于功耗敏感的场景这个投入是值得的。6. 从第八代看下一代哪些方向值得提前布局6.1 Chiplet 与先进封装算力扩展的新路径单芯片的面积不可能无限增大Chiplet芯粒和先进封装成了继续扩展算力的主要路径。但Chiplet不是简单地把大芯片切小它带来了一系列新的设计问题芯粒之间的互联带宽和延迟、芯粒间的功耗分配、芯粒间的测试和良率管理。我的判断是下一代AI芯片的竞争很大程度上会落在封装和互联上。计算芯粒本身可能越来越标准化但怎么把多个芯粒高效地连起来怎么让软件感知到多芯粒的拓扑并做优化这是差异化的关键。提前布局的方向包括定义芯粒间的标准接口、开发跨芯粒的编译和调度策略、建立多芯粒的验证和测试流程。这些工作现在做下一代产品就能用上。6.2 存算一体离实用还有多远存算一体Compute-in-Memory是学术界的热点但工业界落地还面临不少挑战。主要问题在于模拟计算的精度和稳定性、存算阵列的编程和校准、与现有软件栈的兼容。我的看法是存算一体在特定场景如小算力、低功耗的边缘推理会先落地但在大算力训练场景短期内还是数字计算为主。如果你在做边缘端芯片可以开始关注存算一体的IP和工具链如果做数据中心芯片暂时不用急着切换。6.3 软件定义硬件可重构的边界在哪里软件定义硬件是个诱人的概念但可重构的代价往往被低估。可重构意味着更多的配置位、更复杂的控制逻辑、更长的编译时间。可重构的粒度越细灵活性越高但开销也越大。实用的做法是在架构里保留有限的、粗粒度的可重构能力。比如计算阵列的数据通路可以配置成不同的连接模式但不需要做到门级可重构。这样既能适应不同的算子需求又不会让编译和验证变得不可控。7. 给不同角色的一些实操建议7.1 硬件工程师多花时间理解软件在干什么做硬件的人容易陷入我的模块没问题就行的思维。但AI芯片是系统级产品硬件模块没问题不代表系统没问题。建议硬件工程师至少花20%的时间去理解软件栈在做什么编译器怎么调度、运行时怎么分配内存、算子库怎么调用硬件。具体做法可以是参与软件团队的评审、看编译器的输出日志、跑几个真实模型看看硬件计数器。这些经历会让你在设计硬件时自然地考虑软件的使用方式减少设计出来没人会用的情况。7.2 软件工程师别把硬件当黑盒做软件的人容易把硬件当成一个给定条件只在上层做优化。但AI芯片的软件优化空间很大一部分来自对硬件细节的理解。建议软件工程师深入理解硬件的关键特性存储层次、计算单元的流水线结构、指令的延迟和吞吐。具体做法可以是读硬件的微架构手册、用性能计数器做profiling、和硬件团队讨论瓶颈问题。理解硬件之后你会发现很多软件优化其实是在弥补硬件设计的不足而有些硬件限制其实可以通过软件策略绕过。7.3 技术管理者软硬件协同需要组织保障软硬件协同不是靠个人英雄主义能实现的需要组织上的保障。建议在团队结构上做两个调整一是设立跨软硬件的架构组负责定义接口和协同规范二是让软硬件团队共享同一个性能指标避免各自为政。我见过的最有效的做法是软硬件团队坐在一起用同一个profiler工具看同一份性能数据。当大家看到的是同一组数字讨论就有了共同语言决策也会更务实。8. 一个实用的检查清单你的软硬件协同做到位了吗最后分享一个我在项目中常用的检查清单用来评估软硬件协同的成熟度。这个清单不是理论框架是从实际项目中总结出来的每一条都对应着具体的踩坑经历。架构阶段目标负载的画像是否清晰有没有用真实模型做过统计分析计算阵列的规模是否由负载特征决定而不是由峰值指标倒推存储层次的设计是否考虑了软件的数据搬运能力多芯片互联的接口是否预留了足够的灵活性软件栈阶段指令集是否暴露了足够的控制点给编译器手写算子的比例是否合理有没有覆盖关键瓶颈算子运行时调度是否支持动态形状动态开销是否可控精度策略是否按层、按算子做了差异化验证阶段是否有分层验证方案每层的覆盖目标是否明确全模型回归是否用了真实权重是否覆盖了边界条件性能调优是否有系统的排查链路是否用数据驱动决策跨时钟域、电源管理等隐蔽问题是否有专门的验证方案组织保障软硬件团队是否有共同的性能指标是否有跨团队的架构组负责接口定义软硬件工程师是否理解对方的工作方式和约束这个清单我每次项目评审都会过一遍每次都能发现一些被忽略的点。软硬件协同没有终点只有不断迭代。第八代设计里踩过的坑就是下一代设计的起点。