模型选型与路由

一句话理解：模型选型不是选“最强的模型”，而是用自己的评测集，为每一类任务找到“质量达标前提下，单个完成任务成本和延迟最低”的组合；大多数生产系统最终都是多个模型、多个思考等级的搭配。

“我们用最新最强的模型吧”和“用最便宜的模型就够了”，是需求评审里最常听到的两种极端。前者让一个日均十万次调用的工单分类功能每月多花几万美元；后者让复杂的异常诊断频繁出错，客服团队不得不人工返工。

模型选型是产品经理可以、也应该深度参与的决策：它直接决定体验、成本和毛利。这一课给出一套可重复的方法。

选型要看的六个维度

维度	要问的问题	订单售后诊断 Agent 的例子
能力	任务需要多强的推理、编码、长文档理解、工具调用能力？	售后根因诊断需要多步推理；工单分类不需要
延迟	用户在等吗？能接受多久的首字延迟和总耗时？	客服实时回复要快；夜间批量复盘可以慢
成本	单次任务成本 × 调用量，在商业模式里算得过来吗？	单次诊断成本要远低于人工处理一单的成本
上下文长度	最长的输入有多大？输出最长多少？	长工单历史 + 多个工具结果，可能需要较大窗口
模态与功能	需要图片、PDF、结构化输出、特定工具吗？	需要读商品破损照片、输出结构化结果
部署与合规	数据能出境吗？需要在哪个云平台上使用？有数据保留要求吗？	客户数据需要在指定云平台和区域处理

以 Claude 当前主力模型为例（2026 年 9 月查阅官方模型概览页，价格与规格可能调整，以官方为准）：

模型	定位	相对延迟	输入 / 输出价格（每百万 Token）	上下文	最大输出
Claude Fable 5.1	高难度推理与长时间 Agent 任务	较慢	$10 / $50	1M	128K
Claude Opus 5	复杂 Agent 编码与企业级任务	中等	$5 / $25	1M	128K
Claude Sonnet 5	速度与智能的平衡	快	$2 / $10	1M	128K
Claude Haiku 4.5	最快，接近前沿的智能	最快	$1 / $5	200K	64K

OpenAI、Google 等厂商也都提供从旗舰到轻量的多档模型，思路相同。另外两个与成本直接相关的事实：Claude 的 Batch API 价格为标准价的 50%，适合不需要实时返回的批量任务；提示缓存的读取价格为基础输入价的 10%（Fable 5.1 为 2.5%）。

还有一个容易被忽视的维度：模型生命周期。每个模型都有退役时间，例如官方概览页上 Claude Haiku 4.5 的退役承诺是“不早于 2026 年 10 月 15 日”。选型时就要规划好迁移和回归测试的节奏。

两种起步策略，一个更常被忽略的旋钮

Anthropic 官方的选型指南给出了两种起步方式：

效率优先：从小而快的模型开始，充分测试，只在能力不够的地方升级。适合原型、延迟敏感、成本敏感、高量简单任务。
能力优先：从强模型开始把效果做出来，优化提示词，再逐步通过降低思考等级或换小模型来提效。适合复杂推理、高自主性 Agent、准确性比成本更重要的场景。

对 Agent 产品来说，能力优先通常更稳妥：先确认“这件事模型能做成”，再谈降本。否则你很难区分失败是模型能力不够，还是提示词、工具、上下文设计的问题。

更常被忽略的旋钮是 思考等级。官方指南特别提到，在同一个模型内调节 effort 来权衡智能、延迟与成本，往往是比换模型更好的杠杆；而且只维护一个模型，提示词、评测和缓存都更简单。所以正确的比较对象不是“大模型 vs 小模型”，而是“模型 × 思考等级”的组合，详见推理模型与思考预算。

用评测集做决策，而不是凭印象

选型的核心产出是一张对比表。流程如下：

图 1 · 用评测集选型：一次实验，持续重跑

以订单售后诊断为例，一次选型实验的结果可能长这样（数字为示意）：

组合	诊断正确率	P95 耗时	每次调用成本	平均重试次数	每个完成任务成本
大模型 + high	94%	38 秒	$0.42	0.05	$0.47
大模型 + medium	92%	21 秒	$0.26	0.08	$0.31
中模型 + high	85%	17 秒	$0.14	0.35	$0.23（另有 15% 需人工返工）
小模型 + 默认	71%	6 秒	$0.04	0.90	表面最便宜，但近三成需人工处理

注意最后一列：要算“每个完成的任务”花多少钱，而不是“每次调用”花多少钱。 便宜模型如果需要更多重试、更多步骤或人工返工，总成本反而更高。评测方法详见构建评测集与成本模型。

路由：让不同的请求去不同的模型

选型的结论往往不是“一个模型”，而是一套 路由策略：

路由方式	做法	适用场景
按功能固定分配	每个功能、每个 Agent 步骤写死用哪个模型	最简单、最可控，建议优先使用
按请求分类	先用规则或小模型判断难度，再分发给不同模型	请求难度差异大的入口，如统一客服入口
级联升级	先用便宜的组合处理，校验失败或置信度低时升级	大部分请求简单、少数困难
编排者与执行者	强模型负责规划和判断，便宜模型负责大量读取和整理	需要大量阅读的研究、多文件分析
故障降级	主模型过载或限流时切换到备用模型	所有生产系统都应考虑

一个订单售后诊断系统的路由示意：

图 2 · 路由示意：不同步骤用不同的“模型 × 思考等级”

路由也有代价：每多一个模型，就多一套提示词要维护、多一组评测要跑、多一个失败点。能用一个模型加不同思考等级解决的，先不要引入多模型。 多 Agent 架构的取舍见什么时候需要多 Agent。

常见误区

“选最强的模型最省心。” 在高量简单任务上，这是持续的成本浪费，还会拖慢响应。
“按每百万 Token 价格选最便宜的。” 要看完成一个任务的总成本，包括重试、多走的步骤和人工返工；不同模型的分词器也不同，同样的文本 Token 数不一样。
“选型做一次就结束了。” 模型每隔几个月就会更新或退役，业务数据也在变化。选型是一个需要评测集持续支撑的过程。

产品经理检查清单

这个功能有几类任务？每一类对能力、延迟、成本的要求分别是什么？
选型结论是否有评测数据支撑？比较的是“每个完成任务的成本”吗？
是否比较过“同一模型的不同思考等级”，而不只是比较不同模型？
主模型不可用时的降级方案是什么？降级后的质量是否可接受？
当前模型的退役时间是什么时候？迁移和回归测试由谁负责、何时启动？
部署平台、数据区域、数据保留等合规要求是否满足？

练习

完成本模块的实践作业：为一个真实任务写一份选型结论（约 60 分钟）。

选定任务：例如“根据客户留言判断工单类型并提取订单号”或“诊断一个页面的 SEO 问题”。
准备 20 个用例，其中至少 5 个是困难或边界用例，并写好判定标准。
选 3 个组合（例如大模型 + medium、中模型 + high、小模型 + 默认）各跑一遍，记录正确率、平均耗时和总成本。
按“每个完成任务成本”计算，写一段 200 字以内的选型结论，说明推荐方案、主要风险和降级方案。

下一步

选好模型之后，还要决定哪些事根本不该交给模型。本模块最后一课「LLM 与确定性程序的分工」讲清楚这条边界。

模型选型与路由