每年八月，做芯片的工程师几乎都会习惯性地把注意力拉到 HotChips——这个在斯坦福办了几十年的半导体会议，现在基本成了下一代AI芯片架构的前哨站。今年我把议程从头到尾刷完，最强烈的感受是：数据流架构不再只是学术论文里的老古董，而是被好几家头部厂商正式摆到了量产芯片的台面上。如果你聊AI芯片还只盯着“多少TOPS、多少T算力”，可能已经错过了这轮架构讨论里真正核心的问题——数据怎么流动，有时候比数据怎么算更值钱。
这篇想借着 HotChips 上反复出现的几个数据流方向，聊聊为什么控制流的芯片在AI负载面前会吃亏；Cerebras、SambaNova、Groq 各自的数据流路线到底在解决什么；数据流芯片的三大核心机制是什么；以及我从工程视角看到的边界和坑。适合想理解AI芯片架构选型的人，也适合做AI应用优化、想搞明白底层硬件约束的工程师。
1. 为什么“数据流”这三个字在AI芯片时代突然值钱了
1.1 冯诺依曼瓶颈：指令流给AI计算拖的后腿
传统CPU和GPU基本都是指令驱动路线。每个计算单元有一套取指、译码、执行、写回的流程，程序计数器决定下一步去读哪条指令，再根据指令把数据搬运到寄存器、ALU，一层层地算。这套东西发展了五十多年，成熟度极高，但在AI负载面前有几个特别要命的短板。
第一是控制开销占比高。一个AI算子看起来简单，但把它拆成指令流，需要大量循环、寻址、分支跳转的指令来驱动数据搬进搬出。真正做乘加运算的指令只是一小部分。第二是缓存一致性问题。多核共享数据时要维护 cache coherence，核一多，这套协议的流量和延迟就非常可观，功耗也跟着涨。第三是存储墙。GPU的算力增长远远快过DRAM带宽增长，每层计算都要去HBM把权重和中间结果搬出来，算完再搬回去，功耗和时间都耗在搬运上。
打个比方：一条流水线上，如果每个工人每加工一个零件，都要先听中央调度员念一遍操作规程，产量一定上不去。指令驱动就是这样——每个PE都在等“下一步干什么”的命令。数据流的方式则更像流水线本身：零件一到手就加工，做完马上传给下一站，中间不需要任何人反复确认流程。
1.2 AI负载的三个特征，恰好长在数据流的舒适区
AI计算的任务和普通程序很不一样，往往有三个明显特征。
一是结构规则。矩阵乘、卷积、注意力头，本质上都是规则的多维数组运算，计算图在推理时是静态已知的，很少出现运行时才知道的跳转。二是分支极少。Transformer推理的主要时间花在矩阵乘和访存上，控制流几乎可以忽略不计。三是复用性强。同一组权重要被大量输入复用，同一块激活也要被不同输出复用，数据搬移量远大于实际计算量。
这三个特征放在一起，给出一条重要推论：如果计算图能在编译期被完全确定，运行时就不需要“现场决定下一步干嘛”。数据一旦能用固定的节奏在计算单元之间流动，每份数据在片上多流动几次，去DRAM的次数就能大幅降低——这正是数据流架构最擅长的场景。
需要说明的是，数据流不是凭空冒出来的新概念。脉动阵列就是最朴素的静态数据流形态，Google TPU里的矩阵单元本质上是脉动阵列；很多CNN加速器里的“行驻留”设计，也是让数据按照固定节奏在片上流动。所以说HotChips上大家开始高调讲数据流，更多是把老思路捡回来，用现代工艺推到一个量级夸张的形态。
2. HotChips上的数据流样本：三条路线三种哲学
2.1 Cerebras：把整片晶圆变成一张数据流大网
Cerebras 最出名的做法是不切片，直接把一整块晶圆做成芯片，这就是 Wafer Scale Engine。官方公布的系列指标相当夸张：WSE-2 大约有85万个AI核心、40GB片上SRAM；WSE-3 换了更先进工艺后，核心数更进一步到90万量级，片上SRAM也增加到几十GB。跟GPU拿HBM当外部显存不同，WSE的核心是每个PE都带一块本地SRAM，PE之间通过片上的互连网格直接传数据，没有缓存一致性负担。
这套架构为什么要跟数据流绑在一起？关键在于“生产-消费”的流水方式：编译器把计算图映射到PE阵列上，第N层的计算结果直接作为第N+1层的输入传到邻居PE，中间结果尽量留在片上。GPU每层计算都要去HBM读权重、写回激活，WSE则是把参数直接分布在片上SRAM，PE之间用点对点方式传递中间结果，相当于把“算一次搬一次”改成“映射一次，长流水”。
这种设计的最大收益在大模型训练场景。训练时的梯度聚合、参数同步非常吃通信，而晶圆级芯片把通信路径压缩在片上，避免了多卡之间的集群通信开销。HotChips上他们反复强调的就是这一点：放大单芯片的能力边界，把数据中心级的通信问题变成片内问题。
2.2 SambaNova：可重构数据流，让硬件拓扑跟着模型变
SambaNova 走的是另一条路——可重构数据流。它的核心RDU不是固定SN网格，而是由一组计算单元通过可编程互连连在一起，硬件拓扑可以随着计算图的变化重新配置。SN40R这代开始用了更灵活的chiplet方案，官方重点强调的方向是长序列Transformer，因为在序列维度上做自注意力时，数据流图能避免每步都回访片外存储。
我听多个做编译器的人聊过，SambaNova 的思路是把整个Transformer计算图翻译成一个数据流图，然后硬件上的互连跟着这张图动态重配。跟Cerebras固定网格相比，它更像是“软件定义硬件”：模型不同，片上数据流动的路径就不同。好处是对计算图形状的适配性更强，尤其是处理超长序列时，可以把KV信息长时间留在片上流动；代价是编译器复杂度高，硬件重配也有延迟开销。
2.3 Groq：把调度全部提前到编译期的确定性机器
Groq 的TSP/LPU 又是完全不同的哲学。它既不搞晶圆级，也不搞运行时重配，而是用了类似VLIW加数据流的混合风格：片上SRAM非常大，整套芯片几乎不靠外部DRAM干活；编译器把算子、数据搬运、片上时序全部在编译期安排好，运行时不需要调度器做任何决策。
这样做的好处是延迟极低、行为完全可预测——每个操作在哪一个周期执行，都在编译后确定。对推理服务来说，这等于把延迟抖动的源头消除了。缺点也很明显：灵活性差，模型结构一改，基本就要重新编译部署，训练支持也比较弱。Groq敢这么走，赌的是推理场景的模型结构相对固定，编译一次后可以长期复用。
表：三家数据流路线对比
| 厂商 | 核心路线 | 数据如何移动 | 编译器角色 | 典型优势 | 主要短板 |
|---|---|---|---|---|---|
| Cerebras | 晶圆级固定网格 | PE间片上流水，长距离传输 | 图映射与放置 | 训练通信少、片上带宽巨大 | 晶圆制造与封装难度极高 |
| SambaNova | 可重构互连拓扑 | 数据流路径随模型重配 | 图分析与硬件重配 | 长序列Transformer效率高 | 软件栈新，算子覆盖需要追赶 |
| Groq | 静态调度VLIW混合数据流 | 全静态编排，确定性执行 | 完全调度一切 | 推理延迟低、行为确定 | 灵活性差，训练支持较弱 |
虽然三条路线差异很大，但它们有一个共同逻辑：把中间数据尽量留在片上、让数据在计算单元之间“流动”起来，尽量减少DRAM往返。区别只是这个“流”的形状是固定网格、可重配网络，还是编译期完全定死的静态编排。
3. 数据流芯片的三大核心机制：数据驱动、PE阵列、编译期调度
3.1 数据驱动执行：操作数齐了就算，没有程序计数器
理解数据流架构，最关键的一条是换成“数据驱动”的思维方式。控制流模型里是指令决定何时计算：先取指令，再取数据，然后执行。数据流模型里则是数据就绪触发计算：一个PE只要能拿到它需要的所有操作数，就直接开始计算，算完立刻把结果传给下游PE。
这样带来的最直接好处是天然并行。多个PE可以同时计算不同的数据通道，谁先就绪谁先算，不需要锁，不需要中央调度器反复裁决。另一个好处是把控制逻辑省掉了——没有程序计数器，就不需要每周期判断下一步干嘛，所有精力都花在计算和搬运上。
现代AI芯片基本不会做纯数据流，纯数据流里有标签token匹配这类复杂机制，开销太大。实际产品都是“编译期静态映射加运行时数据触发”的混合模式：编译器把计算图画好，把每个算子的执行位置和时序定好，运行时则由数据到达来触发动作。脉动阵列就很好地体现了这种混合状态——每个乘累加单元从左边和上面拿数据，算完就把结果往右边和下面送，整个过程没有指令参与。
3.2 PE阵列与片上网络：真正决定芯片上限的是互连带宽
数据流芯片的性能上限，往往不在PE的算力，而在PE之间以及PE与存储之间的互连。你可以把PE阵列想象成一座城市，计算单元是街区，数据就是需要在不同街区之间快速穿梭的物流。如果物流路网太窄，街区里仓库再多、工人再快也没有意义。
互连拓扑有几种常见选择：mesh网格简单、布线规则，但长距离跳数多；torus在网格基础上加了环绕链路，多一个方向可走；crossbar延迟低，但规模一大布线复杂度和功耗就爆。不同厂商的选择对应不同负载特征，没有绝对优劣。看一款数据流芯片，有几个指标比TOPS更值得先看：每个PE的本地SRAM容量、相邻PE之间的带宽、全局片上网络带宽、以及离片外DRAM接口的距离和延迟。
一个工程上的判断口径是：如果两个PE之间搬运数据的速度低于它们运算消耗数据的速度，再高的算力也会空转。所以数据流芯片的规格书里，互连带宽往往是最能看出设计者真实意图的地方——数字悄悄抬高，说明厂商真的在乎数据流动效率；只讲算力和存储，不提互连细节的，多半还没解决数据移得够不够快的问题。
3.3 编译器才是数据流芯片的灵魂
很多人第一次接触数据流芯片，容易把注意力全放在硬件架构上，其实离开编译器，数据流芯片几乎是一堆昂贵的SRAM和无用PE。编译器要干的事包括四个层面：把计算图lower到硬件原语序列；做算子融合和内存分配，决定中间结果放在哪个PE的本地SRAM；做放置和路由，把计算节点映射到PE阵列并选好互连路径；最后做静态调度，把数据的到达和算子的启动时序排好。
任何一个环节差一点，都会直接反映到实际性能和利用率上。数据流芯片的编译器比GPU编译器更困难，是因为GPU编译器可以依赖硬件调度器兜底，而数据流芯片大多数决策都在编译期做完，编译器要全知全能。这也解释了为什么做数据流芯片的厂商几乎都有规模很大的软件团队，而且绝大部分工程失败案例都败在编译器成熟度，而不是流片本身。
提示：如果一个数据流芯片的PPT完全不聊编译器、不上编译器开源情况或端到端性能，基本可以判断还处于概念验证阶段。硬件卖相再好，软件接不住也白搭。
4. 别被PPT骗了：数据流芯片的真实边界与三个坑
4.1 稀疏与动态形状：数据流架构的阿克琉斯之踵
数据流芯片最大的软肋，是它赖以起效的静态映射，恰好对稀疏和动态形状极不友好。当权重矩阵有大量零值，或者注意力Mask、序列长度在运行时变化，编译器原本排好的数据节奏就会被打破。如果只是把零值也算进去，那大量PE在空转；如果要在运行时跳过零值，又回到了动态控制流，数据流最核心的优势也没了。
各家应对思路大致是几种：结构化稀疏，比如2:4稀疏，把零值排布限制在固定模式；把动态部分留在host端处理；或者对某些算子回退到更“软”的执行路径。但这些方案的效果跟GPU专门优化过的稀疏内核相比，往往还是有差距。所以如果你要做的模型大量依赖动态形状或非结构化稀疏，选数据流芯片前一定要多问一句：编译器对这类算子的critical path是什么，回退路径的性能衰减多大。
4.2 利用率之外的隐性账：数据搬运的功耗与成本
看数据流芯片不能只看利用率，还要算一笔数据搬运的账。片内计算一个乘加的功耗是皮焦量级，读一次SRAM大约是一个数量级的提升，而去片外DRAM访存要再高一到两个数量级。数据流架构的核心价值就在于减少DRAM访问次数——但前提是编译器的映射足够好。映射不好时，数据会在PE之间反复跨网搬运，片上网络功耗一样会爆，算力虚高但没有实际收益。
所以评估时我会先看一个模型映射到芯片后，理论上的DRAM访问量比GPU少多少，再看片上数据搬运次数是否可控。计算量和存储量指标再好看，这两个数字不健康，实际功耗和延迟照样拉胯。内部特征通常拿不到，但可以从公开微基准和编译器文档中反向推算。
4.3 生态是落地最大的坎
再优秀的架构，如果算子库不全、框架接入困难、用户迁移成本高，商业落地就几乎是空谈。HotChips上大家讲的是创新，量场上赌的是开发者心智，这一点NVIDIA花十年建起的护城河就是最典型案例。数据流芯片厂商都声称兼容PyTorch，但“能跑”和“端到端优化到位”完全是两回事。
评估生态成熟度，可以从这几个维度看：算子覆盖度覆盖了哪些常用算子，缺哪些；PyTorch或者ONNX接入的成熟度如何，是否要专门改写模型；常见模型端到端性能是否有公开benchmark；编译器报错后调试体验好不好，定位问题需要多久；以及最现实的一点，厂商锁定的风险——换到其他芯片时，原来了写的数据流代码有多少能带走。
5. 从HotChips看明天：数据流架构的趋势与我的观察清单
5.1 数据流和GPU在互相“抄作业”
把HotChips几年报告连起来看，会发现一个有意思的趋势：数据流和GPU的边界在模糊。NVIDIA的Tensor Core本来就是脉动阵列式的数据流单元；GPU也在靠CUDA Graphs、Triton编程模型和更细粒度的依赖插入来减少运行时调度开销，尝试把更多调度挪到编译期。反过来，数据流芯片也在吸收GPU的长处：异步访存、多级缓冲、任务队列，用来补足自己在动态负载上的短板。
我倾向认为，未来几年市面上不太会出现一种纯正数据流芯片横扫一切的局面，更可能的是一步步混合化：所有AI芯片都会在关键路径上加入数据流思维，但也会保留一块灵活的“控制流区域”来兜底动态负载。做系统选型时，别把“数据流”或“控制流”当成二选一，要看它在具体负载上的表现。
5.2 Chiplet与先进封装给数据流带来新可能
数据流架构极度依赖互连，而先进封装正好在打通互连瓶颈。UCIe、CoWoS这类技术可以让多个die之间获得高带宽低延迟连接，数据流设计就不必死磕单片大尺寸，可以用多个chiplet拼出一个大规模的数据流系统，把制造成本摊开，也让“可重配互连加chiplet加大容量SRAM”的组合变得更现实。SambaNova的chiplet方案已经走了这个方向，接下来应该有更多厂商跟进。
个人看法是，值得持续关注的方向是“可重配互连加chiplet加大容量SRAM”的组合。它既能享受数据流减少访存的优势，又能用chiplet灵活扩展规模，还避免单片晶圆级制造的良率与成本问题。到底这个组合能走到多大规模、编译器能不能撑住多die协作，是未来两三年最值得盯的技术问题。
5.3 一份可以带走的评估清单
每次看完HotChips上的数据流芯片，我习惯用一份固定清单来过滤信息，分享给正在做选型或调研的人参考。
- 计算图映射到硬件之前，需要多少人工预处理？全自动还是得手写算子级映射。
- 编译一次要多久？模型稍微改动，比如加一个分支、换一个attention实现，重编译的代价多大。
- 稀疏算子和动态shape的回退路径是什么？性能衰减有多少，有没有公开数据。
- 端到端延迟和吞吐，是否包含了host侧通信和框架开销，还是只算芯片内部。
- 当模型规模超出片上SRAM容量时，行为如何变化，会不会出现严重性能断层。
- 最终要落到实际部署时，闭源模型、开源框架、自定义算子的支持程度分别如何。
这六条能答出所以然的数据流芯片，即使当下性能数字不那么夸张，也值得长期关注；答不上来的，大概率还停在纸面亮点阶段。
我自己这几年看AI芯片，养成了一个习惯：拿到任何一款新架构，先不急着比TOPS或算力密度，而是先把它讲清楚——数据是怎么进PE的，进来之后在片上怎么流，最终是怎么出去的。能把这一套讲明白的公司，软件栈和编译器通常也是靠谱的；讲不明白，参数再漂亮我也持保留态度。数据流不是万能药，它最擅长解决的是“数据搬移远大于计算”的AI负载，而工程上真正的难点从来不在把芯片造出来，而在让每一份数据都在正确的时间到达正确的位置。这套判断方式不一定能预测谁最后赢，但至少能帮你在满屏参数横评里站稳脚跟。
