如何从闭源模型迁移到开源模型：Together 的迁移策略

幸运的是，闭源到开源的迁移打破了缓慢而痛苦的迁移传统，尤其是当你采用托管服务时。这些服务紧跟 AI 创新的步伐，同时将大量复杂性从你的业务中卸载出去。

现在爆炸半径小得多，你需要迁移的技术栈也没那么复杂。Harness、网关和工具链都设计为可适配多种模型。你可以充分利用这一点，快速而全面地从闭源迁移到开源。

我们将带你了解我们在客户中见过的一套成功迁移策略。这可能需要数周到数月，而不是数月到数年。未来，我们还会提供资产来帮助你跟踪整个过程中的进展。

这是一个概览。对于我们认为需要更多细节的每个部分，我们将提供深入解析，并附上工作手册、示例和演练。

发现

当你开始发现候选模型时，最重要的事情是明确你在评估什么。没有哪个模型在所有方面都是最好的。不同模型在不同领域各有优势，你越清楚地定义想要解决的问题，就越容易筛选出真正适合你的模型。首先用平实的语言定义你的用例和工作负载：模型处理哪些任务、什么样的响应算好、你的流量实际由什么构成。

定义好用例后，已有的基准测试就可以作为筛选工具发挥作用。找出与你工作最相关的基准测试，让排行榜上的数字与你在任务上的表现相关联。基准测试的良好来源包括 The Open Frontier、Artificial Analysis、Epoch AI、Vals AI、Scale 的排行榜、Intelligence 和 Arena。在这些来源中，你可能会发现以下基准测试很有用：

• 编码智能体：FrontierCode、DeepSWE、Terminal Bench 4
• 聊天和通用助手工作：LMArena、AA-Intelligence Index
• 智能体和工具使用：τ-bench、Agent Arena
• 视觉：Vision Arena

请记住，你的工作是确定其中哪些与你相关，以缩小候选模型范围，我们稍后会详细讨论自定义评估。通常你会发现有三档模型可供选择，如上所示。

对于你的首选候选模型，不要只看原始性能。还要看每任务成本、模型每次尝试消耗多少 token、需要多少步骤、端到端运行时间，以及你能多快验证正确答案。许多新基准测试现在都会报告这些每任务数字，我们相信它们与实际模型成本和性能的相关性更好。一个得分低几分但完成任务所用 token 和时间都减半的模型，可能是更合适的选择。

最后，实际试用一下。把一些有代表性的任务放进 playground，看看你入围的模型是否如预期般表现。留意失败模式，并思考是模型本身失败，还是其运行框架和上下文导致的。也值得看看其他运行这些模型的公司是怎么评价他们的体验的。完成这一步后，你应该留下两到三个准备进入严格评估的模型。

评估

评估模型将是整个流程中最复杂的部分，肯定需要单独一篇博客来阐述，但概括来说，你需要评估两件事：准确性和性能。

准确性定义了模型的能力。这可以包括指令遵循、摘要、函数调用、视觉表现等。这是模型无论在哪里运行、速度多快都能做到的一切。你要评估它能否满足你的工作负载需求。

性能涵盖模型运行得如何。这会因模型规模和架构等因素而变化。对于这些测试，我们并不关心模型对请求的响应有多好。我们评估的是该模型是否满足采用 OSM 所需的成本和用户体验，即延迟方面的期望。

对于准确性和性能，你都需要保持一种一致的心态：基准测试具有方向性参考价值，真正的测试要用真实数据来做。评估工作负载的最佳方式不是查找或运行通用基准测试。工作负载有不同的流量形态、特定的响应需求和请求结构。除了你自己的基准测试，没有哪个基准能代表这些。幸运的是，如果你已经在使用闭源模型，只需简单重放现有流量，就是你做基准测试所需的全部数据。无需自定义测试套件，无需大型数据集。这一点，甚至在我们对现代前沿模型（HPC、数据库、负载均衡等）进行基准测试之前，就一直是最佳方法。不过要确保你仍然针对之前定义的目标进行测试。

如果你没有可重放的数据，你也不会被卡住！我们仍然可以根据一般使用模式来估算规模，比如输入和输出大小以及预期的缓存命中率。如果闭源提供商不提供这些指标，像 LiteLLM 这样的网关可以帮助收集这些信息。我们将在后续深度博客中进一步讨论这一技术。

找到数据之后：确定你的目标是什么。你想节省成本？提升速度？改进或保持相近的质量？当你用所选的新模型重新运行数据时，这就是你的目标线。你的目标是达到或超越它。当 OSM 通过这条目标线时，你就有了技术验证，可以进入全面迁移阶段。

