在传统软件开发中，我们习惯关注 CPU、内存、磁盘和网络带宽。

但进入大模型时代后，一个新的资源单位开始频繁出现在开发者的视野中：

Token。

无论是调用大模型 API、构建 RAG 知识库，还是开发 Agent 智能体系统，几乎所有与大模型相关的工程实践，都绕不开 Token。

很多开发者在实际项目中都遇到过类似问题：

• 为什么一份只有几万字的文档，却提示超出 Context Window？
• 为什么 GPT-4o 和 Qwen 处理同一份内容，消耗的 Token 数量却不一样？
• 为什么 Agent 增加几个工具后，模型响应速度明显下降？
• 为什么 Prompt 看起来只增加了几百字，API 成本却翻倍增长？
• 为什么长上下文模型拥有数十万甚至百万 Token 的窗口，却仍然无法无限记忆历史内容？

这些问题看似毫无关联，但背后都指向同一个核心概念：

Token。

很多人认为 Token 就是字数统计。

实际上并不是。

在大模型内部：

• 模型读取的是 Token；
• 模型推理的是 Token；
• 模型生成的也是 Token；
• 上下文窗口统计的是 Token；
• API 计费统计的还是 Token。

从某种意义上说，Token 才是大模型真正理解世界的语言。

而文字、图片、代码、工具描述、RAG 文档，最终都会被转换成 Token 后再交给模型处理。

那么问题来了：

Token 到底是什么？

它为什么不是字，也不是词？

Tokenizer 又是如何把自然语言转换成模型能够理解的数字世界？

本文将从 Tokenizer、Token ID、Vocabulary、Embedding、BPE 等底层机制出发，系统拆解 Token 的工作原理，并结合 Prompt、RAG、Agent 等工程实践，理解大模型背后的这套“文字压缩术”。

读完本文，你将理解：

• Token、Token ID、Embedding 的区别；
• Tokenizer 如何完成编码与解码；
• BPE 为什么能压缩文本；
• Context Window 为什么按 Token 计算；
• Token 如何影响 Prompt、RAG、Agent 和 API 成本。

---

一、Token 是模型处理文本的基本单位

从工程角度看，Token 可以这样理解：

Token 是文本经过 Tokenizer 切分后，交给模型处理的基本单位。

它可能是一个字，也可能是一个词，还可能是一个词的一部分，甚至可能是一个特殊符号片段。

例如一句话：

用户喜欢人工智能吗

从人类视角看，这句话有 9 个汉字。

但从模型视角看，它可能被切成：

用户 / 喜欢 / 人工智能 / 吗

也就是 4 个 Token。

这就是 Token 的关键特点：

Token 不等于字，也不等于词，而是模型自己的文本切分单位。

它的存在，是为了让模型更高效地处理文本。

---

二、大模型为什么不直接读文字？

很多人第一次接触大模型时，会天然以为模型能“理解文字”。

但从计算机系统角度看，大模型本质上是一个巨大的数学函数，内部运行的是矩阵运算。

它真正接收的是数字，输出的也是数字。

也就是说：

人类输入：文字
模型输入：数字
模型输出：数字
人类看到：文字

中间必须有一个翻译层，负责把文字和数字互相转换。

这个翻译层就叫 Tokenizer。

Tokenizer 负责两个核心环节：

1. 编码 Encoding：把文本转换成 Token ID。
2. 解码 Decoding：把 Token ID 转换回文本。

可以把 Tokenizer 理解为人类语言和模型数字世界之间的“翻译官”。

---

三、Tokenizer 的编码流程：文本如何变成数字？

假设用户输入：

用户喜欢人工智能吗

Tokenizer 会先做编码。

编码一般包含两个步骤：

文本 -> 切分为 Token -> 映射为 Token ID

1. 切分：把文本拆成 Token

Tokenizer 会按照自己的规则，把文本切成一个个 Token。

例如：

用户喜欢人工智能吗

可能会被切成：

用户 / 喜欢 / 人工智能 / 吗

这里的每一段，都是一个 Token。

注意，这不是中文分词器意义上的“词”。Tokenizer 的切分规则来自训练过程，而不是语文课本或词典。

2. 映射：把 Token 变成 Token ID

