微调瓶颈并非算法问题

微调瓶颈并非算法问题

DeepSeek V4 Pro 已上线 → 立即尝试。

博客

微调瓶颈

微调瓶颈并非算法问题

发布时间：2026年3月28日

目录

最终目标始终是智能体

反复出现的瓶颈

集成与数据主权

迭代速度

为任务选择合适的工具

从托管到完全控制的阶梯

未来方向

立即开始微调

团队往往追逐最新的训练算法，但真正的瓶颈是集成、迭代速度，以及何时使用SFT、RFT或DPO。

TL;DR：集成摩擦和缓慢的迭代周期才是真正阻碍微调的瓶颈，而非算法。我们分享了在多个项目中观察到的模式，例如Cursor和Genspark等团队如何突破这些瓶颈，以及工作流的未来趋势：完全自主的微调循环，可自动闭环。

大多数寻求微调帮助的团队并非在训练算法上遇到困难。他们面临的是围绕算法的一切：如何让奖励函数与内部API通信而不泄露数据；每次实验需等待数天，因为每个步骤都分散在不同工具中；以及判断问题是否适合使用SFT、RFT或DPO。过去一年中，与一批最具创新性的初创公司、数字原生企业和财富500强公司合作，我们在每个项目中都看到了这些重复模式。

最终目标始终是智能体

每个寻求微调帮助的团队都在构建特定领域的智能体。代码修复、客户支持、深度研究、金融操作——用例不同，但形式相同。通用前沿模型遇到质量天花板，前进的道路是模型级定制。

这个天花板是具体的。Genspark的深度研究智能体在封闭前沿模型上得分仅为0.76。他们通过Fireworks转向基于开放模型的RFT，得分超过0.82——这一跳跃是提示工程无法单独实现的。我们合作的一家大型数字原生企业，在使用RFT微调后，任务质量提升30%，延迟降低2.5倍。提示工程只能带你走到一定程度，要达到新的能力层级，需要微调。

在一个单一账户中，我们看到了从升级检测到奖励建模再到AI驱动的搜索等用例——全部同时运行。这种广度说明微调是构建智能体系统的持续基础设施，而非一次性操作。

智能体之旅

每个团队都遵循相同的轨迹：通用模型达到质量天花板，微调缩小差距，最终结果是生产中的特定领域智能体。

反复出现的瓶颈

在这些项目中——不同行业、模型规模、用例——相同的问题反复出现。有趣的是，这些问题都不涉及训练算法本身，而是围绕算法的所有方面。

集成与数据主权

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

Fireworks在两个层面解决这个问题。对于需要完全数据隔离的团队，Training API允许你在数据永不离开环境的情况下运行训练循环——你控制Python进程，数据保留在你这边，只有权重更新通过平台流动。对于托管微调，安全的自带存储桶存储和远程环境确保评估器在客户VPC内执行。

一个团队因合规要求被限制使用特定的非中文开源模型。模型可用性和地缘政治需求与训练算法一样影响微调工作流。平台必须支持广泛的基础模型。

数据主权架构

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

迭代速度

训练任务很少是瓶颈。周期时间才是。团队花费数周设置训练基础设施，整理嘈杂数据集，运行一次作业，然后通过离线评估发现模型在质量上仍不达标。等到他们迭代数据、调整超参数并重新训练，又过去一周。实际GPU时间只是总周期的一小部分。

速度最快的团队已将该差距从数周缩短到数小时。高频作业提交、快速反馈改进内容、实验间最少手动设置。一个团队在数周内运行了超过100个作业。另一个团队提交了数十个RFT作业，几乎连续迭代。这些节奏看起来更像是CI流水线而非ML实验。我们与Cursor在Composer 2上的合作是最清晰的例子——Fireworks为分布式RL训练基础设施提供支持，帮助Composer 2在编码基准测试中超越顶级前沿封闭源模型，得益于紧密的推理-训练循环，每约5小时即可交付新检查点。

将微调和部署放在同一平台是实现这一点的关键。训练好的LoRA适配器在几分钟内部署——无需模型导出，无需单独的服务栈。eval-protocol CLI针对实时部署运行评估。成本估算器让团队在投入GPU时间前规划迭代预算。

这里还有一个隐藏的倍增器：超参数优化。训练/测试分离纪律、网格搜索和学习率调整对最终模型质量仍有巨大影响。大多数构建智能体的产品团队没有专门的ML工程师来正确执行此操作，而草率的实验设置是微调“不起作用”的主要原因之一。我们认为这是工具最有改进空间的领域之一——想象一个系统，它观察跨运行的评价指标并自动调整训练配置，而不是需要ML专家照顾每个实验。我们正在构建这一点，它比您想象的更近。

