Fireworks 发布 Kimi K3 大规模强化学习技术报告

TL;DR

Fireworks 通过协同优化训练、rollout 生成和策略更新，让强化学习在 Kimi K3 的 2.8T 参数规模上变得切实可行，从而实现更快、更稳定的训练。

在本报告中，我们详细介绍了自定义内核、长上下文缓存和压缩权重传输，这些技术降低了迭代开销；此外还介绍了数值对齐和 router replay，以保持训练稳定。

这套基础设施支撑了 Harvey Tenet，其在 2026 年 8 月的评测中，在 Legal Agent Benchmark 上的全通过率达到 base K3 的 1.8 倍，并在 LAB Contracts 上取得最先进的结果。

Fireworks 无服务器训练让团队可以通过 Fireworks Training API 在 Kimi K3 上测试自己的任务和奖励函数，共享训练与 rollout 容量，无需配置专用 GPU。

对前沿模型进行专门化，意味着将其行为适配到特定领域的任务、工具和成功标准。强化学习（RL）通过一个重复循环来实现这一点：模型生成轨迹——即动作和观察的序列——评估器分配奖励，训练器更新策略，使成功行为更有可能出现。

在 Kimi K3 的规模下，实用的 RL 需要在整个训练循环中实现高效执行。Rollout 生成和训练必须保持高吞吐量，更新后的策略必须快速可用，并且必须维持训练与推理之间的数值对齐。为了便于实验，系统还必须支持独立运行，而无需为每个实验配置专用基础设施。

本报告介绍了 Fireworks 在 Kimi K3 上支持 RL 的系统，涵盖全参数训练与 rollout 生成、训练-推理一致性以及无服务器 LoRA 训练。我们考察了这些组件如何降低迭代开销，并帮助团队更高效地开发和评估专门化策略。

同一套基础设施也为 Harvey Tenet 的 RL 训练提供支持，Tenet 是 Harvey 基于 Kimi K3 构建的模型，面向长周期法律工作。在 Harvey 2026 年 8 月的评测中，Tenet 在 LAB Contracts 上取得 SOTA，在 Legal Agent Benchmark（LAB）上排名第二，两项均优于 Fable 5：

LAB：全通过率 19.7%，而 Fable 5 为 11.5%——相比 base K3（10.8%）提升 1.8 倍。

LAB Contracts：全通过率 11.3%，而 Fable 5 为 9.0%。

训练

Kimi K3 是一个拥有 2.8T 参数、上下文窗口为 1M token 的模型。在这一规模下，模型状态和长序列激活对内存容量构成压力，而其混合架构带来了独特的计算和通信瓶颈。

组件Kimi K3注意力69 层 Kimi Delta Attention（KDA）+ 24 层 Multi-head Latent Attention（MLA）Latent MoE896 个专家；top-16；潜在维度 3,584专家激活SiTU路由专家量化Group-32 MXFP4 权重；group-128 FP8 激活Attention Residuals对层输出进行分块注意力

Fireworks 通过专门的混合专家（MoE）、Kimi Delta Attention（KDA）和 Attention Residual 内核来应对这些瓶颈，并以长序列分布式训练为支撑。

MoE Mega Kernel

K3 的 LatentMoE 将 FP4 专家分布到各 GPU 上，需要在专家计算前后进行 all-to-all 分发与合并。DeepEP 加速了这些传输，但暴露的通信仍可能让张量核心空闲。Mixture-of-Kittens、COMET 和 FlashMoE 中也发表过类似的通信-计算重叠方案。

我们的自研 MoE Mega Kernel 将这些通信-计算重叠技术适配到 K3 的路由专家前向与反向传播中：

环形缓冲区限制分发暂存。随着工作推进复用 token 缓冲区槽位，限制分发工作区。

微批处理实现连续流水线。跨微批重叠分发、专家计算和结果返回；反向传播同样将梯度通信与计算重叠。

将量化融合进暂存。将 FP8 激活和缩放直接写入通信缓冲区，消除中间拷贝，同时保持 K3 的量化约定。

