进入 2026 年后，认真考虑迁移出 OpenAI 的团队明显变多了。开放权重模型在日常生产任务上的质量已经很难与头部模型区分开来，公开单价更低，而权重本身可以下载这一点，把与厂商的关系从依赖变成了选择。

但这并不意味着切换是免费的。API 调用本身几乎一模一样，真正要干活的是它周围的一切。本文讲清楚:哪些东西能原样搬过去,哪些会悄悄出问题,怎样设计一次有意义的比较,以及什么时候留在原地才是正确答案。

先把预期对齐。 换厂商就是换一个基础 URL、一个模型名、一份凭据。但要拿回同样的输出质量,那是以天为单位计的提示词工程。给一个范围明确的功能预留一到三周。任何假设可以即时替换的估算,都是乐观估算。

哪些东西能原样搬过去

比你想的多,这也正是值得考虑的原因。

调用格式能搬。 认真做开放权重的服务方现在基本都提供兼容 OpenAI 约定的接口,你现有的客户端库、请求结构和流式处理代码通常无需改动即可运行。比如 Kimi K3 同时提供 OpenAI 兼容和 Anthropic 兼容接口,细节见 Kimi K3 API 指南 。

周边架构整体能搬。 保管凭据的代理层、队列、重试逻辑、按用户计量、日志,这些都不关心背后是哪个模型。如果这一层做得干净,切换真的就是改配置。反过来,如果你把厂商 SDK 直接铺满了整个代码库,现在就是发现这件事的时刻。

检索层能搬。 向量化、向量库和分块策略与生成模型无关,不过如果新模型的上下文窗口差异很大,分块大小值得重新审视。

哪些东西会悄悄出问题

失败模式足够一致,可以提前规划。

提示词无法移植。 这是最大的一项。提示词往往是在不自觉中针对某个模型的习惯调出来的。原样搬过去,你会得到技术上正确、风格却跑偏的输出:啰嗦程度不同、格式不同、愿不愿意说"我不知道"也不同。请做好重写系统提示词的准备,这就是迁移工作的主体。

结构化输出的行为不一样。 如果你依赖受模式约束的响应,要确认新服务方是怎么强制的。有的在解码层保证符合,有的只是礼貌地要求、大多数时候会遵守。按"有保证"写出来的代码,迟早会碰到一个畸形字段。

工具调用差在细节。 调用格式已经标准化,但可靠性、连续调用多个工具的意愿、以及没有工具匹配时的行为都不一样。在智能体式负载里最痛,因为误差会跨步骤累积。

推理行为和计费方式不同。 有些模型始终推理,并把推理 token 计为输出。一个默认开启推理且默认强度拉满的模型,即使公开单价更低,单次请求成本也可能高于你刚离开的头部模型。在测算节省之前,先把默认值读一遍。

安全边界和拒答位置会移动。 每家划线的位置不同。当前模型能处理的内容可能被拒答,反之亦然。如果你的应用涉及医疗、法律或金融,请明确测试这一点,而不是等客户来告诉你。

设计一次有意义的比较

厂商的基准测试回答不了你的问题。自己做一个小的评测集来回答。

从生产流量里收集 30 到 100 条真实输入,要覆盖完整范围、包含棘手样例,并为每一条记录下你认可的正确输出。这就是我们在 OpenAI API 集成指南 里描述的同一套评测体系,如果已经有了,比较只需要半天。

两个模型都要用各自调好的提示词跑。拿为 A 模型优化的提示词去跑 B 模型,那不是比较,只是再次证明提示词无法移植。

测四件事:按你标准判定的输出质量、包含推理 token 的单次请求总成本、用户真实体验的分位数延迟(不是均值)、以及失败模式。最后一项最重要也最常被漏掉。一个平均质量略低但从不产生畸形输出的模型,对自动化流水线可能是更好的选择。

然后跑影子部署。把线上流量复制一份发给候选模型但不使用其响应,用一周的真实使用做对比。合成评测会漏掉长尾,生产流量不会。

迁移出 OpenAI 后,节省在哪里是真的

先算账,再动工程,因为答案随负载差异极大。

大批量常规任务上,节省真实且可观。 分类、抽取、摘要、路由都属于这一类。它们几乎不需要头部级能力,又持续不断地跑,单 token 价差会一路累积。这是最有力的理由,通常仅凭这一条就足以支撑迁移。

