HotChips这几年在我这里已经不只是参会日程，而像是一面镜子，把AI算力行业一年里藏着的真实技术路线照出来。会议全称叫Hot Chips Symposium，1989年就开始了，本来是半导体圈内部交流高性能微处理器设计的半圆桌会议，如今因为各家都想借它公布新一代AI芯片的架构细节，反而成了AI基础设施从业者每年必看的一次技术快照。

今年的议程里，AI芯片占了多半壁江山。我注意到一个反复出现的关键词：数据流架构。从Google把TPU的脉动阵列细节一遍遍讲，到Cerebras更新晶圆级引擎，再到SambaNova、Groq这些公司把“dataflow”直接写进宣讲标题，数据流早已不是一个实验室概念，而是真实撑起了一批量产系统的底层设计哲学。这篇文章想把这些方案放在一起，梳理它们如何响应AI计算的两大矛盾，也把真正用起来时的代价说清楚。如果你是做AI平台、算力选型的工程师，或者对下一代芯片感兴趣的学生，这篇会把从芯片到编译器再到部署的完整链路串一遍，读完你至少能区分“PPT上的数据流”和“跑得了模型的系统”之间差在哪儿。

1. AI芯片的内存墙和功耗墙，为什么GPU越来越难扛

1.1 GPU统治AI计算，但两条硬墙已经顶到天花板

先说个基本事实：过去十年，AI算力的代名词基本就是GPU。英伟达从Pascal到Volta引入Tensor Core，之后Ampere、Hopper两代把矩阵算力推高了近一个数量级，CUDA生态又顺手把训练、推理、数据科学全部拉进同一个开发环境。所以无论是研究界还是工业界，所有人默认“AI芯片”约等于“GPU”。

可在HotChips上听几场报告你会发现，GPU有两条硬墙，而且基本已经顶到了天花板。第一条是内存墙。芯片算力增长每年超过60%，但是DRAM带宽和容量的增长长期只有20%上下。一个直观的账：H100这类旗舰卡的片上计算能力是千万亿次每秒级别，而HBM带宽只有3TB/s多一些。假设每个计算都需要从DRAM取两个操作数，那带宽需求会高出两到三个数量级。GPU能维持性能，靠的是把数据搬进片上的L1/L2缓存、反复复用，一旦数据布局不理想，实际利用率能掉到三成以下。第二条是功耗墙。把几百瓦的功耗压在先进封装上，散热已经非常吃力，而功耗主要消耗在数据搬运上：一次DRAM读写的能量通常是一次浮点运算的几十倍甚至上百倍。换句话说，大量芯片在做“算力”建模时经常忽略了搬运数据的成本，GPU做了这么多年就是不断上缓存、优化调度，本质上都是在打补丁。

这两条墙才是AI芯片出现架构分叉的根本原因。单靠制程升级已经压不住，于是才有各家厂商开始从“如何把计算组织得像算盘一样有节奏”的角度重新设计芯片。

1.2 指令驱动与数据驱动：两条路线的本质区别

“指令驱动”是指在冯·诺依曼框架下，每个计算单元在一个时钟周期内从内存取指令、译码、执行；GPU虽然成千上万核心，但它本质还是SIMT的指令驱动模式，由硬件调度器动态地把指令分发到有空闲的线程。CPU/GPU的世界观是“计算为中心，数据是原材料”。

“数据驱动”或者说数据流架构，世界观反过来。它把计算单元编排成一个网络：每个节点（如一次乘加）的输入数据一旦就绪，节点就自动执行，结果立刻转给下游节点。这里不依赖集中的指令流来控制时间节奏，而是数据的流动表示了时间关系。

生活化一点：CPU/GPU像一个大酒楼的调度中心——服务员不断拿着顾客订单跑来跑去，厨师听单做菜；数据流架构像一条固定的美食流水线——食材沿着传送带移动，每个工位只需要处理送到自己面前的那份原料，做完就推到下一站。对于规则、重复的工作，流水线显然更省事、更省调度成本。

