01
输入 token
提示词、系统指令、历史上下文与工具返回值都算输入，长文档任务里输入往往占大头。
Token 怎么计费
把 token 折算、四项计价与缓存规则拆开，再用一条公式对账，少交看不懂的钱。
可引用结论
1M token 大致对应几十万汉字，准确折算取决于分词器；计费要分开看输入、输出、缓存写入与缓存读取四项，用应扣公式对账，误差 5% 以内才算对得上。
引用请注明来源 https://zhongzhuancha.com/guides/token-billing（抓取日期 2026-10-27）。
token 与汉字怎么换算
单位不同，先别急着比较价格
token 是模型切分文本的单位，不等于字。中文一个字可能被切成一个或多个 token，英文一个 token 大致覆盖几个字符，代码与符号切得更碎。所以 1M token 等于多少字没有统一答案，只存在区间。
想知道自己场景里的折算比例，最稳的办法是拿一段固定文本跑一次真实调用，看账单报了多少输入 token，再除以字数。比例来自你自己的内容，比任何经验值都可靠。
粗略按量级估，1M token 大约对应几十万汉字；长文、表格与代码会明显偏离这个区间。把 token 直接说成字数，是报价时最容易产生误解的地方。
自测办法
- 准备一段固定长度的中文文本
- 调用一次，记录账单里的输入 token
- 用 token 数除以字数，得到本场景比例
- 换成长文或代码再测一次，取两档估算
四项分别计价
同一个请求，可能产生四种费用
02
输出 token
模型生成的正文、推理过程与工具调用参数都算输出，单价通常高于输入，写长回复成本更高。
03
缓存写入
把稳定前缀写进缓存时按写入价计费，价格与普通输入不同，短对话反复写并不划算。
04
缓存读取
命中缓存的部分按更低单价计费，这是长系统提示与固定知识库能省钱的根本原因。
缓存为什么能省钱
省的是重复前缀，不是全部对话
命中的是什么
缓存存的是稳定不变的前缀：系统提示、知识库、长文档、固定示例。前缀完全一致时，这部分输入按缓存读取价计费，价格通常低于普通输入，前缀越长省得越多。
什么时候不省
写入缓存本身有成本，短对话反复写反而不划算；前缀改一个字、换一次工具顺序，缓存就失效。把缓存当折扣券用，而不是当默认能力，才不会算错账单。
命中率高的场景很集中：同一套系统提示反复调用、同一份文档多轮追问、多轮对话里历史上下文不断变长。这三类任务的输入占比高，缓存生效后总成本下降最明显。
对账五步
从官方价走到账单差额
应扣 = 官方价 × 渠道倍率 × 用量
- 01
查官方价：输入、输出、缓存分开记
- 02
找站点倍率与计价单位，确认覆盖范围
- 03
从账单取用量，按输入输出缓存分项
- 04
代公式：应扣 = 官方价 × 倍率 × 用量
- 05
比对差额，超过 5% 就问清计费口径
三项里官方价与用量都能查，只有倍率是站点单方面声明的。等式成立说明口径自洽；不成立时，差额会落在缓存、输出单价或计价货币上，逐项排除即可。
五个常见计费陷阱
账单对不上，多半是这五处
倍率不含缓存
宣传的倍率只覆盖普通输入，缓存读写另有一套价目，长上下文场景的实际成本会高出预期。
美元人民币不按汇率
官方价以美元计，站点以人民币收，汇率与手续费要么写清楚，要么被悄悄折进倍率里。
只比输入单价
输入很便宜、输出按官方价甚至更高，是常见结构。只看输入价，等于把成本低估了一半。
按次与按量混比
按次计费看着低，但长提示词每次都是固定价，实际单价可能高于按量计费，两类不能直接横比。
上下文阶梯价
超过一定长度后单价上浮。长文档任务要按阶梯价估算，用首档价格推算会低估账单。
先用专用 Key 做小额调用，保留每次请求的用量记录，再对照官方价与倍率复算。能复算清楚的账，才值得继续充值。
继续核对
把计费和选站放在一起看