模型不认识“用户”“喜欢”这些文字。

所以 Tokenizer 还要把每个 Token 映射成一个数字：

用户 -> 35
喜欢 -> 36
人工智能 -> 42
吗 -> 9

这些数字就叫 Token ID。

最终，模型拿到的不是原始文本，而是一串数字：

[35, 36, 42, 9]

这才是模型真正处理的输入。

---

四、Token ID 有语义吗？

一个常见误解是：

语义相近的 Token，它们的 Token ID 也应该接近。

这个理解是错的。

Token ID 本质上只是词表里的编号。

它的作用是告诉模型：

这个数字对应词表里的哪个 Token

例如：

用户 -> 35
喜欢 -> 36
人工智能 -> 42

这里的 35、36、42 只是编号，不代表语义距离。

真正承载语义关系的是模型内部的向量表示，也就是经过 embedding 层之后的高维向量，而不是 Token ID 本身。

所以要区分两个概念：

概念	作用
Token ID	词表编号，用于索引 Token
Embedding	模型内部向量表示，用于表达语义

Token ID 是入口编号，Embedding 才是模型理解语义的起点。

---

五、Tokenizer 的解码流程：数字如何变回文字？

模型生成回答时，输出的也是 Token ID。

例如模型输出：

36

Tokenizer 会查词表：

36 -> 喜欢

于是人类看到的输出就是：

喜欢

如果模型继续输出更多 Token ID：

[36, 42, 9]

Tokenizer 就会把它们还原成：

喜欢人工智能吗

解码过程比编码更简单。

编码时需要先切分，再映射。

解码时通常只需要根据词表做反向映射：

Token ID -> Token -> 文本

---

六、Tokenizer 是怎么训练出来的？

理解了编码和解码之后，下一个问题是：

Tokenizer 的切分规则从哪里来？

答案是：

Tokenizer 也是训练出来的。

不过它的训练过程和大模型训练不同。

大模型训练涉及复杂的参数优化、梯度下降和大规模矩阵计算；Tokenizer 的训练更像是在语料中统计哪些字符或片段经常一起出现，然后把它们合并成更大的 Token。

业界常见的 Tokenizer 算法包括：

• BPE，Byte Pair Encoding
• Unigram
• WordPiece

其中，OpenAI、Anthropic 等模型体系中常见的是 BPE 或类似机制；Google 体系中也常见 Unigram、SentencePiece 等方案。

本文重点用 BPE 解释 Tokenizer 的核心思想。

---

七、BPE：把经常一起出现的片段合并起来

BPE 的核心思想非常朴素：

在训练语料中，统计哪些相邻片段最常一起出现，然后把它们合并成一个新的 Token。

我们继续用这句话做例子：

用户喜欢人工智能吗

假设训练材料里，“智”和“能”经常一起出现。

那么 BPE 会把它们合并：

智 + 能 -> 智能

然后把“智能”加入词表，并记录一条合并规则。

接着，如果“人”和“工”经常一起出现，也会合并：

人 + 工 -> 人工

再进一步，如果“人工”和“智能”经常一起出现，还可以继续合并：

人工 + 智能 -> 人工智能

这说明一个关键点：

合并后的 Token 还可以继续参与下一轮合并。

最终，Tokenizer 训练会得到两个核心产物：

1. 词表 Vocabulary
2. 合并规则 Merge Rules

词表记录 Token 和 Token ID 的对应关系。

合并规则记录哪些片段可以按什么顺序合并。

---

八、词表和合并规则如何协同工作？

训练完成后，Tokenizer 会拿到类似这样的信息。

词表

用 -> 1
户 -> 2
喜 -> 3
欢 -> 4
人 -> 5
工 -> 6
智 -> 7
能 -> 8
吗 -> 9
智能 -> 30
人工 -> 31
人工智能 -> 42
用户 -> 35
喜欢 -> 36

合并规则

智 + 能 -> 智能
人 + 工 -> 人工
人工 + 智能 -> 人工智能
用 + 户 -> 用户
喜 + 欢 -> 喜欢

当用户输入：

用户喜欢人工智能吗

Tokenizer 会先把它看成单字序列：

