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 标识符的团队，在重建成本之上还要承担额外的迁移工作。

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

拒绝边界塑造用户行为

加载中…