Fireworks ARCv3 将 RL 权重更新压缩近 50%，支持跨区域训练

TL;DR

Fireworks 的新 ARCv3 压缩器可减小从训练器发送到生成强化学习（RL）rollout 的机器的 BF16 权重更新体积。

在 1,000 个生产 RL 权重更新 delta 上，ARCv3 生成的负载比 ARCv2 小近 50%，并且能无损重建训练器的精确 BF16 权重。

更小的传输量有助于 rollout 集群更贴近当前策略，使得跨区域使用算力而无需依赖一个巨型同地集群变得更加可行。

ARCv3 已通过 fireworks-delta-compression 在 Fireworks Training API 中提供，面向使用自有训练器搭配 Fireworks rollout 的团队。

随着越来越多团队投身强化学习以训练自己的前沿规模模型，有两件事比以往任何时候都更重要：获取训练算力，以及优化在训练机器之间传输数据的管道。RL 对这些管道的要求尤为严苛。一个前沿模型可能拥有数万亿参数，而训练器需要随着训练的推进，持续将更新版本的模型推送到生成 rollout 的机器集群。

当这些管道跟不上时，团队就被迫走向单一选择：一个巨型同地集群，所有设备都在同一物理场地上互联。这既昂贵又难以获得，还将较小的参与者拒之门外。在 Fireworks，我们穷尽一切可行路径，以避免这成为唯一选项。否则，我们最终会得到一个只有少数几家公司才能进入的训练市场。

在此前的文章《前沿 RL 比你想象的更便宜》中，我们详细介绍了如何在实践中实现跨区域 RL。核心观察是，在我们考察的 RL 工作负载中，连续检查点之间只有约 2% 的模型 BF16 权重发生变化。因此，我们不必在训练器每次执行一步时都将完整的 1 TB 检查点发送到每台 rollout 机器，而是发送一个紧凑的 delta——对变化内容的压缩描述——并在另一端重建更新后的模型。正是这一点让训练运行能够在三四个区域之间保持同步，而无需在集群之间建立专用的高带宽网络。

该 delta 的大小有助于决定这在实践中能发挥多大作用。更小的 delta 有助于 rollout 集群更快更新、更贴近当前策略，并从各区域的可用算力中获取资源。更大的 delta 则可能意味着训练器开始跑在 rollout 前面，集群逐渐过时，多区域部署开始失去相对于单一超大集群的优势。

ARCv3 delta 如何从训练器传输到 rollout。每个训练器分片并行地将其那部分压缩权重 delta 上传到共享对象存储（S3）。随后，Fireworks API 向每个区域发出新更新可用的信号，每个 rollout 区域拉取所需的分片并在本地重建更新后的模型。训练器从不直接与 rollout 集群通信，这正是让全球分布式推理集群能够通过普通网络链路保持同步的原因。

我们发布 ARCv3，这是我们用于构建这些 delta 的压缩器的最新版本。这些改进适用于 BF16 权重，ARCv3 生成的负载大小接近上一版本的一半，平均 delta 负载约为原始 BF16 权重大小的 0.19%，低于此前的 0.36%（越低越好）。压缩是无损的：rollout 侧重建的模型与训练器生成的模型逐位完全一致。ARCv3 已通过 fireworks-delta-compression 在 Fireworks Training API 中提供，面向使用自有训练器搭配 Fireworks rollout 的团队。

深入 ARCv3：并非所有更新都生而平等

这一改进源于 BF16 权重在训练步骤之间变化方式的一个特定属性。

当我们运行生产 RL 训练会话并观察检查点之间实际发生的情况时，我们观察到一种强烈的不对称性。在给定步骤中发生变化的约 2% 的 BF16 权重里，绝大多数只发生了尾数变化，而指数和符号保持不变。触及指数的更新很少见，而翻转符号的更新则更为罕见。换言之，大多数权重更新是微调，而非跳跃。

ARCv3 直接编码了这种不对称性。未变化的权重值从负载中省略。仅尾数变化的更新只贡献其尾数位。更罕见的更新——指数发生偏移或符号翻转——则单独打包，每次更新的变化字段作为一个块一起编码。在 rollout 侧，两个流都被应用到先前的检查点上，并将结果与训练器的原始版本进行校验和比对，以验证重建结果一致。