用 / 户 / 喜 / 欢 / 人 / 工 / 智 / 能 / 吗

然后按照合并规则依次合并：

用 + 户 -> 用户
喜 + 欢 -> 喜欢
人 + 工 -> 人工
智 + 能 -> 智能
人工 + 智能 -> 人工智能

最终得到：

用户 / 喜欢 / 人工智能 / 吗

再根据词表映射为 Token ID：

[35, 36, 42, 9]

这就是 Tokenizer 把文本压缩成模型输入的全过程。

---

九、为什么说 Tokenizer 是一种“文字压缩术”？

如果只按单字切分：

用户喜欢人工智能吗

会得到 9 个 Token：

用 / 户 / 喜 / 欢 / 人 / 工 / 智 / 能 / 吗

但通过 BPE 合并后，可以得到 4 个 Token：

用户 / 喜欢 / 人工智能 / 吗

这相当于把 9 个字符压缩成 4 个模型处理单位。

这就是为什么视频把 Tokenizer 称为“文字压缩术”。

它不是简单地把文本翻译成数字，而是在翻译前先做了一次统计意义上的压缩：

常见片段 -> 合并成更大的 Token -> 减少模型处理长度

这种压缩带来的收益非常直接：

• 输入 Token 更少
• 推理速度更快
• 上下文能放更多有效信息
• 训练和推理成本更低

所以 Tokenizer 的质量，会直接影响模型使用体验。

---

十、Token 与 Context Window 的关系

现在回到开头的问题：

为什么 40万 Token 不等于 40万个字？

因为 Token 是 Tokenizer 切分后的单位。

一个 Token 可能对应：

• 一个汉字
• 两个汉字
• 一个常见中文词
• 一个英文单词
• 一个英文单词片段
• 一个符号组合

经验上可以粗略换算：

文本类型	粗略换算
中文	1 Token 约等于 1.5 到 2 个汉字
英文	1 Token 约等于 0.75 个英文单词
英文字母	1 Token 约等于 4 个英文字母

因此，40万 Token 大致可以对应：

• 约 60 万到 80 万个汉字
• 约 30 万个英文单词

当然，这只是经验估算。

实际数量会受到语言、标点、空格、代码、特殊符号、混合文本等因素影响。

这些数值只能用于粗略估算，实际 Token 数应以具体模型的 Tokenizer 统计结果为准。

例如代码文本里大量符号、缩进、变量名、驼峰命名，Token 消耗往往和自然语言不同。

所以在工程实践中，不能只按字符数估算模型成本，而要以 Token 统计为准。

---

十一、为什么不同模型的 Token 数可能不同？

同一段文本，放到不同模型里，Token 数可能不一样。

原因是不同模型可能使用不同 Tokenizer：

• 词表不同
• 训练语料不同
• 合并规则不同
• 算法不同
• 对中英文、代码、符号的处理方式不同

例如同一句中文，在某个 Tokenizer 中可能被切成 20 个 Token，在另一个 Tokenizer 中可能被切成 25 个 Token。

这会影响：

• 成本估算
• 上下文容量
• 文档切块大小
• RAG 召回片段长度
• Prompt 模板设计
• Agent 工具描述长度

因此，做模型迁移或多模型适配时，不能只看模型名称和上下文窗口大小，还要关注 Tokenizer 行为。

---

十二、Token 对工程实践有什么影响？

Token 不是一个只存在于模型论文里的概念。

在真实系统里，它会影响很多工程决策。

1. Prompt 设计

Prompt 越长，输入 Token 越多。

如果 System Prompt 写得过度冗长，工具描述写得不够精炼，历史对话没有压缩，都会快速消耗上下文窗口。

好的 Prompt 工程，不只是“把话说清楚”，还包括“用尽量少的 Token 表达清楚”。

2. RAG 文档切块

RAG 系统不能只按字符数切块，更应该按 Token 预算切块。

如果切块过大，容易超出上下文预算。

如果切块过小，语义不完整，召回质量会下降。

合理切块通常要综合考虑：

• Token 长度
• 语义完整性
• 标题层级
• 段落边界
• 检索召回数量

3. Agent 工具描述

Agent 调用工具时，工具名称、描述、参数 schema 都要放进上下文。

