零基础认识大语言模型（LLM）工作原理(2.Token 到底是什么？)

最近正好有空,打算抽时间复盘总结一下这些年零零散散学习的AI知识.

首先,我们先从一个疑问开始.

2.1 为什么大模型看不懂文字？

第一次接触大模型时，很多人都会产生一个疑问：

ChatGPT 为什么能够读懂中文、英文、日文，甚至还能写代码？

是不是模型里面真的存放了一个"中文字典"？

或者，它是不是像我们一样，一眼就能看到一个汉字？

答案都是否定。

对于计算机来说，并不存在"文字"这种概念。

计算机能够处理的，永远只有数字。

例如，你现在看到屏幕上的一个字：

你

在人眼里，它就是一个汉字。

但在计算机内部，它通常会先表示成 Unicode 编码，例如：

U+4F60

继续转换之后，又会变成：

01001111……

也就是一长串二进制。

也就是说：

计算机从来没有真正见过"你"这个字，它看到的始终只是数字。

大语言模型当然也是一样。

因此，当我们把一句中文发送给模型时，它首先必须完成一件事情：

把文字转换成模型能够理解的数字。

但是，这里马上会出现另一个问题。

2.2 为什么不能一个字对应一个数字？

假设我们设计一个最简单的大模型。

我们规定：

你 → 1

好 → 2

世 → 3

界 → 4

这样：

你好世界

是不是就可以转换成：

1 2 3 4

看起来非常简单。

为什么现实中的 GPT、Claude、Qwen 不这么做？

原因只有一个：

效率太低。

举个例子。

中文里：

中华人民共和国

如果每个字单独处理。

需要：

中
华
人
民
共
和
国

七次处理。

但是：

如果模型发现：

中华人民共和国

这个词出现了几千万次。

它完全可以把它当成：

一个整体。

例如：

中华人民共和国
↓
一个Token

这样：

模型一次就能识别。

速度更快。

表达的信息也更多。

再举一个程序员更熟悉的例子。

Python：

__init__

如果拆成：

_
_
i
n
i
t

毫无意义。

模型更希望按如下定义token,这样才能更清晰的表示它的维度：

__init__

↓

一个Token

因此：

模型并不是按照汉字或者单词去理解世界。

而是按照这种新的单位：Token。

2.3 什么是 Token？

其实在3月23日中国发展高层论坛2026年年会上，国家数据局局长刘烈宏正式公布，AI领域核心概念Token的标准中文译名为 词元 。这一中文语义其实是相当精准的。

但容易让初学者误以为,Token 就是一个词。

其实完全不是，更准确一点，可以把它理解成：

模型自己发明的一套"文字积木"。

这些积木，有的大，有的小，有的是一个字，有的是半个单词，有的是整个句子。甚至，还有可能只是一个空格。

举几个真实例子。

英文：

apple

可能就是：

apple

一个 Token。

但是：

unbelievable

有可能变成：

un
believ
able

三个 Token。

image

中文呢? 其实也一样,每个模型的规则都可能会有区别

中文：

你好

有些模型：

你
好

两个 Token。

有些模型：

你好

就是一个 Token。

代码：

System.out.println

很可能整个就是一个 Token。

因此Token 并没有固定长度。

它唯一的目标就是：

让模型能够更高效地表示语言。

2.4 Token 是怎么来的？

很多人第一次看到 Token，会认为：

是不是程序员提前规定好的？

例如:你好. 编号是:1234

其实不然。

现代大语言模型中的 Token，大多数都是通过算法自动学习出来的。

训练模型之前，工程师会先收集互联网上的海量文本。

例如：

• 小说
• 新闻
• 论文
• GitHub
• Stack Overflow
• 技术文档

然后统计,哪些字符经常一起出现,举个例子:

中华人民共和国

每天都会出现几十万次。

那么算法就会认为 中华人民共和国 应该作为,一个整体。而不是七个汉字。

同样,程序代码里面：

public static void

经常一起出现。

模型也可能把其中一部分组合成更大的 Token。

这种自动合并过程，就是现代 Tokenizer 的核心思想之一。

它并不是理解了语言。

而是：

根据统计规律，把经常一起出现的字符组合成一个 Token。

2.5 为什么不同模型 Token 数量不同？

很多人第一次使用 API 时会发现,同一段文字,每个模型消耗的token可能不太一样.

GPT：

120 Token。

Claude：

110 Token。

Qwen：

95 Token。

为什么？答案很简单,因为它们使用的是不同的 Tokenizer,也就是说,大家使用的是不同的一套"积木"。

有的人喜欢大积木,有的人喜欢小积木。

举个例子。

一句：

人工智能正在改变世界

模型 A：

可能拆成：

人工智能
正在
改变
世界

四个 Token。

模型 B：

可能拆成：

人工
智能
正在
改变
世界

五个 Token。

模型 C：

甚至可能：

人
工
智
能
……

更多 Token。

因此Token 数量不能直接比较模型性能。

它只是Tokenizer 的设计不同,当然Tokenizer 设计的好,对模型的准确性还是帮助很大的。

2.6 Token 和 Token ID

到了这里,模型已经有了一堆 Token。

例如：

你好
世界
苹果
今天
....

但是,模型仍然不能直接处理这些 Token。

因为Token 本质还是字符串。

计算机真正喜欢的是整数。

于是每一个 Token,都会获得一个唯一编号。

例如：

于是：

你好 世界

在真正送进模型之前,已经变成：

1542
825

注意,这里的编号没有任何数学意义。

1542 不比 825 更高级。

它只是字典里的编号。

很像我们常见的新华字典：

苹果
在第100页

并不代表：

苹果这个词比香蕉更重要。

2.7 本章总结

这一章，我们回答了一个看似简单却非常重要的问题：

为什么大语言模型眼里没有"字"、没有"单词"，只有 Token？

现在，我们应该建立起下面这张知识地图：

用户输入文本
        │
        ▼
   Tokenizer（切分）
        │
        ▼
      Token
        │
        ▼
     Token ID
        │
        ▼
（下一章）
大模型绕不开的核心--Transformer

这一章我们需要记住三个关键内容：

1. Token 不是字，也不是单词，而是模型为了高效表示语言而构建的基本处理单元。
2. 不同模型拥有不同的 Tokenizer，因此同一段文本在不同模型中的 Token 数量可能完全不同，这也是不同 API Token 计费存在差异的重要原因。
3. Token ID 只是 Token 在词表中的编号，本身不携带语义信息。真正让模型理解"苹果""北京""程序员"这些概念的，并不是编号，而是下一章将讲到的内容——Embedding（词向量）。