为什么AI负载适合数据流？因为深度学习计算图是由一批固定形状的矩阵乘法、卷积、归一化、激活拼起来的，数据依赖关系在编译期就是完全确定的，且大部分算子非常规整。正因如此，流式执行计算图的顶层设计，在原理上天然比指令驱动更贴近AI的实际需求。

1.3 数据流架构到底在优化什么：算的不如搬的多

数据流架构优化目标，不是“算得快”而是“搬得少”。AI芯片的大部分能耗和延迟都花在搬数据上。从能耗层面看，一次浮点乘法的能量只有约0.02皮焦，但读取SRAM约为1皮焦，读取DRAM可以到几十皮焦以上，差距是数量级的。因此如果能把中间结果留在片上并直接流向下游算子，整体功耗和时延都会大幅下降。

数据流架构的收益可以归纳为三点：减少片内外数据移动、执行行为高确定性、编译期调度代替运行时动态调度从而降低控制开销。代价是什么呢？硬件不再通用，变成“运行前必须把计算图映射到硬件拓扑”的专用系统。这相当于把调度和资源管理的复杂度从运行时搬到了编译期，对软件栈的要求骤增。理解这一点，后面看任何一家公司PPT，你都会先问：编译器在哪？

2. HotChips上的四类数据流方案盘点

2.1 为什么关注HotChips：半导体圈的年度技术快照

1989年开办的Hot Chips，名义上是一个高性能芯片研讨会，实际上因为芯片公司愿意在这里分享架构细节，早已成为行业技术风向标。和ISSCC那种讲工艺、讲电路的会议不太一样，HotChips上的报告通常更偏体系结构，厂商会放出die照片、片上网络拓扑、编译器流程这类干货。

这些年AI芯片占据了HotChips的主要版面。看这类报告，我的习惯是先忽略TOPS/TFLOPs这类峰值数字，先找每个方案里“数据怎么走”：数据从哪读进来，中间结果放在哪，和下游算子怎么交接。数据流架构不是单一技术，而是一整个家族，它们共享一个原则：片上数据移动最大化，片外DRAM访问最小化。下面把HotChips上最典型的四条技术路线拆开看。

2.2 经典脉动阵列：Google TPU的化简逻辑

Google TPU是数据流思想落地最广为人知的案例。它采用的核心结构叫脉动阵列：一整块二维计算单元阵列，每个PE只做一个乘法加累加。以一次256x256的矩阵乘法为例，如果硬件有一块128x128的脉动阵列，输入数据会以每个周期一个元素的节奏从阵列上方和左侧流入，每个PE里的权重保持不变，部分和在阵列内流动，最终在阵列边缘得到输出。

整个过程没有显式的取指和译码，每个PE每个周期只做同一件事，控制逻辑被压缩到极致。由于消除了大量中间寄存器和调度电路，相同工艺下可以把计算密度做得非常高。TPU在HotChips上反复讲的脉动阵列部分，本质上就是在说：规则矩阵乘法的数据流是确定的，把它固化成硬件路径最省电。

脉动阵列的代价也很明显：不规则算子的效率极低，一旦遇到动态形状、稀疏访问、无法静态展开的循环，阵列的大部分单元只能空转。所以TPU很长一段时间只在Google内部处理完全可控的负载，不是因为不想对外，而是因为通用性撑不住。

2.3 晶圆级系统：Cerebras的大体积路线

Cerebras的思路是把整片晶圆做成一颗芯片，术语叫Wafer-Scale Engine。常规芯片要从晶圆上切割并单独封装，然后靠HBM等外部存储喂数据；Cerebras让所有裸片留在晶圆上，用片上互连把它们连成一个整体，同时堆了巨大的SRAM。第二代WSE-2有85万个核、40GB片上SRAM，第三代WSE-3把核数进一步提升到90万个，SRAM扩到44GB。

