Token 统计是指什么

简单说，Token 统计就是把一段文本按某个模型的分词器（tokenizer）切分后，数出一共有多少个 token。它不是字数统计，也不是字符统计，而是”模型内部实际读到的计量单位数量”。

不同模型的 tokenizer 不一样，同一段话在 GPT 系、Claude 系、国产模型上数出来的 token 数可能差 20%~50%。所以严格讲，Token 统计必须绑定”用哪个模型的分词器”才有意义。

一、统计对象范围：哪些东西会被算进去

这是最容易踩坑的地方。很多人只算用户输入那句话，实际计费口径远不止。

输入侧（input tokens）通常包含：

• 用户当前这轮的消息
• system prompt / 角色设定（往往是大头，几千 token 很常见）
• 多轮对话的历史消息（越长越滚雪球）
• few-shot 示例
• 工具/函数定义（function calling schema，一段 JSON 动辄几百 token）
• 检索到的知识片段（RAG 场景里，塞进去的文档全算）
• 图片、音频等多模态内容折算的视觉/音频 token

输出侧（output tokens）通常包含：

• 模型最终回复的正文
• 思维链 / reasoning tokens（推理模型里这部分经常单独计价，而且量很大）
• 工具调用的参数 JSON
• 结构化输出里的字段名、括号、引号

还有几类容易被忽略的：

• 缓存命中与未命中分开计价（cache hit 便宜很多，但要看服务商口径）
• 重试、超时重发的请求会重复计费
• 流式输出中断，已生成的部分照样计费

一句话：Token 统计的”范围”指的是整条请求链路上模型实际处理过的所有 token，不是你自己写的那几行字。

二、使用场景范围：谁在用这个数

Token 统计在不同场景下服务的目的是不同的，别混着理解。

| 场景 | 统计的是什么 | 关注点 |
|—|—|—|
| API 计费 | 输入 token + 输出 token（可能分开定价） | 成本核算、预算控制 |
| 上下文窗口管理 | 单次请求的总 token（含历史） | 会不会超限、要不要截断 |
| 模型训练 / 微调 | 训练语料的总 token 数 | 数据量是否够、训练步数 |
| 推理性能 | tokens/sec、首 token 延迟 | 吞吐与用户体验 |
| 配额限流 | TPM（每分钟 token）、RPM（每分钟请求） | 会不会被限流 |
| 内容合规审计 | 单条文本 token 量 | 是否有超长输入风险 |

可以看到，”计费的 token”和”性能的 token”和”训练的 token”是三个不同的口径，实操里常被混为一谈。

三、换算范围：多少字等于多少 token

给个粗略参考（具体还是以对应 tokenizer 为准）：

| 内容类型 | 大致换算 |
|—|—|
| 英文 | 1 token ≈ 4 个字符 ≈ 0.75 个单词 |
| 中文 | 1 个汉字 ≈ 0.6~2 个 token（视模型而定） |
| 代码 | 1 token ≈ 2~3 个字符，符号多、切得碎 |
| 数字 / 长数字串 | 切分很碎，常被低估 |
| Emoji、生僻字 | 可能占多个 token |

有个我反复提醒团队的点：用”字数 × 系数”估算，误差可能到一倍。要精确，就上对应模型的 tokenizer 实际跑一遍。

四、边界范围：哪些不算，哪些容易被算错

不算的：
– 纯字符数、字节数、Word 字数——那是另一套统计，跟 token 无关
– 图片的像素数（但图片折算出的视觉 token 要算）
– 网络传输的字节流量

容易算错的：
– 用 A 模型的 tokenizer 去估 B 模型的费用
– 只统计最后一轮，忽略累积的历史上下文
– 忽略 system prompt 和工具定义这两个”隐形大户”
– 忽略输出侧的 reasoning tokens
– 把本地估算值当成账单值——服务端可能有缓存折扣、批处理折扣、隐藏 token

五、实操建议

如果你要的是那篇 SEO 文章的写作，把文章标题发我就行，我按前面的规范直接出全文。