“够用就好”的模型选择陷阱：为什么你的团队在为 AI 支付冤枉钱

大多数团队发布第一个 AI 功能时都会使用最好的模型，因为演示（demo）就是在那上面跑的，而且没人有时间深入思考。接着第二个功能也用了同样的模型。然后是第三个。六个月后，每个功能的每次调用都指向了前沿层级（frontier tier）——而账单比实际需要的数额高出五到十倍。

令人不安的事实是，你的生产系统处理的 40%–60% 的请求根本不需要前沿级别的推理。它们只需要称职的文本处理。而购买称职的文本处理服务的成本要低得多。

默认设置是如何形成的

这种模式在工程团队中非常普遍：工程师使用最好的模型构建原型，因为这在探索新能力时可以最大限度地减少变量。原型发布了。产品部门很满意。工程团队继续进行下一个项目。没有人回头去问，模型选择是否真的是关键支撑。

存在一些组织力量让这种现状变得难以改变。保留昂贵模型的理由很容易提出：“它能提供最好的结果，我们不想让质量退化，客户很满意。” 而切换模型的理由则很难陈述：“我们认为可以削减成本，但可能会引入细微的质量下降。” 不对称的风险容忍度意味着默认选择几乎总是胜出。

结果就是，团队最终为意图分类、格式转换、从格式良好的输入中提取结构化数据以及短文档摘要等任务支付了前沿模型的价格——而这些任务并不能从额外的推理能力中获得明显的益处。

任务复杂度审计

在进行任何路由更改之前，你需要了解你的系统实际上在做什么。抽取 200–500 个最近的请求样本，并根据它们所需的推理类型对每一个进行分类。

大多数生产系统都有三个桶：

模式匹配任务 (Pattern-matching tasks) 需要识别结构、提取字段、分类意图和转换格式。输入有一个明确的正解，能力较小的模型可以可靠地生成。示例：从结构化表单中提取实体、将支持工单路由到正确的类别、将 JSON 从一种 schema 转换为另一种、总结固定模板的报告。

组合任务 (Compositional tasks) 需要结合跨来源的信息，或生成同时满足多个约束的连贯输出。当中型模型的约束明确且上下文结构良好时，它们可以可靠地处理这些任务。示例：使用提供的信息起草回复、解释代码更改、从检索到的文档中合成简短报告。

推理密集型任务 (Reasoning-intensive tasks) 需要跨多个步骤保持持续的逻辑连贯性、在没有明显模式可匹配的情况下解决新颖问题，或者在正确答案空间定义不明确的情况下做出判断。这些是前沿模型体现其溢价的地方。示例：权衡模糊的架构决策、利用不完整的信息进行多步调试、从复杂证据中生成新颖假设。

当团队诚实地进行这项审计时，通常的模式是：模式匹配任务占业务量的 40%–60%，组合任务占 30%–40%，而推理密集型任务占比不到 20%。大多数账单恐怖故事都源于将模式匹配流量路由到了前沿模型，因为没有人做出这种区分。

价格算术

不同层级之间的成本差距不是可以忽略不计的。截至 2026 年，一个代表性的成本阶梯如下：

• Haiku 层级 (Claude Haiku, Gemini Flash, GPT-4o mini)：每百万输入/输出 token 约为 $0.80–$4
• Sonnet 层级 (Claude Sonnet, GPT-4o)：每百万 token 约为 $3–$15
• Opus 层级 (Claude Opus, GPT-5, o3)：每百万 token 约为 $5–$75

一个每天处理 1,000 次对话的聊天机器人，在高效层级上的成本约为每月 $12–$50。而在前沿层级上，同样的工作负载每月需要 $1,000–$3,000。对于类似规模的文档处理，前沿层级的成本可能比高效层级的替代方案高出 90 倍，而两者产生的用户结果却是等效的。

一个来自生产级代码代理基础设施的真实案例：应用三层路由——Opus 用于架构规划，Sonnet 用于实现，Haiku 用于文件导航和简单编辑——与全部在 Opus 上运行相比，单次会话成本降低了 51%。昂贵的模型仍在运行，它只是被用在了真正需要它的工作中。

对级联 LLM 系统（cascaded LLM systems）的研究发现，结合路由和升级机制，可以以 24% 的前沿模型成本实现 97% 的前沿模型准确率。这 3% 的差距通常处于其他系统级波动的噪声范围内，且远低于大多数任务类别中用户可察觉的质量差异。

为什么“演示效果很好”是一个糟糕的校准信号

演示是模型层级选择中最糟糕的信号，原因有两点。

