Migrating from closed to open source models, Together

从闭源模型迁移到开源模型，Together

迁移是任何成熟公司都面临的难题。系统高度集成，你拥有跨领域的关键利益相关者，而传统情况下，即使是微小的改进也可能需要数月甚至数年才能整合。最近，迁移的最新候选对象是从闭源模型迁移到开源模型（OSM）。成本节约和技术创新的分布式所有权一直具有吸引力。但这样做是否值得呢？

幸运的是，从闭源到开源的迁移打破了缓慢且痛苦的迁移传统，尤其是如果你采用托管服务的话。这些服务能够跟上AI创新的步伐，同时将大量复杂性从你的业务中转移出去。

现在影响范围大大缩小，你需要迁移的技术栈也更简单。Harnesses、网关和工具都构建用于采用各种模型。你可以充分利用这些工具，实现从闭源到开源的快速且全面的迁移。

我们将带您了解我们与客户合作看到的成功迁移策略。这通常需要几周到几个月，而不是几个月到几年。未来，我们还将提供资产来帮助您跟踪迁移过程中的进展。

这只是一个概述。我们将为每个我们认为需要更深入探讨的章节提供详细分析，包括工作簿、示例和操作指南。

发现

当你开始发现候选模型时，最重要的是明确你评估的目标。没有一种模型在所有方面都是最佳选择。不同模型在不同领域有各自的优势，你越清楚地定义想要解决的问题，就越容易筛选出真正适合你的模型。首先，用简洁明了的术语定义你的使用场景和工作负载：模型处理哪些任务，理想的响应是什么样子，以及实际流量的具体构成。

在明确使用场景后，现有的基准测试可以作为过滤工具。识别与你的工作最相关的基准测试，使排行榜上的数字与你在任务中的表现相关联。优秀的基准测试来源包括：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

Frontier Open（例如GLM-5.3、Kimi K3）、Value Tier（例如DeepSeek-V4 Flash、GLM-5.3 Flash）、小型和边缘部署（例如Qwen 3.8 27B、Muse Glimmer）

记住，你的任务是识别哪些模型对你的候选模型筛选有帮助，我们稍后会更多地讨论自定义评估。通常你会发现有三个层级的模型可供选择，如上所述。

对于你的顶级候选模型，不要只看原始性能。查看每项任务的成本，模型每次尝试消耗多少token，需要多少步骤，端到端的运行时间，以及你能多快验证正确答案。现在许多新的基准测试都在报告这些按任务计算的指标，我们认为这些指标与实际模型成本和性能的相关性更高。一个得分稍低但能在一半token和一半时间内完成任务的模型可能是更好的选择。

最后，进行实际测试。选取一些具有代表性的任务，在测试环境中运行，观察候选模型是否达到预期效果。注意模型的故障模式，并判断是模型本身的问题，还是模型运行环境或上下文配置的问题。同时，也值得关注其他使用同类模型的公司对其使用体验的反馈。完成此步骤后，你应该筛选出两到三个准备进行深度评估的模型。

评估

模型评估将是整个流程中最复杂的一部分，显然需要单独撰写一篇博客进行详细说明。但总体而言，你需要评估两个核心指标：准确性和性能。

准确性定义了模型的能力范围。这包括指令遵循、摘要生成、函数调用、视觉识别表现等。这些是模型能够实现的所有功能，无论其运行环境或速度如何。你需要评估模型是否能够满足你的业务需求。

性能则关注模型的运行表现。这会受到模型规模、架构等因素的影响。在这些测试中，我们并不关心模型对请求的响应效果，而是评估该模型是否符合采用开源模型（OSM）所需的成本控制、用户体验（延迟）等要求。

对于准确性和性能的评估，你需要保持一致的思维：基准测试具有方向性参考价值，但真正的测试必须使用真实数据。评估工作负载的最佳方式不是查找或运行通用基准测试。因为不同工作负载的流量特征、响应需求和请求结构各不相同，没有任何基准测试能完全代表你的场景。幸运的是，如果你已经在使用闭源模型，只需简单回放现有流量数据即可完成基准测试，无需自定义测试套件或大规模数据集。事实上，这一直是最佳的基准测试方式，即使在我们开始对现代前沿模型（如HPC、数据库、负载均衡等）进行基准测试之前，这种方法就已经被广泛采用。不过，确保你仍然针对之前定义的目标进行测试。

