多模型可靠性并非 2 倍：引入第二个 LLM 服务商的非线性成本

这种天真的算法是这样的。我们的主供应商拥有 99.3% 的可用性。增加第二个具有类似独立性的供应商，同时故障的概率就会降至大约 0.005%。成本翻倍，风险降至两百分之一。工程负责人批准了双倍预算，轮值报警在供应商宕机时也不再响起。电子表格显示，这是路线图上性价比最高的可靠性投资。

六个月后，电子表格错了。评估套件（eval suite）的运行时间变成了三倍，提示词（prompt）修改需要提交两个 PR，每周的回归报告中有两列内容相互矛盾，而且没人记得预发布环境的备选方案当前路由到了哪个供应商。一旦团队核算了用于保持两条路径校准的人力工时，双倍预算实际上更接近 4–5 倍。第二个供应商在技术上仍在提供流量，但一半的功能已被悄悄锁定在其中一方，因为保持两者同步已经变得不再划算。

这就是多模型成本陷阱。可靠性算法是正确的；但团队搞错的是运营层面的算法。接下来是对引入多供应商后的成本分解、大多数团队应该首先尝试的“单供应商加降级模式”方案，以及真正证明这种非线性复杂性合理性的少数准则。

供应商独立性的神话

可用性算法假设供应商是独立发生故障的。在实践中，2025–2026 年的停机事件不断证伪这一点。当一个大型云服务商的区域出现故障时，托管在该区域或依赖该区域的多个 LLM 供应商会同时发生故障。当一个共享的 CDN 或 DNS 供应商出现问题时，每一个下游的 LLM API 都会看到相关联的延迟。当新模型的发布让整个行业处于同步负载之下时（这在发布周是可以预见的），容量压力是跨供应商的，而非针对单个供应商。

现实世界中，2026 年的多供应商部署在有效可用性上更接近 99.6–99.8%，而不是独立性假设所预测的理论值 99.995%。你确实获得了可用性。但你获得的增益比商业计划书中说的要少。而且在最初的 0.5% 之后，每提高一个基点（basis point）的成本都比前一个更高。

单凭这一点并不能否定多供应商策略。否定这种天真的“2 倍成本”框架的是二阶成本：提示词、评估、工具模式（tool schemas）以及运营实践，这些都必须维护两份并相互验证。

真正的成本在哪里

当一个团队说“我们支持供应商 A 和供应商 B”时，表面的成本是两个 API 密钥、一个路由器和一些计费插件。潜在成本更大，且会不断复利。

提示词与模型是耦合的，不可跨模型移植。 生产环境的提示词很少是纯粹的规格说明。它们作为补丁不断积累——“添加这个以防止它执行 X”、“重写那个因为 Y 太严格了”——并最终成为一位从业者所说的针对特定模型怪癖的“谈判产物”。调查数据表明，一个成熟的生产环境提示词中，60% 的 token 是累积的补丁，而不是需求。将提示词移动到不同的供应商，你得到的不是一个翻译后的提示词，而是一个孤儿提示词。Anthropic 想要带标签的示例；OpenAI 想要具有清晰角色层次结构的零样本提示（zero-shot）；Gemini 想要带有明确分段标记的大量示例加载。在一个供应商上胜出的提示词，在另一个供应商上未必奏效。

即便封装层试图掩盖，工具调用格式也会发生偏离。 函数调用（function-calling）和工具使用（tool-use）的 API 表面看起来很相似——都返回描述工具和参数的结构化 JSON——但其传输格式、错误语义、并行调用行为和模式验证规则都各不相同。Anthropic 的 tool_use 块嵌入在消息内容中；OpenAI 将 tool_calls 分离到自己的消息字段中；Gemini 使用其自有的 functionCall 形状。统一 SDK 像 LiteLLM 掩盖了核心流程中的问题，但无法隐藏边缘情况：格式错误的参数处理、流式传输块边界以及工具结果回显的行为都存在细微差异。那些宣称“我们用 LiteLLM 抽象了它”的团队，通常意味着“我们抽象了 80% 的内容；另外 20% 现在都在一个名为 provider_quirks.py 的文件中”。

分词器（Tokenizer）会悄无声息地漂移上下文预算。 Tiktoken、Anthropic 的分词器和 Gemini 的分词器计数方式都不同。同样的 8 KB 上下文在一个供应商上可能消耗 1,900 个 token，而在另一个供应商上可能消耗 2,400 个。由于空格、代码和非英语文本的分词方式不同，在供应商 A 上符合 128K token 预算的提示词，在供应商 B 上可能会超过同样的标称预算。RAG 管道中的块大小逻辑、截断启发式算法和摘要触发器都必须是针对每个供应商定制的，否则当流量路由到“另一侧”时，你就会遇到悄无声息的质量退化。

