大模型的token究竟是什么？一文讲透

一、从一个“以为是游戏代币”的误会说起

第一次看到“token”这个词，很多人脑子里浮现的是游乐场的代币——投一枚进去，机器才肯动一下。这个直觉其实不算离谱：在大模型的语境里，token确实有点像“投喂给模型的计量单位”。但它不是货币，也不是简单的“字”或“词”，而是模型处理文本时的最小切分单元。

真正让人想认真搞清楚它的，往往是一次实验中的报错：

Error: exceeded maximum token limit

翻译过来就是：你输入的内容超过了模型能处理的最大token数量。这时你才意识到，原来模型不是“看多少字”，而是“数多少token”。本文就把这件事从头讲清楚。

二、先做一个小实验：你是按什么单位阅读的？

请在脑子里默念这句话：

今天天气不错。

你是逐字读的——“今 / 天 / 天 / 气 / 不 / 错”，还是按词组读的——“今天 / 天气 / 不错”？

绝大多数人是后者。人类阅读时，大脑会自动把文字切成有意义的块，而不是一个字母一个字母地处理。大模型做的是类似的事情：它先把文本切成一个个小块，再对这些小块进行计算。这些小块，就是token。

但这里要立刻补一句重要的限定：token不等于词。这是绝大多数人第一次接触token时最容易踩的坑。

三、token不等于词：切分粒度是“统计”出来的

很多人以为“一个词就是一个token”，实际远没有这么整齐。看几个英文例子：

• cat：通常是一个token。
• cats：很可能是cat + s，两个token。
• tokenization：大概率是token + ization，两个token。

为什么这么切？因为模型的切分逻辑不是按词典来的，而是按“出现频率”来的。它会把最常见的字母组合打包成一个token：

• ing 在英文中出现频率极高 → 打包成一个token；
• tion、pre、un 同理；
• 越常见的组合，越容易被当成一整块；
• 越生僻的词，越容易被切碎，甚至碎到单个字母。

这背后的算法通常被称为子词切分（subword tokenization），常见思路包括BPE（字节对编码）等。核心思想一句话：用有限的词表，覆盖尽可能多的文本，同时让高频片段保持完整。

四、中文怎么算？

中文相对“友好”一些：大多数情况下，一个汉字就是一个token。

例如：

煮啵今天在实验室等模型收敛

大概就是十几个token，基本一字一个。

但高频词组有时也会被打包。比如“所以”“因为”“的话”这类组合，在某些模型的词表里可能被合并成一个token。所以中文的token数并不严格等于字数，只是“近似等于”。

这就带来一个实用结论：如果你在做上下文长度估算，中文可以粗略按“字数≈token数”来估，英文则通常按“单词数×1.3左右”来估。 注意这只是经验值，具体取决于模型使用的分词器。

五、为什么非要搞token这一层？直接用字母不行吗？

这是最值得追问的问题。答案有两个层面。

原因一：序列太长了

看这句话：

I love machine learning

按字母算，是24个字符（含空格）。按token算，大概4到5个。

模型能处理的序列长度是有上限的。同样的上限下，用token能装进去更多内容。如果按字母处理，一段普通文章就会轻易撑爆上下文窗口，模型还没来得及理解语义，位置就已经用完了。

原因二：字母太碎，没有意义

l、o、v、e 这四个字母单独看，模型几乎学不到任何东西。它们不承载语义，只是符号。而 love 作为一个整体，才和“爱”这个概念产生关联。

token的核心价值，是在“字符”和“词”之间找一个平衡点：既不像字符那么碎，也不像完整词那样词表爆炸。 词表如果按所有单词来建，会是百万级甚至更大，且遇到新词就无能为力；而子词切分用几万规模的词表就能覆盖绝大多数文本，还能通过组合处理未登录词。

六、token在工程实践中的三个实际影响

理解token不是学术兴趣，它直接关系到开发中的成本、性能和体验。

1. 上下文长度限制

模型的“最大token数”是硬约束。输入+输出都算在内。如果你的提示词很长、检索回来的文档很多，很容易触顶。常见做法包括：压缩提示词、对长文档做分段摘要、只保留最相关的检索片段。

2. 计费与成本

大多数大模型API按token计费，输入和输出分别计价。这意味着同样一段话，用不同语言、不同表述，成本可能不同。例如英文通常比中文更“省token”，因为一个英文单词可能只占1个多token，而中文一字一token。

3. 推理速度与延迟

token数量直接影响生成时间。输出token越多，耗时越长。在产品设计中，控制输出长度、设置合理的max_tokens，是优化响应速度的常规手段。

七、一个简单的估算示例

假设你在做一个问答应用，用户问题平均20个汉字，检索到的文档片段500个汉字，系统提示词100个汉字，模型最大上下文为4096个token。

粗略估算：

输入token ≈ 20 + 500 + 100 = 620
剩余可用于输出的token ≈ 4096 - 620 = 3476

看起来够用。但如果检索片段变成2000字，输入就逼近上限，输出空间被严重压缩，甚至直接报错。这就是为什么在RAG（检索增强生成）类应用中，控制检索片段长度和数量是核心工程问题之一。

八、总结：把token当成“模型的计量单位”

回到最初的类比：token确实有点像代币——它是你“投喂”给模型的计量单位。但它不是随意的，而是由分词器按照统计规律切分出来的文本片段。

记住三句话：

1. token是模型处理文本的最小单元，不等于字，也不等于词。
2. 切分依据是频率：高频组合打包，生僻内容切碎。
3. token数量直接决定上下文限制、成本和速度，是工程实践中必须关注的指标。

下次再看到“exceeded maximum token limit”，你就知道该数什么、该省什么了。