LLM 模型路由是伪装成成本优化的市场细分

成本仪表盘本身就很有说服力。60% 的流量是“简单”的，快速评估显示较小模型在全局准确率指标上仅落后几个百分点，路由层在同一周内通过特性开关（feature flag）上线。成本曲线开始下行。财务部皆大欢喜。团队继续推进后续工作。

没有人注意到的是，周二下午走廉价路径、周三上午走昂贵路径的客户，现在实际上在使用两种不同的产品。这两个模型的失败方式不同。格式化方式不同。拒绝的内容不同。它们以不同的默认逻辑处理歧义、追问和部分输入。从客户的角度来看，助手一夜之间失忆了，而且没人能告诉他们原因——因为在公司内部，这次变更被归档为一次 FinOps 的胜利，而不是一次产品发布。

这是我在部署 LLM 路由但不对后果负责的团队中看到的最常见模式。这一层被呈现为基础设施优化——同样的产品，更便宜的后端——但它实际上是一个市场细分决策，由在那一分钟触发客户输入的路由规则簇决定。如果一个团队在部署路由时没有掌控这种细分，那么他们交付的产品身份就完全取决于成本图表在周二随机选中的那个模型。

聚合指标抹平了真正重要的分布形态

路由方案的说辞几乎总是围绕一个数字：“在我们的评估中，小模型的准确率是大模型的 94%。”这个数字是分布的平均值。而分布是有形状的。两个分布可以拥有相同的均值，却产生截然不同的用户体验。

让团队翻车的分布形状通常是这样的：简单查询（短小、格式良好、常见）在两个模型上都能通过，对差距几乎没有贡献。极难的查询在两个模型上都会失败。这两个细分领域在你的评估中都是无效的。差距集中在中间地带，大模型能做对，而小模型表现得“似是而非”：这种错误表现为输出看起来很合理，格式正确，非专家读者无法辨别。这个中间地带通常占流量的 10-20%，而且处于这一地带的客户并不是随机分布的。他们集中在特定的细分群体中——长尾租户、非英语母语者、使用非常规 schema 的用户，或者是你的设计合作伙伴未曾预料到的工作流。

当全局准确率差距为两个百分点时，这两个点其实是“无变化”加“无变化”加“这 15% 的用户体验下降了 30 个点”后的细分权重平均值。聚合指标通过平均化处理，专门抹杀了你唯一需要的信号。这就是为什么团队在评估结果良好并发布路由变更后，总是会惊讶地发现某个特定群体在一个月后开始流失。因为那个群体在指标中从未显现。

能捕捉到这一点的方法不是“更多评估数据”，而是按细分维度进行评估切片（per-segment eval slicing）——至少按租户规模、语言区域和粗粒度的任务类型划分——并设定契约：无论全局平均值如何，任何细分维度的倒退都不能超过预定的预算。如果你在发布前无法说出评估切片所针对的细分群体，说明你还没准备好发布路由器。

两种失败模式并不等同于减半频率的单一失败模式

路由的第二个隐性成本是，你不仅是在为系统增加误差，你还在增加 第二种 误差。这种误差有其自身的特征，而团队的调试直觉尚未经过针对性训练。

尖端模型和小模型并非只是准确率调节旋钮不同的同一个模型。它们有不同的先验知识、不同的拒绝边界、不同的分词器（tokenizer）怪癖、对歧义输入的不同默认处理、对名称和数字幻觉的不同倾向、不同的格式化习惯、不同的工具调用可靠性，以及对提示词顺序的不同敏感度。当你跨模型进行路由时，每次客户交互现在都是从一种双组分混合模型中抽取的。支持团队会看到一个客户反馈“助手突然开始伪造 API 端点”，而另一个客户反馈“助手突然开始拒绝回答”，这两个反馈其实源自同一次发布。

在部署路由器之前的几个月里，团队建立的心智模型是：助手具有某种人格和失败特征。部署后，助手拥有了双重人格，客户的会话就在这两者之间随机采样。现在的运维轮值（on-call）需要为两种失败模式准备操作手册。评估套件现在需要运行两次。在大模型下有效的提示词在小模型下会发生倒退，而团队“修复提示词”的本能反应往往会使情况恶化，因为加强对小模型的指令约束常常会导致大模型过度拒绝。

加载中…