供应商锁定深度分析：导致更换 LLM 供应商变成 6 个月工程项目的七个耦合点

每一个交付 LLM 驱动功能的团队最终都会进行同样的对话：“如果我们需要更换供应商怎么办？”标准的回答——“我们只需要换一下 API 密钥”——揭示了对耦合实际存在位置的危险误解。在实践中，尝试进行供应商迁移的团队会发现，API 端点是他们最不需要担心的问题。真正的锁定隐藏在七个不同的耦合点中，每一个都能将一次“快速更换”变成一个耗时一个季度的项目。

迁移费用通常会消耗原始开发时间的 20–50%。那些将模型切换视为即插即用的企业团队，往往在面对损坏的输出、激增的 Token 成本以及需要数周才能诊断出的推理质量变化时束手无策。在需要迁移之前，了解这些耦合点在哪里，是受控过渡与紧急应对之间的本质区别。

1. 提示词语法和特殊 Token

最显而易见的耦合点也是最被低估的。每个供应商都开发了自己的提示词方言，而这些方言所编码的假设比格式偏好更为深刻。

OpenAI 模型对带有章节分隔符、强调标记和嵌套列表的 Markdown 结构提示词响应最好。Anthropic 的 Claude 系列在输入中使用 XML 标签划分不同部分时表现最佳。Google 的 Gemini 模型则在系统指令和多轮对话格式方面有自己的惯例。

这些并非表面上的差异。一个在一个供应商的评估套件中得分 92% 的提示词，在另一个供应商那里可能会降到 74%——这并不是因为第二个模型更差，而是因为提示词结构触发了不同的注意力模式。那些仅仅通过更改 API 端点来迁移提示词的团队会发现，每一个精心调整的提示词都需要系统性的重做。

真正的成本不在于重写提示词，而在于为每个重写的提示词重新运行整个评估套件，迭代新模型处理方式不同的边缘情况，并验证新提示词在每一个你关注的维度上都达到了同等水平。对于拥有数百个生产环境提示词的团队来说，单单这一项就可能耗时数周。

2. 工具调用模式（Schema）的差异

如果你的应用程序使用了函数调用（Function Calling）或工具使用，那么你就是针对特定供应商的模式进行构建的，而这些模式并不能直接转换。

OpenAI 使用带有 type: 'function' 包装器的 tools 数组。Anthropic 在顶层定义带有 input_schema 的工具。Google 的 Gemini 将所有内容包装在嵌套于 Tool 对象内的 FunctionDeclaration 对象中。当你观察每个供应商如何返回结果时，结构差异会进一步加剧：

• OpenAI 将函数参数作为 JSON 字符串返回，需要 JSON.parse()
• Anthropic 在 tool_use 内容块中直接返回解析后的对象
• Google 在 functionCall 部分中返回解析后的对象

除了结构差异外，模式约束的处理方式也大不相同。当工具模式使用不支持的属性时，OpenAI 会抛出明确的错误。Gemini 会默默忽略诸如字符串长度或数组最小值之类的约束。Anthropic 则能优雅地处理大多数约束。研究表明，兼容层可以将跨供应商的工具调用错误率从 15% 降低到 3%——这意味着如果没有兼容层，你在迁移时将面临 5 倍的错误率增长。

模型上下文协议（Model Context Protocol, MCP）正作为一种标准出现，有望减少这种耦合。OpenAI 和 Google 都已跟随 Anthropic 采用了该协议，且 OpenAI 已宣布弃用其 Assistants API，转而支持 MCP，并计划于 2026 年中期停止服务。但目前采用尚处于早期阶段，大多数生产系统都已经固化了多年来特定于供应商的工具模式。

3. 依赖分词器（Tokenizer）的分块

每个 LLM 都使用不同的分词器——一套将文本拆分为数字 ID 的不同规则。将同一句话输入 GPT-4o 和 Claude，你会得到不同的 Token 数量、不同的分块边界和不同的成本。

