微调瓶颈不在算法，而在集成与迭代速度

文章

微调的瓶颈不在算法

团队通常会追逐最新的训练算法，但真正的瓶颈在于集成、迭代速度，以及何时选择 SFT、RFT 还是 DPO。

大多数来找我们做微调的团队，并不是在训练算法上遇到困难。他们真正困扰的是围绕算法的一切：如何让奖励函数与内部 API 对接而不泄露数据，因为每个步骤都在不同工具中，导致实验之间要等几天，以及搞不清楚问题到底是否需要 SFT、RFT 或 DPO。在过去一年里，我们与一些最具创新精神的初创公司、数字原生企业和财富 500 强企业合作，发现这些模式在每次合作中都反复出现。

所有来找我们的团队，

都在构建领域特定代理。代码修复、客户支持、深度研究、金融运营——应用场景各不相同，但结构是一样的。通用前沿模型遇到了质量天花板，下一步就是进行模型级别的定制化。

这个天花板是实实在在的。

我们的一位客户“Deep Research”代理在封闭前沿模型上的奖励分数卡在了 0.76。他们改用 Fireworks 平台上的开放模型进行 RFT 微调，分数突破到 0.82 —— 这个提升仅靠提示工程是无法实现的。另一家大型数字原生企业通过 RFT 微调后，任务质量提升了 30%，延迟降低了 2.5 倍。提示工程只能走这么远，要达到新的能力层级，必须依靠微调。

在同一账户内，我们看到从异常检测到奖励建模再到 AI 搜索等多种用例同时运行。一个组织内部如此广泛的使用场景说明：微调已经成为构建智能体的持续基础设施，而不是一次性的操作。

代理旅程

每个团队都遵循相同的路径：通用模型遇到质量天花板，微调填补差距，最终产出一个投入生产的领域专用代理。

在这些合作中——无论行业、模型规模还是应用场景——同样的问题不断重现。有趣的是，这些问题都不是关于训练算法本身，而是围绕它的那些环节。

最一致的障碍是集成。奖励函数、内部评分器和评估 API 必须留在客户的环境中。敏感的业务逻辑和专有数据不能离开客户环境用于第三方评分。

Fireworks 在两个层面解决了这个问题。对于需要完全数据隔离的团队，

允许你在本地运行训练循环——数据永远不出你的环境，你控制 Python 进程，数据保留在你这边，只有权重更新通过平台传输。对于托管微调，

和

确保整个训练过程在客户的 VPC 内执行。

有一支团队因合规要求只能使用特定非中文开源模型。模型可用性和地缘政治因素对微调流程的影响，不亚于训练算法本身。平台必须支持广泛的基座模型。

数据主权架构

奖励函数、评分器和训练数据均保留在客户环境中。训练平台安全连接，无需数据离开 VPC。

训练任务很少成为瓶颈。真正瓶颈是周期时间。团队花数周搭建训练基础设施、清洗噪声数据集、跑一次训练任务，然后通过离线评估才发现模型质量仍不达标。等到他们调整数据、优化超参数并重新训练时，又过去一周了。实际 GPU 时间只是总周期的一小部分。

最快前进的团队已经将这个周期从几周缩短到几小时。高频提交任务、快速获得改进反馈、实验间几乎无手动设置。一支团队在几周内运行了超过 100 次任务；另一支团队连续提交数十次 RFT 任务，近乎无缝迭代。这种节奏更像是 CI 流水线，而非传统机器学习实验。我们与 Cursor 在 的合作是最清晰的例子——Fireworks 提供了分布式强化学习训练基础设施，帮助 Composer 2 在编码基准测试中击败顶级闭源前沿模型，得益于紧密的推理-训练闭环，每约 5 小时就能发布一个新检查点。

将微调和部署统一在一个平台上，才使得这一切成为可能。训练好的 ——无需导出模型，也无需单独的服务堆栈。 直接对实时部署进行评估。 让团队在投入 GPU 时间前就能规划迭代预算。

这里还有一个隐藏的乘数效应：

（这是第 2/3 部分，请保持翻译风格一致）

. 训练/测试分割规范、网格搜索和学习率调优对最终模型质量仍有显著影响。大多数构建代理的产品团队没有专门的机器学习工程师来正确执行这些步骤，实验设置粗糙是微调“不起作用”的主要原因之一。这是我们认为工具链最有改进空间的领域——想象一个系统能自动监控每次运行中的评估指标并调整训练配置，而不是要求 ML 专家全程盯住每个实验。我们正在构建这样的系统，而且它比你想象的更近。

