Skip to content
Published on

LLM API 成本如何真正降下来 — 「缓存 90% 折扣」到了账单上为什么只有 25%

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
分享
Authors

引言 — 折扣率不是账单的节省率

「打开提示词缓存就能便宜 90%」这句话，是 LLM 成本文章的常客。它只对了一半。缓存读取的单价是基本输入单价的十分之一，这没错，但那只是缓存读取这一个行项目的折扣率。要让整张账单都降那么多，你花的每一分钱都得是可缓存的输入 token 才行。现实并非如此。

先把答案摆出来。折扣只按该项目在账单中所占的比重来缩减总额。看 Anthropic 直接放在自家价格文档里的计算示例：用 Claude Opus 4.8 跑一个输入 5 万 token、输出 1.5 万 token 的 1 小时会话，成本是 0.705 美元。这时如果输入 5 万中的 4 万 token 变成缓存读取，总额变成 0.525 美元。输入成本从 0.25 美元砍到 0.07 美元，降了 72%，总额却只减少了 25.5%。因为输出 token 本来就吃掉了成本的大头。

所以本文不罗列折扣率，而是直接把账单算出来。缓存为什么有效(Transformer 内部 KV 缓存的那套故事)，已经在LLM 缓存的原理一文里讲过；服务引擎如何把它跑起来，也已经在Prefill·Decode 分离与 goodput一文里讲过。这里只彻底地看买 API 来用这一侧的经济学。

关于本文的数字 — 价格经常变

LLM 成本文章烂得快，是因为价格经常变。所以先把规则钉死。

  • 本文的所有价格，都是 2026 年 7 月 17 日当天直接取自各供应商的官方价目表页面。没有一个数字来自二手资料、摘要或记忆。
  • 价格说变就变，本文里就有证据 — Claude Sonnet 5 的首发价只到 2026 年 8 月 31 日有效，9 月 1 日起上调。OpenAI 的缓存写入费用是在 GPT-5.6 世代新设的(之前的模型是免费的)。这两个都是「曾经正确的句子」如今不再正确的例子。
  • 无法保证你读到本文时这些数字仍然正确。在做出任何影响付款的决定之前，请务必亲自打开各供应商的价目表。链接在文末的参考资料里。

不变的不是价格，而是计算的结构。本文真正想教的，是这个结构。

我的账单从哪里来 — 输出 token 说了算

在决定优化什么之前，得先看钱漏到了哪里。LLM API 的账单几乎总是拆成三项 — 未缓存的输入、缓存读取，以及输出。

这里有一个大多数人都忽略的事实：输出 token 的单价是输入单价的好几倍。以下数字取自 2026 年 7 月 17 日的 Anthropic 价目表。

模型                        输入(每 100 万 token)   输出(每 100 万 token)   输出/输入 倍数
Claude Opus 4.8                 5 美元                25 美元                5 倍
Claude Sonnet 5 (首发价)         2 美元                10 美元                5 倍
Claude Haiku 4.5                1 美元                 5 美元                5 倍
Claude Fable 5                 10 美元                50 美元                5 倍

Claude 系列清一色是 5 倍。OpenAI 那边倍数更大 — 在 2026 年 7 月 17 日的价目表上，gpt-5.6-sol 按短上下文计是输入 5 美元 / 输出 30 美元，6 倍；gpt-5.6-luna 是 1 美元 / 6 美元，同样 6 倍。

这为什么重要?把 Anthropic 文档的计算示例原样搬过来(Opus 4.8，输入 5 万、输出 1.5 万 token)：

项目        token 数     占比        成本         成本占比
输入        50,000      76.9%     0.25 美元      40%
输出        15,000      23.1%     0.375 美元     60%
合计        65,000                0.625 美元

输出按 token 数只占 23.1%，按成本却占 60%。要是看着 token 数就断定「问题在输入」，那正好把方向搞反了。

所以第一条实践规则不是优化，而是测量。Anthropic API 会在响应的 usage 里返回 input_tokens、output_tokens、cache_creation_input_tokens、cache_read_input_tokens；OpenAI 会返回 cached_tokens(缓存读取)，并在 GPT-5.6 之后的世代返回 cache_write_tokens(缓存写入)。在把这四个数字分别乘上单价、算出每一项的金额之前，任何优化都只是猜测。