这种做法带来的最大变化是存储层次被改写。权重不再需要从HBM搬进来，而是直接放进靠近计算单元的片上SRAM，访存带宽比传统GPU高出一到两个数量级。为了支撑这么大的内存与计算阵列，Cerebras在HotChips上花大量篇幅讲的是“如何把几十个裸片连成一个一致的存储和计算系统”，而不是单纯堆算力。它甚至做了一套可自定义16位浮点格式，在有限的片上存储里尽量把精度和动态范围都留住。

制造难、散热难、编译器难，这是它公开的挑战。但对超大模型训练这个场景，权重常驻片上这一招，基本是把内存墙直接绕过去了。这也是数据流思想最极致的一种表达：既然搬数据贵，我就把数据和计算做到同一块硅片上。

2.4 可重构数据通路：SambaNova的软硬件再划分

SambaNova的方案更接近“粗粒度可重构阵列”，也就是CGRA。它的RDU芯片里布满了大量计算单元和存储块，但它们之间的数据通路不是出厂固定连死的，而是运行前由编译器配置成一张“数据流图”。模型跑起来后，数据就按照这张配置好的通路上流动，不需要再动态取指。

你可以把RDU想象成一块棋盘，上面有很多算力格子和存储格子，编译器决定格子之间的连线，也决定每个周期的通行方向。棋盘的连线不像TPU那样只针对矩阵乘优化，而是能表达更庞杂的计算关系。这意味着它可以承载注意力、卷积、归一化这类不同形态的算子，灵活性比纯脉动阵列好不少。

代价是硬件的可重构逻辑本身要占用面积，而且配置一次模型往往需要较长的编译时间。我在评估这类平台时最大的感受是，它把“GPU上运行时调度”变成了“编译时布局”，好处是效率高了，坏处是动态变化会非常疼。换一个batch size，换一个sequence length，可能在GPU上只是重新分配显存，在CGRA上却意味着重新编译、重新配置。

2.5 时间维度的调度：Groq的另一条路

Groq做了一个很激进的选择：它的LPU不搭任何片外DRAM，只保留片上SRAM。没有DRAM意味着没有传统意义上的“内存子系统”，权重和中间结果只能放在片上。那大模型权重放不下怎么办？Groq的回答是：让编译器把计算在时间轴上摊开，每一时刻每条ALU该处理哪个数据，都由编译器在编译期精确排好。

这套思路叫“时间架构”，或者说纯时序调度。你在Groq上跑一个模型，几乎可以精确到周期地预测延迟，因为系统里没有缓存未命中、没有内存控制器仲裁、没有分支预测失败。这对低延迟推理非常友好，比如一次LLM的decode请求，权重就在片上SRAM里，读取稳定且快。

但片上SRAM总容量有限，模型一大就得把权重切到多张LPU上，卡间通信承担起了原本由DRAM承担的搬运量。所以Groq评估客户的第一件事通常是问模型参数多大，权重超过多卡总容量后，效率会明显下降。它是把内存墙变成了管网拓扑墙——只要权重放得下，性能就是直通车。

2.6 四条路线放在同一张表里对比

把四条路线放在同一张表里，差异会非常清楚：

看这张表你会点头：数据流架构远不是一个模板，而是各自取舍。有人用空间换数据移动，有人用可重构换灵活性，有人用时间换物理存储。但它们的共同点也很明显：都试图减少随机访存，都强调编译期静态映射的价值。这也是为什么接下来真正需要深挖的是编译器。

3. 数据流架构的关键技术细节与落地难点

3.1 谁来控制数据流动：编译器是真正的核心

在数据流芯片上，模型不是“运行在硬件上”，而是“被翻译成硬件拓扑和调度”。CPU上你写一段C代码，运行时由指令流水线负责处理；GPU上你写一段CUDA代码，运行时由硬件调度器分发线程；到了数据流芯片，编译器几乎接管了原本运行时的全部决策。