拒绝边界（Refusal boundaries）不一致。 触发安全拒绝的特定输入在不同供应商之间各不相同，且这些边界在每次模型更新时都会发生变化。你的团队花了六周时间加固以避免 OpenAI 拒绝的提示词，在 Claude 上会触发不同的拒绝模式，在 Gemini 上又是第三种。这意味着你的观测层中的错误分类必须将“拒绝”视为针对每个供应商的信号，你的重试逻辑必须区分“供应商 A 的拒绝 -> 尝试不同的措辞”与“供应商 B 的拒绝 -> 尝试不同的供应商”与“合法的用户违规 -> 停止”，并且你的评估必须捕捉供应商特定的误报。这些工作在处理第一个供应商时都不是必须的。但在处理第二个供应商时，这些都是你必须做的工作。

每次模型更新都会导致校准漂移。 2025 年 11 月的一项研究量化了多轮对话系统中的模型切换漂移，结果显示，相对于全程运行相同的后缀模型，即使只是在最后一轮进行交接，也会产生统计学上显著的行为偏移。较小的模型在确定性温度下保持了一致性；而大型前沿模型——团队实际使用的那些——则没有。转化到运营层面：从供应商 A 到供应商 B 的对话中途路由质量，并不是一个你可以测量一次就信任的属性。每当任一供应商发布更新时，你都必须重新测量，而在 2026 年，每个供应商的更新频率至少是每月一次。

非线性叠加的成本

上述每一个成本维度看起来都像是线性的“现在我们要承担两倍”的负担。而真正的复利效应源于它们之间的交互作用。

你的评估套件并不是变成了 2 倍 —— 而是 N × P × M，其中 N 是你的测试用例数量，P 是供应商的数量，M 是每个供应商所需的提示词变体数量。那些以为自己只是将评估支出翻倍的团队，往往会发现支出变成了原来的四倍，因为每个供应商的提示词变体和每个供应商的工具调用路径都需要各自的回归测试覆盖，而跨供应商的交接场景又增加了一个新的维度。

你的运维值班手册（On-call Runbook）也不是变长了 2 倍 —— 它是供应商数量乘以故障模式的乘积效应。“是模型宕机了、触发了频率限制、服务降级但仍在运行、返回了格式错误的工具调用，还是今天单纯反应变慢了？”对于单一供应商，这个问题有五个答案，而现在有二十五个，因为两侧状态的任何组合都是一个独立的运维案例。“服务降级但仍在运行（degraded-but-serving）”的状态尤其令人痛苦：路由依然能看到 200 响应，但响应质量已经悄然退化，如果生产环境中没有运行针对每个供应商的评估网关，直到用户投诉之前你都不会察觉。

你的提示词变更速度并不是慢了 2 倍 —— 它受限于哪个供应商的评估运行最慢、最难解读。团队的有效周期时间变成了最慢的那条路径，而不是平均值。那些投资了多供应商并行 CI 流水的团队经常报告说，他们从 main 到金丝雀发布的时间翻了一倍，而且从金丝雀到全量发布的时间也翻了一倍，因为每次发布现在都需要两次评估通过和一次跨供应商的一致性检查。

你的账单也不是 2 倍 —— 它通常在单一供应商账单的 1.3 倍到 3 倍之间，具体取决于流量分配，但工程师工时通常是更大的支出项目。根据运营 10 个以上模型的团队公开的记录，可靠性工程团队的人数增长速度超过了模型数量本身的增长速度，因为协调面是呈超线性增长的。

这些乘数效应本身都不是灾难性的。但它们加在一起，会将 2 倍的预算变成 4 到 5 倍的实际成本，而且这些成本往往隐藏在财务部门无法追踪的地方：工程师的时间、运维负担、更慢的迭代速度，以及那些尚未被检测到的悄无声息的退化。

“单模型 + 降级模式”的替代方案

大多数认为自己需要多供应商支持的团队，实际上需要的是一个设计良好的降级模式。其逻辑更简单，运维面也小了一个数量级。

设计思路是：运行一个主供应商。当它失败时 —— 无论是频率限制、超时、5xx 错误还是质量违规 —— 尽可能回退到同一个供应商的“受限模式”（通常可以调用同系列的更小模型，它们共享相同的提示词、分词器和工具格式）；如果整个供应商都宕机了，则优雅地降级到一种“做得更少”的模式，而不是路由到其他地方。“做得更少”可能意味着提供缓存的响应、只返回检索到的结果而不进行生成、显示原始工具输出并带有“摘要暂时不可用”的横幅，或者将请求排队，等待主供应商恢复后重试。

这虽然无法给你带来两个独立供应商那种理论上的可用性曲线，但它能给你：