提示词缓存实际能省下多少

现在把开头的计算做完。Anthropic 价格文档的 Managed Agents 一节里，有一张把缓存前后并排放的表。下面照抄那份文档的数字，并做了验算。

[无缓存] Opus 4.8，输入 5 万 / 输出 1.5 万，1 小时会话
  输入          50,000 x 5 美元  / 100 万 = 0.25 美元
  输出          15,000 x 25 美元 / 100 万 = 0.375 美元
  会话运行时     1.0 小时 x 0.08 美元      = 0.08 美元
  合计                                    = 0.705 美元

[启用缓存] 输入 5 万中有 4 万是缓存读取
  未缓存输入     10,000 x 5 美元 / 100 万       = 0.05 美元
  缓存读取       40,000 x 5 美元 x 0.1 / 100 万 = 0.02 美元
  输出          15,000 x 25 美元 / 100 万       = 0.375 美元
  会话运行时     1.0 小时 x 0.08 美元            = 0.08 美元
  合计                                          = 0.525 美元

节省额 = 0.705 - 0.525 = 0.18 美元
节省率 = 0.18 / 0.705 = 25.5%

缓存读取的单价确实是基本输入的 10%(也就是「90% 折扣」)。但总额只减少了 25.5%。

有三点必须指出来。

第一，会话运行时的 0.08 美元是 Managed Agents 专属的项目。普通的 Messages API 里没有这一行。所以单把 token 成本拆出来看，是从 0.625 美元降到 0.445 美元，降幅 28.8%。不管按哪种口径算，都离 90% 远得很。

第二，这个例子假设缓存已经预热完毕。缓存写入的成本不在计算里。第一次请求要额外付写入费，所以实际的首次调用反而更贵。这个盈亏平衡点就在下一节计算。

第三，也是真正的结论 — 缓存之后，输出在 token 成本中的占比上升到 0.375 / 0.445 = 84.3%。缓存抹掉输入项目，反而放大了输出的支配力。当你把缓存正确打开的那一刻，下一个杠杆必然是输出。

缓存要读几次才回本

缓存不是免费的，原因在写入费。截至 2026 年 7 月 17 日，Anthropic 文档给出的倍数(相对基本输入单价)是这样：

缓存操作             倍数               有效期
5 分钟缓存写入     基本输入的 1.25 倍     5 分钟
1 小时缓存写入     基本输入的 2 倍       1 小时
缓存读取(命中)     基本输入的 0.1 倍     与上一次写入相同

假设同一个前缀要发 N 次。不用缓存要付的钱是 N(把基本输入单价记为 1 的相对值)，用缓存则是写入 1 次 + 读取 (N-1) 次。算一下：

5 分钟缓存 (写入 1.25 倍)
  N=1: 无缓存 1.00  vs  有缓存 1.25          -> 用缓存亏
  N=2: 无缓存 2.00  vs  1.25 + 0.10 = 1.35 -> 用缓存赚
1 小时缓存 (写入 2 倍)
  N=2: 无缓存 2.00  vs  2.00 + 0.10 = 2.10 -> 还在亏
  N=3: 无缓存 3.00  vs  2.00 + 0.20 = 2.20 -> 用缓存赚

也就是说，5 分钟缓存从第 1 次读取起、1 小时缓存从第 2 次读取起超过本钱。这与 Anthropic 文档所说的盈亏平衡点严丝合缝，用上面的算式就能直接验算。

对实务真正重要的是这一点：如果你的流量在 5 分钟之内不会有同一个前缀来两次以上，缓存反而增加成本。给一天只进来几次的低频端点开着缓存、再问「怎么没便宜?」的情况，说的就是这个。不过 Anthropic 说明，5 分钟缓存每次被使用时都会免费刷新有效期，所以只要流量持续流动，这 5 分钟就会不断续期。