GPT 模型使用在字节层面运行的字节对编码（BPE）。其他模型则使用具有不同合并规则的 WordPiece 或字符级分词。这些差异比看起来更重要，因为你的整个 RAG 流水线都是建立在分词器假设之上的。

你的分块策略——你选择的大小、重叠窗口、拆分启发式方法——都是针对特定分词器的行为进行优化的。更换供应商后，这些分块不再与新模型的 Token 边界对齐。原本在上下文中可以轻松容纳的文档现在会溢出。原本捕获了完整语义单元的分块现在会在概念中间断开。

修复方法不仅仅是更新 Token 计数器。它意味着重新对整个文档库进行分块，使用新的分块大小重新测试检索质量，并可能重新调整你的重叠策略。对于 RAG 流水线中拥有数百万文档的团队来说，这是一项重大的基础设施工程。

4. 嵌入空间不兼容性

这就是供应商锁定变得真正痛苦的地方。每个嵌入模型都会创建自己独特的向量空间——来自一个模型的 768 维向量与来自另一个模型的 768 维向量之间没有任何意义上的关联，即使它们代表的是同一个概念。

你的向量索引针对之前的坐标系进行了优化，现在却在错误的空间中进行搜索。像 HNSW 和 IVF 这样的近似最近邻算法构建了专门针对当前嵌入几何结构优化的数据结构。当几何结构发生变化时，这些结构就会变得错位，检索质量会无声无息地下降——你不会收到错误提示，只会得到更差的结果。

更换嵌入供应商意味着需要重新嵌入你的整个语料库并完全重新索引。对于拥有数百万文档的组织来说，这是一个耗时数天的计算操作，可能耗资数千美元。在过渡期间，你要么运行双重索引（使基础设施成本翻倍），要么接受一段搜索质量下降的时期。

新兴的解决方案，如嵌入适配器（embedding adapters）——通过学习到的转换将一个模型的向量空间映射到另一个模型——在无需完全重新嵌入的情况下实现增量迁移方面展现了前景。关于跨模型向量数据库集成的学术研究已经证明了很高的召回率。但这些仍是尚不成熟的技术，大多数生产系统默认采用昂贵但可靠的完全重新索引方法。

5. 微调模型不可移植性

如果你通过供应商的 API 微调了模型，那么这些权重就属于该供应商的生态系统。OpenAI 的微调 API 为你提供的是模型端点，而不是模型权重。你无法提取模型学到的内容并将其应用于 Claude 或 Gemini 基础模型。

这是最绝对形式的锁定。你的微调数据集是可移植的，但训练投入——计算、超参数调优、迭代评估——必须在新供应商那里从头开始重复。而且由于不同的架构对相同的训练数据的反应不同，你甚至无法保证获得相同的质量结果。

带有 LoRA 适配器的开放权重模型提供了一种部分的逃避方案。由于 LoRA 在已知的基础模型之上产生小型、离散的适配器权重，因此你保留了完整的所有权。但这需要自托管基础设施，从而引入了其自身的复杂性。对于使用专有微调 API 的团队来说，锁定是现实存在的：你的模型改进是不可转让的。

战略意义很明确。投资于微调专有模型的每一美元都是增加你切换成本的一美元。预见到潜在迁移的团队应该考虑，其性能提升是否可以通过更好的提示词工程、检索增强或在开放权重模型上进行微调来实现。

6. 速率限制架构假设

你的应用程序并发模型、队列系统和重试逻辑都是围绕特定供应商的速率限制方案构建的。这些方案的差异会破坏架构假设。

Anthropic 将速率限制分为每分钟请求数 (RPM)、每分钟输入 Token 数 (ITPM) 和每分钟输出 Token 数 (OTPM)。OpenAI 使用统一的每分钟 Token 数 (TPM) 指标。这意味着针对 OpenAI 组合限制优化的分批策略（即将更多输入 Token 打包到更少的请求中）在 Anthropic 上无法直接转化，因为后者的输入和输出预算是独立的。