前向与反向调度示意图；底部条带显示实测的 16K token/rank 耗时。收益包括减少暂存和数据移动，以及重叠。

与经过优化的原生 DeepEPv2 基线相比，在每 rank 1K-128K token 范围内，它带来 1.87-2.61 倍前向和 1.31-2.13 倍反向加速。对比中包含 Normal EP，以展示在已优化通信后端之外的额外收益。

8× B300，EP=8；优化后的 DeepEPv2 = 1×。路由专家前向/反向分别测量，包含通信；并非全模型吞吐。

KDA：从循环记忆到高效 GPU 执行

Kimi Delta Attention（KDA）是一种线性注意力机制，使用逐通道门控来更新紧凑的循环状态，从而实现随序列长度线性扩展的计算量和固定大小的解码状态。高效训练必须并行化块内局部工作，同时限制循环依赖和中间数据移动造成的停顿。

我们构建了针对 Blackwell 优化的自研 KDA 内核，融合相关工作并减少中间内存流量。与 FLA 的 KDA 实现相比，在 4K-128K token 的序列长度范围内，它带来 1.49-1.58 倍前向和 1.49-1.51 倍反向加速。

B300，无 CP；FLA Triton = 1×。仅 KDA 核心，包含 Q/K 归一化和门控扫描。

Attention Residuals：更低内存，更快训练

Attention Residuals 跨模型深度组合表示。在长序列长度下，用于归一化、加权和梯度计算的中间张量可能消耗大量内存和带宽，减少可用于训练的容量。

我们的内核融合归一化和加权求和操作，以减少前向和反向传播期间的中间张量物化和数据移动。

在 K3 的布局下与 FLA 相比，该实现在 1K-256K 本地 token 范围内带来 1.75-2.50 倍的前向加反向综合加速。在 128K 时，实测峰值分配内存从 63.02 GiB 降至 35.03 GiB——降低 44%，为周边训练工作负载留出更多可用内存。

共享 B300，BF16；算子前向 + 反向，FLA = 1×。由于 GPU 共享下出现 OOM，省略了 64K 以上的 PyTorch 结果。

分布式训练

在2.8T参数规模下，全参数训练需要在GPU之间对权重、梯度和优化器状态进行分片。接近100万token的序列会带来激活内存压力，以及MLA层中二次方复杂度的注意力计算。我们结合三种并行策略来同时应对模型规模和序列长度：

完全分片数据并行（FSDP）。对参数、梯度和优化器状态进行分片。预取将即将进行的权重all-gather和梯度reduce-scatter与当前层的计算重叠。

上下文并行（CP）。将长序列划分到多个GPU上，在平衡MLA因果注意力工作负载的同时，为KDA的循环状态传播保留连续的token范围。

专家并行（EP）。将路由专家分布到多个GPU上，并将EP与FSDP结合以控制专家权重的工作集。我们的MoE Mega Kernel在保持专家GEMM高效的同时，将token分发与合并同计算流水化，减少暴露的all-to-all延迟。

我们的Kernel Bricks库提供拓扑感知和负载感知的集合通信实现，可降低各种训练配置下的通信延迟。例如，AllReduce相比PyTorch Distributed实现1.67-3.31倍的加速。

Rollout

Fireworks支持Kimi K3的rollout推理，用于全参数强化学习。该工作负载不同于普通的聊天服务：数千条轨迹反复从共享提示中分支，在生成和工具使用之间交替，并增长为长的多轮历史。rollout引擎必须保持这些历史可复用，并高效执行2.8万亿参数的混合MoE模型。

本节介绍在GB300系统上实现这一目标的rollout侧技术。

一个模型，两种缓存状态

KV缓存存储继续生成所需的注意力状态，无需重新计算完整提示。K3将保留逐token KV历史的MLA与以紧凑循环状态汇总先前token的KDA相结合。复用对话前缀需要两种历史都表示对话中的同一位置——尤其是当RL轨迹从共享提示分支或在工具调用后恢复时。

