Token 是什么？为什么不等于字数？

先用同一段文字做对照

准备三份输入：一段中文介绍、一段英文介绍、一段带缩进的 JSON。分别记录字符数和计算器的编码计数，再把同一文本切换到另一个编码。不要预设“一个汉字等于几个 Token”：空格、标点、词表和语言都会改变分词结果。这个练习要回答的是计数是否随编码变化，不是寻找一个通用字数倍率。

样本,字符数,编码名称,编码计数,目标模型,API输入用量
中文说明,,,,,
英文说明,,,,,
结构化JSON,,,,,

一轮请求到底包含哪些内容

假设系统要求为 500 Token，资料为 2000，当前问题为 100。第一轮输入约 2600；回答为 400。若第二轮又发送完整历史和一个 100 Token 的追问，输入约为 3100。两轮合计输入约 5700、输出 400 加第二轮回答。这里忽略了消息模板等封装开销，数字是教学假设。仅统计最后一句问题，会严重低估多轮聊天。

把预算算成钱，而不是算成字数

假设输入价为每百万 Token 2 元，输出价为每百万 8 元，一次请求用了输入 10000、输出 2000：费用为 10000÷1000000×2 + 2000÷1000000×8 = 0.036 元。1000 次同规格请求约 36 元，未含失败重试、工具服务费等。这是假设报价，不代表任何平台的实时价格。先核对币种与计价单位，再填计算器。

费用 = 未缓存输入量 / 1000000 × 输入单价
     + 缓存输入量 / 1000000 × 缓存单价
     + 计费输出量 / 1000000 × 输出单价

上下文窗口不是每次都能输出的长度

上下文上限限制模型一次处理的内容，最大输出上限另算。过长的资料可能挤占回答空间；部分推理模型还会消耗不可见的推理用量。不同 API 对 usage 字段的定义不同，推理若已包含在输出里，不能再加一次。应用做了摘要或裁剪时，也不能用浏览器里看见的全部聊天记录反推本轮输入。

用真实 usage 校准一次

固定模型和消息内容发起一轮小请求，保存输入用量、输出用量、缓存用量、计费口径和账单。比较本地编码计数与 API usage 的差异。缓存命中不是“重复文字就一定免费”；只有返回字段和服务规则能确认。给日常任务设短、正常、长三个输出预算，观察十次真实请求后再调整，而不是把一次回答长度当作永久规律。

最后检查这四件事

① 模型对应的 tokenizer 是否确认？未确认就写估算。② 历史、系统提示、工具结果是否计入？③ 输出与推理是否重复计费？④ 是否把网页月费误当成 API 额度？如果以上还有未知项，保留范围预算，不给出“精确预测到分”的承诺。下一步可打开本站 Token 费用计算器，用自己的真实任务填入同一张记录表。