典型流程分五步：前端把模型转换成编译器IR，然后做算子融合和图优化，接着把计算图中的节点映射到可用的计算单元，再为每个数据块决定它什么时候进哪个buffer、走哪条数据通路，最后生成配置位流和时序控制信息。这五步里任何一步出问题，芯片的实际利用率都会崩。SambaNova的SambaFlow、Groq的GroqCraft、Cerebras的Graph Compiler基本都是基于MLIR生态扩展出来的，这也是近几年MLIR被各家战略布局的原因——编译器已经不是“软件生态”，而是“芯片第二层硬件”。

我在实际项目里踩过最多次的坑是图优化阶段。编译器的算子融合规则没认出一个自定义激活函数，会把一个本该在片上完成的分支拆成十几个原子算子，中间结果被迫写回缓冲区，性能掉到原来的五分之一。所以评估一款数据流芯片，不能只看指令集丰不丰富，更要看编译器有没有覆盖你模型里所有形状的算子模式。

3.2 数据复用策略：同样的矩阵乘，三种走法

矩阵乘法的数据流组织方式在体系结构里有一套经典分类：权重静止、输入静止、输出静止。理解这三种，基本就理解数据流芯片为何快。

权重静止：权重先预装进所有PE，输入数据分批流过阵列，部分和在PE内部累加。适合权重尺寸较大、输入样本较多的场景，比如图像分类的卷积层。输入静止：一批输入固定放在PE中，权重不断流入，适合同一输入被大量不同卷积核扫描的情况。输出静止：每次乘加的部分和被留在PE里的累加器里不断更新，等累加完再一次性流出，适合输出特征图需要大量累加的场景。

用食堂打饭类比：权重静止就是厨师不动，学生排队经过窗口；输入静止就是学生坐好，厨师端着不同菜品来回送；输出静止则是每个窗口自己攒着一摞菜，等到齐了再端出来。编译器要做的就是在每个层上选出组合策略，还要考虑不同PE区域之间数据的交接。

仍以Attention里的QKV三个矩阵乘为例，Q和K相乘这一步中，K的权重适合静止，Q按批次流式进入阵列；到了QK^T与V相乘时，V的权重适合静止，而注意力矩阵按行流式进入。如果编译器布局把V的权重放错位置，部分和就要频繁写回中间缓存，注意力计算立刻变成搬运瓶颈。这种问题在GPU上可以通过缓存命中率看到，在数据流芯片上则是直接体现在PE利用率上。

3.3 片上网络与存储层次设计

数据流芯片的片上网络，与其说是“公路”，不如说是“地图”。因为数据流不是随机访问的，每个数据块的路径在一定程度上是编译期规划好的，片上网络需要做的是按路径高效送达，同时不阻塞相邻路径。

不同方案差异很明显：TPU的脉动阵列用规则的单向流水线，数据像传送带一样只朝固定方向走；Cerebras用同步全域互联把几十个裸片连成一个全局一致的阵列；Groq放弃大范围片上网络，改用每个ALU紧密绑定一块SRAM分区，让绝大多数数据在本地完成读写；SambaNova则用可配置的交叉开关，让编译器决定数据通路粗细。

存储层次方面，数据流芯片的共同倾向是堆SRAM、降DRAM。SRAM虽贵但速度快、能耗低，堆得起容量就能让更多计算在片上闭环。这也是为什么HotChips报告里，厂商都会把SRAM容量当成核心卖点。Cerebras把片上SRAM堆到几十GB，Groq把所有权重按切片分布在几百MB级SRAM中，都是为了让“最近的数据”离“最需要的ALU”更近。近存计算这个更大的趋势，本质上也是在重复这个逻辑。

3.4 数值格式、稀疏性与算子支持