Fireworks协调MLA和KDA历史，使两种缓存状态始终表示相同的前缀。随着对话增长和更多轨迹并发运行，这保留了可复用的工作，减少了重复prefill，同时每个分支保持独立且一致的状态。

MLA KV历史和KDA状态一起复用，而每条轨迹独立继续。

在我们的长上下文、多轮rollout基准测试中，Fireworks实现了约99%的缓存命中率，使几乎所有提示token都能从缓存中复用。

不破坏循环状态的推测解码

推测解码使用较小的草稿模型提出token，并由目标模型并行验证。Fireworks为Kimi K3训练了一个推测器；在两个引擎均使用草稿长度3的情况下，我们的重放基准显示，每次验证步骤的token数比SGLang DSpark基线最多多12%。

K3的循环KDA状态在被拒绝的token之后必须保持一致。我们集成ReplaySSM，从已提交的检查点重放被接受token的紧凑状态更新输入，避免为每个候选做完整状态快照。

ReplaySSM仅通过被接受的前缀推进KDA状态。

我们在八种任务类型上评估了322个重放请求，每个引擎配备16块GB300 GPU，使用SGLang v0.5.18。接受长度统计每个验证步骤推进的token数，包括已验证的目标token（草稿长度为3时最多为4）；结果按验证步骤加权。

跨任务来看：通用聊天达到2.80对2.51个token（+12%），竞赛编程为3.09对2.92（+6%），仓库问题修复为3.47对3.29（+5%）。其他智能体任务提升1-3%，基于技能的智能体基本持平（3.24对3.25）。

跨上下文长度来看：提升幅度在2-9%之间。最大的区间为10-20K token（190个请求），达到3.37对3.31（+2%）；60K+达到3.43对3.27（+5%）。请求数少于30的区间，其报告的准确度约为±0.3个token。

热缓存重放，关闭思考，温度0，最大输出512；更新于2026年9月29日。上下文区间汇总了不同的请求；接受长度的提升并非端到端吞吐量的提升。

缩短通信关键路径

张量并行推理要求GPU在计算继续之前合并部分结果。这些反复的同步可能限制K3的生成速度，尤其是在较小的解码批大小下。

Fireworks的AllReduce库使用拓扑感知和负载感知的实现来减少暂存和通信延迟。这使得依赖计算能够更早开始，并缩短通信关键路径。

Fireworks的AllReduce库根据负载大小和硬件拓扑选择集合通信路径。

选择内联或分离式rollout服务

此处描述的配置使用内联prefill：prefill和解码共享同一个GPU副本。这适合长时间运行的多轮rollout，因为后续轮次可以复用保留的历史，只对其新增后缀执行prefill。内联服务还避免了将MLA KV和匹配的KDA循环状态交给单独的decode池。

分离式服务将解码与prefill隔离，并允许每个池选择自己的拓扑和容量。当未缓存的prefill量或严格的token延迟足以证明这种分离合理时，它具有吸引力。然而对于K3，每次交接都必须传输一致的MLA KV以及KDA循环状态和卷积状态，在目标缓存中找到空间，并保留活跃的RL策略版本。

内联服务有其自身成本：prefill与活跃解码竞争GPU时间。正确的选择取决于提示量、生成长度、前缀复用、传输带宽和延迟目标。比较两者需要相同的工作负载和总GPU预算；此处描述的被测系统使用内联服务。

在广泛的专家组之间协调prefill

下面的基准测试使用混合TP4 / DP4 / EP16布局：张量并行保持在快速的节点内互连结构内，四个注意力组独立处理请求，专家并行跨越16-GPU组。这是一个测量配置，而非通用的生产部署配方。

这就带来了调度问题。如果一个注意力组开始prefill，共享专家组中的每个GPU都必须参与，即使其他组没有准备好有用的prefill工作。不均衡的RL轨迹因此可能把许多小的prefill变成重复的填充工作和解码中断。

