企业官网建设流程全解析

1. 写在前面：HotChips为什么值得关注

做AI芯片有个绕不开的会，就是每年八月的HotChips。我入行这几年，每年雷打不动跟完整个流程：先刷提前放出来的论文PDF，再根据现场偷拍的PPT脑补细节，最后等官方录像出来重新看一遍。为什么这么执着？因为HotChips和ISSCC、ISCA不一样，它是一个非常"实"的芯片发布现场。学术圈讨论的是理论上限，HotChips讲的是已经流片、已经在跑负载的硅片到底怎么设计的。

今年这届看下来，最高频的词还是"数据流架构"（Dataflow Architecture）。可以说，从Google提出TPU的脉动阵列方案以来，数据流已经成了AI芯片设计的一条主干道，几乎每家大厂和中型创业公司的新片子都会往这个方向上靠。但问题是，真正理解数据流的人没想象中那么多。很多人把任何"不是GPU的AI加速器"都叫数据流，也有人误以为数据流就是去掉缓存、全用寄存器堆，这其实都是对架构本质的误读。

这篇文章我就顺着HotChips里看到的几类典型设计，把数据流架构芯片的来龙去脉拆开聊一聊。不讲虚的，不讲数学公式，就讲清楚它到底解决了什么问题、不同流派的实现思路、以及你在看这类芯片时需要盯住哪些关键指标。适合正在做芯片评估、AI基础设施选型，或者准备在毕设/部门项目中引入加速器的人。如果你只是好奇"为什么GPU都堆到几千TOPS了大家还要折腾新架构"，这篇文章也能给你一个清楚的答案。

2. 传统架构卡在哪，为什么大家都在谈数据流

2.1 算力堆料的边际在递减

过去十年AI芯片的主旋律很简单：堆MAC单元。GPU从Volta到Hopper，AI加速器单芯片算力从几百TOPS飙到上千TOPS，看起来应接不暇。但如果你真的跑过大规模模型推理，会发现问题不在算力本身，而在数据根本喂不过来。

一个很简单的算术题：假设某AI加速器标称500TOPS，按INT8算，这意味着它每秒需要做5x10^14次乘加运算。每次乘加至少要读两个操作数、写回一个结果，哪怕操作数复用率做到极高，也需要每秒TB级别的片上带宽才能满足需求。而目前最先进的片上SRAM访问带宽，受制于物理布局和功耗，很难无限制增长。于是芯片内部出现了一个经典瓶颈：计算单元在等数据，ALU空转，能效直线下降。

这就是为什么HotChips上大家反复讲"数据搬运开销"（data movement cost）。在成熟工艺下，一次32位浮点运算消耗的能量约0.9pJ，而从DRAM读取同等数据要消耗约20倍以上的能量。这里还不算延迟差异。所以算力堆到一定程度后再往上加MAC，不过是让一匹饿马拉着更重的车——计算能力越强，喂不饱数据的问题越严重。

2.2 数据流架构到底解决什么问题

数据流架构的核心思路，一句话总结：让数据走向计算，而不是让计算去抓取数据。

传统CPU/GPU是控制流架构，指令一条条取出来，ALU被"安排"着干活。数据存放在寄存器或缓存里，需要时由指令去访问。而数据流架构把计算任务表示成一张有向图，节点是运算，边是数据依赖关系。数据一旦准备好，就从上游节点流向下游节点，节点被数据激活后执行运算。没有中央指令来指挥"现在该做什么"，执行节奏由数据本身的就绪状态决定。

这样的好处有两层。第一层，省掉了指令取指（instruction fetch）、译码（decode）、乱序调度（out-of-order scheduling）这套复杂的控制逻辑和流水线开销。这部分在传统架构上占的面积和功耗不是小数目。第二层，节点间的数据传递路径是静态编译期就定好的，芯片可以针对固定通道做高带宽布线，数据在片上移动的路径可以极短、极规整，从而大幅降低数据搬运能耗和延迟。

打个生活化比方。控制流架构像中央厨房统一配送：每个灶台要做菜先举手申请，仓库配货，再按菜单逐一派送，调度室忙得不可开交。数据流架构则像一条流水线，食材在传送带上自动流动，每个工作台看到原料齐了就开工，不需要等中央指令。节奏自然、路径固定、几乎没有等待时间。

2.3 数据流和"智能计算"不是一回事

这里必须澄清一个常见的混淆。有些人拿数据流架构和"模拟人脑""存算一体"混为一谈，这其实是三条不同路线。

存算一体的核心是把权重或激活值放在存储单元附近甚至存储单元内部做计算，重点解决存储墙问题——它关心的是"数据在哪儿算"；数据流架构关心的是"数据怎么流动、计算节点怎么组织和激活"；而类脑计算则更关注脉冲事件驱动和低精度突触可塑性。三者可以叠乘在一起用，比如你可以在数据流芯片上用近存计算单元做节点运算，但它们的抽象层级和目标各不相同。

