数据流架构这条路，我陆陆续续跟了几年，从最早在实验室里啃粗粒度可重构阵列的论文，到后来真正在机房机架上跑模型、看编译日志、调 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 级已经在处理第 n+1 块。两级叠起来，理论上可以让阵列的每个单元在任何时刻都不闲着。
这里有个容易被误读的点：软件流水的级数不是越多越好。级数多了，填充和排空的开销占比上升，片上缓冲需求也变大，反而可能把 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_hint="auto", # 先交给编译器自动切 precision={"linear": "int8", "norm": "fp16", "attn_softmax": "fp16"}, pipeline_stages=2, # 首轮保守取 2 sram_budget_ratio=0.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 元素数 = 2（K和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 上。这时候如果你的批大小设到 32，KV cache 直接涨到 32 GB，HBM 带宽立刻成为瓶颈，吞吐曲线会出现明显的拐点。
我的经验是：先用公式估出 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 上界，关闭自动搜索 |
| 编译失败提示资源超限 | 单次映射的图超过阵列容量 | 看报告里的资源占用明细 | 加大切分段数，或把部分算子拆出 |
| 运行 OOM | KV 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%。档案能让你在升级之后快速定位是哪一环退化了，而不是从零开始重新摸索。这套东西听起来笨，但在我参与的几个项目里，它省下的重复劳动比任何调优技巧都多。
