大模型缓存Token统计：统一口径、计算方法与成本分析
缓存Token统计是评估大模型调用成本、缓存命中效果与系统性能的重要基础。本文梳理输入Token、缓存写入Token、缓存读取Token和输出Token的定义，介绍统计口径、计算方法及监控实践，帮助团队建立可核对、可优化的Token数据体系。
为什么要统计缓存Token
在大模型应用中，系统提示词、角色设定、知识库上下文、工具定义和历史对话往往会被重复发送。若服务商支持提示词缓存，重复内容可以在一定时间内复用，减少重复计算，并可能降低输入Token费用和请求延迟。
缓存Token统计的价值不仅在于核算账单，还在于判断缓存策略是否有效。单独查看总Token数，无法区分哪些内容被重新计算、哪些内容来自缓存，也无法解释命中率下降、成本异常或响应速度波动等问题。
缓存Token的核心概念
大模型平台通常会把一次请求拆分为输入Token和输出Token。输入Token是模型接收的内容，包括系统提示词、用户消息、历史对话、工具描述以及检索结果；输出Token是模型生成的内容。
启用缓存后，输入Token通常还会进一步区分为缓存读取Token和缓存写入Token。缓存读取Token表示本次请求中成功复用的历史内容，缓存写入Token表示本次请求中首次计算并写入缓存的内容。不同平台的字段命名可能不同，但统计逻辑基本相近。
| 指标 | 含义 | 是否通常参与输入Token总量 | 常见计费含义 |
|---|---|---|---|
| 输入Token | 模型接收的全部输入内容 | 是 | 按照平台规则计费或用于用量统计 |
| 输出Token | 模型生成的文本或结构化结果 | 否 | 通常按输出单价单独计费 |
| 缓存读取Token | 本次请求命中并复用的缓存内容 | 是 | 可能按更低单价计费，也可能仅作为用量指标 |
| 缓存写入Token | 本次请求首次计算并写入缓存的内容 | 通常是 | 可能产生缓存写入费用，具体取决于平台 |
| 未缓存输入Token | 本次请求中未命中缓存的输入内容 | 是 | 通常按标准输入Token价格计费 |
缓存Token的统计口径
最基础的输入Token关系可以表示为：输入Token总量 = 缓存读取Token + 缓存写入Token + 未缓存输入Token。在部分平台中，缓存写入Token和缓存读取Token可能存在重叠统计或特殊定义，因此不能只依赖字段名称进行简单相加，应以具体接口文档和账单口径为准。
如果平台只返回缓存读取Token，而没有单独返回缓存写入Token，可以通过输入Token总量、缓存读取Token和其他可用字段进行估算。但估算结果只能用于运营分析，不宜直接作为财务结算依据。
缓存命中率通常使用缓存读取Token除以可缓存输入Token计算。常见公式为：缓存命中率 = 缓存读取Token ÷ 可缓存输入Token × 100%。其中，可缓存输入Token应排除每次都会变化且无法复用的内容，例如实时用户问题、动态时间戳和随机请求标识。
成本计算方法
当平台对不同类型的Token采用不同价格时，可以将费用拆分为标准输入费用、缓存读取费用、缓存写入费用和输出费用。通用计算公式为：总费用 = 未缓存输入Token × 标准输入单价 + 缓存读取Token × 缓存读取单价 + 缓存写入Token × 缓存写入单价 + 输出Token × 输出单价。
如果平台不单独收取缓存写入费用，缓存写入Token仍应保留在内部统计中，因为它可以帮助分析缓存初始化成本、缓存生命周期和后续命中收益。只有把写入阶段和读取阶段分开，才能判断缓存机制是否真正带来了净收益。
| 统计场景 | 主要关注指标 | 分析目的 |
|---|---|---|
| 成本核算 | 输入Token、输出Token、缓存读取Token、缓存写入Token | 核对平台账单并计算实际调用成本 |
| 缓存效果评估 | 缓存命中率、缓存读取占比、重复前缀长度 | 判断提示词结构是否适合缓存 |
| 性能分析 | 缓存命中率、首Token延迟、总响应时长 | 分析缓存对响应速度的改善程度 |
| 容量管理 | 缓存条目数量、缓存占用Token、过期率 | 评估缓存空间和生命周期策略 |
| 异常监控 | Token突增、命中率骤降、写入量异常 | 发现提示词变更、请求污染或服务异常 |
统计时必须区分的内容
首先要区分静态前缀和动态后缀。适合缓存的内容通常包括稳定的系统指令、固定的工具定义、长期不变的业务规则和文档前缀；不适合缓存的内容通常包括用户最新问题、实时检索结果、当前时间和一次性授权信息。
其次要区分Token数量和请求数量。一次请求可能包含大量缓存读取Token，也可能只命中很短的前缀。仅统计命中请求数会掩盖实际复用规模，因此应同时记录请求级命中状态和Token级命中数量。
还要区分模型侧Token与应用侧字符数。中文、英文、数字、代码和特殊符号在不同分词器中的Token数量并不相同。应用层按字符数估算成本时，可能与平台最终统计出现明显偏差，正式分析应优先采用模型接口返回的Token用量。
推荐的数据记录字段
为了支持日常核算和问题追踪，每次模型请求至少应记录请求时间、模型名称、业务场景、请求Token总量、输出Token数量、缓存读取Token、缓存写入Token、请求耗时和响应状态。涉及多租户或多项目时，还应增加租户标识、应用标识和成本中心字段。
缓存键或提示词全文不宜直接写入普通日志，尤其是在请求内容包含个人信息、商业机密或内部知识时。更稳妥的方式是记录缓存键的哈希值、前缀版本号、内容长度和脱敏后的摘要，以便排查命中问题，同时降低敏感数据泄露风险。
| 字段类别 | 建议字段 | 用途 |
|---|---|---|
| 请求标识 | request_id、tenant_id、application_id | 关联请求、租户和业务系统 |
| 模型信息 | model_name、model_version | 区分不同模型和版本的统计口径 |
| Token用量 | input_tokens、output_tokens、cached_read_tokens、cached_write_tokens | 核算用量、成本和缓存效果 |
| 缓存信息 | cache_key_hash、prefix_version、cache_status | 定位缓存命中、失效和版本变化 |
| 性能信息 | time_to_first_token、total_latency、status_code | 分析缓存与响应性能的关系 |
常见异常与判断方法
当输入Token总量保持稳定、缓存命中率却突然下降时，常见原因包括系统提示词发生变化、缓存前缀不再连续、请求中插入了动态字段，或者缓存键生成逻辑发生改变。此时应对比最近的提示词版本、前缀长度和缓存键哈希变化。
当缓存读取Token持续增加但总成本没有明显下降时，可能是缓存读取单价并未显著低于标准输入单价，也可能是缓存写入成本、输出Token成本或请求重试成本抵消了节省金额。因此，缓存效果不能只看命中率，还应计算单位请求成本和单位有效输出成本。
当缓存写入Token异常升高时，可能意味着缓存条目频繁失效、动态内容被错误放入静态前缀，或者缓存生命周期过短。对于这类问题，应结合缓存过期时间、请求间隔和前缀版本进行联合分析。
如何建立可核对的统计体系
较为稳妥的做法是同时保留三套数据：模型接口返回的原始用量、应用网关加工后的标准化指标，以及平台账单或控制台中的结算数据。原始用量用于排查接口差异，标准化指标用于业务分析，账单数据用于最终财务核对。
在日报或月报中，可以将请求数、输入Token、输出Token、缓存读取Token、缓存写入Token、缓存命中率、平均响应时延和总费用放在同一统计周期内进行比较。若不同平台对缓存Token的定义不一致，应在指标名称中明确数据来源和计算公式，避免跨平台直接横向比较。
缓存Token统计的最终目标不是追求最高命中率，而是在满足回答质量、数据安全和实时性的前提下，减少不必要的重复计算。只有建立清晰的统计口径，并将Token数据与成本、延迟和业务结果结合起来，缓存优化才具有稳定的决策价值。