1. 从能跑就行到跑得高效AI芯片软硬件协同设计的核心命题聊到AI芯片的软硬件设计很多人的第一反应是这不就是堆算力吗。但真正在这个领域摸爬滚打过的人都知道算力只是纸面参数真正决定一颗AI芯片能不能用的是软硬件之间的配合是否到位。我见过太多项目芯片流片回来指标漂亮得很峰值算力标称几百TOPS结果实际跑模型的时候利用率连20%都不到大部分时间都在等数据搬运。这就是典型的硬件堆料、软件拉胯。这个系列的第二篇我想把重心放在软硬件协同这个核心命题上。第一篇我们聊了AI芯片的基本架构和设计流程这一篇要往深里走讲清楚三个问题为什么软硬件必须协同设计、协同设计具体协同什么、以及在实际项目中怎么落地这套方法论。不管你是做芯片架构的、写编译器的、还是做算法部署的只要你的工作和AI加速沾边这些内容都能帮你少走弯路。先给一个直观的类比。AI芯片的软硬件关系特别像一家餐厅。硬件是厨房设备和厨师团队软件是菜谱和点菜系统。你厨房里买了最贵的灶台、最快的切菜机但如果菜谱写得乱七八糟点菜系统和厨房的沟通全靠吼那出菜速度照样上不去。更麻烦的是AI这个餐厅的菜单还天天变——今天流行这个模型结构明天又出了新的算子厨房设备一旦定型就很难改所以必须在设计厨房的时候就预判到未来菜谱的变化趋势。这就是软硬件协同设计的本质在硬件定型之前就让软件团队深度参与用真实的模型负载去驱动硬件架构决策在软件设计时又充分理解硬件的脾气秉性把硬件的能力榨干。两边不是上下游的交付关系而是互相约束、互相成就的共生关系。2. 为什么先定硬件再配软件的老路走不通了2.1 传统瀑布式流程的致命伤早些年做芯片流程是很清晰的架构团队定规格前端团队写RTL后端团队做物理实现流片回来之后软件团队再往上适配。这套流程在通用CPU时代勉强能用因为CPU的指令集是通用的软件生态早就成熟了硬件只要兼容指令集就行。但AI芯片完全不是这个逻辑。AI芯片的指令集、数据流、存储层次都是为特定计算模式定制的没有现成的软件生态可以继承。如果还按瀑布式流程走等芯片回来软件团队才发现这个数据通路设计得根本没法高效实现卷积那就晚了改一版芯片几千万起步时间成本更是无法承受。我参与过一个项目架构团队为了追求面积效率把片上缓存设计得特别小觉得数据可以频繁从外部存储搬嘛。结果软件团队拿到芯片后发现主流模型的中间激活值根本放不下每次算子切换都要把数据写回外部存储再读回来带宽直接成了瓶颈实测性能只有理论值的15%。这就是典型的硬件决策没有考虑软件实际负载。2.2 模型演进速度倒逼设计方法变革另一个让传统流程失效的原因是模型演进太快。几年前大家还在卷卷积神经网络现在Transformer一统天下注意力机制、各种归一化层、动态形状这些都对硬件提出了完全不同的要求。硬件设计周期通常要18到24个月而模型架构可能半年就换一代。这意味着你设计硬件时参考的模型等芯片量产时可能已经过时了。怎么破答案是设计可编程性和通用性更强的架构而可编程性的边界在哪里必须靠软件团队用真实的、甚至未来的模型负载来评估。这里有个经验做架构评估时不要只用当前最火的模型一定要留出余量用一些可能成为未来主流的模型结构去压测。比如现在做设计就要考虑长序列、稀疏化、混合专家这些趋势对存储和互联的压力。2.3 协同设计到底能带来什么收益说点实在的。软硬件协同设计做得好能带来三个层面的收益。第一是性能层面。通过软硬件联合优化把数据复用做到极致减少无效的数据搬运。AI计算的瓶颈往往不在计算单元本身而在数据供给。协同设计能让存储层次、数据流、计算阵列的匹配度大幅提升实测性能提升两三倍是常有的事。第二是能效层面。AI芯片大量部署在边缘和端侧功耗是硬约束。软硬件协同可以在算法层面做量化、剪枝在硬件层面做相应的支持两边配合能把能效比做上去。第三是开发效率层面。如果软件栈设计得好算法工程师不用关心底层硬件细节用熟悉的框架就能把模型部署上去这才是AI芯片能规模化应用的前提。3. 协同设计协同什么四个必须对齐的关键接口软硬件协同不是开几次会、拉个群就能搞定的它需要在几个关键接口上做深度对齐。我把这些接口总结为四类每一类都决定了最终产品的成败。3.1 计算接口算子与指令的映射关系硬件提供什么样的计算原语软件怎么把模型算子映射到这些原语上这是最核心的接口。硬件设计时要定义好计算阵列的粒度、支持的运算类型是只支持定点还是也支持浮点支持哪些精度的混合、以及指令的编码方式。软件这边编译器要能把高层框架的算子拆解、融合、映射到硬件指令上。这里最容易出问题的是算子融合。比如一个卷积后面跟一个激活函数再跟一个归一化硬件如果支持把这几个操作在同一个数据通路上完成就能省掉中间结果的读写。但如果硬件没设计这个能力软件就只能老老实实分三步走性能差一大截。所以架构设计阶段软件团队就要把主流模型的算子组合模式梳理出来告诉硬件团队哪些融合模式最值得支持。3.2 存储接口数据在哪、怎么搬存储是AI芯片设计里最容易被低估的部分。计算单元再快数据供不上就是白搭。存储接口要协同的点包括片上缓存的容量和层次划分、外部存储的带宽和访问模式、数据在各级存储之间的搬运策略。软件团队需要根据真实模型的访存特征告诉硬件团队中间激活值大概多大、权重需要多少带宽、哪些数据有复用机会。我个人的经验是做存储设计时一定要建立精确的访存模型。不能拍脑袋说给个几MB缓存够了要用真实的模型跑一遍统计每一层的输入输出大小、复用距离、访存次数。这些数据是硬件定容量的直接依据。3.3 编程接口算法工程师看到的是什么这一层决定了AI芯片好不好用。理想情况下算法工程师用PyTorch或TensorFlow写好模型通过一个编译器就能部署到芯片上不需要手写任何底层代码。但现实往往很骨感。很多AI芯片的编程模型特别难用算法工程师得手动切图、手动指定数据放置、手动调优学习成本极高。这就是编程接口没设计好。好的编程接口应该做到高层框架无缝对接、自动算子映射和优化、对不支持的算子有优雅的降级方案。这需要编译器和硬件指令集紧密配合编译器知道硬件能做什么、不能做什么才能做出合理的调度决策。3.4 调试接口出问题了怎么定位这个接口经常被忽略但在实际项目中极其重要。AI芯片跑模型出问题可能是硬件bug、可能是编译器映射错误、可能是精度问题定位起来非常困难。硬件需要提供足够的性能计数器和调试寄存器让软件能观测到每个计算单元、每条数据通路的运行状态。软件这边要有配套的性能分析工具能把硬件计数器和模型层级对应起来告诉开发者这一层慢是因为访存瓶颈还是计算瓶颈。没有好的调试接口优化就是盲人摸象。我见过团队为了定位一个性能问题花了两周时间逐层加打印效率极低。4. 落地方法论把协同设计变成可执行的流程道理讲完了说说怎么在实际项目中落地。我总结了一套相对可操作的流程分四个阶段。4.1 阶段一负载驱动的架构探索这个阶段的核心是用数据说话。在架构定型之前软件团队要提供一份详细的负载分析报告内容包括目标模型清单、每个模型的算子分布、访存特征、计算强度、以及未来可能的模型演进方向。架构团队基于这份报告做架构探索用性能模拟器评估不同架构方案的优劣。这里的关键是模拟器要足够准确能反映真实的数据流和访存行为。很多团队用简化的解析模型做评估结果和实测差很远就是因为忽略了访存和调度的细节。这个阶段要反复迭代。架构方案改了软件团队要重新评估映射可行性软件发现某个算子没法高效映射架构团队要调整计算原语。来回几轮才能找到一个软硬件都满意的平衡点。4.2 阶段二软硬件联合建模与验证架构定了之后进入联合建模阶段。硬件团队写RTL软件团队写编译器和运行时两边用同一个模型负载做验证。这个阶段最重要的是建立统一的验证基准。硬件团队用仿真器跑模型软件团队用功能模型跑模型两边的结果要对得上。如果对不上要么是硬件RTL有bug要么是软件映射逻辑有问题必须查清楚。我建议在这个阶段就建立端到端的精度验证流程。AI芯片经常用定点计算量化的精度损失必须在早期就评估清楚。软件团队要能模拟硬件的量化行为硬件团队要保证量化逻辑和软件模型一致。4.3 阶段三流片前的软件先行芯片流片到回片有好几个月这段时间软件团队不能闲着。要用硬件的功能模型或者FPGA原型把整个软件栈跑通包括编译器、运行时、驱动、以及上层框架的对接。这个阶段的目标是芯片一回来就能跑通主流模型而不是从零开始调试。我见过太多项目芯片回来了软件还没准备好白白浪费几个月时间。FPGA原型在这个阶段价值巨大。虽然FPGA跑得慢但能验证功能正确性让软件团队提前发现和解决问题。有条件的话一定要做FPGA原型验证。4.4 阶段四回片后的联合调优芯片回来后进入最紧张的联合调优阶段。硬件团队和软件团队要坐在一起用真实的芯片跑真实的模型一起分析性能瓶颈一起找优化空间。这个阶段要建立快速迭代的闭环跑模型、采集性能数据、分析瓶颈、提出优化方案、验证效果。优化可能来自硬件配置的调整比如某些寄存器的设置也可能来自软件调度的改进比如算子融合策略、数据放置策略。一个实用技巧建立性能回归测试集每次优化后都跑一遍确保没有引入性能退化。AI芯片的优化很容易顾此失彼改了这里慢了那里没有回归测试就会失控。5. 几个容易踩的坑和应对经验5.1 过度追求峰值算力忽视实际利用率这是最常见的坑。架构设计时盯着峰值算力指标觉得数字越大越好结果实际模型跑起来利用率极低。应对方法把实际模型利用率作为核心设计指标而不是峰值算力。在架构评估阶段就要用真实模型测端到端性能而不是只看理论峰值。一般来说能跑到峰值算力的50%以上就算不错了能到70%就是优秀。5.2 软件栈设计滞后于硬件很多团队把软件当成硬件的附属品硬件设计完了才让软件团队介入。结果软件团队发现硬件有很多不合理的地方但已经改不了了。应对方法软件团队从第一天就参与架构讨论软件架构师要有和硬件架构师平等的话语权。软件栈的设计要和硬件设计同步推进而不是串行。5.3 忽视编译器的复杂度编译器是连接模型和硬件的桥梁但它的开发难度经常被低估。一个能高效映射各种模型、做好算子融合和调度的编译器工作量不亚于硬件设计本身。应对方法给编译器团队足够的资源和时间不要指望几个月就能做出成熟的编译器。同时编译器要和硬件指令集紧密配合指令集设计时就要考虑编译器实现的可行性。5.4 精度问题发现太晚定点量化是AI芯片的常规操作但精度损失如果发现太晚可能导致整个方案推倒重来。应对方法在架构设计阶段就建立精度评估流程用软件模拟硬件的量化行为评估主流模型的精度损失。如果某些模型精度损失太大要么调整量化策略要么在硬件上支持更高精度。6. 写在最后的一些个人体会做AI芯片软硬件协同设计这些年我最大的体会是这是一个需要翻译能力的岗位。硬件工程师讲的是时序、面积、功耗软件工程师讲的是算子、图优化、调度两边语言不通协同就无从谈起。真正高效的协同需要有人能把硬件的约束翻译成软件能理解的语言也能把软件的需求翻译成硬件能实现的方案。这个翻译角色可能是架构师可能是系统工程师也可能是资深的编译器开发者。不管是什么title核心能力是既懂硬件又懂软件能在两个世界之间自由切换。另外一点体会是协同设计没有银弹它是一个持续迭代、不断妥协的过程。硬件想要通用软件想要高效这两者天然有矛盾。好的设计不是消灭矛盾而是在矛盾中找到最优平衡点。这个平衡点怎么找靠数据靠真实的负载靠反复的验证。拍脑袋做决策最后一定会付出代价。如果你正在做AI芯片相关的工作我的建议是多花时间在前期评估上多用真实模型去驱动设计决策多让软硬件团队坐在一起吵架。吵架不是坏事吵明白了产品就靠谱了。