Fireworks的DP prefill配对为同级组提供一个短窗口，以便在活跃请求继续解码的同时对齐有用的prefill工作。待处理的prefill会在所有组就绪或超时到期后运行，以有界等待换取更大的批次和更少的填充。这遵循了AMD的ATOM中发布的相同总体有界延迟方法。

共享一个专家组的注意力组协调prefill准入；当到达仍然不对称时，超时保证进展。

随着历史增长而提升的吞吐量

在一个合成的长上下文、多轮rollout工作负载上，16块GB300 GPU（TP4 / DP4 / EP16）在50轮中服务了128条并发轨迹，在整个计时运行期间平均达到2,834个输出token/s，包括爬升和排空阶段。

每个点显示一分钟全并发窗口内的总输出吞吐量，并对照该窗口中的平均提示长度绘制。

单独的消融实验测得，使用EAGLE3时完整运行吞吐量提高49.37%，使用ReplaySSM时提高65.05%。ReplaySSM的收益包括GPU缓存容量增加。

综合来看

在合成的长上下文、多轮rollout工作负载上，16块GB300 GPU（TP4 / DP4 / EP16）在50轮中服务了128条并发轨迹，在整个计时运行期间平均达到2,834个输出token/s，包括爬升和排空阶段。

每个点显示一分钟全并发窗口内的总输出吞吐量，并对照该窗口中的平均提示长度绘制。

单独的消融实验测得，使用EAGLE3时完整运行吞吐量提高49.37%，使用ReplaySSM时提高65.05%。ReplaySSM的收益包括GPU缓存容量增加。

综合来看

K3 rollout 的性能源于将模型视为一个完整系统。协同的 MLA 与 KDA 缓存保留了可复用的对话历史。ReplaySSM 使推测解码对循环状态安全。Fireworks 的 AllReduce 库缩短了集合通信。内联服务与 DP prefill 配对将异步 RL 轨迹转化为高效的 GPU 工作。

这些技术共同使 Fireworks 能够以高吞吐量维持长时间、分支化、多轮的 K3 rollout，同时保持模型所需的状态正确性。

RL：快速迭代，稳定训练

使用 XOR 增量进行权重同步

同步 K3 的 2.8T 参数使得全量 checkpoint 传输代价高昂。我们将每次更新编码为逐字节 XOR 增量，Δ = W_new XOR W_base，并用 Zstandard 压缩。未变化的字节变为零，从而减小压缩后的负载。Rollout worker 解压增量并应用 W_base XOR Δ，逐位重建新的 checkpoint。

在 Fireworks 公布的工作负载中，一个 1,024 GiB 的 checkpoint 平均产生 20.3 GiB 的增量——每次增量更新的字节数减少了 98%。计入周期性全量 checkpoint 后，50 步内总传输量下降了 94%。

RL 稳定性与数值

确定性

训练与rollout之间的数值漂移，即使两个系统使用完全相同的权重，也可能扭曲RL重要性比率。这与策略陈旧不同：策略陈旧是指学习器更新权重后，rollout数据来自较旧的策略。这两种效应如果未被测量和控制，都可能使策略更新不稳定。

我们在K3的前向传播中强制执行确定性执行，包括主要内核和归约操作，因此固定的权重、输入和执行配置会产生一致的输出。

包括RMSNorm在内的关键内核也支持批次不变执行。对于RMSNorm，固定的归约顺序可在不同批次大小下保持一致的结果，同时保留K3的舍入边界可减少训练-推理漂移。

路由重放（R3）

即使权重完全相同，微小的数值差异也可能改变 top-k 专家选择，导致训练与 rollout 的对数概率出现分歧。Fireworks RL 平台支持路由重放（R3）：学习器复用 rollout 的专家选择，同时基于当前参数重新计算门控权重与专家输出。

借助这些数值对齐措施，在此配置下，同步 LoRA 训练-rollout 分歧低至 0.0008。我们使用按 token 平均的 Schulman k3 估计器报告估计的 KL 散度；结果取决于序列长度与执行配置。

