1. 从HotChips看数据流架构的崛起逻辑
1.1 为什么今年的HotChips让数据流架构成了焦点
每年HotChips放出来的架构信号，基本就是未来两三年芯片圈的风向标。今年我翻完几个主要场次的资料后，最直观的感受是：数据流架构（Dataflow Architecture）不再是学术圈的自嗨，而是被工业界真正推到了量产芯片的核心位置。前几年大家聊AI芯片，翻来覆去就是脉动阵列、乘加树、存内计算这几个词，但今年你会发现，越来越多的设计开始围绕“数据怎么流动”来做文章，而不是单纯堆算力。
这个转变背后的逻辑其实不复杂。传统冯诺依曼架构下，计算单元和存储单元是分离的，数据要在两者之间来回搬运。AI负载的特点是计算密度高但数据复用模式复杂，搬运开销往往比计算本身还大。我实测过一些推理场景，在典型卷积网络里，数据搬运的能耗能占到总能耗的60%到80%，真正用于乘加运算的能耗反而不到两成。数据流架构的核心思路就是让数据在计算单元之间“流动”起来，减少不必要的往返，把搬运开销压下去。
HotChips上几个比较有代表性的设计，比如一些面向大模型推理的加速器，都采用了粗粒度的数据流调度策略。它们不再把每一层算子拆成独立的kernel去执行，而是把整个计算图映射到硬件上，让中间结果直接在片上流转。这种做法的好处是显而易见的：片上带宽利用率大幅提升，端到端延迟显著降低。当然代价也很明显，编译器和调度器的复杂度直线上升，这是后话。
1.2 数据流架构到底解决了什么核心问题
要理解数据流架构为什么重要，得先搞清楚传统架构在AI负载下的瓶颈在哪。我画个简单的类比：传统架构像是一个中央厨房，所有食材都要先送到仓库，厨师需要什么再去仓库取，做完的菜又送回仓库，最后再端出去。数据流架构更像是流水线厨房，食材从一端进去，经过各个工位逐步加工，最后成品从另一端出来，中间不需要反复进出仓库。
具体到技术层面，数据流架构主要解决三个问题。第一是数据复用，通过把计算单元组织成特定的拓扑结构，让同一个数据能被多个计算单元共享，减少重复读取。第二是并行度挖掘，数据流天然支持流水线并行和空间并行，不同计算节点可以同时处理不同数据。第三是能效优化，数据在片上流动的距离越短，驱动它所需的能量就越少，这是物理层面的硬道理。
HotChips上有个设计让我印象很深，它把权重和激活值的流动路径完全分开，权重走一条固定的广播路径，激活值走另一条逐级传递的路径。这种设计在矩阵乘法为主的负载下，权重读取次数能降低一个数量级。当然，这种架构对权重的静态性有要求，如果权重频繁变化，优势就不明显了。所以你看，数据流架构不是万能药，它的适用场景是有边界的。
1.3 从HotChips看架构演进的几个明显趋势
把今年HotChips上相关的内容串起来看，数据流架构的演进有几个趋势值得关注。第一个趋势是从细粒度向粗粒度演进。早期的数据流架构多是细粒度的，每个计算节点独立触发，灵活性高但调度开销大。现在更多设计采用粗粒度数据流，以算子块或图层级为调度单位，编译时就能确定大部分数据流动路径，运行时开销小很多。
第二个趋势是异构融合。纯数据流架构在处理控制密集型任务时效率不高，所以现在很多设计把数据流核心和通用核心放在一起，让它们各司其职。HotChips上有款芯片就是这种思路，数据流阵列负责矩阵运算，旁边的RISC-V小核负责控制流和标量计算，两者通过共享缓存交互。
第三个趋势是存储层次的重构。数据流架构对存储的要求和传统架构完全不同，它需要的是高带宽、低延迟、可预测的片上存储。所以你会看到很多设计把SRAM做得很大，甚至把一部分权重直接固化在片上，用面积换能效。这种取舍在边缘推理场景下特别常见，因为边缘设备对功耗敏感，对成本相对宽容。
2. 数据流架构芯片的核心技术拆解
2.1 计算阵列的拓扑结构选择
数据流架构最核心的部分就是计算阵列怎么组织。常见的拓扑结构有几种：脉动阵列（Systolic Array）、二维网格（2D Mesh）、树形结构（Tree）和环形结构（Ring）。每种结构都有它的适用场景，选型时主要看你的负载特征。
脉动阵列大家最熟悉，TPU就是典型代表。它的特点是数据像心跳一样有节奏地流过阵列，每个计算单元只和邻居通信。这种结构的优势是布线简单、时钟频率容易做高、数据复用率高。但缺点也很明显：灵活性差，只适合规则的矩阵运算，遇到稀疏矩阵或非规则计算就抓瞎。而且脉动阵列的利用率高度依赖矩阵维度匹配，如果矩阵尺寸和阵列尺寸对不上，填充浪费会很严重。
二维网格结构更灵活一些，每个计算单元可以和上下左右邻居通信，路由算法可以做得比较复杂。这种结构适合处理不规则的计算图，但布线拥塞和功耗是挑战。HotChips上有设计采用分层网格，把大阵列拆成多个小簇，簇内用网格，簇间用总线，算是一种折中。
树形结构适合做归约操作，比如求和、求最大值这类。它的通信延迟是O(logN)，比网格的O(√N)好很多。但树形结构的根节点容易成为带宽瓶颈，所以通常和其他结构混合使用。
环形结构在Transformer类模型上表现不错，因为注意力机制的计算模式有环形特征。有些设计专门为注意力算子做了环形数据流，键值对在环上循环流动，查询向量依次和它们交互，这样权重读取次数大幅减少。
选拓扑结构时别只看峰值算力，要拿你的实际负载去模拟。我见过太多设计峰值算力很漂亮，但实际模型跑上去利用率不到30%，问题就出在拓扑和负载不匹配。
2.2 片上存储层次的设计取舍
数据流架构对存储层次的设计要求很特殊。传统架构的缓存层次是“通用”的，L1、L2、L3层层递进，靠缓存命中率来提升性能。但数据流架构的数据流动是可预测的，编译器在编译时就知道数据什么时候从哪里来、到哪里去，所以不需要靠硬件缓存去猜。
这就引出了数据流架构存储设计的核心思路：用软件管理的暂存器（Scratchpad）替代硬件管理的缓存。暂存器是一块显式地址的SRAM，编译器负责把数据搬进来、搬出去，硬件不做任何替换决策。这样做的好处是能耗大幅降低，因为不需要标签比对、不需要替换策略、不需要一致性维护。坏处是编译器负担重，而且一旦编译器调度不好，性能会断崖式下跌。
HotChips上几个设计都采用了多级暂存器结构。最靠近计算阵列的是一级暂存器，容量小但带宽极高，通常和计算单元做在同一个时钟域。往外是二级暂存器，容量大一些，带宽稍低，负责在计算阵列和外部存储之间做缓冲。再往外可能是共享的L2或者直接连到HBM。
容量怎么定？有个经验公式可以参考：一级暂存器容量至少要能放下一个完整的权重块和对应的激活块。比如你做128x128的矩阵乘，权重块是128x128，激活块是128x1，那暂存器至少要能放128x129个元素。实际设计时还要留一些余量给流水线气泡和双缓冲。
2.3 数据流调度与编译器协同
数据流架构的编译器不是传统意义上的编译器，它更像是一个空间映射器。它的工作是把计算图映射到硬件资源上，决定每个算子在哪几个计算单元上执行、数据怎么在暂存器之间流转、什么时候触发同步。
这个映射问题本质上是NP难的，所以实际编译器都采用启发式算法。常见的方法有列表调度（List Scheduling）、模拟退火（Simulated Annealing）和整数线性规划（ILP）。列表调度速度快但解质量一般，模拟退火解质量好但编译时间长，ILP适合小规模问题。
HotChips上有家公司的编译器采用了分层映射策略：先做粗粒度的算子融合和分区，再做细粒度的指令调度。粗粒度阶段决定哪些算子合并成一个数据流区域，细粒度阶段决定每个区域内的数据路径和同步点。这种分层方法的好处是编译时间可控，同时解质量也还不错。
编译器的另一个重要任务是双缓冲插入。数据流架构里，计算单元不能停等数据，所以需要在暂存器里做双缓冲，一块在算的时候另一块在加载。编译器要自动识别流水线阶段，在合适的位置插入双缓冲逻辑。这个如果靠手写，工作量巨大且容易出错。
评估一个数据流架构芯片好不好用，别光看纸面算力，一定要问编译器成熟度。我见过硬件参数很漂亮的芯片，因为编译器太烂，实际模型部署时性能打三折。
3. 数据流架构芯片的实操评估方法
3.1 如何用实际模型评估架构效率
拿到一款数据流架构芯片，怎么判断它适不适合你的负载？我的做法是分三步走。第一步是算子级微基准测试，把模型里的关键算子单独拎出来跑，看每个算子的利用率和延迟。这一步能快速定位瓶颈在哪个算子。第二步是子图级测试，把相关的几个算子串起来跑，看数据在算子间的流转效率。第三步是全模型端到端测试，看整体延迟和吞吐。
微基准测试时要注意，数据流架构对数据布局很敏感。同一个卷积算子，NHWC和NCHW布局的性能可能差好几倍。所以测试时要覆盖不同的布局，找到最优的那个。另外，batch size的影响也很大，数据流架构通常在小batch下效率更高，因为权重可以常驻片上。batch大了之后，激活值占用的存储增加，权重被挤出去，效率反而下降。
子图级测试主要看算子融合的效果。数据流架构的一大优势是能把多个算子融合成一个数据流区域，中间结果不落外部存储。但融合不是越多越好，融合太多会导致暂存器不够用，反而要溢出到外部存储。所以测试时要找到融合的甜点区。
全模型测试时，我习惯用每秒处理token数或者每秒处理帧数来衡量，而不是单纯看算力利用率。因为用户关心的是端到端性能，不是某个算子的效率。另外要关注尾延迟，数据流架构的延迟通常比较稳定，但如果编译器调度不好，偶尔会出现长尾。
3.2 功耗与能效的实测方法
数据流架构的卖点之一就是能效，但能效这东西纸面参数和实测往往差距很大。实测时我推荐用功耗分析仪配合性能计数器一起看。功耗分析仪给出实时功耗曲线，性能计数器给出每个模块的活动情况，两者对照就能知道功耗花在哪了。
具体操作上，先跑一个空载程序，测出静态功耗。然后跑不同负载，测出动态功耗。动态功耗除以吞吐量就是能效。注意要区分典型功耗和峰值功耗，很多芯片标的是峰值能效，但实际跑模型时根本达不到峰值。
还有个坑是电压频率缩放的影响。数据流架构通常支持DVFS，但不同电压频率下的能效曲线不是线性的。我实测过一款芯片，在0.8V时能效最优，但频率只有标称的60%。如果强行拉高频率，能效会急剧恶化。所以部署时要根据实际负载调DVFS策略，别一味追求高频。
测能效时记得把IO功耗算进去。有些芯片核心功耗很低，但HBM接口功耗很高，整体能效并不好看。特别是大模型推理，权重加载的IO功耗占比不小。
3.3 编程模型与工具链的成熟度判断
数据流架构的编程模型和传统GPU完全不同，这是很多团队踩坑的地方。GPU上你写CUDA，线程怎么调度、内存怎么访问，硬件帮你管大部分。数据流架构上，你得显式描述数据怎么流动、什么时候同步，编程负担重很多。
评估工具链成熟度，我主要看几个方面。一是算子库覆盖度，常用算子是不是都有优化实现，还是得自己手写。二是编译器稳定性，同样的模型编译两次，生成的二进制是不是一致，会不会偶尔编译失败。三是调试工具，有没有性能分析器、有没有可视化数据流图、能不能单步调试。
HotChips上有些设计提供了Python前端，让用户用类似PyTorch的语法描述模型，然后编译器自动映射到数据流硬件。这种抽象层次对用户友好，但灵活性会打折扣。如果你的模型有特殊算子，可能还是得用底层接口手写。
还有个容易被忽视的点是多芯片扩展。单芯片性能再强也有上限，实际部署往往要多芯片互联。数据流架构的多芯片扩展通常通过片间数据流实现，一个芯片的输出直接流到另一个芯片的输入。这种模式对编程模型有额外要求，需要支持跨芯片的数据流描述。评估时要问清楚多芯片编程的难度和效率。
4. 数据流架构落地中的常见问题与排查
4.1 性能不达预期的典型原因
数据流架构芯片性能不达预期，原因通常集中在几个地方。最常见的是暂存器溢出。编译器把太多数据塞进暂存器，导致频繁溢出到外部存储，性能断崖式下跌。排查方法是看编译报告里的暂存器使用率，如果超过80%就要警惕了。
第二个常见原因是同步开销过大。数据流架构里，不同计算单元之间需要同步，如果同步粒度太细，同步开销会吃掉大部分性能。排查方法是看性能计数器里的同步等待时间，如果占比超过20%，说明同步太频繁了。
第三个原因是数据布局不匹配。数据流架构通常对数据布局有偏好，如果输入数据的布局和硬件期望的不一致，就需要额外的转置操作，性能损失可能达到30%以上。排查方法是看编译报告里的布局转换次数，如果很多，就要考虑在数据预处理阶段就转好。
第四个原因是编译器调度不佳。这个最难排查，因为编译器是个黑盒。我的经验是，如果前三个原因都排除了，性能还是不行，那大概率是编译器的问题。这时候可以试试手动指定一些调度策略，或者换一个编译器版本。
4.2 精度与数值稳定性的坑
数据流架构为了追求能效，往往会在数值精度上做文章。比如用FP16或者BF16代替FP32，用定点数代替浮点数。这些取舍在大多数情况下没问题，但在某些模型上会导致精度下降甚至训练不收敛。
我踩过的一个坑是累加器精度。数据流架构的乘加阵列通常用低精度乘法，但累加器要保持高精度。如果累加器精度不够，大矩阵乘法的结果会累积误差。排查方法是拿一个已知结果的矩阵去跑，看误差是否在可接受范围内。
另一个坑是激活函数的数值范围。低精度下，激活函数的饱和区会变窄，导致梯度消失或爆炸。特别是Transformer类模型，注意力分数经过softmax后，低精度下的数值稳定性需要特别关注。我的做法是在关键位置保留高精度计算，比如softmax的输入输出用FP32，中间计算用FP16。
精度问题往往在模型训练后期才暴露，前期loss看着正常，后期突然发散。所以用数据流架构做训练时，一定要监控数值范围，别等到发散了才回头查。
4.3 多芯片互联的实操问题
多芯片互联是数据流架构扩展的必经之路，但实操中问题不少。第一个问题是片间带宽瓶颈。单芯片内数据流带宽很高，但片间带宽通常低一个数量级。如果模型切分不好，片间通信量太大，整体性能会被拖垮。排查方法是统计片间通信量，和片内通信量对比，如果片间占比超过30%，就要重新考虑切分策略。
第二个问题是同步延迟。多芯片同步比片内同步慢很多，如果同步太频繁，延迟会累积。我的经验是尽量做粗粒度同步，比如一个完整的层算完再同步，而不是每个算子都同步。
第三个问题是死锁。数据流架构的多芯片系统里，如果数据流路径设计不当，可能出现循环等待导致死锁。排查方法是看是否有芯片长时间处于等待状态，同时其他芯片也在等待。避免死锁的方法是保证数据流是有向无环的，如果必须有环，要加超时机制。
第四个问题是热管理。多芯片系统功耗密度高，散热是个挑战。如果散热不好，芯片会降频，性能波动大。实操中要监控每颗芯片的温度，如果温差超过10度，说明散热不均匀，需要调整风道或液冷方案。
5. 数据流架构的适用边界与选型建议
5.1 什么场景适合数据流架构
数据流架构不是万能的，它有明确的适用边界。最适合的场景是计算模式规则、数据复用率高、延迟要求稳定的负载。比如卷积神经网络推理、Transformer推理、推荐系统里的嵌入查表，这些场景数据流架构能发挥最大优势。
具体来说，如果你的模型满足以下条件，数据流架构大概率是好选择：算子类型集中，主要是矩阵乘、卷积、激活这些；权重相对静态，不需要频繁更新；batch size不大，权重能常驻片上；延迟要求稳定，不能有长尾。
反过来，如果你的模型控制流复杂、算子种类繁多、动态shape频繁变化，那数据流架构可能不是最优解。这种情况下，通用GPU或者带可编程逻辑的异构架构可能更合适。
还有个容易被忽视的维度是模型迭代速度。数据流架构的编译器通常对模型结构有假设，如果模型结构频繁变化，编译器可能跟不上。所以如果你的团队处于快速试错阶段，数据流架构可能会拖慢迭代速度。等模型结构稳定了再上数据流架构，可能是更务实的策略。
5.2 选型时的关键评估维度
选数据流架构芯片时，我通常会从几个维度打分。第一是算力利用率，不是峰值算力，而是你的实际模型跑上去的利用率。这个只能实测，纸面参数参考价值有限。第二是能效，每瓦性能比每TOPS价格更重要，特别是边缘场景。第三是编程难度，工具链好不好用，算子库全不全，调试方不方便。
第四是可扩展性，单芯片不够用的时候，多芯片扩展好不好做。第五是生态成熟度，有没有成功的部署案例，社区活不活跃，遇到问题能不能找到人问。第六是供应链，芯片能不能稳定供货，生命周期有多长。
这几个维度里，我觉得编程难度最容易被低估。很多团队选型时只看算力和能效，结果芯片买回来发现编程太复杂，模型部署不上去，项目延期。所以选型时一定要让工程师实际写几个算子试试，感受一下编程模型的友好度。
5.3 从HotChips看未来两年的演进方向
从今年HotChips的信号看，数据流架构未来两年会往几个方向走。一是更大规模的片上存储，用3D堆叠或者先进封装把更多SRAM放到片上，减少对外部存储的依赖。二是更灵活的拓扑，可重构的数据流阵列，能根据负载动态调整拓扑结构。三是更智能的编译器，用机器学习方法来优化数据流映射，减少人工调优的工作量。
还有个方向是数据流和存内计算的结合。存内计算把计算单元放进存储阵列里，数据不需要搬出来就能算，能效比传统数据流架构更高。但存内计算目前成熟度还低，良率和一致性是问题。HotChips上有一些早期探索，但离量产还有距离。
软硬件协同设计也会越来越重要。数据流架构的性能高度依赖编译器和硬件的配合，所以未来的趋势是硬件设计阶段就考虑编译器需求，编译器设计阶段就了解硬件细节。这种协同设计模式对团队的组织能力要求很高，但效果也最明显。
如果你正在评估数据流架构芯片，我的建议是别只看今年的HotChips，把过去三年的资料都翻出来对比着看。这样你能看出哪些是真趋势，哪些是昙花一现的噱头。
6. 个人实操体会与建议
6.1 从GPU迁移到数据流架构的注意事项
从GPU迁移到数据流架构，最大的挑战不是硬件，而是思维方式的转变。GPU编程是“我写kernel，硬件调度”，数据流编程是“我描述数据流，硬件执行”。这个转变需要时间适应。
我建议迁移时先从单个算子入手，别一上来就搞全模型。选一个你最熟悉的算子，比如矩阵乘，在数据流架构上实现一遍，感受一下编程模型和性能特征。然后再逐步扩展到子图、全模型。这个过程通常需要两到四周，取决于团队的经验。
还有个实操建议是保留GPU作为参考实现。数据流架构上跑出来的结果，和GPU上对比一下，确保数值正确。数据流架构的数值行为可能和GPU不同，比如累加顺序不一样，导致浮点结果有微小差异。这个在调试时很有用。
6.2 团队能力建设的几个关键点
数据流架构对团队能力的要求和GPU不同。编译器知识比CUDA编程更重要，因为很多优化要在编译器层面做。体系结构知识也比GPU时代更重要，因为你需要理解数据流硬件的微架构细节。数值分析知识同样重要，因为低精度计算下的数值稳定性需要专门处理。
团队建设上，我建议至少有一名懂编译器的工程师，能看懂编译报告，能手动调优数据流映射。至少有一名懂体系结构的工程师，能理解硬件瓶颈在哪，能指导软件优化方向。至少有一名懂数值分析的工程师，能处理精度问题。
另外，和芯片原厂的技术支持保持紧密沟通很重要。数据流架构的很多细节不公开，遇到问题只能问原厂。建立好的沟通渠道，能省很多时间。
6.3 项目落地的节奏把控
数据流架构项目落地，节奏把控很关键。我的经验是分四个阶段。第一阶段是可行性验证，用一个小模型跑通全流程，验证工具链和硬件基本可用。这个阶段通常两到四周。第二阶段是性能调优，针对关键算子做优化，把性能提到可接受水平。这个阶段一到两个月。第三阶段是精度对齐，确保数值精度满足要求。这个阶段两到四周。第四阶段是产品化，做稳定性测试、压力测试、多芯片扩展。这个阶段一到两个月。
每个阶段都要有明确的验收标准，别糊里糊涂往下走。可行性验证阶段如果发现工具链有硬伤，要果断换方案，别硬撑。性能调优阶段如果优化空间有限，要重新评估选型。精度对齐阶段如果精度始终不达标，要考虑混合精度方案。产品化阶段如果稳定性有问题，要回头查根因。
最后分享一个小技巧：在项目早期就建立性能基线。用GPU或者CPU跑一个参考实现，记录延迟、吞吐、精度。数据流架构上每优化一步，都和基线对比，这样能清楚知道优化效果，也能及时发现性能回退。这个基线在后期排查问题时特别有用，能快速定位是硬件问题还是软件问题。
