1. 从HotChips现场回来聊聊架构圈这股“数据流热”先说个有意思的现象。今年HotChips会上我逛了一圈各家的展板和报告最大的感受不是“谁家的算力又翻了几倍”而是“怎么所有人都在讲数据流”——老牌大厂在讲初创公司在讲连做IP授权的也在讲。SambaNova、Cerebras、Groq这些一直坚持数据流路线的公司自不必说连我之前以为会继续死磕传统GPU路线的几家PPT里也悄悄塞进了“temporal dataflow”“spatial array”这类词。这股风不是空穴来风。大模型把算力需求推到了一个很尴尬的位置单卡算力可以堆但数据搬运速度跟不上。你可以把算力想象成一个大厨房厨师切菜速度快到飞起但传菜员还是那个慢悠悠的小伙子菜都堆在案板上送不到锅里。数据流架构的本质就是想绕过这个传菜员让菜直接从一个灶台滑到另一个灶台。这篇文章我想结合HotChips上看到的技术方向和自己的理解聊聊数据流架构AI芯片到底解决了什么问题、有哪些绕不开的坎、以及它对做系统软件和芯片设计的人分别意味着什么。不是那种宣传稿式的解读尽量讲点实在的。如果你正在评估AI芯片选型或者在纠结自研芯片的架构路线这篇应该能帮你把思路理清楚。2. 算力焦虑背后的真正瓶颈数据搬运比计算贵一个数量级在聊数据流之前得先把整个行业焦虑的根源说清楚。过去十年AI芯片算力提升主要靠三招制程微缩、更大的矩阵运算单元、更高的主频。但这三招现在都撞到了同一堵墙——功耗墙和访存墙。制程到了3nm以下每提升一点密度都要付出巨大的代价主频拉到2GHz以上供电和散热就撑不住了。于是芯片公司纷纷转向“堆面积”策略把矩阵单元铺满整个die靠并行度换性能这就是为什么现在AI芯片动不动就是800mm²甚至更大的die。但问题在于你把一百万个小计算单元堆在一起数据从memory运到计算单元的路程就变长了。用行业里的行话说就是“访存墙”——数据搬运消耗的能量比做一次浮点运算高两个数量级访存延迟的代价更是比计算延迟高几个数量级。这个数字有多夸张做过FPGA部署的同学可能有体感同样的卷积操作如果你把权重存在片外DDR里每次计算都要等数据加载实际的吞吐量可能连峰值算力的十分之一都跑不到。HBM解决了带宽问题但HBM的成本和功耗也不是普通场景能随便扛的。更关键的是HBM带宽的增长速度远远跟不上算力的增长速度每代GPU算力翻倍HBM带宽大概只涨40%到50%这个剪刀差越来越大。那么问题来了怎么在不堆HBM的情况下让数据离计算单元更近答案其实早就有——近存计算和数据流架构。近存计算是把memory和计算单元做得更近减少物理距离数据流架构则是从计算模式的层面让数据不用反复经过“取指-解码-访存-计算-写回”这条传统路径。两者经常一起出现但本质是两个层次的事。下面详细拆。先从指令流架构痼疾说起。传统CPU和GPU是典型的指令流架构程序是一条条指令组成的。指令从内存取出来经过解码然后告诉计算单元“去内存的某个地址读数据做个乘法写回另一个地址”。这种模式的好处是灵活——什么程序都能跑编译器只需要把指令排好。但代价是指令本身要搬运取指要消耗带宽每次运算的数据要搬运两次读一次、写回一次计算单元大部分时间在等数据空转率很高。数据流架构的核心思想是反过来的不按指令驱动而是按数据驱动。数据准备好了计算就自动发生计算完了结果自动流向下一个需要它的计算单元。没有取指这一层没有显式的地址读写数据像在流水线上一样从一个个处理单元流过。打个比方。传统架构像一家餐厅顾客点菜指令服务员跑去后厨内存告诉大厨做菜大厨做好了再叫服务员端上来。顾客一多服务员就跑不过来瓶颈在后厨和餐桌之间的路上。数据流架构则是自助餐流水线菜做好一份直接顺着传送带送到下一个加工台每个加工台的师傅只负责自己那一站做完就往下传。没有服务员没有点菜单效率自然高。在AI场景里这种流水线模式非常适合。因为神经网络本质上就是一个有向无环图数据从输入层开始经过卷积、激活、池化、全连接一路流到输出。每一层的计算结果不需要回内存直接作为下一层的输入这就是数据流架构能吃下大模型算力需求的核心原因。3. HotChips上的路线之争三条数据流派系各有各的取舍HotChips让我印象最深的不是某一家公司的具体数据而是产业界对“数据流应该怎么做”这件事已经明显分成了几个派系。每个派系都在用不同的硬件组织方式去逼近“数据尽量少搬”这个目标。我把它们分成三类直通阵列派、近存计算派、可重构数据流派。直通阵列派的典型代表是Cerebras。它的思路比较极致直接做一块wafer级别的芯片整片都是计算阵列——大约90万个核心排成二维网格每个核心自带一小块SRAM数据和中间结果就在网格内流动不往片外搬。它的好处是片上带宽极其恐怖适合超大模型的训练因为参数可以直接摊在阵列里。但也有代价wafer级封装的技术难度巨大良率和散热都是挑战不是谁都能玩得起的。近存计算派的典型代表是各大厂商在HBM之外做的“片上大SRAM”方案。本质上不是纯数据流而是把计算单元的局部存储做大让更多中间结果留在片上减少片外访问。Groq算这一派的激进版它把SRAM做到超大容量存储和计算单元物理上贴在一起整个芯片的运作方式就是“计算单元直接消费邻居产出的数据”。它的好处是实现相对简单编译器压力小一些但SRAM面积成本高没办法支撑超大模型单芯片驻留。可重构数据流派的代表是SambaNova还有国内一些做可重构架构的创业公司。它们用可重构的数据通路把大量的算力单元连接成动态拓扑软件可以针对不同模型专门“编译”出一套数据流配置。好处是灵活能适配不同形状的神经网络坏处是编译器极其难写——你要在编译期就把整个模型的数据流动路径规划好这对编译团队的要求非常高。在HotChips上我看完三家的报告第一反应是这不是谁取代谁的问题而是大家都在用自己最擅长的方式解决同一个物理定律带来的问题——数据搬运的代价。阵列派擅长大模型训练近存派擅长低延迟推理可重构派擅长多模型的灵活性。真正落地的选择得看你的场景最痛的是哪一环。这也是我后来一直跟朋友强调的不要只看“数据流”三个字就兴奋要看到背后的硬件组织方式才能判断它适合哪类工作负载。4. 数据流架构的核心技术拆解PE阵列、片上网络和编译器三角既然要把数据流架构讲透就不能停在概念层面。我从三个关键技术角度拆解一下数据流芯片内部到底是怎么回事。第一个是PEProcessing Element处理单元阵列的组织方式。数据流芯片不像GPU那样有一个个独立的SM而是一大片PE排成二维阵列每个PE可以做乘加运算也可以做简单的激活函数。PE与PE之间通过片上网络直接相连数据可以沿着X轴、Y轴甚至对角线流动。关键问题是中间结果在哪个层级做“汇聚”如果每个PE只跟邻居通信那卷积这种需要跨窗口汇聚的算子在映射时就很痛苦如果设计成任意PE之间都能通信路由器的面积和功耗又会暴涨。我看到的数据流芯片基本都在这个权衡里做了取舍有的偏向邻居通信有的加入了多层级的片上网络。第二个是片上存储层次。数据流芯片最怕的就是“计算单元在等数据”所以片上存储层次的设计直接决定能效。通常做法是把SRAM拆成多个bank每个bank靠近一个PE区域形成一个“分布式存储”格局。做推理的时候权重和中间激活值都能留在片上只有最外层的输入输出才触碰DRAM。我见过一个很典型的估算如果把ResNet-50的推理全部放在片上SRAM里做片外访存可以减少80%以上带来的能效提升是实打实的。第三个是整个架构成败的关键——编译器。传统芯片的编译器只需要把高级语言翻译成指令流数据流芯片的编译则是把计算图的每个节点映射到具体的PE、规划每一条数据流动路径、安排每个PE的时空位置。这本质上是一个NP难问题编译器要在合理时间内给出一个次优解还要保证流水线不堵塞。SambaNova的软件团队几百人大部分都在打磨编译器。很多做数据流芯片创业的公司芯片跑通了但编译器搞不定最后产品根本没法落地这个坎比流片本身还难。这里我要多说一句判断一个数据流芯片靠不靠谱不要光看峰值算力要看它的编译器工具链成熟度以及实际跑真实模型时能跑出多少利用率。芯片是死的编译器是活的。我在评估这类芯片时一般会问三个问题编译器支持哪些模型结构用户自定义算子的路径是怎样的不同shape的模型重编译一次要多久这三个问题比Peak TOPS峰值算力重要得多。5. 为什么大模型时代数据流架构开始“真香”了数据流架构其实不是新概念上世纪八十年代的静态数据流研究就很火后来因为通用性太差被指令流架构压下去了。为什么这几年又开始回潮答案和大模型的结构特点密切相关。大模型有四个特性几乎是为数据流架构量身定做的。第一是超大矩阵乘法。Transformer的Self-Attention本质上是几个大矩阵乘法而矩阵乘法是最容易做数据流化的算子——把矩阵切块分给PE阵列每块在本地算完部分和沿阵列累加。PE互联天然支持这种“部分和累加”模式数据不用到处搬。第二是残差连接和LayerNorm这类轻算子。模型越深这类算子越多它们不是大计算量但会打断流水线。在传统架构上每次做LayerNorm都要把整个tensor从计算单元搬回memory再取出来做下一步在数据流架构上可以直接在流水线里“就地”做一个轻处理然后继续流向下一个计算单元。第三是KV Cache的推理长尾。大模型推理时生成每个token都要去查KV Cache这个访存模式是典型的“读多写少、随机访问”。数据流芯片可以用PE阵列做近似匹配和并行扫描配合片上大SRAM把KV Cache全部放进去生成时完全不需要碰片外存储这对解码延迟是质的改善。第四是对精度和量化的友好性。数据流架构天然支持不同PE用不同的数值精度比如某些层用FP16、某些层用INT8可以在编译期就精确控制每一层的数据格式。传统GPU只能在设备级别统一精度数据流芯片能把精度控制做到算子级别。我自己实测过一个场景一个7B模型在数据流芯片上的推理首token延迟和传统GPU差不多但逐token生成的延迟低很多而且功耗大概只有GPU的三分之一到二分之一。原因就是KV Cache留在了片上while生成时没有任何片外访存。这就是数据流架构在大模型推理上的核心优势——不是体现在峰值算力上而是体现在实际生成的延迟和能效上。6. 数据流架构不是万能药适用边界和工程化里的几个大坑讲完优点也得泼泼冷水。数据流架构有非常明确的适用边界我见过太多团队把它神话化之后踩坑的案例。第一个大坑是动态shape形状可变的噩梦。数据流架构在编译期就把数据流的路径规划死了如果模型输入shape是动态的比如不同长度的序列、不同尺寸的图片编译器要么生成多个静态配置来回切换要么做动态重编译两者的代价都很高。我在评估时遇到过一个场景一个短视频场景的模型推理时输入序列长度从几十到几千随机变数据流芯片跑起来利用率掉了快一半。所以做数据流选型第一件事就是确认你的模型shape是不是基本稳定。第二个大坑是稀疏计算的不友好。数据流架构的设计前提是“每个PE都在算有用的数据”。如果模型是高度稀疏的比如经过剪枝的模型很多PE会算到零值白算一遍。虽然有些芯片做了“跳过零”的硬件逻辑但跳过的代价是流水线气泡数据流的连续性被打断优势反而变成劣势。对稀疏模型传统GPU的稀疏tensor core其实处理得更好。第三个大坑是生态和工具链的锁定。数据流芯片的编程模型和GPU完全不同通常要基于专用编译器输入是ONNX或PyTorch导出的模型文件中间不能插自定义算子。如果你的算法团队经常写一些自定义CUDA算子迁移到数据流架构基本就是噩梦。我见过一些团队评估完数据流芯片后因为两个自定义算子实现不了而放弃整个方案。还有硬件层面的坑PE阵列的利用率非常依赖数据流的“血供”——如果你的模型某个阶段数据量小但算力需求大比如attention后面紧跟一个超大MLPPE阵列会出现严重的饥饿现象大片区域空转。这类模型在GPU上可能跑得很好在数据流芯片上反而会稀烂。所以数据流芯片适合的是“计算密集型、数据流形规整、shape稳定”的模型不是所有AI模型。7. 回到HotChips之后一个资深从业者眼中的选型和落地建议跑完一圈HotChips结合自己做过的几次数据流芯片项目评估我最后分享一些实际的选型建议和经验判断。不一定对但都是在项目里验证过的。先给需求方建议。如果你的业务是纯推理、模型基本固定、shape稳定而且对延迟和功耗极度敏感比如自动驾驶、机器人、云上推理加速数据流芯片非常值得做POC概念验证。但POC不能只跑Peak算力的benchmark一定要拿你们真实的模型、真实的batch size、真实的延迟要求去测尤其要看短序列和不规则输入下的表现。如果你的业务是训练或者经常换模型结构现阶段还是老老实实用GPU数据流芯片的训练生态远没有成熟。再给芯片设计者建议。做数据流芯片最难的不是PE阵列怎么摆而是编译器怎么和硬件协同设计。我看到的成功项目有一个共性编译器团队和硬件架构团队从项目第一天就坐在一起编译器的能力边界直接决定硬件设计的取舍。如果你们团队只有RTL硬件描述语言工程师没有顶级的编译器工程师做数据流架构大概率要翻车。另外建议先从特定场景做起不要一开始就做一个通用数据流芯片。面向Transformer推理的专用数据流芯片比面向所有算子的通用数据流芯片落地的概率高很多。最后回应一个很多人问的问题“数据流架构会不会取代GPU”我的判断是短期内不会。数据处理是技术路线的“三足鼎立”——GPU继续做通用训练和多场景推理数据流架构锁定高能效、低延迟的重计算推理场景NPU类方案继续博弈成本和灵活性。但对特定场景的从业者来说数据流架构已经不是一个停留在论文里的概念而是有产品、有工具链、有实测数据的可用方案。在功耗和延迟就是生命线的领域先吃透数据流的人会拿到不小的先发优势。我在项目里选型时有一条朴素的经验架构没有好坏只有匹配不匹配。数据流架构擅长的事情恰好是大模型推理最痛的那些点——数据搬运成本高、延迟敏感、能效敏感。理解和驾驭它的边界比盲目追新词有价值得多。HotChips上的热闹是一时的真正能在量产系统里把数据流的效率吃干榨净的团队才是这场架构演进里走得更远的人。