我第一次接触 AI 芯片的软硬件设计是在一个模拟项目里。当时团队拿到的任务是评估一种新的计算架构能不能跑主流视觉模型。我看完规格书的第一反应是——这算力数字标得这么高为什么不直接用现成的硬件方案直到跟着走完一遍软件栈适配才明白 AI 芯片远不是“堆算力”那么简单。它真正的门槛藏在硬件架构和软件编译器之间那条狭窄的协同缝隙里。这篇文章我想从一个工程师视角把 AI 芯片软硬件设计的核心逻辑、关键取舍和常见坑位讲清楚。它适合三类人想进入芯片领域的应用开发者正在做模型部署的算法工程师还有需要评估硬件方案的团队。你不一定要会画电路甚至不需要懂 Verilog但理解这些设计决策能让你在选型、移植和性能调优时少走很多弯路。1. 通用 CPU 为何在 AI 任务上力不从心——那个绕不开的瓶颈1.1 瓶颈的本质是数据搬运不是计算本身AI 芯片的诞生根源在于传统通用计算架构和 AI 计算模式之间存在不可调和的矛盾。拿一个标准的卷积层来说动辄百万甚至上亿次乘加运算。如果放在经典处理器架构里逐条指令执行光是把数据从内存搬到寄存器就会消耗大量时钟周期。真正执行乘加运算的时间反而很短大量的时间都花在了“等数据”上。我用一个具体数字说明。假设输入是一张 224×224×64 的特征图卷积核尺寸是 3×3×64×128那么这一层理论上需要的乘加次数大约是 3×3×64×128×224×224差不多 7.7 亿次。传统处理器即便跑在 2GHz单核单周期完成一次乘加处理完这一层也要接近 0.4 秒。如果再算上数据搬运产生的访存延迟时间可能直接恶化到一两秒。而一个像样的模型有几百层这样的延迟显然不可接受。这就是“内存墙”和“计算墙”同时压上来的典型场景。1.2 从 CPU 到 GPU 再到专用 AI 芯片架构取舍的变化CPU 擅长的场景是控制逻辑复杂、数据依赖强的任务它把大量芯片面积花在分支预测、乱序执行、大容量缓存等部件上。这些部件对 AI 计算来说利用率不高——矩阵乘法和卷积本质上是高度规则的计算不需要那么复杂的分支控制。GPU 通过大量并行核心隐藏了部分访存延迟在矩阵乘法这类规则计算上表现不错。但它仍然受制于片外存储带宽和通用指令的调度开销在很多 AI 工作负载上的能效比并不理想。AI 芯片的设计出发点完全不同把计算单元做得更专、更简把片上存储做得更大再把数据流调度做到“每一次数据搬运都服务于有效计算”。一句话概括就是算得专、搬得少、存得近。这句话听起来简单但真要在芯片上落地牵扯到大量硬件微架构选择和软件栈适配工作。这也是“软硬件协同设计”这个概念如此重要的根本原因。2. 硬件侧的核心设计算力、存储与数据流的三重博弈2.1 计算单元选型SIMD 向量核心还是脉动阵列AI 芯片内部的计算单元主流方案大体分成两类一类是接近 GPU 风格的 SIMD 向量核心另一类是专用程度更高的脉动阵列。这个选择直接决定了后面软件编译器怎么写、算子库怎么优化。脉动阵列是研究文献里出现频率很高的设计把大量乘加单元排列成二维阵列数据像波浪一样在阵列中流动每个单元只和相邻单元通信。它的优势是极大减少寄存器堆和互联线复杂度非常适合卷积和矩阵乘法这类规则计算。比如一个 64×64 的阵列理想情况下单个周期就能完成 4096 次乘加。但脉动阵列也有弱点如果数据喂不上阵列会大量空转。所以设计的关键往往不在阵列本身而在周围的数据供给逻辑。SIMD 向量核心则更接近程序员熟悉的模型每个核心处理数据的一个局部编译器负责把算子映射成向量指令。它的好处是通用性强、调度灵活坏处是对缓存和取数逻辑的要求更高否则同样会陷入“算力等数据”的尴尬。两类方案没有绝对优劣选择依据主要看目标场景中算子种类的多少和灵活性要求。2.2 存储架构片上存储每多一层性能就上一个台阶AI 计算有一个被反复强调的特点数据复用率极高。一个 3×3 的卷积核会在整张特征图上滑动同一个权重会被反复使用成千上万次。如果能把权重放到离计算单元最近的片上存储里就能省掉海量的片外访存。正是这个原因几乎每一颗 AI 芯片都会配置可观的片上 SRAM并且会尽量把中间结果留在片上而不是每层计算结束都写回 DRAM。片上 SRAM 的容量和带宽在某种程度上比峰值算力更能决定真实性能。举个例子某颗芯片标称峰值算力 128 TOPS但如果片外带宽只有 256GB/s那么遇到逐点操作这类计算密度很低的算子时数据吞吐会立刻卡在带宽上实际吞吐可能只有峰值的 20% 左右。这也是很多芯片厂商标称数据和客户实测数据差距悬殊的重要原因。片外内存则普遍采用 HBM 或 LPDDR。HBM 带宽高、功耗也相对高多用于数据中心和自动驾驶场景LPDDR 更省电多用于边缘设备。选什么片外内存本质上取决于目标场景对带宽和功耗的需求边界。2.3 数据流设计谁在片上静止谁在阵列里流动数据流是 AI 芯片架构里最容易被人忽略、却又极其影响性能的设计点。大致可以分成三类权重固定、输入固定和输出固定。权重固定数据流指的是权重预先驻留在片上输入特征图在阵列中流动。这种模式对权重复用高的层比较友好比如全连接层。输入固定数据流则相反输入特征图停下来权重广播给所有计算单元适合某些特殊的算子形状。输出固定数据流把中间部分和固定在片上累加减少反复读写中间结果的次数对卷积层的计算密度提升很有效。多数成熟芯片不会只支持一种数据流而是让编译器针对每一层选择较优的模式。这里就出现了一个硬件和软件的接口问题如果硬件支持多种数据流编译器就要有能力为不同的算子自动选择合适的数据流。这个能力做得好不好直接影响芯片在多样模型上的表现。3. 软件侧的关键设计从算子库到编译器把每一层榨干3.1 软件栈的分层结构各层在解决什么问题一颗 AI 芯片的软件栈通常由前端框架适配层、图优化层、算子层、编译器和运行时驱动组成。大多数人对软件栈的理解停留在“把模型导入然后生成底层指令”这一步但实际上图优化层和算子层对最终性能的贡献往往比底层指令生成更大。以算子融合为例。卷积层后面如果跟着批量归一化和激活函数传统执行方式是把每个算子的输出写回内存下一个算子再读出来。融合成一个算子后中间结果可以一直留在片上寄存器里不需要经过片外内存。我测过一个典型模型光做算子融合访存量就能减少 30% 到 50%。这几乎是所有优化手段里投入产出比最高的一招。3.2 量化与精度校准软硬件配合最紧密的界面为降低带宽压力和功耗AI 芯片普遍支持 INT8、INT4 甚至更低的量化推理。量化并不是简单地把 FP32 模型转成整数它背后是一整套校准逻辑。软件栈需要统计模型各层激活值的分布为每个张量选择合适的缩放系数再决定哪些层必须保留高精度。量化有两条经验线可以分享。第一很多模型从 FP32 降到 INT8精度损失能控制在 0.5% 以内前提是校准数据集有代表性。第二如果模型存在长尾分布或者某些对数值极度敏感的层直接一刀切量化会导致精度崩掉。这时候常见的做法是逐层分析敏感度把个别层保留为 FP16 混合精度。这部分工作做没做到位客户不会看文档但会在模型上线后的精度报表里肉眼可见。3.3 调度与编译把计算图映射到有限的片上资源编译器要解决的核心问题是把计算图形式描述的网络映射到实际的计算单元和存储空间上并为每条指令分配合理的时间片。这本质上是资源受限的调度问题需要考虑数据依赖、片上内存上限、片外带宽上限等多个约束。一个很常见的场景是“切块”。某个中间层的特征图特别大片上 SRAM 放不下整张图编译器就必须把它切成若干小块分批次计算。分块尺寸选多大直接影响片上内存利用率和数据搬运次数。切太大放不下切太小搬运开销过高这是一道典型的优化题。成熟的软件栈会内置性能模型在编译阶段快速估算不同切块配置下的耗时而不是每次都在真机上盲试。4. 软硬件协同设计从“各做各的”到迭代闭环4.1 为什么软硬件必须一起设计如果沿用传统思路硬件团队先把芯片做出来软件团队再接入适配在 AI 芯片领域基本行不通。原因很简单硬件一旦流片指令集、内存架构、数据流模式就全部锁死软件优化空间被物理边界框死反过来如果软件团队等到芯片回来才开始写编译器整个项目周期会拉长到不可接受。所以现在通行的做法是在芯片架构定义阶段就让软件团队介入。先根据目标模型场景确定算子集再用性能模型和模拟器做软件评估最后等芯片回来做真机调优。这个过程听起来像流程优化实际上是需要大量技术投入的协同工作——性能模型写不写得准模拟器能不能反映真实硬件行为都决定迭代效率。4.2 一个决策实例片上内存多大才够用片上 SRAM 的容量是我觉得最具性价比讨论价值的设计决策。每多增加 1MB 片上内存都会带来面积和功耗的增加但太少的话编译器被迫做更多切块性能会断崖式下降。某个模拟项目中我们用性能模型针对目标网络集做了扫描从 8MB 提升到 16MB端到端时延下降了约 40%从 16MB 再提高到 32MB效果只有约 3%。这个结果让团队很快锁定了 16MB 作为“甜蜜点”。这样的评估如果不做软硬件协同基本只能靠拍脑袋。4.3 性能模型与模拟器花钱买不到的一致性性能模型写得好不好决定了软硬件协同的精度。我见过不少团队一上来就写高精度周期级模拟器结果进度一拖再拖。比较务实的做法是分两级初期用快速性能模型做粗粒度评估筛选架构选项到方案收敛后再用周期级模拟器精调关键路径。这样既能保证早期迭代速度又能在后期获得足够准确的性能预期。5. 实战复盘评估 AI 芯片软硬件方案时我的一套核查清单5.1 不再只看 TOPS这些指标更接近真实体验评估一颗 AI 芯片如果只看标称算力和能效比很容易被纸面数据迷惑。我的习惯是把评估维度拆成六项分别打权重看综合结论。维度关注点经验复盘峰值算力理论最大吞吐仅供参考芯片几乎跑不到可持续算力真实模型稳定吞吐决定性指标直接看实测内存带宽对访存密集算子的支撑能力和模型特征结合不能只看规格端到端延迟单次推理总耗时时延敏感场景的命门精度保持率量化后的精度退化程度直接决定模型能不能上线软件栈成熟度从框架导入到部署的顺畅程度决定开发周期和工作量这里面最容易被低估的是最后一项。一个硬件再强、编译器开发不完善的芯片带给用户的痛苦远大于快乐反过来一个硬件中规中矩但软件栈成熟度高的方案往往能在实际项目中更快落地。5.2 现场实测的注意点选对模型锁定环境实测时选用的代表性模型和数据集决定了评估结果的参考价值。我见过有团队用小模型测试一颗芯片结果性能很好看换到大模型后因为内存容量不足或算子利用率下降表现判若两芯。此外功耗墙和温升问题也不容忽视——长时间满载运行可能触发降频导致性能逐步走低。做压力测试时至少要连续跑几十分钟看稳态性能而不是瞬时峰值。6. 一线踩坑记录与几个被低估的设计细节6.1 踩坑实录一看似轻量的逐点操作反而成了性能黑洞有次部署一个图像分类模型卷积层的耗时占比并不高反倒是几个逐点激活函数占掉了将近一半的推理时间。我一开始很困惑激活函数计算量这么小怎么会这么慢排查之后才发现这些逐点操作被定义了独立的计算边界中间结果需要写回片外内存再从片外读回来继续下一步访存开销完全掩盖了计算本身的轻量。解决方式是把逐点操作融合到上一层卷积的输出阶段让数据在片上完成流转。这个改动让端到端时延直接下降了约 30%。这个案例给我的教训是软硬件优化不能只看计算量必须同时关注数据在哪里周转。6.2 踩坑实录二编译器“聪明”到自作主张量化精度崩了另一个印象深刻的排查经历出现在量化后的模型精度回退问题上。某个模型里有两个分支结构计算逻辑完全一致但后续处理不同。编译器在图优化阶段把这两个分支误判为等价做了合并结果因为后续操作对数值分布的需求不同造成精度明显下降。当时第一次在真机上测精度比原始模型低接近 2%排查了半天最终定位到是编译器的错误合并。拆分分支并重新逐层校准后精度才恢复正常。这件事提醒我图优化不是越激进出越好。编译器的优化决策必须建立在对模型语义的准确理解之上否则一次“优化”可能变成一次“事故”。6.3 几个看似不起眼、实则决定成败的细节除了上面两类典型问题还有几个细节容易被忽略电源与散热设计。AI 芯片功耗波动幅度大如果电源设计和散热能力不足芯片会在高负载下偷偷降频性能表现出现瀑布式下滑。驱动与框架版本的一致性。不同版本的算子库行为存在差异部署环境必须锁版本号否则回归测试的结果没有可比性。性能计数器和调试探针。芯片内部的 debug 探针和性能计数器极其重要很多问题就是靠这些探针在真实运行中定位的。设计时在这个部分省钱后期排查会付出成倍代价。6.4 最后分享一个我个人的习惯我现在评估任何一套 AI 芯片软硬件方案都会先花半天时间把它的软件栈文档通读一遍然后用一个中等规模的模型跑端到端测试。如果软件文档逻辑清晰、示例代码能直接跑通这台芯片的潜力往往比纸面算力更高反之如果软件栈文档写得很模糊基本可以预期后面每一步都会遇到阻力。这也许是 AI 芯片项目里最被低估的软实力——软件生态的成熟度有时候比硬件参数更能决定项目能不能按时交付。