在HotChips上你也能看到这个趋势：纯靠单一创新已经不够了，各家都在组合拳。有人用脉动阵列做数据流，有人在脉动阵列上叠了近存缓存，还有人把稀疏跳过的逻辑直接做进PE内部。但不管怎么组合，它的调度内核都避不开那张数据流图。

3. 数据流芯片的主流技术流派与HotChips风向

细看今年HotChips的报告，被称为"数据流架构"的设计大致能分成三类，我逐个讲。

3.1 空间架构与脉动阵列：最成熟的流派

空间架构（spatial architecture）是最容易被理解的一种数据流。芯片由大量简单处理单元（PE）布成一个二维阵列，数据沿着相邻PE逐级传递，每个PE只需要和邻居通信，不存在复杂的全局广播网络。这类设计的代表就是Google TPU系列中的脉动阵列（systolic array）。

脉动阵列的精髓在于"每个时钟节拍，数据沿着固定方向移动一格，计算在数据经过时顺手完成"。一个2D的脉动阵列里，权重预先驻留在各个PE中，输入数据从左侧逐列流入，部分和从下方逐行流出。每个PE执行一次乘加操作只和相邻PE交换数据，片上通信距离被压到极致。

我自己看TPU和一系列国产加速器的论文时，有一个感受：脉动阵列的设计陷阱不在阵列本身，而在阵列边缘的进出口带宽。如果输入数据进入阵列的速度跟不上脉动节拍，阵列中间就会"断流"。所以HotChips上凡是采用脉动阵列的芯片，都特别强调片上SRAM预算和片外高带宽内存（HBM）。

另一个陷阱是适配性。脉动阵列对卷基层效率极高，但对结构不规则的自定义算子就很别扭。像动态shape的attention算子、条件分支较多的小模型，映射到脉动阵列后利用率可能只有两三成。所以现在很多芯片在脉动阵列之外还要再加一层灵活的可编程模块，我把它叫"双模策略"。

3.2 粗粒度可重构数据流：灵活性的更高追求

脉动阵列的路子胜在规整、高效，但输在灵活性。另一类厂商在尝试把"数据流图直接映射到硬件上"，而不是把所有模型都强行压成脉动阵列。这类芯片叫粗粒度可重构架构（CGRA）或粗粒度数据流架构。

代表性思路来自SambaNova、Wave Computing（现在已不复当年）等公司，学术源头可以追溯到几十年前的CGRG研究。这类芯片内部包含大量可配置的功能单元，每个功能单元可以做向量运算、矩阵运算、数据搬运和地址生成等操作。芯片上还有高带宽互联网络，可以在编译期就把算子之间的数据通道铺好，让一个模型的执行路径变成一张物理上连通的网络。

换句话说，脉动阵列是"一张固定的阵列，所有模型都往上面映射"；粗粒度可重构是"芯片本身就是一张可编程的布线板，每个模型都能生成自己的专属布线图"。后者的理论利用率天花板更高，对不规则模型也友好，但代价是编译器难度直线上升。编译不到位的模型，在同类芯片上会呈现灾难级性能表现。

我在HotChips上看到这类芯片的实测数据时，第一反应是去看它跑了哪些模型：如果只跑ResNet、只跑CNN，那数据流优势非常明显；如果还跑了NLP、跑了稀疏模型、跑了一些动态shape模型，那才是真本事。这里面的猫腻，你们在评估时也务必注意。

3.3 晶圆级集成与多芯片互联：数据流的物理扩展

数据流架构对带宽的胃口极大。单片硅片的片上SRAM和HBM接口终究有限，于是有一种很极致的方向：做晶圆级芯片，把所有计算和存储一次封装在一整片12英寸晶圆里。最典型的就是Cerebras，它的晶圆级引擎（WSE）里塞了几十万个内核，片内互联带宽是以拍字节每秒（PB/s）来计算的。

从HotChips的视角看，Cerebras传递的信息是：数据流架构和晶圆级封装是天然搭配。为什么？因为数据流图本身就是分层的、有空间局部性的。如果我把一个计算图映射到晶圆的不同区域，各个区域之间的数据流可以通过多层金属走线完成，延迟极低、带宽极高。而如果是多芯片互联方案，芯片之间的数据要经过封装基板、交换机，带宽和能耗都差了一个量级。

但晶圆级设计也有它的麻烦：良率和大面积工艺不均。一家公司如果能搞定晶圆级的良率问题，等于给数据流架构提供了最肥沃的土壤。我个人认为这是未来五年的关键赛点之一，但假如你的团队没有那么大的投入，还是可以靠chiplet思路获得部分收益——把计算die和存储die分开，在封装内用硅桥或die-to-die高速接口做数据流连接。