数据流芯片对数值格式很敏感。FP16、BF16、FP8、INT8这些窄精度不只是位宽变小，还意味着同样面积的PE能放更多路计算，数据流更宽。Cerebras甚至自定义了CFloat格式，目的就是“在给定SRAM容量内，用可调的尾数和指数位数装下更多权重或中间值”。这类自定义格式虽然精度可控，但给模型迁移带来了额外工作——你必须验证自定义格式在你训练的模型上不会造成精度漂移。

稀疏性方面，结构化稀疏（比如2:4稀疏）在GPU上已经很成熟，数据流芯片却更难处理。因为稀疏意味着数据流分布不均匀，静态调度很难预测哪些PE会空转。部分方案通过编译器识别稀疏pattern并插入跳过逻辑来缓解，但动态稀疏（比如token pruning、激活稀疏）仍然是不小的坑。算子层面，凡是依赖动态长度、动态索引、树搜索的操作，在数据流架构里都是先天短板。

4. 部署数据流芯片的真实体验

4.1 算子覆盖率：第一个绕不过去的坎

我第一次把一组ONNX模型迁移到某款数据流芯片时，第一件事不是看算力，而是跑算子覆盖面扫描。扫描结果会告诉你哪些算子原生支持、哪些可以融合、哪些需要拆解、哪些完全不支持。真实业务模型里常见的不支持算子包括：非连续张量上的view、动态索引的TopK、带复杂条件的where分支。这些算子在GPU上都能用现成kernel执行，在数据流芯片上却可能把整张计算图卡住。

遇到不支持算子时，通常会走两条路：一是重写模型结构，把动态操作改成静态的等效计算；二是把那段计算留在主机CPU上，通过同步接口回传结果。第二种方式往往让性能骤降，因为CPU与数据流芯片之间的同步开销极大。所以我建议任何团队在选型数据流芯片之前，把目标负载里最重的10个模型先跑一遍移植测试，别用官方ResNet demo自欺欺人。

经验之谈：很多厂商给的“算子支持矩阵”只覆盖标准算子，可真实训练出来的模型经常带各种变体——比如自定义GELU近似、融合残差的写法。这时候编译器常常无法识别，把它拆成一堆细小算子，性能惨不忍睹。处理办法是维护一个算子替换表，把常见变体统一替换成厂商编译器能识别的标准实现，然后再做数值对齐测试。

4.2 LLM推理：这种架构的甜点和盲区

LLM推理可以被拆成两个阶段：prefill和decode。prefill阶段用户输入的prompt一次性过模型，计算量大、矩阵密集，本质上是“训练式的计算”，对算力利用率要求高；decode阶段逐token生成，每一步都要把所有权重读一遍，等价于一个纯访存任务。

数据流架构的真正甜点在decode。如果权重能驻留片上SRAM，decode阶段就不再需要反复访问HBM，延迟和功耗都会明显占优。这也是为什么像Groq这类无DRAM芯片在LLM的单样本低延迟推理测评里表现突出，它把解码阶段最痛的内存墙问题直接移除了。

盲区也很清楚：动态batch、beam search、长prompt的KV cache管理，这些都需要动态内存分配能力，而数据流芯片往往在编译期就把buffer规划死了。一个常见现象是：在GPU上把batch size从1改成4只需重新分配显存，在数据流芯片上却意味着重新编译一遍，耗时从几十秒到几十分钟不等。部署团队只能把线上常见的batch、sequence长度组合提前做成编译缓存，运行时在有限档位里选。模型再大一些，比如70B参数，权重没法全部塞进单卡SRAM时，跨卡通信的拓扑设计又会成为新的复杂度来源。数据流芯片在LLM推理上并不是通吃，它赢在“形状固定、权重放得下”的细分区间。

4.3 一个可复用的调优流程

在数据流芯片上调优，我总结出一套可复用的流程。

