1. 从能跑就行到跑得高效AI芯片软硬件协同设计的核心命题聊到AI芯片的软硬件设计很多人第一反应是算力多少TOPS功耗多少瓦但真正在一线做过芯片落地的人都知道这些纸面参数只是起点。一块AI芯片从定义到量产中间横跨了算法、微架构、编译器、运行时、驱动、框架适配等一长串环节任何一个环节掉链子最终用户拿到的就是一块跑得起来但跑得难受的板子。我见过太多项目硬件指标漂亮得不行结果模型部署上去利用率只有百分之二三十问题往往不出在芯片本身而是软硬件之间的那道缝没对齐。这一篇是AI芯片的软硬件设计系列的第四篇前面几篇分别聊了架构选型、数据流设计和存储层次这一篇我想把重点放在软硬件协同设计这个最容易被人低估、也最容易翻车的环节上。所谓协同设计说白了就是硬件设计的时候要想着软件怎么用软件设计的时候要理解硬件为什么这么设计。它不是一句口号而是一整套方法论和工程实践。适合谁看如果你是从算法转过来做芯片的、或者是从传统数字IC转过来做AI加速器的、又或者是做编译器/运行时需要跟硬件团队打交道的这篇内容应该能帮你少走一些弯路。我个人的判断是AI芯片的竞争到了今天这个阶段硬件架构的差距其实在缩小真正拉开差距的是软硬件协同的深度。同样一颗芯片协同做得好的团队能让它发挥出百分之七八十的峰值性能协同做得差的团队可能连百分之三十都摸不到。这个差距不是靠堆算力能补回来的。下面我就从几个具体的维度把这件事拆开来讲。2. 为什么先定硬件再配软件的老路在AI芯片上走不通2.1 传统芯片设计流程的惯性陷阱传统数字芯片的设计流程是相对线性的需求定义、架构设计、RTL实现、验证、综合布局布线、流片、回片测试、驱动开发、软件适配。在这个流程里软件往往是硬件基本定型之后才大规模介入的。这套流程在CPU、DSP时代是work的因为那些芯片的编程模型相对稳定指令集几十年不大变编译器生态也成熟软件团队拿到芯片之后照着手册写就行。但AI芯片完全不是这个逻辑。AI芯片面对的是快速演进的神经网络模型今天流行Transformer明天可能又冒出新的结构算子集合、数据布局、精度需求都在变。如果还按硬件先定死、软件后适配的老路走等芯片流片回来可能主流的模型结构已经换了一茬硬件上那些为特定算子做的优化全成了摆设。我见过一个项目硬件团队花大力气优化了某种卷积的专用数据通路结果回片的时候业界主流已经转向了另一种注意力机制那条通路基本闲置这就是典型的协同缺失。2.2 算法-编译-硬件的三角约束关系要理解协同设计得先理解这三者之间的约束关系。算法决定了计算图长什么样计算图里有算子、有数据依赖、有精度要求编译器要把计算图映射到硬件上它需要知道硬件的计算单元怎么组织、存储层次什么结构、有哪些专用指令硬件则要在面积、功耗、成本约束下提供尽可能高效的计算和访存能力。这三者是互相牵制的。比如算法里如果大量使用动态shape那编译器就很难做静态的算子融合和内存规划硬件如果只支持静态shape那这个模型就跑不动。反过来如果硬件提供了很灵活的动态调度能力但编译器不会用那这些能力就浪费了。协同设计的本质就是在这三者之间找到一个平衡点让约束尽量对齐而不是各做各的。2.3 一个真实的协同失败案例拆解说个我亲身经历的例子。某项目硬件团队设计了一个非常激进的片上缓存结构容量很大但访问粒度是固定的、比较大的块。硬件团队的逻辑是AI计算访存密集大块访问能提高带宽利用率。听起来没毛病。但软件团队拿到之后发现很多算子的实际访问模式是细粒度的、不规则的尤其是那些逐元素操作和归一化操作用大块访问反而造成了大量无效数据搬运有效带宽利用率掉得厉害。问题出在哪硬件团队假设的访存模式和软件实际产生的访存模式不一致。如果早期协同软件团队把典型模型的访存trace给硬件团队看硬件团队可能就会设计成可变粒度的访问或者至少提供一个细粒度的旁路通道。这个改动在架构阶段成本很低等流片回来再改就是不可能的事。所以协同设计的第一原则就是在架构定义阶段就要用真实的软件负载去驱动硬件决策而不是拍脑袋假设。3. 协同设计落地的四个关键抓手3.1 抓手一以算子库为契约的接口定义软硬件之间最重要的接口是什么不是寄存器手册也不是驱动API而是算子库。算子库是硬件能力的抽象层也是软件调用硬件的入口。协同设计做得好不好很大程度上看算子库这个契约定得清不清楚。我的经验是在架构阶段就要把算子库的接口雏形定下来包括支持哪些算子、每个算子的输入输出布局、精度支持范围、性能预期。这个接口一旦定了硬件团队就知道要为什么样的计算模式做优化软件团队就知道能依赖哪些能力。这里有个坑很多团队把算子库接口定得太细细到把硬件的微架构细节都暴露出来结果硬件一改软件全崩也有团队定得太粗粗到软件根本没法针对硬件做优化。好的接口应该是语义清晰、实现自由既表达清楚计算意图又不绑定具体实现。举个具体的做法定义算子的时候用逻辑张量的概念描述输入输出而不是用物理内存地址。硬件团队可以自由决定底层怎么布局软件团队只需要关心逻辑上的正确性。同时为每个算子标注一个性能契约比如在什么shape下应该达到多少利用率这样双方都有明确的验收标准。3.2 抓手二编译器与硬件的联合调优编译器是软硬件协同的枢纽它一头连着上层框架的计算图一头连着硬件的指令和数据通路。编译器做得好能把硬件的潜力榨干做得不好再好的硬件也白搭。联合调优的关键在于让编译器团队尽早拿到硬件的行为模型。注意不是等RTL写完而是在架构阶段就要有一个周期近似或者至少是带宽/延迟近似的性能模型。编译器团队用这个模型去评估不同调度策略的效果反过来告诉硬件团队哪些参数最影响性能。我参与过一个项目编译器团队发现某个中间缓存的bank冲突是性能瓶颈反馈给硬件团队后硬件团队调整了bank的映射方式性能直接提升了百分之十几。这种反馈如果等到流片后才发现就只能干瞪眼。具体操作上我建议建立一套编译器-硬件的联合仿真流程编译器生成调度方案喂给硬件性能模型模型输出周期数和瓶颈分析编译器据此调整。这个循环跑得越快协同效果越好。工具链上可以用SystemC或者自研的性能模型来做这件事关键是模型要足够快能支撑大量迭代。3.3 抓手三运行时对硬件资源的动态感知运行时系统是很多人忽略的一环但它其实是软硬件协同的最后一公里。运行时负责把编译好的算子调度到硬件上执行管理内存、管理多核、处理同步。如果运行时对硬件资源没有感知就会出现该并行的没并行、该复用的没复用的情况。一个好的运行时应该能感知硬件的计算单元占用情况、存储层次的使用情况、DMA通道的繁忙程度然后动态调整任务的分配。比如当某个计算单元空闲时运行时可以把等待中的任务提前调度过去当片上缓存快满时运行时可以主动触发数据回写。这些决策如果做得好能显著提升整体利用率。实现上硬件需要提供足够的性能计数器和状态寄存器让运行时能看到内部状态。这也是协同设计的一部分硬件设计的时候就要预留这些观测点而不是等软件团队来要。我见过一些芯片性能计数器少得可怜运行时基本是盲调效果自然好不了。3.4 抓手四精度与数值格式的端到端对齐AI芯片绕不开精度问题。训练用FP32推理可能用FP16、INT8甚至更低。硬件支持哪些精度、软件怎么量化、量化后的精度损失怎么控制这是一条端到端的链路任何一环没对齐都会出问题。协同设计在这里的体现是硬件团队要理解量化算法的需求软件团队要理解硬件数值格式的限制。比如硬件如果只支持对称量化那软件在做非对称量化时就要做转换转换会带来额外开销和精度损失。如果早期就对齐硬件可以同时支持对称和非对称软件就不用做转换。数值格式的对齐还包括累加器的位宽、舍入模式、饱和处理等细节。这些细节看起来琐碎但直接影响模型的最终精度。我的建议是在架构阶段就建立一个数值精度验证流程用真实的模型跑一遍量化仿真看看端到端的精度损失是否可接受再反过来确定硬件的数值格式。这个流程能避免很多回片后的返工。4. 协同设计中的工具链与流程建设4.1 性能建模从电子表格到周期精确模型性能建模是协同设计的基础设施。最粗糙的建模就是电子表格算算理论峰值、算算带宽需求快速但不准。再往上是分析模型用排队论、roofline模型来估算速度和分析精度平衡得不错。最精细的是周期精确模型能精确模拟每个周期的行为但跑得慢。我的实践是分层使用架构探索阶段用分析模型快速筛选方案确定大方向详细设计阶段用周期近似模型做调优关键路径上用周期精确模型做验证。不要一上来就追求周期精确那样迭代速度太慢反而拖累协同效率。工具选型上SystemC TLM-2.0适合做事务级建模gem5适合做体系结构探索自研的模型则更贴合特定架构。4.2 软硬件联合仿真环境的搭建联合仿真环境是协同设计的练兵场。理想情况下软件团队应该能在硬件还没流片的时候就在仿真环境里跑真实的模型评估性能。这需要把编译器的输出、运行时的行为、硬件的性能模型串起来。搭建这套环境的关键是接口标准化。编译器和硬件模型之间用标准的trace格式交互运行时和硬件模型之间用标准的API交互。这样各模块可以独立演进不会因为一方改动就全盘重来。我建议用JSON或者protobuf来定义这些接口可读性和扩展性都好。环境搭好之后软件团队可以每天跑回归测试硬件团队可以随时看到软件负载下的性能表现协同效率会高很多。4.3 回归测试与性能看板的建立协同设计不是一次性的工作而是持续的过程。要保证协同效果不退化必须建立回归测试和性能看板。回归测试覆盖典型的模型和算子每次硬件或软件改动后都跑一遍确保性能不下降。性能看板则把关键指标可视化让两个团队都能看到当前状态。看板上我建议放这几类指标峰值利用率、有效带宽利用率、各算子的耗时占比、编译时间、运行时开销。这些指标能快速定位问题出在哪个环节。比如峰值利用率低但带宽利用率高说明是计算瓶颈反过来则是访存瓶颈。有了这些数据协同讨论才有依据而不是互相甩锅。5. 那些只有踩过才知道的协同设计经验5.1 关于沟通节奏别等评审会才对齐协同设计最大的敌人不是技术难题而是沟通节奏。我见过太多团队硬件和软件各自埋头干等到季度评审会才发现方向对不上这时候返工成本已经很高了。正确的做法是建立高频的、轻量的同步机制。比如每周一次的技术对齐会不需要正式文档就说说这周遇到了什么问题、下周打算怎么做把潜在的冲突尽早暴露。还有一个技巧是结对工作让一个硬件工程师和一个软件工程师结对共同负责某个模块的协同。这样信息传递是实时的不需要经过层层汇报。我在一个项目里推行过这个做法效果非常明显很多问题在萌芽阶段就被解决了。5.2 关于文档接口文档要当代码来维护接口文档是协同的合同但很多团队的接口文档写完就扔在那跟实际实现早就对不上了。我的建议是接口文档要当代码来维护纳入版本管理每次改动都要review。更好的是用IDL接口定义语言来描述接口然后自动生成文档和桩代码这样文档和实现永远一致。具体来说算子接口、寄存器定义、驱动API这些都可以用IDL来描述。工具上可以用protobuf、Thrift或者自研的DSL。自动生成的好处不仅是省事更重要的是消除了人为的笔误和不一致。我吃过这个亏一个寄存器的位定义文档和RTL不一致软件按文档写结果功能不对查了好几天才发现是文档错了。5.3 关于优先级先打通端到端再优化单点协同设计容易陷入一个误区过早优化单点。比如硬件团队死磕某个算子的性能软件团队死磕某个编译pass的效率但端到端跑起来发现整体还是慢。正确的顺序是先把端到端打通哪怕性能很差但链路是通的然后再逐个优化瓶颈。这个原则说起来简单做起来难因为单点优化容易出成绩端到端打通往往费力不讨好。但从项目整体看端到端打通的价值大得多。我建议在项目早期就设定一个端到端里程碑比如某模型能在仿真环境里跑通并输出正确结果这个里程碑达成了再谈优化。5.4 关于人才懂两边的桥梁型工程师最稀缺最后说个现实问题协同设计最缺的是既懂硬件又懂软件的桥梁型工程师。纯硬件背景的人可能不理解编译器的约束纯软件背景的人可能不理解时序和面积的限制。能两边都懂、能翻译两边语言的人是团队的宝贝。培养这种人不容易我的经验是让工程师轮岗硬件工程师去软件团队待几个月参与编译器的开发软件工程师去硬件团队待几个月参与RTL的调试。轮岗之后他们对彼此的工作会有完全不同的理解沟通效率会大幅提升。当然这需要团队有足够的耐心和容错空间但长期看回报很高。6. 从架构定义到回片验证一个协同设计的完整时间线6.1 架构阶段软件负载驱动的硬件定义架构阶段是协同设计的起点也是最关键的阶段。这个阶段的核心工作是用真实的软件负载来驱动硬件架构的定义。具体怎么做先收集目标应用场景下的典型模型分析它们的算子分布、数据布局、访存模式、精度需求然后据此确定硬件的计算单元配置、存储层次、指令集设计。这个阶段软件团队要深度参与不能只给个需求文档就完事。我建议的做法是软件团队用分析模型或者早期的性能模型把典型模型的性能瓶颈分析出来告诉硬件团队这里最需要优化。硬件团队则根据这些输入在面积和功耗约束下做权衡。这个来回可能要迭代好几轮但每一轮都在缩小不确定性。6.2 设计阶段编译器与RTL的并行推进进入详细设计阶段编译器和RTL是并行推进的。这个阶段的关键是保持接口的稳定同时允许内部实现自由演进。编译器团队基于架构阶段确定的算子接口和性能模型开发调度和优化策略硬件团队基于同样的接口实现RTL。这个阶段要特别注意接口冻结的时间点。接口冻结太早可能架构还没探索充分冻结太晚两边都没法稳定开发。我的经验是在架构阶段结束时就冻结主要接口后续只允许向后兼容的扩展。冻结之后任何接口改动都要走正式的变更流程评估对两边的影响。6.3 验证阶段用真实模型做端到端验证验证阶段是协同设计的大考。这个阶段不能只跑单元测试和定向测试必须用真实的模型做端到端验证。具体来说把主流框架的模型导进来经过编译器、运行时在RTL仿真或者FPGA原型上跑看结果是否正确、性能是否符合预期。这个阶段最容易暴露协同问题。比如编译器生成的调度方案在RTL上跑不通或者运行时对硬件状态的假设和实际不符。发现问题不可怕可怕的是发现得太晚。所以我建议验证阶段要尽早开始最好在RTL基本可用的时候就介入而不是等所有模块都验证完。6.4 回片阶段软件团队的实战与硬件团队的陪跑回片阶段是软件团队真正上战场的时候。芯片回来了软件要在真实硅片上跑通、跑好。这个阶段硬件团队的角色是陪跑提供必要的调试支持分析性能瓶颈必要时通过微码或者固件来弥补硬件的不足。这个阶段最常见的坑是仿真和实测不一致。仿真环境里跑得好好的实测就是不行。原因可能很多时序问题、功耗问题、仿真模型不准等等。这时候需要软硬件团队一起定位用性能计数器、逻辑分析仪等工具一层层排查。我的经验是回片阶段要预留足够的时间和人力不要指望一次成功通常要经过几轮调试才能稳定。7. 写在最后协同设计是一种组织能力聊了这么多技术细节最后我想说一个可能更本质的观点软硬件协同设计表面上是技术问题底层其实是组织能力问题。它要求硬件团队和软件团队有共同的目标、共享的信息、互信的协作。技术工具和流程固然重要但如果两个团队各怀心思、信息不通再好的工具也白搭。我在实际项目里最大的体会是协同设计做得好的团队往往不是技术最强的团队而是沟通最顺的团队。他们愿意花时间对齐目标愿意为对方着想愿意在冲突时坐下来一起找方案。这种文化不是一天建成的需要从项目第一天就开始培养。如果你正在做AI芯片的软硬件设计不妨从下一次技术对齐会开始试着多问一句软件这边会怎么用很多问题可能就提前解决了。