如果你没有可回放的数据，也不要担心！我们仍然可以根据通用使用模式（如输入输出大小、预期缓存命中率）进行估算。如果闭源模型提供商未提供这些指标，像LiteLLM这样的网关可以帮助收集这些信息。我们将在后续的深度解析博客中进一步探讨这一技术。

当你找到数据后，需要明确自己的目标：是降低成本？提高速度？还是提升或保持质量？当你用新选择的模型重新运行数据时，这些目标就是你的基准线。你的目标是达到或超越这一基准线。当开源模型（OSM）通过这一基准线时，你就获得了技术验证，可以推进到全面迁移阶段。

投入精力完善评估方法，将使你的团队能够更轻松地快速采用新的开源模型（OSM）。在后续的博客中，我们将深入探讨如何量化工作负载、重放流量以及分析评估结果。目前，这就是评估开源模型（OSM）的基础原则。

适配

前沿开源模型的性能已经足够强大，通常开箱即用即可满足大多数应用场景的需求。但如果某个模型未通过你的评估，就需要进行适配调整。这并不意味着该模型没有价值。通常这意味着你使用模型的方式是为其他模型量身定制的：提示词、采样参数、模型运行环境等。你的闭源系统中积累了大量针对特定模型的调优经验，而开源模型从未接触过这些配置，因此你很可能需要进行适配调整。

Decide

技术验证是迁移过程中的一半战斗。一旦证明OSMs可以匹配或超越当前闭源产品的功能，就需要将这些结果打包并传达给利益相关者，说明“为什么”。

概述迁移到OSMs所需的投入、潜在风险以及投资回报率（ROI）。

根据我们的经验，一些高层次的指导建议如下：

投入将定义迁移到OSMs所需的实际工作量。有时会出现工具和框架的兼容性问题，但这一差距正在日益缩小。例如，我们提供的工具togetherlink可以让用户在任何框架中轻松安装并开始使用OSMs。记录任何需要进行的集成或更改，以实现对OSM的全面利用。

风险反映了采用新技术的传统风险：合规性、扩展性、持续迁移、对工具的熟悉程度以及对下游服务的影响。记录这些风险并根据公司的具体需求进行处理。如果选择使用托管服务提供商，其中大部分风险都可以得到解决。

如果在此阶段已正确设置评估，这一部分可以大大简化，尽管你仍然可以将其视为一个反馈到评估中的循环。

ROI可以从评估阶段计算出一个可量化的价值。每美元能生成多少个token？这与闭源解决方案相比如何？我们看到在某些情况下，客户迁移到开源后，成本可降低多达70%。你也可以对质量进行类似计算：质量与闭源解决方案相比如何？这将帮助你向利益相关者定义ROI。

理想情况下，在明确风险、投入和ROI后，决策应该变得容易。此时的采用更多是关于教育而非技术限制。

Production

在获得批准后，迁移工作开始。如前所述，传统上迁移后进入生产环境是一个漫长而繁琐的过程。然而，从闭源迁移到OSM时，我们发现这实际上是所有步骤中最轻量的一步。

我们可以借鉴传统迁移实践，评估迁移的影响并制定路线图。这些内容大多可以基于之前关于工作量和风险的分析。我们的迁移会影响下游服务吗？如何通过安全和合规团队的审批获得模型的批准？是否需要对现有工具或基于旧模型构建的服务进行调整？这种转变也不必立即完成。金丝雀部署在客户验证生产用例时取得了显著成效，可以先从将10%的流量导向开源方案开始。

路线图应包含实现OSM采用所需的所有步骤。这应包括需要实施的任何安全合规措施、技术变更或下游服务变更。请不要感到畏惧，技术实现可能简单到只需替换一个接口端点！

我们理解这只是一个非常简化的概述，但核心层面，我们已多次协助最大客户完成此类转型，并坚信这比传统技术迁移要轻松得多。

如果您正在经历类似的迁移，我们鼓励您关注后续博客，或通过[email protected]联系销售团队提出任何问题。我们也很欢迎您反馈此处可能遗漏的内容。祝您构建顺利！