从闭源到开源模型：数周完成迁移的五阶段实战手册

从闭源到开源模型：数周完成迁移的五阶段实战手册 [@togethercompute](https://x.com/togethercompute) 团队 [@zainhas](https://x.com/zainhas) 分享了他们从闭源到开源模型的迁移方法论，之所以能在数周内完成，主要是因为技术栈已经解耦，网关、评估框架、工具链天然支持多模型切换，换模型在工程上可能就是换一个 endpoint。真正的瓶颈不在改代码，在于建立评估体系和组织决策。 # 五阶段方法论 1. Discover（筛选候选） · 先定义“为什么评”：明确用例、工作负载、流量的真实构成。没有全能冠军，只有匹配度。 · 公开榜单只做初筛（编码：FrontierCode / DeepSWE / Terminal Bench 4；Agent 与工具调用：τ-bench / Agent Arena；对话：LMArena；视觉：Vision Arena）。 · 关键提醒：不要只看分数，要看每任务经济学——token 消耗、所需步数、端到端耗时。一个分数略低但 token 和时间减半的模型，往往是更优选择。 · 亲手试：把代表性任务放进 playground，并区分失败原因到底是“模型不行”还是“外围 harness 不适配”。 · 出口标准：留下 2–3 个候选进入正式评估。 2. Evaluate（评估）—— 全文最重的部分 · 双轨评估：accuracy（模型能力：指令遵循、函数调用、视觉等）× performance（运行品质：成本与延迟，与回答质量无关）。 · 全文最有价值的方法论：用真实生产流量回放做评估。如果你已经在用闭源模型，你的流量就是最好的 benchmark，不需要自建数据集。这与 HPC、数据库领域传统的负载测试思路一脉相承。 · 没有数据也不阻塞：可按输入输出规模、缓存命中率估算，LiteLLM 等网关能补齐闭源厂商不提供的指标。 · 先定目标线（省钱？提速？质量持平？），重放流量过线即技术验证通过。 · 隐含的复利：评估基础设施建一次，未来切换任何新模型都能复用——这是持续红利。 3. Adapt（适配） · 逻辑起点：你的闭源方案沉淀了大量针对性调优，开源模型从未“见过”这些——评测不过 ≠ 模型是死路。 · 四级杠杆，按成本递增：① 改系统提示词；② 调推理参数（temperature、top\_k、reasoning effort 等）；③ 改上下文工程与 harness（工具、MCP、技能环境）；④ 微调/蒸馏——最难，需要成熟的评估和精调数据，但能解锁垂直领域、让小模型越级作战。 · 方法纪律：单变量迭代。同时改太多东西，永远无法归因什么在起作用。 4. Decide（决策） · 技术验证只是一半，另一半是把结果打包成利益相关方听得懂的“为什么”。 · 三件套：Effort（工作量，兼容性缺口每天在收窄，Together 的 togetherlink 之类的工具进一步降低门槛）、Risk（合规、规模、下游服务，托管商可消化大部分）、ROI（用评估数据量化：每美元 token 产出、质量对比）。 · 结论句很精辟：评估做扎实后，决策水到渠成——剩下的是教育问题，不是技术问题。 5. Production（上线） · 传统迁移最重的一步，这里反而最轻。 · 借用传统迁移的纪律：盘点影响面、拉路线图（安全合规审批、下游服务、工具改造）。 · 灰度发布：从 10% 流量切起，在真实生产中验证。 值得记住的三点经验 1. 你的生产流量就是最好的 benchmark，通用榜单做初筛，真实回放做终审。 2. 每任务成本比榜单分数更接近真实持有成本，token 消耗、步数、时延才是你真正付的钱。 3. 模型评测没通过时，先别急着淘汰它，“模型能力不足”和“harness 不适配”是两个完全不同的问题，后者可修。   Together AI@togethercompute [x.com/i/article/2100…](https://x.com/i/article/2100282486232428544) [🔗 View Quoted Tweet](https://x.com/togethercompute/status/2100284677835653629)