那个你从未进行过负载测试的备用模型

每一个具有韧性的 LLM 设计在配置中都有一行代码指定了一个备选模型。它之所以存在，是因为有人在设计评审中提出了正确的问题——“如果主模型宕机了怎么办？”——而另一个人用一个 fallback: 键回答了这个问题。大家都点头表示赞同。架构图上多了一个带有虚线箭头的第二个框。合规文档中也增加了一句关于优雅降级的描述。

然后，再也没有人碰过它。

备选模型是大多数生产环境 AI 系统中被断言得最自信、但演练最少的组件。它被命名、被记录、被画在图中——而在它真正承载流量的那一天，也是它第一次遇到真实请求的一天。你并没有建立安全网。你只是构建了第二个断裂强度未知的模型，而你将在最糟糕的时刻发现那个极限。

发生这种情况的原因是结构性的，而非疏忽。主模型接收你编写的每一个提示词、运行的每一次评估、来自每个用户的每一份错误报告。它在数月的生产流量磨练中成型。而备选模型只得到了一个配置条目。一条路是锻造出来的，另一条路是宣称出来的。当主模型性能下降且流量转移时，你并不是切换到一个经过测试的系统——你是在事故期间、在高负载下、毫无缓冲地冷启动一个新系统。

配置了备选并不等于测试了备选

“备选”（fallback）这个词里隐含着一种微妙的歧义。在设计评审中，它意味着 一个在主模型无法工作时能处理流量的模型。在配置文件中，它意味着 一段路由代码在看到 503 错误时会选择的字符串。这两者并不是一回事，而它们之间的差距正是第二次事故潜伏的地方。

路由到备选模型是简单部分。网关和代理已经很好地解决了这个问题：优先级组、熔断器、健康检查、备份提供商的自动重试。如果你的主模型返回 503，同一个请求会在几毫秒内重新发送给备选模型。这套机制很有效，也很可靠。它也不是会出问题的地方。

会出问题的是路由决策 下游 的所有环节。备选模型产生输出。这些输出流入一个根据主模型的格式习惯调优的 JSON 解析器、一个根据主模型的表述习惯校准的提示词注入过滤器、一个假设主模型工具调用约定的函数调用层，以及一个渲染主模型 Markdown 特性的 UI。所有这些都没有针对备选模型进行过测试。路由层完美地完成了它的工作，将一个正确的请求交给了一个其输出从未被你的系统成功处理过的模型。

一个配置好的备选方案证明了你的 路由器 工作正常。但它无法证明你的 应用程序 能在备选模型的输出上正常运行。这些需要单独的证据，而其中只有一种证据是容易获得的。

提示词无法通用，这才是核心问题

大多数备选配置中包含的最昂贵的假设是：提示词是与模型无关的——即你为主模型精心调优的指令在备选模型上会有相同的效果。事实并非如此。

真正更换过模型的从业者会直截了当地告诉你：提示词的可移植性根本不存在。措辞和顺序的细微变化都会引起输出的巨大变化。提示词不是交给可替换执行器的规范；它是为特定锁切割的钥匙。能可靠地让主模型输出严格 JSON 的指令，可能会让备选模型输出“包裹在正文中的 JSON”。锚定主模型语气的少样本（few-shot）示例可能会被具有不同指令遵循偏好的模型所忽略。在主模型上表现稳固的系统提示词，在备选模型上可能在几轮对话后就悄悄偏离。

这就是为什么切换到备选模型并不等同于优雅降级。优雅降级意味着同一个请求产生了一个略差但仍然 有效 的结果。实际发生的情况更接近于范畴变化：响应在结构上是不同的，而结构差异破坏的是解析器，而不是心情。没有模式强制（schema enforcement）的旧模型符合预期输出格式的比例不到 40%——而这还是你所关注的模型的 实测 失败率。你从未调优过的备选模型，其失败率根本无人衡量。

加载中…