Tokenizer · 交互图解

模型眼里
没有「字」,只有 token

你打进去的是一句话,模型收到的是一串编号。 把文本切成编号的那一步,就是分词(tokenization)。 它决定了:一句话占多少 token、上下文够不够用、中文为什么「更贵」。

1 字 ≠ 1 token
中文一个字可能占 1–2 个
词表 ≈ 5万–15万
像一本可组合的「乐高字典」
按 token 计费
API 账单的基本单位

像压缩字典,又像乐高

如果直接给每个汉字一个编号,词表太大,生僻组合也学不好。 现代分词(常见是 BPE 一族)的做法是:

程序员类比: 这有点像「把长字符串用字典里的短码表示」——只不过码表是训出来的, 目标是:既覆盖常见模式,又不把词表撑到爆炸。

点一个样本,看它被切成几块

下面是教学示意的分词器(启发式规则,不是某家厂商的真实词表)。 颜色块 = 一个 token。可改输入,或点预设。

分词实验台
输入或选预设 · 看色块
切分结果(色块 = token)
Token 数
字符数
大致效率
怎么看色块? 块越碎,说明这段文本对词表来说「不够常见」。 生僻人名、URL、代码标识符,往往碎成一串。

为什么不直接按「字」或「词」?

按字

词表小,但每个词都要拼,序列变长。

英文 unbelievable 若按字母会占 12 个位置,注意力要算更久。

按词

序列短,但词表爆炸,新词/OOV 处理麻烦。

昨天的新梗、新 API 名,词表里没有就卡住。

子词 BPE(主流)

高频整词,低频拆开。词表可控,新词也能拼。

GPT-4o-mini-2024 这类标识符也能表达。

和你写代码的关系: 上下文窗口按 token 计,不按字符计。 同样 8k 窗口,塞英文文档比塞同信息量的中文更「省」——这就是为什么中文场景 token 消耗更快。

上下文窗口还剩多少?

把序列长度、输出预留、对话历史拖一拖,看 128K 窗口下还能塞多少文档。

上下文预算计算器
拖动滑杆 · 实时更新
窗口占用
调整滑杆试试。

四句话带走

  1. 模型读的是 token 编号,不是你看到的字。分词在进模型之前就发生了。
  2. BPE:常见整块,生僻拆开。兼顾词表大小和表达力。
  3. 中文常常更费 token,同样内容可能比英文占更多窗口。
  4. 上下文预算要留出输出——只算「塞进去多少」会翻车。