1. 写在前面HotChips为什么值得关注做AI芯片有个绕不开的会就是每年八月的HotChips。我入行这几年每年雷打不动跟完整个流程先刷提前放出来的论文PDF再根据现场偷拍的PPT脑补细节最后等官方录像出来重新看一遍。为什么这么执着因为HotChips和ISSCC、ISCA不一样它是一个非常实的芯片发布现场。学术圈讨论的是理论上限HotChips讲的是已经流片、已经在跑负载的硅片到底怎么设计的。今年这届看下来最高频的词还是数据流架构Dataflow Architecture。可以说从Google提出TPU的脉动阵列方案以来数据流已经成了AI芯片设计的一条主干道几乎每家大厂和中型创业公司的新片子都会往这个方向上靠。但问题是真正理解数据流的人没想象中那么多。很多人把任何不是GPU的AI加速器都叫数据流也有人误以为数据流就是去掉缓存、全用寄存器堆这其实都是对架构本质的误读。这篇文章我就顺着HotChips里看到的几类典型设计把数据流架构芯片的来龙去脉拆开聊一聊。不讲虚的不讲数学公式就讲清楚它到底解决了什么问题、不同流派的实现思路、以及你在看这类芯片时需要盯住哪些关键指标。适合正在做芯片评估、AI基础设施选型或者准备在毕设/部门项目中引入加速器的人。如果你只是好奇为什么GPU都堆到几千TOPS了大家还要折腾新架构这篇文章也能给你一个清楚的答案。2. 传统架构卡在哪为什么大家都在谈数据流2.1 算力堆料的边际在递减过去十年AI芯片的主旋律很简单堆MAC单元。GPU从Volta到HopperAI加速器单芯片算力从几百TOPS飙到上千TOPS看起来应接不暇。但如果你真的跑过大规模模型推理会发现问题不在算力本身而在数据根本喂不过来。一个很简单的算术题假设某AI加速器标称500TOPS按INT8算这意味着它每秒需要做5x10^14次乘加运算。每次乘加至少要读两个操作数、写回一个结果哪怕操作数复用率做到极高也需要每秒TB级别的片上带宽才能满足需求。而目前最先进的片上SRAM访问带宽受制于物理布局和功耗很难无限制增长。于是芯片内部出现了一个经典瓶颈计算单元在等数据ALU空转能效直线下降。这就是为什么HotChips上大家反复讲数据搬运开销data movement cost。在成熟工艺下一次32位浮点运算消耗的能量约0.9pJ而从DRAM读取同等数据要消耗约20倍以上的能量。这里还不算延迟差异。所以算力堆到一定程度后再往上加MAC不过是让一匹饿马拉着更重的车——计算能力越强喂不饱数据的问题越严重。2.2 数据流架构到底解决什么问题数据流架构的核心思路一句话总结让数据走向计算而不是让计算去抓取数据。传统CPU/GPU是控制流架构指令一条条取出来ALU被安排着干活。数据存放在寄存器或缓存里需要时由指令去访问。而数据流架构把计算任务表示成一张有向图节点是运算边是数据依赖关系。数据一旦准备好就从上游节点流向下游节点节点被数据激活后执行运算。没有中央指令来指挥现在该做什么执行节奏由数据本身的就绪状态决定。这样的好处有两层。第一层省掉了指令取指instruction fetch、译码decode、乱序调度out-of-order scheduling这套复杂的控制逻辑和流水线开销。这部分在传统架构上占的面积和功耗不是小数目。第二层节点间的数据传递路径是静态编译期就定好的芯片可以针对固定通道做高带宽布线数据在片上移动的路径可以极短、极规整从而大幅降低数据搬运能耗和延迟。打个生活化比方。控制流架构像中央厨房统一配送每个灶台要做菜先举手申请仓库配货再按菜单逐一派送调度室忙得不可开交。数据流架构则像一条流水线食材在传送带上自动流动每个工作台看到原料齐了就开工不需要等中央指令。节奏自然、路径固定、几乎没有等待时间。2.3 数据流和智能计算不是一回事这里必须澄清一个常见的混淆。有些人拿数据流架构和模拟人脑存算一体混为一谈这其实是三条不同路线。存算一体的核心是把权重或激活值放在存储单元附近甚至存储单元内部做计算重点解决存储墙问题——它关心的是数据在哪儿算数据流架构关心的是数据怎么流动、计算节点怎么组织和激活而类脑计算则更关注脉冲事件驱动和低精度突触可塑性。三者可以叠乘在一起用比如你可以在数据流芯片上用近存计算单元做节点运算但它们的抽象层级和目标各不相同。在HotChips上你也能看到这个趋势纯靠单一创新已经不够了各家都在组合拳。有人用脉动阵列做数据流有人在脉动阵列上叠了近存缓存还有人把稀疏跳过的逻辑直接做进PE内部。但不管怎么组合它的调度内核都避不开那张数据流图。3. 数据流芯片的主流技术流派与HotChips风向细看今年HotChips的报告被称为数据流架构的设计大致能分成三类我逐个讲。3.1 空间架构与脉动阵列最成熟的流派空间架构spatial architecture是最容易被理解的一种数据流。芯片由大量简单处理单元PE布成一个二维阵列数据沿着相邻PE逐级传递每个PE只需要和邻居通信不存在复杂的全局广播网络。这类设计的代表就是Google TPU系列中的脉动阵列systolic array。脉动阵列的精髓在于每个时钟节拍数据沿着固定方向移动一格计算在数据经过时顺手完成。一个2D的脉动阵列里权重预先驻留在各个PE中输入数据从左侧逐列流入部分和从下方逐行流出。每个PE执行一次乘加操作只和相邻PE交换数据片上通信距离被压到极致。我自己看TPU和一系列国产加速器的论文时有一个感受脉动阵列的设计陷阱不在阵列本身而在阵列边缘的进出口带宽。如果输入数据进入阵列的速度跟不上脉动节拍阵列中间就会断流。所以HotChips上凡是采用脉动阵列的芯片都特别强调片上SRAM预算和片外高带宽内存HBM。另一个陷阱是适配性。脉动阵列对卷基层效率极高但对结构不规则的自定义算子就很别扭。像动态shape的attention算子、条件分支较多的小模型映射到脉动阵列后利用率可能只有两三成。所以现在很多芯片在脉动阵列之外还要再加一层灵活的可编程模块我把它叫双模策略。3.2 粗粒度可重构数据流灵活性的更高追求脉动阵列的路子胜在规整、高效但输在灵活性。另一类厂商在尝试把数据流图直接映射到硬件上而不是把所有模型都强行压成脉动阵列。这类芯片叫粗粒度可重构架构CGRA或粗粒度数据流架构。代表性思路来自SambaNova、Wave Computing现在已不复当年等公司学术源头可以追溯到几十年前的CGRG研究。这类芯片内部包含大量可配置的功能单元每个功能单元可以做向量运算、矩阵运算、数据搬运和地址生成等操作。芯片上还有高带宽互联网络可以在编译期就把算子之间的数据通道铺好让一个模型的执行路径变成一张物理上连通的网络。换句话说脉动阵列是一张固定的阵列所有模型都往上面映射粗粒度可重构是芯片本身就是一张可编程的布线板每个模型都能生成自己的专属布线图。后者的理论利用率天花板更高对不规则模型也友好但代价是编译器难度直线上升。编译不到位的模型在同类芯片上会呈现灾难级性能表现。我在HotChips上看到这类芯片的实测数据时第一反应是去看它跑了哪些模型如果只跑ResNet、只跑CNN那数据流优势非常明显如果还跑了NLP、跑了稀疏模型、跑了一些动态shape模型那才是真本事。这里面的猫腻你们在评估时也务必注意。3.3 晶圆级集成与多芯片互联数据流的物理扩展数据流架构对带宽的胃口极大。单片硅片的片上SRAM和HBM接口终究有限于是有一种很极致的方向做晶圆级芯片把所有计算和存储一次封装在一整片12英寸晶圆里。最典型的就是Cerebras它的晶圆级引擎WSE里塞了几十万个内核片内互联带宽是以拍字节每秒PB/s来计算的。从HotChips的视角看Cerebras传递的信息是数据流架构和晶圆级封装是天然搭配。为什么因为数据流图本身就是分层的、有空间局部性的。如果我把一个计算图映射到晶圆的不同区域各个区域之间的数据流可以通过多层金属走线完成延迟极低、带宽极高。而如果是多芯片互联方案芯片之间的数据要经过封装基板、交换机带宽和能耗都差了一个量级。但晶圆级设计也有它的麻烦良率和大面积工艺不均。一家公司如果能搞定晶圆级的良率问题等于给数据流架构提供了最肥沃的土壤。我个人认为这是未来五年的关键赛点之一但假如你的团队没有那么大的投入还是可以靠chiplet思路获得部分收益——把计算die和存储die分开在封装内用硅桥或die-to-die高速接口做数据流连接。3.4 这些技术路径的共同逻辑不管是脉动阵列、CGRA还是晶圆级它们共同的底层逻辑是把数据流图中的边物化成物理上的专用通道。静态编译期分析出数据的生产者和消费者然后让它们在物理层面对齐减少不必要的广播、缓存和仲裁。这需要芯片设计团队同时拥有编译器技术和硬件架构能力。在HotChips台上做报告的大多不是纯硬件团队他们的叙事往往从软件栈开始比如算子图如何拆解、调度如何生成然后才讲到硅片的物理结构。这个信号值得注意数据流架构的战点已经从怎么做一块芯片转移到了怎么把一张计算图标定到芯片上并跑满。没有编译器团队的数据流芯片就像没有方向盘的超跑马力和客户之间的体验完全断裂。4. 评估数据流芯片时我最先看的6个指标每届HotChips看完后我都会用一套固定的指标体系去衡量新发布的数据流芯片。这里分享给同行重点是解释为什么看这些因为很多人的评估方法停留在只看峰值算力的阶段那基本等于看汽车只看厂商标称的最大速度。4.1 微架构PE到底能干什么第一项看PE的指令集和运算宽度。有些芯片的PE只能做乘加另外要做非线性激活必须跑到另一个专门的单元里去这就会导致逻辑跳转开销。而有些PE看起来复杂实际上支持向量化、查表和轻量控制流灵活性明显更高。在HotChips上我会从PPT里抠出下列问题PE有没有独立寄存器文件可不可以做非数值操作如地址生成、Mask处理两个PE之间能不能直接通信绕过全局缓存4.2 互联与数据搬运系统平衡度数据流芯片的血管是片上网络NoC。单纯堆PE但互联拓扑不合理是最常见的翻车点。我关注的是PE内部的邻居带宽是多少、跨域通信的延迟是否一致、有没有提供组播或单播通道。通常芯片资料不会直接给全连接结构图但你可以从批量处理单元之间的流量推断出大概的互联层级。经验上二维网格结构的延迟均匀度好但平均跳数高环形结构局部性能好但容易出现热点树状结构则对广播友好但对随机流量不友好。4.3 编译器与运行时这是数据流芯片的命门。评估时一定要具体到它支持哪些深度学习框架算子在原生框架中能被直接捕获还是需要手动改写如果我写了自定义算子会通过什么路径接入编译器数据流图做静态调度还是动态调度如果模型中途出现开关分支芯片是直接用硬件处理还是退回软件同步这些都是影响实际性能的隐藏成本。我见过太多人第一次拿数据流芯片跑模型性能比GPU还差就骂芯片不行。其实不是芯片不行是编译器和框架适配没打通——模型体积小的时候数据流的优势发挥不出来反而因为序列化启动开销跑了更久。4.4 精度与数值策略不同芯片对精度支持的策略差异巨大。有些只做INT8和FP16有些则在FP32上也有不错表现还有些主打高动态范围格式如BF16/自定义浮点。我建议不要只看支持的精度列表要看它在混合精度场景下的路径是怎样的。具体来说在同一个算子内部遇到高动态范围中间量时芯片是直接使用高精度单元还是紧急转发到CPU这两种路径节省的周期是完全不同的。4.5 稀疏性支持真支持还是假支持数据流的底层是数据移动驱动理论上对稀疏数据非常友好。因为如果数据为零或不重要就不需要触发数据流动。但实际芯片对稀疏的利用程度差别很大有的支持结构化稀疏剪枝有的只能跳过固定比例的四元素组有的则只能在激活值上做稀疏跳过。评估时要看芯片是否能动态跳过无效计算而不是静态地把权重置零。如果它只能权重稀疏遇到动态稀疏的激活值就没辙如果它连激活值也能跳过那在生成式模型和稀疏场景下的收益会非常显著。4.6 生态与上手的隐形门槛数据流芯片离真正的工程落地还差一个舒服的程度。上手时的编译时间、调试能力、性能剖析工具在很多HotChips的大报告里都被一笔带过。但实际操作的人知道一次编译都要跑几小时、出现问题连性能计数器的信息都不全这个痛感一点都不低于算力不足。我在评估芯片时一定会拿一个实际业务的小模型从头到尾做完能否一键编译、编译输出是否包含性能指导、调试时能否看到节点内部状态这些决定了它能否从一个专利样片变成能嵌入生产流水线的工具。5. 数据流芯片落地中的常见坑与工程心得5.1 峰值算力论文数字和实际利用率的落差数据流芯片厂商都喜欢在HotChips PPT里放两张图第一张是芯片的RAW TOPS第二张是某个经典模型上的标杆性能。但经典模型静态图全调优的环境到真实场景往往水土不服。原因在于真实AI负载充满不确定性输入长尾分布、动态batch、稀疏度变化、还有多请求并发。数据流芯片是静态编译派它会把一个模型固定成一份硬件调度方案。当输入动态变化超过调度的假设范围时要么降级到较保守路径要么反复重编译。我在实际测试某款数据流芯片时发现同一模型在固定shape下的延迟是1.2毫秒但一旦输入长度变化延迟会涨到3-5毫秒且抖动极大。行业里喜欢说dataflow is great until you hit a branch这个教训我经历过好几次。5.2 编译器优化不只是能跑打个比方GPU的编译器像C语言编译器写了就能跑跑得好不好主要靠程序员水平数据流的编译器更像FPGA的综合工具能不能跑、跑多快完全取决于工具对资源映射的智能程度。这份编译器的心智负担用户未必感受到但团队一定承受了。我遇到过最夸张的情况是只是改了一个模型输出stride的参数编译器重新做布局布线花了几小时最后性能和上次完全一样。所以选择数据流芯片时一定要预留编译离线优化的时间预算。比如每轮迭代如果编译时间超过15分钟整个团队对模型探索的频率就会大幅下降最终影响业务试错速度。5.3 调试与可观测性芯片内部的暗箱数据流芯片里没有PC、没有传统意义上的寄存器现场出了问题极难定位。在一次对接支持时我试过把模型调快了2.3倍后开始出现偶发错误结果但芯片自带的输出校验根本没报告错误。最后排查下来是某个PE在特定数值条件下发生了饱和而芯片默认不检测这类数据异常。从那以后我给自己定了一个规矩凡是做数据流芯片的测试必须先在CPU上生成一份参照输出再用芯片的结果逐层对齐。一开始就要布好观测点不能依赖芯片自带的一切正常结论。5.4 我的几条实操建议基于踩过的坑给准备做数据流芯片评估或替换的团队几条建议。第一一定从高频真实模型开始基准测试不要用标准模型库。可以用自己业务中形态最稳定的三个模型固定输入范围和batch后连跑一周观察平均延迟、P99延迟、重编译频率和功耗曲线。第二在立项时就把编译器团队当作硬件的一部分。如果团队里没有编译器方向的人尽量选择软件栈成熟度高的商用方案而不是试图在选型后自研编译器。第三关注多模型并存场景。数据流芯片通常对单模型大计算图友好但如果你要在一张卡上同时跑5个不同的在线推理模型它的调度策略可能完全不是数据流最擅长的模式而更像虚拟机隔离场景。6. 从HotChips看到的风向与我自己的一点体会数据流架构在AI芯片领域走到今天已经不是要不用的问题而是怎么用得更彻底的问题。从TPU的脉动阵列到CGRA的高灵活性方案再到晶圆级的大规模数据流引擎未来的AI芯片设计会越来越像把硅片变成一张可编程的数据运动场。HotChips也让我有一个明显的感受过去大家比拼的是单个算子的乘法效率现在比拼的是完整图执行的流水线效率。这背后要求芯片设计者懂模型、懂编译器、懂系统。毕竟一旦芯片流片回来你没有办法改硅片上的PE阵列所有后招都得靠软件栈和系统创新去弥补。我个人在折腾数据流架构过程中的体会是这个架构对思考矢量即模型设计的规律性有天然的依赖。你的模型越规整、算子越固定、shape越稳定数据流芯片能带给你的收益就越大。反过来如果你的模型还在频繁试错、结构天天变、动态条件特别多那采用数据流芯片很可能得不偿失。不要被热火朝天的架构潮流裹挟着走先把你自己的负载特征弄明白再去对照架构的特性这才是选型最朴素的逻辑。最后再分享一个小技巧看HotChips的报告时不要只看演讲者给的性能对比表去找那些不起眼的细节——比如一张die photo里缓存所占的面积比例、一个系统架构图里PCIe端点数量、一句说we support dynamic shape的轻描淡写。这些细节往往才是决定一个数据流芯片能不能在你真实业务中活下来的关键。