每年八月的Hot Chips会议前后AI芯片圈子里讨论热度最高的往往不是某家厂商又刷了什么跑分而是架构这个词。尤其是在大模型几乎统治了AI叙事之后大家越来越清楚地意识到算力数字堆得再高如果数据喂不进去、算力用不满那一切都是纸面性能。这几年NVIDIA的GPU依然稳坐主力位置但围绕数据流架构Dataflow Architecture的讨论已经从学术论文里的小众概念变成了各大芯片发布会的核心关键词。很多人都在问数据流架构到底是什么它凭什么被认为是下一代AI芯片的方向之一Hot Chips上那些最硬核的底层细节到底透露了什么信号这篇文章我打算从架构演进的底层逻辑讲起结合近几年Hot Chips上披露的真实芯片设计把数据流架构的核心原理、代表性芯片的实现路径、以及落地时那些PPT上看不到的坑一次说清楚。不管你是做AI Infra的、做芯片架构的还是单纯想搞明白为什么GPU明明算力那么强还不够用的技术人这篇文章都值得你花十分钟读完。1. 为什么GPU越来越难喂饱冯诺依曼瓶颈在AI负载下的放大效应1.1 数据搬运与计算的能量差一个容易被忽视的数量级问题先聊一个最容易被忽视、但实际决定了一切的基本事实在芯片上做一次计算的能耗远远低于搬一次数据的能耗。我做架构评估的时候经常拿一组数字给团队看一次32位浮点乘加运算在当前先进工艺下大概只需要几个pJ皮焦耳但如果要从DRAM里读一份数据到计算单元旁边能耗直接跳到几百pJ。这两个数量级的差距意味着你无论把乘法器做得多么密集、算力标得多么高只要数据搬运路径变长、频次变高芯片的真实效率就会肉眼可见地崩塌。这种现象在行业里有个经典叫法——存储墙或者说访存墙。放到AI场景里就更极端了。Transformer模型的核心是矩阵乘法矩阵乘法的特点是权重复用和数据复用都极其密集。理论上一份权重可以在片上被成千上万次复用但如果芯片架构不支持这种复用每次计算都要从外部存储捞数据那DRAM带宽就会变成死死的天花板。H100的HBM带宽号称4.8TB/s听起来吓人但对比一下它接近1000 TFLOPS的稠密算力平衡点其实极其苛刻——只要数据复用率稍微打点折扣算术强度不够GPU就只能在内存带宽的瓶颈上干瞪眼。1.2 GPU利用率为什么上不去调度开销与片上存储的短板另一个大家日常都能感受到的问题是即便你有足够的带宽GPU的利用率也常常上不去。我自己跑过不少LLM推理和训练任务一个真实体感是——绝大多数现网场景里GPU利用率能稳定跑到50%就已经算调优得不错了更多时候是30%上下晃悠。很多人第一反应是模型太小了或者并行策略没调好但往深了挖根子还是出在架构上。GPU本质上是控制流架构程序计数器决定指令顺序配上乱序执行、寄存器重命名、调度器这些复杂的机制才能让几百上千个计算单元尽量别闲着。这套机制在通用计算里是优点因为它什么负载都能接但在AI这种高度规律化的张量计算里它的代价就变得很突出——取指要花功耗、译码要花功耗、乱序调度要花功耗数据在L1、L2、L2 Cache、HBM之间搬来搬去也要花功耗和延迟。换句话说冯诺依曼体系为了通用性付出的那部分代价在AI时代被无比精准地放大了。Dataflow架构的思路恰恰就是冲着这个问题去的既然AI计算图在编译期就是已知的、结构化的、数据复用规律清晰的那我们为什么还需要一套过度通用的指令调度机制能不能直接把计算图变成硬件结构让数据沿着预先铺设好的物理路径流动流动到哪就算到哪2. HotChips上的风向变化从发布细节看数据流架构的崛起2.1 Hot Chips是什么芯片厂商少有的技术裸奔时刻先给不太熟悉的朋友铺垫一下背景。Hot Chips是斯坦福组织的年度半导体会议每年8月左右在硅谷举办。它跟CES、GTC那种商业发布会完全不一样——各个芯片公司会在这里首次向外界披露自家芯片的微架构细节包括流水线怎么设计、缓存层级怎么布、互联拓扑长什么样、指令集怎么扩展。很多在发布会上只讲AI性能提升多少倍的厂商到了Hot Chips上就必须拿出真东西你用了什么互联方案、你的片上SRAM到底多大、你的调度器怎么处理数据冲突。这也是为什么我一直觉得真正想判断下一代AI芯片往哪走最靠谱的信息源不是新闻稿而是Hot Chips的slide和现场问答。因为商业宣传可以吹牛但微架构细节一旦说错在场的工程师们会直接举手质疑。2.2 数据流架构在Hot Chips上的演进轨迹从边缘话题到C位如果往前翻几年的Hot Chips你会发现数据流架构并不是今天才冒出来的新鲜事物。2016年到2019年之间像Wave Computing、Cerebras、SambaNova这些公司就陆续在会议上亮过自己的数据流方案。只不过那时候AI芯片赛道还是英伟达一家独大的格局通用GPU几乎通吃了训练和推理市场数据流架构被很多人视作学术界概念的小众实践。风向真正变化是在大模型爆发之后。Transformer结构的计算模式高度规整Attention、FFN、LayerNorm这些算子的数据流关系非常清晰几乎可以无脑展开成一张静态计算图。这恰恰是数据流架构最擅长处理的形态。于是从2023年开始Hot Chips上关于数据流的内容明显变密了——Cerebras讲晶圆级引擎怎么把计算阵列铺满整张晶圆SambaNova讲可重构数据流单元怎么适应大模型算子Groq讲如何用编译器彻底替代缓存管理。到了2024年和2025年连传统芯片巨头也开始在自家架构里引入数据流思想。从小众概念到Hot Chips最热关键词之一这中间的变化速度比大多数人预想的要快得多。3. 数据流到底是什么把数据准备好了就计算变成硬件本能3.1 控制流与数据流的本质差异从指令驱动到数据驱动要把数据流讲明白最好的方式是和传统控制流做一个对比。控制流架构的典型代表就是CPU和GPU。它们的工作方式是程序计数器PC不断取指令指令告诉计算单元该做什么了然后数据被加载进来、执行计算、写回结果。整个过程是由指令驱动的指令是主动的数据是被动的。哪怕数据早就躺在寄存器里了只要指令还没排到计算单元也只能等着。数据流架构完全是反过来程序在编译期就被展开成一张计算图每个计算节点对应一次乘加、一次矩阵运算、一次激活函数的输入端有几个数据槽位。当且仅当所有输入数据都抵达槽位时这个节点才会自动触发计算然后结果沿着片上网络直接送到下游节点的输入槽里。这个过程不需要全局的程序计数器不需要复杂的取指译码更不需要专门的数据调度指令。我用一个生活化的例子帮大家理解传统架构就像一条人工流水线每个工位上的工人要等班长拿着工单喊开始干活才动手而数据流架构就像一套自动化传送带传感器检测到所有零件到位就自动启动机器加工。工件自己在流水线上往前流不需要任何人大喊大叫。这里顺便说一个概念性的伪代码方便没接触过数据流编程模型的朋友建立直觉# 概念示例数据流节点触发逻辑非真实代码 def mul_add(A, B, C): # 该节点等待 A、B、C 三个输入全部就绪 wait_all(A.ready, B.ready, C.ready) return A * B C # 编译器把计算图展开成节点连接关系 # 数据从存储读到计算单元就绪即触发结果继续向下游传播实际硬件当然不是用Python跑的但这个等输入齐了就干活的逻辑就是数据流芯片最基本的执行模型。3.2 静态数据流与动态数据流两条路线的取舍在数据流芯片的具体实现里又分成两个流派静态数据流和动态数据流。静态数据流比较好理解整个计算图在编译期就被完全确定硬件上的计算单元、存储单元、互联路径全部按照这张图预先配置好。执行过程中不需要任何运行时仲裁数据沿着固定路径流动行为完全可预测。这个流派的最大优点是硬件可以做得极其简单——没有复杂的调度器没有缓存一致性协议静态功耗低得惊人延迟可精确到时钟周期。代价则是只要计算图变了就得重新配置硬件灵活性差。动态数据流则是在数据流的基础上保留了部分的运行时灵活性。每个数据包会携带标签tag计算节点根据标签来匹配互相对应的数据而不是死板地绑定在物理通路上。这种做法能处理一些运行时不规则的情况比如动态shape、条件分支但代价是硬件需要额外的匹配逻辑和仲裁机制功耗和复杂度都上升了。像Tenstorrent的早期架构就走的是这一路。下面的表可以很直观地概括两者差异对比维度静态数据流动态数据流调度时机编译期全部确定部分运行时确定硬件复杂度低无全局调度器高需要标签匹配与仲裁可预测性极强延迟精确可期中等灵活性差计算图变化需重编译较好可处理动态负载典型代表Cerebras、Groq、SambaNovaTenstorrent等3.3 确定性是最大的礼物也是最大的枷锁理解数据流架构最关键的是理解确定性这三个字。数据流的优势几乎全部来源于确定性因为一切在编译期都安排好了所以执行时没有额外的调度开销因为数据路径固定片上存储布局可以被编译器做全局优化因为行为可预测SoC设计上就不需要为各种万一准备冗余资源。但确定性也是它最大的枷锁。数据流架构本质上是把运行时可以灵活处理的问题提前到了编译期必须解决。这带来的连锁反应是一旦负载中出现编译期无法预测的东西——比如循环次数取决于输入数据、稀疏矩阵的稀疏率动态变化、多模型动态切换——数据流芯片就会变得非常别扭。你必须在编译期把最坏情况都铺好资源否则运行时就可能数据冲突或空泡。这个特性直接决定了后面要讲的落地难题。4. 三家代表性芯片的数据流实现路径WSE-3、SN40L与LPU4.1 Cerebras WSE-3把数据流铺满整张晶圆聊数据流芯片Cerebras是绕不开的。他们的思路是往极端里做直接在整张晶圆上造一个芯片。WSE-3在2024年发布时晶体管数量已经到了万亿量级片上AI核心接近90万颗片上SRAM高达44GB。这是什么概念大多数GPU的片上存储是以MB为单位的而WSE-3做到了44GB——大到可以把相当规模的大模型权重全部常驻在片上彻底绕开外部DRAM带宽瓶颈。在Hot Chips的披露里WSE-3的架构核心就是一张二维Mesh互联的静态数据流阵列。每个AI核心自带一块本地SRAM编译器的任务就是把计算图的节点分配到这些核心上让权重和中间结果尽量在本地和邻近核心之间流动。由于有足够的片上存储矩阵乘法的权重可以驻扎在SRAM里反复复用数据搬运距离被压缩到了极致。Cerebras就是靠这个逻辑在超大规模模型训练上打出了自己的生态位。当然它的代价也很直接因为是一整张晶圆制造良率要求极高功耗和散热方案也极度夸张接入它的数据中心需要专门定制液冷和供电。这套方案不适合所有人但在超大模型、极致带宽这个细分场景里数据流架构的优势被它发挥得非常极致。4.2 SambaNova SN40L可重构数据流的妥协与平衡相比Cerebras的极致刚烈SambaNova走的是另一条路——可重构数据流Reconfigurable Dataflow。他们的RDUReconfigurable Dataflow Unit内部分布了大量可配置的处理单元和存储簇编译器SambaFlow把模型映射成一张数据流水线之后这些单元的连接方式会被实际配置成对应的拓扑。SN40L这个型号已经是他们第三代产品里面同时集成了向量单元、矩阵单元和标量单元三类计算引擎照顾到AI计算里不同算子的多样化需求。这种设计的聪明之处在于它没有把宝全部押在纯静态展开上而是留了一部分可重构的弹性空间。代价则是芯片面积、功耗和编译器的复杂度都明显上去了——你本质上是在用硬件灵活性换编译期压力的下降。从落地场景看SambaNova主要瞄准的是企业级大模型一体机和推理市场。他们不需要你去买一堆GPU然后自己拼集群而是直接给你一台把模型编译好了的机器。这个模式在特定客户群里很受欢迎因为省去了大量系统调优的折腾。4.3 Groq LPU用编译器的极致确定性换掉缓存Groq的LPU是这几家里最极端的静态数据流实践。它的核心思想一句话就能说完既然编译期已经把一切都决定好了那芯片上就不需要硬件管理的缓存一致性和动态调度逻辑。传统芯片里有复杂的缓存层级和一致性协议这些机制的工作是运行时自动维持数据同步。但同步和仲裁都是有开销的。Groq的方案是把片上SRAM的分配权全部交给编译器由编译器告诉每一块SRAM在哪个时钟周期存放哪一条数据。硬件不需要猜测数据应该在哪也不需要在运行时处理缓存未命中的问题——因为压根就不存在缓存未命中。这种设计带来的指标非常亮眼延迟极低、时间确定性极强、功耗效率高。但也因此Groq LPU对编译器的依赖达到了极致——你每次修改模型参数、修改batch size、修改序列长度都必须重新过一遍编译流程。我在实际接触Groq生态时的一个真实感受是一旦你的工作负载非常固定比如某个线上推理服务输入形状永远不变那LPU的确定性会让你觉得舒服得离谱但如果你隔三差五要调模型结构编译流程会磨掉你所有耐心。这个细节后面会展开讲。来一个简单的对比总结维度Cerebras WSE-3SambaNova SN40LGroq LPU数据流类型静态数据流可重构数据流静态数据流极致版核心卖点超大片上SRAM晶圆级三单元异构弹性可重构编译器管理一切零缓存一致性开销片上存储容量44GB相对较小GB级单卡SRAM有限数十MB级主要落地场景超大模型训练企业大模型推理/微调一体机高确定性、低延迟推理最大软肋制造与散热门槛极高编译器复杂度高负载灵活性最差编译依赖最重5. 从理论到生产线数据流架构落地时的三大痛点5.1 编译时间从分钟到小时迭代痛苦的根源如果说架构原理是数据流的A面那编译器就是它的B面而且B面的戏份一点都不少。传统GPU上部署模型是什么流程加载权重、构建计算图、交给CUDA/TensorRT跑就行运行时遇到新的输入形状动态shape机制会自动处理。整个过程对用户而言几乎是顺畅无感的。数据流芯片不是这样。你拿到的模型必须被完整地编译到硬件上——包括算子分解、计算单元分配、片上SRAM布局、数据流的物理路径规划。我见识过的一次实际部署里跑一个中等规模的LLM编译耗时从二十分钟到几个小时不等。这意味着每次调整batch size、改写模型结构、甚至只是换一个激活函数都可能触发一次重编译。我自己在评估这类芯片时的一个经验是编译时间本身不是最可怕的最可怕的是它破坏了快速迭代的闭环。在GPU上你想试试新的模型变体改几行代码就能跑在数据流芯片上一次实验的周期被拉长到改代码→编译等待→跑起来→发现效果不对→再改→再编译。对于研究型团队这个体验几乎是灾难级的。但反过来如果你是一个产品已经固定的推理服务团队编译一次后稳定运行几个月那这点成本就不算什么了。5.2 动态shape与MoE数据流最不擅长的事第二个痛点是动态性。LLM推理的真实负载从来不是完全规整的。KV Cache的长度随序列变化beam search的分支数在运行时才确定更不要说现在越来越火的MoE架构——每个token到底路由到哪几个专家是完全由输入决定的运行时行为。这对静态数据流来说极其不友好。因为编译期你必须为最坏情况预留资源否则运行时数据没地方放但一旦预留得过多资源利用率就会大幅下降。MoE更是捅到了数据流的肺管子专家路由器本身就是一段动态逻辑不同token走的路径在编译期不可见你很难把这样的计算图硬塞进一张静态数据流水线里。我观察到行业里的应对方案大体分两类一类是在数据流芯片内部保留一小块控制流域专门处理动态逻辑相当于让架构变得更混合另一类是在系统层面做调度限制比如固定输入长度、固定专家路由策略硬把动态问题变成静态问题。后者牺牲灵活性但能保住确定性带来的性能优势。5.3 生态迁移成本没有CUDA照样有护城河最后说一个最现实的问题生态。很多讨论数据流架构的人喜欢强调它比GPU功耗低、性能高但很少有人提到你从CUDA生态迁移到一个全新的SDK需要付出多大的代价。目前几家数据流芯片厂商的软件栈基本都是自成一派Cerebras有CSoftSambaNova有SambaFlowGroq有GroqWare。它们都提供了从PyTorch模型转到自家硬件的编译工具链但成色差别很大。碰到常见的Transformer算子还好说一旦你的模型里有自定义算子、特殊的并行策略或者冷门的融合逻辑就可能需要深入到底层编译器去调试。我个人的一个判断是在AI芯片领域生态迁移成本才是真正的护城河。一个芯片的架构再先进如果团队迁移过去要花两个月那大多数理性的工程负责人都会选择继续在CUDA生态里调优。很多数据流创业公司的公开客户名单看起来光鲜实际上背后往往都有厂商派驻的工程师团队在帮忙做模型适配——这笔隐性成本客户自己心里有数。6. 未来走向与我的选型判断数据流不会取代GPU但会重塑整个芯片栈6.1 数据流思想正在下沉传统芯片内部的局部数据流化很多人问我要不要押注数据流取代GPU我的回答一直是大概率不会正面取代但数据流思想正在往传统芯片内部渗透。最明显的一个例子是NVIDIA自己。从Ampere到Hopper再到BlackwellTensor Core的粒度和灵活性一直在进化本质上就是在把越来越大的算子融合到硬件的固定流水线里减少中间结果的搬运。GPU虽然整体依然是控制流架构但在计算核心内部已经出现了局部数据流的影子。这种混合趋势在可见的未来会加速。比如3D堆叠SRAM技术能进一步拉近存储和计算的距离光互连技术如果成熟数据在网络上的搬运效率会大幅提升这些都会让把计算逻辑直接映射到物理通路的数据流思路变得更加可行。可以预见未来不会只有纯控制流芯片和纯数据流芯片两个极端而是收敛到不同比例混合的形态——哪里需要通用性就保留控制流哪里计算模式固定就数据流化。6.2 给从业者的三个判断与一条实操建议结合这几年在相关方向的观察和实际项目经验我给正在做技术选型的朋友三个判断判断一2025年到2027年数据流架构会在固定工作负载的规模化推理这个细分市场里站稳脚跟。如果你的业务是几个固定模型的线上推理且对延迟和功耗极度敏感数据流芯片值得认真评估。判断二编译器决定了数据流芯片的上限。芯片的峰值算力是下限编译器的全局优化能力才是真正拉开差距的地方。评估数据流芯片时别只盯着TOPS和SRAM容量多花时间跑真实模型试编译流程感受等待时间和最终性能。判断三算力利用率比峰值算力更值钱。同样是标称几百TOPS的芯片GPU可能实际跑到三成好的数据流芯片可能跑到六七成。你做TCO测算时用实测吞吐×能效去算而不是拿标称参数算结果会完全不同。最后分享一个选型时的实操小建议如果你真想在一款数据流芯片上做PoC一定别拿那种炼丹式的迭代型任务去test直接拿你线上最稳定的那个推理服务当试验对象。数据流的确定性碰上固定负载效果是乘法级的但如果你拿一个天天改结构的探索性项目去测大概率会被编译流程劝退。测之前想清楚你的场景在光谱上靠哪一端这比纠结任何跑分数字都重要。
GPU算力喂不饱？数据流架构才是下一代AI芯片的关键
每年八月的Hot Chips会议前后AI芯片圈子里讨论热度最高的往往不是某家厂商又刷了什么跑分而是架构这个词。尤其是在大模型几乎统治了AI叙事之后大家越来越清楚地意识到算力数字堆得再高如果数据喂不进去、算力用不满那一切都是纸面性能。这几年NVIDIA的GPU依然稳坐主力位置但围绕数据流架构Dataflow Architecture的讨论已经从学术论文里的小众概念变成了各大芯片发布会的核心关键词。很多人都在问数据流架构到底是什么它凭什么被认为是下一代AI芯片的方向之一Hot Chips上那些最硬核的底层细节到底透露了什么信号这篇文章我打算从架构演进的底层逻辑讲起结合近几年Hot Chips上披露的真实芯片设计把数据流架构的核心原理、代表性芯片的实现路径、以及落地时那些PPT上看不到的坑一次说清楚。不管你是做AI Infra的、做芯片架构的还是单纯想搞明白为什么GPU明明算力那么强还不够用的技术人这篇文章都值得你花十分钟读完。1. 为什么GPU越来越难喂饱冯诺依曼瓶颈在AI负载下的放大效应1.1 数据搬运与计算的能量差一个容易被忽视的数量级问题先聊一个最容易被忽视、但实际决定了一切的基本事实在芯片上做一次计算的能耗远远低于搬一次数据的能耗。我做架构评估的时候经常拿一组数字给团队看一次32位浮点乘加运算在当前先进工艺下大概只需要几个pJ皮焦耳但如果要从DRAM里读一份数据到计算单元旁边能耗直接跳到几百pJ。这两个数量级的差距意味着你无论把乘法器做得多么密集、算力标得多么高只要数据搬运路径变长、频次变高芯片的真实效率就会肉眼可见地崩塌。这种现象在行业里有个经典叫法——存储墙或者说访存墙。放到AI场景里就更极端了。Transformer模型的核心是矩阵乘法矩阵乘法的特点是权重复用和数据复用都极其密集。理论上一份权重可以在片上被成千上万次复用但如果芯片架构不支持这种复用每次计算都要从外部存储捞数据那DRAM带宽就会变成死死的天花板。H100的HBM带宽号称4.8TB/s听起来吓人但对比一下它接近1000 TFLOPS的稠密算力平衡点其实极其苛刻——只要数据复用率稍微打点折扣算术强度不够GPU就只能在内存带宽的瓶颈上干瞪眼。1.2 GPU利用率为什么上不去调度开销与片上存储的短板另一个大家日常都能感受到的问题是即便你有足够的带宽GPU的利用率也常常上不去。我自己跑过不少LLM推理和训练任务一个真实体感是——绝大多数现网场景里GPU利用率能稳定跑到50%就已经算调优得不错了更多时候是30%上下晃悠。很多人第一反应是模型太小了或者并行策略没调好但往深了挖根子还是出在架构上。GPU本质上是控制流架构程序计数器决定指令顺序配上乱序执行、寄存器重命名、调度器这些复杂的机制才能让几百上千个计算单元尽量别闲着。这套机制在通用计算里是优点因为它什么负载都能接但在AI这种高度规律化的张量计算里它的代价就变得很突出——取指要花功耗、译码要花功耗、乱序调度要花功耗数据在L1、L2、L2 Cache、HBM之间搬来搬去也要花功耗和延迟。换句话说冯诺依曼体系为了通用性付出的那部分代价在AI时代被无比精准地放大了。Dataflow架构的思路恰恰就是冲着这个问题去的既然AI计算图在编译期就是已知的、结构化的、数据复用规律清晰的那我们为什么还需要一套过度通用的指令调度机制能不能直接把计算图变成硬件结构让数据沿着预先铺设好的物理路径流动流动到哪就算到哪2. HotChips上的风向变化从发布细节看数据流架构的崛起2.1 Hot Chips是什么芯片厂商少有的技术裸奔时刻先给不太熟悉的朋友铺垫一下背景。Hot Chips是斯坦福组织的年度半导体会议每年8月左右在硅谷举办。它跟CES、GTC那种商业发布会完全不一样——各个芯片公司会在这里首次向外界披露自家芯片的微架构细节包括流水线怎么设计、缓存层级怎么布、互联拓扑长什么样、指令集怎么扩展。很多在发布会上只讲AI性能提升多少倍的厂商到了Hot Chips上就必须拿出真东西你用了什么互联方案、你的片上SRAM到底多大、你的调度器怎么处理数据冲突。这也是为什么我一直觉得真正想判断下一代AI芯片往哪走最靠谱的信息源不是新闻稿而是Hot Chips的slide和现场问答。因为商业宣传可以吹牛但微架构细节一旦说错在场的工程师们会直接举手质疑。2.2 数据流架构在Hot Chips上的演进轨迹从边缘话题到C位如果往前翻几年的Hot Chips你会发现数据流架构并不是今天才冒出来的新鲜事物。2016年到2019年之间像Wave Computing、Cerebras、SambaNova这些公司就陆续在会议上亮过自己的数据流方案。只不过那时候AI芯片赛道还是英伟达一家独大的格局通用GPU几乎通吃了训练和推理市场数据流架构被很多人视作学术界概念的小众实践。风向真正变化是在大模型爆发之后。Transformer结构的计算模式高度规整Attention、FFN、LayerNorm这些算子的数据流关系非常清晰几乎可以无脑展开成一张静态计算图。这恰恰是数据流架构最擅长处理的形态。于是从2023年开始Hot Chips上关于数据流的内容明显变密了——Cerebras讲晶圆级引擎怎么把计算阵列铺满整张晶圆SambaNova讲可重构数据流单元怎么适应大模型算子Groq讲如何用编译器彻底替代缓存管理。到了2024年和2025年连传统芯片巨头也开始在自家架构里引入数据流思想。从小众概念到Hot Chips最热关键词之一这中间的变化速度比大多数人预想的要快得多。3. 数据流到底是什么把数据准备好了就计算变成硬件本能3.1 控制流与数据流的本质差异从指令驱动到数据驱动要把数据流讲明白最好的方式是和传统控制流做一个对比。控制流架构的典型代表就是CPU和GPU。它们的工作方式是程序计数器PC不断取指令指令告诉计算单元该做什么了然后数据被加载进来、执行计算、写回结果。整个过程是由指令驱动的指令是主动的数据是被动的。哪怕数据早就躺在寄存器里了只要指令还没排到计算单元也只能等着。数据流架构完全是反过来程序在编译期就被展开成一张计算图每个计算节点对应一次乘加、一次矩阵运算、一次激活函数的输入端有几个数据槽位。当且仅当所有输入数据都抵达槽位时这个节点才会自动触发计算然后结果沿着片上网络直接送到下游节点的输入槽里。这个过程不需要全局的程序计数器不需要复杂的取指译码更不需要专门的数据调度指令。我用一个生活化的例子帮大家理解传统架构就像一条人工流水线每个工位上的工人要等班长拿着工单喊开始干活才动手而数据流架构就像一套自动化传送带传感器检测到所有零件到位就自动启动机器加工。工件自己在流水线上往前流不需要任何人大喊大叫。这里顺便说一个概念性的伪代码方便没接触过数据流编程模型的朋友建立直觉# 概念示例数据流节点触发逻辑非真实代码 def mul_add(A, B, C): # 该节点等待 A、B、C 三个输入全部就绪 wait_all(A.ready, B.ready, C.ready) return A * B C # 编译器把计算图展开成节点连接关系 # 数据从存储读到计算单元就绪即触发结果继续向下游传播实际硬件当然不是用Python跑的但这个等输入齐了就干活的逻辑就是数据流芯片最基本的执行模型。3.2 静态数据流与动态数据流两条路线的取舍在数据流芯片的具体实现里又分成两个流派静态数据流和动态数据流。静态数据流比较好理解整个计算图在编译期就被完全确定硬件上的计算单元、存储单元、互联路径全部按照这张图预先配置好。执行过程中不需要任何运行时仲裁数据沿着固定路径流动行为完全可预测。这个流派的最大优点是硬件可以做得极其简单——没有复杂的调度器没有缓存一致性协议静态功耗低得惊人延迟可精确到时钟周期。代价则是只要计算图变了就得重新配置硬件灵活性差。动态数据流则是在数据流的基础上保留了部分的运行时灵活性。每个数据包会携带标签tag计算节点根据标签来匹配互相对应的数据而不是死板地绑定在物理通路上。这种做法能处理一些运行时不规则的情况比如动态shape、条件分支但代价是硬件需要额外的匹配逻辑和仲裁机制功耗和复杂度都上升了。像Tenstorrent的早期架构就走的是这一路。下面的表可以很直观地概括两者差异对比维度静态数据流动态数据流调度时机编译期全部确定部分运行时确定硬件复杂度低无全局调度器高需要标签匹配与仲裁可预测性极强延迟精确可期中等灵活性差计算图变化需重编译较好可处理动态负载典型代表Cerebras、Groq、SambaNovaTenstorrent等3.3 确定性是最大的礼物也是最大的枷锁理解数据流架构最关键的是理解确定性这三个字。数据流的优势几乎全部来源于确定性因为一切在编译期都安排好了所以执行时没有额外的调度开销因为数据路径固定片上存储布局可以被编译器做全局优化因为行为可预测SoC设计上就不需要为各种万一准备冗余资源。但确定性也是它最大的枷锁。数据流架构本质上是把运行时可以灵活处理的问题提前到了编译期必须解决。这带来的连锁反应是一旦负载中出现编译期无法预测的东西——比如循环次数取决于输入数据、稀疏矩阵的稀疏率动态变化、多模型动态切换——数据流芯片就会变得非常别扭。你必须在编译期把最坏情况都铺好资源否则运行时就可能数据冲突或空泡。这个特性直接决定了后面要讲的落地难题。4. 三家代表性芯片的数据流实现路径WSE-3、SN40L与LPU4.1 Cerebras WSE-3把数据流铺满整张晶圆聊数据流芯片Cerebras是绕不开的。他们的思路是往极端里做直接在整张晶圆上造一个芯片。WSE-3在2024年发布时晶体管数量已经到了万亿量级片上AI核心接近90万颗片上SRAM高达44GB。这是什么概念大多数GPU的片上存储是以MB为单位的而WSE-3做到了44GB——大到可以把相当规模的大模型权重全部常驻在片上彻底绕开外部DRAM带宽瓶颈。在Hot Chips的披露里WSE-3的架构核心就是一张二维Mesh互联的静态数据流阵列。每个AI核心自带一块本地SRAM编译器的任务就是把计算图的节点分配到这些核心上让权重和中间结果尽量在本地和邻近核心之间流动。由于有足够的片上存储矩阵乘法的权重可以驻扎在SRAM里反复复用数据搬运距离被压缩到了极致。Cerebras就是靠这个逻辑在超大规模模型训练上打出了自己的生态位。当然它的代价也很直接因为是一整张晶圆制造良率要求极高功耗和散热方案也极度夸张接入它的数据中心需要专门定制液冷和供电。这套方案不适合所有人但在超大模型、极致带宽这个细分场景里数据流架构的优势被它发挥得非常极致。4.2 SambaNova SN40L可重构数据流的妥协与平衡相比Cerebras的极致刚烈SambaNova走的是另一条路——可重构数据流Reconfigurable Dataflow。他们的RDUReconfigurable Dataflow Unit内部分布了大量可配置的处理单元和存储簇编译器SambaFlow把模型映射成一张数据流水线之后这些单元的连接方式会被实际配置成对应的拓扑。SN40L这个型号已经是他们第三代产品里面同时集成了向量单元、矩阵单元和标量单元三类计算引擎照顾到AI计算里不同算子的多样化需求。这种设计的聪明之处在于它没有把宝全部押在纯静态展开上而是留了一部分可重构的弹性空间。代价则是芯片面积、功耗和编译器的复杂度都明显上去了——你本质上是在用硬件灵活性换编译期压力的下降。从落地场景看SambaNova主要瞄准的是企业级大模型一体机和推理市场。他们不需要你去买一堆GPU然后自己拼集群而是直接给你一台把模型编译好了的机器。这个模式在特定客户群里很受欢迎因为省去了大量系统调优的折腾。4.3 Groq LPU用编译器的极致确定性换掉缓存Groq的LPU是这几家里最极端的静态数据流实践。它的核心思想一句话就能说完既然编译期已经把一切都决定好了那芯片上就不需要硬件管理的缓存一致性和动态调度逻辑。传统芯片里有复杂的缓存层级和一致性协议这些机制的工作是运行时自动维持数据同步。但同步和仲裁都是有开销的。Groq的方案是把片上SRAM的分配权全部交给编译器由编译器告诉每一块SRAM在哪个时钟周期存放哪一条数据。硬件不需要猜测数据应该在哪也不需要在运行时处理缓存未命中的问题——因为压根就不存在缓存未命中。这种设计带来的指标非常亮眼延迟极低、时间确定性极强、功耗效率高。但也因此Groq LPU对编译器的依赖达到了极致——你每次修改模型参数、修改batch size、修改序列长度都必须重新过一遍编译流程。我在实际接触Groq生态时的一个真实感受是一旦你的工作负载非常固定比如某个线上推理服务输入形状永远不变那LPU的确定性会让你觉得舒服得离谱但如果你隔三差五要调模型结构编译流程会磨掉你所有耐心。这个细节后面会展开讲。来一个简单的对比总结维度Cerebras WSE-3SambaNova SN40LGroq LPU数据流类型静态数据流可重构数据流静态数据流极致版核心卖点超大片上SRAM晶圆级三单元异构弹性可重构编译器管理一切零缓存一致性开销片上存储容量44GB相对较小GB级单卡SRAM有限数十MB级主要落地场景超大模型训练企业大模型推理/微调一体机高确定性、低延迟推理最大软肋制造与散热门槛极高编译器复杂度高负载灵活性最差编译依赖最重5. 从理论到生产线数据流架构落地时的三大痛点5.1 编译时间从分钟到小时迭代痛苦的根源如果说架构原理是数据流的A面那编译器就是它的B面而且B面的戏份一点都不少。传统GPU上部署模型是什么流程加载权重、构建计算图、交给CUDA/TensorRT跑就行运行时遇到新的输入形状动态shape机制会自动处理。整个过程对用户而言几乎是顺畅无感的。数据流芯片不是这样。你拿到的模型必须被完整地编译到硬件上——包括算子分解、计算单元分配、片上SRAM布局、数据流的物理路径规划。我见识过的一次实际部署里跑一个中等规模的LLM编译耗时从二十分钟到几个小时不等。这意味着每次调整batch size、改写模型结构、甚至只是换一个激活函数都可能触发一次重编译。我自己在评估这类芯片时的一个经验是编译时间本身不是最可怕的最可怕的是它破坏了快速迭代的闭环。在GPU上你想试试新的模型变体改几行代码就能跑在数据流芯片上一次实验的周期被拉长到改代码→编译等待→跑起来→发现效果不对→再改→再编译。对于研究型团队这个体验几乎是灾难级的。但反过来如果你是一个产品已经固定的推理服务团队编译一次后稳定运行几个月那这点成本就不算什么了。5.2 动态shape与MoE数据流最不擅长的事第二个痛点是动态性。LLM推理的真实负载从来不是完全规整的。KV Cache的长度随序列变化beam search的分支数在运行时才确定更不要说现在越来越火的MoE架构——每个token到底路由到哪几个专家是完全由输入决定的运行时行为。这对静态数据流来说极其不友好。因为编译期你必须为最坏情况预留资源否则运行时数据没地方放但一旦预留得过多资源利用率就会大幅下降。MoE更是捅到了数据流的肺管子专家路由器本身就是一段动态逻辑不同token走的路径在编译期不可见你很难把这样的计算图硬塞进一张静态数据流水线里。我观察到行业里的应对方案大体分两类一类是在数据流芯片内部保留一小块控制流域专门处理动态逻辑相当于让架构变得更混合另一类是在系统层面做调度限制比如固定输入长度、固定专家路由策略硬把动态问题变成静态问题。后者牺牲灵活性但能保住确定性带来的性能优势。5.3 生态迁移成本没有CUDA照样有护城河最后说一个最现实的问题生态。很多讨论数据流架构的人喜欢强调它比GPU功耗低、性能高但很少有人提到你从CUDA生态迁移到一个全新的SDK需要付出多大的代价。目前几家数据流芯片厂商的软件栈基本都是自成一派Cerebras有CSoftSambaNova有SambaFlowGroq有GroqWare。它们都提供了从PyTorch模型转到自家硬件的编译工具链但成色差别很大。碰到常见的Transformer算子还好说一旦你的模型里有自定义算子、特殊的并行策略或者冷门的融合逻辑就可能需要深入到底层编译器去调试。我个人的一个判断是在AI芯片领域生态迁移成本才是真正的护城河。一个芯片的架构再先进如果团队迁移过去要花两个月那大多数理性的工程负责人都会选择继续在CUDA生态里调优。很多数据流创业公司的公开客户名单看起来光鲜实际上背后往往都有厂商派驻的工程师团队在帮忙做模型适配——这笔隐性成本客户自己心里有数。6. 未来走向与我的选型判断数据流不会取代GPU但会重塑整个芯片栈6.1 数据流思想正在下沉传统芯片内部的局部数据流化很多人问我要不要押注数据流取代GPU我的回答一直是大概率不会正面取代但数据流思想正在往传统芯片内部渗透。最明显的一个例子是NVIDIA自己。从Ampere到Hopper再到BlackwellTensor Core的粒度和灵活性一直在进化本质上就是在把越来越大的算子融合到硬件的固定流水线里减少中间结果的搬运。GPU虽然整体依然是控制流架构但在计算核心内部已经出现了局部数据流的影子。这种混合趋势在可见的未来会加速。比如3D堆叠SRAM技术能进一步拉近存储和计算的距离光互连技术如果成熟数据在网络上的搬运效率会大幅提升这些都会让把计算逻辑直接映射到物理通路的数据流思路变得更加可行。可以预见未来不会只有纯控制流芯片和纯数据流芯片两个极端而是收敛到不同比例混合的形态——哪里需要通用性就保留控制流哪里计算模式固定就数据流化。6.2 给从业者的三个判断与一条实操建议结合这几年在相关方向的观察和实际项目经验我给正在做技术选型的朋友三个判断判断一2025年到2027年数据流架构会在固定工作负载的规模化推理这个细分市场里站稳脚跟。如果你的业务是几个固定模型的线上推理且对延迟和功耗极度敏感数据流芯片值得认真评估。判断二编译器决定了数据流芯片的上限。芯片的峰值算力是下限编译器的全局优化能力才是真正拉开差距的地方。评估数据流芯片时别只盯着TOPS和SRAM容量多花时间跑真实模型试编译流程感受等待时间和最终性能。判断三算力利用率比峰值算力更值钱。同样是标称几百TOPS的芯片GPU可能实际跑到三成好的数据流芯片可能跑到六七成。你做TCO测算时用实测吞吐×能效去算而不是拿标称参数算结果会完全不同。最后分享一个选型时的实操小建议如果你真想在一款数据流芯片上做PoC一定别拿那种炼丹式的迭代型任务去test直接拿你线上最稳定的那个推理服务当试验对象。数据流的确定性碰上固定负载效果是乘法级的但如果你拿一个天天改结构的探索性项目去测大概率会被编译流程劝退。测之前想清楚你的场景在光谱上靠哪一端这比纠结任何跑分数字都重要。
