迁移是任何成熟公司的祸根。系统深度集成，你在各个领域都有关键利益相关者，而在传统情况下，一个小小的改进可能需要数月甚至数年才能整合完成。最近，最新的迁移候选对象是从闭源模型转向开源模型（OSM）。节省成本和分布式技术所有权的承诺一直很有吸引力。但这真的值得吗？
幸运的是，从闭源到开源的迁移打破了缓慢而痛苦的迁移传统，尤其是当你采用托管服务时。这些服务紧跟 AI 创新的步伐，同时将大部分复杂性从你的业务中卸载出去。
如今，影响范围要小得多，你需要迁移的技术栈也不那么复杂。框架、网关和工具都是为了适配各种模型而构建的。你可以充分利用这一点，快速而全面地从闭源迁移到开源。
我们将带你了解我们在客户身上看到的一套成功迁移策略。这可能需要数周到数月，而不是数月到数年。未来，我们还会提供资产来帮助你在整个过程中跟踪进展。
这是一个概览。我们将为每个我们认为需要更多细节的部分提供深入探讨，并附上工作手册、示例和操作演示。
探索
当你开始探索候选模型时，最重要的是明确你要评估什么。没有哪个模型在所有方面都是最好的。不同模型在不同领域各有优势，你越清晰地定义想要解决的问题，就越容易筛选出真正适合你的模型。首先用通俗的语言定义你的用例和工作负载：模型处理哪些任务、什么样的响应算是好的，以及你的流量实际由什么构成。
定义好用例后，现有的基准测试就可以作为筛选工具发挥作用。找出与你的工作最相关的基准测试，使排行榜上的数字与你在任务上的表现相关联。基准测试的良好来源包括 The Open Frontier、Artificial Analysis、Epoch AI、Vals AI、Scale 的排行榜、Intelligence 和 Arena。在这些来源中，你可能会发现以下基准测试很有用：
- 编码智能体： FrontierCode、DeepSWE、Terminal Bench 4 - 聊天和通用助手工作：
LMArena、AA-Intelligence Index - 智能体和工具使用：
τ-bench、Agent Arena - 视觉：
前沿开源（例如 GLM-5.3、Kimi K3）、价值层级（例如 DeepSeek-V4 Flash、GLM-5.3 Flash）、小型和可边缘部署（例如 Qwen 3.8 27B、Muse Glimmer）
请记住，你的工作是确定其中哪些与你相关，以便缩小候选模型的范围，我们稍后会详细讨论自定义评估。通常你会发现有三个层级的模型可供选择，如上所示。
对于你的顶级候选模型，不要只看原始性能。要关注每个任务的成本、模型每次尝试消耗的令牌数、需要多少步骤、端到端运行时间，以及你能多快验证一个正确答案。许多新的基准测试现在都在报告这些每任务数据，我们相信这些数据与实际模型成本和性能更相关。一个得分低几分但完成任务消耗一半令牌和时间一半的模型可能更合适。
最后，试驾一下。将一些代表性任务带入游乐场，看看你入围的模型是否如预期表现。注意失败模式，并问是模型失败还是其周围的框架和上下文失败。也值得看看其他运行这些模型的公司对其体验的评价。你应该在这一步结束时留下两到三个准备进行严肃评估的模型。
评估
评估模型将是这个过程最复杂的部分，当然需要一篇自己的博客，但高层次上你将评估两件事：准确性和性能。
准确性定义了模型的能力。这可以包括指令遵循、摘要、函数调用、视觉性能等。这是模型无论在哪里运行或运行多快都能做的一切。你想评估它是否能解决你的工作负载需求。
性能涵盖了模型运行得如何。这根据模型大小和架构等因素而变化。对于这些测试，我们不关心模型响应请求的好坏。我们评估的是这个模型是否满足采用 OSM 所需的成本和用户感受，或延迟期望。
对于准确性和性能，你都需要有一致的心态：基准测试具有方向性用处，真正的测试是用真实数据完成的。评估工作负载的最佳方式不是查找或运行通用基准测试。工作负载有不同的流量形态、小众响应需求和请求结构。除了你自己的，没有基准测试能代表这些。幸运的是，如果你已经在使用闭源模型，简单重放现有流量就是你基准测试所需的全部数据。无需自定义套件，无需大型数据集。这是，并且一直是，最好的基准测试方式，甚至在我们对现代前沿模型（HPC、数据库、负载均衡等）进行基准测试之前。不过，确保你仍然针对之前定义的目标进行测试。
如果你没有数据可重放，你并没有被阻塞！我们仍然可以根据一般使用模式（如输入和输出大小以及预期缓存命中率）进行规模估计。如果闭源提供商不提供这些指标，像 LiteLLM 这样的网关可以帮助收集这些信息。我们将在深度探讨博客中进一步讨论这种技术。
找到数据后：确定你的目标是什么。你想节省成本？速度？改进或类似质量？当你针对所选的新模型重新运行数据时，这就是你的目标线。你的目标是达到或超过它。当 OSM 通过这条目标线时，你就有了技术验证，可以继续进行全规模迁移。
投资于稳健的评估技术将使你的团队能够轻松快速地采用新的 OSM。在后续博客中，我们将更深入地探讨如何确定工作负载规模、重放流量以及评估结果。目前，这是评估 OSM 的基础概念。
适应
前沿开放模型已经足够好，通常开箱即用就能满足大多数应用，但如果模型未通过你的评估，你就需要适应。这并不一定意味着模型是死胡同。通常意味着你使用它的方式是为另一个模型调优的：提示词、采样参数、围绕它的框架。你的闭源设置积累了大量调优，而开源模型从未见过，很可能你需要调整它。
这里有几个杠杆，大致按投入精力排序：
系统提示工程：尝试以不同方式询问模型。模型训练方式不同，可能需要不同的提示才能达到与当前闭源模型相同的水平。模型推理设置：温度、top_k 等采样参数、保留思考以及推理努力程度都能显著改变行为。上下文工程和框架本身：构成模型运行软件环境的技能、工具和 MCP 服务器。通过微调或蒸馏调整模型权重：最难实现，因为它需要明确定义的评估、精心整理的数据和真实的实验，但它可以解锁一个利基领域，让小模型发挥出远超其体量的作用。
无论你拉动哪个杠杆，都要将此过程视为迭代循环。设置实验，隔离单一修改，评估其影响，并迭代直到找到真正改善评估的东西。保持评估模块化和实验简单。如果你同时测试太多东西并改变太多变量，你将永远无法在混杂的噪音中分离出有效因素。如上所述，一套明确定义的评估是在上述适应上富有成效地迭代的最重要的事情。
决定
与任何迁移一样，技术验证只是成功的一半。一旦你证明 OSM 能够匹配或超越当前闭源产品的功能，你需要打包这些结果并向利益相关者传达“为什么”。
概述迁移到 OSM 所需的努力、风险以及投资回报率（ROI）。
根据我们的经验，一些高层指导：
努力将定义过渡到 OSM 所需的实际工作量。偶尔会有框架和工具的兼容性问题，但这里的差距每天都在缩小。例如 togetherlink，我们提供的一个工具，只需简单安装即可在任何框架中开始使用 OSM。记录为大规模充分利用 OSM 所需进行的任何集成或更改。
风险反映了采用新技术相关的传统风险：合规性、规模、持续迁移、工具熟悉度、影响下游服务。记录这些并针对你公司的具体需求加以解决。如果你选择使用托管提供商，其中大部分问题都能得到解决。
如果你在适当评估的情况下达到这个阶段，这部分可以大大简化，不过你仍然可以将其视为反馈到评估的循环。
ROI 可以从你的评估阶段计算为一个可量化的值。每美元能生成多少 token？与闭源相比如何？我们看到在某些情况下，当客户转向开源时，成本降低高达 70%。你也可以对质量做同样的事：质量与闭源相比如何？这将有助于向利益相关者定义你的 ROI。
理想情况下，一旦定义了风险、工作量和 ROI，决策就应该很容易做出。此时，采用更多是关于教育而非技术边界。
生产
在批准时，迁移开始。如前所述，传统上迁移后投入生产是一个漫长而拖沓的过程。然而，在从闭源过渡到 OSM 时，我们发现这实际上是最轻松的步骤之一。
我们可以从传统迁移实践中学习，盘点迁移的影响并制定路线图。我们可以将大部分基于前面的工作量和风险部分。我们会影响下游服务吗？我们如何让模型通过安全和合规团队的批准？基于先前模型构建的工具或服务是否需要任何更改？这种转变也不需要立即进行。金丝雀部署在我们的客户中取得了巨大成功，用于针对生产用例进行验证，从 10% 的流量开始使用开源。
路线图包含采用 OSM 所需的所有步骤。这应包括任何需要做出的安全/合规、技术变更或下游服务变更。不要被这里吓到，技术实现可以简单到切换一个端点！
我们理解这是一个非常简化的概述，但本质上，我们已经与最大的客户见证了这种转变数十次，并坚信它远比传统技术迁移更不繁琐。
如果你正在进行类似的迁移，我们鼓励你关注未来的博客，或联系 sales@together.ai 提出任何问题。我们也希望得到关于这里可能缺失内容的任何反馈。快乐构建！