1. 从HotChips的议程风向看数据流架构的回归如果你这两年一直在追HotChips的议程应该能感觉到一个明显的变化前几年大家都在卷制程、卷HBM带宽、卷互连拓扑而最近两三届越来越多的演讲开始把话题拉回到一个更底层的问题上——数据在芯片里到底是怎么流动的。这个转向不是学术圈的自我循环而是被真实负载逼出来的。大模型推理和训练对算力的胃口越来越大但芯片的峰值算力利用率和实际有效算力之间的鸿沟并没有同步缩小很多时候卡脖子的不是算得多快而是数据搬得太慢、搬得太远、搬得太频繁。我自己的观察是传统以指令流为中心的架构也就是我们常说的冯诺依曼式控制流在处理规则、稠密的计算时依然高效但一旦遇到稀疏、动态、数据依赖复杂的负载控制开销和访存开销就会迅速吃掉大部分收益。数据流架构Dataflow Architecture之所以重新被拿到台面上讨论核心原因就在于它把什么时候算这件事从集中式的指令调度下放到了数据本身——数据到了就触发计算没到就等着。这个思路听起来简单但落到芯片微架构上涉及的一整套取舍非常值得掰开来讲。这篇文章我想做的事情不是复述某一场HotChips演讲的PPT而是把数据流架构芯片这个方向拆成几个可以讨论的工程问题它到底解决了控制流架构的哪些痛点、在AI负载下它的优势边界在哪里、做一颗数据流AI芯片需要面对哪些真实的架构决策、以及从HotChips上各家披露的细节里能提炼出哪些可复用的设计经验。适合正在做AI加速器架构选型、或者对下一代芯片架构方向感兴趣的读者。我会尽量把原理讲透同时把工程上那些文档里不会写的坑点出来。2. 控制流架构在AI负载下到底卡在哪2.1 指令发射开销与算力利用率的剪刀差要理解数据流架构为什么值得做得先把控制流架构在AI场景下的瓶颈说清楚。传统CPU和大部分早期AI加速器都是控制流驱动的一条指令发射出去译码、取操作数、执行、写回整个过程由程序计数器和一个集中式的调度逻辑来指挥。这个模式在通用计算里非常成功因为它的灵活性高任何逻辑都能表达成指令序列。但AI负载有个特点计算模式高度规则但数据依赖高度动态。以矩阵乘加为例乘加本身是极其规则的运算但什么时候需要哪个操作数、哪个操作数还没准备好是随数据流变化的。在控制流架构里为了保证正确性往往需要插入大量的同步、分支判断和访存指令。这些指令本身不产生有效计算却要占用发射带宽和流水线资源。当矩阵规模变大、稀疏度变高时这些非计算指令的占比会显著上升直接拉低有效算力利用率。HotChips上不止一家厂商提到过类似的数据在某些稀疏推理负载下控制流架构的指令发射带宽有相当大一部分被用于地址计算和依赖检查而不是真正的乘加运算。这就是剪刀差的来源——峰值算力在涨但有效算力被控制开销拖住了。2.2 访存墙数据搬运的能耗远高于计算第二个更硬核的约束是能耗。芯片里做一次乘加的能耗和把操作数从远处存储搬过来的能耗往往差一到两个数量级。这个结论在学术界已经被反复验证过也是所有AI芯片架构师做决策时的第一性原理。控制流架构的一个结构性问题是它倾向于把数据先搬到寄存器或本地缓存再由指令去取用这个搬运-暂存-再取用的链路里很多搬运是重复的、可预测的但架构本身没有机制去消除它。数据流架构的一个核心动机就是让数据在产生的地方尽可能被消费掉减少无谓的往返搬运。这不是说数据流架构就不需要存储层次而是它对存储的访问模式和控制流架构有本质区别——后面会展开讲。2.3 稀疏与动态性对静态调度的挑战第三个痛点是稀疏和动态性。控制流架构的调度在编译期或运行期是相对静态的编译器要尽可能提前把指令排好。但AI模型里的稀疏模式、注意力掩码、动态路由这些机制让提前排好变得非常困难。你排好的指令序列到了运行时可能因为数据分布变化而大量空转。数据流架构天然对动态性更友好因为它的触发条件是数据到达而不是预设的指令顺序稀疏数据没来对应的计算单元就自然不触发不会空转浪费。把这三个痛点放在一起看就能理解为什么HotChips上数据流架构的讨论热度在回升它不是新概念而是在当前AI负载特征下它的优势区间被放大了。3. 数据流架构的核心机制拆解3.1 数据触发计算从取数执行到数到即算数据流架构最本质的特征是计算由数据可用性触发而不是由指令计数器驱动。在一个典型的数据流计算单元里每个算子节点会等待它的所有输入操作数到齐一旦到齐就立即执行执行结果再沿着数据通路流向下一级。整个过程没有集中的指令发射逻辑控制是分布式的、内嵌在数据通路里的。这个机制带来的直接好处是没有指令发射开销没有依赖检查的集中瓶颈。每个节点的等待和触发都是本地的天然并行。对于AI负载里大量存在的、数据依赖明确的算子比如卷积、矩阵乘、激活函数这种模式可以把控制开销压到极低。但要注意数据流架构不是没有控制而是把控制从集中式变成了分布式。分布式控制的设计难度其实更高因为你要保证在任意数据到达顺序下计算结果的正确性和一致性。这是工程上最容易翻车的地方之一。3.2 静态数据流与动态数据流的取舍数据流架构内部还要分两类静态数据流和动态数据流。静态数据流在编译期就把数据通路和触发关系确定下来运行时不再改变硬件实现简单、能效高但灵活性差遇到动态负载容易僵化。动态数据流则在运行时根据数据情况动态决定触发和路由灵活性强但需要额外的仲裁和标记逻辑面积和功耗开销更大。在AI芯片里实际做法往往是混合的规则、稠密的部分用静态数据流动态、稀疏的部分用动态数据流。HotChips上一些架构披露里能看到这种分层设计——粗粒度的算子间用静态调度细粒度的算子内用动态触发。这个取舍没有标准答案取决于你的目标负载分布。3.3 数据流图到硬件的映射逻辑从软件视角看一个AI模型会被表达成一张数据流图Dataflow Graph节点是算子边是数据依赖。把这图映射到硬件上核心问题是哪些节点映射到同一个计算单元、边用什么物理通路实现、数据在哪一级存储暂存。映射策略直接决定了芯片的效率和灵活性。如果映射得太粗一个计算单元承担太多节点内部又退化成控制流如果映射得太细节点间通信开销会爆炸。我见过一些设计在映射粒度上反复调整最后发现算子的融合边界才是关键——把哪些算子融在一起、融合后内部用什么数据流模式比单纯讨论是不是数据流架构更有实际意义。4. AI负载下数据流架构的真实优势边界4.1 稠密矩阵计算优势明显但有前提在稠密矩阵乘这类负载上数据流架构的优势是实打实的。因为计算模式规则数据流图可以高度优化操作数复用路径可以设计得很短控制开销几乎可以忽略。典型做法是设计一个脉动阵列Systolic Array或者类似的规则数据通路让数据在计算单元之间规律流动每个周期都有有效计算发生。但这里有个前提数据供给必须跟得上。如果片上缓存带宽不够或者数据流图的调度导致操作数到达节奏和计算节奏不匹配脉动阵列也会饿死。所以数据流架构在稠密计算上的优势是建立在存储层次和调度策略都做对的基础上的不是架构本身自动带来的。4.2 稀疏与不规则计算动态数据流的用武之地稀疏计算是数据流架构更能体现差异化的地方。控制流架构处理稀疏时往往要靠掩码、分支、条件执行来跳过零元素这些机制本身有开销而且跳过逻辑越复杂开销越大。动态数据流架构可以让零元素根本不产生触发信号对应的计算单元自然不工作理论上能做到零开销跳过。实际工程里要做到这一点需要解决两个问题一是稀疏模式的检测和编码要足够快不能成为新瓶颈二是计算单元要能处理不规则的数据到达节奏不能因为等待某个操作数而整体停顿。HotChips上有架构专门为稀疏设计了动态调度单元思路值得参考但复杂度也确实高。4.3 控制密集与标量逻辑数据流并不擅长必须说清楚的是数据流架构不是万能的。对于控制密集、标量逻辑多的负载比如复杂的条件分支、递归、动态内存管理数据流架构反而会显得笨重。因为它的优势在于数据驱动的并行计算而控制密集负载的本质是串行决策数据流图会变得又大又难调度。所以现实中的AI芯片很少是纯数据流架构更多是数据流为主、控制流为辅的异构设计。把适合数据流的算子交给数据流引擎把控制逻辑交给一个小的控制核这个分工是当前比较务实的做法。5. 做一颗数据流AI芯片要面对的关键架构决策5.1 计算单元的粒度粗粒度与细粒度的平衡第一个决策是计算单元的粒度。粗粒度计算单元比如一个完整的矩阵乘单元实现简单、能效高但灵活性差遇到不匹配的算子形状就浪费。细粒度计算单元比如单个乘加器或小向量单元灵活但调度和通信开销大。我的经验是粒度选择要跟着目标负载的算子形状分布走。如果你的目标负载里矩阵乘占主导粗粒度更划算如果算子种类杂、形状多变就得往细粒度靠或者做可重构的粒度。HotChips上一些架构用了可重构的计算阵列本质上就是在粒度上做折中。5.2 片上存储层次数据流架构的存储设计逻辑数据流架构的存储设计和控制流架构有本质区别。控制流架构的存储层次是为了配合指令取数缓存行、预取这些机制都是围绕指令流设计的。数据流架构的存储更像是一个数据暂存和路由网络重点是让数据在正确的时间出现在正确的位置而不是最小化访存延迟。具体来说数据流架构通常会用大量的分布式小缓存或寄存器文件靠近计算单元减少长距离搬运。片上网络NoC的设计也变得极其关键因为数据流动的路径直接决定了能效。我见过一些设计在NoC上花的面积和功耗占比相当高这是数据流架构容易被低估的成本。5.3 编程模型与编译器数据流芯片的软件门槛这可能是最容易被低估的一环。数据流芯片的硬件再优雅如果编程模型不友好、编译器不够强实际用起来就是灾难。控制流架构有成熟的编程语言和编译器生态数据流架构则需要一套新的抽象——通常是从数据流图出发的领域特定语言DSL和配套的调度编译器。编译器的核心任务是把高层数据流图映射到硬件资源上包括算子融合、数据布局、存储分配、通信调度。这个映射问题在一般情况下是NP难的实际编译器只能用启发式算法。编译器的质量往往决定了一颗数据流芯片的实际可用性这一点在选型时比峰值算力更值得关注。6. 从HotChips披露细节里提炼的工程经验6.1 数据流调度器的设计难点从各家披露的架构看数据流调度器是设计难点中的难点。它要解决的核心问题是在分布式触发的前提下如何保证不出现死锁、不出现数据丢失、不出现顺序错误。常见做法是给数据打标记tag用标记来匹配操作数标记机制的设计直接决定了调度器的复杂度和鲁棒性。一个容易踩的坑是标记空间的设计。标记太少会冲突标记太多会浪费存储和带宽。实际设计里往往要根据最大在途数据量来算标记位宽这个计算需要结合负载特征不能拍脑袋。6.2 片上网络与数据路由的取舍片上网络在数据流架构里的角色比在控制流架构里更重要因为数据流动本身就是计算的一部分。路由策略、拓扑结构、流控机制每一个选择都会影响整体能效。HotChips上能看到从简单总线到复杂Mesh的各种选择没有绝对优劣关键看负载的通信模式。我的体会是NoC设计要和数据流图的通信模式对齐。如果负载的通信是局部密集的用层次化拓扑更划算如果是全局随机的Mesh或更复杂的拓扑才撑得住。脱离负载谈NoC拓扑没有意义。6.3 能效数据背后的真实含义HotChips上各家都会给能效数据但看这些数据要小心。能效数字高度依赖测试负载、工作频率、电压条件和统计口径。同样标称每瓦多少TOPS在不同负载下可能差好几倍。看能效数据时一定要看它是在什么负载、什么精度、什么稀疏度下测的否则很容易被误导。我一般会关注两个指标一是典型负载下的能效而不是峰值能效二是能效随负载变化的曲线看它在负载波动时是否稳定。这两个比单一峰值数字有参考价值得多。7. 数据流架构芯片的落地场景与选型建议7.1 边缘推理与数据中心训练的不同诉求数据流架构在边缘推理和数据中心训练这两个场景下的诉求差别很大。边缘推理看重能效和确定性延迟数据流架构的规则性和低控制开销很契合但边缘场景的负载多样性又对灵活性提出要求所以边缘数据流芯片往往要在灵活性和能效之间做精细平衡。数据中心训练看重吞吐和可扩展性数据流架构在大规模并行上有优势但训练的动态性和通信复杂度也更高对编译器和NoC的要求更苛刻。选型时先明确你的主场景是推理还是训练、是边缘还是数据中心再去看架构是否匹配比单纯比较架构类型更有意义。7.2 什么团队适合切入数据流架构数据流架构不是适合所有团队的。它需要架构、编译器、算法三方面能力都到位缺一环就会导致芯片做出来但用不起来。如果团队只有硬件能力没有编译器和软件栈的积累做数据流芯片的风险很高。反过来如果团队有强的编译器背景和明确的负载定义数据流架构反而可能是一个差异化的切入点。7.3 从架构选型到流片验证的实操路径如果真要推进一颗数据流AI芯片我的建议路径是先用FPGA或仿真平台验证数据流图和调度策略把编译器和运行时跑通确认目标负载下的实际效率再考虑流片。直接流片验证架构风险太大尤其是数据流架构的调度正确性在仿真阶段暴露问题比在硅片上暴露便宜得多。验证阶段要重点看三件事调度器在极端数据到达顺序下是否死锁、NoC在拥塞情况下是否丢数据、编译器生成的映射在负载变化时是否稳定。这三件事过了流片才有底气。8. 我对数据流架构芯片的一点个人判断做了这些年架构相关的工作我对数据流架构的看法是它不是一个取代控制流的答案而是一个在特定负载区间里更优的选择。AI负载的多样性决定了未来芯片大概率是异构的数据流引擎和控制流引擎各管一摊靠编译器和运行时来协调。HotChips上数据流架构讨论的升温反映的是行业在寻找控制流之外的第二条路而不是说控制流要被淘汰。如果你正在评估数据流架构我的建议是先把目标负载的数据流图特征摸清楚——算子形状分布、稀疏度、通信模式、动态性程度这些比架构名词更能指导决策。架构是为负载服务的脱离负载谈架构优劣容易陷入纸上谈兵。最后分享一个实操小技巧在做架构对比时别只看峰值算力和能效一定要把编译器的成熟度和编程模型的易用性纳入评估这两项在实际落地时的权重往往比纸面参数更高。