每年八月中旬芯片圈子里有个不算最热闹、但绝对最硬核的例会HotChips。名字听起来像是“热门芯片”的缩写其实是“高性能芯片研讨会”在硅谷办了三十多年。你如果做AI基础设施、做编译优化或者正在替团队评估下一代AI芯片这个会的价值不在于看PPT模板而是能在几天之内看到各家公司把自家最核心的架构设计、内存层次、片上网络、编译器接口这些硬骨头拖出来讲清楚设计取舍。这两年我在HotChips现场和会后的技术交流里感受最强烈的一个信号就是数据流架构芯片已经从一个学术概念变成了真正的产业方向。大家已经不太争论“要不要数据流”而是争论“数据流放在哪一层、由编译器还是运行时来管”。这篇文章想把这件事讲透数据流架构为什么在这两年被反复提起HotChips上几家的方案差异在哪以及作为一线工程师拿到一款数据流AI芯片之后应该怎么评估、怎么避坑。适合的人有两类一类是准备做AI芯片选型的架构师另一类是搞AI训练推理平台的系统工程师。1. HotChips到底是什么一年一度的“芯片总披露现场”1.1 一个只聊“怎么做芯片”的硬核会议HotChips全称是HotChips: A Symposium on High-Performance Chips每年夏天在硅谷举办。它和ISSCC、MICRO、ISCA这些学术会议最大的不同是ISSCC更偏工艺、器件、模拟电路和SerDes物理层MICRO和ISCA更偏学术论文和算法创新而HotChips站在工业界与学术界的交界处很多公司会在这里做“产品级”的架构细节披露。来演讲的人经常是首席架构师、fellow、首席技术官这一类角色讲的内容不是“我们有个很牛的想法”而是“我们这颗芯片是怎么一步步做出来的”。我常提醒刚入行的朋友看HotChips不要把注意力只放在标题和结论上。很多报告的slide里内存层级的图、片上网络的带宽标注、功耗分布表格比那一页“性能提升XX%”重要得多。这些细节能帮你判断一个架构是不是真的能落地是不是只是把频率拉高或者把缓存加大。尤其近几年各家AI芯片的营销话术太多但HotChips上那些绕不开的工程细节——供电怎么走、散热怎么解、编译器怎么切图——反而最诚实。1.2 在HotChips上看到的架构信号AI芯片进入“架构收敛期”过去十多年HotChips的主线从多核CPU之争转到了GPU、FPGA、再到AI专用加速器。最近三届明显能看到一个趋势大家都在谈数据流。NVIDIA、AMD、Intel这些老牌厂商会在报告里强调Tensor Core、矩阵引擎内部的规则化数据复用Cerebras、SambaNova、Groq这些新玩家则直接把自己定义为数据流芯片。为什么会在这个时间点集中冒出来核心原因是AI计算负载的特征越来越稳定。现在的Transformer系列模型无论是Attention、FFN还是MoE里的路由本质上是极其规则的张量计算。计算高度结构化数据并行、流水线并行都能提前规划。这种负载放在通用CPU上非常浪费因为CPU花了大量晶体管在分支预测、乱序执行、缓存一致性上放在GPU上也有些浪费因为GPU虽然并行度高但指令发射和线程调度的开销依然存在。数据流架构恰恰可以把计算图静态映射到计算单元阵列上让数据像流水一样推进省掉大量“取指、解码、调度”的开销。这就是HotChips上数据流芯片越来越有存在感的最底层原因。2. 数据流架构的核心逻辑从“指令驱动”到“数据驱动”2.1 控制流架构为什么在AI负载下吃亏先说一个生活化的类比。一个通用CPU就像一个大厨手里拿着菜谱逐行执行拿菜、洗菜、切菜、起锅烧油、下锅翻炒……每一步都在看菜谱、理解菜谱、决定下一步。这没问题因为菜谱有各种分支——如果客人不吃辣就跳过辣椒。但问题在于AI场景更像“一个厨房一天要做几万份一模一样的汉堡”每一份汉堡的配料顺序、火候、拼装方式都完全一致。这时候如果每个汉堡都让同一个大厨按菜谱一步步来他大部分精力不是花在“做汉堡”上而是花在“读菜谱”和“拿原材料”上。放到芯片里也一样。传统指令驱动处理器每条指令都要经历取指、解码、发射、执行、回写为了掩盖内存延迟还得做分支预测、乱序执行、寄存器重命名。这些机制在通用计算里很有价值但在AI计算里属于巨额开销。更关键的是AI模型的瓶颈早就不是算力而是访存权重要从DRAM搬进计算单元中间结果要写回DRAM下一层再读出来。数据搬来搬去比计算本身更耗时间、更耗电。2.2 数据流架构如何“反着来”数据流架构的思路一句话概括让数据寻找计算而不是让控制器寻找指令。计算单元先布成一个阵列数据按照预先规划好的路径在网络中流动数据到达哪个算子哪个算子就被激活。整个执行过程没有程序计数器没有传统意义上的取指和解码因为什么时候算、在哪算、算完传给谁在编译期就已经定了。需要注意这不等于完全不做动态控制。它只是把大量的调度工作从硬件运行时阶段提前到了编译器阶段。所以你会看到所有数据流芯片厂商都在强调自己的编译器有多强。这也意味着买一颗数据流芯片本质上是在买“硬件编译器”这个联合体硬件只是靠软件才能发挥出应有性能。这一点如果没想清楚后面大概率会踩坑。2.3 三种代表性的落地路线脉动阵列Systolic Array代表是Google的TPU。把很多个乘加单元排列成矩阵数据像波浪一样在阵列中逐拍流动每个PE只和相邻PE通信复用率极高。优点是极其适合矩阵乘法和卷积缺点是灵活性差遇到不规则算子就比较难受。粗粒度可重构架构CGRA代表是SambaNova。阵列里是一堆可配置的计算单元和可配置的互连网络编译器像布线工程师一样为每个算子安排计算单元、存储位置和数据路径。灵活度比脉动阵列高但编译器压力更大。静态调度数据流Static Dataflow代表是Cerebras和Groq。把整个模型的计算图展开根据数据依赖直接部署到成千上万个计算核心上。Cerebras甚至把整块晶圆做成一颗芯片Groq则干脆把片上SRAM当主内存用编译器要把所有权重和中间变量都安排得明明白白。还有一个容易被忽略的事实GPU内部其实也在“数据流化”。NVIDIA从Volta这一代开始加入Tensor Core本质上是把规则化矩阵运算放到专用的张量核心上数据和累加路径高度静态复用。到了Hopper和BlackwellTransformer Engine的出现更是让精度选择也变成了编译器和硬件共同完成的动态决策。所以不要总把数据流芯片和GPU对立起来更准确的说法是数据流正在不断往主流处理器内部渗透。3. 从HotChips近几届看数据流芯片的全景拆解3.1 Cerebras WSE-3把整块晶圆变成一颗芯片Cerebras在HotChips上的报告一直很有冲击力因为它的思路是传统芯片先把晶圆切成一个个小片再封装芯片之间靠PCB走线通信带宽被引脚数量限制Cerebras反过来直接把整片晶圆当成一颗芯片用。WSE-3根据公开口径大约有90万个AI核心片内SRAM在几十GB量级所有核心之间靠极高的片上互连带宽交换数据几乎不需要频繁访问外部DRAM。这套方案放在数据流架构框架下看就是把“数据流巨量片上存储”推到了极限大模型权重尽量一次性放进片内SRAM中间结果也在片上传递彻底缓解存储墙问题。当然代价也很明显良率怎么保证、整片晶圆怎么供电、怎么散热都是极其硬核的工程问题。所以Cerebras的整机系统形态更像一个超大号加速器适合超大规模训练场景一般客户直接拿来做GPU替代并不现实这一点在选型时要有清醒认知。3.2 SambaNova SN40L编译器优先的可重构数据流SambaNova是“compiler-first”喊得最响的一家。它的RDUReconfigurable Dataflow Unit采用多die封装内部是一大片可重构的数据流计算阵列配上HBM和DDR多级内存。SN40L大概是2023到2024年前后披露的新一代产品官方给的晶体管数量在千亿量级。它最大的特点是你写PyTorch或者JAX模型RDU编译器会把模型编译成一个数据流图静态映射到计算单元阵列上。对于开发者来说你不需要像写CUDA那样手工管理线程、显存拷贝这对很多AI应用工程师是一个很大的吸引力。但“编译器优先”的另一面是编译器能支持的算子集合和模型结构是有边界的。如果你的模型里用了比较新的自定义算子而编译器还不支持那就要等厂商更新编译器或者自己写算子映射。这种等待在很多快速迭代的团队里是难以接受的。SambaNova的优势在于一旦编译成功硬件利用率通常很高能效比也漂亮。3.3 Groq LPU与Graphcore IPU内存就是编译器最大的战场Groq在HotChips上讲解LPULanguage Processing Unit时最特别的一点是芯片里没有传统意义上的大容量外部DRAM而是靠片上SRAM当作主内存。它的思路是把延迟控制在极低水平让编译器把模型的所有权重和中间激活值都提前放进SRAM里。这样做的好处是推理响应速度非常快尤其做逐token生成的LLM推理时不用频繁访问外部内存延迟会很好看。坏处是单芯片的内存容量有限大模型必须跨多张卡拆分而跨卡通信的拓扑和带宽就会成为新的瓶颈。Graphcore的IPU是另一款长期在HotChips上露面的数据流型处理器。它把很多处理器核心和片上SRAM组合在一起强调“把所有数据交换尽量留在片上”也靠编译器静态规划和运行时调度结合。Graphcore这几年的商业命运有些波折但这不影响它作为数据流架构探索样本的价值它证明了编译器调度、片上存储管理、流式计算这些技术方向是可行的只是生态壁垒比很多人想象的要高。3.4 用一张表格看清各家的架构取舍维度Cerebras WSE-3SambaNova SN40LGroq LPU主流GPU以NVIDIA H100为例架构思路晶圆级数据流可重构数据流编译器优先静态调度数据流SRAM当主存通用GPU内部Tensor Core计算核心约90万AI核心可重构数据流PE阵列每芯片大规模张量核心阵列SM中集成Tensor Core片上存储数十GB SRAM量级HBMDDR多级内存单芯片约8GB SRAM量级HBM3/HBM3e大容量显存编译器角色静态图映射分布式部署编译器负责全图调度编译器负责全部内存规划CUDA生态相对成熟典型场景超大模型训练/推理大模型训练推理、企业级部署低延迟、高吞吐LLM推理通用训练和推理这张表格不是拿参数硬碰硬因为每家公开数据的口径差别很大我想表达的核心是它们都在用数据流的思路去解决同一个问题——减少数据搬运、提高计算密度但切入角度完全不同。Cerebras把重点放在“片上空间够不够大”SambaNova放在“硬件能不能被编译器灵活重构”Groq放在“延迟能不能压到极致”。这提醒我们看数据流芯片不能只看一个指标要看它的设计约束到底在解决什么问题。4. 编译器与软件生态数据流芯片的“另一半战场”4.1 为什么数据流芯片的成败有一半在编译器很多人第一次接触数据流芯片时会有个错觉它应该像GPU一样装好驱动就能跑。实际完全不是这样。数据流芯片的编译器至少要做四件事把计算图切分到PE阵列上决定每个数据块放在片上SRAM还是片外DRAM决定数据什么时候从哪个存储挪到哪个计算单元生成每个PE的微码或配置。这相当于在开拍前给几百个演员排一场精确到秒钟的走位导演就是编译器。所以数据流芯片厂商的核心竞争力根本不是硬件本身的技术参数而是编译器能不能高效、稳定地把模型映射到硬件上。这也是为什么SambaNova一直强调“编译器优先”Groq花大篇幅讲自己的编译器工作流。如果一个数据流芯片的编译器覆盖不了当前主流模型的算子那硬件上的TOPS再高也转化不成实际性能。4.2 软件栈的演化从手工kernel到MLIR生态GPU生态之所以强大是因为CUDA经过十几年积累已经形成了一个从底层库到高层框架的完整体系。数据流芯片想用同样方式追赶是不现实的更现实的做法是在统一的编译生态之上做定制。TVM当年打开了“AI编译器”的思路让一份模型定义可以尝试针对不同硬件做代码生成。MLIR的出现则提供了一个多级IR中间表示框架硬件厂商可以在MLIR之上定义自己的dialect描述硬件能力和计算图映射约束。现在主流的数据流芯片公司基本都在MLIR或类似生态上做编译器。用户在高层还是写PyTorch/JAX编译器负责逐层下降到硬件IR再到PE配置。这件事的好处是硬件厂商不需要从零造一套编译生态坏处是无论底层框架多统一算子覆盖、内存规划、并行策略仍然需要大量针对自家硬件的迭代。最终呈现给用户的依然是“这个模型能不能支持”“编译要多长时间”“动态形状能不能处理”这些直接的问题。4.3 当模型演进比编译器快时才是真正的风险数据流芯片最怕的事情不是性能不够而是模型结构变化太快、编译器跟不上。回顾这几年模型从CNN演进到Transformer从密集模型演进到MoE再到Mamba、混合架构速度非常快。GPU因为有成熟的软件栈和大量kernel库新算子出现后社区很快就能补上而数据流芯片如果要支持一个新算子往往要等厂商编译器团队排期开发、优化、测试。这个周期对一个快速迭代的算法团队来说可能等不起。我在实际接触中见过几家团队因为某款数据流芯片在某个模型上性能特别亮眼就决定用它做推理平台结果过了一个季度换了个新的注意力变体发现编译器不支持只能回到GPU上重新部署。这不是说数据流芯片不行而是说选型时一定要把“编译器对模型迭代的响应速度”当成核心风险来评估。5. 实操视角怎么判断一款数据流AI芯片值不值得用5.1 看HotChips报告时要把重点放在哪拿到一款数据流芯片的报告不要只盯着TOPS、TFLOPS这类峰值算力。更值得关注的维度我按优先级排序持续算力而非峰值算力要看在整机功耗和散热约束下实际能维持多少性能。片内存储容量与带宽能装下多大模型、中间激活数据是否放得下直接决定外部访存频繁度。编译器算子覆盖清单最好能找到官方支持模型结构的完整列表。动态形状支持程度LLM推理里batch size和序列长度经常变化编译器能不能动态处理还是每次都要重新编译。多卡扩展拓扑跨芯片通信走什么互连是环形、网状还是交换机瓶颈在哪。软件生态完整度是否支持主流推理框架、K8s集成、监控日志、量化压缩工具。这些信息在HotChips报告里不一定都有但通常可以在厂商公开文档和技术支持那里问到。5.2 我习惯用的评估清单我会尽量用一套固定流程来评估一款数据流芯片避免被厂商的演示效果带偏。第一步准备一个端到端的典型模型最好是自家真实业务里的LLM或者推荐模型第二步确认模型能否不修改、或小幅修改就跑起来这能快速看到编译器兼容性第三步分别在离线batch场景和在线流式场景下测性能在线流式对延迟更敏感很多数据流芯片只优化了离线吞吐第四步测动态形状输入比如变长序列看编译是否频繁重编译第五步了解量化支持和稀疏化利用情况第六步计算总拥有成本包括功耗、机柜空间、散热、人力维护以及算法团队要额外花多少时间配合硬件特性第七步把编译时间、新算子迭代时间作为重要指标记录在案。这套流程走完基本能判断一家数据流芯片是“帮你省事”还是“让你额外承担很多软件适配成本”。5.3 几条容易踩的坑只看峰值算力忽略持续性能。数据流芯片在短时突发的表现可能很好但整机散热和功耗控制跟不上时实际吞吐会掉得很厉害。以为动态batch是标配。很多数据流架构为了追求静态调度对动态batch和变长序列支持不彻底一上线流式请求就出问题。低估编译时间对迭代的影响。模型稍微改一版重新编译可能需要几十分钟甚至更久这对算法团队是很大的时间成本。误以为多卡扩展无限接近线性。数据流芯片扩展能力高度依赖计算图切分方式跨卡通信一旦成为瓶颈扩展性会断崖式下降。忽略可调试性。在GPU上跑模型出现问题可以用成熟的profiler和debug工具定位很多数据流芯片的可观测性很弱出了问题很难定位是编译器映射问题还是硬件问题。这些坑不是某一家独有的而是数据流架构本身的特点。你接受它的高性能和高能效优势就不得不同时接受它的编译约束和调试难度。6. 对下一代AI芯片走向的几点朴素判断6.1 数据流会成为标配能力而不是某个门派标签短中期来看我们不会看到所有芯片都变成纯数据流但一定会看到越来越多“数据流化”的模块出现在主流芯片里。GPU继续在Tensor Core上做文章CPU开始集成更多AI协处理器NPU普遍采用类似CGRA的阵列结构。未来的AI芯片拼的不再是“你用了什么流派”而是“在某个软件栈约束下硬件实际利用率有多高”。6.2 决定下一代AI芯片命运的很可能不是算力我更关注的三个变量是模型结构的不确定性、互连与存储墙、软件生态的响应速度。模型结构如果继续向规则化、可压缩的方向发展数据流架构的优势会进一步放大如果出现完全非规则的计算模式那灵活性和编译器迭代能力会比算力更重要。互连和存储方面单芯片算力增长快带宽增长慢跨芯片通信和片内SRAM容量会越来越成为决定性因素。至于软件生态数据流芯片公司如果没有一支足够强的编译器团队硬件做得再好也难真正进入生产环境。我个人这两年看下来最大的感受是不要拿数据流芯片和GPU当作同一种东西做benchmark。GPU是一套成熟到已经靠CUDA生态给硬件“兜底”的通用系统数据流芯片更像一个对软件栈高度挑剔的跑车调好了确实能跑出高能效调不好连“上牌”都难。所以在HotChips上听架构师讲得天花乱坠之前先把编译器打开跑一次真实场景下的模型再说。如果你正在做AI服务器选型多问问编译器团队的规模、新增算子的周期、动态形状支持的成熟度。这些往往比那些漂亮算力数字更能决定项目的成败。