token计费规则详细解读

很多人第一次看 API 账单会懵：明明只发了一段话，为什么输入比输出贵好几倍，为什么同一段提示词第二次便宜，为什么缓存写还单独收一笔。这篇不讲大道理，只把 token 计费拆成几个可核对的段落，告诉你每一段的计费对象、怎么在用量日志里找到它，以及去哪一页看当期单价。

很多人第一次看 API 账单会懵：明明只发了一段话，为什么输入比输出贵好几倍，为什么同一段提示词第二次便宜，为什么缓存写还单独收一笔。这篇不讲大道理，只把 token 计费拆成几个可核对的段落，告诉你每一段的计费对象、怎么在用量日志里找到它，以及去哪一页看当期单价。

核心结论先放前面：账单对不上，九成不是单价看错，而是口径没对齐——把四类 token 混成一个均值、把不同渠道的价直接相减、把重试当成一次调用。下面按「什么被计费 → 怎么分段 → 什么时候跳档 → 怎么对账」这个顺序走，每一步都给你可验证的动作。

先搞清一件事：到底什么被算成了钱

计费对象是模型实际处理的 token 数，不是你的字数、也不是字符数。同一句话在不同分词器下切出来的长度不同，中文、代码、符号混排时差异更明显。所以拿字数乘以某个系数去估，只能当粗略参考，不能当核对依据。

输入 token

提示词、系统提示、工具/函数定义、历史对话，全部计入，且通常是账单里最不显眼但占比最大的一块。

输出 token

模型生成的内容，逐 token 串行产出，同模型一般比输入段贵，长文和长代码任务要重点盯。

缓存 token

分缓存写和缓存读两笔，命中条件各家不同，不是所有重复内容都能命中。

等效 token

图片、音频等非文本输入，有的平台会换算成等效 token 计入，别以为只按文字收费。

• 先看接口返回体里有没有用量对象，有的话说明是按 token 计费，可以往下拆。
• 如果没有用量对象、只有固定扣费，直接去对应产品的计费说明页确认，不要套用本文口径。
• 同一账号下混用了两种计费模式的接口时，对账要分开做，混在一起必然对不上。

分段计费的四个段落，各自怎么定价

一次请求通常拆成四类 token：未命中缓存的输入、缓存写、缓存读、输出。四段单价往往不一样，有的平台还叠加阶梯。把每段单独乘单价再求和，才是最接近实际的估法；用平均单价去乘总量，误差会随任务类型浮动。

想横向比不同模型或不同渠道，最稳妥的做法是把这四段都填进同一个估算表里，而不是只看输入单价那一行。输入便宜但输出贵、或者缓存读不便宜的模型，在你这种任务上未必划算。

1. 统计你最近一批请求的四段 token 各占多少从用量日志按模型分组导出，看输入、输出、缓存读三列的比例，比例比绝对值更稳定，也更能说明你的任务形态。
2. 把四段分别乘对应单价再求和用站内工具区的模型成本计算器，输入你自己的用量分布，出来的才是你的真实成本，不是官方示例里的成本。
3. 换一个模型重算一遍做对照同样用量分布套另一套单价，差异出现在哪一段，就是你选型时该权衡的点。

阶梯与分档：什么时候单价会跳

分档是账单对不上的第二大原因，而且很多人会默认它是「只对超出部分加价」那种算法。实际上整档生效更常见——只要你的条件落进高档，整个请求或整个账期就按高档算，前后单价差别可能不小。

常见两种分档逻辑：按单次请求的上下文长度分档，或按账期累计用量分档。前者主要影响长文档、长对话这类任务；后者主要影响高频调用，同一份调用量集中在月初还是分散在全月，结果可能不同。

• 判断标准一：看分档门槛是不是以「单次请求」为单位，如果是，长上下文任务要单独拎出来估。
• 判断标准二：看累计档位是整档生效还是分段累进，口径不同，估出来的差距会很大。
• 判断标准三：拿真实用量分布去套门槛，算跨档请求占比，比看平均值有意义得多。
• 不适用的情况：如果平台明确写了统一单价不分档，这一节可以跳过，但要去价格页确认当期口径，别凭印象。

