1. 为什么数据流架构突然成了AI芯片的香饽饽如果你这两年一直在追HotChips的议程应该能明显感觉到一个变化前几年大家还在卷TOPS数字、卷制程节点、卷HBM带宽而最近两三届越来越多的演讲把重心放在了“数据怎么流动”这件事上。这不是学术圈的自嗨而是被真实负载逼出来的转向。我最早接触数据流架构是在做边缘推理盒子的时候。当时用了一颗标称算力很漂亮的加速卡理论峰值算力在同价位里几乎无敌但实际跑一个轻量级检测网络帧率只有理论值的四分之一不到。用性能分析工具一扒发现计算单元大部分时间在等数据——权重从外部存储搬进来激活值写回去再搬下一批。算力单元的空转率高得离谱。那一刻我才真正理解为什么业内老说“AI芯片的瓶颈从来不是算力而是数据搬运”。传统冯诺依曼架构下计算和存储是分离的每做一次乘加运算往往要伴随多次寄存器堆、片上缓存、外部存储之间的数据往返。这个开销在通用计算里还能忍因为访存有局部性、有缓存层级帮你兜底。但深度学习负载不一样它的数据复用模式高度结构化卷积有滑窗复用矩阵乘有行列复用注意力机制有KV复用。这些复用模式是确定的、可预测的用通用缓存机制去处理等于用一把万能钥匙去开一把结构固定的锁效率自然上不去。数据流架构的核心思路就是把“数据怎么走”这件事从运行时动态决定变成编译时静态编排。计算单元不再是被动等指令而是数据到达就触发计算算完直接流向下一级。控制流被数据流取代指令开销被大幅压缩片上网络和存储层级围绕数据复用模式来设计。这就是为什么HotChips上那些讲数据流架构的团队演示的往往不是峰值算力而是“有效算力利用率”和“能效比”。这篇文章我想把这件事拆开讲透。不是复述某一场演讲而是从一线做芯片和用芯片的人的角度把数据流架构到底解决了什么问题、它的技术分支怎么选、落地时踩过哪些坑、以及从HotChips的趋势看下一代AI芯片会往哪走完整地聊一遍。适合正在选型加速方案的工程师、做芯片架构设计的同行以及想搞明白“为什么算力数字越来越不可信”的技术管理者。2. 数据流架构到底在“流”什么从控制流到数据流的范式切换2.1 控制流架构的隐性成本每一条指令都在收“过路费”要理解数据流架构的价值得先算清楚控制流架构在AI负载上的隐性开销。以典型的SIMD或SIMT架构为例一条乘加指令的执行背后是一整条流水线在配合取指、译码、取操作数、执行、写回。每个环节都要消耗时钟周期和能量。有研究统计过在45nm工艺下一次32位浮点乘加运算的能量成本大约是3.7pJ而一次32位数据从外部DRAM搬到片上的能量成本是640pJ差了将近170倍。也就是说你辛辛苦苦优化计算单元省下来的那点能量可能被一次多余的访存就吃回去了。更麻烦的是指令开销。在控制流架构里即使计算单元闲着取指和译码单元也得持续工作等待下一条指令。深度学习负载的算子虽然规整但算子之间的切换、边界处理、非对齐访问都会产生大量控制指令。这些指令不产生任何有效计算纯粹是“管理成本”。当模型层数加深、算子种类变多这部分开销会线性增长。我做过一个粗略的测算在一个典型的ResNet-50推理任务里如果按控制流方式调度指令相关的开销能占到总能耗的30%到40%。这个比例在更大的模型上只会更高。所以数据流架构要做的第一件事就是把这部分“过路费”砍掉。2.2 数据流架构的三种流派静态、动态与混合数据流架构不是单一方案它内部有明确的分支。按数据到达触发计算的方式大致可以分成三类。静态数据流是最彻底的一种。编译器在编译阶段就把整个计算图展开每个计算节点的触发条件、数据来源、输出去向全部确定。硬件上不需要复杂的调度器计算单元就是一张固定的流水线网络。这种方案的优点是控制逻辑极简能效比极高缺点是灵活性差一旦模型结构变了硬件可能就跑不了。适合场景固定的边缘推理比如安防摄像头里的固定检测网络。动态数据流则保留了运行时的调度能力。数据到达计算单元后由硬件调度器决定什么时候算、算完往哪送。它比静态方案灵活能处理动态shape和分支结构但调度器本身又带来了面积和功耗开销。适合云端推理这种模型多变、batch动态的场景。混合数据流是现在HotChips上比较主流的做法。粗粒度上算子之间的依赖关系在编译时确定走静态调度细粒度上算子内部的数据复用和流水线由硬件动态管理。这样既保住了能效又留了一定的灵活性。我个人的经验是混合方案在落地时最容易被接受因为它对软件栈的改动最小现有框架稍微适配就能跑。2.3 数据复用模式决定了架构的形态数据流架构的设计本质上是在匹配深度学习负载的数据复用模式。不同算子的复用维度不一样架构就得跟着变。卷积算子的复用主要在空间维度同一个卷积核在输入特征图上滑动权重被反复复用同一块输入特征图又被多个卷积核复用。所以卷积友好的数据流架构通常会把权重固定在片上让输入特征图在计算阵列里流动或者反过来。这就是Weight Stationary和Output Stationary两种经典数据流的由来。矩阵乘的复用模式又不同。Transformer里的QKV计算和大矩阵乘复用主要发生在行和列之间。一个M×K的矩阵乘N×K的矩阵A的每一行要和B的每一列做点积。这种模式下把A的行和B的列同时送到计算单元做外积复用效率最高。所以很多面向Transformer的加速器会采用Systolic Array或者类似的二维数据流。注意力机制更特殊。它的KV缓存复用是跨token的而且复用距离很长。如果按传统方式把KV存在外部存储每次注意力计算都要搬一遍带宽根本扛不住。所以现在很多方案会把KV缓存放在片上或者近存计算单元里让数据流在近存区域完成注意力计算。这也是为什么近存计算和数据流架构经常被放在一起讨论。3. HotChips上那些数据流芯片的真实设计取舍3.1 片上存储层级不是越大越好而是越“对”越好看HotChips的演讲你会发现一个有意思的现象很多数据流芯片的片上SRAM容量并不夸张有的甚至比同代GPU还小但它们的有效带宽利用率却高得多。原因在于它们不是简单堆容量而是按数据复用模式来组织存储层级。以某款面向推荐系统的数据流加速器为例它的片上存储分成三级最靠近计算阵列的是寄存器堆存当前正在参与计算的权重和激活值中间是算子级缓存存一个算子完整执行所需的数据块最外层是跨算子缓存存需要在多个算子间传递的中间结果。这个层级的划分不是拍脑袋定的而是根据推荐模型里Embedding查表、MLP、注意力等算子的数据流特征反推出来的。我自己的经验是设计存储层级时最容易犯的错是照搬CPU的缓存思路搞一个大而全的L2。AI负载的数据复用是确定性的编译器知道哪些数据会被复用、复用多少次、复用距离多远。与其让硬件去猜不如让编译器把数据生命周期算清楚硬件按需分配。这样能省下大量用于缓存标签、替换逻辑的面积和功耗。3.2 片上网络数据流架构的“高速公路”怎么修数据流架构里计算单元之间的数据搬运靠片上网络。这个网络的设计直接决定了芯片能跑多快、多省电。HotChips上常见的片上网络拓扑有Mesh、Ring、Crossbar几种各有各的适用场景。Mesh拓扑扩展性好适合计算单元数量多的阵列但跳数多的时候延迟会上去。Ring拓扑简单、面积小适合计算单元排成环形的流水线结构。Crossbar是全连接延迟最低但面积随端口数平方增长只适合小规模阵列。我参与过的一个项目里最初选了Crossbar因为延迟确实低。但后来计算阵列从8×8扩到16×16Crossbar的面积直接爆炸布线拥塞到没法收敛。最后换成了分层Mesh局部用Crossbar全局用Mesh才把面积和延迟平衡下来。这个教训是片上网络的设计必须和计算阵列的规模一起考虑不能先定网络再扩阵列。另一个容易被忽略的点是片上网络的数据位宽。位宽太窄搬运大块数据时延迟高位宽太宽布线资源和功耗又受不了。比较务实的做法是根据主要算子的数据块大小来定位宽。比如卷积算子一次搬一个特征图块那就按块大小来设计位宽而不是按单个数据元素。3.3 计算阵列的粒度粗粒度与细粒度的权衡数据流架构的计算阵列按粒度分有粗粒度和细粒度两种。粗粒度阵列里每个计算单元是一个完整的ALU或MAC能独立执行运算。细粒度阵列里计算单元更小可能只做一位或几位的操作靠大量单元并行来堆算力。粗粒度的优点是编程模型简单编译器容易映射适合通用性要求高的场景。缺点是灵活性带来的开销大每个单元都要配指令译码和寄存器面积效率上不去。细粒度的优点是能效比极高因为控制逻辑被摊薄了但编程难度大编译器要处理复杂的映射和调度。HotChips上这两派都有代表。做云端训练的倾向粗粒度因为要支持各种模型结构做边缘推理的倾向细粒度因为模型固定可以把能效压到极致。我个人的判断是未来混合粒度会成为主流粗粒度单元负责通用算子细粒度单元负责固定模式的高频算子两者通过数据流网络协同。4. 从HotChips趋势看下一代AI芯片的架构走向4.1 近存计算与数据流架构的合流近存计算这两年热度很高但它和数据流架构其实是天然一对。近存计算解决的是“数据搬得太远”的问题数据流架构解决的是“数据搬得太多”的问题。两者结合才能把访存开销压到最低。具体做法是把计算单元直接放在存储阵列旁边甚至嵌入到存储阵列内部。数据从存储读出后不经过长距离的片上网络直接在近存区域完成计算算完再写回。这样既省了搬运能量又省了搬运时间。HotChips上有团队展示过在同样的工艺和容量下近存数据流方案的能效比传统方案高出三到五倍。但近存计算也有代价。存储阵列的工艺和计算逻辑的工艺不完全兼容做在一起会牺牲存储密度或者计算频率。而且近存区域的计算能力有限复杂算子还是得回到主计算阵列。所以现阶段的务实方案是分层高频、规整、数据量大的算子放近存区域复杂、低频的算子放主阵列。4.2 编译器和硬件的协同设计成为胜负手数据流架构的能效优势很大程度上依赖编译器能不能把数据流编排好。如果编译器拉胯再好的硬件也跑不出效果。这也是为什么现在做数据流芯片的团队编译器团队往往和硬件团队一样大甚至更大。编译器的核心任务是把高层计算图映射到硬件的计算阵列和存储层级上同时决定每个数据块的生命周期和搬运路径。这个映射问题本质上是NP难的需要在编译时间和映射质量之间做权衡。常见的做法是分层映射先做算子级的粗粒度划分再做算子内的细粒度调度最后做数据块的物理分配。我踩过的一个坑是早期太依赖自动调度结果编译器生成的方案虽然能跑但数据搬运路径绕来绕去能效比手写调度差了将近一倍。后来改成“自动调度人工调优”的混合模式关键算子手工指定数据流非关键算子交给编译器才把整体效率拉上来。这个经验说明数据流架构的编译器不能追求全自动得给工程师留出手动干预的接口。4.3 动态shape和稀疏化对数据流架构的新挑战数据流架构的静态特性在面对动态shape和稀疏化时会遇到麻烦。动态shape意味着计算图在运行时才确定编译时没法完全展开稀疏化意味着有效计算只占理论计算的一小部分但数据流网络是按稠密模式设计的稀疏带来的不规则访问会打乱流水线。现在业界的应对思路有两个方向。一个是做“可重构数据流”硬件上留出可配置的路由和计算资源运行时根据shape和稀疏模式动态调整。另一个是“稀疏感知编译”编译器在编译时分析稀疏模式生成专门的数据流路径把零值跳过。前者灵活但开销大后者高效但依赖稀疏模式的稳定性。从HotChips的演讲看目前还没有完美的方案。比较务实的做法是对稀疏模式稳定的场景用稀疏感知编译对动态性强的场景用可重构数据流两者结合覆盖大部分负载。5. 落地数据流芯片时那些文档里不会写的经验5.1 软件栈的适配成本往往被严重低估很多团队在评估数据流芯片时只看硬件指标忽略了软件栈的适配成本。我见过不止一个项目硬件流片成功指标漂亮但因为没有配套的编译器和运行时实际部署拖了一年多。数据流芯片的软件栈至少需要三层图编译器、算子库、运行时调度。图编译器负责把框架模型转成硬件能执行的指令流算子库提供常用算子的高效实现运行时负责内存管理、任务调度和同步。这三层缺一不可而且每一层都要针对硬件的数据流特性做深度优化。我的建议是在硬件设计阶段就让软件团队介入把编译器的约束反馈给硬件。比如编译器需要什么样的指令格式、需要多大的片上缓存来存中间结果、需要什么样的同步机制。这些如果等到硬件定型再考虑改起来代价极大。5.2 热和功耗的坑数据流架构不是免死金牌数据流架构能效比高但不代表没有热和功耗问题。计算阵列的局部热点、片上网络的拥塞、存储单元的漏电这些在数据流架构里同样存在甚至因为集成度高而更集中。我遇到过的一个典型问题是计算阵列的某一块区域因为数据流映射不均长期高负载运行温度比周围高出十几度导致频率被迫降下来整体性能反而受影响。解决办法是在编译器里加入热感知调度把计算任务均匀分布到阵列上避免局部过热。另一个坑是片上网络的功耗。数据流架构的数据搬运量大如果网络设计不当搬运功耗能占到总功耗的一半以上。优化手段包括用更短的布线、降低翻转率、在空闲时关断部分网络。这些都需要在架构设计阶段就考虑进去。5.3 从Demo到量产一致性和可靠性才是真正的门槛在实验室跑通Demo和在量产环境稳定运行中间隔着巨大的鸿沟。数据流芯片的量产挑战主要来自一致性和可靠性。一致性方面数据流架构的静态调度意味着如果某个计算单元因为工艺偏差或老化导致延迟变化整个流水线可能都会受影响。解决办法是加入弹性缓冲和动态补偿机制让流水线能容忍一定程度的延迟波动。可靠性方面数据流芯片的片上存储和计算单元密集软错误率比通用芯片高。需要加入ECC、冗余计算、定期自检等机制。这些机制会带来面积和功耗开销但为了量产可靠性这笔开销省不得。6. 我个人对数据流架构芯片选型的一点判断如果你正在做加速方案选型面对一堆标称算力漂亮的芯片我的建议是先把“有效算力利用率”和“能效比”这两个指标问清楚。数据流架构芯片的优势不在峰值算力而在实际负载下的效率。让厂商提供目标模型的实测数据而不是跑分数据。另外软件栈的成熟度比硬件指标更重要。一个能效比稍低但编译器成熟的方案实际落地速度可能比一个指标漂亮但软件难用的方案快得多。我自己的经验是软件栈的适配成本通常是硬件成本的数倍选型时一定要把这块算进去。最后数据流架构不是万能药。它适合数据复用模式确定、算子结构规整的负载。如果你的模型动态性极强、算子种类极其杂乱传统架构可能反而更合适。架构选型没有银弹只有匹配。
1. 为什么数据流架构突然成了AI芯片的香饽饽如果你这两年一直在追HotChips的议程应该能明显感觉到一个变化前几年大家还在卷TOPS数字、卷制程节点、卷HBM带宽而最近两三届越来越多的演讲把重心放在了“数据怎么流动”这件事上。这不是学术圈的自嗨而是被真实负载逼出来的转向。我最早接触数据流架构是在做边缘推理盒子的时候。当时用了一颗标称算力很漂亮的加速卡理论峰值算力在同价位里几乎无敌但实际跑一个轻量级检测网络帧率只有理论值的四分之一不到。用性能分析工具一扒发现计算单元大部分时间在等数据——权重从外部存储搬进来激活值写回去再搬下一批。算力单元的空转率高得离谱。那一刻我才真正理解为什么业内老说“AI芯片的瓶颈从来不是算力而是数据搬运”。传统冯诺依曼架构下计算和存储是分离的每做一次乘加运算往往要伴随多次寄存器堆、片上缓存、外部存储之间的数据往返。这个开销在通用计算里还能忍因为访存有局部性、有缓存层级帮你兜底。但深度学习负载不一样它的数据复用模式高度结构化卷积有滑窗复用矩阵乘有行列复用注意力机制有KV复用。这些复用模式是确定的、可预测的用通用缓存机制去处理等于用一把万能钥匙去开一把结构固定的锁效率自然上不去。数据流架构的核心思路就是把“数据怎么走”这件事从运行时动态决定变成编译时静态编排。计算单元不再是被动等指令而是数据到达就触发计算算完直接流向下一级。控制流被数据流取代指令开销被大幅压缩片上网络和存储层级围绕数据复用模式来设计。这就是为什么HotChips上那些讲数据流架构的团队演示的往往不是峰值算力而是“有效算力利用率”和“能效比”。这篇文章我想把这件事拆开讲透。不是复述某一场演讲而是从一线做芯片和用芯片的人的角度把数据流架构到底解决了什么问题、它的技术分支怎么选、落地时踩过哪些坑、以及从HotChips的趋势看下一代AI芯片会往哪走完整地聊一遍。适合正在选型加速方案的工程师、做芯片架构设计的同行以及想搞明白“为什么算力数字越来越不可信”的技术管理者。2. 数据流架构到底在“流”什么从控制流到数据流的范式切换2.1 控制流架构的隐性成本每一条指令都在收“过路费”要理解数据流架构的价值得先算清楚控制流架构在AI负载上的隐性开销。以典型的SIMD或SIMT架构为例一条乘加指令的执行背后是一整条流水线在配合取指、译码、取操作数、执行、写回。每个环节都要消耗时钟周期和能量。有研究统计过在45nm工艺下一次32位浮点乘加运算的能量成本大约是3.7pJ而一次32位数据从外部DRAM搬到片上的能量成本是640pJ差了将近170倍。也就是说你辛辛苦苦优化计算单元省下来的那点能量可能被一次多余的访存就吃回去了。更麻烦的是指令开销。在控制流架构里即使计算单元闲着取指和译码单元也得持续工作等待下一条指令。深度学习负载的算子虽然规整但算子之间的切换、边界处理、非对齐访问都会产生大量控制指令。这些指令不产生任何有效计算纯粹是“管理成本”。当模型层数加深、算子种类变多这部分开销会线性增长。我做过一个粗略的测算在一个典型的ResNet-50推理任务里如果按控制流方式调度指令相关的开销能占到总能耗的30%到40%。这个比例在更大的模型上只会更高。所以数据流架构要做的第一件事就是把这部分“过路费”砍掉。2.2 数据流架构的三种流派静态、动态与混合数据流架构不是单一方案它内部有明确的分支。按数据到达触发计算的方式大致可以分成三类。静态数据流是最彻底的一种。编译器在编译阶段就把整个计算图展开每个计算节点的触发条件、数据来源、输出去向全部确定。硬件上不需要复杂的调度器计算单元就是一张固定的流水线网络。这种方案的优点是控制逻辑极简能效比极高缺点是灵活性差一旦模型结构变了硬件可能就跑不了。适合场景固定的边缘推理比如安防摄像头里的固定检测网络。动态数据流则保留了运行时的调度能力。数据到达计算单元后由硬件调度器决定什么时候算、算完往哪送。它比静态方案灵活能处理动态shape和分支结构但调度器本身又带来了面积和功耗开销。适合云端推理这种模型多变、batch动态的场景。混合数据流是现在HotChips上比较主流的做法。粗粒度上算子之间的依赖关系在编译时确定走静态调度细粒度上算子内部的数据复用和流水线由硬件动态管理。这样既保住了能效又留了一定的灵活性。我个人的经验是混合方案在落地时最容易被接受因为它对软件栈的改动最小现有框架稍微适配就能跑。2.3 数据复用模式决定了架构的形态数据流架构的设计本质上是在匹配深度学习负载的数据复用模式。不同算子的复用维度不一样架构就得跟着变。卷积算子的复用主要在空间维度同一个卷积核在输入特征图上滑动权重被反复复用同一块输入特征图又被多个卷积核复用。所以卷积友好的数据流架构通常会把权重固定在片上让输入特征图在计算阵列里流动或者反过来。这就是Weight Stationary和Output Stationary两种经典数据流的由来。矩阵乘的复用模式又不同。Transformer里的QKV计算和大矩阵乘复用主要发生在行和列之间。一个M×K的矩阵乘N×K的矩阵A的每一行要和B的每一列做点积。这种模式下把A的行和B的列同时送到计算单元做外积复用效率最高。所以很多面向Transformer的加速器会采用Systolic Array或者类似的二维数据流。注意力机制更特殊。它的KV缓存复用是跨token的而且复用距离很长。如果按传统方式把KV存在外部存储每次注意力计算都要搬一遍带宽根本扛不住。所以现在很多方案会把KV缓存放在片上或者近存计算单元里让数据流在近存区域完成注意力计算。这也是为什么近存计算和数据流架构经常被放在一起讨论。3. HotChips上那些数据流芯片的真实设计取舍3.1 片上存储层级不是越大越好而是越“对”越好看HotChips的演讲你会发现一个有意思的现象很多数据流芯片的片上SRAM容量并不夸张有的甚至比同代GPU还小但它们的有效带宽利用率却高得多。原因在于它们不是简单堆容量而是按数据复用模式来组织存储层级。以某款面向推荐系统的数据流加速器为例它的片上存储分成三级最靠近计算阵列的是寄存器堆存当前正在参与计算的权重和激活值中间是算子级缓存存一个算子完整执行所需的数据块最外层是跨算子缓存存需要在多个算子间传递的中间结果。这个层级的划分不是拍脑袋定的而是根据推荐模型里Embedding查表、MLP、注意力等算子的数据流特征反推出来的。我自己的经验是设计存储层级时最容易犯的错是照搬CPU的缓存思路搞一个大而全的L2。AI负载的数据复用是确定性的编译器知道哪些数据会被复用、复用多少次、复用距离多远。与其让硬件去猜不如让编译器把数据生命周期算清楚硬件按需分配。这样能省下大量用于缓存标签、替换逻辑的面积和功耗。3.2 片上网络数据流架构的“高速公路”怎么修数据流架构里计算单元之间的数据搬运靠片上网络。这个网络的设计直接决定了芯片能跑多快、多省电。HotChips上常见的片上网络拓扑有Mesh、Ring、Crossbar几种各有各的适用场景。Mesh拓扑扩展性好适合计算单元数量多的阵列但跳数多的时候延迟会上去。Ring拓扑简单、面积小适合计算单元排成环形的流水线结构。Crossbar是全连接延迟最低但面积随端口数平方增长只适合小规模阵列。我参与过的一个项目里最初选了Crossbar因为延迟确实低。但后来计算阵列从8×8扩到16×16Crossbar的面积直接爆炸布线拥塞到没法收敛。最后换成了分层Mesh局部用Crossbar全局用Mesh才把面积和延迟平衡下来。这个教训是片上网络的设计必须和计算阵列的规模一起考虑不能先定网络再扩阵列。另一个容易被忽略的点是片上网络的数据位宽。位宽太窄搬运大块数据时延迟高位宽太宽布线资源和功耗又受不了。比较务实的做法是根据主要算子的数据块大小来定位宽。比如卷积算子一次搬一个特征图块那就按块大小来设计位宽而不是按单个数据元素。3.3 计算阵列的粒度粗粒度与细粒度的权衡数据流架构的计算阵列按粒度分有粗粒度和细粒度两种。粗粒度阵列里每个计算单元是一个完整的ALU或MAC能独立执行运算。细粒度阵列里计算单元更小可能只做一位或几位的操作靠大量单元并行来堆算力。粗粒度的优点是编程模型简单编译器容易映射适合通用性要求高的场景。缺点是灵活性带来的开销大每个单元都要配指令译码和寄存器面积效率上不去。细粒度的优点是能效比极高因为控制逻辑被摊薄了但编程难度大编译器要处理复杂的映射和调度。HotChips上这两派都有代表。做云端训练的倾向粗粒度因为要支持各种模型结构做边缘推理的倾向细粒度因为模型固定可以把能效压到极致。我个人的判断是未来混合粒度会成为主流粗粒度单元负责通用算子细粒度单元负责固定模式的高频算子两者通过数据流网络协同。4. 从HotChips趋势看下一代AI芯片的架构走向4.1 近存计算与数据流架构的合流近存计算这两年热度很高但它和数据流架构其实是天然一对。近存计算解决的是“数据搬得太远”的问题数据流架构解决的是“数据搬得太多”的问题。两者结合才能把访存开销压到最低。具体做法是把计算单元直接放在存储阵列旁边甚至嵌入到存储阵列内部。数据从存储读出后不经过长距离的片上网络直接在近存区域完成计算算完再写回。这样既省了搬运能量又省了搬运时间。HotChips上有团队展示过在同样的工艺和容量下近存数据流方案的能效比传统方案高出三到五倍。但近存计算也有代价。存储阵列的工艺和计算逻辑的工艺不完全兼容做在一起会牺牲存储密度或者计算频率。而且近存区域的计算能力有限复杂算子还是得回到主计算阵列。所以现阶段的务实方案是分层高频、规整、数据量大的算子放近存区域复杂、低频的算子放主阵列。4.2 编译器和硬件的协同设计成为胜负手数据流架构的能效优势很大程度上依赖编译器能不能把数据流编排好。如果编译器拉胯再好的硬件也跑不出效果。这也是为什么现在做数据流芯片的团队编译器团队往往和硬件团队一样大甚至更大。编译器的核心任务是把高层计算图映射到硬件的计算阵列和存储层级上同时决定每个数据块的生命周期和搬运路径。这个映射问题本质上是NP难的需要在编译时间和映射质量之间做权衡。常见的做法是分层映射先做算子级的粗粒度划分再做算子内的细粒度调度最后做数据块的物理分配。我踩过的一个坑是早期太依赖自动调度结果编译器生成的方案虽然能跑但数据搬运路径绕来绕去能效比手写调度差了将近一倍。后来改成“自动调度人工调优”的混合模式关键算子手工指定数据流非关键算子交给编译器才把整体效率拉上来。这个经验说明数据流架构的编译器不能追求全自动得给工程师留出手动干预的接口。4.3 动态shape和稀疏化对数据流架构的新挑战数据流架构的静态特性在面对动态shape和稀疏化时会遇到麻烦。动态shape意味着计算图在运行时才确定编译时没法完全展开稀疏化意味着有效计算只占理论计算的一小部分但数据流网络是按稠密模式设计的稀疏带来的不规则访问会打乱流水线。现在业界的应对思路有两个方向。一个是做“可重构数据流”硬件上留出可配置的路由和计算资源运行时根据shape和稀疏模式动态调整。另一个是“稀疏感知编译”编译器在编译时分析稀疏模式生成专门的数据流路径把零值跳过。前者灵活但开销大后者高效但依赖稀疏模式的稳定性。从HotChips的演讲看目前还没有完美的方案。比较务实的做法是对稀疏模式稳定的场景用稀疏感知编译对动态性强的场景用可重构数据流两者结合覆盖大部分负载。5. 落地数据流芯片时那些文档里不会写的经验5.1 软件栈的适配成本往往被严重低估很多团队在评估数据流芯片时只看硬件指标忽略了软件栈的适配成本。我见过不止一个项目硬件流片成功指标漂亮但因为没有配套的编译器和运行时实际部署拖了一年多。数据流芯片的软件栈至少需要三层图编译器、算子库、运行时调度。图编译器负责把框架模型转成硬件能执行的指令流算子库提供常用算子的高效实现运行时负责内存管理、任务调度和同步。这三层缺一不可而且每一层都要针对硬件的数据流特性做深度优化。我的建议是在硬件设计阶段就让软件团队介入把编译器的约束反馈给硬件。比如编译器需要什么样的指令格式、需要多大的片上缓存来存中间结果、需要什么样的同步机制。这些如果等到硬件定型再考虑改起来代价极大。5.2 热和功耗的坑数据流架构不是免死金牌数据流架构能效比高但不代表没有热和功耗问题。计算阵列的局部热点、片上网络的拥塞、存储单元的漏电这些在数据流架构里同样存在甚至因为集成度高而更集中。我遇到过的一个典型问题是计算阵列的某一块区域因为数据流映射不均长期高负载运行温度比周围高出十几度导致频率被迫降下来整体性能反而受影响。解决办法是在编译器里加入热感知调度把计算任务均匀分布到阵列上避免局部过热。另一个坑是片上网络的功耗。数据流架构的数据搬运量大如果网络设计不当搬运功耗能占到总功耗的一半以上。优化手段包括用更短的布线、降低翻转率、在空闲时关断部分网络。这些都需要在架构设计阶段就考虑进去。5.3 从Demo到量产一致性和可靠性才是真正的门槛在实验室跑通Demo和在量产环境稳定运行中间隔着巨大的鸿沟。数据流芯片的量产挑战主要来自一致性和可靠性。一致性方面数据流架构的静态调度意味着如果某个计算单元因为工艺偏差或老化导致延迟变化整个流水线可能都会受影响。解决办法是加入弹性缓冲和动态补偿机制让流水线能容忍一定程度的延迟波动。可靠性方面数据流芯片的片上存储和计算单元密集软错误率比通用芯片高。需要加入ECC、冗余计算、定期自检等机制。这些机制会带来面积和功耗开销但为了量产可靠性这笔开销省不得。6. 我个人对数据流架构芯片选型的一点判断如果你正在做加速方案选型面对一堆标称算力漂亮的芯片我的建议是先把“有效算力利用率”和“能效比”这两个指标问清楚。数据流架构芯片的优势不在峰值算力而在实际负载下的效率。让厂商提供目标模型的实测数据而不是跑分数据。另外软件栈的成熟度比硬件指标更重要。一个能效比稍低但编译器成熟的方案实际落地速度可能比一个指标漂亮但软件难用的方案快得多。我自己的经验是软件栈的适配成本通常是硬件成本的数倍选型时一定要把这块算进去。最后数据流架构不是万能药。它适合数据复用模式确定、算子结构规整的负载。如果你的模型动态性极强、算子种类极其杂乱传统架构可能反而更合适。架构选型没有银弹只有匹配。
