大模型 API 的成本通常在流量增长后才变得明显。最常见的反应是立即切换到更便宜的模型，但如果没有请求级数据，这种优化很容易以准确率、稳定性或人工返工为代价。
更可靠的顺序是：先计量，再减少无效 token，最后为不同任务建立模型路由。
成本从哪里来
一次调用的费用可以粗略理解为：
总成本 = 输入 token 成本 + 输出 token 成本 + 额外调用成本实际系统中，输入 token 往往比预想中增长得快。完整聊天历史、重复的系统提示、没有裁剪的检索片段，以及多轮工具调用都会持续推高上下文长度。
所以先不要只看每天花了多少钱，而要把成本关联到每一个请求：
| 指标 | 用途 |
|---|---|
| 输入 / 输出 token | 定位上下文膨胀或输出失控 |
| 模型与版本 | 识别不同路由的成本结构 |
| 任务类型 | 判断哪类请求值得使用高能力模型 |
| 首次成功率 | 防止低价模型造成重试与返工 |
| 端到端耗时 | 平衡成本与交互体验 |
有了这些数据，才知道优化应从哪里开始。
先减少没有价值的上下文
在多数应用里，减少无效输入的收益比更换模型更直接。
不要重复发送固定提示
稳定不变的指令应尽量复用，并让服务端或缓存机制识别其重复性。业务侧也要避免在每轮对话中拼接同一段长说明。
检索只取真正相关的片段
RAG 系统不应把「排名靠前的所有内容」直接塞给模型。可以先用关键词、元数据和相似度做召回，再用重排或阈值过滤。每个片段都应能回答一个问题：它是否为当前结论提供了不可替代的信息？
为输出设置明确上限
没有 max_tokens 的生成容易在边界情况下持续扩张。对于摘要、分类、字段抽取等任务，应要求结构化输出并限制长度；对于长文生成，则将大任务拆成可审阅的小段。
路由不是「默认用小模型」
合理的多模型路由，需要先按任务风险和难度分层：
| 任务 | 合适的策略 |
|---|---|
| 意图分类、标签提取、格式转换 | 低成本模型 + 严格结构校验 |
| 知识库问答 | 以检索质量为先，模型按答案复杂度升级 |
| 代码、复杂推理、重要决策支持 | 高能力模型，并保留人工审核入口 |
| 失败重试 | 先保留相同输入和失败原因，再有条件升级模型 |
路由器本身也应该简单、可解释。不要用一次昂贵的大模型调用来决定是否需要调用大模型；规则、置信度、请求长度和用户显式选择通常足以处理第一层分流。
缓存要以语义正确为前提
缓存能降低重复调用，但缓存命中错误比缓存未命中更危险。设计时至少要考虑：
- 缓存键是否包含模型、提示版本、用户权限和知识库版本
- 内容发生变化后如何失效
- 哪些答案可以跨用户复用，哪些必须隔离
- 是否允许用户看到缓存来源和生成时间
对于纯转换、公开且稳定的知识问答，缓存通常很有效；对于实时数据、个性化内容和权限敏感问题，则应谨慎使用。
评估优化是否真的有效
只看账单下降是不够的。一次优化上线后，至少同时对比：
- 单请求平均成本与 P95 成本
- 首次成功率、重试率和人工修正率
- 用户完成任务的总耗时
- 不同任务类型的质量抽样结果
如果成本下降但重试和人工接管大幅上升，系统只是把成本从 API 账单转移到了运维和人力。
结语
成本控制的核心不是「少用模型」，而是让模型能力与任务价值匹配。先建立可观测的请求数据，持续削减无效上下文，再以质量约束驱动分层路由，才能让成本、体验和可靠性一起改善。