Token 是什么：大模型真正读到的不是一句完整的话

人看到一句话，会自然按字、词、标点和语气去理解。大语言模型不这样读。它会先用分词器把输入文本切成一段段 token，再把这些 token 转成数字表示，交给模型继续计算。也就是说，模型真正接收的不是“这是一整句话”，而是一串 token 序列。

LLM 全教程总结里有一句很重要的提醒：前面为了方便理解，可以说语言模型预测下一个词，但实际技术细节是，模型预测的是下一个 token。这个差别不只是术语精确一点。很多模型行为，比如为什么长文本会占满上下文、为什么反转字母会出错、为什么不同语言消耗 token 不同，都和 token 有关。

可以把 token 理解成模型的阅读颗粒。颗粒太大，词表会变得很大，稀有词很难覆盖；颗粒太小，序列会变长，模型处理成本上升。现代大模型通常不会只按完整单词，也不会只按单个字符，而是使用介于两者之间的子词方案，让常见词尽量保持完整，让生僻词可以拆开组合。

按词切听起来最符合人的习惯。英文单词之间有空格，中文也可以用分词工具切词。但大语言模型基础与实践学习笔记指出，词粒度有一个麻烦：词表会非常大。语言里有大量长尾词、专有名词、新词、拼写变化和代码标识符，如果每个词都放进词表，存储和训练成本都会上升。

更麻烦的是 OOV，也就是词表之外的词。一个从没见过的产品名、用户名、函数名、外语词，如果模型词表里没有，按词切就不好处理。字符粒度能解决覆盖问题，因为任何词都能拆成字符，但它又会把序列拉得很长。比如一个普通句子按字符切，token 数会明显增加，模型需要处理的上下文更长，计算成本也更高。

子词粒度就是折中方案。常见词可以保持比较完整，少见词可以拆成更小片段。资料里提到 BPE、WordPiece、Unigram Language Model 等算法，核心思路都是在词表大小、语义表达和编码效率之间找平衡。对普通使用者来说，不必记每个算法细节，先知道模型看见的是“切分后的片段”，就够解释很多现象。

LLM 全教程总结里给过一个经验：英文输入里，一个 token 通常约等于 4 个字符，或者大约四分之三个单词；中文输入里，一个 token 通常对应一个或半个词。这个数字不是绝对规则，不同模型、不同分词器会有差异，但它能帮助你建立直觉：同样是 1000 字，不同语言和写法消耗的 token 可能不一样。

中文没有天然空格，分词器会按自己的规则切。一个常见词可能是一个 token，复杂词或少见词可能拆成多个。代码也很特殊。函数名、缩进、括号、下划线、字符串、路径、JSON 字段，都可能被切成很多小片段。所以你把一大段代码、日志或配置文件交给模型时，token 消耗可能比肉眼感觉更多。

这就是为什么处理长 资料、长网页、代码仓库或日志时，不能只按字数估算。更稳的做法是先清理无关内容，比如页眉页脚、重复目录、广告导航、无用日志，再分段处理。清理掉 2000 字噪声，不只是让文本更干净，也是在给模型腾出上下文空间。

很多人只把 token 当成计费单位，其实它更像一次请求的空间预算。LLM 全教程总结里讲得很直接：token 限制是输入 Prompt 和输出 Completion 的 token 数之和。输入越长，留给输出的空间越少。

这点在写长提示词时很容易被忽略。系统消息、角色设定、背景材料、示例、用户问题、前几轮对话，都会占 Prompt token。模型生成的答案，则占 Completion token。如果你一次粘贴大量 资料 内容，又要求模型输出一篇很长文章，系统可能因为空间不够而截断输出，或者根本放不下完整输入。

所以，长任务要学会分配预算。需要模型总结整份资料时，先切成章节；需要写长文章时，先提纲再分节生成；需要保留格式时，示例不要堆太多；需要事实准确时，把相关材料放进上下文，而不是把所有资料一股脑塞进去。token 预算不是越大越好，而是要把空间留给真正有用的信息。

Token 最能解释的一类现象，是模型在某些看似简单的文字任务上会出错。LLM 全教程总结里用了 `lollipop` 的例子：让模型反转这个单词的字母，它可能给出错误结果。原因不是模型不知道英语单词，而是它未必把这个词当成一串独立字母来处理。

分词器可能把一个词切成几个片段。模型在生成时处理的是 token 序列，而不是你眼里的每一个字母。你让它“反转字母”，它需要把 token 里的字符结构拆开再重排，这对它来说并不是天然任务。资料里还提到一个改法：把字母之间加上分隔符，让每个字母更容易成为独立片段，模型就更容易按字母处理。

这件事对日常使用很有启发。需要模型处理非常细的字符级任务时，比如逐字反转、逐字符校验、统计某个字符出现次数、精确操作编号，最好把输入拆清楚，或者改用专门程序。大模型擅长语言理解和生成，不代表每个字符操作都可靠。

在实际使用里，token 不只是理解模型原理的概念，也会影响速度和成本。模型处理的 token 越多，请求越慢，费用也可能越高。长上下文模型能放进更多内容，但这不等于应该把所有资料都塞进去。无关 token 越多，模型越难聚焦，生成时也更容易被噪声带偏。

一个实用习惯是先整理材料，再交给模型。资料 复制出来的页码、页眉、重复标题，网页里的导航和推荐阅读，日志里的重复行，都可以先清掉。Prompt 也要少写空话。与其写一大段“你是一个经验丰富、思维严谨、擅长多领域分析的专家”，不如写清楚任务、材料范围、输出格式和边界。

当你发现模型回答到一半停了、总结漏掉后半段、长文处理很慢、费用明显上升，先别急着怀疑模型。回头看 token：输入是不是太长，材料是不是太乱，输出要求是不是一次要太多。很多问题不是能力不够，而是上下文预算没有管好。

第一，材料要有边界。用分隔符把资料框起来，删掉无关段落。第二，示例要少而准。少样本提示很有用，但示例过多会吃掉上下文。第三，长任务拆开做。先让模型提炼目录，再写某一节；先抽取事实，再做润色；先检查资料缺口，再生成正文。

第四，格式要明确。让模型输出表格、JSON、Markdown 时，把字段写清楚，避免它为了猜格式消耗空间。第五，必要时让模型先返回 token 级别的粗略判断，比如材料是否过长、是否需要分块、哪些段落最相关。你不一定要精确计算 token，但要有预算意识。

对普通使用者来说，Token 不是一个需要背公式的概念。它更像提醒你：模型不是按人眼里的文章长度工作，而是按可计算的片段工作。把材料切干净、把任务写清楚、把长工作拆开，通常比单纯换一个更大的模型更有用。