顺序很关键
常见的降本手段有四类：缓存、批处理、路由（大小模型分工）、提示词瘦身。它们的性价比与风险完全不同，建议按下面的顺序做：
第一步：缓存（收益最大、风险最小）
先回答一个统计问题：你的请求里有多少是重复或高度相似的？
批量任务里这个比例常常高得惊人（同一段模板、同一批分类标签）。
- 精确缓存：请求体哈希后直接返回旧结果，适用于幂等的分类/抽取任务；
- 语义缓存：相似度超过阈值就复用，要谨慎——阈值偏低会把「相似但不同」的问题答错；
- 缓存键要包含模型、提示词版本、参数，否则换了模型还在吃旧结果。
⚠️ 缓存最容易踩的坑：把带时效性的问题缓存了（价格、库存、新闻）。这类要么设短过期，要么不缓存。
第二步：批处理（摊薄固定开销）
把能并行的小请求合成一次调用（或交给支持异步批量的接口），可以显著提高吞吐、降低成本。
前提是任务互不依赖；如果任务 B 需要任务 A 的结果，合批只会让错误传播得更快。
第三步：路由（大小模型分工）
只有前两步做完，路由才有意义：
- 简单任务（分类、格式化、短抽取）→ 小模型；
- 复杂任务（多步推理、长文分析）→ 大模型；
- 判据要可度量：按输入长度、是否命中规则模板、历史失败率来分流，不要凭感觉。
路由最容易伤质量的地方是没有兜底：小模型答错时没有人发现。建议对分流结果做抽样复核（例如 2% 人工看，或大模型抽检）。
第四步：提示词瘦身
删掉冗余说明、重复示例、无效约束——这部分省的是输入 token，通常占比不大，但零风险。
不建议用的两种「省法」
- 砍掉输出校验：省了钱，但错误会流到下游，返工成本远高于省下的钱；
- 把温度调到极低就以为更便宜：温度不影响价格，只影响输出长度分布，别把它当降本手段。
一个可执行的降本清单
- 统计重复率，做精确缓存（含模型与提示词版本）；
- 统计平均输入/输出长度，找出最贵的 10% 请求；
- 对这 10% 做路由或提示词瘦身；
- 每次只改一项，用同一批真实请求回归正确率与成本；
- 建立成本与质量的看板——只盯成本会不知不觉把质量赔进去。