平衡模型可能降低真实总成本
Claude Sonnet 4.6 API cost 不能只看单价。一个平衡模型如果能以更低延迟、更少重试和足够质量完成任务，真实总成本可能低于更强模型。
用于生产规划前，必须确认当前官方价格和模型信息。最终估算应使用 模型价格表 和 文本模型成本计算器。
按任务比较，不按模型名比较
同一个模型在不同场景下成本差异很大。短分类、客服回复、长文档摘要和 Agent 工具循环，成本结构完全不同。
先从任务开始：
| 任务类型 | 需要记录 |
|---|---|
| 分类 | 输入长度和标签输出长度 |
| 客服回复 | 上下文、回答长度、编辑率 |
| 内容生成 | 提纲长度、初版长度、修改次数 |
| 编程辅助 | 代码上下文、补丁输出、测试重试 |
| Agent 工作流 | 模型调用、工具返回、循环重试 |
如果 Sonnet 能稳定完成任务，它可能是更好的默认模型。如果它导致多次重试或大量人工修改，更强模型反而可能更省。
估算重试的真实成本
单次请求便宜，不代表完整任务便宜。格式错误、回答质量不足、约束遗漏和工具参数修正都会造成重试。
建议记录：
- 回答可接受率；
- 重试次数；
- 人工修改时间；
- 平均输出 token；
- 超时或工具调用失败；
- 升级到更强模型的比例。
这些指标比单价更能反映真实成本。
Sonnet 适合重复性中等复杂任务
平衡模型通常适合质量要求较高但不需要最高推理上限的重复任务：
- 客服回复版本；
- 中短摘要；
- 内容提纲；
- 明确 schema 的信息抽取；
- 内部工具助手；
- 初步分类；
- 大型 Agent 中的普通步骤。
更难的任务可以单独路由到更强模型。混合路由通常比所有请求都走最高模型更省。
输出长度也是预算杠杆
即使是平衡模型，如果每次都输出很长，也会变贵。换模型前，先控制输出。
可用方法包括：
- 限制章节数量；
- 使用简洁回答模板；
- 使用固定 JSON schema；
- 限制 bullet 数量；
- 控制摘要长度；
- 区分短模式和长模式。
要用真实被接受的回答统计输出 token，而不是理想样例。很多追加问题，来自第一版回答太长或太空泛。
路由方案
可以从这张表开始：
| 请求模式 | 建议路由 |
|---|---|
| 短抽取或分类 | 平衡模型或更小模型 |
| 普通客服/内容生成 | Sonnet 类平衡路线 |
| 长上下文推理 | 评估更强模型 |
| 多工具 Agent | 简单步骤用 Sonnet，规划步骤用更强模型 |
| 高风险最终回答 | 升级模型或人工复查 |
这样预算更灵活。之后可以根据实测准确率和成本调整路由。
计算器流程
- 选 20-50 个真实请求。
- 记录输入 token、输出 token、重试和可接受率。
- 估算每个完整任务的成本。
- 把重试算进去后，再比较 Sonnet 和更强模型。
- 用 文本模型成本计算器 估算常见请求。
- 用 模型价格表 更新官方价格假设。
FAQ
Sonnet 一定比 Opus 便宜吗？
不一定。单次调用可能更便宜，但总成本还取决于重试、输出长度和结果可接受率。
什么时候该用更强模型？
当错误代价高、推理很深，或 Sonnet 多次重试抵消节省时，应考虑更强模型。
一个产品可以混用模型吗？
可以。常见做法是简单步骤走平衡模型，复杂规划、复查和升级任务走更强模型。