4 篇博文 含有标签「vendor-lock-in」

询问任何工程主管，他们是否被模型供应商锁定了，他们都会指向抽象层。“我们通过网关路由所有内容。更换供应商只是配置更改。”端点只有一行代码。Base URL 是一个环境变量。在纸面上，迁移只需要一个周二下午。

然后他们尝试了。他们将配置切换到不同的模型系列，集成测试依然通过，但生产环境却悄然崩溃。原本总能解析的 JSON 现在被包裹在 Markdown 代码块中。准确率曾达 94% 的分类器降到了 80% 出头。一个稳定运行了一年的提示词开始因为无人能复现的原因，在每 20 个请求中拒绝 1 个。端点在几秒钟内完成了切换，但行为并没有随之迁移。

这就是没人预料到的锁定。它不在你的合同或 SDK 中，而是在你的提示词（prompts）中——你的团队为了适应单一模型系列的特性，一次又一次地做出的数千个细微调整。你选的不是模型，而是与之“联姻”，而“婚前协议”就是你发布过的每一个提示词。

你最优秀的 AI 工程师能凭记忆背诵 Claude 的 XML 格式偏好。他们知道 Claude Opus 拒绝泛化隐式指令，知道少样本示例（few-shot examples）实际上会损害 o1 系列模型的性能，还知道在某些地区，Azure OpenAI 相比直接 API 会增加额外的 8 到 12 秒延迟。这种专业知识花了数月时间积累。它也代表了当今 AI 工程中最被低估的风险之一。

当供应商弃用某个模型或悄然改变行为时，这些知识并不会随之迁移。它会消失。那些围绕单一模型系列构建系统以及组织能力的团队，往往会以惨痛的方式发现这一点。

每个人都在讨论如何避免 LLM 供应商锁定。建议通常归结为"使用抽象层"——仿佛把 openai.chat.completions.create 换成 litellm.completion 就能解决问题。但事实并非如此。API 调用是最简单的部分。真正的锁定是隐形的：它存在于你的提示词、评估数据、工具调用假设，以及你不知不觉围绕特定行为设计的系统中。

供应商可移植性不是非黑即白的。它是一个连续谱系，大多数团队比他们认为的离可移植端更远。好消息是，实现真正可移植性的模式已经很成熟——只是比引入一个封装库需要更多的纪律性。

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

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