OpenAI 那边的规则因世代而异。按 OpenAI 文档，GPT-5.6 之前的模型缓存写入不额外收费，从 GPT-5.6 世代起缓存写入是未缓存输入单价的 1.25 倍。「OpenAI 缓存写入免费」这条老常识，在最新世代已经不成立了。缓存读取按 gpt-5.6-sol 算，相对输入 5 美元是 0.5 美元，恰好 10%。结果就是，在最新世代，两家的缓存价格结构(写入 1.25 倍 / 读取 0.1 倍)事实上趋同了。

缓存完全不生效的情况

最虚无的失败，是打开了缓存却什么都没发生。提示词不够最小长度，缓存就是不生效。

按 Anthropic 文档(2026 年 7 月 17 日)，Claude API 上可缓存提示词的最小长度因模型而异：

Claude Fable 5, Mythos 5                       512 token
Claude Mythos Preview, Opus 4.7              2,048 token
Claude Opus 4.6, Opus 4.5                    4,096 token
Claude Haiku 4.5                             4,096 token
Claude Opus 4.8, Sonnet 5, Sonnet 4.6,
  Sonnet 4.5                                 1,024 token

文档在这里加了一个决定性的注脚 — 不足最小长度的提示词，就算加了 cache_control 也会按无缓存处理，而且不会报错。意思是它会静默失败。要确认缓存有没有生效，去看响应里的 cache_creation_input_tokens 和 cache_read_input_tokens，两个都是 0 就是没生效。

还有一点要注意：这个最小值可能因平台而异。Anthropic 文档单独注明，在 Amazon Bedrock 上 Fable 5 和 Mythos 5 的最小长度是 1,024 token。Bedrock 上各模型的最小值、失败行为、字段名，得看 AWS 文档。

OpenAI 的结构更简单 — 按文档，1,024 token 以上的提示词会自动应用缓存，缓存命中只发生在前缀精确一致时。不足 1,024 token 的请求，cached_tokens 会是 0。

从这里引出两家共同强调的设计规则：把固定的内容(系统提示词、示例、工具定义)放在前面，把变化的内容(用户输入)放在后面。缓存只认前缀一致，所以在最前面塞进一行时间戳的那一刻，它后面的全部内容都会掉出缓存。图片和工具定义也必须在请求之间保持一致。

Batch API 的 50% 是真的吗

是真的。而且三家供应商给的是同一个数字。以下内容于 2026 年 7 月 17 日从各家文档确认。

  • Anthropic: Message Batches API「所有用量按标准 API 价格的 50% 计费」。输入和输出两边都是。
  • OpenAI: Batch API 相对同步 API 有「50% 的成本折扣」。可以在价目表上验算：gpt-5.6-sol 短上下文，输入 5 美元 → 2.5 美元，输出 30 美元 → 15 美元。
  • Google: Vertex AI 价格页面明确写着「Gemini 模型在批处理模式下有 50% 折扣」，按 Gemini 3.1 Pro Preview 验算：输入 2 美元 → 1 美元，输出 12 美元 → 6 美元。

和缓存不同，批处理折扣同时作用于输入和输出两侧。所以在由输出主宰的账单上，批处理比缓存能砍掉的总额大得多。把前面那个 Opus 4.8 的例子(token 成本 0.625 美元)拿去跑批处理，就是 0.3125 美元，恰好一半。请拿它和缓存的 28.8% 比一比。

当然不是白拿的。代价是时间和确定性。

Anthropic: 文档一边说「大多数批次在 1 小时内完成」，一边明确写着结果要「在所有消息完成时或 24 小时后，以先到者为准」才能访问，并且24 小时内没处理完的批次会过期。还带着一个重要的但书 — 处理可能因需求和请求量而变慢，那种情况下 24 小时后过期的请求就会更多。不过过期的请求不会计费。

OpenAI: 完成窗口(completion_window)目前只能设成 24h，批次状态里存在 expired(「未能在 24 小时窗口内完成」)。

归纳一下：批处理不是「50% 折扣」，而是打包在一起的「50% 折扣 + 24 小时过期风险」。用户正在等的请求用不了它。夜间报表生成、文档批量分类、嵌入重建索引、跑评估集 — 对这类任务，它几乎永远是赚的。

批处理用不了的工作负载 — Flex

