大模型不能直接读文字，它读的是一串 token。把一段文字切成这些 token 的工具叫分词器，它决定了模型能读多长、以及你每次调用要花多少成本。理解分词器，能解释好几个日常现象：为什么模型算数容易错、为什么中文通常比英文更「费 token」、为什么「让它少废话」真的能省钱。这些现象背后，都是 token 层面的结果。
分词器到底切了什么
模型看到的文本，先要经过分词器变成一个个离散单元，每个单元对应词表里的一个编号。模型既非逐字读，也非整句读，它是按 token 读的。一个 token 可能是一个常见英文单词，也可能是中文的一个字，还可能是半个生僻词。分词器的切法，直接决定了同样一句话会变成多少个 token，进而影响两件事：模型一次能装下多少内容，以及按 token 计费时你要付多少。
三种切法各有什么取舍
切法不是唯一的，不同方案各有利弊，下表是三种常见思路的对比。
| 切法 | 怎么做 | 优点 | 缺点 |
|---|---|---|---|
| 按字切 | 每个字单独成一个 token | 简单、词表小 | 序列长、同等内容 token 多 |
| 按词切 | 整词作为一个 token | 序列短、效率高 | 词表大、遇新词难处理 |
| 子词切分 | 常见词整体切，生僻词拆成小块 | 折中、兼顾长度与词表 | 仍有碎切、符号易被拆散 |
子词切分是目前的主流，常见实现有 BPE 等算法。它的思路是：高频常见词整体保留，低频生僻词拆成几个可复用的小块，这样词表不必无限膨胀，又能应付没见过的词。这也是大语言模型能处理海量文本的基础之一。
切法如何决定成本与长度上限
上下文窗口按 token 计算，不是按字数计算。同样一段内容，切得越碎，占用的 token 越多，能装进窗口的内容就越少，费用也越高。这解释了为什么「精简提示词」能省钱：少几个字，就少几个 token。反过来说，如果切法不合理，把本可以一个 token 表示的词拆成三四个，模型的可读容量会被无声地压缩。窗口大小和分词器设计，共同决定了模型实际能吃进多少有效信息。
中英文的 token 差异
这是一个很实际的现象：同样含义的内容，中文往往比英文消耗更多 token。英文一个常见单词可能就是 1 个 token，而中文一个常用字可能要 1 个甚至更多 token。原因在于英文天然有空格分词，词表里可以存大量整词；中文需要分词器去「猜」字与字之间的边界。这让中文用户的成本感受更明显，也提醒我们在比较不同语言任务时，不能只看字数，要看 token 数。用分隔符把指令和材料清楚分开，也能减少分词歧义带来的浪费。
数字与符号为什么是弱项
数字和符号容易被切碎，是模型算数偏弱的 token 层面原因。一个多位数字可能被拆成几段，模型要先把它们拼起来再计算，中间任何一步对齐出错，结果就错。生僻字和特殊符号可能被拆成好几个 token，甚至落到词表之外。空格和换行同样占 token，这也是「让它少废话」能省钱的直接来源。理解了这一点，你就知道模型的算数问题，很多时候是「没把数字看成一个整体」，并非「不懂数学」。
分词器做不到什么
分词器只负责切分，不负责理解。它不会判断语义，也不能替模型补齐上下文；切得再好，也只是把原始文字无损地变成 token 序列。一旦遇到词表里完全没有的内容、或者生僻到拆不出合理小块的字符，分词器就可能产生碎块甚至错误，这部分错误会原样传给模型。分词器还无法改变「窗口按 token 计」这个前提，它只能让同样的窗口装下更合理的内容，不能凭空扩大容量。
一条能直接用的判断
评估模型成本或长度时，先问「这段内容是多少 token」，比问「多少字」更接近真相。写提示词时尽量精简、用分隔符减少歧义，都是 token 层面的实在优化。训练侧的反向传播同样受到词表与切分质量的影响，词表不合理会让训练效率下降。分词器虽不显眼，却是成本、长度、效果三者共同的底层变量。
速查：分词器要点
- 模型读的是 token，不是字或整句。
- 三种切法：按字、按词、子词切分。
- 窗口按 token 计，切得碎＝装得少、花钱多。
- 中文通常比英文更费 token。