3.4 这些技术路径的共同逻辑

不管是脉动阵列、CGRA还是晶圆级，它们共同的底层逻辑是：把数据流图中的边，物化成物理上的专用通道。静态编译期分析出数据的生产者和消费者，然后让它们在物理层面对齐，减少不必要的广播、缓存和仲裁。

这需要芯片设计团队同时拥有编译器技术和硬件架构能力。在HotChips台上做报告的大多不是纯硬件团队，他们的叙事往往从软件栈开始，比如算子图如何拆解、调度如何生成，然后才讲到硅片的物理结构。这个信号值得注意：数据流架构的战点已经从"怎么做一块芯片"转移到了"怎么把一张计算图标定到芯片上并跑满"。没有编译器团队的数据流芯片，就像没有方向盘的超跑，马力和客户之间的体验完全断裂。

4. 评估数据流芯片时，我最先看的6个指标

每届HotChips看完后，我都会用一套固定的指标体系去衡量新发布的数据流芯片。这里分享给同行，重点是解释"为什么看这些"，因为很多人的评估方法停留在只看峰值算力的阶段，那基本等于看汽车只看厂商标称的最大速度。

4.1 微架构：PE到底能干什么

第一项看PE的指令集和运算宽度。有些芯片的PE只能做乘加，另外要做非线性激活必须跑到另一个专门的单元里去，这就会导致"逻辑跳转开销"。而有些PE看起来复杂，实际上支持向量化、查表和轻量控制流，灵活性明显更高。在HotChips上，我会从PPT里抠出下列问题：PE有没有独立寄存器文件？可不可以做非数值操作（如地址生成、Mask处理）？两个PE之间能不能直接通信绕过全局缓存？

4.2 互联与数据搬运：系统平衡度

数据流芯片的"血管"是片上网络（NoC）。单纯堆PE但互联拓扑不合理，是最常见的翻车点。我关注的是：PE内部的邻居带宽是多少、跨域通信的延迟是否一致、有没有提供组播或单播通道。通常芯片资料不会直接给全连接结构图，但你可以从"批量处理单元之间的流量"推断出大概的互联层级。经验上，二维网格结构的延迟均匀度好但平均跳数高，环形结构局部性能好但容易出现热点，树状结构则对广播友好但对随机流量不友好。

4.3 编译器与运行时

这是数据流芯片的命门。评估时一定要具体到：它支持哪些深度学习框架？算子在原生框架中能被直接捕获还是需要手动改写？如果我写了自定义算子，会通过什么路径接入编译器？数据流图做静态调度还是动态调度？如果模型中途出现开关分支，芯片是直接用硬件处理，还是退回软件同步？这些都是影响实际性能的隐藏成本。

我见过太多人第一次拿数据流芯片跑模型，性能比GPU还差，就骂芯片"不行"。其实不是芯片不行，是编译器和框架适配没打通——模型体积小的时候，数据流的优势发挥不出来，反而因为序列化启动开销，跑了更久。

4.4 精度与数值策略

不同芯片对精度支持的策略差异巨大。有些只做INT8和FP16，有些则在FP32上也有不错表现，还有些主打高动态范围格式（如BF16/自定义浮点）。我建议不要只看"支持的精度列表"，要看它在混合精度场景下的路径是怎样的。具体来说，在同一个算子内部遇到高动态范围中间量时，芯片是直接使用高精度单元，还是紧急转发到CPU？这两种路径节省的周期是完全不同的。

4.5 稀疏性支持：真支持还是假支持

数据流的底层是数据移动驱动，理论上对稀疏数据非常友好。因为如果数据为零或不重要，就不需要触发数据流动。但实际芯片对稀疏的利用程度差别很大：有的支持结构化稀疏剪枝，有的只能跳过固定比例的四元素组，有的则只能在激活值上做稀疏跳过。评估时要看芯片是否能动态跳过无效计算，而不是静态地把权重置零。如果它只能权重稀疏，遇到动态稀疏的激活值就没辙；如果它连激活值也能跳过，那在生成式模型和稀疏场景下的收益会非常显著。

4.6 生态与上手的隐形门槛

数据流芯片离真正的工程落地还差一个"舒服"的程度。上手时的编译时间、调试能力、性能剖析工具，在很多HotChips的大报告里都被一笔带过。但实际操作的人知道，一次编译都要跑几小时、出现问题连性能计数器的信息都不全，这个痛感一点都不低于算力不足。我在评估芯片时一定会拿一个实际业务的小模型从头到尾做完：能否一键编译、编译输出是否包含性能指导、调试时能否看到节点内部状态，这些决定了它能否从一个专利样片变成能嵌入生产流水线的工具。