迭代速度

区分成功交付与停滞不前的团队：将评估-训练-部署周期从几天的碎片化工具整合为以小时计的紧密闭环。

迭代最快的团队已经不再把微调当作单一技术。在同一账户中，我们经常看到

、

和

同时运行于同一产品——每种方法针对问题的不同部分。

方法选择应跟随问题本身，而非相反。

当你拥有高质量演示数据和明确的输出格式时 —— 使用蒸馏（distillation）、结构化提取（structured extraction）或风格迁移（style transfer）。

当奖励信号比正确输出更清晰时 —— 使用代理任务（agentic tasks）、工具使用（tool use），任何难以标注但容易评估的任务（例如 RFT）。

当你有强偏好对（preference pairs）且希望对齐行为而无需编写奖励函数时。

真正的力量在于组合它们。我们常见的模式是：先用 SFT 从演示数据中蒸馏出一个强大的基线，再切换到 RFT 来提升 SFT 无法捕捉的代理行为质量。平台让这变得简单。通过

，你可以直接从之前的 SFT Adapter 启动 RFT 运行（使用 --warm-start-from 参数），这样微调后的 PEFT 检查点就成为强化训练的起点，无需手动导出。若需更深控制，Training API 支持跨作业边界

—— SFT 运行可以无缝流入 RFT 运行，并保留完整的优化器状态。

模型选择也是搜索空间的一部分。我们看到团队同时在多个规模上进行实验：子 1B 模型用于快速迭代，200B+ MoE 模型用于生产级质量，有时一周内两者都跑。平台必须让方法和模型之间的切换毫无摩擦。我们还支持

用于多模态场景。

存在一种稳定的成熟路径。团队几乎总是从

—

DPO 或 RFT 开始，通过 API 调用。这是正确的起点。它移除了基础设施对关键路径的影响，并验证了微调确实适用于你的问题。

然后他们会遇到瓶颈。深度领域适配，尤其是在大型 MoE 架构上，需要更多控制：

、自定义数据流水线、优化步访问权限、LoRA 无法实现的全参数更新。从“托管服务帮你完成 80%”到“我们需要剩下的 20%”，正是这个差距决定了团队是停滞还是重新搭建整个堆栈。

填补这一差距。相同的基础设施、相同的部署目标，但你可以自带训练循环。自定义 GRPO、DAPO 或混合目标。对高达 200B 的模型进行全参数更新。在推理过程中评估，使用实时服务检查点。无需准备 GPU 集群。这个

让你几分钟内就能开始。

从抽象层级最高的地方起步，需要时再下沉。关键是过渡要无缝——你不应该为了获得更多控制而重新平台化。

选择你的控制级别

从完全托管的微调任务，到类似菜谱式的 SFT/DPO/GRPO 工作流，再到自定义 Python 训练循环。同一平台，每一层都适用。

行业正从手动 ML 实验转向 CI/CD 式的微调循环——逻辑终点是一个能自我运行的闭环。

我们上面描述的所有瓶颈都是本不该手动执行的步骤。集成不应需要数周定制连接器工作——训练平台应原生接入客户的评估基础设施。迭代不应因人类决定何时重训而停滞——平台应监控评估指标，检测退化并自动触发训练。超参数调优也不应每个实验都需要 ML 专家——系统应观察数千次历史运行的结果，推荐可能收敛的配置。

把这些结合起来，你就得到了一个自身具备代理能力的微调流程。

评估到重训的闭环会自动闭合。系统观察模型在生产中哪里出错，选择合适的训练方法，配置运行，用保留数据验证结果，如果质量提升则自动部署。人类定义什么是好的标准并设定护栏。其余全部由系统完成。

我们合作的团队已经在手工拼凑这个闭环——编写脚本监控评估仪表盘、触发重训并控制部署。我们正在构建使该闭环成为第一类原语的基础设施。稍后会有更多内容。

代理式微调

未来状态：评估到重训的闭环自动闭合。人类设定目标和护栏；系统负责观察、训练、验证和部署。

如果你觉得这些听起来很熟悉，现在就可以开始。

• •托管微调 ——

通过 API。16B 以下的模型可免费微调。从 开始。

（这是第 3/3 部分，请保持翻译风格一致）

• •需要更多控制？—— 对于自定义训练循环、全参数更新以及在循环中进行推理评估，

我们正在开发自动超参数优化、基于评估的重新训练，以及闭环的代理微调工作流。如果你希望提前体验或讨论你的微调架构，请通过我们的 [链接] 或在 [平台] 上联系我们。