1. 从HotChips现场聊起为什么数据流架构突然成了香饽饽今年HotChips的议程一出来我朋友圈里做芯片架构的几位老哥就炸了锅。往年大家盯的都是制程、封装、HBM带宽这些硬指标今年画风明显变了——好几场重头戏都压在数据流架构Dataflow Architecture上从初创公司到头部大厂不约而同地在讲同一件事怎么让数据在芯片里少跑冤枉路。我在这个圈子里摸爬滚打十来年经历过通用处理器一统天下的年代也看着GPU靠着并行计算一步步吃掉AI训练市场。但这两年跟做推理芯片的朋友聊天大家普遍有个共识传统的冯·诺依曼架构在AI负载面前越来越像让一个快递员每次送一件货还要回仓库重新取——算力堆得再高数据搬运的能耗和延迟先把收益吃掉了。数据流架构的核心思路就是让数据像流水线上的零件一样到了工位就加工加工完直接流向下一个工位而不是反复回仓库排队。这篇内容我打算把HotChips上几个有代表性的数据流架构方案拆开揉碎结合我自己做架构评估时踩过的坑讲清楚三个问题数据流架构到底解决了什么传统架构解决不了的问题、它在实际芯片设计里怎么落地、以及如果你要评估或选型这类芯片该盯哪些关键指标。适合做AI芯片架构、编译器、系统软件或者正在做推理硬件选型的同学参考。里面涉及的具体参数和实现细节一部分来自公开演讲资料一部分是我基于常见工程实践做的合理推演我会明确标注哪些是推测。2. 数据流架构到底在解决什么问题2.1 冯·诺依曼瓶颈在AI负载下的真实代价先算一笔账这样后面聊架构选择时心里有数。假设一个典型的矩阵乘法MNK4096FP16精度。计算量是2×4096³≈1.37×10¹¹次浮点运算。如果芯片峰值算力是256 TFLOPS理论计算时间约0.54毫秒。但数据量呢三个矩阵各4096²×2字节32MB加起来96MB。如果这些数据每次都要从片外HBM搬进来按HBM3约819GB/s带宽算光搬数据就要约117微秒。看起来还好问题是实际计算中数据复用率远没有这么理想很多算子需要反复读写中间结果实际数据搬运量可能是理论值的3到5倍搬运时间直接超过计算时间。这就是冯·诺依曼瓶颈的具象化计算单元和存储单元分离数据在两者之间来回穿梭能耗上搬运一个32位数据的成本可能是做一次乘加的几十倍。在7nm工艺下一次32位浮点乘加大约消耗0.1到0.2皮焦耳而从片外DRAM读一个32位数据要消耗几十皮焦耳差了整整两个数量级。所以架构师们拼命做片上缓存、做数据复用本质上都是在跟这个能耗差做斗争。2.2 数据流架构的核心思想让计算跟着数据走数据流架构的哲学跟传统控制流架构正好反过来。控制流架构是程序计数器指到哪数据就从存储里取出来算数据是被动的数据流架构是数据准备好了就触发计算计算单元等着数据上门控制是分布式的、由数据可用性驱动的。打个比方控制流架构像传统银行柜台客户数据排队等柜员计算单元叫号柜员按固定流程一个个处理。数据流架构更像自助餐厅的流水线食材数据在传送带上流动每个工位计算单元看到自己需要的食材到了就动手加工加工完放回传送带继续往下走。没有中央调度每个工位自己判断我能不能干活。这个思路在AI负载上特别对路因为神经网络的计算图本身就是数据依赖明确的——卷积层的输出就是下一层的输入注意力机制里Q、K、V的依赖关系也是固定的。数据流架构可以把整个计算图映射成一条或几条数据通路数据在片上流动的过程中被逐级处理中间结果尽量不落回片外存储。2.3 跟脉动阵列、存内计算的区别与联系这里容易混淆我梳理一下。脉动阵列Systolic Array其实是数据流思想的一种具体实现TPU就是典型代表。它的特点是数据像心跳一样有节奏地在PE阵列中流动每个PE做乘加后把结果传给邻居。但脉动阵列通常只适合规则的矩阵运算遇到非规则计算图或者动态shape就抓瞎。存内计算Compute-in-Memory走得更远直接把计算单元嵌到存储阵列里从根本上消除搬运。但存内计算目前受限于模拟计算精度、工艺成熟度离大规模量产还有距离。数据流架构介于两者之间它不像脉动阵列那么死板可以支持更灵活的计算图又不像存内计算那样对工艺要求苛刻用成熟数字工艺就能实现。HotChips上几个方案本质上都是在灵活性和能效之间找平衡点。3. HotChips上值得细看的数据流架构方案拆解3.1 粗粒度数据流以计算块为调度单位粗粒度数据流Coarse-Grained Dataflow的思路是把多个计算单元打包成一个计算块块内可以是脉动阵列或者向量单元块间通过片上网络NoC传递数据。调度粒度是块级别的编译器把计算图切分成若干块决定哪块先算、数据往哪流。这种方案的好处是调度开销小编译器不用管块内每个PE怎么动只管块间依赖。坏处是灵活性受限如果某个算子没法整齐地切成块就会出现计算块利用率低的情况。我在评估这类架构时第一件事就是看它的编译器能不能把主流模型ResNet、BERT、LLaMA的算子都映射成高效的块划分。有些方案在卷积上表现很好一到Transformer的注意力机制就露怯因为注意力里的softmax和动态shape对块划分很不友好。HotChips上有家公司的方案我印象很深他们做了一个可重构的计算块块内PE之间的连接可以通过配置改变这样同一个硬件既能高效跑卷积也能跑注意力。代价是配置开销和面积增加但换来的是模型覆盖率大幅提升。这个取舍在推理芯片里很常见——面积换灵活性只要面积不是太离谱客户通常愿意买单。3.2 细粒度数据流每个PE独立触发细粒度数据流走的是另一个极端每个PE都有自己的指令队列或者触发条件数据到了就执行。这有点像数据流计算机的现代版理论上灵活性最高能支持任意计算图。但实际做起来调度和同步的开销会吃掉不少收益。我见过一个细粒度方案每个PE配了一个小的FIFO和触发逻辑PE之间通过握手信号传递数据。好处是天然支持流水线数据在PE间流动时计算自动重叠。问题是当计算图有分支或者循环时握手逻辑会变得复杂死锁风险也上来了。他们的解决办法是在编译器层面做静态调度把动态行为尽量转成静态的减少运行时握手。这类架构对编译器的要求极高编译器要能做算子融合、流水线调度、缓冲区分配。我个人的经验是评估细粒度数据流芯片编译器团队的实力比硬件参数更重要。硬件再漂亮编译器映射不出高效代码实际性能可能连理论峰值的20%都不到。3.3 混合方案数据流加控制流的务实选择纯数据流架构在通用性上始终有短板所以HotChips上更多看到的是混合方案——主体用数据流但保留一定的控制流能力处理非规则部分。比如主计算阵列用数据流驱动但外面套一个标量核做控制、做地址计算、处理边界情况。这种务实做法我很认同。纯数据流听起来优雅但实际模型里总有那么些算子比如动态shape的reshape、条件分支不适合数据流。硬要用数据流实现要么效率极低要么编译器复杂度爆炸。留一个控制流后门让这些边角料跑在标量核上整体收益反而更高。选型时我会重点看这个控制流部分的性能。有些方案标量核太弱成了整个芯片的瓶颈有些方案标量核和主阵列的协同做得不好数据在两者之间来回倒腾把数据流省下来的能耗又吐回去了。4. 数据流架构芯片的实操评估要点4.1 算力利用率别被峰值算力忽悠数据流架构芯片的峰值算力通常标得很高但实际利用率才是关键。我评估时必看三个指标一是典型模型下的实测吞吐二是不同batch size下的利用率曲线三是算子覆盖率。实测吞吐最好拿真实模型跑ResNet-50、BERT-Base、LLaMA-7B这几个是标配。有些芯片在ResNet上能跑到峰值的70%一到BERT就掉到30%因为注意力机制的数据流映射没做好。batch size的影响也很大数据流架构通常在小batch下效率更高因为延迟低但大batch下如果片上缓存不够数据反复进出片外利用率会断崖式下跌。算子覆盖率指的是芯片原生支持多少种算子。数据流架构通常对卷积、矩阵乘、激活函数支持很好但对一些特殊算子如LayerNorm、Softmax可能需要回退到标量核性能损失明显。评估时要问清楚哪些算子是原生的哪些是回退的回退的代价有多大。4.2 片上存储层次数据流架构的命门数据流架构的能效优势很大程度上来自减少片外访问所以片上存储的设计至关重要。我会关注几个点片上SRAM的总容量、带宽、以及存储层次的组织方式。总容量决定了能缓存多大的中间结果。如果模型的一层输出有几十MB片上只有几MB SRAM那数据流到一半就得写回片外优势大打折扣。带宽决定了数据在片上流动的速度如果NoC带宽不够计算单元会饿死。存储层次的组织方式则影响编译器的调度难度层次越多、越复杂编译器越难做全局优化。我见过一个方案片上SRAM容量很大但带宽不足结果计算阵列经常等数据实测性能只有理论值的一半。另一个方案带宽很足但容量小大模型跑起来频繁换入换出能效比反而不如传统架构。所以容量和带宽要匹配不能偏废。4.3 编译器与软件栈决定实际可用性数据流架构芯片的软件栈通常比传统架构复杂因为编译器要做的事情更多算子融合、数据流图构建、缓冲区分配、流水线调度。我评估时会把编译器成熟度放在跟硬件同等重要的位置。具体看几个方面一是支持的框架和模型格式PyTorch、TensorFlow、ONNX这些主流格式能不能直接导入二是算子库的丰富程度常用算子有没有手写优化版本三是调试和性能分析工具能不能看到数据流图、每个算子的耗时、片上缓存的占用情况。有个坑我踩过某款数据流芯片的编译器对动态shape支持很差模型里有个动态reshape编译器直接报错只能改成静态shape重新训练。这种限制在选型时一定要问清楚不然模型部署时才发现就晚了。5. 常见问题与排查技巧实录5.1 数据流架构芯片跑不满算力怎么排查这是最常见的问题。我的排查顺序是先看数据搬运是不是瓶颈用性能分析工具看片外带宽利用率如果接近峰值说明数据供给跟不上要么是片上缓存不够要么是数据复用没做好。再看计算阵列利用率如果阵列经常空闲可能是数据依赖导致的等待检查数据流图的并行度够不够。最后看编译器生成的代码有没有明显的低效模式比如频繁的同步、不必要的缓冲区拷贝。有个技巧把模型逐层跑看哪一层的利用率突然掉下来。通常问题就出在那层。我遇到过一层Group Convolution利用率只有15%原因是编译器没做好分组数据的调度后来手动改了数据布局才解决。5.2 精度对不齐怎么办数据流架构芯片通常支持INT8、FP16等精度但不同芯片的量化策略不同精度对齐是个麻烦事。我的经验是先在浮点模型上验证功能正确性再逐步量化。量化时不要一刀切敏感层如第一层和最后一层保持高精度中间层可以激进一些。如果芯片支持混合精度尽量用起来。有些数据流架构对混合精度的支持很好不同层可以用不同精度编译器和硬件自动处理转换。但要注意转换开销如果转换太频繁收益可能被抵消。5.3 多卡互联时的数据流一致性数据流架构在多卡场景下有个特殊问题数据流是分布式的跨卡的数据依赖怎么保证一致性。有些方案靠编译器做全局调度把跨卡通信也纳入数据流图有些方案靠运行时库做同步。前者效率高但编译器复杂后者灵活但有运行时开销。我评估时会看跨卡通信的带宽和延迟以及是否支持通信和计算的重叠。如果通信不能重叠多卡扩展效率会很差。实测下来支持通信计算重叠的方案4卡扩展效率能到3.5倍以上不支持的只有2.5倍左右。6. 数据流架构的适用边界与选型建议6.1 什么场景适合数据流架构数据流架构不是万能的它有明确的甜点区。推理场景、模型结构相对固定、对能效和延迟敏感的应用是数据流架构的主场。比如边缘端的视觉推理、数据中心的推荐系统推理、自动驾驶的感知模型这些场景模型迭代没那么快数据流架构可以把模型结构固化到硬件里换来极致的能效。训练场景目前还是GPU的天下因为训练需要高精度、大batch、频繁的权重更新数据流架构的灵活性不足以支撑。但有些方案在做训练加速的探索比如把反向传播也映射成数据流这个方向值得关注。6.2 选型时的关键决策点如果你在选型我建议按这个优先级排序第一看模型覆盖率芯片能不能高效跑你所有的模型第二看编译器成熟度能不能快速部署和调优第三看能效和延迟这是数据流架构的核心价值第四看生态和工具链长期维护成本很重要。不要只看峰值算力那个数字参考价值有限。也不要只看单算子性能实际模型是算子组合端到端性能才是真的。最好能拿到开发板或者云上实例跑自己的模型实测。6.3 未来演进方向的一些观察从HotChips的趋势看数据流架构正在往两个方向走一是更粗粒度的可重构用更大的计算块降低调度开销二是更紧密的存算一体把数据流和存内计算结合进一步消除搬运。还有一个方向是Chiplet把数据流计算块做成小芯片通过先进封装拼成大芯片这样既能保证良率又能灵活扩展。我个人比较看好可重构数据流加Chiplet的组合。可重构解决灵活性问题Chiplet解决扩展性问题两者结合可能是下一代AI芯片的主流形态。当然这中间还有不少工程挑战比如Chiplet间的数据流一致性、可重构配置的编译优化都需要时间打磨。最后分享一个我在实际项目中的体会数据流架构芯片的评估一定要带着真实模型去跑不要只看纸面参数。我见过太多参数漂亮但实际跑起来各种问题的方案。另外编译器的迭代速度很关键选型时不仅要看当前版本的能力还要看团队的更新频率和响应速度。一个活跃的编译器团队能让同一块硬件在半年内性能提升30%以上这个价值往往被低估。
HotChips 2024数据流架构深度拆解：从冯·诺依曼瓶颈到AI芯片选型实操
1. 从HotChips现场聊起为什么数据流架构突然成了香饽饽今年HotChips的议程一出来我朋友圈里做芯片架构的几位老哥就炸了锅。往年大家盯的都是制程、封装、HBM带宽这些硬指标今年画风明显变了——好几场重头戏都压在数据流架构Dataflow Architecture上从初创公司到头部大厂不约而同地在讲同一件事怎么让数据在芯片里少跑冤枉路。我在这个圈子里摸爬滚打十来年经历过通用处理器一统天下的年代也看着GPU靠着并行计算一步步吃掉AI训练市场。但这两年跟做推理芯片的朋友聊天大家普遍有个共识传统的冯·诺依曼架构在AI负载面前越来越像让一个快递员每次送一件货还要回仓库重新取——算力堆得再高数据搬运的能耗和延迟先把收益吃掉了。数据流架构的核心思路就是让数据像流水线上的零件一样到了工位就加工加工完直接流向下一个工位而不是反复回仓库排队。这篇内容我打算把HotChips上几个有代表性的数据流架构方案拆开揉碎结合我自己做架构评估时踩过的坑讲清楚三个问题数据流架构到底解决了什么传统架构解决不了的问题、它在实际芯片设计里怎么落地、以及如果你要评估或选型这类芯片该盯哪些关键指标。适合做AI芯片架构、编译器、系统软件或者正在做推理硬件选型的同学参考。里面涉及的具体参数和实现细节一部分来自公开演讲资料一部分是我基于常见工程实践做的合理推演我会明确标注哪些是推测。2. 数据流架构到底在解决什么问题2.1 冯·诺依曼瓶颈在AI负载下的真实代价先算一笔账这样后面聊架构选择时心里有数。假设一个典型的矩阵乘法MNK4096FP16精度。计算量是2×4096³≈1.37×10¹¹次浮点运算。如果芯片峰值算力是256 TFLOPS理论计算时间约0.54毫秒。但数据量呢三个矩阵各4096²×2字节32MB加起来96MB。如果这些数据每次都要从片外HBM搬进来按HBM3约819GB/s带宽算光搬数据就要约117微秒。看起来还好问题是实际计算中数据复用率远没有这么理想很多算子需要反复读写中间结果实际数据搬运量可能是理论值的3到5倍搬运时间直接超过计算时间。这就是冯·诺依曼瓶颈的具象化计算单元和存储单元分离数据在两者之间来回穿梭能耗上搬运一个32位数据的成本可能是做一次乘加的几十倍。在7nm工艺下一次32位浮点乘加大约消耗0.1到0.2皮焦耳而从片外DRAM读一个32位数据要消耗几十皮焦耳差了整整两个数量级。所以架构师们拼命做片上缓存、做数据复用本质上都是在跟这个能耗差做斗争。2.2 数据流架构的核心思想让计算跟着数据走数据流架构的哲学跟传统控制流架构正好反过来。控制流架构是程序计数器指到哪数据就从存储里取出来算数据是被动的数据流架构是数据准备好了就触发计算计算单元等着数据上门控制是分布式的、由数据可用性驱动的。打个比方控制流架构像传统银行柜台客户数据排队等柜员计算单元叫号柜员按固定流程一个个处理。数据流架构更像自助餐厅的流水线食材数据在传送带上流动每个工位计算单元看到自己需要的食材到了就动手加工加工完放回传送带继续往下走。没有中央调度每个工位自己判断我能不能干活。这个思路在AI负载上特别对路因为神经网络的计算图本身就是数据依赖明确的——卷积层的输出就是下一层的输入注意力机制里Q、K、V的依赖关系也是固定的。数据流架构可以把整个计算图映射成一条或几条数据通路数据在片上流动的过程中被逐级处理中间结果尽量不落回片外存储。2.3 跟脉动阵列、存内计算的区别与联系这里容易混淆我梳理一下。脉动阵列Systolic Array其实是数据流思想的一种具体实现TPU就是典型代表。它的特点是数据像心跳一样有节奏地在PE阵列中流动每个PE做乘加后把结果传给邻居。但脉动阵列通常只适合规则的矩阵运算遇到非规则计算图或者动态shape就抓瞎。存内计算Compute-in-Memory走得更远直接把计算单元嵌到存储阵列里从根本上消除搬运。但存内计算目前受限于模拟计算精度、工艺成熟度离大规模量产还有距离。数据流架构介于两者之间它不像脉动阵列那么死板可以支持更灵活的计算图又不像存内计算那样对工艺要求苛刻用成熟数字工艺就能实现。HotChips上几个方案本质上都是在灵活性和能效之间找平衡点。3. HotChips上值得细看的数据流架构方案拆解3.1 粗粒度数据流以计算块为调度单位粗粒度数据流Coarse-Grained Dataflow的思路是把多个计算单元打包成一个计算块块内可以是脉动阵列或者向量单元块间通过片上网络NoC传递数据。调度粒度是块级别的编译器把计算图切分成若干块决定哪块先算、数据往哪流。这种方案的好处是调度开销小编译器不用管块内每个PE怎么动只管块间依赖。坏处是灵活性受限如果某个算子没法整齐地切成块就会出现计算块利用率低的情况。我在评估这类架构时第一件事就是看它的编译器能不能把主流模型ResNet、BERT、LLaMA的算子都映射成高效的块划分。有些方案在卷积上表现很好一到Transformer的注意力机制就露怯因为注意力里的softmax和动态shape对块划分很不友好。HotChips上有家公司的方案我印象很深他们做了一个可重构的计算块块内PE之间的连接可以通过配置改变这样同一个硬件既能高效跑卷积也能跑注意力。代价是配置开销和面积增加但换来的是模型覆盖率大幅提升。这个取舍在推理芯片里很常见——面积换灵活性只要面积不是太离谱客户通常愿意买单。3.2 细粒度数据流每个PE独立触发细粒度数据流走的是另一个极端每个PE都有自己的指令队列或者触发条件数据到了就执行。这有点像数据流计算机的现代版理论上灵活性最高能支持任意计算图。但实际做起来调度和同步的开销会吃掉不少收益。我见过一个细粒度方案每个PE配了一个小的FIFO和触发逻辑PE之间通过握手信号传递数据。好处是天然支持流水线数据在PE间流动时计算自动重叠。问题是当计算图有分支或者循环时握手逻辑会变得复杂死锁风险也上来了。他们的解决办法是在编译器层面做静态调度把动态行为尽量转成静态的减少运行时握手。这类架构对编译器的要求极高编译器要能做算子融合、流水线调度、缓冲区分配。我个人的经验是评估细粒度数据流芯片编译器团队的实力比硬件参数更重要。硬件再漂亮编译器映射不出高效代码实际性能可能连理论峰值的20%都不到。3.3 混合方案数据流加控制流的务实选择纯数据流架构在通用性上始终有短板所以HotChips上更多看到的是混合方案——主体用数据流但保留一定的控制流能力处理非规则部分。比如主计算阵列用数据流驱动但外面套一个标量核做控制、做地址计算、处理边界情况。这种务实做法我很认同。纯数据流听起来优雅但实际模型里总有那么些算子比如动态shape的reshape、条件分支不适合数据流。硬要用数据流实现要么效率极低要么编译器复杂度爆炸。留一个控制流后门让这些边角料跑在标量核上整体收益反而更高。选型时我会重点看这个控制流部分的性能。有些方案标量核太弱成了整个芯片的瓶颈有些方案标量核和主阵列的协同做得不好数据在两者之间来回倒腾把数据流省下来的能耗又吐回去了。4. 数据流架构芯片的实操评估要点4.1 算力利用率别被峰值算力忽悠数据流架构芯片的峰值算力通常标得很高但实际利用率才是关键。我评估时必看三个指标一是典型模型下的实测吞吐二是不同batch size下的利用率曲线三是算子覆盖率。实测吞吐最好拿真实模型跑ResNet-50、BERT-Base、LLaMA-7B这几个是标配。有些芯片在ResNet上能跑到峰值的70%一到BERT就掉到30%因为注意力机制的数据流映射没做好。batch size的影响也很大数据流架构通常在小batch下效率更高因为延迟低但大batch下如果片上缓存不够数据反复进出片外利用率会断崖式下跌。算子覆盖率指的是芯片原生支持多少种算子。数据流架构通常对卷积、矩阵乘、激活函数支持很好但对一些特殊算子如LayerNorm、Softmax可能需要回退到标量核性能损失明显。评估时要问清楚哪些算子是原生的哪些是回退的回退的代价有多大。4.2 片上存储层次数据流架构的命门数据流架构的能效优势很大程度上来自减少片外访问所以片上存储的设计至关重要。我会关注几个点片上SRAM的总容量、带宽、以及存储层次的组织方式。总容量决定了能缓存多大的中间结果。如果模型的一层输出有几十MB片上只有几MB SRAM那数据流到一半就得写回片外优势大打折扣。带宽决定了数据在片上流动的速度如果NoC带宽不够计算单元会饿死。存储层次的组织方式则影响编译器的调度难度层次越多、越复杂编译器越难做全局优化。我见过一个方案片上SRAM容量很大但带宽不足结果计算阵列经常等数据实测性能只有理论值的一半。另一个方案带宽很足但容量小大模型跑起来频繁换入换出能效比反而不如传统架构。所以容量和带宽要匹配不能偏废。4.3 编译器与软件栈决定实际可用性数据流架构芯片的软件栈通常比传统架构复杂因为编译器要做的事情更多算子融合、数据流图构建、缓冲区分配、流水线调度。我评估时会把编译器成熟度放在跟硬件同等重要的位置。具体看几个方面一是支持的框架和模型格式PyTorch、TensorFlow、ONNX这些主流格式能不能直接导入二是算子库的丰富程度常用算子有没有手写优化版本三是调试和性能分析工具能不能看到数据流图、每个算子的耗时、片上缓存的占用情况。有个坑我踩过某款数据流芯片的编译器对动态shape支持很差模型里有个动态reshape编译器直接报错只能改成静态shape重新训练。这种限制在选型时一定要问清楚不然模型部署时才发现就晚了。5. 常见问题与排查技巧实录5.1 数据流架构芯片跑不满算力怎么排查这是最常见的问题。我的排查顺序是先看数据搬运是不是瓶颈用性能分析工具看片外带宽利用率如果接近峰值说明数据供给跟不上要么是片上缓存不够要么是数据复用没做好。再看计算阵列利用率如果阵列经常空闲可能是数据依赖导致的等待检查数据流图的并行度够不够。最后看编译器生成的代码有没有明显的低效模式比如频繁的同步、不必要的缓冲区拷贝。有个技巧把模型逐层跑看哪一层的利用率突然掉下来。通常问题就出在那层。我遇到过一层Group Convolution利用率只有15%原因是编译器没做好分组数据的调度后来手动改了数据布局才解决。5.2 精度对不齐怎么办数据流架构芯片通常支持INT8、FP16等精度但不同芯片的量化策略不同精度对齐是个麻烦事。我的经验是先在浮点模型上验证功能正确性再逐步量化。量化时不要一刀切敏感层如第一层和最后一层保持高精度中间层可以激进一些。如果芯片支持混合精度尽量用起来。有些数据流架构对混合精度的支持很好不同层可以用不同精度编译器和硬件自动处理转换。但要注意转换开销如果转换太频繁收益可能被抵消。5.3 多卡互联时的数据流一致性数据流架构在多卡场景下有个特殊问题数据流是分布式的跨卡的数据依赖怎么保证一致性。有些方案靠编译器做全局调度把跨卡通信也纳入数据流图有些方案靠运行时库做同步。前者效率高但编译器复杂后者灵活但有运行时开销。我评估时会看跨卡通信的带宽和延迟以及是否支持通信和计算的重叠。如果通信不能重叠多卡扩展效率会很差。实测下来支持通信计算重叠的方案4卡扩展效率能到3.5倍以上不支持的只有2.5倍左右。6. 数据流架构的适用边界与选型建议6.1 什么场景适合数据流架构数据流架构不是万能的它有明确的甜点区。推理场景、模型结构相对固定、对能效和延迟敏感的应用是数据流架构的主场。比如边缘端的视觉推理、数据中心的推荐系统推理、自动驾驶的感知模型这些场景模型迭代没那么快数据流架构可以把模型结构固化到硬件里换来极致的能效。训练场景目前还是GPU的天下因为训练需要高精度、大batch、频繁的权重更新数据流架构的灵活性不足以支撑。但有些方案在做训练加速的探索比如把反向传播也映射成数据流这个方向值得关注。6.2 选型时的关键决策点如果你在选型我建议按这个优先级排序第一看模型覆盖率芯片能不能高效跑你所有的模型第二看编译器成熟度能不能快速部署和调优第三看能效和延迟这是数据流架构的核心价值第四看生态和工具链长期维护成本很重要。不要只看峰值算力那个数字参考价值有限。也不要只看单算子性能实际模型是算子组合端到端性能才是真的。最好能拿到开发板或者云上实例跑自己的模型实测。6.3 未来演进方向的一些观察从HotChips的趋势看数据流架构正在往两个方向走一是更粗粒度的可重构用更大的计算块降低调度开销二是更紧密的存算一体把数据流和存内计算结合进一步消除搬运。还有一个方向是Chiplet把数据流计算块做成小芯片通过先进封装拼成大芯片这样既能保证良率又能灵活扩展。我个人比较看好可重构数据流加Chiplet的组合。可重构解决灵活性问题Chiplet解决扩展性问题两者结合可能是下一代AI芯片的主流形态。当然这中间还有不少工程挑战比如Chiplet间的数据流一致性、可重构配置的编译优化都需要时间打磨。最后分享一个我在实际项目中的体会数据流架构芯片的评估一定要带着真实模型去跑不要只看纸面参数。我见过太多参数漂亮但实际跑起来各种问题的方案。另外编译器的迭代速度很关键选型时不仅要看当前版本的能力还要看团队的更新频率和响应速度。一个活跃的编译器团队能让同一块硬件在半年内性能提升30%以上这个价值往往被低估。
