数据流架构这条路我陆陆续续跟了几年从最早在实验室里啃粗粒度可重构阵列的论文到后来真正在机房机架上跑模型、看编译日志、调 tiling 参数踩的坑不算少。SambaNova 芯片是我反复拆解过的一个典型样本——它不靠堆频率、不靠把 cache 做大而是把数据怎么流、流到哪、什么时候流这件事从硬件运行期搬到编译期决定。这篇文章就是围绕这颗芯片把它的架构骨架、性能来源、以及你要真上手时会遇到的具体问题一层层剥开讲清楚。本文适合三类人看正在做推理集群选型的架构岗、对非 GPU 加速器好奇的算法工程师、以及想搞明白数据流芯片到底和 GPU 差在哪的技术爱好者。前置知识只需要你了解深度学习推理的基本流程前向传播、算子、batch、KV cache剩下的我会用生活化的类比补齐。文中的性能量级、片上资源规模都基于公开资料和常见实践整理具体型号参数请以官方规格书为准实操环节涉及的环境配置、参数选择、排障路径则是我和几位同行在项目里反复验证过的做法可以直接拿去对照。1. 先把靶子立清楚这类芯片到底在跟谁较劲1.1 从一次推理延迟异常说起几年前参与一个文档问答系统的推理部署模型不算大十几亿参数用户要求首字延迟压到 800ms 以内。当时的方案是通用 GPU 加批处理硬件利用率看着不低但延迟曲线很怪单条请求进来GPU 上有大量时间花在 kernel 启动和访存等待上真正做乘加的周期只占一小段。批量拉大到 32 之后吞吐上去了可尾部延迟又崩了——因为所有请求得排队等一个批次凑齐。那次之后我意识到一个问题通用 GPU 的设计目标是什么都能干代价是每一步运算都要经过指令取指、调度、cache 查找这些行政开销。当模型结构固定、数据流动路径固定的时候这些开销本质上是浪费。数据流架构芯片的出发点非常朴素——既然模型的计算图是确定的为什么不把这张图直接烧成硬件的连线方式让数据自己流过去一个周期一个周期地算完SambaNova 芯片就是这条路线里商业化走得比较远的一颗它的核心单元叫 RDU可重构数据流单元。这里的关键词是可重构不是专用。专用芯片比如某个算子固化下来的加速器一旦模型结构变了就废了可重构的意思是编译一次硬件内部的计算单元阵列和互联拓扑按这张计算图重新配置换模型就重新编译一次配置。这个思路介于 FPGA 的细粒度可重构和 ASIC 的完全固化之间业内一般叫粗粒度可重构架构缩写 CGRA。1.2 三个词拆开看数据流、可重构、粗粒度数据流这个词经常被滥用我先把它说清楚。传统处理器是控制流驱动的程序计数器指向哪条指令就执行哪条数据是被取过来用的。数据流驱动则是反过来的——哪个计算单元的操作数到齐了它就点火执行结果往下游推。你把它想象成一条装配线不是工头喊下一个而是零件到了工位这个工位自己就开始干。可重构解决的是装配线怎么摆的问题。芯片出厂时阵列是空白的编译器根据模型的数据流图决定哪个计算单元负责哪段运算、彼此之间的数据通路怎么走、片上存储块怎么分配给哪个张量。配置好之后它可以连续跑几百万个周期不用改这就是所谓的一次配置长期运行。粗粒度则是对可重构粒度的限定。FPGA 细到查找表和触发器级别灵活但配置开销大、编译时间长、能效被布线吃掉不少粗粒度把基本单元做成能处理向量或小矩阵的运算单元配置信息量骤降编译时间从几小时压到几十分钟量级代价是灵活性略降。对深度学习这种算子种类有限但形状变化多的负载粗粒度是比较合适的甜点区。理解了这三点后面所有的架构细节其实都是它们的展开。我特别建议新手在这里多停一会儿——很多人看这类芯片的资料上来就盯着峰值算力数字结果完全抓不到重点。数据流芯片的竞争力从来不在峰值 FLOPS而在有效利用率和端到端延迟。峰值算力是纸面参数能不能把阵列填满、数据能不能及时喂到才是真功夫。1.3 和 GPU 的定位差异用一张表说透维度通用 GPU可重构数据流芯片执行模型SIMT成千上万线程轮转空间并行计算单元按图固定分工指令开销每步都要取指、调度配置期一次性生成运行期几乎无取指存储策略多级 cache 自动管理靠命中率片上 SRAM 显式分配编译器决定谁放哪灵活性通用什么模型都能跑需编译适配换结构要重编译调优入口kernel 实现、算子库、批大小图切分、tiling、布局、阵列映射擅长场景训练、动态形状、算子频繁变化结构稳定的推理、大模型推理流水线这张表不是要分高下而是想说清楚一件事两者的调优入口完全不同。你在 GPU 上习惯的那套改 kernel、调 cuBLAS 参数、调 batch size的经验搬到数据流芯片上有一半用不上取而代之的是这张图怎么切、切多大、切完放哪。提示如果你正评估这类芯片别只跑一个 ResNet 或 BERT 就下结论。真正能体现它优势的是结构稳定、连续调用、对延迟敏感的长序列推理负载拿一个算子种类极多、形状动态变化的模型去测大概率会得到一个让你失望的数字但那个数字未必反映真实场景。2. 架构拆解一颗可重构数据流芯片里装了什么2.1 计算阵列PCU 与 PMU 的分工逻辑打开这类芯片的架构图你会看到一个二维阵列里面主要住着两种单元。一种是模式计算单元PCU负责算另一种是模式存储单元PMU负责存和搬。两者交替排布通过片上网络互联。PCU 内部不是单个 ALU而是一组向量/矩阵运算资源乘法累加阵列、移位与逻辑单元、FIFO 缓冲、以及少量控制逻辑。它可以被打扮成不同的模式——做点积、做归约、做逐元素激活、做 softmax 的指数部分取决于编译器给它下的配置。这里的设计取舍很有意思如果把 PCU 做得太专用比如只做矩阵乘那遇到 attention 里的 softmax、LayerNorm 就抓瞎如果做得太通用又退化成小 CPU失去能效优势。所以它选择一组基础运算 可组合模式让编译器去拼。PMU 的地位经常被低估。它不只是块 SRAM里面还带地址生成逻辑能做流式读写、能做数据重排比如转置、padding、stride 变换甚至能在存储侧做简单的归约。这个东西的价值在于很多算子的瓶颈不在算而在数据布局不对导致要额外搬运。PMU 把这些整备工作放在存储侧完成计算单元拿到的就是已经排好队的整齐数据。阵列规模决定了单芯片能承载多大的图。这里有个容易被忽略的约束——一颗芯片一次只能装下计算图的一个切面。如果模型太大编译器要把图切成若干段段内在阵列上流水段间要走片外存储。切分的粒度直接决定性能这事我在第 4 节会展开讲。2.2 片上网络数据流芯片的隐形命门我一直认为评价一颗数据流芯片看它的片上网络比看计算单元更能看出功力。原因很简单计算单元再多数据送不到就是摆设。GPU 靠 cache 和 warp 调度掩盖访存延迟数据流芯片没有这层缓冲它必须保证数据在正确的时间出现在正确的位置。这类芯片的片上网络通常是软件可配置的编译器在映射阶段就规划好每条数据通路的路由和带宽分配。好处是确定性极强——你编译完就知道这条流水线的节拍不存在运行期拥塞导致的抖动。坏处是灵活性差一旦实际访存模式和编译期假设不符比如动态 shape 导致的地址跳变性能会断崖式下滑。实际调优时我经常用血管这个比喻计算单元是器官片上网络是血管片上 SRAM 是血库。器官再强血管堵了照样休克。所以排查性能问题我的第一顺位永远是看数据通路有没有被打断——是不是某个张量因为容量不够被迫写回片外导致流水线上出现一个几百周期的空泡。注意这类芯片的诊断工具通常会把片上溢出到片外的次数作为关键指标暴露出来。这个数字哪怕只占总量百分之几也可能吃掉三成以上性能因为一次溢出意味着一次跨存储层次的往返而流水线最怕的就是等。2.3 三层存储SRAM、HBM、DDR 各司其职这一层是我认为最能体现设计意图的地方。架构上通常分三层最靠近计算单元的是大容量片上 SRAM公开资料里新一代产品的片上 SRAM 做到了数百 MB 量级晶体管规模过千亿中间是 HBM最外层是 DDR。为什么要把片上 SRAM 堆到这么大因为数据流架构的核心诉求是让数据尽量别动。片上 SRAM 的带宽比 HBM 高一个数量级功耗却低得多。把权重、激活、KV cache 尽量关在片上等于把最贵的搬运成本省掉了。数百 MB 听起来不多但对推理场景其实很够用——一个几十亿参数的模型做低比特量化后权重可以大部分驻留片上剩下的按层流式换入。三层存储的分工大致是这样片上 SRAM当前 tile 的输入输出、中间结果、热点权重、KV cache 的活跃部分。编译器显式分配生命周期精确到周期级。HBM放不下的权重、跨段流水的中间张量、批量较大的激活。带宽高但延迟不可忽略访问要提前预取。DDR模型参数冷存储、多卡共享的检查点、日志与预处理缓冲。容量大、带宽低只做兜底。这里有个反直觉的点片上 SRAM 不是越大越好。面积和功耗是硬约束堆大了会挤占计算单元。真正的关键是容量与访问模式的匹配度——编译器能不能把热点数据算准、能不能把生命周期错开的数据复用同一块 SRAM。这活儿干得好几百 MB 能顶几 GB 用干得差给你几 GB 也不够。2.4 编译器决定成败的另一半如果只能用一个词概括这类芯片的技术门槛我会说编译器。硬件只是提供了可塑性真正把模型变成高效流水线的是编译器。完整的编译链路大致是从主流框架导出计算图 → 图级优化算子融合、常量折叠、死代码消除→ 布局与精度决策哪些算子走低比特、哪些保持高精度→ 空间映射把算子切成 tile分配到 PCU/PMU规划 NoC 路由→ 时序调度软件流水决定每个 tile 在第几拍启动→ 生成配置 → 多卡切分与通信插入。这个流程里最难的是空间映射和时序调度本质是一个带约束的装箱加排程问题。切得粗并行度不够切得细片上存储碎片化、通信开销上升。我见过同一个模型仅调整 tile 尺寸和流水级数吞吐差出 1.8 倍的情况。实用的判断方法是拿到一个模型先看编译报告里的阵列占用率和片上溢出量。占用率低说明图没被切好硬件闲着溢出量高说明 tile 切大了或生命周期排布不合理。这两个指标调顺了再去抠细节才有意义。3. 高性能的秘诀四条主线缺一不可3.1 免取指把控制开销摊到编译期传统处理器执行一条乘加背后可能跟着取指、译码、寄存器读、写回、分支判断一整套动作。深度学习负载的特点是重复性极高同一段运算在 token 维度上循环几万次这些行政工作完全是重复浪费。数据流芯片的做法是把控制信息在编译期一次性生成写进每个 PCU 的配置里运行期由硬件状态机按节拍推进。配置生效后阵列可以连续跑上百万个周期不打断。这带来的不仅仅是省了几个周期的开销——更关键的是消除了流水线的扰动源。没有分支预测失败没有指令 cache 缺失节拍是确定的。这个特性对推理延迟的意义特别大。GPU 上你很难精确预测一条请求走完要多少时间因为调度、cache、批处理排队都会引入抖动数据流芯片上编译完基本就能算出端到端周期数抖动在个位数百分比。对在线服务来说可预测性本身就很值钱。3.2 显式管理存储不靠 cache 赌命中cache 是通用处理器的伟大发明但它有个本质问题你不知道下一次访问会不会命中。对通用程序这是好事对结构固定的推理负载反而是负担——为了应对不确定性硬件要维护标签、做替换、处理一致性这些都要面积和功耗。数据流芯片直接把这一层拿掉改成编译器显式分配片上存储。哪个张量住哪块 SRAM、住多久、什么时候被覆盖全部在编译期定死。好处有三个一是省掉标签比对和替换逻辑同样的面积能放更多存储二是访问延迟固定流水线好排三是可以用上软件流水——编译器知道下一拍要读什么提前几个周期就把数据搬到计算单元门口。代价是把复杂度转移给了软件。如果模型里有数据相关的动态行为比如 MoE 的路由、变长序列的 padding编译器只能保守处理预留最坏情况的空间利用率就下来了。这也是为什么这类芯片在稠密模型上表现更亮眼。提示如果你的模型里有大量条件分支或动态 shape先在框架层把它们规整成静态形式固定序列长度、pad 到统一形状、把路由算子单独拆出来再交给编译器。这一步做不做性能差得不是一点半点。3.3 空间并行叠加软件流水并行有两层。第一层是空间并行阵列上几百个计算单元同时干活每个负责图里的一小块。第二层是时间并行也就是软件流水——把一个大算子切成若干级第 i 级在处理第 n 个数据块的同时第 i-1 级已经在处理第 n1 块。两级叠起来理论上可以让阵列的每个单元在任何时刻都不闲着。这里有个容易被误读的点软件流水的级数不是越多越好。级数多了填充和排空的开销占比上升片上缓冲需求也变大反而可能把 SRAM 挤爆。经验值通常取 2 到 4 级具体看单个 tile 的计算时长与访存时长的比例。如果计算时长明显大于访存2 级足够掩盖如果访存占比高才需要加深流水。判断方法很土但很有效看编译报告里的流水线气泡占比。气泡超过 15%说明级数或 tile 尺寸有一个不对劲两个参数一起微调通常能把气泡压到 5% 以内。3.4 粗粒度重构一次配置跑完整个模型可重构这三个字听着美好但重构本身是有成本的——重配一次阵列要几十微秒到毫秒量级。如果每跑一个算子就重配一次那点收益全被吃光了。所以真正的秘诀在于配置的持久性把尽量多的算子同时铺到阵列上让它们共存数据在它们之间流动而不是轮流占用硬件。这要求编译器有全局视野——它不是一个个算子单独编译而是把整张图当成一个待布局的二维平面来排。这个思路带来的直接好处是模型推理过程中几乎不产生重构事件配置一次跑到结束。对长序列连续生成的场景比如自回归解码这意味着每个 token 的生成都踩在同一条已经预热的流水线上节拍稳定。也正因为此模型的图结构越规整、算子越能平铺收益越大。反过来图里有大量串行依赖、小算子、控制流的模型铺不开就退化成频繁重配性能会很难看。这是架构特性决定的不是调优能完全弥补的。3.5 多卡与多节点扩展三层互联的取舍单芯片装不下大模型时就得往外扩。这类系统的扩展通常分三层芯片内NoC、节点内卡间高速互联通常走 PCIe 或专用链路、节点间机架级网络。关键在于切分策略。常见的做法是按层切pipeline parallel和按张量切tensor parallel混用。层切通信量小但有流水气泡张量切通信频繁但并行度高。在数据流架构上因为单卡片上存储大层切能塞下更多层气泡相对好掩盖张量切则要特别小心因为 all-reduce 会打断数据流的连续性。我见过一个典型问题8 卡跑一个中等规模模型扩到 4 卡时吞吐是线性的扩到 8 卡反而只提升了 1.6 倍。查下来是张量切的通信被插在了流水线中间每次都要等所有卡同步。改成层切 微批流水之后8 卡做到了 7.2 倍。教训很直接——扩展性不是靠加卡加出来的是靠切分策略换出来的。4. 上手实操从跑通到调优的完整路径4.1 标准上手流程这里给出一条我验证过的最小路径适用于大多数支持该架构的托管环境或本地部署。步骤不复杂但每一步的意图要清楚。第一步确认编译工具链版本与驱动匹配。这类平台对版本极其敏感编译器版本、运行时版本、固件版本三者不匹配时报错信息往往指向莫名其妙的地方。第二步把模型从框架导出成静态图。推荐先在 PyTorch 里用 trace 或 export 拿到静态图跑通一次 CPU 推理确认图本身没问题。第三步做精度策略决策。低比特量化是这类芯片的主要收益来源之一但不是所有层都能承受。我的习惯是线性层、卷积层走 8 比特甚至 4 比特LayerNorm、softmax、残差累加保持 16 比特。第四步跑一次编译只看编译报告不看性能。重点看三个数阵列占用率、片上溢出量、气泡占比。第五步用小批量跑通端到端验证输出精度与参考实现的一致性通常要求 top-1 一致率在 99% 以上。第六步再逐步放大批量观察延迟与吞吐曲线的拐点。下面是一段示意性的调用流程语言选了 Python具体 API 名称各平台不同重点是流程结构# 示意代码静态图导出 编译 执行 import torch from compiler_sdk import Graph, compile_config model load_model(my_model).eval() dummy torch.randint(0, 32000, (1, 2048)) # 1. 导出静态图 graph torch.export.export(model, (dummy,)) # 2. 编译配置tile 尺寸、精度策略、流水级数 cfg compile_config( tile_hintauto, # 先交给编译器自动切 precision{linear: int8, norm: fp16, attn_softmax: fp16}, pipeline_stages2, # 首轮保守取 2 sram_budget_ratio0.85, # 留 15% 余量给中间张量 ) # 3. 编译产出配置与报告 artifact, report Graph(graph).compile(cfg) print(report.array_occupancy) # 阵列占用率 print(report.spill_bytes) # 片上溢出量 print(report.bubble_ratio) # 流水气泡占比 # 4. 加载执行 runtime load_artifact(artifact) out runtime.run(dummy)4.2 参数选择把容量算清楚再动手调参之前先把账算明白能省掉大量试错。核心是三个量权重占用、KV cache 占用、激活占用。以 70 亿参数模型、8 比特权重量化为例权重约 7 GB。假设 32 层、32 个注意力头、head_dim 128、FP16 的 KV cache批大小为 8序列长度 2048单层 KV 元素数 2K和V × 32头 × 128维 × 2048长度 × 8批 2 × 32 × 128 × 2048 × 8 134,217,728 个元素 FP16 每元素 2 字节 → 单层 268,435,456 B ≈ 256 MB 32 层合计 ≈ 8 GB这个数字很关键权重 7 GB 加 KV cache 8 GB已经超过单片数百 MB 的 SRAM 容量必须分层流式换入而 KV cache 的大部分会落在 HBM 上。这时候如果你的批大小设到 32KV cache 直接涨到 32 GBHBM 带宽立刻成为瓶颈吞吐曲线会出现明显的拐点。我的经验是先用公式估出 HBM 侧的实际驻留量再反推最大可接受批大小。公式很简单——HBM驻留 ≈ 权重外溢部分 KV总量 × (1 - 片上可容纳比例)。如果这个值超过 HBM 容量的一半说明该降批或者该做 KV 量化了。激活占用则跟 tile 尺寸强相关。tile 切得大激活缓冲需求涨切得小阵列利用率降。我的做法是先固定 tile 让占用率到 70% 左右再看溢出量如果溢出明显就缩小 tile 或者增加流水级数把重叠部分摊薄。4.3 性能剖析该盯哪几个指标脱离具体指标谈调优都是耍流氓。这类芯片的分析工具通常给出这些维度我按重要性排序指标含义健康区间偏差时先动什么阵列占用率计算单元实际被使用的比例65%~85%调整 tile 尺寸与切分粒度片上溢出量被迫写回 HBM 的数据量越低越好占比 5%缩小 tile 或提精度分级流水气泡占比流水线空转周期占比10%调整流水级数与 tile 计算时长NoC 带宽利用率片上网络实际吞吐/峰值50%~75%重排数据布局减少转置HBM 有效带宽实际读写吞吐/理论峰值60%~85%优化预取与分层策略多卡通信占比通信耗时/总耗时15%换切分策略增大微批这几个指标是有先后顺序的。占用率不到位其他都是次要问题占用率上来了但溢出高说明切分和存储分配打架得重新算容量前两个都健康而吞吐仍然低才轮到看 NoC 和 HBM。我个人的排查顺序是占用率 → 溢出 → 气泡 → 带宽 → 通信。倒着排查的人十有八九会在通信优化上白花一周最后发现根因是 tile 太大导致溢出。4.4 迁移已有代码的常见改法从 GPU 代码迁过来有几处几乎是必改的去掉动态 shape 依赖。所有 padding、动态序列长度都要在入口处固定下来或者至少给出一个有限的候选集合让编译器枚举。把自定义算子拆成基础算子组合。数据流编译器对算子融合的支持很强但它需要认识每个基础算子你写的大 kernel 它可能整个当成黑盒性能反而差。慎用控制流。循环和条件分支在数据流架构上要靠特殊的同步机制实现代价不低。能量化就量化能展开就展开。批处理的边界要清楚。连续批处理continuous batching在这类架构上需要额外的调度层如果平台没提供就退化成静态批批次凑不齐会浪费阵列。我特别想强调第二条。有位同行把一个融合了十几个操作的 attention 算子整体搬过去编译能过但性能只有预期的一半。后来拆成标准算子组合交给编译器让它自己融合性能反而上去了——因为编译器知道每个算子的边界能做更精细的 tile 切分和存储复用。在数据流架构上让编译器看见细节比替编译器做决定更有效。5. 常见问题与排查实录5.1 典型故障速查表现象可能原因定位方法处理方式编译卡住或超时图过大、tile 搜索空间爆炸看编译日志的阶段耗时手动指定 tile 上界关闭自动搜索编译失败提示资源超限单次映射的图超过阵列容量看报告里的资源占用明细加大切分段数或把部分算子拆出运行 OOMKV cache 或激活超出预算按 4.2 的公式重算降批、KV 量化、缩 tile吞吐只有理论值三成片上溢出严重看溢出字节数与占比优先缩 tile其次降精度策略延迟抖动大存在动态 shape 或调度层排队抓单请求时间戳分布固定 shape改用静态批扩卡不线性张量切通信打断流水看多卡通信占比改层切加微批流水输出精度下降量化范围过激逐层对比参考输出敏感层norm、softmax回到 FP16多卡结果不一致微批边界或归约顺序问题单卡跑同批次对比固定归约顺序检查种子5.2 几个只有踩过才知道的坑坑一编译报告比性能测试更值得看。我早期的一个坏习惯是改完参数立刻跑 benchmark跑一次十几分钟一天试不了几个组合。后来改成只看编译报告——溢出量、占用率、气泡这三个数就能预判 80% 的性能走向只有报告看起来健康了才值得跑实测。这个习惯把迭代效率提了好几倍。坑二阵列占用率不是越高越好。曾经把占用率从 72% 硬调到 91%结果吞吐反而降了。原因是剩下的 9% 空间被塞得太满编译器没有余量做流水重叠气泡从 6% 涨到 22%。留余量是设计的一部分不是浪费。坑三批大小存在隐性台阶。这类芯片的收益曲线不是平滑的往往在某几个特定批大小上出现台阶——因为批大小决定了 tile 能否整除、能否填满阵列的行列数。实测时要以 2 的幂次为基准做二分而不是 1、2、3 这样线性扫。坑四量化的收益要算总账。8 比特权重确实省了存储但反量化可能要额外算子如果这部分算子没被融合进流水线反而多了访存。判断标准很简单量化前后看片上溢出量有没有真的下降没降就说明省下的空间又被中间张量吃回去了。坑五多节点场景先验证单节点线性度。我见过团队上来就调 16 节点结果一直在追一个根本不存在的网络问题最后发现是单节点 8 卡本身就只有 5.8 倍扩展效率。基础不牢越往上越乱。5.3 什么场景值得上什么场景别硬上说句实在的这类芯片不是万金油。结构稳定、连续调用、对延迟和确定性敏感的推理负载——比如固定长度文档的批量编码、长上下文对话的生成、多模态模型的稳定前向——它能给出很漂亮的能效和延迟曲线。反过来算子日更的实验性模型、形状高度动态的负载、需要频繁在训练和推理间切换的场景硬上会非常痛苦光编译适配就能耗掉两周。我的建议是拿一个真实业务里最常跑的那条链路去测别用标准 benchmark。标准 benchmark 都是规整的测出来的数字好看但和你没关系。真实链路里那些 padding、那些变长、那些后处理才是决定这套架构能不能落地的关键。最后分享一个我一直在用的小方法给每个模型建立编译档案——记录 tile 配置、精度策略、数组占用、溢出量、实测吞吐以及当时的编译器和固件版本。这类平台的版本敏感性比通用 GPU 高得多同一套配置换个版本性能可能差 20%。档案能让你在升级之后快速定位是哪一环退化了而不是从零开始重新摸索。这套东西听起来笨但在我参与的几个项目里它省下的重复劳动比任何调优技巧都多。
数据流架构这条路我陆陆续续跟了几年从最早在实验室里啃粗粒度可重构阵列的论文到后来真正在机房机架上跑模型、看编译日志、调 tiling 参数踩的坑不算少。SambaNova 芯片是我反复拆解过的一个典型样本——它不靠堆频率、不靠把 cache 做大而是把数据怎么流、流到哪、什么时候流这件事从硬件运行期搬到编译期决定。这篇文章就是围绕这颗芯片把它的架构骨架、性能来源、以及你要真上手时会遇到的具体问题一层层剥开讲清楚。本文适合三类人看正在做推理集群选型的架构岗、对非 GPU 加速器好奇的算法工程师、以及想搞明白数据流芯片到底和 GPU 差在哪的技术爱好者。前置知识只需要你了解深度学习推理的基本流程前向传播、算子、batch、KV cache剩下的我会用生活化的类比补齐。文中的性能量级、片上资源规模都基于公开资料和常见实践整理具体型号参数请以官方规格书为准实操环节涉及的环境配置、参数选择、排障路径则是我和几位同行在项目里反复验证过的做法可以直接拿去对照。1. 先把靶子立清楚这类芯片到底在跟谁较劲1.1 从一次推理延迟异常说起几年前参与一个文档问答系统的推理部署模型不算大十几亿参数用户要求首字延迟压到 800ms 以内。当时的方案是通用 GPU 加批处理硬件利用率看着不低但延迟曲线很怪单条请求进来GPU 上有大量时间花在 kernel 启动和访存等待上真正做乘加的周期只占一小段。批量拉大到 32 之后吞吐上去了可尾部延迟又崩了——因为所有请求得排队等一个批次凑齐。那次之后我意识到一个问题通用 GPU 的设计目标是什么都能干代价是每一步运算都要经过指令取指、调度、cache 查找这些行政开销。当模型结构固定、数据流动路径固定的时候这些开销本质上是浪费。数据流架构芯片的出发点非常朴素——既然模型的计算图是确定的为什么不把这张图直接烧成硬件的连线方式让数据自己流过去一个周期一个周期地算完SambaNova 芯片就是这条路线里商业化走得比较远的一颗它的核心单元叫 RDU可重构数据流单元。这里的关键词是可重构不是专用。专用芯片比如某个算子固化下来的加速器一旦模型结构变了就废了可重构的意思是编译一次硬件内部的计算单元阵列和互联拓扑按这张计算图重新配置换模型就重新编译一次配置。这个思路介于 FPGA 的细粒度可重构和 ASIC 的完全固化之间业内一般叫粗粒度可重构架构缩写 CGRA。1.2 三个词拆开看数据流、可重构、粗粒度数据流这个词经常被滥用我先把它说清楚。传统处理器是控制流驱动的程序计数器指向哪条指令就执行哪条数据是被取过来用的。数据流驱动则是反过来的——哪个计算单元的操作数到齐了它就点火执行结果往下游推。你把它想象成一条装配线不是工头喊下一个而是零件到了工位这个工位自己就开始干。可重构解决的是装配线怎么摆的问题。芯片出厂时阵列是空白的编译器根据模型的数据流图决定哪个计算单元负责哪段运算、彼此之间的数据通路怎么走、片上存储块怎么分配给哪个张量。配置好之后它可以连续跑几百万个周期不用改这就是所谓的一次配置长期运行。粗粒度则是对可重构粒度的限定。FPGA 细到查找表和触发器级别灵活但配置开销大、编译时间长、能效被布线吃掉不少粗粒度把基本单元做成能处理向量或小矩阵的运算单元配置信息量骤降编译时间从几小时压到几十分钟量级代价是灵活性略降。对深度学习这种算子种类有限但形状变化多的负载粗粒度是比较合适的甜点区。理解了这三点后面所有的架构细节其实都是它们的展开。我特别建议新手在这里多停一会儿——很多人看这类芯片的资料上来就盯着峰值算力数字结果完全抓不到重点。数据流芯片的竞争力从来不在峰值 FLOPS而在有效利用率和端到端延迟。峰值算力是纸面参数能不能把阵列填满、数据能不能及时喂到才是真功夫。1.3 和 GPU 的定位差异用一张表说透维度通用 GPU可重构数据流芯片执行模型SIMT成千上万线程轮转空间并行计算单元按图固定分工指令开销每步都要取指、调度配置期一次性生成运行期几乎无取指存储策略多级 cache 自动管理靠命中率片上 SRAM 显式分配编译器决定谁放哪灵活性通用什么模型都能跑需编译适配换结构要重编译调优入口kernel 实现、算子库、批大小图切分、tiling、布局、阵列映射擅长场景训练、动态形状、算子频繁变化结构稳定的推理、大模型推理流水线这张表不是要分高下而是想说清楚一件事两者的调优入口完全不同。你在 GPU 上习惯的那套改 kernel、调 cuBLAS 参数、调 batch size的经验搬到数据流芯片上有一半用不上取而代之的是这张图怎么切、切多大、切完放哪。提示如果你正评估这类芯片别只跑一个 ResNet 或 BERT 就下结论。真正能体现它优势的是结构稳定、连续调用、对延迟敏感的长序列推理负载拿一个算子种类极多、形状动态变化的模型去测大概率会得到一个让你失望的数字但那个数字未必反映真实场景。2. 架构拆解一颗可重构数据流芯片里装了什么2.1 计算阵列PCU 与 PMU 的分工逻辑打开这类芯片的架构图你会看到一个二维阵列里面主要住着两种单元。一种是模式计算单元PCU负责算另一种是模式存储单元PMU负责存和搬。两者交替排布通过片上网络互联。PCU 内部不是单个 ALU而是一组向量/矩阵运算资源乘法累加阵列、移位与逻辑单元、FIFO 缓冲、以及少量控制逻辑。它可以被打扮成不同的模式——做点积、做归约、做逐元素激活、做 softmax 的指数部分取决于编译器给它下的配置。这里的设计取舍很有意思如果把 PCU 做得太专用比如只做矩阵乘那遇到 attention 里的 softmax、LayerNorm 就抓瞎如果做得太通用又退化成小 CPU失去能效优势。所以它选择一组基础运算 可组合模式让编译器去拼。PMU 的地位经常被低估。它不只是块 SRAM里面还带地址生成逻辑能做流式读写、能做数据重排比如转置、padding、stride 变换甚至能在存储侧做简单的归约。这个东西的价值在于很多算子的瓶颈不在算而在数据布局不对导致要额外搬运。PMU 把这些整备工作放在存储侧完成计算单元拿到的就是已经排好队的整齐数据。阵列规模决定了单芯片能承载多大的图。这里有个容易被忽略的约束——一颗芯片一次只能装下计算图的一个切面。如果模型太大编译器要把图切成若干段段内在阵列上流水段间要走片外存储。切分的粒度直接决定性能这事我在第 4 节会展开讲。2.2 片上网络数据流芯片的隐形命门我一直认为评价一颗数据流芯片看它的片上网络比看计算单元更能看出功力。原因很简单计算单元再多数据送不到就是摆设。GPU 靠 cache 和 warp 调度掩盖访存延迟数据流芯片没有这层缓冲它必须保证数据在正确的时间出现在正确的位置。这类芯片的片上网络通常是软件可配置的编译器在映射阶段就规划好每条数据通路的路由和带宽分配。好处是确定性极强——你编译完就知道这条流水线的节拍不存在运行期拥塞导致的抖动。坏处是灵活性差一旦实际访存模式和编译期假设不符比如动态 shape 导致的地址跳变性能会断崖式下滑。实际调优时我经常用血管这个比喻计算单元是器官片上网络是血管片上 SRAM 是血库。器官再强血管堵了照样休克。所以排查性能问题我的第一顺位永远是看数据通路有没有被打断——是不是某个张量因为容量不够被迫写回片外导致流水线上出现一个几百周期的空泡。注意这类芯片的诊断工具通常会把片上溢出到片外的次数作为关键指标暴露出来。这个数字哪怕只占总量百分之几也可能吃掉三成以上性能因为一次溢出意味着一次跨存储层次的往返而流水线最怕的就是等。2.3 三层存储SRAM、HBM、DDR 各司其职这一层是我认为最能体现设计意图的地方。架构上通常分三层最靠近计算单元的是大容量片上 SRAM公开资料里新一代产品的片上 SRAM 做到了数百 MB 量级晶体管规模过千亿中间是 HBM最外层是 DDR。为什么要把片上 SRAM 堆到这么大因为数据流架构的核心诉求是让数据尽量别动。片上 SRAM 的带宽比 HBM 高一个数量级功耗却低得多。把权重、激活、KV cache 尽量关在片上等于把最贵的搬运成本省掉了。数百 MB 听起来不多但对推理场景其实很够用——一个几十亿参数的模型做低比特量化后权重可以大部分驻留片上剩下的按层流式换入。三层存储的分工大致是这样片上 SRAM当前 tile 的输入输出、中间结果、热点权重、KV cache 的活跃部分。编译器显式分配生命周期精确到周期级。HBM放不下的权重、跨段流水的中间张量、批量较大的激活。带宽高但延迟不可忽略访问要提前预取。DDR模型参数冷存储、多卡共享的检查点、日志与预处理缓冲。容量大、带宽低只做兜底。这里有个反直觉的点片上 SRAM 不是越大越好。面积和功耗是硬约束堆大了会挤占计算单元。真正的关键是容量与访问模式的匹配度——编译器能不能把热点数据算准、能不能把生命周期错开的数据复用同一块 SRAM。这活儿干得好几百 MB 能顶几 GB 用干得差给你几 GB 也不够。2.4 编译器决定成败的另一半如果只能用一个词概括这类芯片的技术门槛我会说编译器。硬件只是提供了可塑性真正把模型变成高效流水线的是编译器。完整的编译链路大致是从主流框架导出计算图 → 图级优化算子融合、常量折叠、死代码消除→ 布局与精度决策哪些算子走低比特、哪些保持高精度→ 空间映射把算子切成 tile分配到 PCU/PMU规划 NoC 路由→ 时序调度软件流水决定每个 tile 在第几拍启动→ 生成配置 → 多卡切分与通信插入。这个流程里最难的是空间映射和时序调度本质是一个带约束的装箱加排程问题。切得粗并行度不够切得细片上存储碎片化、通信开销上升。我见过同一个模型仅调整 tile 尺寸和流水级数吞吐差出 1.8 倍的情况。实用的判断方法是拿到一个模型先看编译报告里的阵列占用率和片上溢出量。占用率低说明图没被切好硬件闲着溢出量高说明 tile 切大了或生命周期排布不合理。这两个指标调顺了再去抠细节才有意义。3. 高性能的秘诀四条主线缺一不可3.1 免取指把控制开销摊到编译期传统处理器执行一条乘加背后可能跟着取指、译码、寄存器读、写回、分支判断一整套动作。深度学习负载的特点是重复性极高同一段运算在 token 维度上循环几万次这些行政工作完全是重复浪费。数据流芯片的做法是把控制信息在编译期一次性生成写进每个 PCU 的配置里运行期由硬件状态机按节拍推进。配置生效后阵列可以连续跑上百万个周期不打断。这带来的不仅仅是省了几个周期的开销——更关键的是消除了流水线的扰动源。没有分支预测失败没有指令 cache 缺失节拍是确定的。这个特性对推理延迟的意义特别大。GPU 上你很难精确预测一条请求走完要多少时间因为调度、cache、批处理排队都会引入抖动数据流芯片上编译完基本就能算出端到端周期数抖动在个位数百分比。对在线服务来说可预测性本身就很值钱。3.2 显式管理存储不靠 cache 赌命中cache 是通用处理器的伟大发明但它有个本质问题你不知道下一次访问会不会命中。对通用程序这是好事对结构固定的推理负载反而是负担——为了应对不确定性硬件要维护标签、做替换、处理一致性这些都要面积和功耗。数据流芯片直接把这一层拿掉改成编译器显式分配片上存储。哪个张量住哪块 SRAM、住多久、什么时候被覆盖全部在编译期定死。好处有三个一是省掉标签比对和替换逻辑同样的面积能放更多存储二是访问延迟固定流水线好排三是可以用上软件流水——编译器知道下一拍要读什么提前几个周期就把数据搬到计算单元门口。代价是把复杂度转移给了软件。如果模型里有数据相关的动态行为比如 MoE 的路由、变长序列的 padding编译器只能保守处理预留最坏情况的空间利用率就下来了。这也是为什么这类芯片在稠密模型上表现更亮眼。提示如果你的模型里有大量条件分支或动态 shape先在框架层把它们规整成静态形式固定序列长度、pad 到统一形状、把路由算子单独拆出来再交给编译器。这一步做不做性能差得不是一点半点。3.3 空间并行叠加软件流水并行有两层。第一层是空间并行阵列上几百个计算单元同时干活每个负责图里的一小块。第二层是时间并行也就是软件流水——把一个大算子切成若干级第 i 级在处理第 n 个数据块的同时第 i-1 级已经在处理第 n1 块。两级叠起来理论上可以让阵列的每个单元在任何时刻都不闲着。这里有个容易被误读的点软件流水的级数不是越多越好。级数多了填充和排空的开销占比上升片上缓冲需求也变大反而可能把 SRAM 挤爆。经验值通常取 2 到 4 级具体看单个 tile 的计算时长与访存时长的比例。如果计算时长明显大于访存2 级足够掩盖如果访存占比高才需要加深流水。判断方法很土但很有效看编译报告里的流水线气泡占比。气泡超过 15%说明级数或 tile 尺寸有一个不对劲两个参数一起微调通常能把气泡压到 5% 以内。3.4 粗粒度重构一次配置跑完整个模型可重构这三个字听着美好但重构本身是有成本的——重配一次阵列要几十微秒到毫秒量级。如果每跑一个算子就重配一次那点收益全被吃光了。所以真正的秘诀在于配置的持久性把尽量多的算子同时铺到阵列上让它们共存数据在它们之间流动而不是轮流占用硬件。这要求编译器有全局视野——它不是一个个算子单独编译而是把整张图当成一个待布局的二维平面来排。这个思路带来的直接好处是模型推理过程中几乎不产生重构事件配置一次跑到结束。对长序列连续生成的场景比如自回归解码这意味着每个 token 的生成都踩在同一条已经预热的流水线上节拍稳定。也正因为此模型的图结构越规整、算子越能平铺收益越大。反过来图里有大量串行依赖、小算子、控制流的模型铺不开就退化成频繁重配性能会很难看。这是架构特性决定的不是调优能完全弥补的。3.5 多卡与多节点扩展三层互联的取舍单芯片装不下大模型时就得往外扩。这类系统的扩展通常分三层芯片内NoC、节点内卡间高速互联通常走 PCIe 或专用链路、节点间机架级网络。关键在于切分策略。常见的做法是按层切pipeline parallel和按张量切tensor parallel混用。层切通信量小但有流水气泡张量切通信频繁但并行度高。在数据流架构上因为单卡片上存储大层切能塞下更多层气泡相对好掩盖张量切则要特别小心因为 all-reduce 会打断数据流的连续性。我见过一个典型问题8 卡跑一个中等规模模型扩到 4 卡时吞吐是线性的扩到 8 卡反而只提升了 1.6 倍。查下来是张量切的通信被插在了流水线中间每次都要等所有卡同步。改成层切 微批流水之后8 卡做到了 7.2 倍。教训很直接——扩展性不是靠加卡加出来的是靠切分策略换出来的。4. 上手实操从跑通到调优的完整路径4.1 标准上手流程这里给出一条我验证过的最小路径适用于大多数支持该架构的托管环境或本地部署。步骤不复杂但每一步的意图要清楚。第一步确认编译工具链版本与驱动匹配。这类平台对版本极其敏感编译器版本、运行时版本、固件版本三者不匹配时报错信息往往指向莫名其妙的地方。第二步把模型从框架导出成静态图。推荐先在 PyTorch 里用 trace 或 export 拿到静态图跑通一次 CPU 推理确认图本身没问题。第三步做精度策略决策。低比特量化是这类芯片的主要收益来源之一但不是所有层都能承受。我的习惯是线性层、卷积层走 8 比特甚至 4 比特LayerNorm、softmax、残差累加保持 16 比特。第四步跑一次编译只看编译报告不看性能。重点看三个数阵列占用率、片上溢出量、气泡占比。第五步用小批量跑通端到端验证输出精度与参考实现的一致性通常要求 top-1 一致率在 99% 以上。第六步再逐步放大批量观察延迟与吞吐曲线的拐点。下面是一段示意性的调用流程语言选了 Python具体 API 名称各平台不同重点是流程结构# 示意代码静态图导出 编译 执行 import torch from compiler_sdk import Graph, compile_config model load_model(my_model).eval() dummy torch.randint(0, 32000, (1, 2048)) # 1. 导出静态图 graph torch.export.export(model, (dummy,)) # 2. 编译配置tile 尺寸、精度策略、流水级数 cfg compile_config( tile_hintauto, # 先交给编译器自动切 precision{linear: int8, norm: fp16, attn_softmax: fp16}, pipeline_stages2, # 首轮保守取 2 sram_budget_ratio0.85, # 留 15% 余量给中间张量 ) # 3. 编译产出配置与报告 artifact, report Graph(graph).compile(cfg) print(report.array_occupancy) # 阵列占用率 print(report.spill_bytes) # 片上溢出量 print(report.bubble_ratio) # 流水气泡占比 # 4. 加载执行 runtime load_artifact(artifact) out runtime.run(dummy)4.2 参数选择把容量算清楚再动手调参之前先把账算明白能省掉大量试错。核心是三个量权重占用、KV cache 占用、激活占用。以 70 亿参数模型、8 比特权重量化为例权重约 7 GB。假设 32 层、32 个注意力头、head_dim 128、FP16 的 KV cache批大小为 8序列长度 2048单层 KV 元素数 2K和V × 32头 × 128维 × 2048长度 × 8批 2 × 32 × 128 × 2048 × 8 134,217,728 个元素 FP16 每元素 2 字节 → 单层 268,435,456 B ≈ 256 MB 32 层合计 ≈ 8 GB这个数字很关键权重 7 GB 加 KV cache 8 GB已经超过单片数百 MB 的 SRAM 容量必须分层流式换入而 KV cache 的大部分会落在 HBM 上。这时候如果你的批大小设到 32KV cache 直接涨到 32 GBHBM 带宽立刻成为瓶颈吞吐曲线会出现明显的拐点。我的经验是先用公式估出 HBM 侧的实际驻留量再反推最大可接受批大小。公式很简单——HBM驻留 ≈ 权重外溢部分 KV总量 × (1 - 片上可容纳比例)。如果这个值超过 HBM 容量的一半说明该降批或者该做 KV 量化了。激活占用则跟 tile 尺寸强相关。tile 切得大激活缓冲需求涨切得小阵列利用率降。我的做法是先固定 tile 让占用率到 70% 左右再看溢出量如果溢出明显就缩小 tile 或者增加流水级数把重叠部分摊薄。4.3 性能剖析该盯哪几个指标脱离具体指标谈调优都是耍流氓。这类芯片的分析工具通常给出这些维度我按重要性排序指标含义健康区间偏差时先动什么阵列占用率计算单元实际被使用的比例65%~85%调整 tile 尺寸与切分粒度片上溢出量被迫写回 HBM 的数据量越低越好占比 5%缩小 tile 或提精度分级流水气泡占比流水线空转周期占比10%调整流水级数与 tile 计算时长NoC 带宽利用率片上网络实际吞吐/峰值50%~75%重排数据布局减少转置HBM 有效带宽实际读写吞吐/理论峰值60%~85%优化预取与分层策略多卡通信占比通信耗时/总耗时15%换切分策略增大微批这几个指标是有先后顺序的。占用率不到位其他都是次要问题占用率上来了但溢出高说明切分和存储分配打架得重新算容量前两个都健康而吞吐仍然低才轮到看 NoC 和 HBM。我个人的排查顺序是占用率 → 溢出 → 气泡 → 带宽 → 通信。倒着排查的人十有八九会在通信优化上白花一周最后发现根因是 tile 太大导致溢出。4.4 迁移已有代码的常见改法从 GPU 代码迁过来有几处几乎是必改的去掉动态 shape 依赖。所有 padding、动态序列长度都要在入口处固定下来或者至少给出一个有限的候选集合让编译器枚举。把自定义算子拆成基础算子组合。数据流编译器对算子融合的支持很强但它需要认识每个基础算子你写的大 kernel 它可能整个当成黑盒性能反而差。慎用控制流。循环和条件分支在数据流架构上要靠特殊的同步机制实现代价不低。能量化就量化能展开就展开。批处理的边界要清楚。连续批处理continuous batching在这类架构上需要额外的调度层如果平台没提供就退化成静态批批次凑不齐会浪费阵列。我特别想强调第二条。有位同行把一个融合了十几个操作的 attention 算子整体搬过去编译能过但性能只有预期的一半。后来拆成标准算子组合交给编译器让它自己融合性能反而上去了——因为编译器知道每个算子的边界能做更精细的 tile 切分和存储复用。在数据流架构上让编译器看见细节比替编译器做决定更有效。5. 常见问题与排查实录5.1 典型故障速查表现象可能原因定位方法处理方式编译卡住或超时图过大、tile 搜索空间爆炸看编译日志的阶段耗时手动指定 tile 上界关闭自动搜索编译失败提示资源超限单次映射的图超过阵列容量看报告里的资源占用明细加大切分段数或把部分算子拆出运行 OOMKV cache 或激活超出预算按 4.2 的公式重算降批、KV 量化、缩 tile吞吐只有理论值三成片上溢出严重看溢出字节数与占比优先缩 tile其次降精度策略延迟抖动大存在动态 shape 或调度层排队抓单请求时间戳分布固定 shape改用静态批扩卡不线性张量切通信打断流水看多卡通信占比改层切加微批流水输出精度下降量化范围过激逐层对比参考输出敏感层norm、softmax回到 FP16多卡结果不一致微批边界或归约顺序问题单卡跑同批次对比固定归约顺序检查种子5.2 几个只有踩过才知道的坑坑一编译报告比性能测试更值得看。我早期的一个坏习惯是改完参数立刻跑 benchmark跑一次十几分钟一天试不了几个组合。后来改成只看编译报告——溢出量、占用率、气泡这三个数就能预判 80% 的性能走向只有报告看起来健康了才值得跑实测。这个习惯把迭代效率提了好几倍。坑二阵列占用率不是越高越好。曾经把占用率从 72% 硬调到 91%结果吞吐反而降了。原因是剩下的 9% 空间被塞得太满编译器没有余量做流水重叠气泡从 6% 涨到 22%。留余量是设计的一部分不是浪费。坑三批大小存在隐性台阶。这类芯片的收益曲线不是平滑的往往在某几个特定批大小上出现台阶——因为批大小决定了 tile 能否整除、能否填满阵列的行列数。实测时要以 2 的幂次为基准做二分而不是 1、2、3 这样线性扫。坑四量化的收益要算总账。8 比特权重确实省了存储但反量化可能要额外算子如果这部分算子没被融合进流水线反而多了访存。判断标准很简单量化前后看片上溢出量有没有真的下降没降就说明省下的空间又被中间张量吃回去了。坑五多节点场景先验证单节点线性度。我见过团队上来就调 16 节点结果一直在追一个根本不存在的网络问题最后发现是单节点 8 卡本身就只有 5.8 倍扩展效率。基础不牢越往上越乱。5.3 什么场景值得上什么场景别硬上说句实在的这类芯片不是万金油。结构稳定、连续调用、对延迟和确定性敏感的推理负载——比如固定长度文档的批量编码、长上下文对话的生成、多模态模型的稳定前向——它能给出很漂亮的能效和延迟曲线。反过来算子日更的实验性模型、形状高度动态的负载、需要频繁在训练和推理间切换的场景硬上会非常痛苦光编译适配就能耗掉两周。我的建议是拿一个真实业务里最常跑的那条链路去测别用标准 benchmark。标准 benchmark 都是规整的测出来的数字好看但和你没关系。真实链路里那些 padding、那些变长、那些后处理才是决定这套架构能不能落地的关键。最后分享一个我一直在用的小方法给每个模型建立编译档案——记录 tile 配置、精度策略、数组占用、溢出量、实测吞吐以及当时的编译器和固件版本。这类平台的版本敏感性比通用 GPU 高得多同一套配置换个版本性能可能差 20%。档案能让你在升级之后快速定位是哪一环退化了而不是从零开始重新摸索。这套东西听起来笨但在我参与的几个项目里它省下的重复劳动比任何调优技巧都多。
