LLM 供应商锁定的隐性迁移成本

大多数工程团队认为自己已经对 LLM 供应商锁定做了充分防护：用 LiteLLM 统一 API 调用、避免在托管平台上做微调、把原始数据存在自己的存储里。他们感到安全。然后某天提供商宣布弃用某模型，或竞争对手降价 40%，团队才发现，自己搭建的抽象层大概只处理了约 20% 的实际迁移成本。

另外 80% 藏在没人仔细看过的地方：围绕模型格式怪癖写成的系统提示词、按照某个模型的拒绝阈值校准的评估套件、一旦换模型就会失效的嵌入索引，以及建立在某种行为模式上却根本无法迁移的用户预期。

这篇文章就是那 80% 的地图。

API 兼容性只是容易的部分

工程师谈到供应商锁定，通常想到的是 API。OpenAI 用 /chat/completions，Anthropic 用 /messages，参数有些差异，工具/函数的 schema 也不同。这是大家都理解的表层。

LiteLLM、Portkey 这类统一网关工具，以及 LangChain 这类与提供商无关的 SDK，能很好地解决这一层问题。换个 model 参数，调整一下消息格式，代码就能跑起来。

但它们解决不了行为兼容性——而成本正藏在这里。

从 GPT-4o 切换到 Claude，或从 Anthropic 换到 Gemini，API 层面的改动一个下午就能搞定。下游的一切需要几周。

提示词可移植性问题

每个前沿模型都有提示词工程师摸索出的行为特征可以利用。Claude 对 XML 标签结构的响应格外好——用 <instructions>、<document>、<examples> 来分隔不同内容；GPT 模型对带标题的 Markdown 响应更好；Gemini 如果你明确要求，往往会给出结构化推理。

这些不只是风格差异，在复杂提示词中会成倍放大：

• 一个针对 Claude XML 解析调优的 2000 token 系统提示词，直接扔进 GPT-4o 后效果会明显变差——不是因为 GPT-4o 不能理解指令，而是结构暗示错位了。
• 利用 Claude 倾向简洁特点写成的提示词，在 GPT 模型上会产生意外冗长的输出。
• 在 GPT-4o 上可靠运行的 JSON 提取提示词（该模型天然偏向 JSON），换到没有这种偏好的模型上则需要显式强化指令。

这些问题在快速 API 测试中根本不会暴露，而是在 p5 失败案例中出现：边缘输入、长文档、模糊查询。在演示中看起来干净的模型切换，在生产环境的尾部会大量失准。

可持续的提示词模式——清晰的目标陈述、明确的输出规格、展示预期行为的少样本示例——确实可以跨模型迁移。但大多数生产提示词并非如此构建，而是迭代积累了数月针对特定模型的调整。把可移植的逻辑从模型专属调优中剥离出来，不是重构，而是重写。

你的评估套件在衡量错误的模型

自定义评估套件是第二个隐形锁定层，而且可以说是最危险的，因为团队太信任它了。

一个维护良好的评估套件感觉像是模型质量的客观仲裁者。当提供商 B 在公开基准上优于提供商 A 时，你跑自己的评估，却看到提供商 A 赢了。这不是矛盾——这是信号，说明你的评估在测试模型特定行为，而不是业务需求。

导致评估锁定的常见模式：

基于格式的断言。 检查"95% 的情况下返回 JSON"的评估，衡量的是 GPT-4o 的默认输出倾向，而不是你的实际需求。换到格式默认值不同的模型时，评估失败——但如果你加一条格式指令，产品可能完全没问题。

经过校准的阈值。 团队设置"分类任务准确率 > 87%"这样的阈值，是通过观察当前模型的表现得出的。这些阈值编码了一个模型的性能区间，而非独立标准。更好的模型可能得 91%，或者 84%，但有你的阈值无法区分的不同失败模式。

