2 篇博文 含有标签「vendor-strategy」

在过去六个月中，我审计过的每一个团队都声称自己是供应商无关的。但实际上没有一个团队能做到。在评估套件中得分最高的系统提示词之所以表现出色，是因为它倾向于单一供应商的分词器行为、JSON 模式协议、拒绝节奏以及停止序列处理 —— 而编写该提示词的团队甚至无法说出其中哪些偏差在起作用。当 CFO 询问为什么采购清单上更便宜的模型不能直接替换时，诚实的回答是：这需要两个工程师季度的提示词重新调优以及对每个评估进行完全的基准重设。这不仅仅是一个勾选项。它是一个季度的成本项。

一直困扰团队的心智模型是将供应商可移植性视为一次性的架构决策。你添加了一个抽象层，在配置中写了一个 model: 字段，以此自我庆贺，然后继续前进。一年后，当供应商提价、发布弃用通知，或者在你关注的某个类别上出现了一周糟糕的拒绝服务时，你发现那个抽象层只是一个围绕特定模型提示词的薄包装。你买到的可移植性是语法上的。而你真正需要的是行为上的可移植性，且行为上的可移植性在你停止支付的那一刻就会衰减。

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

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