多步 Agent 的真实成本往往不在模型输入价格,而在于每次调用都在重复支付相同上下文 token 的费用;缓存命中计费模式改变了这一单位经济。
真正决定 Agent 账单的不是模型的输入价格,而是你为"读取已发送内容"支付的费用。
如果你运行多步骤 Agent,可能遇到过这种情况:一个预期只需几分钱的任务,账单上却出现了令人意外的小数字。你没有换模型,也没有增加提示词。那这些 Token 究竟花在了哪里?
大多数时候,它们花在了为同一份上下文一遍又一遍地付费。
一个 2 分钟的任务可能触发 40+ 次计费调用
这是我经常看到的一种模式。一个 Agent 做一项"2 分钟"的工作:
反思结果
每一步都是一次 LLM 调用。而每次调用都会重新发送相同的"脚手架":系统提示词、任务描述,以及——关键——不断增长的历史对话。一个步骤虽然只新增了 200 个 Token 的思考内容,却携带了 4000 个 Token 的上下文——而这些上下文早在之前就付过费了。
乘以 40 步,这个数学题就不再是"模型价格"的问题了,而是关于"你为已经拥有过的上下文重复付了多少次费"。
普通输入计费是按你每次发送的 Token 数量收费。缓存命中计费则改变了计量单位:如果提供商已经缓存了你的前缀(因为你最近发送过它且尚未过期),读取该缓存前缀的费用会以大幅折扣计费,而不是按全价输入价格计算。
在统一网关中,每个模型都能看到这一信息。模型目录中有两个具体例子:
DeepSeek-v4-Pro:缓存读取 ¤10 / 1M Token(¤ 是平台的计费单位)
Qwen3.5-plus:缓存读取 ¤20 / 1M Token
这些不是全量输入价格——而是缓存读取价格,这正是对 Agent 型工作负载真正重要的数字,因为 Agent 型工作负载大部分都是重复的。
结论不是"这个模型更便宜"。而是:对于任何重发上下文的循环,缓存读取价格才是真正的边际成本,而大多数团队优化的却是错误的数字。
不去看具体数字,看结构。假设一个循环运行 40 次调用,每次携带约 4k Token 的重复上下文加上约 200 Token 的新内容。
每次都对重复的 Token 支付全价输入费用:你为实际上早已存在的那 4k × 40 = 160k "新" Token 付了费。
对重复前缀支付缓存读取费用:那 160k Token 会降到一个零头——用缓存读取价格替代全量输入价格。
在上面两个模型中,缓存读取价格为 ¤10–¤20 / 1M,而全量输入价格是这个价格的数倍。循环的成本不会归零,但重复税大幅降低了。在 Agent 系统中,重复税才是账单的主要部分——所以 70%+ 的节省空间实际上在这里,而不是在"选一个更便宜的模型"。
这里有一个陷阱。缓存命中计费只有在你能看到命中和未命中时才有帮助。一个只返回文本的黑盒 API 隐藏了你需要的那个数字:这个 Token 是缓存命中还是新鲜计费?
请求追踪可以让这一切变得可观测。每次调用都应该暴露它的各个阶段:
REQUEST — 收到了什么
AUTH — 谁/什么调用了
ROUTE — 由哪个模型服务
RESPONSE — 返回了什么
METER — 花费了多少,包括缓存命中/未命中
当每次调用都显示其缓存命中/未命中和每个阶段的成本时,这个循环就不再是一个谜了。你可以看到哪一步超出了预算,以及你的前缀是否真正保持了热度。
缓存命中计费是必要条件,但还不够充分。另一半是保持缓存热度,而这是一个路由问题。
80/20 模式依然有效:将 80% 的简单调用路由到小型/快速模型,把前沿模型留给 20% 的困难任务。但人们忽略的部分是缓存亲和性——如果你在循环中保持相同的系统提示词和稳定的前缀,缓存就会保持热度,便宜的读取就会持续命中。每一步都改变前缀(重新格式化历史、重写系统提示词、打乱顺序)就会在不知不觉中清空你自己的缓存。然后你就永远在支付全价输入费用。
使用模型:"auto"风格的路由背后是一个 OpenAI 兼容的端点,循环不需要考虑哪个模型服务哪个步骤——但它仍然需要尊重缓存亲和性,因为那才是把"便宜的模型"变成"便宜且有缓存的模型"的关键。
Agent 成本不是模型选择问题,而是重复税问题:你为已经发送过的上下文重复支付了多少次,以及你能否看到它正在发生。
缓存命中计费 + 请求追踪 + 缓存友好路由,这个组合才能把一张可怕的 Agent 账单变成一张平淡无奇的账单。大多数团队优化了第一个,而忽略了后两个——这就是为什么他们的账单仍然会让他们意外。
如果你想要与这个主题配套的路由攻略(80/20 分流以及如何保持缓存热度),可以访问 https://tokenlat.com ——但这个理念本身是独立的:停止计算输入价格,开始计算缓存命中。