第一步，先把目标模型全部算子列出来，做成一张覆盖表，哪些原生支持、哪些需要替换，记录每个算子预期成本。第二步，用平台的profiler跑一遍基准任务，看每类算子的实际耗时和PE利用率，找出最差的10%。第三步，针对瓶颈段做重写：比如把多个小矩阵乘合并成一个大GEMM，改变数据布局让编译器能把更多算子做融合。第四步，调整编译器的布局选项和数据流策略，有时候只是把一个transpose提前，就能避免一整块buffer的搬移。第五步，把线上常见shape提前编译好，沉淀成“shape缓存池”，运行时按需取用。

具体例子：我在调一个对话模型时发现，batch从1跳到16，GPU上无感，数据流芯片每次都要重新布局，线上p99延迟从5ms直接飚到20ms。解决办法是预设batch档位1、2、4、8、16，全部提前编译，运行时按请求量选择最接近的档位，代价是显存里多占几份权重副本。这种“空间换编译时间”的思路，在数据流芯片部署中几乎是标配操作。

部署数据流芯片不是“装个驱动就完事”，而是要建立一套编译产物的管理、缓存、切换机制。这个机制的核心地位，不亚于GPU平台上的CUDA runtime。

5. 常见问题与选型避坑指南

5.1 关于数据流芯片的8个高频问题

5.2 三步法评估一款数据流芯片

我的建议是先跑通三步评估，再决定是否立项。

第一步，算子覆盖测试。拿自己真实业务里最重的模型做移植，记录原生算子占比、需要重写的算子数量、编译耗时。如果原生支持率低于80%，迁移工时可能高到你怀疑人生。第二步，可持续吞吐测试。连续跑24小时以上，记录芯片温度、降频行为、编译等待造成的空泡时间、p99延迟抖动。数据流芯片在冷启动和长时间运行后的表现差异，往往比GPU更明显。第三步，综合成本测算。不只算采购价，要把编译器工程师投入、模型迁移工时、shape缓存管理、故障排查成本都摊进去。有些数据流芯片的每瓦性能很好看，但软件团队的维护成本可能吃掉所有收益。

提醒一点：评估负载至少要覆盖线上80%的模型结构。官方demo只跑小模型、跑三次都是同一张resnet的，给再高的TOPS也只是纸面数据。宁可花一周时间在真实负载上跑出编译器警告，也不要花一天看PPT上的峰值算力。

5.3 该信HotChips演讲里的哪些数字

HotChips报告的技术含量通常很高，但也要学会读重点。首先，die size、SRAM容量、片上带宽、支持格式这类物理参数可信度较高，因为它们需要经过物理验证。其次，计算峰值、TOPS这类理论指标别当结论看，重点听他们怎么描述“编译器如何把真实模型映射到阵列上”，这一部分越具体，方案离落地越近。

再看benchmark的时候，要留意演讲者有没有给出完整配置：模型版本、batch大小、输入长度、芯片数量、是否包含主机同步开销。缺失这些细节的指标，基本不具备横向参考价值。我还习惯看演讲者的背景：如果一场报告一半时间在讲编译器，说明这家公司已经过了堆硬件阶段；如果全程都在讲“我们的算力是别人三倍”，那大概率还在拿纸面数据撑场面。

最后说几句

数据流架构这几年已经在HotChips上从“新物种”变成“常见物种”。我自己在评估多家平台时最大的体会是：它解决的问题比很多人以为的更大，但“用起来”的门槛也比PPT上写的高很多。真正决定一个AI芯片系统能不能落地，不是那张1000 TOPS的规格表，而是编译器认不认你的算子、搬运数据的成本能不能被布局优化压下来。

如果你未来有一天要选型这种架构，请一定把模型迁移工时、编译产物管理、线上shape调度这些工作算进预算里，这些往往比硬件本身更贵。正因如此，我判断下一代AI芯片的竞争，已经从“谁的片子更大”转向“谁的编译器更懂模型”——谁能把数据流映射得又准又稳，谁才是真正值得押注的方向。