1. 从HotChips现场聊起为什么数据流架构突然成了香饽饽今年HotChips的议程一出来我朋友圈里做芯片架构的几个人几乎同时转了同一场演讲的预告。原因很简单过去几年大家被“堆算力”这件事搞得有点疲惫了。工艺红利在放缓封装成本在飙升单纯靠增加MAC阵列规模来提升峰值算力的路子边际收益越来越薄。而数据流架构Dataflow Architecture这个在学术圈讨论了二三十年的老概念突然被推到了产业聚光灯下背后一定有它不得不被重视的理由。我先把结论放在前面数据流架构之所以在当下这个时间点被反复提及核心原因是它试图解决一个传统冯诺依曼架构下越来越尖锐的矛盾——计算单元和存储单元之间的数据搬运开销已经远远超过了计算本身的开销。在典型的AI推理负载里一次矩阵乘法的能量消耗中真正用于乘加运算的部分可能只占不到百分之五剩下的百分之九十五都花在了把数据从DRAM搬到SRAM、再从SRAM搬到寄存器堆的过程中。这个比例不是我拍脑袋说的是多家研究机构在不同工艺节点上反复验证过的量级。那数据流架构是怎么应对这个问题的它的基本思路是让数据自己“流动”起来计算单元在数据到达时就被触发执行而不是由一个中央控制器按顺序取指、译码、执行。换句话说控制的粒度从“指令级”变成了“数据级”。这听起来有点抽象你可以把它想象成一个工厂流水线传统架构是工头拿着喇叭喊“一号工位开始、二号工位准备”而数据流架构是传送带上的零件到了哪个工位哪个工位就自动开始干活。少了中央调度的开销也少了频繁访问寄存器文件的需求。这篇文章适合谁看如果你是对AI芯片架构感兴趣但还没深入过数据流方向的开发者我会从最基础的概念讲起把HotChips上几个典型设计拆开揉碎。如果你已经在做相关的工作我会重点分享架构选型时的权衡逻辑、参数计算过程以及实际落地时容易踩的坑。整篇内容基于我在这个方向的持续跟踪和一些实际项目的经验尽量做到既有原理层面的解释也有可以直接参考的实操细节。2. 数据流架构到底在“流”什么核心概念拆解2.1 从冯诺依曼瓶颈说起要理解数据流架构得先看清楚传统架构的痛点在哪里。冯诺依曼架构的核心特征是“指令驱动”程序计数器指向一条指令控制器把它取出来、译码、然后执行。这个模式通用性极强几乎支撑了整个计算机产业的发展。但它的代价是每一次计算都需要经过取指、译码、访存、执行、写回这几个阶段而其中访存环节在AI负载下会成为绝对的瓶颈。我做过一个简单的估算假设一个乘加运算需要从寄存器文件读取两个操作数那么即使寄存器文件的带宽做到每周期128字节一个256个MAC单元的阵列每周期也需要读取512字节的操作数。这个带宽需求在传统架构下很难持续满足更不用说数据还要从更远的SRAM或DRAM搬过来。结果就是计算单元经常处于“等数据”的状态利用率可能只有百分之二三十。数据流架构的切入点就在这里。它不再把“取指令”作为执行的起点而是把“数据可用”作为执行的触发条件。当一个计算节点的所有输入数据都准备好了这个节点就自动开始计算并把结果传给下游节点。整个过程不需要程序计数器的参与也不需要指令译码器。控制逻辑从“集中式”变成了“分布式”每个节点只需要知道自己什么时候该干活。2.2 数据流架构的几种典型形态在实际的芯片设计中数据流架构并不是一个单一的模式它有几个常见的变体各自适用于不同的场景。第一种是静态数据流。这种模式下计算图在编译阶段就已经确定好了每个节点的连接关系和触发条件都是固定的。硬件实现相对简单因为不需要动态调度逻辑。缺点是灵活性差一旦计算图变了硬件就得重新配置。适合那些负载非常稳定的场景比如某些固定的推理任务。第二种是动态数据流。节点可以在运行时根据数据的到达情况动态决定执行顺序。灵活性高但硬件复杂度也高需要额外的仲裁和调度逻辑。在通用性要求较高的AI加速器里这种模式更常见。第三种是粗粒度可重构数据流。这是目前产业界比较流行的一种折中方案。计算单元不是单个的乘加器而是一个个小型的处理单元PE每个PE内部有自己的小存储和计算逻辑。PE之间的连接可以通过配置来改变从而适应不同的计算图。这种方案在灵活性和效率之间找到了一个比较好的平衡点。在HotChips上看到的几个设计大多是在粗粒度可重构这个方向上做文章。有的把PE阵列做成二维网格有的做成层次化的树状结构还有的针对特定算子做了定制化的数据流优化。这些设计的共同点是都在试图减少数据搬运让计算单元尽可能“吃饱”。2.3 数据流架构的核心优势与代价数据流架构最大的优势在于能量效率。因为减少了指令调度和寄存器访问的开销同样的计算量下功耗可以显著降低。有研究数据显示在某些典型的卷积神经网络负载下数据流架构的能效比传统SIMD架构高出三到五倍。这个数字在边缘端和移动端尤其有吸引力因为那里的功耗预算非常紧张。第二个优势是可扩展性。传统架构在增加计算单元时指令调度和寄存器文件的压力会线性增长很快就遇到瓶颈。而数据流架构的分布式控制天然适合大规模并行增加节点时只需要扩展连接网络控制逻辑的复杂度增长相对平缓。但代价也是实实在在的。首先是编程模型复杂。传统架构上写代码程序员只需要关心指令序列数据流架构上需要把计算映射成数据流图考虑节点之间的依赖关系和数据分布。这对编译器和编程框架提出了很高的要求。其次是硬件资源利用率。如果计算图中有一些节点的数据依赖比较稀疏或者存在大量的条件分支数据流架构的节点可能会经常处于空闲状态利用率反而不如传统架构。所以数据流架构不是万能药它更适合那些计算图相对规整、数据依赖密集的负载。这也是为什么它在深度学习推理领域先火起来的原因——卷积、矩阵乘法这些算子的数据流模式非常规整天然适合数据流架构发挥优势。3. HotChips上的典型设计拆解他们是怎么做的3.1 二维网格型数据流架构HotChips上有一类设计采用了二维网格2D Mesh的拓扑结构。每个网格节点是一个处理单元包含一个小型的乘加阵列和一块本地SRAM。节点之间的连接是最近邻的数据可以在网格中逐跳传输。这种设计的核心考量是局部性。在卷积运算中相邻的输出像素共享大量的输入数据。如果把这些相关的计算映射到相邻的节点上那么数据只需要在相邻节点之间传递不需要经过长距离的全局总线。这大大降低了互连网络的功耗和延迟。具体实现上每个节点通常包含一个8x8或16x16的乘加阵列本地SRAM的容量在几十KB到几百KB之间。节点之间的数据带宽需要仔细设计带宽太低会成为瓶颈带宽太高则功耗和面积开销太大。一个常见的做法是根据目标负载的数据复用率来反推所需的带宽。比如如果平均每个输入数据被复用8次那么节点间的带宽可以设计为计算带宽的八分之一左右。这种架构的挑战在于映射效率。不是所有的计算图都能完美地映射到二维网格上。有些算子的数据依赖是长距离的需要经过多跳传输延迟会比较大。为了解决这个问题有些设计在网格中加入了长距离的旁路通道或者采用了层次化的网格结构。3.2 层次化树状数据流架构另一类设计采用了树状的层次化结构。底层的叶子节点负责细粒度的计算上层的节点负责数据的汇聚和分发。这种结构在处理规约操作如求和、求最大值时特别有优势因为规约操作天然就是树形的。我印象比较深的是一个用于Transformer推理的设计。Transformer中的注意力机制涉及到大量的矩阵乘法和softmax操作数据依赖比较复杂。这个设计把注意力计算分解成几个阶段每个阶段用不同的数据流模式来处理。在QK^T乘法阶段采用了广播式的数据流把Query向量广播到多个节点每个节点负责计算与一个Key向量的点积。在softmax阶段则切换成树状的规约模式逐层汇总最大值和指数和。这种动态切换数据流模式的能力是层次化架构的一个亮点。它不像静态数据流那样只能处理固定的计算图而是可以根据算子的特点灵活调整。代价是控制逻辑更复杂需要一套机制来在运行时重新配置节点之间的连接。3.3 针对特定算子的定制化数据流还有一类设计走的是更极致的路线针对某一个或某一类算子把数据流架构做到极致。比如专门为卷积设计的脉动阵列Systolic Array本质上就是一种高度规整的数据流架构。数据在阵列中按固定的节奏流动每个周期都有新的数据进入、旧的数据移出计算单元始终保持忙碌。脉动阵列的优势在于控制极其简单。因为数据流动的节奏是固定的不需要复杂的握手协议和仲裁逻辑。每个PE只需要知道什么时候从左边和上边接收数据、什么时候把结果传给右边和下边。这种简单性使得它可以做到很高的频率和很低的功耗。但脉动阵列的局限性也很明显它只适合那些可以规整映射到阵列上的计算。一旦遇到不规则的稀疏计算或者动态变化的计算图脉动阵列的效率就会大幅下降。所以现在很多设计会把脉动阵列和其他类型的数据流架构混合使用用脉动阵列处理规整的卷积用更灵活的数据流处理其他算子。4. 实操中的架构选型参数怎么算、方案怎么定4.1 从负载特征反推架构参数做架构设计最忌讳的就是拍脑袋定参数。我见过不少项目一开始就定下“要做256个MAC单元”“片上SRAM要16MB”这样的目标结果做到后面发现要么算力过剩、要么带宽不够。正确的做法是从目标负载的特征出发反推所需的计算资源和存储资源。具体来说需要先分析目标负载的几个关键指标计算强度每字节数据能支撑多少次运算、数据复用率同一份数据被重复使用的次数、并行度可以同时执行的计算任务数量。这三个指标决定了架构的基本形态。举个例子假设目标负载是一个典型的卷积层输入特征图是224x224x64卷积核是3x3x64x128。计算量大约是224x224x128x3x3x64约等于3.7 GFLOPs。输入数据量是224x224x64x4字节约等于12.8 MB。计算强度大约是289 FLOPs/Byte。这个强度不算高意味着数据搬运的压力比较大架构设计时需要重点考虑如何提高数据复用率。如果采用数据流架构可以把卷积核的权重固定在PE中让输入特征图在PE阵列中流动。这样权重只需要加载一次输入数据每个元素被复用128次对应128个输出通道。复用率上去了对带宽的需求就下来了。根据这个复用率可以反推PE阵列的规模和本地SRAM的容量。4.2 互连网络的设计权衡数据流架构中互连网络的设计往往是最容易被低估的部分。很多人把注意力放在计算单元上结果做出来的芯片计算能力很强但数据在节点之间传不动整体性能上不去。互连网络的设计需要在带宽、延迟、面积、功耗这四个维度之间做权衡。全连接的网络带宽最高、延迟最低但面积和功耗随节点数量呈平方增长超过一定规模就不可行了。二维网格的面积和功耗随节点数量线性增长但延迟随距离增加最坏情况下需要经过O(√N)跳。一个实用的折中方案是层次化互连。把节点分成若干簇簇内用全连接或高带宽总线簇间用网格或环形连接。这样大部分通信发生在簇内只有少量数据需要跨簇传输。簇的大小需要根据负载的通信模式来确定如果大部分数据复用发生在局部簇可以小一些如果需要频繁的全局通信簇就要大一些。在实际项目中我通常会先用一个简单的分析模型估算不同互连方案的带宽需求然后再用周期级仿真来验证。分析模型可以快速排除明显不合理的方案仿真则用来做精细的对比。这个过程可能需要迭代好几轮但比直接拍板要靠谱得多。4.3 编译器与硬件的协同设计数据流架构的硬件设计离不开编译器的配合。硬件提供了什么样的数据流模式编译器就需要能够把计算图映射到这些模式上。如果硬件支持的模式和编译器的能力不匹配再好的硬件也发挥不出来。在项目初期我建议硬件和编译器团队一起定义中间表示IR。这个IR需要能够表达计算图的结构、数据依赖关系、以及硬件支持的数据流模式。硬件团队根据IR来设计指令集和配置接口编译器团队根据IR来开发映射和优化算法。两边用同一套IR作为沟通语言可以避免很多后期的返工。一个常见的坑是硬件设计时觉得某个数据流模式很优雅但编译器实现起来非常复杂或者映射效率很低。反过来编译器期望的某些优化硬件又不支持。解决这个问题的办法是尽早做端到端的验证拿一个真实的模型从编译器前端一路跑到硬件仿真看看整个流程是否顺畅、性能是否达标。不要等到硬件流片了才发现编译器映射不了。5. 常见问题与排查技巧实录5.1 数据流架构的典型问题速查在实际项目中数据流架构会遇到一些特有的问题。我把常见的几个整理成了表格方便快速对照排查。问题现象可能原因排查思路解决方向计算单元利用率低数据供给不足或依赖阻塞检查数据到达率和节点等待时间调整数据流图映射增加数据预取功耗超出预期互连网络翻转率过高分析节点间通信模式优化数据局部性减少长距离传输映射失败或效率低计算图与硬件拓扑不匹配检查计算图的连通性和并行度调整硬件拓扑或增加映射灵活性延迟波动大动态调度引入的不确定性分析调度器的仲裁策略改用静态调度或限制动态调度范围面积超标本地存储或互连资源过多分析各模块的面积占比重新权衡存储容量和互连带宽5.2 几个容易踩的坑第一个坑是过度追求峰值算力。数据流架构的峰值算力很容易做高因为可以堆很多计算单元。但实际性能取决于数据供给能否跟上。我见过一个设计峰值算力做到了128 TOPS但实际跑模型只有不到20 TOPS的有效算力原因就是数据带宽不够。所以在定义规格时一定要把有效算力作为核心指标而不是峰值算力。第二个坑是忽视编译器的开发周期。硬件设计可能一年就能完成但一个成熟的编译器可能需要两到三年。如果硬件流片了编译器还没准备好芯片就只能跑一些手工优化的demo无法支持真实的模型。我的建议是在硬件设计的同时就启动编译器的开发哪怕一开始只支持最简单的映射也要尽早打通整个流程。第三个坑是本地SRAM容量拍脑袋决定。SRAM太大则面积和功耗受不了太小则数据复用率上不去。正确的做法是根据目标负载的数据复用模式来计算所需的容量。比如如果目标负载的最大复用窗口是64KB那么本地SRAM至少要有64KB否则数据就会被反复换入换出。这个计算需要结合具体的算子来分析不能一概而论。5.3 性能调优的实操心得性能调优时我习惯先做瓶颈分析。具体做法是在仿真环境中统计每个节点的忙碌周期、等待周期、以及互连网络的利用率。如果某个节点的等待周期占比很高说明它的上游数据供给有问题如果互连网络的利用率接近饱和说明带宽是瓶颈。找到瓶颈后调优的方向就明确了。如果是数据供给问题可以考虑增加预取缓冲区、调整数据流图的映射顺序、或者增加本地存储容量。如果是互连带宽问题可以考虑优化数据局部性、减少不必要的数据传输、或者增加互连的并行通道。还有一个实用的技巧是分阶段调优。不要试图一次性解决所有问题而是先解决最大的瓶颈然后再看下一个。因为系统的瓶颈会随着优化而转移解决了计算瓶颈后瓶颈可能就变成了存储或互连。分阶段调优可以避免在非瓶颈环节浪费精力。6. 数据流架构的未来走向与个人观察从HotChips这几年的趋势来看数据流架构正在从学术研究走向产业落地。早期的数据流架构更多是在FPGA上做验证现在已经有多个基于数据流架构的AI芯片实现了量产。这个转变的背后是深度学习负载的规整性和数据流架构的高效性之间找到了比较好的匹配点。但我个人觉得数据流架构不会完全取代传统的指令驱动架构。更可能的情况是两者融合在芯片内部用数据流架构来处理规整的计算密集型任务用指令驱动架构来处理控制密集型和灵活性的任务。这种异构架构已经在一些高端芯片中出现了未来可能会成为主流。另一个值得关注的方向是可重构数据流。如果硬件能够在运行时动态改变数据流模式那么同一块芯片就可以适应不同的负载灵活性和效率都能兼顾。这需要硬件和编译器的深度协同技术难度不小但潜力很大。最后分享一个我在实际项目中的体会数据流架构的设计本质上是在灵活性和效率之间找平衡点。过于追求效率硬件就会变得很僵硬只能跑特定的负载过于追求灵活性又会失去数据流架构本身的优势。这个平衡点在哪里取决于你的目标应用场景。如果是做专用的推理加速器可以偏向效率如果是做通用的AI芯片就需要在灵活性上多留一些余地。没有标准答案只有适合自己场景的选择。