Harvey Tenet：在 Fireworks 上训练最先进的法律模型

Harvey 使用 Fireworks RL 平台将 Kimi K3 后训练为 Tenet，在 2026 年 8 月的评测中于 LAB Contracts 上取得最先进性能，并在 LAB 上位列第二。在 LAB 上，Tenet 完成的留出任务数量是基础版 K3 的 1.8 倍（来源）。这些提升也泛化到了 Apex Agents（公司法）和 Redline Bench。

配方：GSPO + 离策略 RL。智能体在沙箱中读取案件文件、使用工具并撰写法律交付物。基于评分标准的奖励对实质性工作进行评分，并奖励完整解决方案。我们使用 GSPO 在 K3 上优化 rank-64 LoRA 适配器，采用序列平均重要性权重、双侧裁剪和高重要性比率 token 掩码。

Harvey 离策略 RL：奖励和全通过率上升，而估计的 KL 散度（Schulman k3）保持在接近 0.0053 的水平，包括策略滞后。同一次运行；奖励/全通过率使用 EMA 0.99，KLD 未平滑。

新的奖励函数、不同的数据集、更好的学习率：强化学习的进步来自尝试想法并衡量哪些有效。Fireworks 无服务器训练让这些实验在 Kimi K3 上变得可行，通过 Python API 提供共享的训练和 rollout 容量。

你的实验连接到一个已在运行的训练器和 rollout 工作器池。无需为每次运行配置专用 GPU 分配、启动训练器作业或搭建单独的 rollout 部署。使用现有池将基础设施配置从实验设置中移除，缩短了从想法到训练循环的路径。

多 LoRA 训练器和推理引擎让不同的运行和策略快照共享同一套基础权重。在推理时，适配器异步加载，多 LoRA 内核减少重复的准备和数据移动。在训练时，调度器对兼容的请求进行批处理，并在适配器局部性与公平性之间取得平衡。优化器状态被卸载，并随着会话的调度异步分阶段加载，从而为更长的上下文和更多活跃适配器保留 GPU 内存。

Rollout 生成通常占据 RL 迭代的大部分时间。高吞吐量既需要适配器并发，也需要足够的缓存容量来应对长且分支繁多的历史。Fireworks 采用分层适配器与缓存管理：可复用的 KV 和 KDA 状态可移至主机内存，活跃适配器占用 GPU 槽位，非活跃快照异步加载。缓存复用始终限定在正确的适配器和策略版本范围内，因此就绪的 rollout 能持续运行，而不会在不同实验之间混淆状态。

一个真实案例：Visual ToolBench

在一项针对多轮 VisualToolBench 任务（含图像工具）的无服务器 Kimi K3 实验中，经过 20 次训练更新后，评估奖励从 0.314 提升至 0.451，该结果在固定的 50 任务评估集上测得。完整可运行示例见 Fireworks cookbook。

使用 Fireworks 无服务器训练启动 Kimi K3 实验。带上你的任务、环境和奖励函数，使用共享的训练与 rollout 工作流来测试你的下一个想法。

背景与参考资料

术语在首次使用时附有链接。以下来源提供额外背景，但不扩展正文叙述：

Kimi K3 架构、KDA、MLA、Attention Residuals、LatentMoE、SiTU 和量化。

MoE 路由与通信：Switch Transformers、DeepEP、Mixture-of-Kittens、COMET 和 FlashMoE。

分布式训练：FSDP 以及统一的序列/上下文并行。

Rollout 服务：PagedAttention、推测解码、ReplaySSM 和 DistServe。

策略同步与数值对齐：XOR checkpoint 增量、Fireworks 的 MoE 数值和 Router Replay。

LLM 强化学习与优化：一项从奖励中学习的综述、InstructGPT、DeepSeek-R1、PPO、GSPO，以及 Schulman k3 KL 估计器。

无服务器多 LoRA 系统：LoRA、Punica、S-LoRA、mLoRA 和 tLoRA。

评估来源：VisualToolBench 以及已发布的客户案例研究。