1. 为什么GPU不能通吃所有AI场景从算力垄断到专用芯片做了几年AI芯片的软硬件协同设计我经常被问到同一个问题现在GPU这么强H100、A100都上万卡了为什么还要费劲搞专用AI芯片等GPU大规模铺开之后市面上那些小芯片不就都成了摆设吗说实话这个问题在五年前问出来我还得组织一下语言才能解释清楚。但现在业内几乎已经达成共识了——GPU很强但它强在通用并行计算而不是AI推理计算。这两者之间的差距恰恰是专用AI芯片的生存空间。先看一组很直观的数字。以目前主流的LLM推理场景为例GPU的利用率通常在30%到50%之间徘徊。这不是说GPU性能不行而是因为Transformer结构的解码过程是token一个一个出来的每一步都有前后依赖这导致计算密度天然被切得很碎。GPU为大规模矩阵并行而设计的SIMT架构在这种每个请求只有一小段矩阵运算、但请求并发数量极多的场景下会出现两个问题一是小矩阵运算无法填满数千个CUDA core二是频繁的kernel launch和显存读写让带宽成为瓶颈。我实测过在一个8卡GPU服务器上跑7B模型的批量推理pipeline中间有大量时间花在等待显存带宽上而不是真正在算。专用AI芯片的路子就完全不同。它从一开始就明确了一个核心问题你要跑的模型里面绝大多数计算量集中在卷积、矩阵乘、向量运算这三种模式上而且这些模式本身有极大的并行度。既然如此我干脆放弃通用性把这几种运算做成硬连线的计算阵列再围绕计算阵列设计专门的存储和调度逻辑。这样一来同样的制程工艺下AI芯片的每瓦算力和每美元算力都能比GPU高出数倍。以英伟达A100的FP16算力约312 TFLOPS为例很多国产AI芯片在同等功耗区间内推理性能密度其实已经能做到接近甚至超越了。这背后是一个经典的经济学逻辑GPU是瑞士军刀什么都能干但每件事都不够极致AI芯片是专用刀具只干一件事但干得极好。对于互联网厂商、自动驾驶公司、安防厂商这些用户来说他们一年的推理服务成本动辄上千万元能把每瓦性能提升两倍省下来的电费和服务器采购费都足以覆盖芯片选型迁移的研发成本了。但这里要泼一盆冷水专用AI芯片也不是万灵丹。一旦你选择了专用就相当于把模型的运行方式焊死在了硬件上。模型结构一旦有大变化比如Transformer里引入新的算子原有的计算阵列可能就发挥不出效率了。所以华为、谷歌这些做AI芯片的公司在架构设计之初就会广泛调研未来两三年可能出现的算子类型尽可能让计算阵列覆盖主流的矩阵形态和激活函数。我做软硬件协同设计时最深的一个体会是AI芯片能不能打不只是看芯片本身的峰值算力更要看整个软件栈能不能把模型高效地映射到硬件上。硬件是骨架软件是血脉两者缺一不可。这一篇我准备把AI芯片软硬件设计的核心内容和盘托出重点讲清楚计算阵列、存储层级、编译器调度、精度量化这几个关键模块是怎么协同工作的以及我在实际项目中踩过的坑和总结的经验。不管你是做框架开发、算子优化还是想入门芯片架构设计这一篇都能给你一个相对完整的全局视角。2. 一块AI芯片的骨骼计算阵列、存储层级与数据流架构很多人第一次接触AI芯片架构容易被各种专有名词劝退什么脉动阵列、片上网络、近存计算、HBM带宽。但拆开来看AI芯片的硬件核心就三件事算力从哪里来、数据放哪里、数据怎么流。2.1 计算阵列为什么是MAC而非通用ALUAI芯片最底层的计算单元叫MACMultiply-Accumulate乘累加单元一个MAC一次能完成一个乘法和一个加法。卷积运算和矩阵乘法的本质就是大量乘累加操作的叠加。以一次矩阵乘法C A×B为例C中每个元素都是A的一行和B的一列逐元素相乘再求和的结果这个逐元素相乘求和就是MAC的职责。专用AI芯片的做法是在芯片上把成百上千个MAC排列成一个阵列比如经典的8×8、16×16、32×32脉动阵列。所谓脉动阵列数据像血液一样在阵列中按节拍流动每个MAC只和相邻的MAC通信算完的结果沿着阵列边缘输出。这种设计有两大好处一是大幅减少访存次数因为数据在阵列内部被多处复用不需要每次都从外部存储搬数据二是逻辑简单每个MAC只需要一个乘法器和一个加法器时钟频率可以拉得很高。我在设计一个AI推理芯片的原型时最初选的脉动阵列尺寸是32×32。后来跑了一圈模型算子覆盖率分析发现对于ResNet那种7×7卷积32×32阵列的实际利用率只有60%多因为卷积窗口的有效复用宽度不够大。后来调整为16×16单算子效率提升了15%但峰值算力下降了因为阵列规模变小了。这就是一个典型的权衡阵列尺寸越大峰值算力越高但算子适配难度也越大。没有完美的架构只有针对目标模型集的最优解。2.2 存储层级片上SRAM为什么比HBM更值钱算力再高数据喂不进去也是白搭这就是业内常说的内存墙问题。AI芯片的访存体系通常分三层寄存器堆、片上SRAM静态随机存取存储器、片外DRAM或HBM。其中片上SRAM的容量虽小通常在几MB到几十MB之间但带宽极高读写延迟只有几个纳秒而HBM的带宽虽然也很大但延迟在百纳秒级别而且功耗高得多。所以AI芯片软硬件设计的核心目标之一就是让模型计算的中间结果尽可能留在片上SRAM里减少往片外搬数据的次数。这个思路跟我们平时写代码时用CPU缓存是类似的但AI芯片把这个思想做到了极致。设计者会仔细分析每一层的输入输出尺寸、中间激活值大小然后反推需要多大的片上SRAM才能装下整个计算图的活跃数据。以MobileNet这类轻量级模型为例单层卷积的输入特征图加权重加输出特征图压缩后大约几十到几百KB。如果把片上SRAM做到8MB左右就能在内存中完成大部分层之间的数据传递避免频繁回写DRAM。我实测过一个推理场景把片上SRAM从4MB增加到8MB整体能效比提升了接近30%因为DRAM访问次数大幅减少。但SRAM是芯片上最贵的资源之一面积大、工艺要求高不能无限加。这里就必须靠编译器做精细的数据生命周期管理这点我后面会展开讲。2.3 数据流架构权重固定、输入固定还是输出固定每个AI芯片设计团队在设计之初都躲不开一个灵魂拷问数据流怎么组织业内主流的方案有三种权重固定Weight Stationary、输入固定Input Stationary、输出固定Output Stationary。权重固定是把权重数据尽可能留在计算阵列内部外部输入的数据在阵列中流动重复利用已经加载的权重。这种方案尤其适合卷积神经网络因为同一个卷积核会被反复用到不同的图像位置上权重复用率极高。输入固定则适合权重经常变化、输入数据相对固定的场景。输出固定适合计算流程中输出结果复用度高的模型。我当时参与的那个推理芯片项目最终选了权重固定作为主数据流原因很直接目标模型集都是CNN大类权重加载一次后可以服务整批图片复用收益最大。但为了保证未来对Transformer模型的兼容性我们又额外增加了对输出固定的支持。这个决定在后续适配Bert模型时起了大作用否则仅仅靠权重固定注意力矩阵的计算效率会低得难看。数据流架构的选择不是从一而终的游戏。我见过有些团队为了追求极致的CNN效率把数据流方案焊得非常死结果过了两年主流的模型变成了Transformer芯片的竞争力瞬间塌了一半。这个领域架构设计必须兼具眼前和未来的考量预留可配置的灵活性。3. 软件栈才是硬骨头编译器、算子库与运行时调度如何让芯片跑起来如果硬件是AI芯片的骨架那么软件栈就是灵魂。一个设计得再精妙的计算阵列如果软件栈无法把模型高效地编译成底层指令它就只能躺在Spec里当摆设。我见过不止一个AI芯片项目流片回来之后跑了整整几个月模型性能却一直上不去最后发现瓶颈不是硬件bug而是编译器的调度策略出了问题。3.1 编译器到底在干什么从计算图到机器码的分层映射AI芯片编译器的工作可以拆成三步看第一步把PyTorch或TensorFlow的计算图解析成中间表示IR此时模型里的算子已经是一个个无依赖关系的节点了第二步将IR中的每个算子匹配到硬件支持的底层算子库或手写kernel上这一步叫算子映射第三步也是最重要的一步是对内存和运算顺序做全局调度决定每个中间张量在SRAM里的生命周期尽量让数据在片上流动而不是落到片外。在实际的AI芯片编译器中前两步做得再快对整体性能的影响也很有限真正决定芯片效率的是第三步数据安排。每拿到一个模型编译器都需要把整个计算图重排一遍。以GPT类大模型为例它包含数百个算子节点每个节点都产生若干个中间张量。如果编译器能精确地为每个张量分配片上SRAM空间并让相邻层的输出直接作为下一层的输入复用同一块内存区域就能把DRAM访问量压到最低极限。这里有一个很反直觉的现象对同一个硬件优化做得好的编译器跑同一个模型的性能可能是优化差的编译器的好几倍。而编译器的开发成本又极其高昂一个成熟的AI编译器通常需要几十人年的投入。这也是为什么AI芯片行业巨头都在拼命砸钱做软件生态因为硬件规格可以抄软件栈的积累才是真正的护城河。3.2 算子库为什么手写Kernel永远无法被模板完全替代编译器自动生成机器码的能力越来越强但一个残酷的事实是在AI芯片领域目前最高效的算子实现依然离不开资深工程师的手写Kernel。原因在于编译器擅长的是把逻辑正确的指令调度出来但它很难像人一样去洞悉计算阵列每个通道的时序细节做到极致利用。我举一个亲测的例子。一次卷积操作输入是一个112×112×64的特征图用3×3的卷积核输出通道是128。如果完全不写手写Kernel直接依赖编译器自动派发计算阵列的利用率只有55%后来同事花了三天时间手调了一个Kernel把卷积的滑动窗口切分方式从按通道切改成了按空间位置切同时为每个MAC的输入设计了双缓冲核心运算的间隙被完全填满利用率直接提升到88%。这中间30多个百分点的差距就是手写Kernel的价值。所以你会发现AI芯片公司虽然都在推自己的编译器但主力软件栈里算子库这条线从来没有被削弱过。算子库本质上是一组预编译的、手工优化的函数专门适配自家硬件的每一个细节。编译器遇到匹配的算子就直接调用算子库里的最终代码而不是临时去生成指令。这套策略保证了性能下限。3.3 运行时调度多模型并发与多核任务分配除了编译器和算子库运行时调度器Runtime Scheduler也是AI芯片软件栈的关键一环。尤其到了推理场景同一块芯片上往往要同时跑多个模型、多个请求不同的请求可能有不同的优先级和SLAService Level Agreement要求。调度器要做的事情就是把计算阵列的物理资源比如MAC阵列可以划分成多个逻辑分区动态分配给不同的任务同时保证每个任务不会饿死。我在做多任务调度时踩过一个很深的坑一开始为了追求吞吐最大化把计算阵列全部分配给一个大模型任务结果旁边那些小模型的时延飙升用户端P99延迟直接突破了可接受的阈值。后来调整了调度策略把阵列做成可抢占式分区每隔若干调度周期重新计算一次优先级和资源配额小模型的任务切进slice间隔里完成P99延迟回落到了正常范围。这里面的关键机制是时间分片空间分片的组合调度。空间分片把计算阵列切成几个独立区域时间分片让每个区域在不同的时钟周期执行不同的任务。两者结合才能同时满足高吞吐和低时延的诉求。这个调度层的复杂性往往被架构师们低估但它直接决定了芯片在实际部署时是否够稳。4. 软硬件协同设计的核心博弈精度、时延与内存墙如何权衡软硬件协同设计听起来是个很高级的词但落到具体工作里就是一连串的取舍和权衡。AI芯片的设计团队通常被分到硬件组和软件组但真正高效的做法是两组人从一开始就坐在一起讨论同一份设计规格。这一章我挑几个最典型的协同设计博弈点说说。4.1 精度量化FP16、INT8还是更低模型权重的精度选择直接影响芯片面积和计算效率。FP16比FP32瘦一半INT8又比FP16瘦一半而INT4的算力密度还能再翻一倍。真相是越低的精度MAC单元的晶体管面积越小、功耗越低、算力密度越高。但代价是模型精度损失甚至在某些层出现数值溢出。量化是我们做AI芯片软硬件协同设计时的头号大事。我参与过一次针对图像分类模型的量化实战精度目标是对标FP32的99%。实验下来纯INT8的全程量化方案精度损失到了98.2%不达标。后来我们采用混合精度方案前几层浅层特征对精度敏感保留INT16中间层用INT8最后的全连接层降为INT4。这样一来整体精度恢复到了99.1%而平均比特数只有8.3 bit比纯FP16方案的计算效率提升了接近一倍。这里要说一个经验混合精度量化里的关键不是把低精度强制用在所有层上而是先做逐层敏感度分析。你可以在目标硬件上用模拟器跑一遍逐层把精度从高往低调找出精度崩塌的临界层。那些对量化误差不敏感的层统统可以压到INT4甚至更低。这一步的收益远比拼命堆算力来得大。4.2 内存带宽的极限求解算子融合与数据复用片外DRAM的带宽是AI芯片最稀缺的资源之一。HBM的带宽虽然很高但和片上SRAM的带宽比起来还是差了两个数量级。所以软硬件协同设计里最大的优化空间就是减少片外访问。算子融合是最经典的手段。把相邻的卷积激活批归一化融合成一个算子在计算阵列里一次性完成所有步骤中间结果只存在寄存器里不落到片上SRAM更不落片外。这种融合不仅能大幅减少访存还能省掉好几轮kernel launch的开销这在时延敏感场景下尤为宝贵。我实测过一个Transformer的注意力算子融合优化原始的算子序列是矩阵乘-变换-缩放-Softmax-矩阵乘按照传统方式跑每次变换都要读一遍完整的注意力矩阵写完还要存回DRAM。融合之后整个注意力算子变成一个流水线矩阵乘的结果直接进入Softmax的输入缓冲区缩放、指数计算都在寄存器流水线上完成。最终一个注意力头的时延从原有方案的120微秒降到了70微秒融合的收益达到了42%。这种级别的大幅优化单纯靠硬件参数调整是做不到的必须软硬件一起改。4.3 静态形状与动态形状的拉锯战另一个容易被忽略的协同设计议题是对动态形状的支持。静态形状模型比如固定尺寸的卷积最容易优化因为编译器可以对每一层的SRAM分配做静态规划所有中间张量的地址都在编译期确定运行时只需要跟着指令走就行。动态形状则意味着模型输入的batch size在运行时才能确定编译器无法提前预知每层的数据尺寸只能做保守的内存分配SRAM利用率大幅下降。这个问题的本质是灵活性和效率之间的经典矛盾。为了兼顾两者一些AI芯片厂商引入了即时编译JIT机制模型第一次以某个shape运行时编译器现场做静态规划和kernel生成之后同样的shape直接复用编译产物。这样既保留了动态输入的能力又在下一次运行拿到了静态规划的性能。我在一个视频理解模型的项目里试过这套方案首批数据需要额外花200毫秒编译之后同shape的数据处理速度比纯解释执行快了三倍以上。5. 一个AI芯片项目的完整实战流程从规格定义到流片验证读到这里你可能对AI芯片的各个模块都有了大致概念。这一章我想用一个更贴近一线的视角把一块AI芯片从立项到验证的完整流程串起来。这个流程我在多家公司反复走过其中的坑和心得都是真金白银换来的。5.1 规格定义阶段先对准模型集不是先定峰值算力很多团队做AI芯片的第一步是拍脑袋定一个峰值算力数字比如我要做200 TOPS的芯片——这是最大的错误。正确做法是先定义目标模型集未来一到两年这枚芯片主要跑哪些模型是ResNet、YOLO这种CV模型还是BERT、GPT这种NLP模型模型的精度要求是什么典型时延要求是什么输入的分辨率或序列长度范围是什么基于模型集才能反推计算阵列的规模卷积和矩阵乘的FLOPs按层统计出来再除以目标时延得出所需的最小MAC吞吐再留出30%的冗余。存储容量也是如此模型集中最大的单层中间张量有多大下采样后需要多少SRAM。我在定义一款安防AI芯片时目标模型集是八成的轻量级检测模型加两成大模型分割模型。我统计了所有模型的最大单层激活值之后把片上SRAM从初版的16MB砍到了10MB芯片面积直接节省了约20%因为那些超大的单层激活值可以通过算子融合手段压缩不需要为极端情况预留太多资源。5.2 前端设计和仿真芯片还没流片软件已经在跑了芯片的前端设计阶段硬件描述语言如SystemVerilog代码在一点一点垒起来但软件团队不应该等到芯片回来才开始干活。成熟的团队会在仿真阶段就搭建指令级模拟器或Cycle-Level模拟器让编译器、算子库在虚拟的芯片硬件上跑通模型。这一点非常关键。芯片流片周期往往要半年到一年如果软件栈等到芯片回来后才开始适配整个产品的上市节奏就会被拖垮。我参与过的项目里硬件前端设计和软件栈开发是并行的硬件每完成一个子模块的验证就会同步更新模拟器软件团队基于模拟器开发编译器和算子库发现架构不合理的地方及时反馈给硬件在RTL层面做修改。这种软硬件同迭代的节奏能避免大量的返工。举一个具体的例子我们在初版模拟器上跑YOLOv5s时发现每次检测输出的非极大值抑制NMS后处理耗时极高占到了总时延的25%。排查发现NMS的循环逻辑依赖排序而排序操作在计算阵列里没有原生指令支持只能退化为多次比较和分支效率极低。软硬件联合评审后我们在硬件上增加了一条排序加速指令软件侧改用了并行化的NMS实现最终把后处理时间压到了总时延的8%以下。这个改进如果等芯片回来再做只能靠软件层硬顶不会有这么好的效果。5.3 流片返回后的Bring-up效率从跑通到跑好芯片流片回来之后进入Bring-up阶段也就是上电、加载固件、跑最小的裸机程序确认芯片能正常工作。这个阶段最容易出的问题是电源、时钟和内存控制器的稳定性但一旦芯片能稳定跑helo world级别的程序就要尽快把完整的软件栈灌进来开始跑真实的模型。Bring-up阶段有个心法先求跑通再求跑快。心态上要接受第一版性能和设计峰值差得远这个事实。由于建模精度的偏差、物理工艺参数的差异、时序收敛的问题实测性能经常只有模拟器预测的60%到80%。这时候回到性能分析工具一层一层地看是哪个环节的占比超出了预期然后针对性地调整算子实现或编译器调度。我遇到过一次某个卷积算子在模拟器上预测时延50微秒实际跑到82微秒分析之后发现是SRAM的bank冲突太严重访问分布不均匀导致有效带宽折损。解决方法是调整数据在SRAM中的排列布局把bank冲突率从70%压到15%最终时延回到了55微秒以内。5.4 量产前的最后一公里稳定性、温漂与生态适配从功能验证完到能够量产中间的打磨期往往比想象中漫长。硬件层面要跑高温、低温、电压漂移等极端压力测试确保芯片在用户的各种环境里都不会翻车软件层面则要把框架接入的工作做完让PyTorch、TensorFlow和主流推理引擎都能直接调用这块芯片的能力而不仅仅是内部团队用专属工具链。生态适配是我觉得国内AI芯片团队普遍做得不够好的地方。芯片做得再强如果用户要把模型迁移到你的芯片上需要改代码、调参数甚至重写算子很多用户就会直接掉头走了。所以Pytorch的扩展机制、ONNX的导入导出兼容、主流推理引擎的插件化接入都是必须在量产前就完成的硬任务。这块工作不性感甚至很琐碎但它决定了你的芯片在市场上的真实生命力。以我自己的经验一个AI芯片项目从立项到量产最顺也需要18个月。这个过程中硬件团队、软件团队、算法团队必须像同一个产品的三根支柱一样紧密协作。任何一根支柱偏了整个产品的节奏都会受影响。6. 给入局者的建议哪些坑我替你踩过了最后这一节我不画大饼不列十点忠告那么隆重就讲几个我自己在实战中体会最深、但很少在公开资料里看到的细节。第一做AI芯片软硬件协同设计的能力比单一硬件的峰值算力更重要。公司内部分配资源时如果软件团队预算被砍了三分之一那芯片实际性能可能打了对折都不止。所以如果你是技术决策者千万别把大部分资源砸在RTL开发和流片上编译器、算子库、运行时调度这一整条软件栈才是真正决定芯片能否兑现设计值的关键。第二关于架构设计的验证建议保留一个虚拟平台做持续回归。芯片流片前的模拟器不能只用来跑一两个benchmark就完事要把它变成CI流水线的一环每天自动跑一遍目标模型集的所有算子做性能回归和多版本对比。一旦某天性能指标突变了当天就能定位到是哪个改动引起的而不是一个月后才发现再翻代码日志追溯。第三如果团队刚起步规格定义阶段请多花时间做模型集约束分析。别试图做一枚什么都能跑的AI芯片那是GPU要做的事情。把目标模型集和精度要求写清楚架构设计的边界自然就清晰了后面每一步的日子都会好过很多。第四年轻工程师入行我强烈建议先花半年时间吃透一个开源AI编译器。读源码不是目的而是要通过源码理解计算图调度、内存分配、指令生成这条主线。我面过不少基础很不错的候选人算法和框架熟门熟路但问到一个算子被编译到底层指令时数据如何在流水线里流动这类问题时就暴露出对硬件执行模型的理解不够到位。而这恰恰是AI芯片软硬件协同设计最核心的底层能力。AI芯片这个领域表面上拼的是制程、算力、带宽这些硬指标骨子里拼的其实是把硬件和软件融成一套系统的工程能力。每一次性能突破背后都是无数次的权衡、回退和重来。希望这篇关于AI芯片软硬件设计的实战拆解能帮你把整个链条的脉络看得更清楚一些。后面我准备对编译器调度、量化映射、以及大模型在专用芯片上的推理优化分别再写几篇把每个环节的坑和玩法展开细讲感兴趣的话可以持续关注。