教程：用提示缓存与批量接口把推理成本再砍一层

降本的第一反应通常是「换个便宜模型」，但换模型要重新验收效果，代价不小。真正无损的降本，来自把「重复的算力」和「不着急的算力」分别处理掉——对应的就是提示缓存与批量推理。

提示缓存：为重复的前缀付费一次

多轮对话里，系统提示词、知识库片段、历史轮次每一轮都要重新送一遍，这部分 token 占了请求的绝大部分。提示缓存把这段**前缀**缓存起来，后续请求只按折扣价计费。

命中缓存的前提是「前缀完全一致」——哪怕改动一个空格，缓存就会失效。这是实践中最常见的坑。

• 把稳定不变的内容放前面：系统提示词、工具定义、固定知识片段
• 把每次都变的内容放后面：用户输入、时间戳、随机 ID
• 不要把时间戳、请求 ID 之类放进前缀，否则每轮都是新前缀
• 观察命中率指标，低于 50% 说明结构没排好

批量推理：用时间换价格

如果你的任务不要求实时返回——离线打标、批量摘要、历史数据回填、内容生成——那么批量接口通常有明显折扣，代价是结果在窗口内异步返回（常见为 24 小时内）。

接入形态一般是：提交一个批次任务 → 拿到 batch id → 轮询结果或用 Webhook 接收完成事件。

两者怎么配合

批量任务里往往包含大量相同的前缀（同一份系统提示词 + 同一套规范），所以批量与缓存可以叠加：批量解决「不急」，缓存解决「重复」。先做批量、再把批量请求的公共前缀排整齐，是成本下降最快的一条路径。

什么时候别用

实时对话场景用不了批量推理——用户不可能等 24 小时。缓存也要注意：如果业务每次请求的系统提示词都是动态拼出来的（比如塞了实时数据），命中率会低到没有意义，这时候应该先把结构拆开：动态的走变量注入，静态的留在前缀里。

成本优化的顺序建议是：先把可观测性装好（知道钱花在哪），再做提示缓存（结构改造，无损），再考虑批量（牺牲实时性），最后才是换模型（影响效果）。这个顺序反了，很容易省下小钱、赔上体验。