对拒绝敏感的测试用例。 如果你的评估包含接近当前模型拒绝边界的边缘案例，换提供商后，这些案例的通过/失败结果会立即改变。这是否算回归，完全取决于你的使用场景实际需要哪一侧。

修复方法不是写更多评估，而是从用户结果和业务需求出发设计评估，而不是观察当前模型的行为再把它当成规格。

嵌入锁定：没人预算的重建工作

在所有迁移成本类别中，嵌入模型锁定结构最清晰，也最容易被系统性低估。

每个嵌入模型都创建自己的向量空间。OpenAI text-embedding-3-large 生成的 1536 维向量，与 Cohere embed-english-v3.0 生成的 1536 维向量之间，即使编码同一句话，也没有任何有意义的几何关系。这两个空间在拓扑上毫不相关。

切换嵌入提供商需要：

1. 全量语料重新嵌入。 检索索引中的每一份文档都必须通过新模型重新处理。对于有 5000 万文档的系统，这意味着数万美元的计算费用和数天的流水线时间。

2. 向量索引重建。 向量数据库中的 HNSW 图、IVF 分区或其他索引结构，都是针对旧嵌入分布优化的，必须基于新向量从头重建。

3. 零停机编排。 无法就地替换，需要并行运行两个索引——在构建新索引时继续用旧索引响应查询，然后切换。这是复杂的运维工作。

4. 检索质量重新验证。 你的检索基准是基于旧模型的语义分组开发的，切换后需要重新验证搜索质量是否保持或改善。

使用向量数据库 collection alias 的团队——应用引用语义名称而非特定 collection 标识符——重建完成后可以秒级切换。硬编码 collection 标识符的团队，在重建成本之上还要承担额外的迁移工作。

实际影响：对待嵌入模型选择，要像对待主数据库选择一样慎重。这不是随便可以换的基础设施。

拒绝边界塑造用户行为

一种讨论较少但对产品至关重要的锁定形式是拒绝策略。前沿模型在划定边界上差异显著：

Anthropic Claude 通过 Constitutional AI 训练，具有可预测、一致的拒绝行为；OpenAI 的模型在边缘请求上更倾向于提供替代方案而非直接拒绝；Google Gemini 模型在不同版本间差异较大——有分析发现某些内容类别的满足率在主要版本之间从 33% 降至 7%。

对于内容相关应用——写作工具、客服机器人、研究助手——这些差异在演示中看不出来，在生产中却看得见。一个每天处理 10000 次查询的客服智能体，如果模型切换后拒绝阈值哪怕只是略微偏移，每天就会拒绝数百条合法查询。

遇到更多拒绝的用户不会提工单说"拒绝率上升了"，他们只会放弃任务。会话完成率下降，支持量上升。根本原因在几周后才会出现在使用分析中，而此时因果关系已经很难建立。

分词器税

一个会在其他类别上叠加放大的微妙成本：各提供商的分词器不同，这些差异影响成本估算、提示词长度计算和上下文窗口规划。

同样的输入文本，在 OpenAI 的 tiktoken 和 Anthropic 的分词器上会产生不同的 token 数。Anthropic 的分词器对同等文本往往产生更多 token，这意味着：

• 你的上下文窗口规划会出错。在 GPT-4o 上设计为在 4096 token 以内的提示词，在 Claude 的分词器上可能超出限制。
• 你的成本估算会偏差。如果你期望在同等 token 数下成本相当，分词器差异会悄悄抬高账单。
• 速率限制行为不同。基于 token 的速率限制（每分钟 token 数）与分词器效率交互，即使请求模式不变，峰值负载行为也会改变。

这不是迁移的拦路虎，但它是那种以神秘生产异常形式出现的问题——在测试中正常的提示词开始不一致地被截断，或成本比预期高 15%——如果不知道往哪里找，诊断起来很费时间。

模型切换后真正能留下来的东西

不是所有东西都需要重写。有些模式确实可以跨提供商移植：

