专门化一个前沿模型意味着将其行为适配到特定领域的任务、工具和成功标准。强化学习（RL）通过一个重复循环来实现这一点：模型生成轨迹——即动作和观察的序列——评估器分配奖励，训练器更新策略，使成功行为更有可能出现。
在 Kimi K3 的规模下，实用的 RL 需要在整个训练循环中实现高效执行。轨迹生成和训练必须保持高吞吐量，更新后的策略必须能快速可用，并且必须保持训练与推理之间的数值对齐。为了便于实验，系统还必须支持独立运行，而无需为每个实验配备专用基础设施。
本报告描述了 Fireworks 上支持 Kimi K3 RL 的系统，涵盖全参数训练与轨迹生成、训练-推理一致性，以及无服务器 LoRA 训练。我们考察这些组件如何降低迭代开销，并帮助团队更高效地开发和评估专门化策略。
同一套基础设施也为 Harvey Tenet 的 RL 训练提供支持，这是 Harvey 基于 Kimi K3 的模型，用于长周期法律工作。在Harvey 2026 年 8 月的评估中，Tenet 取得了LAB Contracts 上的 SOTA，并在 Legal Agent Benchmark（LAB）上排名第二，在两项上均优于 Fable 5：
- LAB：19.7% all-pass，对比 Fable 5 的 11.5%——相比基础 K3提升了 1.8×（10.8%）。
- LAB Contracts：11.3% all-pass，对比 Fable 5 的 9.0%。
Kimi K3是一个2.8T 参数模型，具有 1M token 的上下文窗口。在这一规模下，模型状态和长序列激活对内存容量造成压力，而其混合架构引入了独特的计算和通信瓶颈。
Fireworks 通过专门的混合专家（MoE）、Kimi Delta Attention（KDA）和 Attention Residual 内核来解决这些瓶颈，并以长序列分布式训练作为支撑。
K3 的LatentMoE将 FP4 专家分布到多个 GPU 上，需要在专家计算前后进行 all-to-all 分发和合并。DeepEP加速了这些传输，但暴露的通信仍可能使张量核心空闲。类似的通信-计算重叠已发表在Mixture-of-Kittens、COMET以及FlashMoE。
我们的自研MoE Mega Kernel将这些通信-计算重叠技术适配到 K3 的路由专家前向与反向传播中：
- 环形缓冲区限制 dispatch 暂存。随着工作推进复用 token 缓冲区槽位，限制 dispatch 工作区。
- 微批处理实现持续流水线。跨微批重叠 dispatch、专家计算和结果返回；反向传播同样将梯度通信与计算重叠。
- 将量化融合进暂存。将 FP8 激活值和缩放因子直接写入通信缓冲区，消除中间拷贝，同时保持 K3 的量化约定。
与优化后的原生 DeepEPv2基线相比，它带来1.87-2.61× 前向和1.31-2.13× 反向加速覆盖每 rank 1K-128K token。对比中包含 Normal EP，以展示在已优化的通信后端之上获得的额外收益。
Kimi Delta Attention (KDA)是一种线性注意力机制，使用逐通道门控来更新紧凑的循环状态，从而随序列长度实现线性计算扩展，并保持固定大小的解码状态。高效训练必须并行化块内局部工作，同时限制循环依赖和中间数据移动带来的停顿。
我们构建了自研 KDA kernel针对 Blackwell 优化，融合相关工作并减少中间内存流量。与FLA 的 KDA 实现相比，它带来1.49-1.58× 前向和1.49-1.51× 反向加速覆盖序列长度4K-128K token。
Attention Residuals跨模型深度组合表示。在长序列长度下，用于归一化、加权和梯度计算的中间张量可能消耗大量内存和带宽，降低可用于训练的容量。
我们的内核融合了归一化和加权求和操作，以减少前向和反向传播过程中的中间张量物化和数据移动。
与K3 布局中的 FLA相比，该实现带来了1.75-2.50 倍的前向加反向综合加速覆盖1K-256K 本地 token。在 128K 时，实测峰值分配内存从63.02 GiB 降至 35.03 GiB——降低了 44%，为周围的训练工作负载留出更多可用内存。
在2.8T 参数规模下，全参数训练需要在 GPU 之间分片权重、梯度和优化器状态。接近1M token的序列会加剧激活内存压力，并在 MLA 层中带来二次方注意力计算。我们结合三种并行策略来同时应对模型规模和序列长度：
- 全分片数据并行（FSDP）。分片参数、梯度和优化器状态。预取将即将进行的权重 all-gather 和梯度 reduce-scatter 与当前层的计算重叠。
- 上下文并行（CP）。在 GPU 之间划分长序列，为 KDA 的循环状态传播保留连续的 token 范围，同时平衡 MLA 的因果注意力工作负载。
- 专家并行（EP）。将路由专家分布到 GPU 上，并将 EP 与 FSDP 结合以控制专家权重的工作集。我们的MoE Mega Kernel在保持专家 GEMM 高效的同时，将 token 分发和合并与计算流水线化，减少暴露的 all-to-all 延迟。
我们的Kernel Bricks库提供拓扑感知和负载感知的集合通信实现，可降低各种训练配置下的通信延迟。例如，AllReduce 相比 PyTorch Distributed 实现了1.67-3.31×的加速。
Fireworks 支持用于全参数强化学习的 Kimi K3 rollout 推理。该工作负载不同于普通的聊天服务：数千条轨迹反复从共享提示中分支，在生成和工具使用之间交替，并增长为长的多轮历史。rollout 引擎必须保持这些历史可复用，并高效执行 2.8 万亿参数的混合 MoE 模型。
本节介绍在 GB300 系统上实现这一点的 rollout 侧技术。
AKV 缓存存储继续生成所需的注意力状态，而无需重新计算完整提示词。K3将保留逐 token KV 历史的 MLA 与以紧凑循环状态汇总先前 token 的 KDA 相结合。复用对话前缀需要两种历史都表示对话中的同一位置——尤其是当 RL 轨迹从共享提示词分叉或在工具调用后恢复时。
Fireworks 协调 MLA 和 KDA 历史，使两种缓存状态始终表示同一前缀。随着对话增长和更多轨迹并发运行，这保留了可复用的工作，减少重复 prefill，同时每个分支保持独立且一致的状态。
在我们的长上下文、多轮 rollout 基准测试中，Fireworks 实现了约99% 的缓存命中率，使得几乎所有提示词 token 都能从缓存中复用。
投机解码使用较小的草稿模型提出 token，并由目标模型并行验证。Fireworks 为 Kimi K3 训练了一个推测器；在两个引擎均使用草稿长度 3 的情况下，我们的回放基准测试显示，每次验证步骤的 token 数比 SGLang DSpark 基线最多多 12%。
K3 的循环 KDA 状态在被拒绝的 token 之后必须保持一致。我们集成了ReplaySSM，从已提交的检查点回放已接受 token 的紧凑状态更新输入，避免为每个候选做完整状态快照。
我们评估了跨八种任务类型的 322 个回放请求，使用每个引擎 16 块 GB300 GPU和 SGLang v0.5.18。接受长度统计每次验证步骤推进的 token 数，包括已验证的目标 token（最大4，草稿长度为 3）；结果按验证步骤加权。
- 跨任务来看：通用聊天达到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 tokens（190 次请求），达到3.37 对 3.31（+2%）；60K+达到3.43 对 3.27（+5%）。请求数少于 30 的桶，其报告准确率约为 ±0.3 tokens。
张量并行推理需要 GPU 合并部分结果后才能继续计算。这些反复的同步可能限制 K3 的生成速度，尤其是在较小的解码批大小下。
Fireworks 的 AllReduce 库使用拓扑感知和负载感知的实现，以减少暂存和通信延迟。这让依赖计算能更早开始，并缩短通信关键路径。
这里描述的配置使用内联预填充：预填充和解码共享同一个 GPU 副本。这适合长时间运行的多轮 rollout，因为后续轮次可以复用保留的历史，只预填充其新增后缀。内联服务还避免了将 MLA KV 和匹配的 KDA 循环状态交给单独的解码池。
分离式服务将解码与预填充隔离，并允许每个池选择自己的拓扑和容量。当未缓存的预填充量或严格的 token 延迟足以证明这种分离合理时，它很有吸引力。然而对于 K3，每次交接都必须传输一致的 MLA KV 加上 KDA 循环和卷积状态，在目标缓存中找到空间，并保留活动的 RL 策略版本。
内联服务有其自身成本：预填充会与活跃解码争抢 GPU 时间。正确的选择取决于提示量、生成长度、前缀复用、传输带宽和延迟目标。比较两者需要相同的工作负载和总 GPU 预算；这里描述的被测系统使用内联服务。
下面的基准测试使用混合 TP4 / DP4 / EP16 布局：张量并行保持在快速的节点内互连结构内，四个注意力组独立处理请求，专家并行跨越 16-GPU 组。这是一种测量配置，不是通用的生产部署配方。
这带来了调度问题。如果一个注意力组开始 prefill，共享专家组中的每个 GPU 都必须参与，即使其他组没有准备好有用的 prefill 工作。不均匀的 RL 轨迹因此可能把许多小的 prefill 变成重复的填充工作和解码中断。
Fireworks 的 DP prefill 配对让同级组有一个短暂窗口来对齐有用的 prefill 工作，同时活跃请求继续解码。待处理的 prefill 会在所有组就绪或超时到期后运行，用有界的等待换取更大的批次和更少的填充。这遵循了同样公开发表的有界延迟方法，见AMD 的 ATOM。
在一个合成的长上下文、多轮 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，同时保持模型所要求的状态正确性。
同步 K3 的2.8T 参数使得全量检查点传输变得昂贵。我们将每次更新编码为逐字节的XOR 增量，Δ = W_new XOR W_base，并用 Zstandard 压缩。未变化的字节变为零，从而减小压缩后的负载。Rollout worker 解压增量并应用W_base XOR Δ以重建新的检查点，逐位一致。
在Fireworks 公布的工作负载中，一个1,024 GiB的检查点产生了平均 20.3 GiB 的增量——每次增量更新的字节数减少了 98%。计入周期性的全量检查点后，总传输量在 50 步内下降了94%。
训练与 rollout 之间的数值漂移即使在两个系统使用相同权重时也可能扭曲 RL 的重要性比率。这与策略陈旧性不同：策略陈旧性是指在学习器更新权重后，rollout 数据来自较旧的策略。如果未被测量和控制，这两种效应都可能使策略更新不稳定。我们在 K3 的前向传播中强制执行确定性执行，包括主要内核和归约操作，从而使固定的权重、输入和执行配置产生一致的输出。
关键内核，包括
RMSNorm，也支持批次不变执行。对于 RMSNorm，固定的归约顺序可在不同批次大小下保持一致的结果，同时保留 K3 的舍入边界可减少训练-推理漂移。即使权重相同，微小的数值差异也可能改变 top-k 专家选择，导致训练和 rollout 的对数概率出现分歧。
Fireworks RL 平台支持Router Replay (R3)：学习器复用 rollout 的专家选择，同时用当前参数重新计算门控权重和专家输出。借助这些数值对齐措施，同步
LoRA的训练-rollout 分歧在此配置下低至0.0008。我们使用按 token 平均的Schulman k3 估计器报告估计的 KL 散度；结果取决于序列长度和执行配置。Harvey 使用 Fireworks RL 平台将 Kimi K3 后训练为
Tenet，在 LAB Contracts 上取得了最先进性能，并在 LAB 上获得第二名，在其2026 年 8 月评估中。在 LAB 上，Tenet 完成的留出任务数是基础 K3 的1.8 倍（来源）。这些提升也泛化到了 Apex Agents（公司法）和 Redline Bench。配方：
GSPO+ 离策略 RL。+ off-policy RL.智能体在沙箱中读取案件文件、使用工具并撰写法律交付物。基于评分标准的奖励对实质性工作进行评分，并奖励完整的解决方案。我们在 K3 上使用 GSPO 优化 rank-64 LoRA 适配器，采用序列平均重要性权重、双侧裁剪和高重要性比率 token 掩码。
新的奖励函数、不同的数据集、更好的学习率：强化学习的进步来自尝试想法并衡量哪些有效。Fireworks 无服务器训练让这些实验在 Kimi K3 上变得可行，通过 Python API 提供共享的训练和 rollout 容量。
你的实验连接到一个已在运行的训练器和 rollout worker 池。无需为每次运行配置专用 GPU 分配、启动训练器任务或搭建单独的 rollout 部署。使用现有池将基础设施配置从实验设置中移除，缩短了从想法到训练循环的路径。
一个多 LoRA训练器和推理引擎让不同的运行和策略快照共享相同的基础权重。在推理时，适配器异步加载，并且多 LoRA 内核减少重复的准备和数据移动。在训练时，调度器对兼容的请求进行批处理，并在适配器局部性与公平性之间取得平衡。优化器状态在会话被调度时被卸载并异步暂存，为更长的上下文和更多活跃适配器保留 GPU 内存。
Rollout 生成通常占据 RL 迭代时间的大部分。高吞吐量既需要适配器并发，也需要足够的缓存容量来容纳长且分支的历史。Fireworks 使用分层适配器和缓存管理：可复用的 KV 和 KDA 状态可以移至主机内存，活跃适配器占用 GPU 槽位，非活跃快照异步加载。缓存复用始终限定在正确的适配器和策略版本范围内，因此就绪的 rollout 可以继续推进，而不会在实验之间混用状态。
在一项关于多轮的无服务器 Kimi K3 实验中VisualToolBench使用图像工具的任务，评估奖励从0.314 提升到 0.451在20 次训练更新之后，在固定的 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 deltas、Fireworks 的 MoE 数值和Router Replay。
- LLM 强化学习与优化：一项从奖励中学习综述、InstructGPT、DeepSeek-R1、PPO、GSPO以及Schulman k3 KL 估计器。
- 无服务器多LoRA系统：LoRA、Punica、S-LoRA、mLoRA和tLoRA。
- 评估来源：VisualToolBench和已发布的客户案例研究。