这里有一个不太为人所知的选项。OpenAI 的 Flex 处理是同步调用，却按批处理价格计费。照 OpenAI 文档的原话，Flex 的 token「按 Batch API 费率计费」，而且提示词缓存折扣还能再叠上去。价目表上也一样，gpt-5.6-sol 的 Flex 费率(输入 2.5 美元 / 输出 15 美元)与 Batch 费率完全一致。

不用搭 24 小时的批处理文件工作流，只要把 service_tier 设为 flex 就行，所以它很适合那些搬去批处理有点尴尬的非交互式任务。

代价也写得清清楚楚。Flex 便宜，是用「更慢的响应时间和间歇性的资源不足」换来的，而且目前还是测试版，支持的模型也有限。资源不够时会返回 429 Resource Unavailable，文档明确说这种情况不会计费。SDK 默认超时是 10 分钟，长任务得把超时调大；OpenAI 给出两种失败时的策略：按指数退避重试，或者把 service_tier 改成 auto 用标准处理重试。

一句话总结：非交互式、但又等不起 24 小时的任务，Flex 填的正是这个缝。

换成便宜的模型就能便宜那么多吗 — 分词器陷阱

模型路由的逻辑很简单：容易的请求给便宜的模型，只有难的请求才给贵的模型。价格阶梯在 2026 年 7 月 17 日是这样：

Anthropic (每 100 万 token，输入 / 输出)
  Claude Fable 5              10 美元 / 50 美元
  Claude Opus 4.8              5 美元 / 25 美元
  Claude Sonnet 5 (首发价)      2 美元 / 10 美元   <- 截至 2026-08-31
  Claude Sonnet 5 (9/1 起)      3 美元 / 15 美元
  Claude Haiku 4.5             1 美元 /  5 美元

OpenAI (每 100 万 token，按短上下文计，输入 / 输出)
  gpt-5.6-sol                  5 美元 / 30 美元
  gpt-5.6-terra              2.5 美元 / 15 美元
  gpt-5.6-luna                 1 美元 /  6 美元

Haiku 4.5(1 美元/5 美元)和 Opus 4.8(5 美元/25 美元)正好差 5 倍。把 80% 的简单请求下放给 Haiku，就能省下相应的一大块 — 这就是路由确实值得做的原因。

但这里有个陷阱。per-token 价格只有在分词器相同时才可比。Anthropic 价格文档里挂着这样一条脚注 — Claude Opus 4.7 之后的 Opus 模型、Fable 5、Mythos 5、Mythos Preview、Sonnet 5 使用新的分词器，而这个分词器对同样的文本大约多产生 30% 的 token。(文档补充说「确切的增幅取决于内容和工作负载的形态」。Sonnet 4.6 及更早的模型用旧分词器。)

来算算这会怎样掀翻价格比较。把文档里的「约 30%」直接记为 1.3 倍，假设要处理同一段文本 T：

Sonnet 4.6 (3 美元，旧分词器) vs Sonnet 5 首发价 (2 美元，新分词器)
  单纯比单价:      (3-2)/3           = 便宜 33.3%
  按同一文本算:    3T vs 2 x 1.3T = 2.6T
                  (3-2.6)/3         = 便宜 13.3%   <- 实际

Sonnet 5 在 9 月 1 日涨到 3 美元后
  按同一文本算:    3T vs 3 x 1.3T = 3.9T
                  -> 比 Sonnet 4.6 贵 30%

Opus 4.1 (15 美元，旧) vs Opus 4.8 (5 美元，新)
  单纯比单价:      (15-5)/15         = 便宜 66.7%
  按同一文本算:    15T vs 5 x 1.3T = 6.5T
                  (15-6.5)/15       = 便宜 56.7%  <- 实际

有几句话得诚实地补上。这个计算是建立在「输入文本相同」这一假设之上的算术，不是基准测试。Anthropic 文档说新分词器「有助于在广泛的任务上提升性能」，所以不能把 token 变多直接读成吃亏。更好的模型可能用更短的输出干完同一件事，重试也可能变少。而且「约 30%」很可能是以英语为准的近似值 — 在像韩语这样分词特性不同的语言上实际是多少百分比，没有公开的数字。除了把你的真实提示词塞进各模型的 token 计数 API 亲自数一遍，没有别的办法。

