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跑一个参考实现记录延迟、吞吐、精度。数据流架构上每优化一步都和基线对比这样能清楚知道优化效果也能及时发现性能回退。这个基线在后期排查问题时特别有用能快速定位是硬件问题还是软件问题。
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跑一个参考实现记录延迟、吞吐、精度。数据流架构上每优化一步都和基线对比这样能清楚知道优化效果也能及时发现性能回退。这个基线在后期排查问题时特别有用能快速定位是硬件问题还是软件问题。
