2 篇博文 含有标签「portability」

一个团队在 GPT-4 上构建了一个生产环境功能。几个月后，出于成本考虑，他们决定评估 Claude。他们花了两周时间进行“迁移”——但核心的 API 替换只花了一个下午。剩下的十天都花在了修复损坏的系统提示词（system prompts）、重新测试拒绝服务的边缘情况、调试由于意外文本而崩溃的 JSON 解析器，以及重新调整在不同供应商之间表现迥异的工具调用模式（tool-calling schemas）。原本以为只是简单的连接器更换，结果迁移预算膨胀成了多层重构。

这就是现实中的 LLM 供应商锁定问题。那些受挫的团队并不是因为选错了供应商——而是因为他们没有意识到锁定存在于多个维度，且每个维度都有不同的风险画像。

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

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