从这里得出的规则是：换模型时，别比单价表，要比「我的真实提示词的 token 数 x 单价」。在世代不同的模型之间只比单价，等于拿两个单位不同的数做减法。

长上下文加价 — 没人算进预算的那一项

上下文用得长，token 变多所以变贵 — 这谁都知道。但取决于供应商，单价本身也会上调这件事，知道的人就少得多了。三家公司在这里分道扬镳。以下每个数字都取自该公司自己的价目表(2026 年 7 月 17 日)。

OpenAI 的价目表把 gpt-5.6 系列的费率分成「Short context」和「Long context」两套：

gpt-5.6-sol    短上下文   5 美元 / 30 美元
               长上下文  10 美元 / 45 美元    -> 输入 2 倍，输出 1.5 倍
gpt-5.6-terra  短上下文  2.5 美元 / 15 美元
               长上下文   5 美元 / 22.5 美元  -> 输入 2 倍，输出 1.5 倍
gpt-5.6-luna   短上下文   1 美元 / 6 美元
               长上下文   2 美元 / 9 美元     -> 输入 2 倍，输出 1.5 倍

三个模型都是精确的输入 2 倍、输出 1.5 倍。不过，gpt-5.6 系列的「长上下文」从多少 token 算起，价目表页面上并没有写。同一页在旧世代模型的行里会像 gpt-5.5 (<272K context length) 那样标出边界，gpt-5.6 系列却没有那个标注。所以这里不去编造阈值 — 请务必亲自确认。

Google 的 Vertex AI 价格页面把阈值写明了。Gemini 3.1 Pro Preview 是输入 2 美元 / 输出 12 美元，但超过 200K 输入 token 后变成 4 美元 / 18 美元(同样是输入 2 倍、输出 1.5 倍)。而这一页的脚注里有一句可能让人肉疼的话 — 一旦查询的输入上下文超过 200K token，包括输入和输出在内的所有 token 都按长上下文费率计费。意思是阈值哪怕只超出 1 个 token，那次请求整体的单价就都变了。

Anthropic 走的是反方向。价格文档明确写着 Fable 5、Mythos 5、Mythos Preview、Opus 4.8、Opus 4.7、Opus 4.6、Sonnet 5、Sonnet 4.6 把 100 万 token 的完整上下文包含在标准价格里，还用括号钉死了这一点 — 「90 万 token 的请求与 9,000 token 的请求按相同的每 token 费率计费」。提示词缓存和批处理折扣同样在整个上下文区间按标准费率适用。

这不是基准测试的比较，而是价格结构的比较。这里没有把三家性能放在一起量的共同基准，只是把各家写在自家价目表上的计费规则并排摆出来。对实务的含义很明确：像 RAG 这种上下文长度参差不齐的工作负载，来回跨越阈值的请求可能悄悄压垮预算。在有阈值的供应商那里，监控上下文长度的分布、并把长度截到阈值正下方，有时就能带来可观的节省。

最大的杠杆是输出 token

前面的计算一直指向同一个地方。输出的单价是 5~6 倍，一旦打开缓存，它在 token 成本中的占比会升到 84%。可是在大多数成本文章里，输出被放到最后，只给一段。顺序反了。

减少输出 token 的办法，简单到无聊。

  • 把 max_tokens 设成实际需要的值。它是上限而不是目标值，但它是挡住失控的最后一道防线。
  • 强制输出格式。分类任务只需要一个标签，模型却附赠三段解释的话，那些解释全都按 5 倍单价计费。结构化输出(JSON schema)在是精度工具之前，先是成本工具。
  • 认清「请一步一步解释」的价格。把推理过程拉长的提示词，就要花掉相应的输出 token。在只需要最终答案的自动化流水线里，那纯粹是浪费。(顺带一提，Google 的 Vertex 价目表干脆把输出一项写成「Text output (response and reasoning)」 — 意思是推理 token 也按输出计费。)
  • 数一数重试。失败的调用也照样按生成的输出 token 花钱。因解析失败而重试 3 次的流水线，输出成本是 4 倍。

