模型选型看哪几项
选模型时最常见的做法是看榜单分数。这几乎总是错的——榜单测的是通用能力，而你要的是它在你的任务、你的提示词、你的数据上的表现。
更麻烦的是，模型是会被替换的。今天选的那个，三个月后可能有更好的，也可能供应商悄悄换了个快照。所以选型不只是"选哪个"，还包括"怎么让换模型变得可控"。
1. 榜单为什么不够用
三个原因：
分布不同。 榜单的样本分布和你的真实请求分布通常差得很远。客服场景里八成的问题集中在二十类，而榜单不会按这个真实比例选取样本。
它不测你的提示词。 同一个模型在不同提示词下表现差别很大。榜单用的是它自己的提示词。
它不测你的组合。 你的系统里有检索、有工具、有后处理。模型只是其中一环，而榜单测的是单模型。
所以榜单的正确用法是初筛——用它把候选从几十个缩到三四个，然后用你自己的评测集定胜负。
2. 看哪六项
2.1 任务匹配度
第一件事是确认模型能稳定完成你的核心任务类型。分类、抽取、改写、长文总结、多步推理——这些能力的分布在不同模型上差异很大，而且和"总体智能"不完全成正比。
小模型在窄任务上经常够用。用你的评测集去测，别用直觉判断"这个更小所以更差"。
2.2 结构化输出的严格度
如果你的下游依赖 schema（见《结构化输出与自愈》），那么"它能不能稳定按 schema 输出"是一个独立的选型维度。
不同模型对结构化输出的服从程度差异明显，有些需要 strict 模式加持，有些即便开了也会偶尔跑偏。这一项只能实测：用你的 schema 跑上百次，看失败率。
2.3 工具调用的质量
同样在《工具调用的四段循环》里提过：模型会不会选对工具、参数填得对不对，是另一个独立维度。
有的模型推理强但工具参数经常填错；有的正相反。如果系统重依赖工具，这一项的权重应该高于通用分数。
2.4 上下文与输出长度
不只看"支持 200K"这个数字。要看：
- 长上下文下的实际表现（lost-in-the-middle 现象在长上下文上更明显，见《上下文是有限预算》）
- 最大输出长度——如果你的场景需要长输出，这一项常常是硬门槛
- 长上下文的价格——很多模型对超过某个阈值的输入收取更高单价
2.5 价格与分词
价格表上写的是每百万 token 多少钱，但不同模型的分词器不同。同样的中文文本，不同分词器切出来的 token 数可以差很多。
所以比较成本时，要用你的真实语料测 token 数，再乘单价。只看单价会算错。
另外三项容易被漏：
- 缓存是否可用、折扣多少（见《Token 成本的三个杠杆》）
- 推理型模型会额外产生 reasoning token，且单独计价
- 批量接口是否有折扣
2.6 部署与合规
能不能自托管、数据是否出境、有没有驻留要求、供应商的可用性记录、是否有稳定的模型 ID 可供固定。
最后一项很实际：有些供应商提供会移动的别名，指向"当前最新"。生产系统要用固定的快照 ID，否则某天模型悄悄升级，你的系统行为变了而你不知道（这一点在《评测集怎么变成门禁》里也提过）。
3. 路由：把请求分到能成功的最便宜那一档
选型阶段定的是"主力模型是谁"，还有一个更激进的选项是连主力都不外采——自己微调一个窄任务模型，或私有化部署。这条路解决的是另一类问题（数据不出境、单位成本、延迟），它的适用面比多数人以为的窄，先看《微调解决什么》再决定要不要走。
选定一个模型之后，真正的省钱空间在路由——不是所有请求都需要最强的模型。
3.1 三种策略
前置路由（cascade）。 先用一个分类器判断难度，直接选模型，一次成。最快，风险是分类错了没有补救。
后置兜底（fallback）。 先用便宜的，生成后做一次校验，不通过就升级到贵的。更安全，代价是升级的那部分请求延迟更高。
混合。 前置分类 + 生成后校验 + 失败升级。生产环境最常见，实现也最复杂。
3.2 校验什么
后置兜底的关键是"怎么判断便宜模型这次没做对"。可用的信号：
- 结构化输出校验没过
- 引用不在召回集合里
- 长度或格式明显异常
- 一个小的评分模型给出低分
前三个是确定性的、便宜的；最后一个要再花一次调用，只有在前三个都不适用时才用。
3.3 路由本身也有成本
分类器也是一次调用。如果分类器的成本接近它省下的钱，这套就不划算了。
一个实用的简化：用规则而不是模型做路由——按查询长度、是否命中知识库、是否有历史上下文这类信号分档，往往已经能拿到大部分收益，且不增加延迟。
还有一个容易被漏掉的耦合：路由会打散提示缓存。缓存是按"从开头到断点"的哈希做的，一旦请求被分到不同供应商，各家的缓存互不共享；同一个供应商内部，路由到不同机器也可能命中不了（OpenAI 的自动缓存就跟着机器走）。路由粒度越细、命中率越低。所以分档要按稳定维度做（任务类型、租户档位），别按随机权重或实时延迟轮询——那样每一档都在冷启动。缓存与路由的取舍见《Token 成本的三个杠杆》。
后置兜底还要算清代价：便宜模型那次已经付了，贵模型那次还要再付一遍，延迟也叠了一倍。只有当"便宜模型成功率 × 校验成本"明显低于"直接上贵模型"时才划算。另外那个打分模型本身也要校准、要评测——它是整条链路里唯一不确定的环节，别默认它准。
4. 换模型是一次要管的事
模型会变——供应商发新版本、你们想换更便宜的、某个模型下线了。所以换模型不能是"改一行配置然后祈祷"。
4.1 固定模型 ID
生产代码里写具体版本，不写会移动的别名。这样模型变化是一个可见的 diff，而不是一个悄悄发生的事。
4.2 换之前先做影子对比
用一周真实流量，新旧模型各跑一遍，比较结果。不要只看聚合分数，要按类别看——经常出现"总分持平，但某一类明显变差"的情况。
这个步骤在《评测集怎么变成门禁》里有对应的 CI 做法，但影子对比用的是真实流量，能发现评测集里没有的问题。
4.3 提示词要跟着调
换了模型，提示词通常要改。原提示词里的某些约束在新模型上可能过度（导致过度拒答）或不足（导致跑偏）。
所以"换模型"和"调提示词"是一次变更的两半，要一起评估，不要分两次上线——否则你分不清变化来自哪一半。
4.4 保留回退路径
新模型上线后要有可回退的能力。这不是技术问题而是流程问题：回退的开关在哪里、谁能按、按了之后旧配置还在不在。
和《多模型接入与降级链》里说的一样——一条从没被真实流量验证过的备选路径，等于没有。
5. 一个反模式
为了"用上最新最强的模型"而换模型。 除非你的评测集显示有实质提升，否则换模型只是引入了变化和风险。
更常见的实际情况是：小模型加上好的检索和好的提示词，胜过最强的模型配上一套粗糙的管线。这在《RAG 链路与失败模式》里说过——大多数效果问题不在模型，在检索和上下文。
6. 决策记录该写什么
选型做完了，把结论写下来，因为半年后一定有人问"为什么用这个"。至少记：
- 候选清单与淘汰理由
- 用的是什么评测集、多少条、什么分布
- 各候选在你的评测集上的分数（按类别分）
- 成本测算（用真实语料测的 token 数 × 单价）
- 决定时的日期——这一条最重要，因为半年后这个结论就该被重新验证了
没有这份记录，下一次选型就得从头再来一遍；有了它，重测只需要跑一遍评测集。
7. 清单
- 用榜单初筛，用自己的评测集定胜负
- 测过结构化输出的失败率
- 测过工具调用的参数正确率
- 用真实语料测 token 数再比价
- 生产用固定快照 ID，不用会移动的别名
- 路由规则先用规则型，不够再上分类器
- 换模型前做过真实流量的影子对比
- 换模型和调提示词一起评估
- 有回退开关且被验证过
- 选型结论写成了记录，带日期
最后一条不是文档工作。带日期的意思是：这份结论有保质期。模型领域半年一个样，半年前的最优解今天可能已经不是了。
换模型本身也是一次需要对照的变更——怎么分流、看哪些指标、什么时候回滚，见《灰度与 A/B 怎么分》；如果团队里有多个业务在调模型，路由和凭证应当集中在《统一接入层：AI 网关》里统一管，而不是每个服务各写一遍。