在 AI 算力领域SambaNova 的 Reconfigurable Dataflow UnitRDU可重构数据流单元经常和 GPU 放在一起讨论但它并不是 GPU 的另一种实现。RDU 是一种从计算模型上就和 CPU/GPU 分道扬镳的专用处理器它没有传统意义上的指令流而是由编译器把深度学习模型映射成一张可配置的数据流图再在芯片上把这张图“铺设”出来。对做 AI 基础设施、模型推理、训练加速的工程师来说理解 RDU 的核心意义在于当模型规模和访问特征固定时把“取指令-译码-执行”的通用计算方式换成“数据在硬件通路里流动”的方式可以更高效地利用片上资源和带宽。这篇文章从架构原理、编译器、软件栈、实际运行流程、排查思路和选型清单几个角度展开目标是让没有接触过 RDU 的人也能判断它适合什么场景以及为什么它很难用 GPU 的思维去理解。1. RDU 为什么存在从控制流到数据流1.1 CPU 和 GPU 的共同前提指令驱动现代 CPU 和 GPU 都建立在控制流模型之上。CPU 每个核心有取指、译码、执行、写回几个阶段程序计数器按地址取指令遇到分支还要预测跳转方向。GPU 虽然用大量线程掩盖延迟但本质上仍然是指令驱动计算单元要不断从指令流中取指令由调度器分发线程再按同一指令处理不同的数据。这套模型的优点是通用性任何可编程任务都能运行代价是硬件要为“下一条指令是什么”投入大量资源包括指令缓存、分支预测、乱序执行、寄存器文件等。对于循环体很长、分支很少的矩阵运算这部分开销非常明显。从能耗角度理解更直接。一次矩阵乘法中真正做乘加运算的能耗占比并不高大量能量消耗在取指、调度、缓存命中和数据搬运上。如果能把“指令”这个环节拿掉让数据自己沿着固定的通路流动理论上可以省下大量与计算本身无关的开销。1.2 AI 计算负载的两个典型特征AI 训练和推理负载有两个突出特征。第一计算模式高度重复。一个 transformer 层就是 QKV 投影、注意力打分、softmax、加权求和、MLP几十层基本同构CNN 是卷积、池化、激活的重复堆叠。同一段计算逻辑会被执行成千上万次而且每次执行的算子顺序、数据依赖几乎不变。第二数据复用率高。一个权重矩阵要被同一 batch 里的所有样本反复使用激活值也要在多个算子之间流动。矩阵乘天然有很高的数据重用性适合用流水线方式处理。这两点决定了如果能把计算图固定下来让数据在一个预铺好的硬件通路上连续流动就可以省掉大量与计算本身无关的取指和调度开销。这正是 RDU 的出发点。1.3 数据流计算让数据决定执行数据流dataflow计算的核心思想是操作在操作数准备好了之后自动触发而不是由指令流控制。早期数据流机在 1980 年代就被研究过但通用负载的代价太高。问题在于通用程序的分支、动态数据依赖、不可预知的内存访问会让“数据在哪、下一步去哪”很难静态决定。RDU 的取舍是不追求通用计算只服务可静态分析的深度学习模型。当模型的算子、shape、依赖关系在编译期已知时数据流图就是确定的硬件可以按这个图做精确的资源分配。这就是它被称为数据流单元的原因。1.4 “可重构”意味着什么可重构在这里有两层含义。第一层是硬件层面的重构RDU 上的计算单元、存储单元和互连路径可以在运行前通过配置被设置成特定模型需要的形态相当于把模型“铺”在芯片上。第二层是灵活性同一块 RDU 跑不同模型时不必重新设计芯片只要重新配置数据通路即可。这听起来像 FPGA但 RDU 的配置不是门级重构而是算子级数据流调度的重构。编译器承担了绝大部分布局和调度工作所以它常被描述为 software-defined hardware硬件提供可配置的粗粒度资源软件定义资源如何连接。CPU、GPU、RDU 三者最核心的差异可以浓缩成一张表维度CPUGPURDU执行模型控制流指令驱动SIMT线程指令驱动数据流配置驱动调度单位指令warp / 线程块数据流图程序表达任意可编程语言CUDA / OpenCL高层框架 编译器资源分配运行时由硬件管理运行时由硬件调度编译期由编译器静态规划优势场景分支多、交互多并行度高、通用性强结构固定、重复执行的模型主要代价取指和调度开销高指令调度和访存开销仍在编译成本高、动态能力弱2. RDU 的硬件结构计算单元、片上存储与互连2.1 从 Tile 到 PCU 和 PMU在公开的 RDU 资料和专利描述中芯片内部通常被划分为多个 tile每个 tile 内包含两类主要资源一类用于计算SambaNova 术语中常称为 PCUPattern Compute Unit模式计算单元另一类用于存储常称为 PMUPattern Memory Unit模式存储单元。PCU 针对“同一种计算模式重复执行”设计适合把矩阵乘法、卷积的切片映射成固定流水线。PMU 则贴近计算单元放置保存激活值和中间结果减少数据在芯片上来回搬运。tile 之间通过片上网络互联。不同代际 RDU 的 tile 数量、SRAM 大小、互联带宽都有差异具体参数应以官方数据手册为准。理解这一类结构的重点不是记住数字而是建立两个观念计算资源是分片的存储资源是分布式贴近计算的。2.2 片上存储优先减少数据搬运传统 GPU 的存储层次是寄存器、L1/L2 cache、HBM 显存、系统内存数据不断在层级之间移动cache miss 会带来停顿和带宽占用。RDU 的思路不同。编译器在编译期就知道每个张量何时产生、何时被消费、生命周期多长于是可以把它直接放到离消费它的 PCU 最近的 PMU 上。这相当于把“运行时缓存”变成“编译期缓存”。代价是如果计算图很大、中间结果很多SRAM 容量会限制可同时保活的数据量。编译器必须做复杂的 buffer 融合、内存复用和调度。这也是为什么 RDU 的设计不能只看芯片本身还要看编译器能力。数据放不下时要么减少同时活跃的中间结果要么把数据搬到片外再搬回来这两种选择都会反映在最终性能上。2.3 互连与流水线数据流动的骨架数据流需要硬件提供确定的流动路径。RDU 的片上网络不是普通总线的广播式访问而是支持在多个计算单元之间建立点对点、流水线式的数据通路。一个算子算完结果以固定速率向后传递下一个算子立刻消费。这样就像工厂流水线原料从一端进入成品从另一端出来中间每个工位都在并行处理不同批次的数据。对 transformer 这种层间结构固定的模型流水线式执行可以把不同层的计算重叠起来提高硬件利用率。2.4 和 GPU 思维不同的内存管理用 GPU 的思维看 RDU 很容易误解。GPU 上做优化时常说“合并内存访问”“减少 bank conflict”“提高 cache hit”这些是线程级并行视角下的优化。RDU 上没有线程这个抽象编译器考虑的是 buffer 布局、数据依赖、片上网络路由和资源占用。如果团队已经习惯用 CUDA profiler 的结果指导优化换到 RDU 后要重新学习分析对象编译报告、资源占用、buffer footprint、数据流饱和度而不是 warp occupancy。3. 编译器才是 RDU 真正的“第二颗芯片”3.1 没有指令集模型怎么跑RDU 没有公开的、面向用户的指令集这正是它和 CPU/GPU 最重要的区别。用户不直接写汇编或 CUDA kernel而是用高层框架描述模型然后由编译器把模型映射成 RDU 的数据流配置。换句话说RDU 在运行前就被配置成“这个模型的样子”。配置一旦生成硬件执行的是一张固定的数据流图而不是一串动态指令。这个设计让编译器承担了传统硬件控制器的工作也意味着编译器能力直接决定硬件能跑多快。在 SambaNova 的软件栈中SambaFlow 负责模型编译和运行SambaStudio 提供围绕模型开发、部署和管理的环境。具体模块名称和版本会随产品演进变化落地前要以官方文档为准。3.2 编译流程的五个阶段从高层模型到 RDU 配置编译过程大致可以分成五步。不同实现细节有差异但思路是相同的。第一步图获取。用 trace 或转换方式把 PyTorch、ONNX 等模型变成静态计算图。这一步决定了后面所有优化的输入。第二步图优化。做算子融合、常量折叠、layout 转换、去掉冗余拷贝。例如把连续的矩阵乘和激活融合成一个算子减少中间结果的写回和读取。第三步内存规划。计算每个张量的生命周期分配 PMU buffer尽量复用。生命周期不重叠的张量可以共用同一块 buffer。第四步资源映射。把算子分配到具体 tile 和 PCU考虑负载均衡和数据依赖。计算放在哪个 tile直接影响片上网络的流量和延迟。第五步配置生成。输出硬件配置和 host 端可执行文件供运行时加载。每一步都会影响最终性能和正确性。尤其第三步和第四步本质上是一个资源分配和调度问题数据放哪里、什么时候搬、计算放哪个 tile都会影响整体执行效率。3.3 为什么动态 shape 会让编译器很被动动态 shape 是编译器最不喜欢的东西。如果 batch size 或序列长度在运行时变化buffer 大小就不能固定数据流路径就很难提前铺好。编译器只能按最大可能 shape 预留资源或者落到低效的通用分支。很多 RDU 项目花在 shape 对齐上的时间远比想象中多。常见做法是把序列 padding 到固定长度或者按几个固定档位编译多份配置运行时按输入长度选择。动态控制流例如依赖数据的 if 和 while也是如此支持程度取决于编译器版本但代价一定高于静态图。注意RDU 的性能上限不是由峰值算力单独决定的而是由“编译器能把计算图切得多好、内存规划得多紧凑”决定的。评估 RDU 时必须同时评估编译器成熟度。4. 用最小示例走通 RDU 运行流程4.1 环境准备先确认硬件和软件栈学习 RDU 至少要在一台装有 RDU 的服务器或云端实例上进行因为编译产物只能在 RDU 上运行纯 CPU 环境通常只能做编译练习。开始前需要逐项确认环境。环境项需要确认确认失败的影响RDU 硬件能被驱动识别查询命令可用无法运行编译产物驱动和运行时版本与软件栈匹配运行时报设备错误Python 环境版本受支持安装依赖失败SambaFlow 版本与 Python、PyTorch 版本匹配编译和运行时行为不一致PyTorch 版本在支持列表内模型 trace 阶段失败实际排查时先用设备管理工具确认 RDU 可见。以官方文档中的查询命令为准常见的显示内容包括设备型号、驱动版本、显存占用等。4.2 编写一个可编译的模型脚本RDU 的编程入口是框架级别的 API。模型仍用 PyTorch 风格的代码描述但必须保证能被静态编译。下面是一个简化的注意力块示例目的是展示代码形态不是官方模板。import torch from torch import nn # 说明以下代码用于呈现 RDU 编程模型的代码形态 # 具体 API、模块名和参数以所使用版本的官方文档为准 class SmallAttention(nn.Module): def __init__(self, hidden_size768, num_heads12): super().__init__() self.num_heads num_heads self.head_dim hidden_size // num_heads self.qkv nn.Linear(hidden_size, 3 * hidden_size) self.out nn.Linear(hidden_size, hidden_size) def forward(self, x): # x: [batch, seq_len, hidden_size] qkv self.qkv(x) # [batch, seq_len, 3 * hidden_size] q, k, v torch.chunk(qkv, 3, dim-1) # 真实项目中attention mask、缩放、softmax 等需要 # 使用编译器支持的算子完整实现这里省略细节 attn torch.matmul(q, k.transpose(-2, -1)) attn torch.softmax(attn, dim-1) out torch.matmul(attn, v) return self.out(out)关键不是模型多复杂而是写成结构固定、shape 固定、算子列表明确的代码。模型里出现的每个算子都需要在编译器的支持列表中。如果使用了自定义算子、Python 列表推导或依赖数据的循环编译器可能无法处理。4.3 编译与运行命令下面这段命令展示了通用步骤# 编译把模型映射成 RDU 配置 sambaflow compile small_attention.py \ --model-name small_attention \ --compile-dir compiled/small_attention \ --batch-size 1 \ --seq-len 128 \ --hidden-size 768 # 运行加载配置并在 RDU 上执行 sambaflow run small_attention.py \ --model-name small_attention \ --compile-dir compiled/small_attention \ --batch-size 1 \ --seq-len 128 \ --hidden-size 768不同版本 SambaFlow 的参数名和必填项可能不同应以官方文档为准。编译完成后重点看编译报告而不是只确认没有报错。编译报告通常包含资源占用、buffer 规划、算子映射和潜在瓶颈信息。4.4 验证运行结果验证运行结果至少要做三件事。第一检查输出 shape 是否与预期一致。第二把同样的输入在 CPU 上用 PyTorch 跑一遍比较输出在数值容忍范围内是否一致用于发现精度模式设置问题。第三查看编译报告和运行日志确认资源占用、buffer 使用、执行时间在合理范围。如果模型是训练任务还要检查 loss 是否按预期下降不能只看训练脚本有没有退出。注意不要只验证程序能启动。RDU 项目的风险往往出现在编译期资源分配和运行期数值精度上这两项才是验证重点。5. 关键参数与配置影响性能和成本的细节5.1 参数速查RDU 项目的参数调整和 GPU 项目不完全一样。很多在 GPU 上可以运行时调整的参数在 RDU 上需要在编译期确定。参数含义偏小的影响偏大的影响推荐方向batch-size每次处理样本数硬件利用率低buffer 占用高可能编译失败在编译报告指导下逐步增大seq-len序列长度浪费表达能力需要更大 bufferpadding 浪费按业务最大长度固定输入 shape图像高宽等无法覆盖真实输入资源预留过多固定为业务典型档位precisionFP32、BF16 等精度更高性能更低数值误差增大训练用 BF16推理按精度验证芯片数量多芯片配置单芯片放不下跨芯片通信成本上升按模型显存和通信量估算编译模式训练 / 推理资源规划不符合目标无法满足另一类场景训练推理分别编译batch-size 偏小时计算单元可能处于空转等待状态偏大时中间激活值的 buffer 规划会变紧张甚至直接编译失败。调整 batch-size 后必须重新编译不能像 GPU 那样运行时换一个值就生效。5.2 推理与训练场景的配置差异推理场景追求吞吐和低延迟输入 shape 一般固定可以针对固定的 batch 大小编译一份配置长期复用。训练场景需要保存梯度、优化器状态和中间激活内存压力更大编译配置会预留更多 buffer。切换训练和推理不是改一个 flag 的事而是编译时就使用不同的目标配置。因此不要把同一个编译产物既当训练又当推理使用。数值方面也有差异。训练常用 BF16 混合精度因为梯度对精度要求相对宽松推理时如果模型在 BF16 下掉点就要检查逐层误差必要时让某些层保持高精度。这个选择同样需要在编译期确定。5.3 多芯片部署与拓扑RDU 单片容量有限大模型需要多芯片。传统分布式训练里模型并行、数据并行、流水线并行都是开发者用代码实现的RDU 的编译器可以把图切分到多颗芯片开发者更多是配置拓扑和资源而不是手写 all-reduce。这降低了大模型部署的编码成本但依赖编译器的切分质量。遇到多芯片性能不达预期时优先看跨芯片通信量和负载均衡而不是急着调整训练参数。跨芯片通信越频繁收益越接近通信瓶颈。6. RDU 项目常见问题与排查路径6.1 排查顺序从可编译性开始排 RDU 的问题和排 GPU 问题顺序不同。GPU 问题常常从 CUDA error、显存溢出查起RDU 问题要先确认模型能不能编译。推荐排查顺序模型可编译性算子是否支持、shape 是否静态、是否有动态控制流。编译日志和编译报告内存布局、资源占用、哪个算子被降级。运行日志host 端错误、设备端错误。数值对比输出精度、loss 曲线、与 CPU 结果差异。性能分析batch 大小、数据 pipeline、跨芯片通信。6.2 常见错误现象表现象常见原因检查方式处理建议编译失败使用了不支持的算子查看编译日志中的算子名替换为支持算子或拆分算子编译失败shape 不固定检查输入是否动态生成固定 shapepadding 到最大长度编译失败模型中含有动态控制流搜索 forward 中依赖数据的 if/while改成静态条件或提前展开运行时内存不足batch 或序列过大查看编译报告中的 buffer 占用减小 batch 或重新规划中间结果输出精度偏差大精度模式配置不一致和 CPU 参考结果对比检查 precision 设置隔离异常层模型没有加速batch 太小或模型过小查看硬件利用率和执行时间增大 batch评估模型是否适合 RDU反复重新编译配置或 shape 频繁变化查看编译触发原因固定 shape 档位建立配置缓存6.3 静态图思维下最容易踩的坑三个坑在迁移 RDU 时出现频率最高。第一个坑模型里有 list comprehension 或依赖数据的循环编译器没法静态展开。例如在 forward 里根据 seq_len 动态拼接 tensortrace 阶段可能通过编译阶段却报错。第二个坑为了省显存把中间张量 detach 或用 Python 对象保存破坏了图结构。RDU 编译器需要完整的依赖关系来做内存规划和调度任何人为切断图的操作都会降低优化效果。第三个坑把 GPU 的 batch size 习惯直接搬过来不考虑编译产物的 buffer footprint。GPU 上显存不够可以换更大显存的卡RDU 上则要重新编译而且 buffer 规划是否合理直接决定能不能编译通过。团队迁移 RDU 时前两周往往都花在把这些“动态习惯”改成“静态表达”上。这是学习成本最高的部分也是理解数据流架构的关键一步。7. 选型判断与落地检查清单7.1 适合 RDU 的负载特征适合 RDU 的场景通常具备以下特征模型结构确定、迭代频率低例如已经定型的 LLM 服务、推荐模型、CV 批处理模型。输入 shape 可以固定或者通过 padding 变成固定 shape。推理时存在稳定、重复的算子序列层与层之间结构一致。对功耗和时延敏感希望在有限功耗内提高单位吞吐。团队愿意投入编译器、静态图、性能分析方面的工程能力。RDU 更适合把“已经稳定的模型”部署成高吞吐服务而不是在模型还在频繁调整时做每轮实验的加速器。7.2 需要谨慎评估的场景以下几类场景需要谨慎实验型研究团队天天改模型结构。编译成本会抵消部分执行收益。已有大量自定义 CUDA kernel 的代码库RDU 无法原样运行迁移成本高。输入高度动态、单请求长度差异极大padding 浪费严重。团队没有静态图优化经验遇到编译报错不知道从哪一层查起。选择前先拿实际模型跑一轮编译和性能对比不要只看峰值算力宣传。7.3 落地前检查清单上线前把下面清单过一遍模型所有算子是否在支持列表中。是否能为所有输入确定固定 shape 档位。训练和推理是否分别编译了对应配置。是否有 BF16 精度验证和异常层定位方案。编译时延是否在产品可接受范围内。host 端数据 pipeline 是否会和 RDU 执行重叠避免数据预处理成为瓶颈。是否有监控、日志和回滚机制能不能在运行结果异常时快速切回旧版本。是否建立了 CPU/GPU 对照基线方便评估真实收益。清单里的每一项都有实际代价。最容易忽略的是第一项和最后一项算子不支持会导致编译失败没有基线会导致“看似加速但没有业务收益”的判断偏差。8. 理解 RDU 的正确姿势软硬件协同是核心8.1 把问题从“有没有更多核”换成“数据流怎么铺”RDU 给开发者最重要的启发是评估加速硬件时不要只看峰值算力要看数据流如何被组织。GPU 拿高算力硬扛不规则负载RDU 则把模型图变成硬件配置把问题从“有没有更多核心”换成“数据流怎么铺、buffer 怎么安排、编译器怎么切分”。这就是为什么 RDU 的选型要连同编译器一起评估。硬件只是执行框架编译器决定了真实效率。一个结构很漂亮但编译器规划很粗糙的数据流图实际跑起来可能还不如一张简单图。8.2 下一步学习建议如果决定深入学习 RDU方向可以按这个顺序展开第一掌握静态计算图的表示和优化理解算子融合、内存复用、拓扑排序这些基础概念。第二练习把常见 PyTorch 模型改造为可编译形态重点处理动态 shape 和动态控制流。第三研究 transformer 在数据流硬件上的映射理解为什么层间结构固定的模型天然适合这种架构。第四在有硬件环境下把编译报告和运行 profile 对照分析看哪些警告被忽略后变成了性能损失。对很多团队来说RDU 不是 GPU 的替代品而是提出了另一种看待 AI 算力的方式当程序和硬件在编译期就达成一致时运行时的开销才会真正降下来。理解这一点比记住任何具体芯片参数都更有价值。 
长河君 · 2026/8/30 5:23:59 · 阅读 1.2k 数据流架构的AI加速：RDU可重构数据流单元原理与工程实践
在 AI 算力领域SambaNova 的 Reconfigurable Dataflow UnitRDU可重构数据流单元经常和 GPU 放在一起讨论但它并不是 GPU 的另一种实现。RDU 是一种从计算模型上就和 CPU/GPU 分道扬镳的专用处理器它没有传统意义上的指令流而是由编译器把深度学习模型映射成一张可配置的数据流图再在芯片上把这张图“铺设”出来。对做 AI 基础设施、模型推理、训练加速的工程师来说理解 RDU 的核心意义在于当模型规模和访问特征固定时把“取指令-译码-执行”的通用计算方式换成“数据在硬件通路里流动”的方式可以更高效地利用片上资源和带宽。这篇文章从架构原理、编译器、软件栈、实际运行流程、排查思路和选型清单几个角度展开目标是让没有接触过 RDU 的人也能判断它适合什么场景以及为什么它很难用 GPU 的思维去理解。1. RDU 为什么存在从控制流到数据流1.1 CPU 和 GPU 的共同前提指令驱动现代 CPU 和 GPU 都建立在控制流模型之上。CPU 每个核心有取指、译码、执行、写回几个阶段程序计数器按地址取指令遇到分支还要预测跳转方向。GPU 虽然用大量线程掩盖延迟但本质上仍然是指令驱动计算单元要不断从指令流中取指令由调度器分发线程再按同一指令处理不同的数据。这套模型的优点是通用性任何可编程任务都能运行代价是硬件要为“下一条指令是什么”投入大量资源包括指令缓存、分支预测、乱序执行、寄存器文件等。对于循环体很长、分支很少的矩阵运算这部分开销非常明显。从能耗角度理解更直接。一次矩阵乘法中真正做乘加运算的能耗占比并不高大量能量消耗在取指、调度、缓存命中和数据搬运上。如果能把“指令”这个环节拿掉让数据自己沿着固定的通路流动理论上可以省下大量与计算本身无关的开销。1.2 AI 计算负载的两个典型特征AI 训练和推理负载有两个突出特征。第一计算模式高度重复。一个 transformer 层就是 QKV 投影、注意力打分、softmax、加权求和、MLP几十层基本同构CNN 是卷积、池化、激活的重复堆叠。同一段计算逻辑会被执行成千上万次而且每次执行的算子顺序、数据依赖几乎不变。第二数据复用率高。一个权重矩阵要被同一 batch 里的所有样本反复使用激活值也要在多个算子之间流动。矩阵乘天然有很高的数据重用性适合用流水线方式处理。这两点决定了如果能把计算图固定下来让数据在一个预铺好的硬件通路上连续流动就可以省掉大量与计算本身无关的取指和调度开销。这正是 RDU 的出发点。1.3 数据流计算让数据决定执行数据流dataflow计算的核心思想是操作在操作数准备好了之后自动触发而不是由指令流控制。早期数据流机在 1980 年代就被研究过但通用负载的代价太高。问题在于通用程序的分支、动态数据依赖、不可预知的内存访问会让“数据在哪、下一步去哪”很难静态决定。RDU 的取舍是不追求通用计算只服务可静态分析的深度学习模型。当模型的算子、shape、依赖关系在编译期已知时数据流图就是确定的硬件可以按这个图做精确的资源分配。这就是它被称为数据流单元的原因。1.4 “可重构”意味着什么可重构在这里有两层含义。第一层是硬件层面的重构RDU 上的计算单元、存储单元和互连路径可以在运行前通过配置被设置成特定模型需要的形态相当于把模型“铺”在芯片上。第二层是灵活性同一块 RDU 跑不同模型时不必重新设计芯片只要重新配置数据通路即可。这听起来像 FPGA但 RDU 的配置不是门级重构而是算子级数据流调度的重构。编译器承担了绝大部分布局和调度工作所以它常被描述为 software-defined hardware硬件提供可配置的粗粒度资源软件定义资源如何连接。CPU、GPU、RDU 三者最核心的差异可以浓缩成一张表维度CPUGPURDU执行模型控制流指令驱动SIMT线程指令驱动数据流配置驱动调度单位指令warp / 线程块数据流图程序表达任意可编程语言CUDA / OpenCL高层框架 编译器资源分配运行时由硬件管理运行时由硬件调度编译期由编译器静态规划优势场景分支多、交互多并行度高、通用性强结构固定、重复执行的模型主要代价取指和调度开销高指令调度和访存开销仍在编译成本高、动态能力弱2. RDU 的硬件结构计算单元、片上存储与互连2.1 从 Tile 到 PCU 和 PMU在公开的 RDU 资料和专利描述中芯片内部通常被划分为多个 tile每个 tile 内包含两类主要资源一类用于计算SambaNova 术语中常称为 PCUPattern Compute Unit模式计算单元另一类用于存储常称为 PMUPattern Memory Unit模式存储单元。PCU 针对“同一种计算模式重复执行”设计适合把矩阵乘法、卷积的切片映射成固定流水线。PMU 则贴近计算单元放置保存激活值和中间结果减少数据在芯片上来回搬运。tile 之间通过片上网络互联。不同代际 RDU 的 tile 数量、SRAM 大小、互联带宽都有差异具体参数应以官方数据手册为准。理解这一类结构的重点不是记住数字而是建立两个观念计算资源是分片的存储资源是分布式贴近计算的。2.2 片上存储优先减少数据搬运传统 GPU 的存储层次是寄存器、L1/L2 cache、HBM 显存、系统内存数据不断在层级之间移动cache miss 会带来停顿和带宽占用。RDU 的思路不同。编译器在编译期就知道每个张量何时产生、何时被消费、生命周期多长于是可以把它直接放到离消费它的 PCU 最近的 PMU 上。这相当于把“运行时缓存”变成“编译期缓存”。代价是如果计算图很大、中间结果很多SRAM 容量会限制可同时保活的数据量。编译器必须做复杂的 buffer 融合、内存复用和调度。这也是为什么 RDU 的设计不能只看芯片本身还要看编译器能力。数据放不下时要么减少同时活跃的中间结果要么把数据搬到片外再搬回来这两种选择都会反映在最终性能上。2.3 互连与流水线数据流动的骨架数据流需要硬件提供确定的流动路径。RDU 的片上网络不是普通总线的广播式访问而是支持在多个计算单元之间建立点对点、流水线式的数据通路。一个算子算完结果以固定速率向后传递下一个算子立刻消费。这样就像工厂流水线原料从一端进入成品从另一端出来中间每个工位都在并行处理不同批次的数据。对 transformer 这种层间结构固定的模型流水线式执行可以把不同层的计算重叠起来提高硬件利用率。2.4 和 GPU 思维不同的内存管理用 GPU 的思维看 RDU 很容易误解。GPU 上做优化时常说“合并内存访问”“减少 bank conflict”“提高 cache hit”这些是线程级并行视角下的优化。RDU 上没有线程这个抽象编译器考虑的是 buffer 布局、数据依赖、片上网络路由和资源占用。如果团队已经习惯用 CUDA profiler 的结果指导优化换到 RDU 后要重新学习分析对象编译报告、资源占用、buffer footprint、数据流饱和度而不是 warp occupancy。3. 编译器才是 RDU 真正的“第二颗芯片”3.1 没有指令集模型怎么跑RDU 没有公开的、面向用户的指令集这正是它和 CPU/GPU 最重要的区别。用户不直接写汇编或 CUDA kernel而是用高层框架描述模型然后由编译器把模型映射成 RDU 的数据流配置。换句话说RDU 在运行前就被配置成“这个模型的样子”。配置一旦生成硬件执行的是一张固定的数据流图而不是一串动态指令。这个设计让编译器承担了传统硬件控制器的工作也意味着编译器能力直接决定硬件能跑多快。在 SambaNova 的软件栈中SambaFlow 负责模型编译和运行SambaStudio 提供围绕模型开发、部署和管理的环境。具体模块名称和版本会随产品演进变化落地前要以官方文档为准。3.2 编译流程的五个阶段从高层模型到 RDU 配置编译过程大致可以分成五步。不同实现细节有差异但思路是相同的。第一步图获取。用 trace 或转换方式把 PyTorch、ONNX 等模型变成静态计算图。这一步决定了后面所有优化的输入。第二步图优化。做算子融合、常量折叠、layout 转换、去掉冗余拷贝。例如把连续的矩阵乘和激活融合成一个算子减少中间结果的写回和读取。第三步内存规划。计算每个张量的生命周期分配 PMU buffer尽量复用。生命周期不重叠的张量可以共用同一块 buffer。第四步资源映射。把算子分配到具体 tile 和 PCU考虑负载均衡和数据依赖。计算放在哪个 tile直接影响片上网络的流量和延迟。第五步配置生成。输出硬件配置和 host 端可执行文件供运行时加载。每一步都会影响最终性能和正确性。尤其第三步和第四步本质上是一个资源分配和调度问题数据放哪里、什么时候搬、计算放哪个 tile都会影响整体执行效率。3.3 为什么动态 shape 会让编译器很被动动态 shape 是编译器最不喜欢的东西。如果 batch size 或序列长度在运行时变化buffer 大小就不能固定数据流路径就很难提前铺好。编译器只能按最大可能 shape 预留资源或者落到低效的通用分支。很多 RDU 项目花在 shape 对齐上的时间远比想象中多。常见做法是把序列 padding 到固定长度或者按几个固定档位编译多份配置运行时按输入长度选择。动态控制流例如依赖数据的 if 和 while也是如此支持程度取决于编译器版本但代价一定高于静态图。注意RDU 的性能上限不是由峰值算力单独决定的而是由“编译器能把计算图切得多好、内存规划得多紧凑”决定的。评估 RDU 时必须同时评估编译器成熟度。4. 用最小示例走通 RDU 运行流程4.1 环境准备先确认硬件和软件栈学习 RDU 至少要在一台装有 RDU 的服务器或云端实例上进行因为编译产物只能在 RDU 上运行纯 CPU 环境通常只能做编译练习。开始前需要逐项确认环境。环境项需要确认确认失败的影响RDU 硬件能被驱动识别查询命令可用无法运行编译产物驱动和运行时版本与软件栈匹配运行时报设备错误Python 环境版本受支持安装依赖失败SambaFlow 版本与 Python、PyTorch 版本匹配编译和运行时行为不一致PyTorch 版本在支持列表内模型 trace 阶段失败实际排查时先用设备管理工具确认 RDU 可见。以官方文档中的查询命令为准常见的显示内容包括设备型号、驱动版本、显存占用等。4.2 编写一个可编译的模型脚本RDU 的编程入口是框架级别的 API。模型仍用 PyTorch 风格的代码描述但必须保证能被静态编译。下面是一个简化的注意力块示例目的是展示代码形态不是官方模板。import torch from torch import nn # 说明以下代码用于呈现 RDU 编程模型的代码形态 # 具体 API、模块名和参数以所使用版本的官方文档为准 class SmallAttention(nn.Module): def __init__(self, hidden_size768, num_heads12): super().__init__() self.num_heads num_heads self.head_dim hidden_size // num_heads self.qkv nn.Linear(hidden_size, 3 * hidden_size) self.out nn.Linear(hidden_size, hidden_size) def forward(self, x): # x: [batch, seq_len, hidden_size] qkv self.qkv(x) # [batch, seq_len, 3 * hidden_size] q, k, v torch.chunk(qkv, 3, dim-1) # 真实项目中attention mask、缩放、softmax 等需要 # 使用编译器支持的算子完整实现这里省略细节 attn torch.matmul(q, k.transpose(-2, -1)) attn torch.softmax(attn, dim-1) out torch.matmul(attn, v) return self.out(out)关键不是模型多复杂而是写成结构固定、shape 固定、算子列表明确的代码。模型里出现的每个算子都需要在编译器的支持列表中。如果使用了自定义算子、Python 列表推导或依赖数据的循环编译器可能无法处理。4.3 编译与运行命令下面这段命令展示了通用步骤# 编译把模型映射成 RDU 配置 sambaflow compile small_attention.py \ --model-name small_attention \ --compile-dir compiled/small_attention \ --batch-size 1 \ --seq-len 128 \ --hidden-size 768 # 运行加载配置并在 RDU 上执行 sambaflow run small_attention.py \ --model-name small_attention \ --compile-dir compiled/small_attention \ --batch-size 1 \ --seq-len 128 \ --hidden-size 768不同版本 SambaFlow 的参数名和必填项可能不同应以官方文档为准。编译完成后重点看编译报告而不是只确认没有报错。编译报告通常包含资源占用、buffer 规划、算子映射和潜在瓶颈信息。4.4 验证运行结果验证运行结果至少要做三件事。第一检查输出 shape 是否与预期一致。第二把同样的输入在 CPU 上用 PyTorch 跑一遍比较输出在数值容忍范围内是否一致用于发现精度模式设置问题。第三查看编译报告和运行日志确认资源占用、buffer 使用、执行时间在合理范围。如果模型是训练任务还要检查 loss 是否按预期下降不能只看训练脚本有没有退出。注意不要只验证程序能启动。RDU 项目的风险往往出现在编译期资源分配和运行期数值精度上这两项才是验证重点。5. 关键参数与配置影响性能和成本的细节5.1 参数速查RDU 项目的参数调整和 GPU 项目不完全一样。很多在 GPU 上可以运行时调整的参数在 RDU 上需要在编译期确定。参数含义偏小的影响偏大的影响推荐方向batch-size每次处理样本数硬件利用率低buffer 占用高可能编译失败在编译报告指导下逐步增大seq-len序列长度浪费表达能力需要更大 bufferpadding 浪费按业务最大长度固定输入 shape图像高宽等无法覆盖真实输入资源预留过多固定为业务典型档位precisionFP32、BF16 等精度更高性能更低数值误差增大训练用 BF16推理按精度验证芯片数量多芯片配置单芯片放不下跨芯片通信成本上升按模型显存和通信量估算编译模式训练 / 推理资源规划不符合目标无法满足另一类场景训练推理分别编译batch-size 偏小时计算单元可能处于空转等待状态偏大时中间激活值的 buffer 规划会变紧张甚至直接编译失败。调整 batch-size 后必须重新编译不能像 GPU 那样运行时换一个值就生效。5.2 推理与训练场景的配置差异推理场景追求吞吐和低延迟输入 shape 一般固定可以针对固定的 batch 大小编译一份配置长期复用。训练场景需要保存梯度、优化器状态和中间激活内存压力更大编译配置会预留更多 buffer。切换训练和推理不是改一个 flag 的事而是编译时就使用不同的目标配置。因此不要把同一个编译产物既当训练又当推理使用。数值方面也有差异。训练常用 BF16 混合精度因为梯度对精度要求相对宽松推理时如果模型在 BF16 下掉点就要检查逐层误差必要时让某些层保持高精度。这个选择同样需要在编译期确定。5.3 多芯片部署与拓扑RDU 单片容量有限大模型需要多芯片。传统分布式训练里模型并行、数据并行、流水线并行都是开发者用代码实现的RDU 的编译器可以把图切分到多颗芯片开发者更多是配置拓扑和资源而不是手写 all-reduce。这降低了大模型部署的编码成本但依赖编译器的切分质量。遇到多芯片性能不达预期时优先看跨芯片通信量和负载均衡而不是急着调整训练参数。跨芯片通信越频繁收益越接近通信瓶颈。6. RDU 项目常见问题与排查路径6.1 排查顺序从可编译性开始排 RDU 的问题和排 GPU 问题顺序不同。GPU 问题常常从 CUDA error、显存溢出查起RDU 问题要先确认模型能不能编译。推荐排查顺序模型可编译性算子是否支持、shape 是否静态、是否有动态控制流。编译日志和编译报告内存布局、资源占用、哪个算子被降级。运行日志host 端错误、设备端错误。数值对比输出精度、loss 曲线、与 CPU 结果差异。性能分析batch 大小、数据 pipeline、跨芯片通信。6.2 常见错误现象表现象常见原因检查方式处理建议编译失败使用了不支持的算子查看编译日志中的算子名替换为支持算子或拆分算子编译失败shape 不固定检查输入是否动态生成固定 shapepadding 到最大长度编译失败模型中含有动态控制流搜索 forward 中依赖数据的 if/while改成静态条件或提前展开运行时内存不足batch 或序列过大查看编译报告中的 buffer 占用减小 batch 或重新规划中间结果输出精度偏差大精度模式配置不一致和 CPU 参考结果对比检查 precision 设置隔离异常层模型没有加速batch 太小或模型过小查看硬件利用率和执行时间增大 batch评估模型是否适合 RDU反复重新编译配置或 shape 频繁变化查看编译触发原因固定 shape 档位建立配置缓存6.3 静态图思维下最容易踩的坑三个坑在迁移 RDU 时出现频率最高。第一个坑模型里有 list comprehension 或依赖数据的循环编译器没法静态展开。例如在 forward 里根据 seq_len 动态拼接 tensortrace 阶段可能通过编译阶段却报错。第二个坑为了省显存把中间张量 detach 或用 Python 对象保存破坏了图结构。RDU 编译器需要完整的依赖关系来做内存规划和调度任何人为切断图的操作都会降低优化效果。第三个坑把 GPU 的 batch size 习惯直接搬过来不考虑编译产物的 buffer footprint。GPU 上显存不够可以换更大显存的卡RDU 上则要重新编译而且 buffer 规划是否合理直接决定能不能编译通过。团队迁移 RDU 时前两周往往都花在把这些“动态习惯”改成“静态表达”上。这是学习成本最高的部分也是理解数据流架构的关键一步。7. 选型判断与落地检查清单7.1 适合 RDU 的负载特征适合 RDU 的场景通常具备以下特征模型结构确定、迭代频率低例如已经定型的 LLM 服务、推荐模型、CV 批处理模型。输入 shape 可以固定或者通过 padding 变成固定 shape。推理时存在稳定、重复的算子序列层与层之间结构一致。对功耗和时延敏感希望在有限功耗内提高单位吞吐。团队愿意投入编译器、静态图、性能分析方面的工程能力。RDU 更适合把“已经稳定的模型”部署成高吞吐服务而不是在模型还在频繁调整时做每轮实验的加速器。7.2 需要谨慎评估的场景以下几类场景需要谨慎实验型研究团队天天改模型结构。编译成本会抵消部分执行收益。已有大量自定义 CUDA kernel 的代码库RDU 无法原样运行迁移成本高。输入高度动态、单请求长度差异极大padding 浪费严重。团队没有静态图优化经验遇到编译报错不知道从哪一层查起。选择前先拿实际模型跑一轮编译和性能对比不要只看峰值算力宣传。7.3 落地前检查清单上线前把下面清单过一遍模型所有算子是否在支持列表中。是否能为所有输入确定固定 shape 档位。训练和推理是否分别编译了对应配置。是否有 BF16 精度验证和异常层定位方案。编译时延是否在产品可接受范围内。host 端数据 pipeline 是否会和 RDU 执行重叠避免数据预处理成为瓶颈。是否有监控、日志和回滚机制能不能在运行结果异常时快速切回旧版本。是否建立了 CPU/GPU 对照基线方便评估真实收益。清单里的每一项都有实际代价。最容易忽略的是第一项和最后一项算子不支持会导致编译失败没有基线会导致“看似加速但没有业务收益”的判断偏差。8. 理解 RDU 的正确姿势软硬件协同是核心8.1 把问题从“有没有更多核”换成“数据流怎么铺”RDU 给开发者最重要的启发是评估加速硬件时不要只看峰值算力要看数据流如何被组织。GPU 拿高算力硬扛不规则负载RDU 则把模型图变成硬件配置把问题从“有没有更多核心”换成“数据流怎么铺、buffer 怎么安排、编译器怎么切分”。这就是为什么 RDU 的选型要连同编译器一起评估。硬件只是执行框架编译器决定了真实效率。一个结构很漂亮但编译器规划很粗糙的数据流图实际跑起来可能还不如一张简单图。8.2 下一步学习建议如果决定深入学习 RDU方向可以按这个顺序展开第一掌握静态计算图的表示和优化理解算子融合、内存复用、拓扑排序这些基础概念。第二练习把常见 PyTorch 模型改造为可编译形态重点处理动态 shape 和动态控制流。第三研究 transformer 在数据流硬件上的映射理解为什么层间结构固定的模型天然适合这种架构。第四在有硬件环境下把编译报告和运行 profile 对照分析看哪些警告被忽略后变成了性能损失。对很多团队来说RDU 不是 GPU 的替代品而是提出了另一种看待 AI 算力的方式当程序和硬件在编译期就达成一致时运行时的开销才会真正降下来。理解这一点比记住任何具体芯片参数都更有价值。