大模型的 Token 到底是什么？为什么中文更“贵”，以及怎么估算用量

调用大模型 API 时，计费、上下文长度、速率限制几乎都以 token 为单位。但 token 既不是字，也不是词，很多人对它只有一个模糊的印象。这篇文章把它讲清楚。

Token 是怎么来的

模型并不直接读文字，而是读一串数字。把文本切成小片段、再映射成数字的工具叫分词器（tokenizer），切出来的每个片段就是一个 token。

目前主流模型大多使用 BPE（字节对编码） 一类的算法：先把文本拆成字节，再根据训练语料里的出现频率，不断把常见的组合合并成一个 token。结果就是：

• 常见的英文单词，通常整个词就是 1 个 token（如 the、function）；
• 不常见的词会被拆成几段（如 tokenization 可能是 token + ization）；
• 空格、标点、换行也都会占用 token。

为什么中文通常更“贵”

分词器的“词表”是从训练语料里学出来的。如果语料里英文占多数，英文的常见组合就会被合并得更充分，而中文字符合并得少，平均每个字占用的 token 就更多。

不同分词器差异很大。以 OpenAI 的两代分词器为例，新的 o200k_base（GPT-4o 及之后的模型使用）词表更大，处理中文明显比旧的 cl100k_base（GPT-4、GPT-3.5 使用）更省。

最直接的办法是拿你自己的真实文本测一测。在 Token 计数器 里粘贴同一段内容，切换两种分词器，就能看到差别，还能看到文本具体被切成了哪些片段。

不同模型的 token 不能直接比较

Claude、Gemini、DeepSeek、通义千问等模型都有自己的分词器，同一段文字在不同模型下的 token 数并不相同。所以：

• 用 OpenAI 分词器算出来的数，只能作为其他模型的粗略估算；
• 需要精确数字时，用厂商提供的 token 计数接口，或者看 API 响应里返回的 usage 字段；
• 比较不同模型的价格时，要用同一段真实文本分别实测，而不是只比“每百万 token 单价”。

上下文窗口：输入和输出共用

模型的上下文窗口（比如 128K、200K）指的是一次请求里能处理的 token 总数，通常包括：

• system prompt；
• 全部历史对话；
• 工具定义（function / tool 的 JSON Schema 也算 token）；
• 检索进来的文档；
• 以及模型这次要生成的输出。

所以对话越长，每一轮的输入就越多。多轮对话的成本会随着轮数累积增长，而不是每轮固定。

控制 token 用量的几个方法

1. 精简 system prompt：删掉重复、客套的说明。每次请求都会带上它，省下的部分会乘以请求次数。
2. 清理输入格式：从网页或 AI 回答里复制来的文本常带有大量 Markdown 符号和空行，可以先用 Markdown 清洗 处理成纯文本。
3. 控制对话历史：只保留最近几轮，或者把早期对话总结成一段摘要。
4. 检索而不是全塞：长文档切块后按需检索（RAG），而不是整篇放进上下文。RAG 文本分块 可以帮你预览不同块大小的效果。
5. 利用提示缓存：OpenAI、Anthropic 等都提供了 prompt caching，把固定不变的长前缀（system prompt、工具定义、参考文档）放在最前面，可以显著降低重复部分的成本和延迟，具体规则以各家文档为准。
6. 限制输出长度：合理设置 max_tokens，并在 prompt 里明确要求简洁。输出 token 的单价通常比输入高。

小结

• Token 是分词器切出来的片段，不等于字数；
• 不同模型的分词器不同，token 数不能直接换算；
• 上下文窗口包括输入和输出，多轮对话的成本会累积；
• 估算用量最靠谱的方法，是用真实数据实测。