从HotChips议程看数据流架构回归：AI芯片如何突破内存墙与功耗墙
1. 从HotChips的议程风向看数据流架构的回归
每年HotChips的议程变化，基本就是芯片行业未来两三年技术路线的一张晴雨表。前几年大家挤破头去讲的是制程微缩、Chiplet封装、HBM带宽，而最近一两届，一个明显的信号是：数据流架构（Dataflow Architecture）相关的议题占比在快速上升，而且不再是学术圈的自娱自乐，而是英伟达、谷歌、特斯拉这些真正在量产芯片的团队在台上讲。这个变化本身就值得琢磨——为什么在算力堆叠已经如此极致的今天，大家反而回头去重新审视一种几十年前就提出的架构思想？
答案其实不复杂。当摩尔定律的边际收益越来越薄，单纯靠堆晶体管、堆带宽、堆算力的路子已经撞到了功耗墙和内存墙。一颗芯片里，计算单元可能只占面积的三成，剩下七成都在做数据搬运和调度。数据流架构的核心价值，恰恰是把"搬运"这件事的代价压到最低，让计算单元尽可能少地空转等待数据。这不是新概念，但在AI负载成为主流的今天，它的适用性被重新激活了。
这篇文章想做的事情，是把HotChips上那些关于数据流架构的讨论，翻译成一线工程师能直接理解和参考的架构思考。我会从数据流架构到底解决了什么问题讲起，拆解它的几种典型实现形态，对比它和传统冯诺依曼架构在AI场景下的真实差异，最后落到实际选型和设计时容易踩的坑。不管你是做芯片架构设计的，还是做AI系统优化的，或者是想搞清楚下一代AI芯片到底往哪走的从业者，这篇内容应该都能给你一些可用的参考。
2. 数据流架构到底在解决什么问题
2.1 冯诺依曼瓶颈在AI负载下的真实代价
要理解数据流架构为什么回归，得先把传统架构在AI场景下的痛点说清楚。经典的冯诺依曼架构，计算和存储是分离的，指令一条条从内存取出来，数据也从内存搬到计算单元，算完再写回去。这个模型通用性极强，但在AI负载下，它的代价被放大了几个数量级。
AI计算的核心是大量的矩阵乘加运算，数据复用率理论上可以很高，但传统架构的取指-译码-执行流水线，每做一次运算都要经历完整的指令周期。更致命的是，内存带宽的增长速度远远跟不上算力增长速度。过去二十年，算力翻了大概几万倍，而内存带宽只翻了几百倍，这个剪刀差就是所谓的"内存墙"。
我拿一个具体的数字来感受一下。假设一个典型的卷积层，计算量是1 GFLOP，数据量是10 MB。在传统架构下，如果每次运算都要从DRAM取数据，那需要的带宽是计算量的几十倍甚至上百倍。实际芯片里当然有缓存和寄存器复用，但即便如此，数据搬运消耗的能量往往是计算本身的几倍到几十倍。有研究数据表明，在28nm工艺下，一次32位浮点乘加运算的能耗大约是3.7 pJ，而从DRAM取一次数据的能耗是640 pJ，差了将近两百倍。这意味着，架构设计的核心矛盾不是"算得快不快"，而是"数据搬得贵不贵"。
2.2 数据流架构的核心思想：让数据驱动计算
数据流架构的思路，从根本上换了一个驱动模型。传统架构是"控制流"驱动——程序计数器指向哪条指令，就执行哪条，数据是被动地被拉过来。而数据流架构是"数据流"驱动——当一条运算的所有输入数据都就绪时，这条运算就自动触发执行，不需要指令来调度。
这个区别听起来抽象，但用生活化的类比就很好理解。控制流架构像是一个严格的流水线工厂，工人必须等工头喊"下一个"，才能开始干活，哪怕零件早就摆在面前了。数据流架构则像是自助餐厅，食材一到齐，厨师就自动开始做这道菜，不需要有人专门指挥。
在硬件实现上，数据流架构通常会把计算任务映射成一张数据流图（Dataflow Graph），节点是运算单元，边是数据依赖关系。数据在节点之间流动，每个节点只关心自己的输入是否到齐。这种模型天然适合AI负载，因为神经网络的计算图本身就是一张数据流图，层与层之间的依赖关系是明确的。
2.3 为什么是现在：三个条件同时成熟
数据流架构不是新东西，上世纪七八十年代就有大量研究，但当时没能成为主流。现在它重新回到舞台中央，是因为三个条件同时成熟了。
第一，AI负载的确定性。传统通用计算的任务类型千变万化，数据流架构很难覆盖所有场景。但AI推理和训练的计算模式高度规整，就是矩阵运算加激活函数，这种确定性让数据流架构的优势能充分发挥。
第二，片上存储和互连技术的进步。数据流架构需要把大量数据留在片上，对SRAM容量和NoC（片上网络）带宽要求很高。现在3D堆叠、先进封装、高密度SRAM这些技术已经能支撑起这个需求。
第三，编译器和映射工具的成熟。数据流架构的编程难度一直是个大问题，需要把计算图高效映射到硬件上。现在TVM、MLIR这些编译框架的发展，让这个映射过程可以自动化完成，大大降低了使用门槛。
3. HotChips上几种典型数据流芯片的架构拆解
3.1 粗粒度可重构阵列：以TPU为代表的脉动阵列思路
谷歌TPU是数据流架构在工业界最成功的落地案例之一。它的核心是一个256x256的脉动阵列（Systolic Array），数据从左侧和上方流入，在阵列中像波浪一样逐级传递，每个PE（处理单元）完成一次乘加后把结果传给下一个PE。
这种设计的精妙之处在于，数据在阵列中的流动是规整的、可预测的，不需要复杂的调度逻辑。权重数据预先加载到阵列中，激活值从一侧流入，部分和从另一侧流出。整个过程中，数据复用率极高，每个权重被复用了256次，每个激活值也被复用了256次。这就把内存带宽的压力降到了最低。
但脉动阵列也有它的局限。它最适合的是稠密矩阵运算，遇到稀疏矩阵或者不规则计算时，PE的利用率会大幅下降。而且阵列一旦固定，灵活性就受限，很难适应不同形状的矩阵。HotChips上不少团队在讨论的，就是如何在保持脉动阵列高效率的同时，增加一定的灵活性。
3.2 粗粒度数据流：特斯拉Dojo的分布式计算架构
特斯拉的Dojo芯片是另一个值得研究的案例。它采用的是一种粗粒度数据流架构，每个核心是一个独立的计算节点，节点之间通过高带宽互连通信。计算任务被切分成小块，分配到各个节点上，节点之间通过数据依赖关系自动触发执行。
Dojo的设计哲学和TPU不同。TPU追求的是极致的规整性和复用率，而Dojo更强调可扩展性和灵活性。它的每个节点都有自己独立的存储和计算资源，可以独立处理一个子任务。这种架构在训练场景下特别有优势，因为训练的计算图往往比推理更复杂，需要更多的并行度和灵活性。
从HotChips上披露的信息看，Dojo的互连网络是它最核心的技术难点之一。节点之间的通信带宽和延迟直接决定了整个系统的扩展效率。特斯拉在这方面做了大量定制化设计，包括专用的路由芯片和高速SerDes，这些都是为了支撑数据流架构对通信的高要求。
3.3 细粒度数据流：学术界的探索与工业界的谨慎
除了上面两种粗粒度方案，学术界一直在探索更细粒度的数据流架构。细粒度意味着每个运算单元都可以独立触发，调度粒度更小，理论上灵活性更高。但细粒度带来的问题是调度开销大、硬件复杂度高，在实际芯片中很难做到高效率。
HotChips上一些学术团队的报告显示，细粒度数据流在特定场景下确实有优势，比如稀疏计算、动态图神经网络等。但这些优势目前还不足以支撑大规模商业化。工业界的态度普遍比较谨慎，更倾向于在粗粒度数据流的基础上做局部优化，而不是全面转向细粒度。
我的判断是，未来几年主流AI芯片的数据流架构会以粗粒度为主，细粒度作为补充。粗粒度保证效率和可扩展性，细粒度在特定场景下提供灵活性。这种混合方案可能是最务实的路线。
4. 数据流架构与传统架构在AI场景下的真实对比
4.1 能效比：数据搬运能耗的差距有多大
前面提到过，数据搬运的能耗远高于计算本身。数据流架构最大的优势，就是通过提高数据复用率来减少搬运。我拿几个公开的数据做个对比。
在传统GPU架构下，做一次矩阵乘法，数据需要从DRAM搬到L2，再从L2搬到共享内存，再从共享内存搬到寄存器，最后才进入计算单元。每一级搬运都有能耗开销。而在数据流架构下，数据一旦进入阵列，就可以在阵列内部多次复用，搬运次数大幅减少。
根据HotChips上一些团队的披露，在同等算力下，数据流架构的能效比可以做到传统架构的3到5倍。这个差距在边缘端尤其明显，因为边缘设备的功耗预算非常紧张。这也是为什么很多边缘AI芯片都选择了数据流架构。
4.2 灵活性：数据流架构的"硬伤"与缓解方案
数据流架构最大的问题就是灵活性差。一旦硬件固定，能支持的计算模式就受限。传统GPU虽然效率低，但什么都能算，这是它的优势。
缓解这个问题有几个方向。一是可重构，让硬件可以根据不同的计算图动态调整连接方式。二是混合架构，在数据流阵列旁边保留一些通用计算单元，处理不规则的计算任务。三是编译器优化，通过软件层面的调度来弥补硬件的不足。
HotChips上不少团队在讲可重构数据流架构，思路是在阵列中增加一些可配置的开关和路由，让数据流的路径可以根据任务动态改变。这种方案能在一定程度上提升灵活性，但代价是硬件复杂度上升，能效比会有所下降。怎么平衡，是个需要仔细权衡的问题。
4.3 编程模型：从CUDA到数据流图的范式转换
对开发者来说，数据流架构带来的最大挑战是编程模型的改变。传统GPU编程用CUDA，开发者需要显式管理线程、共享内存、同步等。而数据流架构的编程，更多是描述计算图和数据依赖关系，由编译器来完成映射和调度。
这个转换对开发者来说既是机会也是挑战。机会在于，编程抽象层次更高，开发者可以更专注于算法本身，不用太关心硬件细节。挑战在于，现有的编程习惯和工具链都需要重新适应，而且编译器的优化能力直接决定了最终性能。
从HotChips的讨论来看，业界正在推动MLIR等中间表示来统一数据流架构的编程接口。这个方向是对的，但距离成熟还有一段路要走。目前实际使用中，还是需要针对具体硬件做不少手工调优。
5. 设计数据流AI芯片时容易踩的坑
5.1 片上存储容量与阵列规模的匹配问题
设计数据流芯片时，一个常见的误区是只关注计算阵列的规模，而忽略了片上存储的匹配。阵列越大，需要的输入数据就越多，如果片上SRAM容量不够，数据就得频繁从DRAM搬运，数据流架构的优势就荡然无存了。
我见过一些设计，阵列做到了512x512甚至更大，但片上SRAM只有几MB，结果实际运行时PE利用率很低，大部分时间都在等数据。合理的比例是，片上存储容量至少要能放下一个完整计算图的所有中间数据，这样才能实现真正的数据流执行。
具体怎么算？假设你的计算图有N层，每层的输入输出数据量是D，那片上存储至少需要能容纳2D到3D的数据量，留出双缓冲的余量。这个数字在架构定义阶段就要算清楚，不然后面很难补救。
5.2 数据流调度的死锁与拥塞控制
数据流架构的调度是分布式的，每个节点独立触发。这就带来一个风险：如果多个节点的数据依赖形成环路，或者某个节点的输入长期不到齐，就可能导致死锁。这个问题在粗粒度数据流中相对好处理，但在细粒度或者混合架构中就很棘手。
解决死锁的常见方案是引入超时机制或者令牌控制。每个节点在等待输入时，如果超过一定周期还没到齐，就主动释放资源或者重新调度。另外，在NoC层面要做好拥塞控制，避免某些链路被长时间占用导致其他节点饿死。
HotChips上有团队分享过他们在NoC中引入优先级和虚拟通道的经验，效果不错。核心思路是给不同的数据流分配不同的优先级，关键路径上的数据优先传输，避免被非关键数据阻塞。
5.3 编译器映射质量对实际性能的决定性影响
数据流芯片的实际性能，很大程度上取决于编译器能不能把计算图高效地映射到硬件上。同一个硬件，不同的映射方案，性能可能差好几倍。
映射的核心问题包括：怎么切分计算图、怎么分配到不同的PE、怎么安排数据的流动顺序、怎么复用片上存储。这些问题都是NP难的组合优化问题，实际中只能用启发式算法来近似求解。
我的经验是，在架构设计阶段就要和编译器团队紧密配合，了解他们的映射策略和约束，反过来指导硬件设计。比如，如果编译器发现某种数据复用模式特别高效，那硬件就应该支持这种模式。如果硬件设计不考虑编译器的实际能力，很容易做出"理论上很美，实际跑不起来"的芯片。
6. 从HotChips看数据流架构的未来演进方向
6.1 存内计算与数据流架构的融合
存内计算（Compute-in-Memory）是另一个热门方向，它的核心思想是把计算单元嵌入到存储阵列中，彻底消除数据搬运。这个思路和数据流架构是天然互补的。
在存内计算中，数据不需要在存储和计算之间来回搬运，计算就在存储的位置完成。这和数据流架构"让数据流动起来"的思路看似相反，但实际上可以结合。一种可能的方案是，在存内计算阵列内部采用数据流调度，让数据在存储阵列中流动时顺便完成计算。这样既减少了搬运，又保持了数据流的高效性。
HotChips上已经有团队在展示这种融合方案的原型，虽然还比较早期，但方向值得关注。
6.2 光互连对数据流架构的潜在影响
数据流架构对互连带宽的要求极高，电互连在带宽密度和能耗上逐渐逼近极限。光互连被认为是下一个突破口。光互连的带宽密度可以做到电互连的几十倍，而能耗只有几分之一。
如果光互连成熟，数据流架构的扩展性会大幅提升。芯片之间、甚至芯片内部的不同模块之间，都可以通过光互连实现高带宽低延迟的通信，数据流图的规模可以做得更大，映射也更灵活。
当然，光互连目前还有成本、集成度、可靠性等问题需要解决。但从HotChips的议程来看，光互连相关的报告越来越多，产业化的步伐在加快。
6.3 数据流架构在边缘端的落地挑战
边缘端是数据流架构很有潜力的市场，因为边缘设备对功耗极其敏感，而数据流架构的能效比优势正好契合这个需求。但边缘端也有自己的挑战。
首先是成本压力。边缘芯片的出货量大，但对成本极其敏感。数据流架构的硬件复杂度相对较高，怎么在保证性能的同时控制成本，是个难题。其次是灵活性需求。边缘设备可能跑各种不同的模型，数据流架构的灵活性不足可能会限制它的适用范围。
目前来看，边缘端的数据流芯片更多是针对特定场景做定制化设计，比如智能摄像头、自动驾驶感知等。通用性更强的边缘数据流芯片，还需要在架构和编译器上做更多工作。
7. 一些实操层面的经验与建议
如果你正在做数据流AI芯片的架构设计或者评估，有几个实操层面的经验可以分享。
第一，不要一上来就追求大阵列。先从小的阵列开始验证数据流调度的正确性和效率，跑通之后再逐步扩大规模。我见过太多团队一开始就设计大芯片，结果调度逻辑没调通，整个项目卡住。
第二，编译器团队要尽早介入。硬件架构和编译器是强耦合的，不能等硬件设计完了再让编译器团队去适配。最好在架构定义阶段就让编译器团队参与，一起确定指令集、存储层次、互连协议这些关键接口。
第三，重视仿真和验证。数据流架构的调度行为很复杂，光靠静态分析很难发现所有问题。需要搭建完整的仿真环境，跑真实的计算图，观察数据流动和PE利用率。这个投入是值得的，能避免流片后的意外。
第四，关注软件生态的兼容性。数据流芯片如果只支持自己的编程模型，生态很难做起来。尽量兼容主流的AI框架和中间表示，比如PyTorch、ONNX、MLIR，降低开发者的迁移成本。
第五，功耗和性能的权衡要贯穿始终。数据流架构的优势在能效比，但如果为了追求峰值性能而牺牲能效，就本末倒置了。每个架构决策都要问一句：这个改动对能效比的影响是什么？
从HotChips这几年的趋势来看，数据流架构正在从学术概念走向工程落地，但距离大规模普及还有距离。架构设计、编译器、编程模型、生态建设，每个环节都有不少硬骨头要啃。但方向是清晰的：在AI负载成为主流的时代，数据流架构提供了一条突破内存墙和功耗墙的可行路径。对于做芯片架构的人来说，现在正是深入理解和实践数据流架构的好时机。