• 统一的提示词层面。 没有针对每个供应商的变体，没有跨供应商的回归测试套件，没有分词器差异。
• 统一的工具调用格式。 你的工具契约在回退路径上保持稳定，因为回退依然在同一个模型系列内。
• 统一的评估校准。 回归测试只有一个维度。你在发布改进时提升的那个数字，就是生产环境中提升的那个数字。
• 透明的用户体验。 一个可见的“摘要暂时不可用”横幅引发的投诉，远少于悄无声息的质量下降——在这种情况下，用户是在与一个具有不同拒绝模式和不同工具使用惯例的完全不同的模型对话。

这种方案的可用性计算不再是多供应商的计算方式。它大约等于供应商生成的可用性加上系统降级模式的可用性，并根据用户接受降级模式的频率进行加权。对于大多数消费者和专业消费者产品，可接受的降级模式覆盖了 95% 以上的请求，而这个产品指标 —— (供应商可用性 × 99.3%) + (降级覆盖率 × 系统可用性 × 0.7%) —— 往往优于那些经过相关性故障调整后的、实际环境下的双供应商配置，且运维成本仅为后者的四分之一。

这种构思框架非常重要：你并没有放弃可靠性。你是在一个系统内投资可靠性 —— 带有抖动的重试、熔断器、针对每个功能的降级方案、缓存、频率限制配额、提示词级别的护栏 —— 而不是在两个都需要同样投资的系统之间投入协调开销。

多供应商方案何时能真正发挥作用

在极少数情况下，多供应商是正确的选择。它们都有一个共同点：停机的成本超过了协调的成本，且不存在合理的降级模式。

大规模的合同谈判筹码。 当年度 LLM 支出超过 500 万美元时，能够可靠地在供应商之间迁移 30% 流量的能力会改变谈判格局。在年支出低于 100 万美元左右时，你能争取到的折扣根本无法覆盖工程协调成本，供应商也深知这一点。

合规性的故障转移要求。 金融服务、医疗保健和某些政府工作负载有合规义务，要求提供文档化的独立供应商故障转移，而不仅仅是降级模式。监管机构将“服务暂时显示缓存数据”视为停机，因此必须有第二条独立路径。这种成本是真实存在的；而另一种选择是不合规。

基于特定能力的路由，而非冗余。 某些工作负载确实需要不同的模型来处理不同的任务 —— 在一个供应商上进行长上下文检索，在另一个供应商上进行快速的小模型分类，在第三个供应商上使用专门的领域模型。这是通过专业化实现的多供应商，而非通过故障转移，其成本结构不同，因为每个供应商负责一组互不重叠的任务，每组任务只需要一次校准。这里的错误做法是试图让每个专业化供应商也互为备份；那正是非线性成本开始发挥威力的时候。

降级模式无法覆盖的已知相关性故障风险。 实时语音代理或交易信号流水线可能没有可行的降级模式。如果功能必须持续生成而供应商宕机了，则必须有另一个随时待命的供应商。大多数团队认为自己属于这一类；但实际上极少有团队真正属于此类。

测试方法很简单：向团队之外的人描述你的降级模式。如果你无法描述它，说明你还没有设计出一个降级方案，而多供应商方案只是在掩盖你的设计缺陷，而不是解决它。

决策框架

在决定投入多供应商架构之前，请先思考四个问题。如果其中三个问题的答案是否定的，那么请留守单一供应商，并将预算投入到降级模式和单一供应商的可靠性提升上。

1. 预期的工程协作成本是否低于 LLM 预算的 15%？ 如果你每年的 LLM 支出为 20 万美元，多供应商协作每年将消耗 3 万美元以上的工程时间。如果由此带来的运行时间收益（折合美元）低于这个数，那就不要做。

2. 你的用户真的会注意到低于 99.5% 的可用性吗？ 对于内部工具、批处理流水线和异步功能，答案通常是否定的。对于实时智能体（Agent）和关乎收入的关键功能，答案通常是肯定的。

3. 是否存在无法接受的降级模式？ 这需要先设计降级模式，而不是假设无法设计。一个提供缓存或仅限检索回答的降级模式，所涵盖的场景往往比团队最初想象的要多。

4. 你是否愿意无限期地运行两套评估测试套件、两个提示词库以及两套值班操作手册（Runbook）？ 因为多供应商的成本不在于项目本身，而是一项永久性的“税收”。

对这四个问题都回答“是”的团队，才有真正的理由采用多供应商架构。而那些只对前两个问题回答“是”的团队，即将以昂贵的代价领教什么是非线性成本曲线。

核心要点

多模型可靠性通常被推销为“以 2 倍的成本换取显著提升的运行时间”。在实践中，运营层面的账目更接近 4–5 倍成本，运行时间的收益会因关联失效而缩减，而单一供应商上设计良好的降级模式只需一小部分的协作成本，就能提供大部分的可靠性。首先要问的问题不是“我们应该使用哪两个供应商？”，而是“我们的降级模式是什么样的？”先回答这个问题，关于第二个供应商的问题要么会变得更加清晰，要么会直接消失。