API账单能砍掉50%，但坑太多了
上周翻账单，盯着那个数字看了好久。
光上个月调用 GPT-4 的 API，烧了 2387 块。我一条条对下来，至少有 600 多块是重复计算那些压根没变过的系统提示词。那一刻我突然意识到一件事——我们天天喊降本增效，结果连缓存这茬都没几个人真正搞明白。
今天聊聊大模型缓存感知架构下的 Token 计费模式。搞懂了，你的 API 账单能直接砍掉 30% 到 50%。不夸张。
先搞清楚：什么是缓存感知架构？
说白了，就是 LLM 服务商在后台识别出你请求里那些重复的部分，跳过计算，直接复用之前的结果。这部分不收费，或者少收费。
但这里有个巨坑。
各家服务商的缓存策略完全不一样，计费规则也千差万别。你以为在省钱，可能一分没省；你以为在浪费，人家早帮你优化了。
我去年 11 月做 AI 客服项目的时候就踩过。当时用某国产大模型的 API，每次请求带将近 2000 个 token 的系统提示词，里面塞满业务规则和话术模板。我天真地以为服务端会自动缓存，结果跑了两个月，账单出来人傻了——那 2000 个 token 每次都按全价算，一个月多花将近 4000 块。
后来找他们技术 support 聊，对方很直接：他们那会儿根本没开 prompt caching，或者说只对某些特定模型开放，而且需要你在请求头里显式标记。你不标记？默认全量计算。
嗯...这个说起来挺无语的，但确实是我的锅。没看文档就假设了。
主流服务商缓存计费对比（我实测的）
花了两周，把手头在用的几个服务商都测了一遍。数据你们参考：
OpenAI（GPT-4o / GPT-4o-mini）
2024 年 10 月正式上线 Prompt Caching。注意，只对超过 1024 token 的请求生效。缓存命中后，这部分 token 价格打五折。
我测下来，一个典型的 RAG 场景（系统提示词 1500 token + 用户问题 200 token），缓存命中率能做到 85% 以上，单次请求成本从 $0.012 降到 $0.008 左右。
坑在哪？
缓存有 TTL。官方说 5 到 10 分钟，我实测大概 7 分钟左右失效。而且如果你在两次请求之间改了系统提示词哪怕一个字，缓存全部失效，重新计算。我有次上线前临时改了个错别字，那一个小时的缓存命中率直接归零。账单飙上去。
等等，这里我要更正一下——OpenAI 在 2025 年 1 月更新了缓存策略，现在 TTL 延长到了最长 1 小时，但前提是请求间隔不超过 5 分钟。也就是说它会自动续期。这个改动用的人还不多，我是在他们社区 changelog 里翻到的。
Anthropic（Claude 3.5 Sonnet / Haiku）
Anthropic 的缓存策略是我见过最激进的。2024 年 8 月推出 Prompt Caching，缓存命中的 token 价格直接降到原来的 10%。打一折。
我那个 AI 写作助手，系统提示词将近 3000 token，用 Claude 3.5 Sonnet，缓存命中后单次请求成本从 $0.045 降到 $0.012，省了 73%。
代价呢？
TTL 只有 5 分钟。而且你必须在 API 请求里显式标记哪些是"cache breakpoint"。这文档写得特别绕，我第一次集成搞错了标记位置，缓存命中率一直是 0，跑了三天才发现。Claude 的缓存只对完全匹配的内容生效，多一个空格都不行。我建议系统提示词用变量拼接，确保每次传过去的字符串完全一致。
DeepSeek（V3）
DeepSeek 比较特殊。2024 年 12 月上线"上下文缓存"，但目前只对连续对话场景生效——你必须在同一个 session_id 下发起请求，缓存才会被复用。单次 API 调用不支持。
计费方面，缓存命中的输入 token 完全免费，只收输出 token 的钱。对客服、教育这类多轮对话场景特别友好。我有个做在线辅导的朋友，切到 DeepSeek V3 后输入 token 成本直接砍掉 60%。
坑也有。session 有效期只有 30 分钟，超时自动清空。而且目前只支持文本场景，多模态请求暂时用不了缓存。据我了解，他们团队在搞多模态缓存支持，但具体上线时间还没定，大概 Q2 吧。
三个教训
教训一：别指望服务商自动帮你优化
去年做法律文书生成工具，用某二线国产模型。系统提示词将近 4000 token，我以为服务商肯定会自动缓存。跑了三个月，账单居高不下。后来直接找他们技术负责人聊，对方很坦诚："我们现在确实没做服务端缓存，会影响推理集群的调度效率。"
别想当然。
翻文档，问技术支持，去 GitHub 搜 issue。如果服务商没提供缓存，你就得自己在业务层做——把系统提示词和用户输入分开管理，静态内容放本地，必要时拼接发送。
教训二：缓存 TTL 比你想象的短
前面说了，OpenAI 的缓存 TTL 是 5-10 分钟（现在最长 1 小时但要续期），Anthropic 是 5 分钟，DeepSeek 的 session 是 30 分钟。
我那个 AI 客服项目，用户平均对话间隔是 8 分钟，刚好卡在 OpenAI 的缓存失效边缘。后来做了个优化：客户端加心跳机制，每隔 4 分钟发一个空请求（只带系统提示词，不带用户输入），保持缓存活跃。缓存命中率从 40% 提升到 75%，一个月省了将近 2000 块。
这个方案有点 hack。但管用。
教训三：计费粒度比你想象的细
很多人以为"缓存命中"就是整段不收费。不是。
以 OpenAI 为例，他们按"前缀匹配"计费。假设你的请求是 [系统提示词 A + 系统提示词 B + 用户输入]，如果只有 A 命中了缓存，A 的部分打五折，B 和用户输入还是全价。
所以，把最稳定、最长的内容放前面，容易变化的内容放后面。我现在把系统提示词拆成两部分：核心规则（基本不改）放最前面，业务场景描述（偶尔调整）放后面。这样即使后面没命中缓存，前面 80% 的内容还是能省下来。
你的产品适不适合做缓存优化？
判断标准很简单：系统提示词超过 500 token，且 80% 以上的请求共享同一套提示词，那你必须做缓存优化。
操作上分三步：
1. 先看服务商支不支持。翻文档，搜"prompt caching""context caching""prefix caching"。搞清楚 TTL、命中规则、计费方式。用 curl 或者 Postman 直接发测试请求，看响应头里有没有 x-cache-hit: true 之类的标记。
2. 再看你的请求模式。拉日志，看系统提示词平均长度、请求间隔、提示词变化频率。如果间隔超过 TTL，要么加心跳，要么在业务层做本地缓存。我一般用 LangSmith 或者自己写脚本分析。
3. 最后做 A/B 测试。开两组实验，一组用缓存，一组不用，跑一周对比成本和延迟。别只看成本，有些服务商缓存命中后延迟能降低 30%-50%，用户体验也是加分项。我习惯用 promptfoo 这个工具跑对比测试，配置简单，结果直观。
说点实在的
我现在产品的月调用量大概 300 万 token，通过缓存优化，输入 token 成本从 $0.01/1K token 降到 $0.005 左右，一个月省将近 $1500。这钱说多不多，但对一个还在跑 PMF 的小团队来说，够付半个月服务器费用了。
而且说实话，缓存优化这事儿技术门槛不高。主要考验你对服务商文档的阅读理解能力。很多人不是做不了，是压根不知道有这回事。我上周在 V2EX 上看到有人吐槽 API 费用高，点进去一看，系统提示词 2000 多 token 每次都全量计算，完全没做缓存。底下回复也没几个人提到 prompt caching。
我觉得这个行业有个问题——大家都在追新模型、新架构，但工程落地这些"脏活累活"反而没人聊。其实把这些细节搞好了，省下来的钱比你想的多得多。
你们现在用的哪个模型？有没有做过缓存优化？评论区聊聊，我也想看看各家最新的缓存策略有没有变化。如果你有更好的省钱技巧，别藏着掖着，说出来大家一起薅羊毛。
#LLM成本优化 #PromptCaching #Token计费 #API降本 #大模型工程实践 #IndieHacker心得
读者评论 4