该用哪个模型？

具体的模型推荐，几个月就过期了。决策框架不会，所以这一页讲框架。

看档位，不看名字

每一家厂商大致都提供三档，档与档之间在能力和价格上都差得很远。

小/快。 最便宜、延迟最低。分类、抽取、路由、简单格式化、短摘要，都能胜任。

中档。 通用场景的默认选择。大部分工作都属于这一档。

大/前沿。 推理最强、最贵、最慢。只有真正难的任务才值得用。

各档之间的价差通常在一个数量级甚至更多。只要有真实流量，选档位这一个决定就压过其他所有成本决策。

从小档起步，逐步往上

直觉是直接抓最强的模型，然后一直用下去。这很贵，而且往往没必要。

更好的做法：从小档开始，只在实测失败时才往上加档。

1. 拿你真实任务里的真实样本，先用小模型试。
2. 用评测量出它到底成不成，而不是靠感觉。
3. 失败了就升一档，再测。

生产环境里相当大一部分工作用小模型跑得好好的。分类、抽取、路由、打标签很少需要前沿级别的推理。为抽取付前沿模型的价格，是最常见也最容易避免的 AI 开销。

什么才真的需要大模型

误差会累积的多步推理——尤其 agent 循环，因为可靠性会逐级衰减，弱一点的模型单步错误率就足以毁掉长流程。

有点分量的代码生成，尤其是跨多个文件或面对不熟悉的 API 时。

细微的判断——语气拿捏、模糊的边界情况，以及任何「差不多就行」不成立的地方。

长上下文综合，需要真正用上散落在大输入里的材料。

复杂条件下的指令遵循。 当多条约束相互纠缠时，小模型最先垮。

路由

不必所有事都用同一个模型。

按任务分档。 抽取交给小模型，最终回复生成交给中档。这是性价比最高的结构性优化，却用得很少。

不确定时升档。 先跑小模型，如果置信度低或输出没过校验，再用更大的模型重试。你只为需要它的那一小部分请求付大模型的价钱。

先分类再路由。 用一次便宜的先期调用判断难度，然后按难度派发。流量确实混杂时值得这么做。

其他维度

能力不是唯一的维度。

延迟。 交互界面超过两三秒就让人难受。立刻回答的小模型，常常胜过答得更好但慢吞吞的大模型——流式输出也会明显改变体感的延迟。

上下文窗口。 如果你要送大文档进去，容量就是一道硬门槛。注意标称长度并不保证能用好中间部分。

开放权重还是托管。 自托管意味着数据不离开你的基础设施，成本也从按 token 计费变成固定投入。同时也意味着你要自己运维 GPU。稳定高流量或有严格数据驻留要求时值得，其他情况下很少值得。

数据处理。 输入是否会被留存或用于训练，是一个合同问题，而且对受监管的业务来说常常是决定性的。

结构化输出支持。 如果你需要有保证的 schema，受约束生成的支持比基准测试上多几分更重要。

谨慎看待基准测试

公开基准测试对你具体任务的证据力很弱。它们是聚合结果，有时被训练数据污染，而且从不用你的 prompt 测你的输入。

用它们缩小候选范围，然后拿自己的样本去测。二十个来自你真实业务的案例，比任何排行榜都更能说明问题。

估算成本

每次请求：输入 token 加输出 token，分别计价，输出更贵。

真实账单里，主导成本的是两件事：

对话历史。 每一轮都要重发，成本随长度呈平方增长。给历史上限通常是最有效的一根杠杆。

检索来的上下文。 RAG 的文本块每次调用都要算输入 token。5 块够用时却检索 20 块，就是永远贵四倍。

优化之前先在真实流量上测。估算一向不准，通常就是栽在历史增长上。

要点回顾

• 用 档位 思考，别记模型名——框架比模型发布活得久。
• 从小档起步，实测失败再升档。 为抽取付前沿模型的价格，是最常见的可避免浪费。
• 大模型的钱花在多步推理、正经代码生成、细微判断和长上下文综合上才值。
• 按任务路由——机械步骤用便宜模型，只在需要的地方用贵的。
• 基准测试用来缩范围，自己的样本才是决定者。

下一篇： 响应为什么要流式输出