大模型 API 降本十招：按性价比排好序，从不换模型开始
降本不是一上来就换便宜模型。真正的顺序是先改结构，再谈单价——把输入砍下来、把重复前缀交给缓存、把简单任务分流给小模型，这三步做完，多数项目已经不用换模型了。
下面十招按性价比从高到低排。每一招都给出适用场景和代价，别照单全收，挑你场景对得上的做。想边做边验证效果，用月成本估算器把改动前后的用量分别代一遍。
一、砍掉 system prompt 里的废话
很多项目的 system prompt 是一层层加需求堆出来的，里面有大量重复约束、过时规则、以及模型本来就会做的事。这段内容每次请求都要发一遍，多轮会话里更是反复发。
做法：把 system prompt 打印出来通读一遍，删掉重复项，把长篇解释压成短指令。压掉三成很常见，而效果通常没有变化。压完粘进 token 计算器对比一下前后。
二、裁剪对话历史
多轮场景里输入是累加的，第十轮要重发前九轮。不管这件事，成本会随会话长度快速上升。
做法：滑动窗口保留最近几轮，更早的用便宜的小模型压成摘要。摘要的成本相对于省下的重发，几乎可以忽略。
三、开提示缓存
如果每次请求的前缀高度一致（固定 system prompt、固定工具定义、固定知识片段），提示缓存命中后这部分按很低的折扣价计费。
关键在于把稳定的内容放前面、变化的内容放后面，缓存才命中得了。很多项目开了缓存却没效果，原因就是把时间戳、随机 ID 之类的东西放在了前缀里，导致每次前缀都不同。
四、给 max_tokens 一个贴合场景的上限
输出单价通常是输入的几倍，而 max_tokens 设得越大，模型越可能一路写下去。给一个和你场景匹配的上限——分类任务几十 token 就够，没必要留几千。
配套做法是在 prompt 里明确要求简洁输出，双管齐下。
五、简单任务分流给轻量档模型
分类、抽取、格式化、意图识别这类任务，轻量档模型往往够用，单价可能只有旗舰的几分之一。
常见架构是两级：先用小模型跑，附带一个置信度判断，拿不准时才升级到大模型。实际项目里能被小模型消化的请求比例常常超出预期。
六、能异步的走批处理
多数厂商的 Batch 接口价格是实时接口的一半左右。数据清洗、批量打标、离线摘要这类不要求秒回的活，走批处理直接省一半。
代价是延迟不可控，所以只适合真的能等的场景。
七、用检索替代整份文档
把三十页文档整份塞进上下文，和检索出相关的三段再塞进去，成本差一个数量级，而且后者往往更准——噪声少了，模型更容易抓住重点。
例外是需要跨全文关联的任务，那种情况检索会切断上下文，只能用长窗口。怎么判断，看上下文长度怎么选。
八、用结构化输出减少重试
输出格式不稳定导致解析失败、然后重跑，是很隐蔽的一笔成本。用 JSON schema 约束、function calling 或厂商提供的结构化输出能力，把格式错误率压下去，重试自然少。
这一招省的不只是钱，还有你排查问题的时间。
九、把并发和重试策略调对
限流触发的重试全部照常计费。并发开太猛撞限流、退避策略太激进又反复重发，都会白烧钱。
做法：按厂商给的 RPM/TPM 上限设客户端并发，重试用指数退避加抖动，设最大重试次数，区分可重试错误（限流、超时）和不可重试错误（参数错、鉴权错）——后者重试多少次都是浪费。
十、最后才是换模型
前九招做完再来看单价。这时候你对自己的用量结构已经很清楚了，去价格对比表看单价、用模型横向对比把候选并排看，代进月成本估算器按真实输入输出比排序。
换模型的隐性代价别忽略：prompt 要重调、输出格式要重验、效果要重测。省下的钱要能覆盖这些工时才划算。
每一招的代价，别只看收益
降本手段都有副作用，上线前先想清楚你愿意付什么。
砍 system prompt 的风险是约束变松、输出格式开始飘。做法是一次只删一块，删完跑一遍回归样本，确认输出没退化再删下一块。一次删一半然后发现效果崩了，你会不知道是哪句话的问题。
裁剪历史的风险是模型「忘事」，用户问「刚才说的那个」它接不上。摘要压缩能缓解，但摘要本身会丢细节。折中做法是关键事实单独抽成结构化记忆常驻，其余历史该裁就裁。
提示缓存几乎没有效果副作用，但有工程要求：前缀必须稳定。项目里那些看起来无害的动态内容（当前时间、请求 ID、随机排序的知识片段）只要出现在前缀里，缓存就永远命中不了。上线后一定要用命中率指标验证，不要假设它生效了。
分流小模型的风险最实在：小模型判断错了，用户直接感知。所以分流一定要配置信度兜底和抽样人工复核，把「小模型可以处理」的边界圈准，宁可保守一点。
降 max_tokens 的风险是回答被截断。给上限的同时要在 prompt 里明确要求简洁，让模型主动收尾，而不是被硬截。
哪些招不该一起上
别同时砍输入和换模型。 两个变量一起变，效果掉了你分不清是谁的锅。降本改动建议一次一个，每次都跑同一批回归样本对比。
缓存和历史裁剪要协调。 如果你的裁剪策略每轮都改变前缀内容，缓存就会持续失效。正确姿势是把不变的部分（system prompt、工具定义）放最前面，把会变的历史放后面，两者井水不犯河水。
Batch 和实时不要混在一个链路里。 批处理延迟不可控，混进实时链路会让超时策略变得难以推理。物理上分开两条路径，各自设各自的重试和超时。
一个务实的执行节奏
十招不要一次全上。建议分三轮，每轮之间留出观察期。
第一轮（一两天就能做完）：砍 system prompt、给 max_tokens 设上限、清理输入里的多余空白。这三件事不改架构、不动模型，风险最低，收益立刻可见。做完观察一周，看单位成本降了多少。
第二轮（一两周）：上提示缓存、裁剪历史、调并发与重试策略。这一轮涉及请求结构调整，需要配套的命中率和重试率指标来验证是否真的生效——很多团队以为开了缓存，实际命中率接近零却毫无察觉。
第三轮（视情况）：模型分流、批处理改造、检索替代长上下文。这一轮改动最大，要配回归样本和抽样人工复核，确认效果没退化。
三轮做完再回头算总账，多数项目的单位成本能降到原来的一半上下，而且用户侧几乎无感。这个数字比换一个便宜模型能省的更多，也更可持续——因为它优化的是结构，不是赌某家不涨价。
配套的一件事：先能看见，才能优化
上面十招都需要数据支撑——哪个接口最烧钱、哪类请求的输入最长、重试率多少。没有埋点就只能凭感觉优化。
最小可用的埋点是：每次调用记录模型名、输入 token、输出 token、是否命中缓存、是否重试、耗时。有了这几个字段，账单异常时能在几分钟内定位到具体接口。具体做法可以看 API 成本监控和 API 配额规划。