清晰的目标导向指令。 围绕明确任务目标构建的提示词（"你正在审查以下代码变更的安全漏洞，请识别……"）比围绕规避模型弱点构建的提示词（"永远不要加前言，直接回答……"）移植性更好。

少样本示例。 通过例子展示预期行为，比通过指令解释更有可移植性。大多数前沿模型都能高效地从示例中提取模式。

明确的输出 schema。 指定预期输出的确切结构——包括类型、必填字段和示例——比依赖模型的默认输出倾向更能经受提供商切换的考验。

角色框架。 角色指令（"你是一名审查 PR 的高级工程师"）足够抽象，可以干净地移植。

业务逻辑放在数据里，而不是提示词里。 移植性最好的系统设计，是把业务规则放入结构化上下文——查找表、配置、检索到的文档——而不是编码进模型可能以不同方式解读的提示词语言中。

真正有效的缓解措施

抽象层方法（LiteLLM、与提供商无关的 SDK）解决了 API 表面的问题，这是真实存在的，但也是浅层的。更深层的缓解需要更早做出架构决策：

拥有你的数据。 训练数据、评估集、微调数据集和提示词库，应该存放在你控制的版本化仓库中。当你在托管平台上做微调而权重存放在对方基础设施里时，你已经失去了在其他地方复现该能力的能力。

为你的任务设计评估，而不是为你的模型。 从用户视角写评估用例，表达什么是正确行为，不要参照当前模型的行为。这更难、更慢，但这是切换提供商时能给你真实信号的唯一评估方式。

对提示词进行版本控制。 把提示词当作一等软件制品，有版本历史、变更审查和回归测试。这种纪律在任何模型过渡期间都会带来回报——你可以追踪行为何时改变以及为什么。

提前规划嵌入迁移成本。 在选择嵌入模型之前，先构建迁移路径：在向量数据库中使用 collection alias、构建重索引流水线、建立不依赖于哪个模型生成嵌入的检索质量基准。

维护一套兼容性测试框架。 保留一套轻量级测试用例，可以对任何提供商运行，验证基本行为：JSON 格式合规性、边缘案例的拒绝行为、输出长度分布。这不是为了取代你的评估套件，而是在切换引入意外行为变化时给你一个早期预警系统。

弃用时间线不由你说了算

有一个现实团队总是低估：你最终都会切换提供商，不管你是否主动选择。

OpenAI 在 2026 年下线了 GPT-4o API，提前约 12 个月通知；Anthropic 在 2025 年 8 月弃用了 Claude 3.5 Sonnet。大多数前沿模型在被弃用之前的有效生产寿命是 12 到 18 个月。

这意味着问题不是"我们是否应该保持提供商可移植性？"，而是"我们是按自己的节奏吸收迁移成本，还是按提供商的节奏？"把第一次迁移作为构建可移植基础设施机会的团队，支付一次性架构成本，之后的迁移几天内就能完成。被动响应迁移的团队，在每个弃用周期都要支付全额迁移成本。

工程工作量其实是一样的，区别在于你是否能掌控它发生的时间。

实际成本

对于已经运行一年的生产系统，更换 LLM 提供商的成本大致是：

• 40–70% 的工作量在数据准备和评估重建
• 20–30% 在提示词移植和验证
• 10–20% 在基础设施重配置和运维工作

最后一类是 LiteLLM 能处理的。前两类无论你用什么抽象层都得自己扛。

对于一名全职高级工程师管理的系统，假设代码库结构清晰、评估存在，这大约是 4 到 6 周的专注工作。对于积累了提示词债务、存在未记录行为或缺少评估的系统——这描述的是大多数生产 AI 系统——时间会更长。

与提供商无关的抽象层值得使用，它们处理了真实的复杂性。但要把它们当作工具箱，而不是保障。真正重要的可移植性，在于你如何设计提示词、构建评估、管理嵌入基础设施——这些没有任何库能替你做到。