两年前我参与一个AI加速芯片项目时硬件团队拿出来的峰值算力相当漂亮INT8下的理论吞吐标到128TOPSPPT上看起来一切都在正轨。可等软件团队把经典卷积网络移植上去实际吞吐只有峰值的一半多点换上注意力类模型直接掉到两成出头。这个结果其实不算意外——很多AI芯片项目的通病是硬件设计和软件栈分开迭代硬件先定稿流片软件再进场适配于是大量时间消耗在联调、争论架构细节、反复改数据路径上。我现在的核心体会是AI芯片的软硬件设计本质上是把“算力”变成“可用算力”的过程。峰值指标只代表天花板软件映射和系统协同才决定真实收益。这篇文章我会把软硬件协同设计这条链路拆开讲包括硬件侧的计算架构、存储层次与数据流软件侧的编译器、算子库与运行时调度以及两边如何在方案定稿前互相约束、互相迁就。内容适合做芯片验证、编译器开发、算法迁移的同行参考也适合刚接触AI芯片的读者建立一个整体框架。1. 算力只是入场券为什么实际性能总打骨折1.1 先搞清楚“TOPS”是怎么算出来的AI芯片标称的TOPS指的是理论上每秒钟能完成的定点乘累加操作总数。比如一个核里有2048个乘法器主频1GHz两个操作算一次MAC带来的2 ops那么单核就是2048×1GHz×2 4.096 TOPS。如果四个这样的核加起来就是16.38 TOPS左右。这个数据本身没算错但它忽略了三个真实世界里的关键变量第一吞吐是正交于数据搬运的。计算单元要吃到数据才能干活。片上缓存命中率高的时候还行一旦要频繁从外部DRAM反复搬数据计算单元只能在空转等待。第二并行效率不是天然满的。多核之间如果有同步、有锁、有负载不均核越多浪费的周期越多。第三软件栈能不能把计算图高效映射到硬件上是最大的变数。同一个模型手写算子调得好和直接用通用编译器生成代码性能能差出3到5倍。所以把TOPS当成唯一KPI来倒推设计是最容易踩的坑。硬件设计阶段应该从一开始就问一个问题在目标工作负载上我们实际能拿到百分之多少的峰值这个比例背后的决定权一半在硬件架构一半在软件工具链。1.2 三个绕不开的核心矛盾我习惯用三个词来概括AI芯片落地时的系统性矛盾算力带宽墙、并行效率墙、软件可控性墙。算力带宽墙讲的是“计算强度”问题。专业一点说每个算子从外部存储器读入的字节数和它能进行的运算次数之间有个比值。如果这个比值小于硬件能够支撑的平衡点硬件就处于带宽受限状态——加再多的MAC阵列也没用喂不饱。这个平衡点做硬件的人都很熟要么拼命堆片上缓存要么给DDR加更多通道。但在实际项目里带宽受限的算子往往比算力受限的算子更多尤其在小batch推理和稀疏场景下。并行效率墙来自任务划分和同步开销。比如一个可变长token序列的注意力计算不同头之间天然可以并行但中间层归一化又需要跨头汇总统计量这就要等待全部完成。很多调度工作表面上看起来是软件问题但追根溯源是硬件没给够细粒度的同步原语和异步执行通道软件只能挎着脚镣跳舞。软件可控性墙最容易让硬件团队反感但偏偏最关键。有些架构为了追求极致的峰值能效把数据流写死在控制逻辑里——表面上只需要简单配置几十个寄存器实际上各种约束条件复杂得一塌糊涂编译器想生成最优代码根本无从下手。硬件设计者觉得逻辑简单软件设计者觉得约束爆炸。这件裂缝如果不在架构阶段弥合后面就是无限期的补丁循环。提示判断一个AI芯片架构是否“软硬友好的”可以拿一个经典的通用计算法则——Roofline模型——去看横轴是计算强度运算数除以数据字节数纵轴是实际吞吐。斜线区是带宽限制水平区是算力限制。这个模型不是万能的但它能快速暴露系统瓶颈在哪一侧做协同设计时最好人人都会画。2. 硬件设计的关键算力结构、存储层次与数据流2.1 从通用核到专用加速核到底改了些什么传统CPU或者通用并行处理器追求的是“什么都能跑”。到了AI推理这个场景绝大部分算子是乘累加构成的规则结构于是硬件设计师想到把这些乘加器排成大规模阵列用固定的数据流协议让它们在空间上连成流水减少重复取指令和译码的开销。这就是专用加速核的基本思路。现实中AI加速核主要有三条路径向量阵列、脉动阵列、可重构数据流。向量阵列像是一个宽版本的SIMD单元一条指令驱动一批处理单元做同样的事脉动阵列让数据像脉冲一样流动每个处理单元只和最近的邻居通信权重做一个方向移动、激活数据做另一个方向移动适合矩阵乘可重构数据流则把数据通路和计算单元的连接做成可配置的理论上能匹配更多不规则算子但编译器复杂度陡增。表三种常用AI计算阵列的取舍结构类型优势劣势典型适用场景向量阵列实现简单、调试直观数据复用依赖软件显式搬运通用性强、算子种类杂的中小模型脉动阵列数据流固定、能效高不规则算子映射难矩阵乘与卷积占比高的场景可重构数据流灵活度最高编译器与校验复杂度大固定工作负载的定制推理引擎选哪种结构不能只看算力密度。脉动阵列的能效确实最优但前提是你的工作量绝大多数能被整形卷积或矩阵乘覆盖。如果模型里还有大量动态shape、稀疏索引、非规则分支脉动阵列的映射效率会直线下降。我见过一些项目硬件做得极其漂亮结果在内部评审时软件团队提交了一份算子映射覆盖率报告把产品经理都看沉默了。2.2 存储层次AI芯片里真正的“业绩功臣”如果算力阵列是厨房里的炒锅那存储层次就是后厨的备菜通道和水池。一个让人印象深刻的例子某型号芯片片上SRAM只有256KB却声称能跑复杂检测模型。软件团队实际做的时候不得不把一张中等分辨率的特征图切成很多个小块逐块计算计算开始前要先从DDR把数据搬进来算完再搬走一个算子的数据搬运次数翻了好几倍。结果就是功耗和延迟全部起飞。这里有一个可以推广的计算案例。假设处理一个32×32×128的特征图用3×3卷积输出同样分辨率权重形状是128×128×3×3约147KB。仅输入激活本身就有32×32×128×2字节 256KB。如果片上SRAM只有256KB就必须把输入先切块只放一部分通道进来算完再换下一批通道。每次切换都意味着一次DDR流量。而如果SRAM能扩到1MB整个算子可以一次性完成搬运开销几乎为零。这就是为什么不少边缘AI芯片设计时会刻意把SRAM堆到几MB甚至十几MB——这不是堆料是实打实的性能手段。存储层次设计里有三个指标要同时看容量、带宽、延迟。容量决定能不能装下一个算子或一个数据块带宽决定搬运速度延迟决定随机访问的代价。硬件团队经常只盯容量但软硬件协同设计时软件真正关心的是带宽——更准确地说是在计算单元持续运转的情况下后台DMA能否把下一块数据提前预取成功。这个“预取流水线”做得好不好比多几MB SRAM影响更大。2.3 数据流策略谁把数据复用起来谁就赢数据流策略决定了数据在阵列中的移动方式。经典分类里有三种主流方案权重固定weight stationary、输出固定output stationary、行流式row stationary。权重固定的意思是把权重先放进阵列的处理单元里然后不断向各个单元灌入不同的输入激活让同一套权重对多个输入进行复用。这个方案在做全连接和批量卷积时效率很高因为权重复用率高外部带宽压力小。输出固定的意思是把输出的一部分暂存在阵列内部反复从外部读取多个输入增量和中间的权重适合输出特征图很小、输入特征图很大的情况。行流式则让数据沿着阵列的某一行流动每一行负责一条卷积滑窗路径兼顾中间结果的复用。这几个方案没有绝对好坏关键是硬件要在体系结构层面给软件提供足够的选择空间。如果硬件已经把数据流方向写死成一种那软件就只能反过来被“教做人”——比如想优化的算子偏偏和固定数据流相性不合白白损失好几倍性能。所以我一直觉得数据流策略不是硬件一个部门的自嗨它本质上是一种接口设计硬件能支持哪些数据流动方式软件就能给出对应的最优映射两边越早对齐最终性能越可控。3. 软件栈的“翻译能力”编译器、算子库与运行时调度3.1 编译器不只是“能跑”还要“跑得稳”AI芯片软件的起点是把深度学习框架的计算图“翻译”成硬件指令。这里面最关键的两个阶段一是图优化二是算子映射。图优化阶段要对计算图做等价变换算子融合把卷积、批归一化、激活函数合成一个子图减少中间张量写回内存内存规划复用那些生命周期不交叠的缓冲布局转换解决NHWC还是NCHW的访存顺序问题。这些优化直接决定最终的搬运量和计算密度好的图优化可以让一个算子群减少一半以上的外部访存。算子映射阶段则要把一个融合后的算子分配到具体的计算阵列上。这里又分出两条路线一条是靠手写库比如把常用的卷积、矩阵乘预先用汇编或者高级循环调优成高性能版本然后编译时直接调用另一条是靠编译器自动调优自动搜索分块大小、循环顺序、片上缓冲分配策略。自动调优的好处是省人但搜索空间极大在小算子和不规则shape上经常迷失方向。成熟芯片的商用软件栈往往两条腿走路核心热算子走手写库边缘算子走自动生成加回退。3.2 算子库热算子的每一笔性能都要“抠”出来现实里很多AI芯片项目的软件团队第一批任务不是写一个万能编译器而是把一个核心算子库做出来矩阵乘、卷积、缩放点积注意力、层归一化、Softmax、池化等等。为什么这些算子被单独拎出来因为它们在整个模型里被调用的频率最高、耗时占比最大。一个卷积算子如果能从通用实现的100个周期压到40个周期整个模型端到端性能的提升会比优化一堆边角算子明显得多。手写算子优化的套路其实很成熟先做数据分块让每个循环嵌套的数据块能完整放进片上SRAM再做向量化和双缓冲计算单元算当前块的同时DMA预取下一块最后按阵列宽度做并行切分必要时直接用汇编控制寄存器级的数据重排。这三板斧下去大部分算子的利用率就能从30%拉到60%以上。我特别想多说一句Transformer场景。现在注意力类模型里很多工作是从“算中间矩阵”变成“在片上把中间结果算完并直接汇聚输出”尽量避免把QK^T这个大矩阵完整写到DDR。硬件设计者如果能在架构里支持这种“算子内联融合”的带宽模式软件侧的收益会成倍放大。这个思路按传统硬件设计不太容易想到因为最直观的分解方式是把每个子操作当成独立算子来做流水但真正高效的做法必须跨越算子边界。3.3 运行时调度多核并行里的“机关算尽”编译器和算子库把“单算子性能”做到极致之后还有一个被很多人忽视的环节运行时的多核调度与任务流水。多核芯片在执行一个深度模型时如果只是简单地把算子按层拆分到不同的核上经常会遇到两个问题。一是负载不均有的层计算密集有的层访存密集核与核之间完成时间差异很大。二是同步开销一个层的输出是下一层的输入就必须等待所有相关核完成任务、写出共享内存或DDR这个同步点会成为明显的停顿。好的运行时需要图级的依赖调度把计算图按算子的数据依赖关系展开成任务图再按核的空闲度和访存距离动态派发。它还要管理好DMA请求的优先级让计算密集的任务和搬运任务尽量重叠。另外内存分配策略也非常关键。重复的malloc/free不仅是性能杀手还可能造成碎片。成熟的实现通常做内存池复用按张量的生命周期做区间着色把内存分配规划成一个静态编排问题。有一点必须说清楚运行时调度看起来是纯软件的事但它对硬件接口的要求一样严格。如果硬件没有提供细粒度的中断和事件通知机制没有足够清晰的内存屏障指令软件只能在保守的时间点做同步白白把流水线压扁。这就是典型的“硬件给软件添麻烦”的情形。4. 软硬件协同设计的具体方法论先约束再实现4.1 用性能模型把“纸上算力”变成“可达吞吐”软硬件协同的第一步是建立一个可计算的性能模型让架构方案还没有真正成型时就能预测某个算子配置在特定硬件参数下的表现。这个模型不需要非常精确能指导方向就行。下面这段伪代码可以说明基本思路给定一个算子、片上SRAM大小、DDR带宽、MAC阵列吞吐估算实际能跑出多少吞吐。它会在可能的分块方案中枚举一部分找数据搬运和计算之间的平衡点def estimate_throughput(ops, weight_bytes, act_bytes, sram_bytes, ddr_bw, mac_tops): # 先看整个算子能否一次放进SRAM if weight_bytes act_bytes sram_bytes: bytes_moved weight_bytes act_bytes # 理想情况只搬一次 else: # 必须分块用每个tile能放下的大小去估算搬运次数 tile_ratio (weight_bytes act_bytes) / sram_bytes bytes_moved (weight_bytes act_bytes) * max(tile_ratio, 1.0) compute_time ops / mac_tops # 假设峰值全开 move_time bytes_moved / ddr_bw # 假设带宽全部用来搬运 # 重叠后的时间大致是两者取大 total_time max(compute_time, move_time) return ops / total_time / 1e12 # 返回TOPS这个模型故意做得很粗糙但它的用处是在架构评审时快速回答“如果我把SRAM从0.5MB加到2MB某个模型的可用算力能提升多少”。我实际用下来这个一阶模型对“瓶颈在带宽还是算力”的判断准确率相当高足以在早期推翻一些看起来很美但不是为工作负载优化的设计方案。要做得再准确一点就需要加入循环展开、双缓冲、bank冲突、多核划分等微观因素。可以让硬件描述层提供参数化的面积和功耗模型软件团队用自动调优框架去搜索最优分块和循环变换。这一步投入不小但一旦跑通整个芯片项目就有了一个可以回放的“数字孪生”之后每一次架构改动都能先仿真验证而不是等流片回来再赌。4.2 把真实工作负载固化成“不可协商的输入集”协同设计中最容易犯的懒是拿一两个明星模型来做性能目标。实际上一个芯片要面对的工作负载往往是数十上百个模型的组合不同版本的卷积分支、各种shape的Transformer块、语音里长短不一的前后端、推荐系统里大量的embedding查表加稀疏交互。开发基线和验收基准如果不覆盖这些架构师和编译器工程师就是在互相猜谜。我的做法是项目启动后第一件事就是拉一个“工作负载档案”把目标模型集里所有算子展开统计每一类算子出现次数、每类算子计算强度分布、权重和激活的体积分布、batch大小和精度需求。然后把这些分布画出来让硬件团队看清真实访存压力集中在哪个区间让软件团队看清哪些算子必须重点优化。这个档案一旦定了就作为双方评审的输入集所有硬件指标争议都拿数据说话。表一个虚构边缘侧芯片的工作负载档案示例算子类别出现占比平均计算强度OP/Byte是否带宽受限优化优先级卷积45%950中等P0矩阵乘20%1800偏算力P0注意力计算10%480偏带宽P1归一化/激活12%120明显带宽受限P1嵌入/查表8%30严重带宽受限P2其余标量5%15严重带宽受限P2从这个表能直接读出设计优先级必须把矩阵乘和卷积的阵列做大但注意力、归一化和查表这些带宽敏感算子决定了缓存和带宽不能省。如果某版架构为了冲算力把SRAM砍了三分之一表格里P1和P2那批算子的性能就会雪崩端到端效果反而下降。4.3 把指令集和寄存器配置当成“API”来评审硬件团队看指令集习惯从实现复杂度出发指令越少、模式越固定验证越容易。软件团队看指令集想的是编译器好不好生成、调试信息能不能透传、profiling能不能拿到周期级别的数据。这个视角差异会直接体现在项目后期的工作量上。一个典型的反面教材是硬件定义了一个很优雅的“自动卷积模式”配置好寄存器之后硬件自动完成全部卷积和数据搬运。优点是硬件实现高效、软件调用简单但编译器在混合算子场景中几乎无法插入自己的优化排障时又很难观测内部中间状态。等到某个特殊形状的卷积出来了硬件自动模式处理不了软件只能退回到一个极其低效的通用循环实现性能惨不忍睹。所以我的建议是指令集扩展要以“软件能否生成高质量实现”为准绳来做立项评审。每一个新的硬件功能都要配套给出一个软件抽象层设计草案、一个编译器支持的评估报告、一个profiling观测点的占位。换句话说硬件添加一条指令的门槛应该和软件发布一个公共API版本的门槛一样高。这样才能从源头上逼着两边把约束对齐。5. 实际项目中最容易被低估的三件事5.1 调试工具链残缺直接拖垮交付周期硬件功能不跑通大家都能紧张起来可芯片能跑通但性能上不去的时候真正拉后腿的往往是调试工具链。没有cycle级模拟器软件团队只能在板卡上反复跑已编译好的程序printf想打在硬件内部的某个buffer上结果发现根本没有这个调试通道想统计某个算子的真实搬运量发现硬件计数器只有两个而一个工程同时需要的数据包括MAC利用率、DDR带宽、总线饥饿周期、同步等待时间。这种项目光靠猜和反复实验效率极低。我现在做任何芯片项目都坚持把“可观测性”写进硬件需求。至少每个计算组要留有足够的性能计数器DMA和计算流之间要能打时间戳工具链要能自动生成访存热点报告。这个东西前期的投入确实不小但一次调试周期的缩短往往就能值回全部成本。对一个软硬件协同项目来说尽早建立“循环模拟器硬件计数器离线profiling”三件套相当于给项目上了三道保险。5.2 算子的“边角情况”反而花掉了大部分精力很多软件团队一开始都信心满满卷积、矩阵乘、注意力这些核心算子代码都能调出漂亮数字。真正开始做整模型适配的时候才发现工作量被大量边界情况吃掉了动态shape带来的循环上界变化、padding和mask让卷积边界分支剧增、分组卷积和空洞卷积对数据重排要求不同、不同batch下内存对齐策略要换。这些情况里核心算子库那一套“精心调过的分块方案”往往直接失效性能表现和通用实现差不多。应对这种情况一个比较务实的策略是“热算子精细冷算子通用”把算子池按频率分成三层对最高频的一小撮做极致的汇编级优化对中频算子用编译器自动调优生成较优代码对最低频的算子直接走通用实现加回退路径。用这个分层策略可以把有限的软件人力集中在收益最大的地方而不是试图让所有算子都达到手工调优的水准。这个思路听起来简单但做过的团队都知道克制住“想让每个算子都好看”的冲动有多难。5.3 性能验收口径必须提前定死软硬件协同项目最伤士气的阶段就是验收口径打架。硬件说“我们理论峰值够高”软件说“端到端延迟不合格”市场说“竞品在这个batch下比我快30%”。如果没有统一的标准每一次性能汇报都变成各说各话问题迟早上升到管理层互相扯皮。我的建议是在项目立项时就把验收口径和白纸黑字的benchmark定下来是单流延迟优先还是多流吞吐优先batch大小固定多少是否需要包含动态shape的最差情形精度是INT8还是FP16混合范围是纯模型推理还是包含前后处理。所有优化和架构调整都围绕这份口径来评审。哪怕平行对比时设计目标变化了也要先改口径文档再改方案避免用不同的口径随机解释性能结论。我自己还有一个习惯每次跑完性能都在报告里显式列出“当前模型的计算强度是多少、硬件参考平衡点是多少”让管理层能看出这次结果到底是算力受限还是带宽受限。这种数据化的复盘方式能把经验沉淀下来也让下一次架构讨论有据可依。软硬件协同设计不是一个玄学它就是一轮一轮地用真实工作负载倒逼架构决策、又用架构反馈重塑软件策略的过程。做久了你会发现最值钱的不是某一个惊艳的算子实现而是这套让两边持续对齐、持续验证的方法本身。