Fireworks AI 官宣 Training API 与 Fireworks Lab 全面可用，称同预算下迭代增 2～4 倍

8 月 31 日，Fireworks AI 在宣布 Training API 与 Fireworks Lab 正式全面可用（GA），博客标题是「Train past the frontier」（越过前沿去训练）。Training API 把客户用 Python 编写的自定义训练循环接入 Fireworks 托管的分布式训练与 rollout 基础设施：训练器负责计算梯度并更新模型，rollout 部署负责从当前模型生成样本，两者之间的权重同步、失败切换恢复与训练-采样对齐也由 Fireworks 管理；客户自行编排循环，完全控制损失函数或奖励、数据与环境。

Fireworks 称，团队在相同训练预算下能获得 2～4 倍的迭代次数，模型开发周期从数周压缩到数小时。公告还援引了 Harvey、Vercel、Heidi Health、Factory 与 Figma 五个客户的使用情况。

一条 API、两种容量：Serverless 与 Dedicated

Training API 提供两种算力选项，差异写在同一张对照表里：

Serverless（无服务器）：在共享基础设施上训练 LoRA（低秩适配）适配器，按 token（词元）计费，采样在同一会话内运行。适合快速实验、为更大规模的训练去风险，以及交替进行 rollout 与训练的 RL（强化学习）循环。通过多 LoRA 部署，每个客户或用例都能拥有各自的微调模型，不必单独搭建基础设施。
Dedicated（专用）：支持 LoRA 与全参数训练，模型范围从精选列表扩展到最大的 MoE（混合专家）模型，可容纳更长的上下文或更大的 LoRA rank；按 GPU 小时计费，每次运行弹性分配容量，可调整 GPU 类型与集群大小，也支持把训练器与 rollout 拆分开来加速训练。

训练方法上，托管模式（Managed Training）支持在 UI/API 中选择 SFT（监督微调）、RFT（强化微调）、DPO（直接偏好优化）；Training API 则完全由客户自带循环，博客附了一个可直接写进训练循环的 Python 奖励函数示例——模型输出与 ground truth（标准答案）一致返回 1.0，否则返回 0.0。公告把现有训练工作流的痛点归纳为：模型与方法选择受限、对参数和训练循环控制有限、算力僵化且利用率低，以及训练与 rollout 基础设施割裂带来的成本膨胀、同步开销和数值漂移，Training API 正是针对这些痛点设计。

训练与采样对齐：数值格式、Router Replay 与 10 倍带宽压缩

RL（强化学习）训练把训练与推理变成一套持续耦合的系统：每一步都用当前策略生成 rollout 样本，更新权重，再把新权重送回推理用于下一轮采样。Fireworks 称自己是前沿实验室之外少数在超过 10,000 块 GPU 上运行过 RL 的组织，并把有效 RL 归结为三个要求：正确性、性能效率与开发速度。

正确性方面，rollout 引擎与训练器必须共享相同的数值定义，微小漂移就可能毁掉学习信号。Fireworks 的做法是让两端的数值格式一致（如 BF16、块级 FP8 与 NVFP4），对齐底层 kernel（内核）实现，并用 Router Replay 保持 MoE 的专家选择在 rollout 与反向传播之间一致。公司通过让同一序列分别经过 rollout 引擎与训练器、测量训练-推理 KL 散度（KLD）来验证对齐，所有在 Fireworks 上训练并发布的模型都会持续验证 KLD 最小化。

性能方面，大规模 RL 大部分时间花在生成 rollout 上，完成长度差异大，僵化的批处理会让 GPU 空等少数长轨迹。Fireworks 支持异步 RL，让 rollout 采集与训练重叠进行，算法允许时还可接受有界的权重陈旧度；每步训练完成后，新权重被热加载进正在运行的 rollout 部署，而不是拆掉重建。对全参数检查点，公司计算新旧权重之间的 XOR Diff（异或差分）并用 zstd 压缩，称最多可将传输带宽降低 10 倍。

开发速度方面，平台把迭代变成 train → deploy → evaluate → retrain 的连续循环：检查点直接进入服务，生产流量、评估与反馈再喂给下一轮训练，客户跳过了 GPU 采购、模型适配与容量规划等环节。

从四月预览到全面可用

GA 并非 Fireworks 训练产品的起点。同一博客页面的相关文章列表显示，4 月 6 日公司发布过「Own Your AI: Fireworks Training Preview」训练预览，7 月 15 日宣布完成 Series D 融资、ARR（年度经常性收入）达到 10 亿美元。本次 GA 把训练入口分成三条产品线：Training API 面向 ML（机器学习）研究员，提供最深的控制；Managed Training 面向 ML 工程师，客户自带数据或评估、由 Fireworks 运行循环；Fireworks Lab 面向所有层级，提供嵌入式 ML 研究员与前向部署工程师。

公告把发布背景概括为：下一阶段的竞争优势来自专用智能（specialized intelligence），最有野心的公司正在为编码、芯片设计、网络安全等方向训练支撑差异化产品与运营的模型，而对基础模型做针对性训练，能改善质量、延迟、成本或行为一致性。

客户成绩单：Harvey 的 19.7% 与 Vercel 的 40 倍

博客给出四个带数据的客户案例，全部为 Fireworks 官方发布口径：

Harvey 用异步 RL 对 Kimi K3 做后训练，用于长程法律工作。Tenet 模型在 LAB 基准上 all-pass（整题通过）得分 19.7%，基准 Kimi K3 为 10.8%，单任务成本基本持平。
Vercel 用 RFT 与推测解码（speculative decoding）微调开源模型，用于 v0 的 auto-fixer（自动修复器），达到 93% 的无错误生成率，端到端延迟改善 40 倍。
Heidi Health 把临床笔记服务（clinical scribe）从闭源前沿模型迁移到自己微调的开源模型上，延迟降低 3.5 倍。其 CTO Yu Liu 在博客引语中说：「Fireworks 帮助我们把临床笔记从闭源前沿模型迁移到我们自己微调的开源模型上，从概念验证到生产只用了四周。在同一平台上同时优化微调与服务，让我们这么快就达到了临床质量门槛。」
Factory 在开源 Qwen 基座上微调了两个小型 LoRA 适配器，一个标记高风险 secret（密钥等敏感凭据），一个清除误报。在 5% 误报预算下，微调模型捕获约 70% 的真实 secret，对比 GPT-5.5 的约 59%，且更快、成本更低。

Figma 的 AI 研究经理 Sumithra Bhakthavatsalam 则这样描述自助 API 的价值：「Fireworks 的自助 API 提升了我们的实验速度与整体生产力，让 Figma 的 AI 团队把更多时间花在科学与研究上，而不是调试基础设施。我们得以更快迭代，构建出真正改变设计与产品开发工作流的功能。」

Fireworks Lab：诊断先行、时间盒交付

Fireworks Lab 是本次 GA 的另一半，负责帮团队做出训练策略决策。它的做法是让前向部署研究员与工程师直接嵌入客户团队：完整合作从诊断开始，先定义能力、基线、成功标准与范围，再以目标日期倒推，进行时间盒（time-boxed）实现。需要决策的问题包括采用同步还是异步 RL、可接受的权重陈旧度、rollout 与训练器的算力分配、并行策略，以及检查点与热加载策略。合作结束时，客户保留生产就绪的模型、评估框架、数据管道、训练循环与配方，成果不留在 Fireworks 手里。

这篇公告里的全部量化成效都出自 Fireworks 自己的博客，未经独立验证。Training API 能否兑现这些数字，要等客户在自己的训练循环上跑出结果。