投资于稳健的评估技术，将使你的团队今后能够轻松快速地采用新的 OSM。在后续博客中，我们将更深入地探讨如何估算工作负载规模、重放流量并评估结果。目前，这就是如何评估 OSM 的基础概念。

适配

前沿开源模型已经足够好，通常开箱即用就能满足大多数应用，但如果某个模型无法通过你的评估，你就需要做适配。这并不一定意味着该模型是死路一条。通常意味着你使用它的方式是为另一个模型调校的：提示词、采样参数、围绕它的运行框架。你的闭源方案积累了大量调优，而开源模型从未见过这些，你很可能需要做适配。

这里有几个可用的杠杆，大致按投入精力排序：

1. 系统提示词工程：尝试换一种方式向模型提问。模型的训练方式不同，可能需要不同的提示方式才能达到你当前闭源模型的同等水平。
2. 模型推理设置：温度、top_k 等采样参数、保留思考，以及推理强度，都能显著改变行为。
3. 上下文工程与运行框架本身：构成模型运行软件环境的技能、工具和 MCP 服务器。
4. 通过微调或蒸馏调整模型权重：最难实现，因为它需要定义清晰的评估、精心整理的数据和真正的实验，但它可以解锁一个细分领域，让小模型发挥出远超其体量的实力。

无论你拉动哪些杠杆，都要把这一过程当作迭代循环。设置只隔离单一改动的实验，评估其影响，并不断迭代，直到找到真正能提升评估结果的做法。保持评估模块化、实验简单。如果你同时测试太多东西、一次改动太多变量，就永远无法在混杂的噪声中分辨出什么在起作用。上文讨论过的一套定义清晰的评估，是在上述适配中有效迭代的最重要前提。

决策

与任何迁移一样，技术验证只是成功的一半。一旦你证明 OSM 能够匹配或超越当前闭源方案的功能，就需要把这些结果打包，并向利益相关方说明“为什么”。

概述迁移到 OSM 所需的投入、存在哪些风险，以及投资回报率（ROI）是多少。

根据我们的经验，一些高层面的指引：

投入将决定迁移到 OSM 实际需要的工作量。运行框架和工具偶尔会有兼容性问题，但这一差距每天都在缩小。例如togetherlink，这是我们提供的一个工具，只需简单安装，就能在任何运行框架中使用 OSM。记录下要大规模充分利用 OSM 所需做的任何集成或改动。

风险反映采用新技术时的传统风险：合规、规模、持续迁移、对工具的熟悉程度、对下游服务的影响。记录这些风险，并针对你公司的具体需求加以应对。如果你选择使用托管服务商，其中大部分风险都能得到解决。

如果你在评估到位的情况下走到这一步，这部分可以大大简化，不过你仍然可以把它当作一个循环，将结果反馈回评估。

ROI 可以从你的评估阶段计算为一个可量化的值。每美元能生成多少 token？与闭源相比如何？我们看到在某些情况下，当客户转向开源时，成本可降低高达 70%。你也可以对质量做同样的事：质量与闭源相比如何？这将有助于向利益相关者定义你的 ROI。

理想情况下，在定义了风险、投入和 ROI 之后，决策就应该很容易做出。此时，采用更多是关于教育而非技术边界。

生产

在批准之时，迁移就开始了。如前所述，传统上迁移后投入生产是一个漫长而拖沓的过程。然而，在从闭源过渡到 OSM 时，我们发现这实际上是最轻松的步骤之一。

我们可以借鉴传统迁移实践，盘点迁移的影响并制定路线图。我们可以将大部分内容基于前面的 投入 和 风险 部分。我们会影响下游服务吗？我们如何让模型通过安全和合规团队的批准？基于先前模型构建的工具或服务是否需要任何更改？这种转变也不必立即进行。金丝雀部署在我们的客户中取得了巨大成功，用于针对生产用例进行验证，从 10% 的流量开始转向开源。

路线图包含你的 OSM 采用所需的所有步骤。这应包括任何需要做出的安全/合规、技术变更或下游服务变更。不要被吓到，技术实现可以简单到只需更换一个端点！

我们理解这是一个非常简化的概述，但就其核心而言，我们已经在最大的客户中见证了数十次这种转变，并坚信它远比传统的技术迁移轻松得多。

如果你正在经历类似的迁移，我们鼓励你关注未来的博客，或联系 sales@together.ai 提出任何问题。我们也非常希望听到关于这里可能遗漏之处的任何反馈。祝你构建愉快！