大模型 Token 计费的演进之路

从“字字斤斤计较”到“缓存时代”大模型 Token 计费的演进之路在大模型应用特别是 AI Agent 和代码助手爆炸式增长的今天很多开发者和企业在拿到 API 账单时常常会觉得像在看“无字天书”。从最初简单的按字算钱到后来的 Prefill、Decode、KV Cache再到如今账单上出现的 Prompt Cache 和 Cached Input大模型的计费逻辑经历了一场深刻的演进。理解这一演进过程不仅能帮你看懂账单更是做 AI 产品成本控本的关键。一、 青铜时代按量计费与“10万字系统提示词”的尴尬大模型世界里文本计算和计量的基本单位是Token可以粗略理解为单词或汉字的片段。在最初的计费模式下大模型的算账方式非常朴素——你发多少我收多少我回多少你付多少输入成本Input Token用户发送给大模型的文本字数。输出成本Output Token大模型吐出来的回答字数。这种模式在简单的“一问一答”场景下运作良好。但随着 AI 应用向Agent智能体演进问题出现了假设你开发了一个专业的英语教学 Agent。为了保证回答质量你必须在系统提示词System Prompt里塞入庞大的规则、教学知识库和工具定义总长达到了10 万 Token。这时用户只需要问一句简短的话“‘Apple’怎么造句”20 Token。如果不做任何优化大模型每次为了回答这 20 个字的提问都必须重新把前面的 10 万字系统提示词完整地“阅读”并处理一遍。如果你有 1000 个用户同时提问大模型就需要重复处理1000×100,00011000 \times 100,000 11000×100,0001亿个 Input Token 的巨大计算量账单金额会非常惊人。二、 白银时代底层的自我救赎——Prefill、Decode 与 KV Cache为了解决这种重复计算的低效问题大模型推理引擎在底层架构上做出了拆分。模型在处理一次请求时实际上分为两个阶段Prefill预填充阶段模型一次性读取并理解你传入的所有输入包括系统提示词和用户提问。Decode解码生成阶段模型根据理解好的上下文一个字一个字地生成回答。在生成回答时如果每生成一个新字都要把前面已生成的字和输入文本全部重新计算一遍计算量会呈指数级爆炸。为了避免重复劳动KV Cache键值缓存应运而生模型在 Prefill 阶段处理完输入文本后会把提取出的中间计算状态KV 状态矩阵直接保存在显存中。在随后的 Decode 阶段生成每个新 Token 时只需直接读取显存里的 KV Cache追加新生成的 Token 状态即可大大节省了计算资源。关键概念厘清KV Cache 是推理引擎底层的计算优化手段。在这一阶段厂商虽然提升了自己的服务器吞吐效率但在商业 API 账单上依然是按照标准 Input 和 Output 来向开发者收费的。三、 黄金时代账单的商业革命——Prompt Cache 与 Cached Input底层的优化最终推动了商业计费模式的演变。既然固定不变的前缀如 10 万字的 System Prompt在计算后产生的 KV 状态可以被保存那能不能让不同用户的请求共享这些保存好的 KV 状态呢这就是Prompt Cache提示词缓存机制。计费模式的改变大模型厂商在 API 账单中引入了一个全新的计费维度Cached Input缓存输入。普通 Input首次写入或未命中缓存的输入按标准原价计费因为模型需要完整执行 Prefill 计算。Cached Input命中已保存缓存的重复前缀以极低的价格计费通常仅为标准输入价格的 10% 左右。1000 个用户场景下的账单对比假设普通 Input 价格为 $10/MTokCached Input 价格为 $1/MTokOutput 价格为 $30/MTok无 Prompt Cache 时1000 个用户每次都重新处理 10 万字 Prompt总输入成本为1000×100,000×$101,000,000$10001000 \times 100,000 \times \frac{\$10}{1,000,000} \$10001000×100,000×1,000,000$10​$1000有 Prompt Cache 时第 1 个用户请求到来模型将 10 万字写入缓存支付少量写入成本或标准 Input 费后续 999 个用户的请求命中缓存这 10 万字全部转化为Cached Input计费999×100,000×$11,000,000≈$99.9999 \times 100,000 \times \frac{\$1}{1,000,000} \approx \$99.9999×100,000×1,000,000$1​≈$99.9整个系统的输入成本直接下降了接近90%。厂商随后也引入了更精细的Cache Write缓存写入费和Cache Read缓存读取费机制第一次把内容塞进缓存时支付稍高的写入成本后续读取时享受极低折扣。四、 王者时代复杂 Agent 与代码助手中的分层缓存实践进入代码助手Code Agent和多轮智能体时代计费与缓存的设计变得更加复杂。Code Agent 不是简单的“一问一答”而是一个持续循环的过程LLM → 调用工具 → 获得工具返回结果 → LLM → 修改代码 → 运行测试 → 最终答案。在这个过程中上下文会像雪球一样越滚越大。1. 缓存是如何“向后生长”的在一个设计良好的 Agent 任务中Prompt Cache 不仅能缓存最开头的系统提示词第 1 轮缓存系统提示词例如 100K。第 2 轮第 1 轮的工具调用记录和代码返回结果被追加到末尾形成新的、更长的前缀整体被缓存例如 108K。第 3 轮前缀继续增长可复用缓存延伸至 120K。只要追加新消息时不修改前面的历史记录可复用的缓存前缀就会随对话推进而向后生长。2. 三层缓存架构企业在搭建大型 Code Agent 时通常采用三层缓存策略来最大化降本全局共享缓存全员复用包含通用系统提示、Agent 行为规则、工具定义。项目级缓存团队复用包含项目代码库架构、依赖定义、数据库 Schema。会话级缓存单人单任务复用单次 Agent Loop 中产生的多轮工具调用与历史上下文。3. 指标衡量Token Cache Hit Rate在复杂场景下评估成本不能简单看“请求命中率”而必须统计Token Cache Hit RateToken 级缓存命中率Token Cache Hit Rate缓存命中的 Token 数量总输入 Token 数量\text{Token Cache Hit Rate} \frac{\text{缓存命中的 Token 数量}}{\text{总输入 Token 数量}}Token Cache Hit Rate总输入Token数量缓存命中的Token数量​因为 99 次短请求命中的 Token 数量可能还抵不上 1 次超长上下文未命中带来的巨大开销。五、 总结四大核心概念与最终成本模型理解大模型计费的演化本质上是要分清以下四个极易混淆的概念概念它解决什么问题是否直接对应账单Prefill模型的输入处理阶段理解全文对应基础 Input 的计算开销KV Cache避免在生成每一个新字时重复计算历史上下文底层推理优化不作为独立收费项Prompt Cache跨请求保存并复用完全相同的 Prompt 前缀产品级缓存复用机制Cached InputAPI 账单中针对命中缓存前缀的优惠计费分类直接体现在 API 账单上的折扣计费今天一个成熟 AI Agent 的真实成本公式已不再是简单的“字数相加”而是总成本Cache Write 成本∑Cache Read 成本∑普通 Input 成本∑Output 成本\text{总成本} \text{Cache Write 成本} \sum \text{Cache Read 成本} \sum \text{普通 Input 成本} \sum \text{Output 成本}总成本Cache Write成本∑Cache Read成本∑普通Input成本∑Output成本搞懂了这个公式就能在架构设计时有的放矢——通过保持稳定前缀、优化 Prompt 顺序和合理利用缓存 TTL在不牺牲 Agent 智能的前提下把 API 成本降到最低。