提示缓存和批处理该用哪个？两种降本手段的适用边界
缓存和批处理都能省钱，但省的是完全不同的钱：缓存省的是「重复内容重复算」的钱，批处理省的是「你愿意等」的钱。前者要求前缀稳定，后者要求时效可放宽——两个条件互不相干，所以它们不是二选一。
这篇讲怎么判断该上哪个、能不能一起上。想把两种方案的成本分别算出来对比，用月成本估算器。
两者的省钱机制完全不同
提示缓存的原理是复用：请求前缀相同时，把已经算过的中间状态存下来直接用，命中部分按很低的折扣价计费。它的前提是同一段内容被多次发送。
批处理（Batch）的原理是错峰：你把一批请求打包提交，厂商在算力空闲时慢慢处理，作为交换给你一个明显的价格折扣（普遍是五折量级）。它的前提是你不着急要结果。
一个看重复率，一个看时效性。搞清楚这一点，选择就简单了。
什么场景该用缓存
高频、前缀稳定、要求实时。 典型的是线上客服问答、代码助手、实时文档问答。这类场景不能等，批处理直接出局；但它们的 system prompt、工具定义、常驻知识每次都一样，正是缓存的主场。
判断标准很直接：把请求拆成固定部分和变化部分，固定部分占比高（比如超过一半），且调用频率足够让缓存在存活期内被反复命中，就该上缓存。
具体怎么把命中率做上去，见提示缓存命中率上不去？八个常见原因。
什么场景该用批处理
大批量、可延迟、每条请求各不相同。 典型的是历史数据打标、批量摘要生成、离线内容审核、evaluation 跑分。
这类场景的特征是：一次要处理成千上万条，每条内容都不一样（缓存帮不上大忙），但结果什么时候出来不影响业务——今晚提交、明早拿结果完全可以接受。
用批处理的收益是直接的价格折扣，代价是延迟不可控。所以千万别把批处理塞进用户等待的链路里。
能不能一起用
能，而且很常见。批处理任务里同样有固定前缀（同一套指令跑一万条数据），如果厂商的批处理接口也支持缓存，那就是折上折。
不过要注意两点：
一是要确认厂商是否支持组合。 各家的批处理实现不同，有的走独立通道、缓存策略也不同。以官方文档说明为准。
二是批处理的额度通常独立于实时额度。 这其实是个好消息：把离线任务挪到批处理，不只省钱，还把实时额度腾出来给真正需要它的请求。额度这一块的原理见 RPM 和 TPM 是什么。
选错的代价
该用批处理却走实时：多付大约一倍的钱，还占用实时额度，高峰期把线上请求挤到限流。这是最常见也最可惜的浪费——一批凌晨就能跑完的活，非要在白天抢通道。
该用缓存却没开：固定前缀反复按全价计费。前缀越长、频率越高，损失越大。而且这种浪费完全无感，账单上看不出异常，只有和「本可以花多少」对比时才发现。
把批处理塞进实时链路：用户点了按钮等半天没反应。这个错误一上线就会被投诉，反而是最容易发现的。
一个简单的决策表
问自己两个问题：
问题一：结果能等吗？ 能等（几小时以上）→ 优先批处理。不能等 → 只能实时，跳到问题二。
问题二：请求前缀重复吗？ 重复率高 → 上缓存。重复率低 → 缓存帮不上忙，回到基础优化：压缩输入、控制输出长度、简单任务分流小模型。
两个问题都是「否」的场景（不能等、前缀又不重复），说明你的成本大头在真实的变化内容上，那就该从输入长度和模型选型上想办法了——见大模型 API 降本十招。
批处理改造的五个实现要点
决定上批处理之后，工程上要处理这几件事，比想象中琐碎。
一、任务提交与结果取回是异步的。 提交后拿到一个任务 ID，之后轮询状态或等回调。这意味着你的业务流程要能容忍「提交了但还没结果」的中间状态，数据模型要加状态字段。
二、部分失败要能处理。 一批一万条，可能有几十条失败。要能识别出哪几条失败、为什么失败、以及只重跑失败的部分。整批重跑是最贵的错误处理方式。
三、批次大小要权衡。 太小则批处理的调度开销占比高，太大则单批耗时长、失败影响面大、中途出问题损失也大。实践中按几百到几千条一批比较常见，具体看厂商限制。
四、结果要能对回原始数据。 提交时给每条请求一个自定义 ID，结果回来时按 ID 对应。别依赖顺序——异步处理不保证返回顺序。
五、超时与兜底。 批处理有最长处理时限，超时未完成时怎么办要提前想好：转实时接口跑、还是标记失败下个周期再来。
一个常见的混合模式
实践中很实用的一种组合：实时链路 + 离线预热。
思路是把可以预测的请求提前用批处理跑好，存起来；用户真正请求时直接返回缓存的结果，只有预测不到的才走实时接口。
典型场景是内容平台的摘要、标签、推荐理由这类——大部分内容是提前入库的，完全可以在入库时用批处理批量生成，而不是等用户点开时实时生成。
这个模式同时拿到了批处理的价格优势和实时的体验，代价是要维护一层结果存储和失效策略。对于读多写少的场景，收益非常可观。
别忘了工程成本
批处理需要改造调用方式（提交任务、轮询状态、取回结果、处理部分失败），不是改个参数就完事。小规模任务的改造成本可能超过省下的钱。
缓存的改造成本低得多（主要是调整请求拼装顺序），但需要配套的命中率监控，否则你不知道它有没有生效。
所以实践中的常见顺序是：先上缓存（改动小、见效快），量大了再做批处理改造（收益随规模线性增长，值得投入工程）。
三个高频问题
问：批处理的结果什么时候能拿到？ 各家承诺的时限不同，通常以小时计。做产品设计时按最长时限规划，别按平均值。
问：批处理失败了会退钱吗？ 一般失败的条目不计费，但成功的部分照常收。以厂商的具体规则为准。
问：小批量值得走批处理吗？ 通常不值得。改造成本固定，收益随量增长，量小的时候收益覆盖不了工时。