做AI芯片这几年，我最大的感受是：芯片本身只是硬件，真正决定性能上限的，是软件能不能把硬件每一份算力榨干。AI芯片的软硬件设计，听起来像是两个团队的分工协作，但实际撕过几轮方案、踩过几轮坑之后就会明白，这从来就是一个整体工程——从第一行架构文档开始，硬件和软件就必须绑在一起设计，否则"算力很强但跑不出性能"的尴尬局面，会在流片之后毫无保留地还给你。
这篇文章我按自己做项目的实际经历来写，不聊玄的，只讲从架构选型、数据流设计，到软件编译器、运行时，再到软硬件协同调试的完整链路。适合三类人看：刚入行想搭一套AI芯片评估体系的工程师，正在做芯片软件工具链的编译器开发，以及准备立项、需要评估"自研芯片还是买现成方案"的技术负责人。读完你至少能少走我两年弯路。
1. 为什么AI芯片不能靠"堆料"解决
1.1 "算力焦虑"背后的真瓶颈
很多团队立项时第一个问题就是："我要做多少TOPS的芯片？"这个数字当然重要，但它是最容易定的指标，也是最容易骗人的指标。我见过不少标称几十TOPS的芯片，实际跑一个大规模模型，连标称值的十分之一都跑不出来。原因很简单：芯片标的是理论峰值，而真实算力取决于数据能不能喂到计算单元里、算完的结果能不能及时搬出。
AI计算和传统计算最大的区别，是它极度依赖数据流动。一个卷积层，权重是几兆到几百兆的参数，输入特征图也有同样量级，计算本身不过是乘累加，但每个数据要被反复复用。如果存储层级设计不好，数据搬运的时间和能耗会远远超过计算本身。这背后有个著名的经验法则：一次DRAM访问的能耗，能顶几十次甚至上百次MAC运算。所以AI芯片的核心设计目标不是堆更多的MAC单元，而是让计算尽量待在片上，减少对外部存储的访问。
这也是为什么类似GPU那样的通用架构做AI训练是合适的选择，但到了推理场景、边缘场景，大家还是愿意专门做NPU、ASIC。因为专用架构可以把数据流组织得更合理，把存储和计算的物理距离拉近，用空间换时间。
1.2 硬件架构与软件栈的耦合关系
我说"软硬件设计是一个整体"，不是指那种"接口定义清楚、两边各自开发、最后联调"的协作模式，而是指：架构的每个关键决策，都必须同时回答"编译器能不能高效生成代码"和"运行时能不能充分调度"两个问题。举个最直观的例子：如果你的硬件设计了某种特殊的数据排布方式（比如为了提升存储带宽，要求特征图按通道交错存储），但编译器后端不支持自动插入重排操作，那么要么你派几个工程师手写汇编，要么这个设计就根本用不起来。
反过来说，软件也要为硬件设计"让路"。比如很多AI芯片为了省功耗，去掉了浮点运算单元，只支持定点量化。编译器就必须承担起精度管理责任，在算子级别做量化感知的图优化。硬件的一个"减法"，会变成软件的一堆"加法"。
我经常跟团队说的一句话是：不要把软硬件当成两台机器之间的协议，而是当成同一条流水线上两个工位。工位A的形状，直接决定了工位B的操作方式；工位B的操作方式，反过来又约束工位A的边界。谁先动、谁后动，错一步，后面全乱。
1.3 软硬件协同设计为什么这么难
协同设计难，难在三层原因。
第一层是知识割裂。硬件工程师习惯用RTL描述逻辑，关心时序、面积、功耗；软件工程师关心算子、图优化、内存分配。两边词汇都不一样，开会时容易各说各话。我见过最典型的场景：硬件说"我加了双缓冲，带宽利用率能到90%"，软件说"那你的片上内存小了，我模型放不下，得切碎"。两边都对，但没法合成一个决策。
第二层是时间错位。硬件设计和软件工具链开发周期不对齐。硬件要提前两三年定义架构，软件想等硬件定了再动手，结果就是芯片出来以后，工具链还没ready，只能靠手写优化库打补丁。正确的做法是软件在硬件定型前就基于架构模拟器开发，两边并行。
第三层是评估失真。没有真实的软件负载去跑架构探索，硬件的面积和功耗预算就是拍脑袋。但等你跑通了完整的应用负载，往往已经到了不能回头改架构的阶段。这个死结，只能靠分层抽象和周期级模拟器来解，后面我会详细讲。
2. 架构选型与关键权衡
2.1 主流的AI芯片架构全景对比
做AI芯片架构选型，市面上逃不过四种路线：通用GPU风格、张量核风格、脉动阵列风格、可重构数据流风格。我做一个粗线条的对比，帮助团队快速定位。
通用GPU风格的思路是大规模并行线程，用统一着色器做标量和向量运算，把AI运算映射成SIMT模式的并行任务。优点是通用性强，编译器生态成熟，但能效比天花板明显，因为调度开销、缓存一致性的开销很大。
张量核风格是给GPU/MAC再加一个专用的大矩阵运算单元，配合灵活的通用核做预处理和激活函数。这是目前云端AI芯片最流行的折中方案：计算密集部分用张量核吃满，其余杂活交给通用核。缺点是面积开销大，软件调度复杂度高。
脉动阵列和可重构数据流本质上是把数据流的组织方式固化到硬件里：脉动阵列让数据像滚珠一样在计算单元阵列里按节奏流动，复用率极高；可重构数据流则是用网络把计算单元连起来，数据按图拓扑流动。后者设计灵活、能效比最高，但编译器要把计算图映射成网络拓扑，难度非常大，工具链一旦不成熟，满盘皆输。
我这几年接触的团队，云端推理芯片大多走张量核路线，端侧小芯片走精简的类脉动阵列路线，真正走全可重构路线的项目，几乎都死在编译器上。选架构之前，请先掂量自己的软件团队，这个顺序不能反。
2.2 数据流、存储层次与算子映射
架构选完之后，接下来绕不开的词就是数据流（Dataflow）。它决定了计算过程中数据怎么流动、在哪里复用、什么时候存回。最经典的三种是：权重固定（Weight Stationary）、输入固定（Input Stationary）、输出固定（Output Stationary）。名字看着学术，本质上是"你愿意把哪份数据焊在计算单元附近不动"。
权重固定的思路适合权重反复复用、输入不断刷新的场景，比如卷积层的偏置层和全连接层；输入固定适合激励反复复用、权重不断刷新的场景，比如某些逐元素算子和池化层；输出固定适合输出累加次数多的场景。现实中芯片不会只支持一种数据流，而是支持几种模式，由编译器根据算子特性选择切换。
这个选择直接影响存储端口设计。固定某份数据，意味着给它开快速访问通道，也就是给计算阵列配一组紧耦合的寄存器文件或者小容量SRAM。数据流定下来之后，编译器才知道怎么排循环、怎么切分tile，才知道一个算子最少搬几次数据。没有数据流的架构，你就只能靠缓存去猜，猜准了算你运气好。
2.3 算力密度与能效比的折中
算力密度，通俗讲就是单位面积上能塞多少有效计算。这个指标比XX TOPS难追得多，因为提升算力就要加MAC阵列，加阵列就要加大片上互连，互连面积一膨胀，密度反而下降。所以架构师要在计算单元、存储、互连三者之间做零和博弈。
我做过的项目中，一个16x16的MAC阵列，如果每个MAC配一个独立的激活缓冲，整体面积会比阵列本身大好几倍。后来改成8列共享一组缓冲，面积省了40%，代价是编译器必须更精细地安排数据复用窗口。能效比同理——很多团队只看峰值TOPS/W，但这个数字通常是在某个很窄的shape下测出来的，真实负载一跑就露馅。
我的建议是：把能效比的标准定为"完整跑通代表模型后的系统能效"，不是单点峰值。因为AI芯片吃的是整个系统，除了计算阵列，存储、互联、控制逻辑都在耗电。软硬件设计要一起优化，才能让TOPS/W这个数字在指标表之外真正站得住脚。
3. 硬件侧核心模块设计要点
3.1 计算阵列：从乘累加单元到脉动阵列
计算阵列是AI芯片的心脏，核心单元就是乘累加（MAC）。一个MAC完成一行乘加运算，一组MAC做二维复用就形成阵列。架构设计的第一个决策是阵列的shape：正方形、长方形、还是带状。正方形有利于矩阵乘法，长方形有利于卷积切tile，带状则牺牲计算密度换取更高的数据复用率。
脉动阵列的精髓，是把"数据搬运"这个动作也变成流水线的一部分。每个MAC把结果直接传给下一个MAC，不需要反复走寄存器堆。这就像工厂里的传送带，零件一台一台传过去，每台机床只做一个小动作。好处是功耗低、面积小，坏处是只在规则运算下效率高，遇到不规则算子（比如稀疏结构）就抓瞎。
所以现代设计大多做混合结构：主计算单元用脉动阵列或者类脉动组织，旁边配套一套"尾巴"逻辑处理归一化、激活、池化这些杂活。我强烈建议在硬件定义阶段，就把"哪些算子在阵列上跑、哪些算子走旁路"写进架构文档，因为这会直接决定编译器后端的分派策略。
3.2 片上存储：容量、带宽与功耗的三角博弈
片上存储是AI芯片最贵的东西。SRAM面积大、功耗低、速度快，但容量做不大；DRAM容量大但速度慢、带宽受限于外部引脚。设计的目标是在有限的SRAM预算内，给计算阵列提供足够带宽。
一个常用的估算公式：假设卷积层的输入特征图是c×h×w，权重是c×k²，输出是n×h'×w'。单次输出tile需要搬运的输入数据大约等于输入tile尺寸加权重尺寸，你可以反推不同存储容量能支撑多少计算复用。凡是"算力高、带宽低"的配置，基本都是请客吃饭不上菜，计算单元饿肚子。
带宽匹配上有个实操指标叫字节/操作（Bytes/Op）。如果每个MAC操作需要1个字节的权重和1个字节的输入，那么1GHz频率下跑1T OPS的芯片，就需要至少2TB/s的片上带宽。很多团队在选SRAM组数和位宽时，就是靠这个比例倒推出来的：阵列频率、数据位宽、SRAM口数三者互相制约，缺一个就得牺牲另一个。
3.3 互联与同步：多核扩展时怎么不打架
单核的AI引擎设计得再漂亮，规模一大就得考虑多核扩展。多核互联最常见的就是总线、环形、Mesh网格。总线简单但带宽共享，适合核数少的场景；环形公平性好但延迟随节点数增加；Mesh带宽高但面积大，布线也麻烦。这块没有银弹，只有根据部署场景做取舍。
互联设计里最容易被忽略的是同步语义。AI计算的并行方式通常是SPMD，每个核拿一小块数据自己算，最后归并。如果硬件没有提供高效的同步原语（比如栅栏、原子操作、片上归约），软件就得用全局同步来做，一旦有核快有核慢，全部卡住，利用率直线往下掉。我在项目中吃过这个亏：当时觉得片上同步用软件做就行，结果性能调优时发现20%的时间耗在同步等待上，后来加了一条专用归约总线，整体推理延迟降了差不多三成。
所以多核设计的核心问题不是"怎么连起来"，而是"连起来之后，任务怎么切分、结果怎么汇聚、同步怎么高效"。这三个问题，必须跟软件调度器一起设计，而不是留给软件在后期硬扛。
4. 软件侧：编译器与运行时的真实战场
4.1 算子到底怎么落到硬件原语上
硬件设计得再复杂，软件看到的永远是有限的硬件原语（Primitives）：加载数据、启动矩阵计算、把结果存回、做激活/池化等。软件栈的核心工作，就是把一个深度模型的计算图，翻译成这些原语组成的序列，并且排得尽可能高效。
编译器前端先把模型转成中间表示（IR），做图级别的优化：算子融合、死代码消除、常量折叠。中端做数据布局转换，主要是把多维张量排布转换成硬件友好的存储格式。后端做指令调度和寄存器分配，生成最终机器码。
这里最关键的其实是算子融合。以卷积+批归一化+ReLU为例，三个算子如果分三次执行，中间结果要写回DRAM再读出来，一次白跑；如果把批归一化的系数折到卷积权重里，ReLU直接在卷积输出上执行，中间结果就留在片上寄存器里，直接省掉一组片外访问。这个优化在某些模型上能带来2-3倍的端到端加速，几乎是我见过的性价比最高的优化手段。
4.2 调度、数据搬运与流水线
当算子序列出来了，编译器面临的问题是：存储空间有限，算子之间如何重叠执行？这就引出了调度的核心——数据搬运隐藏。
AI芯片通常采用DMA（直接内存访问）做片外到片上的搬运，计算单元做运算。一个优秀的调度策略是三层流水：第一级DMA预取下一块输入数据，第二级计算当前块，第三级DMA把结果写回。三层同时进行，计算单元理论上可以一直不停。
要实现这个重叠，需要双缓冲甚至多缓冲：片上分配两块缓冲区，一块被计算单元读着算，另一块被DMA填着数据，算完换边。双缓冲看起来简单，但真正难的是循环切分——也就是tile。你的片上存储只有那么大，模型特征图切多大、权重分几块、沿哪个维度切，直接决定数据复用率。切错了，要么存储放不下，要么反复搬运，性能陡降。这块没有诀窍，就是靠编译器对硬件模型做建模，跑遍历搜索找到最优tile方案。
4.3 精度与量化的软件补偿
AI芯片为了能耗，常常只支持低精度定点数。我从实际测试中得到的结论是：感知量化（量化感知训练）配合部署阶段的定点推理，在大多数模型上能做到几乎无损。但前提是软件栈要做几件事：
第一，每个算子的量化敏感度不一样，不能一刀切。有些层对量化非常敏感（比如检测头的回归分支），需要保留更高精度。编译器应该支持混合精度标注。第二，激活值的动态范围每个批次都可能变，纯离线统计的量化参数容易失真。运行时要用滑动窗口修正量化scale，这也是许多芯片评测里"量化精度翻车"的常见原因。第三，低精度计算需要溢出保护，尤其是int8乘法累加到int32时很容易饱和，硬件上要有饱和截断，软件上要安排好累加顺序。
软件在这块的职责，表面上是在补硬件的"坑"，但本质上是在用算法智慧换取芯片的能效优势。没有一套成熟的量化工具链，再省电的硬设计也只能活在纸面上。
5. 软硬件协同设计流程（可落地的实操路径）
5.1 第一步：用Roofline模型把工作负载摸清楚
我在每个芯片项目启动后的第一件事，不是画架构框图，而是先收集目标工作负载。把要跑的模型（比如目标场景的推理模型集合）整理出来，统计每个算子的计算量、数据量、访存次数，然后画出一张Roofline图。
Roofline模型是一张二维图：横轴是运算强度（每字节数据对应的操作数），纵轴是可达性能。芯片的计算峰值和带宽峰值在图上形成两条线，两条线的交点是"拐点"。每个算子按自己的运算强度落在图上：落在斜率段说明它是访存密集型，加算力没用，得提带宽；落在水平段说明它是计算密集型，加MAC阵列才有意义。
这套方法之所以重要，是因为它把"软硬件怎么设计"变成了"让算子尽量往图上哪个区域移动"的问题。比如某模型的所有算子运算强度都很低，那么你设计芯片时最重要的任务就不是堆算力，而是把数据压缩、复用做得极致。Roofline分析应该贯穿整个设计周期，做架构探索时用于评估，软硬件联调时用于定位瓶颈，百试百灵。
5.2 第二步：架构探索与建模
在真正写RTL之前，要用性能模拟器做架构探索。我的习惯是先搭一个周期级模拟器，行为级建模到位：每个计算单元的时钟周期、DMA的带宽模型、存储的带宽和延迟、仲裁策略等等。软件团队的编译器可以直接对准这个模拟器做开发和调优。
模拟器的精度要把握好。太粗（比如只建模计算时间，不建模访存冲突），得出来的结论没法做决策；太细（全cycle级精确）又慢到跑不动真实模型。折中方案是"分层建模"：计算部分用固定周期表查表，访存部分用排队模型模拟竞争，整体精度控制在正负15%以内就够了。不要追求无谓的精确，因为你拿它做的是相对比较，不是算账。
架构探索的核心方法论是参数扫描：固定工作负载，把阵列大小、SRAM容量、带宽、互联拓扑分别往上下扫描，观察端到端延迟和能效的变化曲线。哪个维度拉满10%算力只涨1%，哪个维度加一点就有显著收益，一目了然。这一步，是整段软硬件设计的"决策大脑"，后期所有重大取舍都能追溯到这里的模拟数据。
5.3 第三步：软件bring-up与性能调优闭环
芯片流片回来后，真正的战争才刚开始。Bring-up阶段先跑两个东西：硬件自测程序（BIST）确认逻辑没问题，然后马上把完整的工具链套件跑一个最小可用的模型，验证编译-加载-执行-取回的完整通路。这个阶段的问题通常出在硬件寄存器的时序细节和编译器生成代码的假设不一致：编译器以为某个指令会等DMA完成，但硬件实际上不会发中断。这种问题，需要软硬件两边人坐到一起，关闭所有优化一层层剥。
性能调优是软硬件协同设计的闭环。线上真实模型跑一遍，用profiler抓各模块的占用率、访存带宽、气泡时间，对照Roofline分析定位短板。常见的结果是"计算阵列利用率只有30%，DMA空闲率却很高"，说明数据供给跟不上，需要调tile策略；或者是"计算满载，但额外开销占了大半"，说明调度重叠没做好。调优是个反复过程：改调度参数，跑基准测试，看profiler，再改。
我坦白讲，这个调优闭环不可能一步到位。第一版工具链总是先求"能跑"，再求"跑得快"，最后才求"跑得稳"。每轮迭代都会发现新瓶颈，然后你会发现，很多瓶颈其实在架构定义阶段就已经埋下了——这正是软硬件协同设计的意义：把本应在联调期爆发的矛盾和冲突，尽量提前消耗在设计期。
6. 踩坑实录与排查经验
6.1 存储带宽翻车的三种典型场景
我自己的项目里，带宽问题排在所有问题数量的第一位。第一种典型翻车是"权重反复读取"。模型权重很大，但片上SRAM装不下，只能做权重分块。如果编译器没有做好权重复用，一个tile算完就重新加载同块权重，DMA带宽直接爆掉。排查方法很简单：让profiler统计每个权重块的加载次数，如果是贴近tile数量而非1，说明复用没做好。
第二种是"碎片化搬运"。DMA一次搬运的数据块太小，每次传输的握手开销占比太高。把profile数据拉出来看，有效数据占传输量的比例只要低于60%，就要考虑调整tile形状，让DMA能搬运更连续的大块。
第三种是"写回延迟叠加"。每个算子都可能产生中间结果，如果不做片上融合就写回DRAM，带宽在输出方向上被吃光。遇到这种场景，优先检查算子融合是否失效，比如某个激活算子没有融合进上一个卷积，白白多了一次往返。这类问题不需要改硬件，改软件收益最大。
6.2 编译器"生成垃圾代码"的排查思路
编译器生成的代码性能差，是软件团队最常背的锅。但实际排查下来，七成问题的根本不在于代码生成逻辑，而在于硬件行为与软件假设不匹配。每次拿到低性能数据，我会按这个顺序排查：
先查数据布局。编译器假设的张量排布是不是硬件最友好的？如果不是，可能在某个环节被插入了重排指令，这种指令非常贵。再查tile参数。编译器选择的tile大小，是不是受限于片上容量导致复用率低？可以在模拟器里直接改tile参数做对照实验。然后查同步开销。算子之间有太多强制等待，说明依赖分析没做好，需要加软件流水和异步执行。最后才怀疑代码生成器本身的bug——这种情况反而是最少的。
这个排查顺序执行下来，你会发现大部分"垃圾代码"其实是"硬件协议和编译器默认假设的错位"。修一个硬件文档注释、改一处寄存器配置，往往比优化遍历代码更有效。
6.3 工具链必备清单与上手建议
给准备入坑软硬件协同设计的朋友一份工具链清单，都是我自己用下来离不开的东西：一款开源深度学习框架（用于产生前端的计算图和onnx导出）、一套支持自定义算子注册的前端优化库、一个周期级性能模拟器（软件开发和硬件评估共用）、一个波形级仿真环境（用于RTL验证）、一套性能profiler（能输出算子级、指令级、访存级的统计）。
上手建议就三条。第一，不要在还没有模拟器的时候就急着写RTL，哪怕模拟器很粗糙，也比拍脑袋强。第二，第一版软件只要做到"能跑通端到端模型"就算成功，千万不要在第一版就追求极致性能，否则会在还没建立完整通路的时候陷入局部优化出不来的泥潭。第三，所有性能优化的结论，都要写成可回归的测试用例。今天调好的方案，明天改了一行编译器的代码就可能崩掉，没有回归测试兜底，你寸步难行。
我个人在这些项目里最深的一个体会是：AI芯片的软硬件设计，本质上是一个"熵减"工程。硬件把规则的算力固化下来，软件把不规则的模型削足适履地映射上去，两边互相较劲又互相成就。真正顺利的项目，往往不是某一边特别强，而是两边都愿意为对方改自己的设计——硬件为编译器多留一个原语，软件为硬件多写一个优化pass。这种默契不是靠流程文档逼出来的，而是靠一起加班de掉一个又一个性能瓶颈磨出来的。如果非要给后来者一句建议，那就是：尽早让软硬件工程师用同一套模拟器、同一份负载、同一张Roofline图开会，比什么都管用。
