1. 从HotChips现场聊起为什么数据流架构突然成了AI芯片的顶流话题今年HotChips的议程一出来我朋友圈里做芯片架构的几位老哥就炸了锅。往年大家关注的都是又堆了多少TOPS、用了什么先进封装、HBM又迭代到几代但今年明显不一样——数据流架构Dataflow Architecture相关的议题占了相当大的比重从初创公司到巨头都在讲自己怎么把数据流的思想揉进下一代AI加速器里。我前后翻了几十页的公开资料和厂商演讲摘要越看越觉得这事值得好好聊一聊因为它触及了一个根本问题当摩尔定律放缓、功耗墙越来越硬的时候AI芯片到底该怎么设计才能继续把算力往上推先说清楚这篇文章要解决什么问题。如果你是对AI芯片架构感兴趣的技术从业者、正在选型推理硬件的工程师、或者单纯想搞明白“数据流架构”到底是个啥的读者那这篇内容就是写给你的。我会从HotChips上几个有代表性的案例切入把数据流架构的核心逻辑、它跟传统冯诺依曼架构的本质区别、实际落地时的关键设计取舍以及我个人在评估这类芯片时踩过的坑全部掰开揉碎讲一遍。不堆术语不抄PPT尽量用从业者之间聊天的口吻把这事说透。先给一个最直观的类比。传统的CPU/GPU架构像是一个大食堂所有人排队去窗口打饭厨师计算单元和取餐口寄存器/缓存之间来回跑大部分时间花在走路上了。数据流架构则像是把厨房直接搬到你桌上菜数据到了就开做做完直接端走中间没有来回跑腿的浪费。这个类比不完全精确但能帮你快速抓住核心数据流架构的本质是让计算跟着数据走而不是让数据追着指令跑。HotChips上好几家公司的演讲都在强调同一个趋势AI负载尤其是Transformer类模型其计算模式高度规则且可预测这恰好是数据流架构最擅长的场景。传统GPU虽然通用性强但在处理这类负载时指令调度、寄存器读写、缓存一致性这些开销吃掉了大量功耗和面积。数据流架构通过把计算单元按特定模式互联让数据在阵列中流动时自然完成计算省掉了大量控制开销。这就是为什么今年大家都在往这个方向靠。2. 数据流架构到底解决了什么问题从冯诺依曼瓶颈说起2.1 传统架构的功耗都花在哪了要理解数据流架构的价值得先看清楚传统架构的痛点。我拿一个典型的GPU推理场景来算笔账跑一个BERT-base的推理batch size设为1序列长度128。在V100上实测下来端到端延迟大概在几毫秒量级但如果你用功耗分析工具去拆解会发现真正用于矩阵乘加运算的功耗占比可能只有30%到40%。剩下的60%到70%去哪了指令取指、译码、寄存器堆读写、共享内存访问、线程调度、缓存tag比对——全是“管理性开销”。这个比例在模型规模变大、计算密度变高的时候会更夸张。我见过一份对某款主流推理芯片的功耗拆解报告在跑ResNet-50时MAC阵列的功耗占比不到25%而片上网络和缓存子系统的功耗加起来超过了40%。这意味着什么意味着你花大价钱买的算力大部分被“搬运工”吃掉了。注意这里说的功耗占比是动态功耗的拆解不包含静态漏电。不同工艺节点、不同电压频率下这个比例会有浮动但量级上不会有根本性变化。2.2 数据流架构的核心思想让数据自己找到该去的地方数据流架构的解法很直接既然控制开销大那就把控制逻辑砍到最少。具体怎么做把计算单元按照某种规则拓扑连成阵列每个单元只负责一小块固定的计算任务数据从输入端流入经过一系列单元处理后从输出端流出。每个单元什么时候该干活不靠中央指令发射器告诉它而是靠“数据到了没”这个信号来触发。这就像工厂流水线每个工位只做一件事零件到了就加工加工完推到下一个工位。不需要工长拿着大喇叭喊“张三你现在该拧螺丝了”流水线本身的物理结构就决定了工序顺序。数据流架构的硬件实现也是这个道理——用硬连线的数据通路替代了指令发射逻辑用局部握手信号替代了全局时钟同步。HotChips上有一家做边缘推理芯片的公司展示了一组对比数据同样的7nm工艺、同样的MAC阵列规模数据流架构的能效比TOPS/W比他们的上一代SIMD架构高了3.2倍。这个提升不是靠堆料堆出来的而是靠把控制开销砍掉之后省下来的功耗预算全部让给了计算单元。2.3 为什么是现在AI负载的“可预测性”红利数据流架构不是新概念学术界从上世纪七八十年代就在研究了。为什么直到最近几年才真正在商业芯片上大规模落地核心原因是AI负载特别是深度学习推理负载具有极高的可预测性。传统通用计算负载比如操作系统调度、数据库查询、Web服务的控制流极其复杂分支预测失败率动辄百分之几十数据依赖关系动态变化这种场景下数据流架构的硬连线优势发挥不出来反而因为缺乏灵活性而吃亏。但AI推理不一样一个训练好的模型其计算图是固定的每一层的算子类型、张量形状、数据依赖关系在编译期就完全确定了。这意味着你可以针对这个计算图做极致的静态调度把数据流动路径在硬件上固化下来。我个人的判断是数据流架构在AI推理领域的黄金窗口期至少还有三到五年。训练场景因为需要支持动态图、梯度计算、参数更新等复杂操作数据流架构的适用性还有限但推理场景的确定性足够高数据流架构的优势可以充分发挥。3. HotChips上的三个典型架构案例拆解3.1 案例一粗粒度可重构阵列今年HotChips上有一类设计思路是粗粒度可重构阵列CGRA。它的基本单元不是单个MAC而是一个个小型的处理单元PE每个PE内部有自己的ALU、寄存器和局部存储。PE之间通过可配置的互联网络连接编译时根据模型的计算图决定PE之间的连接方式和每个PE执行的操作。这种设计的优势在于灵活性比纯硬连线数据流高可以支持多种不同的算子组合。代价是PE内部的控制逻辑比纯数据流单元复杂能效比会打一些折扣。我看到的实测数据是CGRA方案的能效比大概在纯数据流方案的60%到70%之间但支持的算子种类多了将近一倍。实操心得评估CGRA方案时不要只看它宣称支持多少种算子要问清楚“支持”的定义是什么。有些方案所谓的支持是通过多次配置切换实现的切换开销可能高达几百个时钟周期在实际推理中如果频繁切换性能会大打折扣。3.2 案例二脉动阵列的进化版脉动阵列Systolic Array是数据流思想最经典的实现TPU就是靠这个打天下的。今年HotChips上好几家公司在讲脉动阵列的进化版本核心改进方向有两个一是支持稀疏计算二是支持更灵活的数据流方向。传统脉动阵列的一个硬伤是只能处理稠密矩阵乘遇到稀疏矩阵比如剪枝后的模型效率会急剧下降因为零值也会占用计算周期。今年的几个方案通过在每个PE里加入零值跳过逻辑让稀疏矩阵的计算周期跟非零元素数量成正比而不是跟矩阵维度成正比。实测下来在50%稀疏度下有效算力能提升1.8到2.2倍。另一个改进方向是数据流方向的可配置性。传统脉动阵列的数据流向是固定的比如权重从左边进、激活从上面进但不同算子的最优数据流方向不一样。今年的方案允许在编译时配置数据流方向让卷积、矩阵乘、转置等不同算子都能跑在最优的数据流模式下。3.3 案例三片上网络驱动的多核数据流第三个案例思路是把数据流思想从单核扩展到多核。芯片上有几十个甚至上百个小核每个核是一个独立的数据流处理单元核间通过片上网络NoC通信。编译时把计算图切分成多个子图分配到不同核上核间通过NoC传递中间结果。这种架构的挑战在于NoC的带宽和延迟。如果子图切分得不好核间通信量太大NoC就会成为瓶颈整体性能反而不如单核。我看到的几个方案都在NoC上下了大功夫有的用多层NoC分离控制流和数据流有的用动态路由避免拥塞有的干脆把NoC的拓扑结构做成可配置的。从实测数据看这种多核数据流架构在跑大模型时优势明显因为大模型的计算图天然可以切分成很多并行子图。但在跑小模型时核间通信开销占比太高效率反而不如单核方案。4. 数据流架构芯片的实操评估要点4.1 算力指标怎么看才不被忽悠评估AI芯片时TOPS每秒万亿次操作是最常被拿来宣传的指标但也是最容易注水的。我见过太多芯片标称算力几百TOPS实际跑模型时利用率不到20%。对于数据流架构芯片有几个比TOPS更值得关注的指标。第一个是有效算力利用率。问厂商要一个具体模型比如ResNet-50或BERT-base的端到端吞吐和延迟数据然后自己算一下模型的总计算量FLOPs除以实测延迟再除以标称峰值算力得到的百分比就是有效利用率。数据流架构芯片在跑匹配的模型时这个数字应该能到60%以上如果低于40%要么是模型不匹配要么是架构有硬伤。第二个是能效比的实际值。不要看峰值能效比要看跑目标模型时的实际功耗。有些芯片在跑小模型时功耗很低一跑大模型功耗就飙上去了因为数据流阵列的利用率上不去但时钟频率和电压还得维持在高位。第三个是编译器的成熟度。数据流架构芯片的性能高度依赖编译器能否把计算图高效映射到硬件阵列上。我个人的经验是评估阶段一定要让厂商现场跑一个你自己提供的模型不要只看他们准备好的demo。如果编译器对某个算子的支持不好性能可能直接掉一个数量级。4.2 内存带宽数据流架构的隐形天花板数据流架构解决了计算单元的控制开销问题但没有解决内存带宽问题。实际上因为计算单元的效率提高了内存带宽反而更容易成为瓶颈。我算过一笔账一个峰值算力256TOPS的芯片如果跑的是INT8精度的矩阵乘每个MAC操作需要读取两个操作数权重和激活假设权重可以缓存在片上激活需要从DRAM读取那么每秒钟需要从DRAM读取的数据量是256T/2 128T个激活值也就是128TB/s的带宽需求。这个数字远超当前HBM的带宽上限。所以实际的数据流架构芯片都会在片上做大量的数据复用。常见的手段包括权重 stationary权重固定在PE里激活流过、输出 stationary部分和留在PE里权重和激活流过、行 stationary一行权重固定激活流过。不同的stationary策略适合不同的算子形状编译器需要根据具体模型选择最优策略。提示评估芯片时一定要问清楚片上SRAM的容量和带宽。对于大模型推理片上SRAM容量直接决定了能缓存多少权重带宽决定了数据复用效率。我见过一些芯片标称算力很高但片上SRAM只有几MB跑大模型时权重频繁换入换出实际性能惨不忍睹。4.3 编程模型别被“一键部署”忽悠了数据流架构芯片的编程模型跟GPU完全不同。GPU上你可以用CUDA写kernel灵活控制每个线程的行为数据流架构芯片通常需要你把模型转成特定的中间表示IR然后由编译器做映射和调度。这个转换过程的质量直接决定了最终性能。我试过好几款数据流架构芯片的编译器体验差异非常大。好的编译器能自动做算子融合、数据布局优化、双缓冲流水线你只需要把ONNX模型丢进去就能得到不错的性能。差的编译器需要你手动指定每个算子的数据流方向、每个PE的配置调优工作量巨大。评估编译器时我建议重点看三个能力一是对动态shape的支持很多实际场景输入尺寸不固定如果编译器只支持静态shape用起来会很痛苦二是对自定义算子的支持如果你的模型里有非标准算子编译器能不能通过某种方式比如手写微码支持三是调试工具链性能不达预期时能不能定位到是哪个算子、哪个PE成了瓶颈。5. 常见问题与排查技巧实录5.1 性能不达预期时的排查思路实际部署数据流架构芯片时最常见的问题就是“跑出来的性能只有标称的零头”。我总结了一套排查流程按顺序走下来基本能定位到问题所在。第一步确认模型是否在芯片的支持列表里。有些芯片对某些算子比如LayerNorm、Softmax有硬件加速对另一些算子只能回退到通用计算单元性能差距可能有几十倍。先看编译器的算子支持矩阵确认你的模型里没有“性能杀手”算子。第二步检查数据布局是否匹配。数据流架构芯片通常对输入数据的排布方式有特定要求比如NHWC vs NCHW如果布局不匹配编译器会插入额外的转置操作这些操作可能吃掉大量带宽和计算周期。第三步看片上内存是否够用。如果模型的一层权重超过了片上SRAM容量编译器就不得不把权重放在DRAM里每次计算都要从DRAM读权重带宽瓶颈立刻出现。解决办法要么是量化压缩权重要么是切分模型分多次加载。第四步检查是否开启了双缓冲。数据流架构芯片通常需要双缓冲来隐藏数据加载延迟如果编译器没有自动开启或者你手动关掉了性能可能直接减半。5.2 精度问题的排查数据流架构芯片为了追求能效比通常会在计算单元里做定点化处理。INT8是标配有些芯片甚至支持INT4。但量化会带来精度损失如果模型对精度敏感量化后准确率可能掉得厉害。我遇到过的精度问题主要有两类一是激活值的动态范围太大INT8表示不下导致截断误差累积二是权重和激活的量化scale不匹配导致乘法结果溢出或下溢。解决办法通常是做量化感知训练QAT在训练阶段就模拟量化误差让模型自己去适应。如果模型已经训练好了不方便重训可以尝试逐层量化校准找到每层的最优scale。注意不是所有模型都适合INT8量化。我实测下来CNN类模型量化后精度损失通常在1%以内但Transformer类模型特别是注意力层的softmax输出对量化非常敏感可能需要保留FP16精度或者用更精细的量化方案。5.3 多卡互联的坑数据流架构芯片在多卡场景下的表现跟GPU很不一样。GPU有NVLink这样的高带宽互联多卡通信开销相对可控。数据流架构芯片的卡间互联通常走PCIe带宽低一个数量级而且通信模式需要编译器做特殊处理。我试过用四张数据流加速卡跑一个大模型理论算力是单卡的四倍但实测下来只有2.3倍左右。瓶颈就在卡间通信上模型切分后每张卡算完一部分需要把中间结果传给下一张卡PCIe的带宽和延迟成了瓶颈。后来调整了切分策略让每张卡尽量独立完成一个完整的子图减少卡间通信次数性能才提升到3.1倍。这个经验告诉我数据流架构芯片的多卡扩展性高度依赖模型切分策略。如果模型本身并行度高比如MoE架构多卡效率会好很多如果模型是串行结构多卡反而可能因为通信开销而变慢。6. 数据流架构芯片的选型建议与个人体会6.1 什么场景适合上数据流架构根据我这段时间的观察和实测数据流架构芯片在以下几类场景里优势最明显。第一类是固定模型的批量推理。比如推荐系统里的embedding计算、搜索排序模型、内容审核模型这些模型结构稳定、更新频率低、推理请求量大数据流架构可以把能效比拉到极致。第二类是边缘端的低功耗推理。数据流架构因为没有复杂的指令调度逻辑芯片面积和功耗可以做得很小适合放在摄像头、传感器、移动设备里做本地推理。第三类是需要确定性延迟的场景。数据流架构的执行时间在编译期就基本确定了没有GPU上那种因为线程调度、缓存miss导致的延迟抖动适合对延迟稳定性要求高的场景。反过来如果你的模型需要频繁更新、支持动态shape、或者包含大量控制流比如条件分支、循环那数据流架构可能不是最优选择GPU或CPU可能更合适。6.2 选型时的几个硬指标我整理了一个选型对照表把评估数据流架构芯片时需要重点关注的指标和对应的验证方法列出来供参考。评估维度关键指标验证方法合格线参考有效算力目标模型实测吞吐现场跑自己的模型标称算力的50%以上能效比目标模型实测功耗功耗计实测比同代GPU高2倍以上片上内存SRAM容量和带宽查datasheet实测能缓存最大单层权重编译器算子支持率、动态shape现场编译自己的模型支持模型全部算子多卡扩展4卡加速比实测4卡vs单卡3倍以上精度量化后精度损失跑验证集对比损失小于1%这个表里的合格线是我个人经验值不同场景下可以放宽或收紧。比如边缘场景对能效比要求更高对多卡扩展没要求云端场景对多卡扩展要求高能效比可以适当放宽。6.3 我踩过的几个坑最后分享几个我在评估和使用数据流架构芯片时踩过的坑希望能帮你省点时间。第一个坑是过度相信标称算力。我曾经选了一款标称算力很高的芯片结果实际跑模型时发现它的算力是按稀疏模式算的稠密模式下算力直接砍半。后来学乖了一定要问清楚标称算力是在什么条件下测的。第二个坑是忽略编译器的学习曲线。数据流架构芯片的编译器通常比GPU的CUDA工具链年轻很多文档不全、bug不少、社区支持弱。我花了将近两周才搞明白怎么把自定义算子映射到硬件上如果项目时间紧这个学习成本一定要提前算进去。第三个坑是低估了模型转换的工作量。从PyTorch模型到数据流芯片能执行的二进制中间要经过ONNX导出、图优化、量化校准、算子映射、布局转换等多个步骤每一步都可能出问题。我建议在正式项目开始前先拿一个简单模型比如MobileNet走一遍完整流程把工具链的坑都踩一遍。第四个坑是没考虑散热。数据流架构芯片的能效比虽然高但算力密度也高单位面积的发热量可能比GPU还大。我有个项目用了被动散热跑满载时芯片温度直接冲到105度触发降频性能掉了30%。后来换了主动散热才解决。6.4 后续可以关注的方向从HotChips今年的趋势看数据流架构芯片接下来几个值得关注的方向一是动态可重构让芯片在运行时根据模型的不同阶段切换数据流配置兼顾灵活性和效率二是存内计算把计算单元直接嵌入SRAM或新型存储器里进一步消除数据搬运开销三是光互联用光信号替代电信号做片间和片内通信突破带宽瓶颈。我个人最看好存内计算和数据流架构的结合。数据流架构已经把控制开销砍得差不多了剩下的主要开销就是数据在存储和计算单元之间的搬运。如果能把计算嵌入存储阵列这部分开销也能省掉能效比还能再上一个台阶。不过存内计算目前还面临工艺成熟度、良率、设计工具链等多方面的挑战大规模商用可能还需要几年时间。眼下如果你要选型AI推理硬件数据流架构芯片值得认真考虑但一定要带着自己的模型去实测不要只看PPT上的数字。芯片这个领域纸面参数和实际表现之间的差距可能比你想的大得多。