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负载成为主流的时代数据流架构提供了一条突破内存墙和功耗墙的可行路径。对于做芯片架构的人来说现在正是深入理解和实践数据流架构的好时机。 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负载成为主流的时代数据流架构提供了一条突破内存墙和功耗墙的可行路径。对于做芯片架构的人来说现在正是深入理解和实践数据流架构的好时机。