中等规模的交互功能上,节省真实但有限。 每月处理几千次会话的客服助手,用哪家花的钱都不多,工程时间可能超过一整年的节省额。

如果推理 token 计为输出且新模型每次调用都推理,节省可能是幻觉。 请用你真实的提示词长度建模,而不是公开单价。

还有一类节省与钱无关。 可下载的权重是一个退出选项。当服务方停掉你依赖的模型、在合同中途改价、或施加不合适的速率限制时,“有地方可去"本身是有价值的。真正行使这个选项要花多少钱,见自建 Kimi K3 指南 ,它比多数团队预想的要高。

答案通常是"两个都要”

把这件事框定为一次切换,本身就是错的。回报最好的团队会在同一个接口后面同时跑多个模型。

按任务路由。把大批量常规工作发给能通过评测的最便宜模型;把长上下文和智能体式工作发给最擅长它的模型;再保留一个头部模型,用于那一小部分你想要最强答案、价格不是决定因素的请求。

也可以按数据分级路由。含有不得离开辖区材料的请求走自建模型,其余走托管 API。因为接口相同,应用层根本不需要知道请求走了哪条路。

这要求抽象层在你需要它之前就已经存在。先建好这道边界,厂商选择就变成配置项而不是项目,未来的切换也会因此变便宜。预算全景可参考 AI 集成成本指南 ,它把建设成本和运行成本分开算。

什么时候应该留在原地

比迁移类文章暗示的要多得多。

如果量小,就留下。工程成本收不回来,那些时间花在功能本身更值。

如果你确实依赖某个厂商特有能力,并且已经验证(而不是假设)替代方案没有它,就留下。下结论之前先测试。

如果这是安全敏感的应用,而当前服务方的边界经过真实测试确实符合要求,就留下。重建这份信任也是有成本的。

如果你还没有评测体系,现在就留下。没有评测的切换意味着,直到客户告诉你,你才知道质量掉了。先把体系建起来,无论最后怎么决定它都有用。

让比较被正确地跑一遍

Mecanik 在人工智能集成服务 中承接多厂商大模型工作:路由层、评测体系、针对目标模型重写提示词,以及告诉你生产环境真实表现的影子部署。

在你做出承诺之前,我们会把你自己的流量跑过多个服务方,把质量、成本和延迟并排摆出来,包括那些诚实建议就是"别动"的情况。如果你现有的集成把某一家厂商硬编码在整个代码库里,我们的 OpenAI API 集成指南 讲了那一层代理,它能让这次以及今后每一次切换都便宜下来。

告诉我们当前的月度支出规模和这个功能在做什么,我们会告诉你这次迁移值不值这份工程投入。

相关文章: 微调 vs RAG vs 提示词：各自的真实成本 、构建 OpenAI API 聊天机器人：2026 指南 。

常见问题

从 OpenAI 迁到开放权重模型难吗? API 调用本身很简单,多数服务方提供 OpenAI 兼容接口,改一个基础 URL、模型名和凭据即可。真正的工作是重写那些针对单一模型习惯调优过的提示词,并重新验证结构化输出和工具调用。给一个范围明确的功能预留一到三周。

换成开放权重模型能省钱吗? 取决于负载。分类、抽取、摘要这类大批量常规任务通常节省显著;而小规模交互功能往往收不回工程成本。要留意那些始终推理并把推理 token 计为输出的模型,它们可能抵消掉更低的公开单价。

我现有的提示词在别的模型上还能用吗? 不重写通常不行。提示词是针对某个模型的啰嗦程度、格式和拒答倾向调出来的,同一段提示词换个模型会得到技术上正确但风格跑偏的输出。比较之前请按模型分别调优。

怎样公平地比较两个大模型? 用 30 到 100 条已知正确输出的真实输入建评测集,为每个模型单独调优提示词,然后比较质量、含推理 token 的单次请求成本、真实分位数延迟以及失败模式,再用线上流量跑一次影子部署。

该用一家服务方还是多家? 在同一个接口后面用多家。大批量常规工作走能通过评测的最便宜模型,长上下文和智能体式工作走最擅长的模型,再保留一个头部模型给需要最强答案的少数请求。这样未来切换也更便宜。