ARCv3 如何编码一个权重块。每个前/后配对进行 XOR 运算，并根据实际发生变化的字段进行分类。未变化的权重值（零 XOR）从输出中省略。仅尾数变化——最常见的情况——只贡献其尾数位（高亮显示）。更罕见的更新——指数发生偏移或符号翻转——则打包在一起，将变化的字段编码为一个块。输出流的形态由变化内容决定，而非输入格式的固定宽度。

对于模型中的每个张量，ARCv3 还会并行运行多种通用压缩算法，并保留产生最小输出的那一种。这比预先选定单一算法消耗更多 CPU，但训练器机器在 GPU 执行实际训练时通常有闲置的 CPU 周期，因此值得花费这些周期。

ARCv3 与同类方案的对比

我们在从生产 RL 工作负载中抽取的 1,000 个真实权重更新 delta 上，将 ARCv3 与三种替代方案进行了基准测试。所有更新均为 BF16，且四种压缩器均无损运行，因此我们比较的是纯负载大小：每种压缩器描述完全相同的权重更新需要多少字节。

ARCv3 的替代方案包括：

ARCv2，我们自家压缩器的上一版本。

PULSESync，来自《Understanding and Exploiting Weight Update Sparsity for Communication-Efficient Distributed RL》（Miahi & Belilovsky, 2026）的权重同步算法。PULSESync 同样利用 BF16 权重更新中的稀疏性，采用稀疏补丁设计。

Hugging Face TRL 中的 delta 压缩实现。

压缩器压缩后/原始 BF16 权重比率ARCv30.19%PULSESync0.35%ARCv20.36%HF TRL（草稿）0.67%

此处越低越好，ARCv3 在本基准测试中产生的负载最小。在测试的 BF16 权重张量上，ARCv3 将压缩后的 delta 缩小到次优方案约一半的大小。每个 rollout 区域拉取所需的 delta 片段，并重建训练器精确的 BF16 权重。这有助于让全球分布式 rollout 集群更贴近当前策略，这正是跨区域 RL 能够大规模运作的关键。

使用 ARCv3

如果你使用 Fireworks Trainer SDK 进行 rollout，则无需任何操作，因为 ARCv3 已是默认选项。你的 rollout 集群将以更小的传输量运行，而你无需更改任何代码。

如果你自带训练器并使用 Fireworks 进行 rollout，可以通过 fireworks-delta-compression 包直接集成 ARCv3。完整的集成流程请参阅 Fireworks rollout 文档。bashCopy

1pip install fireworks-delta-compressionpythonCopy

123456789101112131415161718192021import torchfrom fireworks_delta_compression import delta_compress, delta_decompress src = torch.randn(1024, 1024, dtype=torch.bfloat16)dst = src + 1e-3 * torch.randn_like(src) compressed_diff, checksum = delta_compress( src=src, dst=dst, compression_format="arc_v3",) restored = delta_decompress( src=src, compressed_diff=compressed_diff, checksum=checksum, compression_format="arc_v3",) # bit-for-bit identical to the originalassert torch.equal(restored.view(torch.uint8), dst.view(torch.uint8))

让分布式计算服务于 RL

RL 权重更新具有结构，压缩器可以利用这一点。将罕见的指数变化与常见的尾数更新分离，并在其上并行运行几种通用编解码器，使我们以在已有闲置资源的机器上消耗额外 CPU 的较低代价，获得了接近自家上一版本两倍的压缩率。

我们之所以推进这一点，是因为从 delta 中削减的每一个字节，都是在训练步骤中无需跨洲传输的字节。这让我们更接近让跨三四个区域集群的训练感觉像是在同一栋楼里训练。它帮助更多团队凭想法竞争，而不是凭他们能购买多少同地算力来竞争。

对于构建专用模型的团队而言，回报在于扩展 RL 时拥有更大的灵活性。Fireworks 负责跨 rollout 区域的权重分发与同步。

ARCv3 是我们目前的成果。我们将继续推进。

将你的训练器带到 Fireworks。