5. 数据流芯片落地中的常见坑与工程心得

5.1 峰值算力论文数字和实际利用率的落差

数据流芯片厂商都喜欢在HotChips PPT里放两张图：第一张是芯片的RAW TOPS，第二张是某个经典模型上的标杆性能。但"经典模型+静态图+全调优"的环境，到真实场景往往水土不服。

原因在于真实AI负载充满不确定性：输入长尾分布、动态batch、稀疏度变化、还有多请求并发。数据流芯片是静态编译派，它会把一个模型固定成一份硬件调度方案。当输入动态变化超过调度的假设范围时，要么降级到较保守路径，要么反复重编译。我在实际测试某款数据流芯片时发现，同一模型在固定shape下的延迟是1.2毫秒，但一旦输入长度变化，延迟会涨到3-5毫秒，且抖动极大。行业里喜欢说"dataflow is great until you hit a branch"，这个教训我经历过好几次。

5.2 编译器优化，不只是"能跑"

打个比方：GPU的编译器像C语言编译器，写了就能跑，跑得好不好主要靠程序员水平；数据流的编译器更像FPGA的综合工具，能不能跑、跑多快，完全取决于工具对资源映射的智能程度。

这份编译器的心智负担，用户未必感受到，但团队一定承受了。我遇到过最夸张的情况是，只是改了一个模型输出stride的参数，编译器重新做布局布线花了几小时，最后性能和上次完全一样。所以选择数据流芯片时，一定要预留编译离线优化的时间预算。比如每轮迭代如果编译时间超过15分钟，整个团队对模型探索的频率就会大幅下降，最终影响业务试错速度。

5.3 调试与可观测性：芯片内部的"暗箱"

数据流芯片里没有PC、没有传统意义上的寄存器现场，出了问题极难定位。在一次对接支持时，我试过把模型调快了2.3倍后开始出现偶发错误结果，但芯片自带的输出校验根本没报告错误。最后排查下来，是某个PE在特定数值条件下发生了饱和，而芯片默认不检测这类数据异常。从那以后，我给自己定了一个规矩：凡是做数据流芯片的测试，必须先在CPU上生成一份参照输出，再用芯片的结果逐层对齐。一开始就要布好观测点，不能依赖芯片自带的"一切正常"结论。

5.4 我的几条实操建议

基于踩过的坑，给准备做数据流芯片评估或替换的团队几条建议。

第一，一定从高频真实模型开始基准测试，不要用标准模型库。可以用自己业务中形态最稳定的三个模型，固定输入范围和batch后连跑一周，观察平均延迟、P99延迟、重编译频率和功耗曲线。第二，在立项时就把"编译器团队"当作硬件的一部分。如果团队里没有编译器方向的人，尽量选择软件栈成熟度高的商用方案，而不是试图在选型后自研编译器。第三，关注多模型并存场景。数据流芯片通常对单模型大计算图友好，但如果你要在一张卡上同时跑5个不同的在线推理模型，它的调度策略可能完全不是数据流最擅长的模式，而更像虚拟机隔离场景。

6. 从HotChips看到的风向，与我自己的一点体会

数据流架构在AI芯片领域走到今天，已经不是"要不用"的问题，而是"怎么用得更彻底"的问题。从TPU的脉动阵列，到CGRA的高灵活性方案，再到晶圆级的大规模数据流引擎，未来的AI芯片设计会越来越像"把硅片变成一张可编程的数据运动场"。

HotChips也让我有一个明显的感受：过去大家比拼的是单个算子的乘法效率，现在比拼的是完整图执行的流水线效率。这背后要求芯片设计者懂模型、懂编译器、懂系统。毕竟一旦芯片流片回来，你没有办法改硅片上的PE阵列，所有后招都得靠软件栈和系统创新去弥补。

我个人在折腾数据流架构过程中的体会是：这个架构对"思考矢量"（即模型设计的规律性）有天然的依赖。你的模型越规整、算子越固定、shape越稳定，数据流芯片能带给你的收益就越大。反过来，如果你的模型还在频繁试错、结构天天变、动态条件特别多，那采用数据流芯片很可能得不偿失。不要被热火朝天的架构潮流裹挟着走，先把你自己的负载特征弄明白，再去对照架构的特性，这才是选型最朴素的逻辑。

最后再分享一个小技巧：看HotChips的报告时，不要只看演讲者给的性能对比表，去找那些"不起眼"的细节——比如一张die photo里缓存所占的面积比例、一个系统架构图里PCIe端点数量、一句说"we support dynamic shape"的轻描淡写。这些细节往往才是决定一个数据流芯片能不能在你真实业务中活下来的关键。