一个混合档位任务（同一请求里既有超长输入又有大量输出）要按最贵的那一档来估，这是保守但不容易翻车的做法。想知道当期门槛和档位数字，去官方 API 价格页核对，站内价格页和官方页面的口径都要看一遍。

倍率、折算与计费口径怎么对齐

官方价、中转价、订阅折算价，同样是「元」但不是同一个口径。比价前先把口径统一，否则算出来的是假差价，看着便宜实际贵。这是很多人换渠道后账单反而上升的原因。

判断标准很简单：拿同一段提示词，在两边各跑一次，记录四类 token 的用量和实际扣费，换算成每次调用成本再比。不要拿两个不同记账单位里的数字直接相减。

失败、重试和流式中断算不算钱

请求在计费前就被拒（比如鉴权失败、参数错误），一般不计费；已经生成到一半才断流的，多数平台会按已产生的 token 计费。这两类要分开看，不能笼统地说「失败不计费」。

更容易被忽略的是重试。超时后自动重发等于又跑了一次，两次都计费。账单明显高于预估时，先别怀疑单价，先确认实际调用次数是不是等于你以为的次数。

1. 按请求 ID 去重在日志里找出内容完全相同但时间接近的记录，数量就是多跑的次数。
2. 核对状态码分布看错误码和超时各占多少，这部分对应的是额外成本，能解释多少偏差一目了然。
3. 先对齐次数再对齐单价顺序反了会白查半天：先确认次数，金额对不上再去查单价和分档。

限速被拦后立刻重试容易连环触发，形成一批几乎无效的调用。这类问题的排查动作是固定的：把同一时间窗内的调用数、失败数、重试数三个数字摆在一起看，基本一眼就能定位。

对账靠什么：用量日志里的关键字段

没有日志就对不了账，只能猜。至少要留下这几个字段：请求时间、模型标识、输入 token 数、输出 token 数、缓存写 token 数、缓存读 token 数、请求耗时、状态码。有了它们，账单再对不上也能定位到是哪一类 token、哪个模型、哪一天出的偏差。

• 优先把接口返回体里的用量对象原样落盘，比事后按业务统计更可靠，也更少口径争议。
• 字段命名各家不同，先统一成自己的口径再汇总，否则同一列里混了两种含义。
• 缓存写和缓存读要分两列，合成一列后面就没法拆开核对。
• 模型标识要存接口实际用的那串，别只存你口语里的叫法，对不上表就白查。

判断标准：拿一次已知的调用，手工按日志字段算一遍总额，再和账单里对应的那笔比。对得上说明字段口径没问题，对不上先修口径再谈成本优化，不然优化方向都是错的。

想知道当期数字，去哪几个页面看

本文不给任何具体数字，因为价格和档位会变，写死的数字只会误导人。看当期数字的正确姿势是：先确认模型标识，再分别看官方和中转两边的价格页，最后用自己的用量分布算一遍。

• 比价前先到 /models 核对模型标识，确认你用的名字和计费表里的确实是同一个模型。
• 当期官方单价去官方 API 价格页看，中转渠道的价格去 /sites 对应条目看，两边别混着用。
• 拿不准换算结果时，用 /price-watch 看价格变动记录，再用 /tools/speed-test 之外的模型成本类工具按自己的用量算一遍。
• 价格随时可能调整，所有结论以页面上的当期数字为准，别参考任何二手截图或记忆里的旧价。

一套可复用的核对清单

把上面的内容收成一套固定动作，下个月账单出来照着走一遍，基本能解释清楚每一个偏差。关键是顺序：先对齐总量，再对齐单价，最后才谈优化。

1. 导出账期内的请求数与四类 token 总量先对齐总量，总量对不上说明数据范围或去重口径有问题，先修这个再往下走。
2. 四类 token 分开套单价再求和不要用一个混合均值去估，混合均值的误差会随任务类型变化，无法解释偏差。
3. 检查跨档请求占比和缓存命中情况这两项最能解释「为什么比预估高」或「为什么第二遍反而便宜」。
4. 把结论写进下个月预算表下次预估直接用这次的实测分布，而不是重新拍脑袋，逐月收敛误差。

不适用的情况也要说清楚：如果你的调用量很小、任务形态单一，这套拆法的收益有限，知道四段单价差异即可；如果平台明确按次或按订阅计费，整套逻辑都不适用，直接看对应产品的计费说明。