工具越多，描述越长，占用 Token 越多。

这也是为什么 Agent 平台需要：

• 工具分组
• 按需加载工具
• 精简工具描述
• 动态选择工具集

否则模型还没开始执行任务，上下文就已经被工具说明占满了。

4. 长对话记忆

长对话不是无限保存。

当历史对话超过 Context Window 时，系统必须做处理：

• 截断旧消息
• 总结历史
• 提取关键信息
• 写入长期记忆
• 按任务相关性召回

这些策略背后，本质都是 Token 管理。

5. 成本控制

大模型 API 通常按输入 Token 和输出 Token 计费。

如果一个系统每次请求都塞入大量无关上下文，成本会迅速放大。

对企业级应用来说，Token 优化不是细枝末节，而是直接影响预算和毛利的工程问题。

---

十三、常见误区总结

误区	正确认知
Token 等于一个字	Token 可能是字、词、词片段或符号片段
Token 等于一个词	Tokenizer 不等同于自然语言分词器
Token ID 有语义	Token ID 只是编号，语义来自 embedding
Context Window 是字符数	Context Window 统计的是 Token 数
上下文越长越好	长上下文会增加成本、延迟和噪声
不同模型 Token 数一样	不同 Tokenizer 切分结果可能不同
Tokenizer 只是翻译器	Tokenizer 也是一种文本压缩机制

---

十四、一张图理解 Tokenizer

可以把整个流程总结为：

原始文本
↓
Tokenizer 编码
↓
按合并规则切分 Token
↓
查词表映射 Token ID
↓
模型接收 Token ID
↓
模型输出 Token ID
↓
Tokenizer 解码
↓
人类可读文本

再从训练视角看：

训练语料
↓
统计高频相邻片段
↓
不断合并
↓
生成词表 Vocabulary
↓
生成合并规则 Merge Rules
↓
得到 Tokenizer

这两张图合起来，就能解释 Tokenizer 的核心逻辑。

---

十五、最后：Token，本质上是大模型时代的新资源单位

过去的软件系统设计中，我们习惯使用以下指标衡量资源消耗：

• CPU 使用率
• 内存占用
• 网络带宽
• 存储空间
• 数据库连接数

这些指标决定了系统能够承载多少用户、处理多少请求以及需要付出多少成本。

而在大模型时代，一个新的资源单位正在变得越来越重要：

Token。

从技术角度看，Token 不仅仅是文本切分后的结果。

它实际上是连接自然语言与模型计算过程之间的桥梁。

模型看到的是 Token。

模型理解的是 Token。

模型预测的也是 Token。

当我们讨论：

• Prompt Engineering
• RAG 文档检索
• Agent 工具调用
• 长上下文记忆
• API 调用成本
• 推理延迟优化

这些看似不同的问题时，本质上都在解决同一个问题：

如何更高效地利用有限的 Token Budget。

尤其是在 Agent 系统逐渐成为主流的今天，一个复杂任务往往包含：

System Prompt
+
工具描述
+
历史对话
+
长期记忆
+
RAG 召回内容
+
用户输入

在模型开始推理之前，大量 Token 预算实际上已经被消耗掉了。

因此，大模型应用的优化过程，本质上也是 Token 管理的过程：

• 如何用更少的 Token 表达更多信息；
• 如何在有限上下文中保留最关键内容；
• 如何平衡上下文长度、推理质量与成本开销；
• 如何让 Agent 在有限 Token 预算下完成更复杂任务。

理解 Token，并不仅仅是理解一种文本编码方式。

更重要的是理解大模型为什么存在能力边界，长上下文为什么昂贵，Agent 为什么需要记忆压缩，以及企业级 AI 应用为什么必须关注成本控制。

当我们真正理解 Tokenizer、Vocabulary、Token ID 和 BPE 的工作机制后，就会发现：

大模型世界里衡量信息的单位，不再是“字数”，而是 Token；

衡量模型能力的尺度，也不再只是参数量，而是 Token 的处理效率；

而未来 AI 应用架构设计的重要课题之一，也将是如何在有限的 Token Budget 下，实现更高质量的信息表达与任务执行。

这或许正是理解大模型工程化的第一课。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】