成本仪表盘本身就很有说服力。60% 的流量是“简单”的，快速评估显示较小模型在全局准确率指标上仅落后几个百分点，路由层在同一周内通过特性开关（feature flag）上线。成本曲线开始下行。财务部皆大欢喜。团队继续推进后续工作。
没有人注意到的是，周二下午走廉价路径、周三上午走昂贵路径的客户，现在实际上在使用两种不同的产品。这两个模型的失败方式不同。格式化方式不同。拒绝的内容不同。它们以不同的默认逻辑处理歧义、追问和部分输入。从客户的角度来看，助手一夜之间失忆了，而且没人能告诉他们原因——因为在公司内部，这次变更被归档为一次 FinOps 的胜利，而不是一次产品发布。
这是我在部署 LLM 路由但不对后果负责的团队中看到的最常见模式。这一层被呈现为基础设施优化——同样的产品，更便宜的后端——但它实际上是一个市场细分决策，由在那一分钟触发客户输入的路由规则簇决定。如果一个团队在部署路由时没有掌控这种细分，那么他们交付的产品身份就完全取决于成本图表在周二随机选中的那个模型。
聚合指标抹平了真正重要的分布形态
路由方案的说辞几乎总是围绕一个数字：“在我们的评估中，小模型的准确率是大模型的 94%。”这个数字是分布的平均值。而分布是有形状的。两个分布可以拥有相同的均值，却产生截然不同的用户体验。
让团队翻车的分布形状通常是这样的：简单查询（短小、格式良好、常见）在两个模型上都能通过，对差距几乎没有贡献。极难的查询在两个模型上都会失败。这两个细分领域在你的评估中都是无效的。差距集中在中间地带，大模型能做对，而小模型表现得“似是而非”：这种错误表现为输出看起来很合理，格式正确，非专家读者无法辨别。这个中间地带通常占流量的 10-20%，而且处于这一地带的客户并不是随机分布的。他们集中在特定的细分群体中——长尾租户、非英语母语者、使用非常规 schema 的用户，或者是你的设计合作伙伴未曾预料到的工作流。
当全局准确率差距为两个百分点时，这两个点其实是“无变化”加“无变化”加“这 15% 的用户体验下降了 30 个点”后的细分权重平均值。聚合指标通过平均化处理，专门抹杀了你唯一需要的信号。这就是为什么团队在评估结果良好并发布路由变更后，总是会惊讶地发现某个特定群体在一个月后开始流失。因为那个群体在指标中从未显现。
能捕捉到这一点的方法不是“更多评估数据”，而是按细分维度进行评估切片（per-segment eval slicing）——至少按租户规模、语言区域和粗粒度的任务类型划分——并设定契约：无论全局平均值如何，任何细分维度的倒退都不能超过预定的预算。如果你在发布前无法说出评估切片所针对的细分群体，说明你还没准备好发布路由器。
两种失败模式并不等同于减半频率的单一失败模式
路由的第二个隐性成本是，你不仅是在为系统增加误差，你还在增加 第二种 误差。这种误差有其自身的特征，而团队的调试直觉尚未经过针对性训练。
尖端模型和小模型并非只是准确率调节旋钮不同的同一个模型。它们有不同的先验知识、不同的拒绝边界、不同的分词器（tokenizer）怪癖、对歧义输入的不同默认处理、对名称和数字幻觉的不同倾向、不同的格式化习惯、不同的工具调用可靠性，以及对提示词顺序的不同敏感度。当你跨模型进行路由时，每次客户交互现在都是从一种双组分混合模型中抽取的。支持团队会看到一个客户反馈“助手突然开始伪造 API 端点”，而另一个客户反馈“助手突然开始拒绝回答”，这两个反馈其实源自同一次发布。
在部署路由器之前的几个月里，团队建立的心智模型是：助手具有某种人格和失败特征。部署后，助手拥有了双重人格，客户的会话就在这两者之间随机采样。现在的运维轮值（on-call）需要为两种失败模式准备操作手册。评估套件现在需要运行两次。在大模型下有效的提示词在小模型下会发生倒退，而团队“修复提示词”的本能反应往往会使情况恶化，因为加强对小模型的指令约束常常会导致大模型过度拒绝。
架构上的后果是，路由边界并非免费的抽象——它给每个涉及助手输出的下游系统都引入了切实的复杂度税。如果一个团队仅根据推理成本来评估路由器的价值，那他们就遗漏了以下开支：翻倍的评估成本、翻倍的调试成本、翻倍的提示词维护成本，以及在两个供应商按各自进度发布更新时，必须让两种模型行为保持大致一致的长期义务。
用户不在乎你的成本图表；他们在乎的是可预测性 可靠性研究得出了一个路由相关文献往往会忽略的结果：在准确率处于中等水平时，用户预测何时可以信任系统 的能力，比系统的平均准确率更重要。一个 95% 准确率但其 5% 的失败可以被预见（总是发生在用户能识别为超出范围的输入上）的模型，比一个 96% 准确率但其 4% 的失败随机分布在各种输入类型中的模型更出色。
在这一维度上，在客户不知情的情况下将其在两个模型之间切换的路由器是最糟糕的结果。客户的心智模型是基于交互历史建立的。当这些历史记录来自两个不同的分布时，客户无法形成稳定的预期。他们会开始重复问同一个问题，看看答案是否会改变。他们会对正确的答案失去信任，因为他们无法区分“这是对的”和“这是那个能把事情做对的模型”。他们开始怀疑产品正在退化，即使测量的质量正在提高——因为他们的体验方差（experiential variance）上升了。
这是金融领域永远看不到的失败模式，因为没有人会为方差买单。它会在六周后表现为那些处于路由接缝（routing seam）处的客群的静默流失（quiet churn），而团队会将其归因于“AI 还不够可靠”，而不是“我们在配置标志背后发布了一个市场细分决策，结果被客户察觉了”。
正确的产品级做法是在一个会话（session）内，理想情况下是在一个计费周期内，将客户的流量锁定（pin）在单个模型类别上。成本图表会受到轻微影响，但客户的体验方差不会激增。如果路由必须在不同客群之间变动，这种变动应该遵循客户可以识别的特征——例如任务类型、他们明确选择的复杂程度分级——而不是对他们不可见的输入内部特征。
层级提升是一个发布事件，而不是一个路由决策 第三个失误是客户确实会跨越层级。一个不断增长的租户，其流量特征会发生变化。产品团队发布的新功能可能会产生路由器将其归类到不同桶中的查询形态。模型供应商发布更新，导致你的路由阈值发生偏移。这些事件中的每一个都会将单个客户推向路由边界的另一侧，从客户的角度来看，每一次跨越都是在他们的账户中发布了一个不同的产品——没有发布说明，没有变更日志，也没有回滚方法。
因为这种跨越是持续的且针对每个租户的，所以没有任何单一事件会触发团队现有的发布管理机制。没有 PR 评审，没有灰度发布（canary），没有回滚计划，也没有对支持团队的赋能。团队收到的第一个信号是一个困惑的工单——“上周四是不是改了什么？”——而支持工程师无法回答，因为路由日志没有与支持工具关联，而且这种变化并不是一次部署。
解决这一问题的规则是将层级跨越视为一等公民的遥测数据（first-class telemetry）。每一次晋升或降级事件——从廉价层级到昂贵层级，反之亦然——都应记录客户 ID、触发因素（流量形态变化、阈值更新、供应商发布）以及支持团队可以与工单关联的时间戳。当客户询问“是否发生了变化”时，支持工程师可以回答：“是的，在 14 号，由于你的典型输入长度翻倍，你的流量进入了更高层级。”这比“我得去问问工程部”要好得多。
更深层次的做法是为每个层级编写一份成本-质量契约。路由器只允许在特定的质量包络（quality envelope）内优化成本，该包络按细分市场和任务类型定义。当客户的流量形态可能将他们推过层级边界时，系统要么将他们锁定在之前的层级（保持体验一致），要么将这种跨越视为一次带有通知的明确迁移。这样，路由就不再是“现在哪个模型最便宜”，而是“满足该客户所签契约的最便宜模型”——这正是世界上所有其他分层 SaaS 产品最终达成的实际产品语义。
核心问题是谁拥有细分权 如果你只能从中记住一件事，那就是：发布路由器不是一个 FinOps 决策，假装它是 FinOps 决策是所有后续意外的根源。这是一个关于谁能获得哪个版本助手的“产品决策”，是在成本压力下做出的，并被一个专门为向批准变更的人隐瞒细分情况而构建的聚合指标所伪装。
解决方法不是停止路由。路由是现实存在的，其成本优势也是真实的——前沿模型与廉价模型之间 30 到 300 倍的价差不会消失，在大规模情况下采用单一模型策略本身就是一种失职。解决方法是将路由边界置于与任何其他发布相同的治理之下：按细分市场的质量预算、按租户的锁定机制、层级跨越遥测、支持可见的原因，以及一位职责描述中包含“让客户体验到一个产品，而不是多个”的产品负责人。
做对这一点的团队最终会拥有一个从外部看起来像分层产品方案的路由层——因为它本质上就是如此，将其命名为分层产品是保持产品连贯性的唯一方法。做错这一点的团队最终会得到一条向下弯曲的成本曲线，以及一条随之向下弯曲的体验曲线，并且在那些处于接缝处的客户流失殆尽之前，内部甚至没有一套词汇能将这两者联系起来。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