首先，演示是经过精挑细选的。你记住的是令利益相关者印象深刻的回答，而不是那五十个表现尚可的回答。当前沿模型比 Sonnet 模型产生稍显优雅的输出时，这在开发过程中的侧向对比中是可见的。但对于只看到一个回答的用户来说，它是不可见的。

其次，演示测试的是展示场景，而不是生产分布。前沿模型在困难案例上赢得优势——模糊的输入、边缘情况、需要长上下文真实推理的请求。这些只占生产量的一小部分。而在真实流量中占据主导地位的模式匹配请求，在不同层级之间并不会产生明显不同的输出。

正确的校准信号是实际条件下的用户行为。修改率、后续请求率、会话放弃率、任务完成率——这些衡量的是用户是否得到了他们需要的，而不是输出在受控对比中是否达到了最大程度的令人印象深刻。

如何进行 A/B 测试

模型降级的实际障碍在于对隐性质量退化的恐惧。解决方案不是相信你对重要事项的直觉，而是去衡量。

将特定功能的百分之几流量路由到低成本模型。衡量任务完成信号，而不是评估准确度。在精选测试集上的评估准确度无法预测用户体验；它只能预测评估准确度。真正重要的行为信号包括：

• 修改率 (Revision rate)：用户在低成本模型下修改或重做输出的频率是否更高？
• 后续查询率 (Follow-up query rate)：用户是否更频繁地提出澄清性问题或进行修正？
• 会话深度 (Session depth)：交互是更快完成，还是需要更多轮次？
• 直接拒绝 (Direct rejection)：用户是否直接丢弃回复而未采取行动？

在得出结论前，在中等流量下运行两到四周。大多数团队会发现，对于模式匹配类任务，低成本模型在每项行为指标上都能产生统计学意义上的等效结果。对于组合性任务，中端模型的表现与旗舰级模型的差距在误差范围内。只有对于推理密集型子集，旗舰级模型才显得必要。

组织层面的问题

技术工作很简单，更难的问题在于组织层面。

工程团队通常默认使用旗舰模型，部分原因是模型选择的讨论会产生摩擦。“我们降级了 AI” 是一个很难传达给产品和业务利益相关者的信息，因为他们一直被告知旗舰模型更好。即使 A/B 测试显示用户感知不到差异，内部的叙事也会变得令人不安。

通常有效的重构思路是：模型选择不是一个质量决策，而是一个工作负载匹配决策。你不会使用专为 OLAP 查询设计的数据库集群来处理简单的键值对查询，无论它在技术上是否胜任。同样的逻辑也适用于 LLM 分级。将旗舰模型用于模式匹配任务并非谨慎之举，而是对计算资源的错配。这些资源如果部署在真正需要它们的推理密集型任务上，会更有价值。

将路由策略框定为一种优先级排序——通过将简单问题卸载到高效能算力上，从而为难题腾出昂贵的资源——通常比将其框定为削减成本更容易被人接受。

构建路由策略

起点是静态路由：按功能或任务类别定义规则，而不是按单个请求。静态路由是确定性的、无需额外延迟且可审计的。它在不增加复杂性的情况下涵盖了大多数高价值的路由决策。

• 对于任何尚未经过明确分析的功能，默认使用中端模型。中端模型的能力足以应付大多数生产工作，且成本低廉，使得优化的紧迫性不高。
• 对于结构上属于模式匹配的功能，默认使用高效能模型：如提取、分类、格式化、简单摘要。
• 将旗舰模型保留用于以下场景：你已衡量出其任务分布确实需要持续推理的功能，或者错误代价极高的场景。

如果你的流量模式多变，足以支持动态路由，请使用任务复杂度信号——输入长度、请求类型、模糊约束的存在——来进行选择性升级。核心纪律是：在将功能加入旗舰模型之前需要证据，而不是在将其移除之前需要证据。

闭环管理

模型成本会随着时间的推移而累积，因为产品覆盖面和流量都在增长，但一旦功能发布，模型选择决策就很少被重新审视。管理得好的团队会建立一个简单的成本归因层：按功能统计 Token 支出，每周汇总。当某个功能的支出超过阈值时，就会触发路由审查。

这并不是为了激进地斤斤计较，而是为了确保旗舰级的算力被保留用于真正能产生显著影响的工作。仅仅因为没有人回头去检查最初的决定，就让文档分类功能一直跑在 Opus 上，是对资源的浪费。这些资源本可以资助额外的实验、扩展算力，或为真正需要它们的任务提供更好的基础设施。

目标不是打造最便宜的 AI 系统，而是建立一个系统，让每一美元的推理成本都用在确实需要这项支出的任务上。