迁移是任何成熟公司的心头之患。系统深度集成，各领域都有关键利益相关方，按传统做法，哪怕是一点小改进，也可能要花数月甚至数年才能落地。最近，最新的迁移候选项是从闭源模型迁移到开源模型（OSM）。降低成本、让技术所有权更分散的前景一直很有吸引力。但这真的值得吗？
好在，从闭源迁移到开源打破了迁移缓慢而痛苦的传统，尤其是当你采用托管服务时。这类服务能跟上 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
*前沿开源（例如 GLM-5.3、Kimi K3）、性价比档（例如 DeepSeek-V4 Flash、GLM-5.3 Flash）、小型及可边缘部署（例如 Qwen 3.8 27B、Muse Glimmer）*
记住，你的任务是找出其中哪些与你相关，以缩小候选模型的范围，关于自定义评测我们稍后再谈。通常你会发现，可供选择的模型有如上所示的三个层级。
对于排在前面的候选模型，不要只看原始性能。要看每项任务的成本、模型每次尝试消耗多少 token、需要多少步骤、端到端运行时间，以及验证出正确答案有多快。现在很多新的基准测试都会报告这些按任务计算的数字，我们认为它们与实际的模型成本和性能相关性更好。一个得分低几分、但完成任务所需的 token 和时间都只有一半的模型，可能更合适。
最后，亲自上手试一试。拿几个有代表性的任务到试验场（playground）里，看看入围的模型是否表现如预期。留意失败模式，并判断问题出在模型上，还是出在它周围的 harness 和上下文上。也值得看看其他运行这些模型的公司怎么评价自己的体验。这一步结束时，你应该选出两到三个模型，准备让它们接受严格的评测。
评估
评估模型将是整个过程中最复杂的部分，本身就值得单独写一篇博客，但概括来说，你要评估两件事：准确性和性能。
准确性定义了模型的能力。这可以包括指令遵循、摘要、函数调用、视觉表现等。这是模型能做的一切，与它在哪里运行、速度多快无关。你要评估它能否满足你的工作负载需求。
性能涵盖模型运行得有多好。它会随模型大小和架构等因素而变化。在这些测试中，我们不关心模型回答请求的质量如何，而是评估这个模型能否达到采用 OSM 所需的成本和用户体感（即延迟）预期。
无论是准确性还是性能，你都需要保持一致的心态：基准测试在方向上有参考价值，真正的检验要用真实数据来做。评估工作负载最好的办法不是去查找或运行通用基准测试。工作负载有不同的流量形态、特殊的响应要求和请求结构，没有哪个基准测试能代表这些，只有你自己的数据可以。好在，如果你已经在使用闭源模型，只需简单回放现有流量，就拥有了做基准测试所需的全部数据。不需要自定义测试套件，也不需要庞大的数据集。这是、而且一直是做基准测试的最佳方式，早在我们给现代前沿模型做基准测试之前就是如此（HPC、数据库、负载均衡等）。不过，仍要确保针对前面定义的目标进行测试。
如果你没有可回放的数据，也不用被卡住！我们仍可以根据通用的使用模式来估算规模，比如输入和输出大小以及预期的缓存命中率。如果闭源提供商不提供这些指标，LiteLLM 这样的网关可以帮助收集这些信息。我们会在后续的深度博客中进一步讨论这一技巧。
找到数据之后：确定你的目标是什么。是想节省成本？提升速度？还是提高或保持相近的质量？当你用选定的新模型重新运行数据时，这就是你的目标线，你的目标是达到或超过它。当 OSM 越过这条目标线，你就获得了技术验证，可以进入全面迁移。
在稳健的评测方法上投入，将使你的团队今后能轻松、快速地采用新的 OSM。在后续的博客中，我们会更深入地讲解如何估算工作负载规模、重放流量以及评估结果。就目前而言，这就是评估 OSM 的基本理念。
适配
前沿开源模型已经好到大多数应用通常开箱即用，但如果某个模型没有通过你的评测，就需要做适配。这不一定意味着该模型走进了死胡同，通常只是说明你使用它的方式是为另一个模型调好的：提示词、采样参数、围绕它的 harness。你的闭源方案积累了大量调优成果，而开源模型从未见过这些，你很可能需要对其做适配。
你有几个杠杆可用，大致按投入从小到大排列：
- 系统提示词工程：尝试换一种方式向模型提问。模型的训练方式各不相同，可能需要不同的提示方式，才能达到与你当前闭源模型相同的水平。
- 模型推理设置：temperature 和 top_k 等采样参数、保留思考（preserved thinking）以及推理强度，都可能显著改变模型行为。
- 上下文工程与 harness 本身：构成模型所处软件环境的技能（skills）、工具和 MCP 服务器。
- 通过微调或蒸馏调整模型权重：最难做到，因为它需要定义清晰的评测、精心整理的数据和真正的实验，但它能解锁某个细分领域，让小模型发挥出远超其规模的实力。
无论拉动哪个杠杆，都要把这个过程当作迭代循环。设计只隔离单一改动的实验，评估其影响，然后不断迭代，直到找到真正能改善评测结果的做法。让评测保持模块化，让实验保持简单。如果同时测试太多东西、改动太多变量，你永远无法在混杂的噪声中分离出真正有效的部分。想让上述适配迭代取得成效，最重要的就是上文所说的一套定义清晰的评测。
决策
与任何迁移一样，技术验证只是成功的一半。一旦证明 OSM 可以匹敌或超越你当前闭源方案的功能，你就需要把这些结果整理出来，向利益相关方说明“为什么”。
概述迁移到 OSM 所需的投入、存在哪些风险，以及投资回报率（ROI）是多少。
基于我们的经验，给出一些高层次的指导：
投入决定了过渡到 OSM 所需的实际工作量。harness 和工具链偶尔会有兼容性问题，但这一差距每天都在缩小。例如，我们提供的工具 togetherlink 只需简单安装，就能在任何 harness 中开始使用 OSM。请记录下为在规模化场景下充分利用 OSM 而需要做的所有集成或改动。
风险反映了采用新技术的传统风险：合规、规模、持续迁移、对工具的熟悉程度、对下游服务的影响。请把这些记录下来，并针对贵公司的具体需求加以应对。如果你选择使用托管提供商，其中大多数风险都由其代为处理。
如果你带着完善的评测走到这一阶段，这部分工作可以大大简化，不过你仍可以把它当作一个反馈回评估环节的循环。
ROI 可以根据评估阶段得出的量化数值来计算。每美元能生成多少 token？与闭源相比如何？我们看到，在某些情况下，客户转向开源后成本最高可降低 70%。质量方面同样可以这样做：质量与闭源相比如何？这将有助于向利益相关方说明你的 ROI。
理想情况下，风险、投入和 ROI 都明确之后，决策就应该很容易做出。到这一步，推广采用更多是教育问题，而不是技术壁垒。
上线生产
获得批准之后，迁移便开始了。如前所述，传统上迁移之后进入生产是一个漫长拖沓的过程。然而，对于从闭源过渡到 OSM，我们发现这其实是最轻松的步骤之一。
我们可以借鉴传统的迁移实践，盘点迁移的影响并制定路线图。其中大部分内容可以基于前面的投入和风险部分。会影响下游服务吗？如何让安全和合规团队批准一个模型？基于先前模型构建的工具或服务是否需要改动？这种转变也不必一步到位。金丝雀部署在我们的客户中取得了很大成功，可用于对照生产用例进行验证，从把 10% 的流量切到开源模型开始。
路线图包含采用 OSM 所需的全部步骤，应涵盖需要进行的所有安全/合规、技术变更或下游服务变更。不必在此感到畏惧，技术实现可能简单到只是换一个端点！
我们明白这只是一个非常简化的概述，但从本质上讲，我们已与最大的客户一起经历过这种过渡几十次，并坚信它远没有传统的技术迁移那么繁琐。
如果你正在经历类似的迁移，欢迎关注后续的博客，或有任何问题请联系 sales@together.ai。我们也非常欢迎你反馈这里可能遗漏了什么。祝构建愉快！