每家大模型 API 服务商都会拿同一件事来证明换供应商很容易：如今几乎所有厂商都支持“OpenAI 兼容”的聊天补全（chat completions）端点。把 SDK 指向新的 base URL，换上新的 API 密钥，事情就办完了，对吧？我们的《将 AI 云端推理迁离前沿模型公司》一文，就完整走了一遍这样的切换：新 base URL、新凭证、新模型名，并展示了实际运行效果。这话没错，但也只到此为止。传输层确实可移植，而它恰恰是唯一可移植的部分。
生产系统架在这个端点之上的一切，其实都在悄然对齐某个特定行为。提示词的措辞、输出解析、重试逻辑、缓存设计、成本估算，全都按你起步时选定的模型与供应商组合调优过。换供应商时要把这些统统重新校准，是一项实打实的工程，不是改改配置就能完事的。其中一部分校准针对的是模型本身，而非托管模型的供应商。这个区别在后文讨论“以开放权重模型作为可移植性策略”时会变得很关键。但也有相当一部分是供应商特有的：服务栈如何实现 JSON 模式、高负载时返回什么错误码、缓存怎么计价。这两类加在一起，构成了同样实打实的迁移成本。
本文依据各大推理服务商当前公开的文档，逐一梳理这些锁定究竟藏在哪里；同时坦率分析了合同层面的因素（事实证明它没有人们想象的那么重要），给出了一套围绕锁定进行架构设计的框架，并论证了在什么情况下接受一定程度的锁定反而是正确的工程决策。
注意：各家服务商的文档、定价和模型阵容更新得很勤，所以下文出现的每个具体数字都只能当作快照看待，而非长期参考。所有数据均注明出处并附有链接，来源页面标有日期的也一并注明；完整来源清单见文末。在真实决策中依据任何数字之前，请先核对原始来源。
核心要点：
- “OpenAI 兼容”只规范了传输格式。架在其之上的一切——提示词措辞、错误处理、缓存、成本估算——都是按某一家供应商的特定行为校准的，而这些校准才是真正迁移成本的所在。
- 锁定分布在六个层面：提示词校准、输出格式假设、错误处理与重试、缓存架构、成本优化以及运维工具。
- 各家对结构化输出的保证差别很大：OpenAI 的 strict 模式总能产出合法 JSON；Anthropic 的实现则在截断和预填充等场景存在文档明示的例外；Together.ai 和 Fireworks 则要求你在提示词里再写一遍 schema。
- 各家提供商的提示词缓存规则差异很大，针对某家缓存调优过的提示词，换到另一家往往表现更差。Anthropic 对缓存写入收取额外费用，默认 TTL 也较短；OpenAI 的缓存基本是自动的；Google 则额外收一笔其他提供商都没有的存储费。
- 两个按 token 单价相同的模型，实际花费可能相差悬殊。最大的两个原因是分词器的差异，以及不可见的推理 token——后者按输出计费，调用方却根本看不到。
- 就算弃用通知给得再宽裕，如果你的提示词和重试逻辑都是按该提供商的行为调校的，也无济于事。合同上的自由与实际可迁移性是两回事。
- OpenAI 和 Anthropic 公布的弃用与价格变动通知政策，比几家以“无锁定”为卖点的提供商还要详细。在这个细分问题上，最常与集中度风险挂钩的厂商反而最为透明。
- 对抗锁定，回报最高的投入是自动化评估套件，而不是抽象层。网关只应负责鉴权、传输和日志；把提示词逻辑抽象出来，往往比维护各提供商的专用版本成本更高、输出质量更差。
锁定效应藏身的六个层面
所谓“OpenAI 兼容”，大多只是描述请求和响应的形态，再加上鉴权头、流式传输等共享语义的粗略约定。各家提供商忠实实现的只是这个接口面的不同部分；至于请求抵达模型之后会发生什么、响应到达后你的代码需要做哪些处理，这些约定几乎都没讲清楚。锁定正是在这道缝隙里逐渐累积的，它分布在六个层面上。
提示词校准
提示词的调优——无论是有意为之，还是反复试错摸索出来的——针对的始终是某个特定模型的“脾气”：它执行格式指令有多死板、遇到含糊的请求会怎么应对、拒答的边界又划在哪里。同样的提示词换个模型来跑，输出分布就会随之改变。哪怕名义上还是“同一个”开放权重模型，只要新服务商采用不同的量化方案、换用别的推理引擎，或者引入投机解码（speculative decoding）之类的推理优化，输出分布照样会变。这些因素本身就能改变输出，与客户端可控的 temperature、top_p 等设置无关。更换服务商意味着要把评估套件对每一条生产环境提示词重新跑一遍，出现退化的还得重新调优。对一个维护着 40 条生产提示词的团队来说，这绝不是一下午就能搞定的事。按粗略的经验估计（并非实测基准数据）：为每条提示词搭建或重跑自动化评估、人工审查输出、再调整措辞，往往要花上几天到几周。实际耗时很大程度上取决于现有评估体系够不够严格，以及第一轮评估中会有多少条提示词过不了关。
输出格式假设
每家服务商都宣称支持结构化输出，但各家给出的保证和故障模式各不相同，而这些差异恰恰是解析器在意的。一篇即插即用型 OpenAI 兼容 API 的横向对比从实测角度印证了同样的结论：基础的聊天补全在所有受测服务商那里都能跑通，真正出现兼容性问题的是工具调用和流式传输的边缘场景。兼容性是一条光谱，不是非黑即白的开关。
OpenAI 的response_format 配合 json_schema 与 strict: true，按官方文档的说法能始终生成符合 schema 的 JSON，不过 schema 本身存在上限（最多 5,000 个对象属性，合计 120,000 字符——这一上限在 2025 年从原本小得多的限额上调而来）。较早的 json_object 模式只保证输出合法的 JSON，并不保证符合 schema，OpenAI 如今已不建议使用。
Anthropic 的 Claude API 也有一个与之类似的结构化输出功能（结构化输出，即 output_config.format），它建立在约束解码之上，而不是靠在提示词里恳求模型“请返回 JSON”。但这份保证存在文档明确记载的例外：当 stop_reason: "max_tokens" 触发截断时，输出仍可能是无效 JSON；枚举值的大小写没有保证；此外该功能与引用和消息预填充不兼容——而正在迁移的团队可能恰恰依赖这两项特性。
Together.ai 和 Fireworks AI 都支持基于 schema 约束的 JSON 模式，但两家厂商各自的文档都说明，仅通过 response_format 传入 schema 还不够，你还必须在提示词文本里把 schema 再写一遍。Fireworks 和 Together 都明确指出，“模型并不会自动‘看到’ schema”。这只是两家厂商在文档表述方式上的差异，并不是已被证实的可靠性差别。不过，如果解析器是按“OpenAI 会强制保证格式”这一假设构建的，那么在这里就可能需要额外的校验——而这些校验在 OpenAI 上纯属冗余。
工具调用在结构层面的分歧更大。OpenAI、Together 和 Fireworks 把工具调用参数以 JSON 编码字符串的形式返回，客户端必须自行解析；Anthropic 返回的则是已解析好的 JSON 对象，并且强制执行一条其他家都没有的严格消息顺序规则：工具结果必须紧跟在工具调用之后，中间不能有任何文本。按 OpenAI 较宽松的顺序约定编写的代码，要想跑在 Claude 上，需要的是实质性改动，而不是改个字段名那么简单。
finish_reason（OpenAI 的叫法）和 stop_reason（Anthropic 的叫法）同样存在分歧。OpenAI、Together、Fireworks 以及 DigitalOcean 的 OpenAI 兼容端点，都把“自然停止”和“命中停止序列”合并为同一个值 stop；Anthropic 则将其拆分为 end_turn 和 stop_sequence——这两个值携带的信息不同，而不只是名称不同。另外，content_filter 出现在 OpenAI 和 DigitalOcean 的枚举中，但文档表明 Together 和 Fireworks 的枚举里并没有它，因此为其中一家编写的分支逻辑，放到另一家上会悄无声息地永不触发。
错误处理与重试逻辑
针对某一家服务商的故障模式调校好的重试逻辑，换到另一家身上可能就会失灵：各家的错误分类并不对齐，而且同一个状态码下的不同错误，也不该用同一种方式重试。OpenAI 的文档记录了同一 429 状态码下两种表述截然不同的响应：一种表示请求频率过快，适合配合退避策略重试；另一种表示账单配额已超限，无论重试多少次都不会自行恢复。Anthropic 用 HTTP 529 表示“全体用户过载”，这个状态码有别于 429；其官方文档还指出，在极少数情况下，容量压力仍可能通过另一套加速限制机制以 429 的形式出现，也就是说 Anthropic 实际上运行着一套两级限流模型。Together.ai 的文档把边界划得清清楚楚：429 表示调用方超出了自身限额，503 则是平台侧的容量故障，责任不在调用方。Fireworks 的错误码划分得更为细致，包括用 502 表示“上游服务器返回了无效响应”；Fireworks 同时提醒，即使守住速率限制，请求也不保证一定成功，因为 503 “服务过载”仍可能出现。如果重试策略把所有 429 一律视为可重试，或者把所有 5xx 一概等同视之，那么上述情形中至少有一种会处理出错。
限流响应头同样没有统一标准。OpenAI 用的是 x-ratelimit-remaining-requests 和 x-ratelimit-remaining-tokens；Anthropic 用的是 anthropic-ratelimit-requests-remaining，还附带一个 retry-after 头；DigitalOcean 的响应头则干脆去掉了 x- 前缀（ratelimit-remaining、retry-after）。不过，retry-after 这个头只在触发突发限流的错误响应中才出现，并非每次响应都会携带。很多团队从不直接接触这些响应头——SDK 或 API 网关早已替他们完成了归一化，这种情况下各家差异不会带来任何成本。真正要为此付出迁移工作的，只有那些编写或维护归一化层的人，以及在没有归一化层的情况下直接解析响应头的团队。
缓存架构
各家供应商的提示词缓存定价机制差异不小：针对某一家缓存机制优化过的提示词结构，换到另一家那里往往效果明显打折扣——虽说算不上有害，但确实不太划算。
Anthropic 的缓存机制是显式的：每个请求最多可设置四个 cache_control 断点，默认 TTL 为五分钟且每次命中都会刷新（另有付费的一小时档位）；写入需加收 25% 的溢价（一小时档位为 100%），读取则可享受 90% 的折扣。可缓存前缀的最低 token 数从最新型号的 512 到某些其他型号的 4,096 不等，而且与模型发布顺序没有清晰的对应关系，所以最好专门查一下你所用的具体型号，别想当然。
OpenAI 的缓存是自动开启的，对 GPT-5.6 之前的模型写入免费，前提是前缀至少要有 1,024 个 token。保留时长分两种形态：较早的内存缓存只能维持 5 到 10 分钟；另一种是 24 小时档——如今在新模型上，这已是唯一选项。折扣幅度从老一代模型系列的约 50% 到最新模型的约 90% 不等，同样是缓存机制，调用的 OpenAI 模型不同，经济账也大不一样。Microsoft 的 Azure OpenAI 文档还提到，GPT-5.6 及之后的模型现在开始对缓存写入计费，这与 OpenAI 一贯“写入免费”的口碑相悖——不过这一说法仅在 Azure 上得到确认，并未对照 OpenAI 官方文档独立核实。
Google 的 Gemini 缓存则完全是第三种形态：既有自动的“隐式”缓存（费用没有任何保证），也有手动的“显式”缓存——后者能确保输入价格直降约 90%，而且与文中其他厂商都不同，Gemini 还要单独收存储费，按缓存存续的每小时、每百万 token 计价。
Together.ai 和 Fireworks 同样是自动缓存，没有开关可调，但与上面三家不同，两家都没公布固定的 TTL 或最小前缀要求。Together 自己的文档也承认其 serverless 缓存“尽力而为、存活期短”，相形之下透明度明显不足。
以上种种，都不能直接回答缓存对你的工作负载是否划算——归根结底这是一道盈亏平衡题：你的前缀是否足够稳定？请求是否来得足够密集，足以赚回写入缓存付出的成本？我们的提示词缓存文章一步步算清了这笔账，其中一项实测表明：只要在提示词开头放一个时间戳，缓存命中率就会从 98% 跌到不足 1%。另外，把请求原样转发给 Anthropic 或 OpenAI 托管模型的平台，会直接继承该模型自身的缓存计费规则，而不是另立一套；而像 OpenRouter 这类路由网关，或自托管的 LiteLLM 代理，则会在其上叠加自己的重试、回退和缓存逻辑——这一层依赖，迁移时同样必须计入。
成本优化校准
两个每 token 单价看起来一模一样的模型，跑同样的工作负载，实际花费却可能相差悬殊。分词器差异和不可见的推理 token 是其中证据最扎实、最常被引用的两个原因，但原因并不止这两个。输出长度、单次请求动用了多少推理算力、系统提示词的体量，以及简单按每条消息估算 token 时根本体现不出来的工具调用开销——这些因素都独立于每 token 的标称费率之外，实实在在地左右着最终账单。
具体到分词器，差别绝非小事。OpenAI 在自家模型系列中使用了多种不同的命名编码（cl100k_base、o200k_base 以及更早的几种），因此同一段文本即使都在同一家厂商的模型家族内，切分出的 token 数也不一样。Anthropic 自己的文档明确指出，其新版分词器（从 Claude Opus 4.7 起启用）处理同样的输入文本，产出的 token 数比旧版多出约 30%。如果你按 token 数量而不是按内容体量来估算迁移成本，这一点就必须掂量。Anthropic 官方的工程指南还提醒不要用 OpenAI 的 tiktoken 库来估算 Claude 的 token 数：普通文本会被低估 15% 到 20%，代码被低估得更多。
推理模型还会对调用方永远看不到的 token 收费。OpenAI 的文档写得明明白白：推理 token 虽然在 API 响应中不可见，却“会占用模型上下文窗口的空间，并按输出 token 计费”。文档同时警告，响应可能在产出任何可见内容之前就被截断——也就是说，调用方可能为输入和推理 token 付了钱，却什么结果都没拿到。Together.ai 的文档在其自家平台上对推理模型的计费也指出了同样的问题，只是具体表述和所适用的模型家族有所不同，因此别想当然地认为两边一致，最好先查一下具体模型页面。这倒不算刻意隐瞒的隐形收费，但在为迁移做预算时很容易被漏掉。一个单看 token 数量似乎完全负担得起的工作负载，最终可能把预算中相当大且难以预测的一部分，花在这些看不见的推理 token 上。
输出 token 值得在这里单独拎出来说：只按输入价格比较各家服务商时，它最容易被低估。我们深入分析过 Llama 3.3 70B 的输出 token 定价，发现在大多数模型上，输出 token 的价格是输入 token 的 2.2 至 5.4 倍，而且与输入 token 不同，输出 token 每个都要串行生成，没法靠缓存省掉。落到单个请求（而非会话平均值）的粒度上，这笔溢价足以扭转"哪个模型更便宜"的结论——而这恰恰是逐 token 标价对比最容易漏掉的地方。
运维工具
最不起眼的一层，实际黏性却名列前茅：仪表盘、可观测性集成、用量归因，还有围绕特定服务商的控制台和账单导出搭建起来的一整套财务与值班流程。这类工具锁定有相当一部分完全不在服务商自己的仪表盘之内，而是藏在第三方可观测性层里——团队早已按某一家服务商的用量格式，把 LangSmith、Helicone、Arize 或 Weights & Biases 之类接了上去。这些都不会体现在应用代码里，但要替换它们可是实打实的工作量，得排进某人的路线图，不是一个 pull request 就能了事的。
以上六个层面是本目录关注的重点，但一次真实的迁移会碰到的并不止这些。微调模型和适配器（针对某家服务商基座模型训练的 LoRA 权重）往往根本无法移植。更换嵌入模型意味着对语料库重新计算嵌入、重建向量索引，这笔开销跟聊天补全毫不相干。内容审核与拒答行为在不同服务商之间、甚至同一模型的不同版本之间，都可能出现明显变化。前文只简单带过的文本流式事件格式，一旦涉及工具调用流式与推理流式，分歧会大得多。每一项都值得单独展开；在这里点出它们，只是为了提醒别把这份六层清单当成完整列表。
合同层："无锁定"究竟意味着什么
合同条款这一层，通常就是人们谈论“避免锁定”时所指的内容。下表从四个维度展开：消费额或期限承诺、模型弃用通知、价格变动通知，以及数据迁出。表中数据取自各服务商自己的定价页面和服务条款，查询时间为2026年7月；凡未经独立复核的内容，请视作参考起点，而非最终定论。
| 服务商 | 标准合同模式 | 公开的模型弃用通知 | 公开的价格调整通知 | 流量出口/可迁移性说明 |
|---|---|---|---|---|
| DigitalOcean | 按量付费，需预充值余额；无最短使用期限 | 三阶段政策：提前14天通知，随后进入为期7天的"仅限旧版本 slug"阶段，最后正式下线 | 未公开；通用条款允许提前通知后进行更新 | 推理服务不收取流量出口费；其他服务按标准带宽计费规则收费 |
| Together.ai | 默认按量付费；可选"预留"档位，并非强制 | 两级政策：同系升级提前3天通知，新模型约2周 | 未公开 | 不收取流量出口费；内容所有权条款偏向客户 |
| Fireworks AI | 默认按量付费；预留容量是可选增值项，需与销售协商，期限约1年 | 未找到公开的弃用政策 | 条款写明变更"在下一个计费周期"生效，未给出具体天数 | 未发现流量出口费或可迁移性相关条款 |
| Baseten | 按量付费，无每月最低消费；Pro/Enterprise 用户可签年度承诺 | 模型 ID 弃用前约2周通知 | 未公开 | 合同保证可导出内容，并在服务终止后提供20天的数据取回窗口期 |
| Modal | 按量付费，按秒计费；企业承诺合同可选 | 不适用；Modal 是通用计算平台，并非托管模型服务 | 未公开 | 不收取流量出口费；服务终止后60天内删除数据 |
| Nebius AI Cloud | GPU 按需计价；可选多月承诺享受折扣 | 没有统一政策；托管模型弃用逐案公告 | 付费协议规定费率变更前提前10天通知；免费层条款允许不另行通知即变更 | 计算流量出口免费；对象存储流量出口按每吉字节计费 |
| OpenAI | 默认按量付费；可选承诺消费协议 | 分级政策：正式版（GA）模型6个月，专用变体3个月，预览版2周 | 条款中有提及；具体天数未经独立核实 | 微调模型只能在 OpenAI 平台上用于推理；无法导出底层权重 |
| Anthropic | 默认按量付费；承诺消费需另行签署协议 | 政策：提前60天通知，并承诺在公司存续期间保留权重 | 商业条款：费率变更前提前30天通知 | 没有任何条款允许导出底层模型权重用于自托管 |
| Google Vertex AI | 默认按量付费；可选预置吞吐量和承诺使用折扣 | 继任模型发布时即公布原模型的退役日期；退役前一个月停止新的访问 | 通用云条款包含一项30天通知豁免，但仅限特定产品，不涵盖 Vertex AI | 适用标准云流量出口定价；未发现 Vertex 关于导出微调权重的专门条款 |
有几点格外显眼。只有 DigitalOcean、Together.ai 和 Baseten 公布了具体数字形式的弃用通知期限；Fireworks 的文档则对此只字未提，这更可能是文档缺漏，而非内部真的没有这种惯例。七家非超大规模厂商中，没有一家公布价格变动的数字通知期限，Nebius 算半个例外——付费协议下有相关规定。相比之下，OpenAI 和 Anthropic 在这方面给出的承诺要详细得多。这也提醒我们：“无需签合同”和“文档完善”是两种不同的品质。单就这个狭窄的维度来看，最常被与供应商集中风险挂钩的那些厂商，反而比一些打着“无锁定”旗号的替代选择更透明。
不过，这些都丝毫没有动摇第 1 节的结论。一家厂商即便给出了宽裕的弃用通知期，也没有最低消费门槛，一旦你的提示词、解析器和重试逻辑都是照着它的行为调校的，迁移过去照样可能困难重重。合同上的自由和实际的可迁移性是两回事，把二者混为一谈，正是团队在迁移半路措手不及的原因。
成本可预测性：另一种锁定途径
合同成本之下，还藏着一种更隐蔽的成本。只有当你能准确算清自己的工作负载放在每一家那里各要花多少钱，扬言换厂商才有威慑力，竞争也才能让定价保持诚实。而不透明的成本结构会让这种货比三家变得困难。如此一来，即便合同里没有任何条款拦着你，切换的实际成本也会被抬高——因为一家真实成本算不清的厂商，其涨价往往也难以察觉。
最典型的例子是上文已经提到过的推理 token 计费：调用方根本看不到的 token，却被当作普通输出一样计费，而模型的推理长度事先又无法完全预测。第二个例子是分词器差异，同样在上文说过。即便两家标称的每 token 单价完全相同，同样的内容在不同模型上的花费也可能相差可观——Anthropic 自己的文档就直接量化了其分词器切换带来的这种差异。第三个例子是在 token 或算力定价之上层层叠加的各类基础设施费与按请求收费。例如，Anthropic 就在基础 token 价格之外披露了多项附加收费：网页搜索工具按每次搜索收费；代码执行按容器运行时间计费，预加载文件时“即使工具未被调用”也可能照常产生费用；某些数据驻留和优先处理选项还带有明文标注的费率倍数。这些都不是秘密——毕竟都是公开的；但如果只盯着每 token 的标价来估算迁移成本，很容易把它们漏掉。
按算力计费的平台引入了另一类复杂性，而这里通常被归为一类的两家，形态其实并不完全相同。Modal 完全按算力时长计费，按 GPU 使用的秒数收费，压根没有按 token 计价的选项。Baseten 则两种兼备：针对热门模型提供按 token 计费的“Model APIs”档位，体验上与普通的按 token 计价服务商无异；针对定制或高吞吐负载，另设按分钟计费的专属部署。无论拿哪一家的算力计费档位去和按 token 计价的服务商对比，你都得先估算自己的吞吐量，光看价目表是不够的——而恰恰是这个估算环节，常常让成本对比在不知不觉中出错。
一个很有用的习惯是：在选定任何服务商之前，先对其定价页面做一次简短的“可预期性审查”。问一问：输出 token 的价格是否与输入价格分开、显眼地列出？有些服务商会刻意把它埋起来。问一问：如果模型会产生推理 token，服务商是否明确说明这部分会计费、并会在 usage 对象中如实报告，而不是含糊其辞？再问一问：服务商是否提供费用计算器或按请求拆分的成本明细，让你能独立复算，而不是只能被动信任每月的账单？还要问：API 响应本身是否暴露了足够详细的 usage 对象——提示 token、补全 token、缓存 token、推理 token——让你能把自己的估算与实际收费逐项核对。一家服务商若在多项上都不达标，就意味着成本悄悄上涨很难察觉，直到账单送达才会暴露。
面向可移植性做架构：抽象预算
把这些复杂性暴露面一一指名之后，实际的问题就变成了：值得投入多少抽象工作去把它们框住？坦率的答案是：比多数工程师凭直觉估的要少。
网关模式。在你的应用与各服务商的 API 之间加一层轻薄的内部层是值得的，但它只该承担有限的几项职责：鉴权、传输、统一化的错误处理与重试，以及跨服务商的一致用量日志。提示词逻辑不属于这一层。试图写一个在各家服务商上都能原样生效的抽象提示词模板，是个陷阱。与维护针对各服务商单独调优的提示词版本、并在需要时有意识地迁移相比，这种做法往往耗费更多工程精力，而且在每一家上的产出都更差。
评测套件才是真正的可迁移层。在应对供应商锁定这件事上，杠杆效应最大的一笔投资是测试套件，而不是抽象层。如果团队有一套自动化、不依赖特定供应商、覆盖真实生产任务的评测套件，通常一天左右就能验证新供应商的表现，一两周内就能完成一次有依据的切换。实际耗时在很大程度上取决于评测覆盖率、合规审查流程，以及部署的深浅。而没有这类套件的团队，只能靠着一次次生产事故，逐一重新发现提示词当初为迁就某家供应商的怪癖而悄悄调整过的每一处。这是测试投入，不是架构投入；无论最终换不换供应商，这笔钱都花得值——因为当现供应商在你不知情时悄悄更新了模型版本，它同样能帮你捕捉由此引发的回退。
选用开放权重模型，相当于买了一份结构性保险。运行开放权重模型，托管方随时换成当下价格与性能最优的供应商——这是现有手段中最彻底的可迁移方案之一。原因在于，第 1 节讲到的那些行为校准大多随模型本身一起迁移，而不是被锁死在单一厂商的托管部署里。这并不能彻底消除锁定：量化方案的选择、张量并行等推理引擎层面的差异，以及不同版本之间分词器的改动，都可能让名义上相同的开放模型产生不同的输出。一些托管供应商还会在你自己的系统提示词前面塞进他们默认的系统提示或安全指令——各家做法不一，所以无论选定哪家开放权重托管商，都要实际核查，不能想当然。开放权重能降低校准风险，却无法把它清零。即便有这些注意事项，它在供应商迁移中的表现仍远好于完全专有的模型——后者一旦切换，就意味着在接入新接口的同时，还得接受一个行为截然不同的模型。真正需要坦诚面对的取舍在能力：最强的专有模型在许多高难度任务上依然领先，为了可迁移性而选择开放权重模型，可能意味着接受一段实打实的质量差距。
值得三思的情形。第一天就上多供应商路由、在还没有第二家供应商可抽象之前就引入 LiteLLM 这类网关抽象层、过早进行多云部署——这三者犯的是同一个毛病：今天就要付出真实且持续的复杂度成本，换来的却是一个可能永远无法兑现的假想未来收益。团队往往低估这笔成本，因为在抽象层面总能轻易找到辩护的理由。如果把多模型路由视为一项基础设施决策仔细推敲，就能为这笔复杂度成本算出实打实的数字：每个请求都会增加延迟、多出一个新的故障面，而最糟糕的是静默误路由——错误的路径返回一个看似合理实则错误的答案，有时费用还高出许多，却全程不抛出任何错误。话虽如此，这是一种权衡，而非铁律。有些组织确实能从统一网关中即刻获得真实价值，比如集中式的可观测性和鉴权；还有些组织出于可用性或合规方面的原因，从第一天起就需要多供应商冗余，而这些理由是具体确凿的，并非假想。判断的关键在于：第二家供应商（或合规要求，或可用性目标）今天是真实存在的，还是仅仅有朝一日可能出现。只有前者才值得现在就支付这笔复杂度成本。
何时接受锁定才是理性之选
以上这些并不意味着可移植性永远值得追求。这项决策取决于三个变量：你迁移的可能性有多大；参照第 1 节给出的校准标准，迁移的成本会有多高；以及为了保持可移植而放弃供应商的独到优势，你会损失多少价值——这些优势可能是前沿的专有模型、更划算的缓存定价，或是团队已经依赖的集成工具链。
对早期团队而言，接受锁定往往是正确的选择——此时交付速度压倒一切，可移植性实际上要等到公司日后资金更充裕时才需要操心。对于依赖前沿专有模型、且没有可比开源权重替代方案的工作负载，接受锁定通常也是对的：真正的切换成本在于能力差距，而不只是迁移工作量。而当供应商的专属成本优化——比如激进的缓存折扣，或针对你的流量模式调优的批处理支持——所带来的节省明显超过任何可预见的未来迁移收益时，接受锁定同样是明智的。
有几类场景，减少供应商锁定尤为重要：开放权重模型的工作负载，此时可迁移性近乎免费，没有理由不用；成本敏感、规模大到供应商竞争成为压价主要杠杆的业务；以及合规环境，其中短期内更换供应商的能力是硬性要求而非锦上添花。
决策框架
一条简明的参考准则：当你在运行开放权重模型、支出规模大到供应商竞争能实质影响你的价格、评估流程已经实现自动化，或者退出能力属于合规要求时，就应当尽量减少锁定。反之，当某家供应商的专属功能能带来超过现实迁移成本的可衡量价值、你尚未达成产品市场契合且速度比保留选择余地更重要，或者你需要的模型只有一家才有时，接受锁定也是合理的。
无论你最终落在分界线的哪一侧，有几项实践都值得无条件执行：让评估套件保持可迁移且自动化；记录每次请求的用量与成本数据，这样即便脱离任何一家供应商的仪表盘，你也能还原真实的支出情况；组织提示词时把供应商专属的部分隔离出来，而不是散落在整个代码库中；并且趁着没有时间压力，提前弄清各家供应商的模型弃用通知政策，别等到被截止日期逼着去查的时候。
常见问题
1. “OpenAI 兼容”端点意味着更换供应商只需改一下配置吗？
并非如此。它统一的只是传输层，也就是请求和响应的结构，但传输层之上的东西并不在标准化范围内。提示词调校、输出解析、重试逻辑、缓存设计和成本估算，都是围绕某一家供应商的具体行为调出来的；切换之后重新调校这些环节是实打实的工程工作，不是改一下 base URL 那么简单。
2. 供应商锁定主要体现在哪些环节？
六个环节：提示词调校、输出格式假设、错误处理与重试逻辑、缓存架构、成本优化调校，以及运维工具。每一处都在悄然积累针对特定供应商的行为，而单纯替换端点根本触及不到它们。
3. 结构化输出和工具调用在各家供应商那里的表现是否一致？
并不一致。OpenAI 的严格 JSON 模式能在大小上限之内保证输出符合 schema；Anthropic 的结构化输出功能在截断和消息预填充场景下存在官方文档明确列出的例外；Together 和 Fireworks 则要求把 schema 直接写进提示词文本，而不能仅作为参数传入。此外，工具调用的参数格式和消息排序规则也各不相同。
4. 提示缓存在各家供应商那里的省钱方式都一样吗？
不一样。Anthropic 会收取写入溢价，且默认 TTL 较短；OpenAI 的缓存基本自动启用，保留窗口也更长；Google 则会额外收取一笔存储费，这是其他供应商都没有的。针对某家供应商缓存特性优化的提示词结构，放到另一家上往往效果明显打折。
5. 无合约供应商是不是天然就比 OpenAI 或 Anthropic 这类专有供应商风险更低？
并非在所有方面都如此。OpenAI 和 Anthropic 公布的模型弃用及价格调整通知政策，比几家打着“无锁定”旗号的供应商还要详尽。合约上的自由与实际可迁移性是两回事。如果你的提示词和重试逻辑都是围绕某家供应商的行为调校出来的，再充裕的弃用预告期也帮不上忙。
6. 降低锁定风险最值得的一项投入是什么？
一套覆盖真实生产任务、不依赖特定供应商的自动化评估套件，而不是抽象层。它能让团队快速验证新供应商的实际表现；即便你从不切换供应商，这笔投入也不白费——当现有供应商在底层悄悄更新模型时，它还能帮你及时发现性能回退。
结论
本文追踪了锁定效应在六个层面的体现：提示词调校、输出格式假设、错误处理与重试、缓存架构、成本优化以及运维工具。这些调校大多存在于“OpenAI 兼容”所声称标准化的传输层之上。合同层面（弃用通知、价格变更政策、数据迁出条款）的重要性不及它之下的行为调校，不过依然值得整理归档，因为各家厂商在这方面的文档详尽程度相差悬殊。成本可预测性则为整个闭环补上最后一环：如果连自己工作负载的成本都算不准，“换一家”的威胁就毫无分量，定价也就始终由对方说了算。务实的应对之策是：维护一套自动化评测套件，记录真实的用量与成本数据，把依赖特定供应商的代码集中隔离而非四处散落，并在真正需要之前就摸清各家供应商的弃用政策。之后，再结合团队当下的处境，判断接受锁定与规避锁定哪一个是更划算的取舍。
换掉一个 base URL 从来都不是迁移的全部。把这些层面一一指认出来，剩下的迁移工作就变成了一个范围明确、可以提前规划的项目。趁还没有外力逼迫时把这项工作做好，更换供应商就会成为你按自己的节奏做出的决定，而不是一封弃用通知邮件替你拍板的决定。