迭代速度

成功交付与停滞不前的团队之间的区别：将评估-训练-部署周期从数天的分散工具缩短为以小时计量的紧密循环。

为任务选择合适的工具

迭代最快的团队不再将微调视为单一技术。在一个单一账户中，我们经常看到SFT、RFT和DPO同时用于同一产品——每种方法针对问题的不同部分。

方法选择遵循问题，而非相反。当你有高质量演示数据和定义明确的输出格式时使用SFT——蒸馏、结构化提取、风格迁移。当奖励信号比正确答案更清晰时使用RFT——智能体任务、工具使用、任何正确性难以标记但容易评估的情况（RFT的工作原理）。当你拥有强偏好对并希望在没有编写奖励函数的情况下对齐行为时使用DPO。

真正的力量在于组合使用。我们常见的一种模式：从SFT开始，从演示数据中蒸馏出强基线，然后切换到RFT以推高SFT无法单独捕获的智能体行为质量。平台使这变得简单。使用eval-protocol，你可以通过--warm-start-from直接从之前的SFT适配器热启动RFT运行，因此微调后的PEFT检查点成为强化训练的起点，无需手动导出。为了实现更深层次的控制，Training API允许你跨作业边界加载先前训练作业的检查点——SFT运行流入RFT运行，并保留完整的优化器状态。

模型选择也是搜索空间的一部分。我们看到团队同时进行多种规模的实验——低于1B用于快速迭代，200B以上MoE用于生产质量，有时在同一周内两者兼用。平台必须使方法和模型之间的切换无摩擦。我们还支持多模态用例的视觉微调。

从托管到完全控制的阶梯

存在一致的成熟度模式。团队几乎总是从托管微调开始——通过API进行SFT、DPO或RFT。这是正确的起点。它将基础设施从关键路径中移除，并验证微调是否适用于该问题。

然后他们遇到天花板。深度领域适应，特别是在大型MoE架构上，需要更多控制：自定义损失函数、自定义数据管道、优化器步长访问、LoRA无法达到的全参数更新。托管达到80%的需要剩余20%的差距正是团队要么停滞要么从头重建堆栈的地方。

Training API弥合了这一差距。相同的基础设施，相同的部署目标，但你可以带来自己的训练循环。自定义GRPO、DAPO或混合目标。对高达200B+模型的全面参数更新。使用实时服务检查点的推理内循环评估。无需部署GPU集群。快速入门让你在几分钟内运行。

从最高抽象层开始，当需要时降低到更细粒度。关键在于过渡是无缝的——你不应为了获得更多控制而重新平台化。

选择你的控制级别

从完全托管的微调作业到菜谱式SFT/DPO/GRPO工作流，再到自定义Python训练循环。同一平台在每个级别。

未来方向

行业正从手动ML实验转向CI/CD风格的微调循环——其逻辑终点是自我运行的循环。

我们描述的每个瓶颈都是一个不需要手动的手动步骤。集成不应需要数周的自定义连接器工作——训练平台应原生接入客户的评估基础设施。迭代不应因人类决定何时重新训练而停滞——平台应观察评估指标，检测回归，并自动开始训练运行。超参数调整不应每次都需要ML专家——系统应观察数千个先前运行的经验，并推荐可能收敛的配置。

将这些结合起来，你得到一个本身就是智能体的微调工作流。

评估到重新训练的循环自动关闭。系统观察模型在生产中出错的地方，选择合适的训练方法，配置运行，对保留数据验证结果，并在质量提升时部署。人类定义什么是好的并设置防护栏。系统完成其余工作。

与我们合作的团队已经手动拼接这些循环的片段——编写脚本监控评估仪表板、触发重新训练并控制部署。我们正在构建使该循环成为一等原语的基础设施。更多细节即将发布。

智能微调

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

立即开始微调

如果其中任何内容听起来熟悉，你现在就可以开始。

• 托管微调 ——通过API进行SFT、DPO和RFT。16B以下模型可免费微调。从微调概述开始。

• 需要更多控制？ ——对于自定义训练循环、全参数更新和推理内循环评估，请联系我们了解更多关于训练产品的信息。

我们正在致力于自动超参数优化、评估驱动重新训练以及端到端闭环的智能微调工作流。如果你想提前试用或讨论你的微调架构，请通过我们的联系页面或Discord联系我们。