你的队列深度计算、熔断器阈值、自动扩缩容触发器——所有这些都编码了关于速率限制结构的假设。为了保持在 TPM 限制内而预先对文档进行分块，或者为了管理生成预算而序列化高输出请求的团队，会发现他们的吞吐量架构需要重新设计。

标头格式也不同。Anthropic 返回带有重置时间戳的 anthropic-ratelimit-requests-remaining。OpenAI 使用不同的标头名称和语义。你的重试中间件、背压信号、容量规划仪表盘——全都耦合到了特定的标头合约上。

7. 改变成本优化策略的计费模型差异

最后的耦合点是经济层面的。你的成本优化架构——路由规则、模型选择逻辑、缓存策略——都是针对特定供应商的定价模型进行调整的，而这些模型在结构上存在差异。

OpenAI 的提示词缓存对于超过 1,024 个 Token 的提示词是自动执行的。Anthropic 则需要显式的 cache_control 标头来指定缓存断点。如果你的应用程序是围绕自动缓存设计的，那么迁移到需要手动缓存管理的供应商意味着需要在整个代码库中加装缓存提示——否则就会失去缓存 Token 带来的 90% 成本削减。

批处理折扣也各不相同。OpenAI、Google 和 Mistral 都为异步批处理任务提供大约 50% 的折扣，但 API、延迟保证和任务管理界面各不相同。为一个供应商的语义构建的批处理流水线无法干净地移植到另一个供应商。

输出 Token 的成本通常是输入 Token 的 3–5 倍，但具体比例因供应商和模型层级而异。如果你的路由逻辑根据某个供应商的价格比例将冗长的任务定向到特定模型，那么在不同供应商的成本结构下，该逻辑会产生次优决策。使用智能路由（将每个请求匹配到成本最低且能力胜任的模型）的团队报告称节省了 60–90% 的成本，但这些路由规则建立在特定供应商的价格表之上，一旦你切换供应商，这些规则就会变得错误。

抽象层的问题

应对供应商锁定的自然反应是抽象化：像 LiteLLM、Portkey 和 LLM 网关这样的工具，它们承诺在不同供应商之间提供统一接口。这些工具确实很有价值 —— 它们负责处理 API 格式转换、提供自动故障转移，并为你提供跨供应商的可观测性。

但抽象层可能只解决了七个耦合点中的三个。它们处理提示词格式差异（部分）、工具调用模式转换以及速率限制标准化。它们并不能解决嵌入空间不兼容、微调模型的可移植性、依赖于分词器的分块，或者计费模式的差异。

诚恳的架构建议并不是 “使用抽象层，你就拥有了可移植性”。而是要了解你的应用程序有哪些耦合点，为你最看重的那些耦合点投入可移植性建设，并针对那些切换成本值得其性能收益的耦合点，接受有意识的锁定。

为可管理的锁定而构建

完全的供应商独立性既无法实现也不理想 —— 这意味着要放弃能带来实际价值的供应商特定优化。目标是实现可管理的锁定：清楚地知道你的耦合点在哪里，切换每个耦合点的成本是多少，并且在需要时有一个切实可行的迁移时间表。

首先根据这七个耦合点对你的应用程序进行审计。对于每一个点，请问：我们的耦合程度有多深，迁移需要什么，以及这种耦合是否提供了足够的价值来证明切换成本是合理的？有些耦合 —— 比如利用特定模型优势的经过精细调校的提示词 —— 是值得锁定的。而其他耦合 —— 比如硬编码的速率限制标头 —— 则是无论如何都应该被抽象掉的偶然复杂性。

能够成功应对供应商转型的团队并不是那些完全避免了锁定的团队。而是那些清楚地知道锁定存在于何处、对接受哪些耦合做出深思熟虑的选择、并保持足够的组织知识以在战略考量发生变化时执行迁移的团队。