输入侧也有一项免费的节省。Anthropic 价格文档按模型公开了使用工具时自动附加的系统提示词的 token 数 — Opus 4.8 在 auto/none 下是 290 token，Opus 4.7 是 675 token。在这之上还要加上工具定义本身的 token(例如 bash 工具在 Opus 4.7·4.8 上是 325 token)。如果你把用不到的工具塞在每个请求里发出去，那就是每次都在交的税。工具定义位于前缀的前部，所以能被缓存盖住 — 这一点也请一并记住。

那么应该从哪里做起

是有顺序的。从上往下做。

第 1 步 — 先算账。把最近一天的 usage 字段扒下来，算出每一项(未缓存输入 / 缓存读取 / 缓存写入 / 输出)的金额。如果输出占 60% 以上，调缓存就不是优先事项。

第 2 步 — 找出能搬去 Batch 或 Flex 的流量。只要存在用户不在实时等待的请求，输入、输出两边就都能吃到 50%。作为单一杠杆，它是最大的。等得起 24 小时用 Batch，等不起就(在 OpenAI 上)用 Flex。

第 3 步 — 收紧输出。强制格式、max_tokens、去掉不必要的推理、减少重试。这是单价 5~6 倍的项目，效果会按原样乘上去。

第 4 步 — 然后才轮到缓存。只给 5 分钟内同一前缀会被复用 2 次以上的流量打开。固定资产放前面，变动数据放后面。有没有超过最小 token 数，用 usage 字段确认(它会静默失败)。

第 5 步 — 路由。把简单请求下放给便宜的模型，但一定要按「我的提示词的实际 token 数 x 单价」来比较。世代不同的话，比单价表毫无意义。

第 6 步 — 看看上下文长度的分布。如果你用的是有阈值的供应商，长上下文加价可能正在啃食你的预算。

什么时候不该做这些

该诚实的部分来了。本文的大部分内容，你可能并不需要。

  • 账单每月只有几十美元的话，什么都别做。设计缓存断点、搭批处理流水线的工程师时间，比省下来的钱贵得多。LLM 成本优化，是等账单和工程师人力成本到了同一个数量级时才开始做的事。
  • 流量低频的话，缓存是亏的。前面的盈亏平衡计算就是答案。
  • 质量还没站稳之前，别做路由。下放到便宜模型后精度掉了、重试和人工介入变多，总成本反而上升。没有评估集的路由不是成本优化，是拿质量赌博。
  • 别把批处理用在用户正在等的路径上。看起来理所当然，但被「50%」这个数字迷住、想把交互式端点搬去批处理的尝试，现实中真的见得到。
  • 缓存和批处理叠加使用时是相乘的。Anthropic 文档明确写着，缓存的倍数与包括批处理折扣在内的其他价格修饰符「相乘适用(stack)」。这是好消息，但也因此让预估成本的计算容易犯迷糊 — 不是简单地把 90% 和 50% 加起来得到 140% 的折扣。反过来，Fast mode 不能和批处理一起用，Managed Agents 的会话也不适用批处理折扣、Fast mode 和数据驻留倍数。

结语

压缩成一句话就是：折扣率只按该项目在账单中所占的比重来缩减总额。

缓存读取是输入单价的 10%，这是事实。而它只能把总额减少 25.5%，这 — 在 Anthropic 自己的计算示例里 — 也是事实。两者并不矛盾。只是输出 token 本来就吃掉了成本的 60% 而已。理解了这个结构，你就不会再被「省 90%」之类的标题晃到。那种标题，是把一个行项目的折扣率当成整张账单的节省率来用了。

所以顺序永远一样 — 把账单按项目拆开，先动最大的那一项，并把每个杠杆的代价(24 小时过期、资源不足、缓存写入费、质量下降)明明白白算出来。而且，包括本文的数字在内，所有价格都以今天(2026 年 7 月 17 日)为准，而且经常变。请从打开下面的链接亲自核对开始。不变的不是价格，是算术。

参考资料

Discuss on Twitter • View on GitHub