1. 从 HotChips 现场回来我重新理解了数据流架构刚从今年的 HotChips 回来脑子里全是各种架构图在打架。如果你也是做芯片或者 AI 系统方向的应该知道这个会在圈子里的分量——它不像那些商业发布会讲 PPT 画大饼而是各家把硅片拿出来、把微架构图摊开、把实测数据摆上桌的地方。今年最让我坐不住的不是某家又堆了多少 TOPS而是数据流架构Dataflow Architecture在 AI 芯片里从“学术论文里的漂亮概念”变成了“工程上真能跑起来的东西”。这篇文章我想聊的就是我从 HotChips 上看到的、以及结合我自己这几年在 AI 加速器上踩过的坑对下一代 AI 芯片架构的一些思考。核心关键词就几个HotChips、AI 芯片、数据流架构、芯片架构。我会讲清楚数据流架构到底解决了什么问题、它和传统冯诺依曼架构的本质区别在哪、工程落地时哪些细节会要命、以及如果你要评估或设计这类芯片该从哪些维度下手。适合做芯片架构、AI 系统软件、算子优化、以及想搞清楚“为什么 AI 芯片不能简单堆 MAC”的读者。先给一个最直观的类比。传统架构像一家公司里所有员工都听一个中央调度员指挥调度员喊“张三去取数据、李四去算加法、王五把结果写回仓库”每个人干完一步都要等调度员下一道指令。数据流架构则像一条流水线车间每个工位只关心“我的输入到了没、到了我就干活、干完把结果推给下一个工位”没有中央调度员在中间来回喊话。这个区别听起来简单但在 AI 计算这种“数据量大、计算模式规整、但访存极其昂贵”的场景里它直接决定了你能效和实际性能的天花板。2. 数据流架构到底在解决什么问题2.1 冯诺依曼瓶颈在 AI 负载下被放大到什么程度要理解数据流架构为什么在 AI 芯片里重新火起来得先看清楚传统架构在 AI 负载下到底卡在哪。经典冯诺依曼架构的核心特征是“指令流驱动”程序计数器指向一条指令取指、译码、取操作数、执行、写回一条接一条。为了提升吞吐我们加了流水线、加了多发射、加了乱序执行、加了大缓存。这些手段在通用计算里非常有效因为通用程序的局部性还行分支预测能兜住大部分不确定性。但 AI 负载不一样。以矩阵乘加为例一个 512x512 的矩阵乘计算本身是高度规整的但数据搬运量巨大。假设每个 MAC 需要两个操作数传统架构里每个操作数都要经过寄存器文件、可能还要经过多级缓存指令发射本身也要消耗能量。有研究数据表明在 7nm 工艺下一次 32 位浮点乘加运算的能量大约是 0.2 pJ 量级而从 DRAM 取一个 32 位数据的能量是它的几百倍。也就是说计算本身不贵把数据搬来搬去才贵。冯诺依曼架构的指令驱动模式恰恰在“搬数据”这件事上效率极低——因为每条指令都要显式地指定操作数来源和去向指令带宽和寄存器文件带宽成了瓶颈。我在实际做算子优化时感受特别深。同一个卷积算子在 GPU 上跑理论算力利用率能到 70% 就算不错了剩下 30% 全耗在指令发射、寄存器 bank 冲突、以及等待内存返回上。这不是 GPU 设计得不好而是指令流驱动模式在规整计算下的固有开销。数据流架构的思路就是既然计算模式这么规整为什么还要每条操作都发指令让数据自己流动数据到了计算单元就自动触发计算算完自动流向下一级指令开销可以降到极低。2.2 数据流架构的核心思想让数据驱动计算数据流架构的核心思想可以用一句话概括计算的触发条件是操作数就绪而不是程序计数器指向某条指令。在数据流模型里程序被表示为一个数据流图Dataflow Graph节点是计算操作边是数据依赖。一个节点只有在它的所有输入边都“有令牌token”时才会触发执行执行完把结果令牌放到输出边上。没有全局时钟步调一致地推指令每个节点异步地、数据驱动地工作。这个模型在 AI 里天然契合因为神经网络的计算图本身就是数据流图。卷积、矩阵乘、激活函数、归一化这些算子之间的依赖关系是静态的、可分析的。你可以在编译阶段就把整个计算图映射到硬件的数据流架构上让数据在片上网络NoC里流动经过一个个计算单元最后流出结果。指令只在最外层做粗粒度配置细粒度全靠数据令牌驱动。HotChips 上我看到的一个趋势是很多做 AI 推理的芯片都在往这个方向靠。有的是完全的数据流架构有的是混合架构——粗粒度用指令控制细粒度用数据流触发。但核心逻辑是一致的减少指令开销让数据搬运和计算重叠起来把能效做上去。2.3 从粗粒度到细粒度数据流架构的几种形态数据流架构不是一个单一的东西它有一个谱系。最粗粒度的是“粗粒度可重构架构”CGRA计算单元是 ALU 阵列配置信息决定每个 ALU 的功能和连接关系配置一次可以跑很多周期。中等粒度的是“数据流加速器”比如把卷积的滑窗操作做成硬件数据流数据从行缓存流入乘加树结果流入累加器。最细粒度的是“动态数据流”每个操作数到达都触发一次计算硬件里用标记tag匹配来配对操作数。我在评估不同形态时主要看三个维度灵活性、能效、编译复杂度。粗粒度 CGRA 灵活但编译难细粒度动态数据流能效高但硬件开销大要维护标记匹配逻辑中等粒度数据流在 AI 场景里往往是甜点区。HotChips 上有个做边缘推理的芯片用的就是中等粒度数据流卷积层直接映射成硬件流水线激活和池化用可配置单元处理实测能效比同代 GPU 高一个数量级。当然它的代价是只擅长卷积类负载遇到 Transformer 那种注意力机制就需要重新配置甚至部分回退到指令控制。3. 数据流架构芯片的关键技术点拆解3.1 片上网络数据流架构的“高速公路”怎么修数据流架构里片上网络NoC的重要性怎么强调都不过分。在指令驱动架构里数据搬运靠 load/store 指令路径是确定的在数据流架构里数据在计算单元之间流动NoC 的拓扑、路由策略、带宽分配直接决定了整个芯片的吞吐和能效。我见过一些设计计算单元本身做得很好但 NoC 成了瓶颈数据在路由节点上排队计算单元反而饿着。HotChips 上几个做得好的数据流芯片NoC 设计都有共同特点。第一拓扑和计算图匹配。如果计算图是层叠的卷积结构NoC 就做成多层总线或者二维网格让数据从上一层流到下一层时路径最短。第二路由策略简单。动态路由虽然灵活但每个路由节点都要做仲裁面积和功耗都上去了。很多设计用静态路由或者时分复用编译时就把路径定好硬件只做简单的转发。第三带宽分层。计算单元之间的局部通信用高带宽短路径跨区域的通信用较窄的总线避免全局 NoC 做得太宽导致面积爆炸。我自己在做一个数据流加速器原型时NoC 这块踩过的坑是一开始想用全连接交叉开关觉得灵活结果综合出来面积是计算单元的 3 倍功耗也压不住。后来改成二维网格加静态路由面积降到 1/5性能只损失了不到 10%。这个经验让我明白数据流架构的 NoC 设计简单和匹配比灵活更重要。3.2 计算单元的粒度选择MAC 阵列还是可配置算子计算单元的粒度是另一个关键决策。最细的是单个 MAC最粗的是整个卷积层做成一个固定功能单元。粒度越细灵活性越高但指令/配置开销越大粒度越粗能效越高但只能跑特定算子。HotChips 上我看到的一个趋势是“可配置算子粒度”计算单元不是单个 MAC也不是整个卷积层而是一个可以配置成不同形状的乘加阵列。比如一个 16x16 的 MAC 阵列可以配置成 16 个 1x16 的向量乘也可以配置成 4 个 4x4 的矩阵乘还可以配置成 1 个 16x16 的矩阵乘。配置信息在编译时生成运行时只加载一次。这种设计的妙处在于它用有限的配置位宽覆盖了 AI 里最常见的几种计算模式全连接、卷积、矩阵乘。我在实际项目里对比过固定功能的卷积单元能效最高但遇到全连接层就要空转可配置阵列能效略低但利用率高整体下来反而更划算。选择粒度的经验法则是统计你目标负载里各算子的计算量占比如果前三个算子占了 80% 以上就为它们做可配置阵列如果负载很杂就退回更细的粒度。3.3 存储层次数据流架构里缓存该怎么放数据流架构里存储层次的设计和指令驱动架构很不一样。指令驱动架构里缓存是为了掩盖访存延迟因为指令流是顺序的预取和缓存命中能大幅提升效率。数据流架构里数据流动是显式的缓存的角色更像是“数据暂存和重排”。比如卷积的滑窗操作行缓存line buffer是必须的因为要重复使用相邻行的数据。矩阵乘的 tiling需要在片上暂存一块 A 和一块 B算完再换下一块。HotChips 上有个设计让我印象深刻它把存储分成了三级——寄存器级、暂存级、全局缓冲级。寄存器级在计算单元内部存当前周期的操作数暂存级是计算单元之间的共享缓冲存一个 tile 的数据全局缓冲级是片上的 SRAM存整个层的输入输出。数据从全局缓冲流入暂存再流入寄存器计算完逆方向流回。这个层次的关键是容量和带宽的匹配暂存级太小数据来不及重用就流走了太大面积和功耗上去了。我自己的经验是暂存级容量应该至少能放下一个完整 tile 的输入和输出这样计算单元不用频繁等待全局缓冲。3.4 编译器和映射数据流架构的“隐形战场”数据流架构芯片能不能用好一半看硬件一半看编译器。硬件提供了数据流的能力但怎么把计算图映射到硬件上、怎么调度数据流动、怎么分配存储全是编译器的事。HotChips 上很多公司讲芯片时花在编译器上的时间比硬件还多这不是没有道理的。数据流编译器的核心任务包括算子融合、tiling 切分、数据流调度、存储分配。算子融合是把多个算子合并成一个数据流图减少中间结果的写回。tiling 是把大矩阵切成小块适配片上存储。数据流调度是决定每个计算单元什么时候执行、数据什么时候流动。存储分配是给每个中间结果分配片上缓冲。这些任务互相耦合一个变了其他都要跟着变所以编译器往往要用到整数规划或者启发式搜索。我在实际项目里最深的一个体会是数据流架构的编译器不能只做“翻译”要做“协同设计”。什么意思就是编译器的输出要能反馈给硬件设计。比如编译器发现某个算子的数据重用率很高但硬件暂存不够那就应该加暂存如果发现某个数据流路径总是拥堵那就应该加宽那条路径。HotChips 上有个团队分享说他们的芯片迭代了三版每一版都是编译器团队和硬件团队一起调最后能效比第一版提升了 4 倍。这个数字很能说明问题。4. 实操视角评估和设计数据流架构芯片的完整流程4.1 第一步负载分析搞清楚你要跑什么任何架构设计都要从负载分析开始数据流架构尤其如此。因为数据流架构的优势在于“匹配计算模式”如果你连计算模式都没搞清楚设计出来的硬件就是瞎猜。负载分析要回答几个问题目标模型有哪些算子、各算子的计算量和访存量占比、算子之间的依赖关系、batch size 和序列长度的分布。我一般会拿几个代表性模型跑一遍 profiling把每个算子的耗时、访存、算力利用率都列出来。比如 ResNet-50 里卷积占了 90% 以上的计算量那数据流架构就应该重点优化卷积。BERT 里矩阵乘和注意力机制占大头那就要考虑矩阵乘阵列和 softmax 的硬件支持。如果是多模型混合负载就要看能不能找到一个公共的计算模式或者做成可重构的。这里有个容易忽略的点访存量比计算量更重要。有些算子计算量不大但访存特别频繁比如 depthwise 卷积。这种算子在数据流架构里反而要特别设计因为它的数据重用率低如果存储层次没做好能效会被访存拖垮。我在负载分析时会专门算一个“算术强度”计算量/访存量算术强度低的算子要重点看存储设计。4.2 第二步架构选型数据流还是混合负载分析完之后就要决定架构选型。纯数据流架构适合计算模式非常规整、算子种类少的场景比如专用推理芯片。混合架构适合算子种类多、需要一定灵活性的场景比如同时支持 CNN 和 Transformer 的芯片。HotChips 上我看到的一个趋势是纯数据流架构在边缘推理里越来越多混合架构在数据中心里更常见。原因很简单边缘场景对能效要求极致愿意为特定负载做专用硬件数据中心场景负载多变需要保留指令控制的灵活性。选型时我会用一个简单的决策矩阵如果前三个算子的计算量占比超过 80%且算子内部数据重用率高就选数据流如果算子种类超过 10 种且计算模式差异大就选混合架构数据流处理规整部分指令控制处理不规则部分。这个矩阵不是绝对的但能帮你快速缩小范围。4.3 第三步参数计算算力、带宽、存储怎么配架构选型定了之后就要算具体参数。这一步最容易被拍脑袋决定但拍脑袋的后果往往是芯片回来发现瓶颈在没想到的地方。我一般会从目标性能反推先定峰值算力再算需要的带宽再算片上存储容量。举个例子。假设你要跑一个 1080p 的实时目标检测模型帧率 30fps模型计算量是 10 GOPS/帧。那峰值算力至少是 10 GOPS × 30 300 GOPS。但实际算力利用率不可能 100%数据流架构乐观估计 60%那硬件峰值算力要做到 500 GOPS。然后算带宽假设每 GOPS 需要 0.1 GB 的访存那 300 GOPS 需要 30 GB/s 的带宽。片上存储假设最大的 tile 是 256x256 的 feature map16 位精度那就是 128 KB加上权重和中间结果片上 SRAM 至少 512 KB。这些数字算出来之后再和工艺、面积、功耗预算对一下看能不能实现。如果实现不了就回去调架构或者调目标。注意算力、带宽、存储这三个参数是互相制约的。算力做高了带宽跟不上就是浪费带宽做高了存储不够数据就要反复进出片外功耗就上去了。我见过一个设计算力堆到 100 TOPS但片上存储只有 1 MB结果跑大模型时数据在片外和片内来回搬实测性能只有理论值的 5%。这个坑一定要在参数计算阶段就避开。4.4 第四步原型验证用 FPGA 还是仿真参数算完下一步是验证。数据流架构的验证比指令驱动架构更难因为数据流动是并行的、异步的传统的指令级仿真器不够用。我一般会分两步走先用高层仿真比如 SystemC 或者 Python 建模验证数据流图的正确性和性能模型再用 FPGA 原型验证硬件细节。高层仿真的好处是快改一个参数几分钟就能看到结果适合做设计空间探索。比如你想对比不同 NoC 拓扑对性能的影响高层仿真一天能跑几十个配置。FPGA 原型的好处是真实能跑实际模型能看到时序、功耗、资源占用。但 FPGA 的容量有限大芯片往往要分多片片间通信又成了新问题。HotChips 上有个团队分享说他们用 4 片 FPGA 拼了一个原型光片间同步就调了两个月。所以我的建议是高层仿真做探索FPGA 原型做确认两者结合不要指望一步到位。4.5 第五步编译器协同硬件和软件一起迭代最后一步也是最重要的一步编译器和硬件协同迭代。数据流架构芯片的最终性能很大程度上取决于编译器能不能把计算图高效地映射到硬件上。我见过太多芯片硬件指标很漂亮但编译器映射不好实际跑模型性能打对折。所以从第一天起编译器团队和硬件团队就要坐在一起。协同迭代的具体做法是硬件团队提供架构参数计算单元数量、NoC 带宽、存储容量编译器团队拿这些参数去映射目标模型看性能瓶颈在哪然后反馈给硬件团队调整参数。这个循环可能要跑很多轮每一轮硬件改一点编译器调一点直到性能收敛。HotChips 上有个做数据流芯片的公司分享说他们第一版芯片流片前编译器和硬件协同迭代了 20 多轮最后一版编译器的映射效率比第一版提升了 3 倍。这个投入是值得的因为流片一次的成本远高于多迭代几轮编译器。5. 常见问题与排查技巧实录5.1 数据流架构芯片跑不满算力怎么排查这是最常见的问题。芯片标称 100 TOPS实际跑模型只有 20 TOPS算力利用率 20%。排查思路我一般按这个顺序来先看是不是访存瓶颈。用性能计数器看计算单元的等待周期如果大部分时间在等数据那就是 NoC 或者存储带宽不够。这时候要算实际带宽需求对比硬件带宽看差多少。如果差得不多可能是调度问题如果差很多那就是硬件设计问题。再看是不是调度问题。数据流架构里如果数据流动的依赖关系没处理好计算单元会互相等待。比如两个计算单元共享一个缓冲一个写一个读如果调度不好就会冲突。这时候要看编译器的调度策略是不是把有依赖的算子放得太近或者太远。最后看是不是算子映射问题。有些算子可能根本没法高效映射到数据流架构上比如动态形状的算子、稀疏算子。这时候要么改硬件支持要么在编译器里做算子替换或者回退到指令控制。我整理了一个速查表方便对照现象可能原因排查方法解决方向计算单元等待周期高NoC 带宽不足统计 NoC 利用率加宽关键路径或改拓扑计算单元等待周期高存储带宽不足统计片上 SRAM 访问冲突增加 bank 或调整 tiling计算单元利用率低调度依赖冲突看数据流图的临界路径调整调度顺序或加缓冲计算单元利用率低算子映射效率低看编译器的算子覆盖率增加硬件支持或算子替换整体性能波动大动态形状或稀疏看输入分布做形状 specialization5.2 数据流架构的功耗为什么下不来数据流架构理论上能效高但实际做出来功耗下不来往往是因为几个地方没做好。第一时钟树功耗。数据流架构虽然异步触发但大部分设计还是全局时钟同步的时钟树翻转功耗占比可能到 30%。解决办法是分区域时钟门控不活跃的区域关时钟。第二NoC 功耗。数据在 NoC 上流动每次路由转发都要消耗能量。如果 NoC 设计得太复杂功耗就上去了。解决办法是简化路由用静态路由或者电路交换。第三存储功耗。片上 SRAM 的读写功耗在先进工艺下占比越来越高。解决办法是减少不必要的读写增加数据重用。我在实际项目里测过一个数据流加速器计算单元功耗只占 40%NoC 占 25%存储占 25%时钟占 10%。所以优化功耗要从 NoC 和存储下手光优化计算单元效果有限。5.3 编译器映射失败或者性能差怎么办编译器映射失败通常有几个原因片上存储不够、NoC 带宽不够、算子不支持。排查时先看编译器的报错信息如果是存储不够就减小 tile size 或者增加片上存储如果是带宽不够就调整数据流调度让数据流动更均匀如果是算子不支持就加硬件支持或者在编译器里做算子分解。性能差的话先看编译器的调度报告找到临界路径。数据流架构的性能瓶颈往往在最长的那条数据依赖链上。如果临界路径太长就考虑并行化把一条长链拆成多条短链。如果临界路径不长但性能还是差那就是资源冲突看是不是多个数据流争抢同一个计算单元或者同一条 NoC 路径。实操心得数据流编译器的调试最好有一个可视化的数据流图工具能把调度结果画出来标出每个节点的开始时间、结束时间、占用的资源。这样一眼就能看出瓶颈在哪。纯看日志或者数字效率太低了。5.4 数据流架构适合 Transformer 吗这是 HotChips 上讨论很多的问题。Transformer 的核心是注意力机制里面有矩阵乘、softmax、层归一化。矩阵乘很适合数据流架构softmax 和层归一化相对不规则但也可以做成数据流。挑战在于注意力的序列长度是可变的数据流图要能动态适应。目前我看到的一些方案是矩阵乘用数据流阵列softmax 用可配置的向量单元整体用混合架构。纯数据流架构跑 Transformer 也有但往往要做形状 specialization把序列长度固定或者分档。我的判断是数据流架构在 Transformer 推理上是有优势的尤其是矩阵乘部分。但要注意 softmax 的数值稳定性数据流架构里做 exp 和除法精度和延迟都要仔细设计。HotChips 上有个团队分享说他们把 softmax 做成流水线用查表加插值近似 exp精度损失控制在 0.1% 以内性能比软件实现快 20 倍。这个思路值得参考。6. 我对下一代 AI 芯片架构的几个判断6.1 数据流和指令控制的边界会越来越模糊纯数据流和纯指令控制都是极端实际芯片里往往是混合的。HotChips 上我看到的一个明显趋势是粗粒度用指令控制细粒度用数据流触发。比如整个网络的层间调度用指令层内的计算用数据流。这样既有指令控制的灵活性又有数据流的能效。未来这个边界会越来越模糊硬件可能同时支持两种模式编译器根据算子特点自动选择。6.2 存储和计算的融合会更深入数据流架构的一个天然优势是存储和计算可以靠得很近。HotChips 上有个设计把 SRAM 和计算单元做在一起数据从 SRAM 读出直接进计算单元省掉了中间的寄存器和总线。这种“存内计算”或者“近存计算”的思路在数据流架构里特别自然。未来我判断会有更多设计把存储和计算融合减少数据搬运的能量开销。6.3 编译器和硬件的协同设计会成为标配前面反复提到编译器的重要性。我的判断是未来做 AI 芯片编译器团队和硬件团队必须是一体的。硬件设计的时候就要考虑编译器怎么映射编译器设计的时候就要考虑硬件的能力边界。HotChips 上做得好的公司都是编译器团队和硬件团队坐在一起办公的。那种硬件做完扔给编译器团队的做法在数据流架构上行不通。6.4 数据流架构的评估标准需要更新传统的芯片评估标准是 TOPS、TOPS/W、面积。但数据流架构的实际性能高度依赖负载和编译器光看峰值指标会误导。我建议在评估数据流架构芯片时加上几个指标实际模型端到端性能、编译器映射效率、负载适应性。HotChips 上有些公司开始公布实际模型的性能数据而不是只公布峰值这是个好趋势。最后分享一个我在实际项目里的小技巧评估数据流架构芯片时不要只看它跑得最好的那个模型要看它跑得最差的那个。因为数据流架构的优势在于匹配劣势也在于匹配。跑得最好的模型可能利用了硬件的所有特性跑得最差的模型可能暴露了硬件的所有短板。把最差的那个搞清楚你才能真正判断这个架构适不适合你的场景。