缓存、批处理、降级：压住大模型 API 账单的三板斧实战复盘

缓存、批处理、降级：压住大模型 API 账单的三板斧实战复盘

第一季度我们的大模型 API 账单环比涨了 70%，而业务量只涨了 30%——多出来的 40%，全是工程上的浪费。花了一个月做调用侧治理，账单回落到比治理前低两成的水平。先说结论：便宜不只取决于选哪个入口，更取决于你怎么调用。下面是三板斧的具体复盘。

第一板斧：缓存，先把重复的钱省掉

打开调用日志做指纹统计，我们吓了一跳：约 22% 的请求语义上是重复的——同一篇文档被不同用户触发摘要、同一个报错被反复问。两层缓存解决：

请求级缓存：对"系统提示 + 用户输入 + 模型名"做哈希，命中直接返回。注意要做轻量归一化（去首尾空白、统一标点），否则命中率会被无意义的差异打掉。

import hashlib

def cache_key(model: str, system: str, user_input: str) -> str:
    norm = " ".join(user_input.split())
    raw = f"{model}|{system}|{norm}"
    return hashlib.sha256(raw.encode()).hexdigest()

前缀缓存：把长系统提示、固定知识库片段放在消息最前面且保持字节级一致，凡是支持上下文缓存的入口，命中部分的输入计价通常只有原价的一到两成。我们一个 RAG 场景的输入成本因此降了约 35%。

第二板斧：批处理，让不着急的请求排队走

把请求按时效拆成两类后发现，近一半流量其实不需要秒回：夜间报表、文档预处理、打标签，全是攒一批慢慢跑也没人抱怨的活。做法有两层：

• 入口支持批处理接口的，离线任务全部走批量提交，这类接口的折扣普遍在五折上下；
• 不支持的，自己在队列里错峰：高峰期只放行在线流量，离线任务压到凌晨跑，顺带避开了限流高发时段——省钱的同时把 429 错误率也压下去了。

第三板斧：降级，稳定性和成本一起兜底

降级链是三板斧里对"稳定"贡献最大的一件事。我们的规则：

1. 主模型超时或限流，先在同档位换一个上游重试一次；
2. 再失败，降一档用轻量模型给出兜底回答，并打上降级标记记日志;
3. 连续触发降级超过阈值就告警，人工介入。

要做到第 1 条，接入层就不能和单一上游焊死。我们统一走 OpenAI 兼容的 /v1 规范，base_url 用环境变量注入（自建开源网关如 OneAPI、或第三方统一接入服务如 kkaiapi 等都支持这种形态，具体稳定性需自行实测），换上游只动配置不动代码。

一笔总账

按示例口径：缓存砍掉约两成重复调用，批处理给四成离线流量打了对折，降级把重试浪费从 6% 压到 2%——三项叠加，相当于在不换模型、不降质量的前提下把综合单价打了个七折左右。

注意事项

• 缓存要设 TTL，知识更新后的旧答案比没答案更糟；
• 降级回答必须可识别，别让兜底输出混进正式数据；
• 每月复盘一次调用日志，浪费是会复发的。

工具和入口会一直变，但"少调、错峰、留退路"这九个字，到哪都管用。