我的提示词有多少 token？

语言模型读取的不是字符，也不是单词，而是 token：按照从训练数据中学到的固定词表，把文本切分后得到的片段。

常见单词通常就是一个 token。生僻词则会被拆成几段。空格一般附着在下一个 token 的前面，这就是为什么同一个单词在句首和句中的计数可能不同。

unbelievable 这个词不是一个 token——它很可能会被拆成类似 Un + believ + able 这样的三段。而 the 是单个 token，international 也是，因为它在训练数据中出现得足够频繁，赢得了自己的词表条目。

这就是 token 计数难以预估的原因。它的单位不是语言学意义上的，而是统计学意义上的：在训练语料中的出现频率，决定了某个内容是一个 token 还是四个。

对于英语文章：

• 1 token ≈ 4 个字符
• 1 token ≈ 0.75 个单词
• 1,000 个单词 ≈ 1,300 个 token
• 一个标准页面（约 500 词）≈ 650 个 token

一旦超出普通文章的范围，这些法则就会迅速失效：

内容类型	大致情况
英语文章	每个 token 约 0.75 个单词
代码	token 数是同等篇幅文章的 2–3 倍
键名较长的 JSON	非常高——标点和引号都是独立 token
中文、日文、韩文	往往每个字符就要 1–2 个 token
西里尔文、天城文、阿拉伯文	表达相同含义通常需要英语的 2–3 倍
URL 和哈希值	极高——随机字符串的分词效果很差
连续重复的空白	每一段空白都可能自成一个 token

多语言差距很大，却常被低估：同一句话用日语表达，费用可能是英语的好几倍，这既影响成本，也影响上下文窗口能装下多少内容。

每个模型家族都使用自己的分词器和词表，所以同一段文本会得出不同的计数。

GPT 系列使用字节对编码的变体——GPT-4 时代的模型用 cl100k_base，更新的模型用 o200k_base。Claude 使用另一套分词器和词表。Llama、Mistral 等开源模型又各有各的方案。

同一段英文文本在不同家族之间相差 10–20% 很正常，而在代码和非英语文本上差距更大，因为词表的分歧最明显。

实际这意味着：

• 来自某个分词器的计数，对其他模型来说只是估算值。
• 只有服务商自己的分词器才能给出与其计费一致的精确数字。
• 做预算时要留出余量，而不是卡着上限来安排。

我们的 Token 计数器 会同时给出 GPT-4o 的计数和 Claude 的估算值，通常足以判断一个提示词是距离上限还很宽裕，还是已经逼近极限。

费用。 API 按 token 计价，输入和输出分别计费，输出通常贵好几倍。系统提示词翻倍，意味着每一次调用的这部分成本都翻倍——测试时察觉不到，上了规模就很可观。

上下文限制。 窗口装的是所有内容：系统提示词、对话历史、检索到的文档、当前消息，以及为回复预留的空间。长对话出问题，往往不是因为某一条消息太长，而是历史在不断累积。

截断。 输入超出限制时，总会有内容被丢弃——常常是静默发生的，而且被丢的往往是最早的内容。模型"忘记"了你的指令，很多时候只是指令被截断掉了。

检索时的分块。 为生成嵌入而切分文档时，按的是 token 而不是字符。按字符数定长的分块会大小不一，从句子中间切断的分块检索效果很差。如需把长文本切成可用的片段，文本分割工具 会在段落边界附近切分，而不是从词语中间截断。

收效最高的缩减方法，大致按优先级排序：

1. 精简对话历史。 在长对话中，它占的比例远超其他一切。把旧的对话轮次总结后再发，而不是原样重发。
2. 删掉重复的指令。 同一条规则用三种说法重复，不会让遵守概率变成三倍，但一定会让这条规则的成本变成三倍。
3. 清除格式残留。 不可见字符、重复空白和装饰性分隔线都会消耗 token，一行四十个连字符的花费可能比它上面那句话还高。删除不可见字符 可以清掉那些看不见的东西。
4. 缩短结构化提示词中的 JSON 键名。 {"n": ...} 与 {"customer_full_name": ...} 的差别，乘以上千条记录就很可观。
5. 只发送相关片段。 检索出三段相关内容，胜过粘贴整篇文档，而且通常回答质量也更好、成本更低。

没有帮助的做法：删掉普通标点、删冠词，或者用电报式的极简风格写作。省下的 token 微乎其微，对输出质量的损害却不是。