大模型通识 / 大模型理论基础
1. 文字怎样进入模型：Token、分词与文本表示
原文备份 · 第 2 / 20 篇 · 查看极客时间原知识库 ↗
本篇目录 · 11 节
来源：大模型理论基础
你准备把一篇笔记交给复习助手。编辑器显示它有几千字，模型服务却报告另一组长度：输入用了多少 Token，回答又用了多少 Token。
两者为什么不同？把中文翻译成英文，会不会更省？删除空格能不能多塞几段材料？模型明明读懂了一句话，为什么有时连其中某个字母出现几次都数不准？
这些问题都与文字进入模型的方式有关，但不能只用“模型不识字”解释。我们先沿着一条具体路径走进去：文字经过分词，变成编号，再转成模型可以计算的向量。
本篇是第二部分的起点。没有通读第一部分也可以继续：只需知道，模型用一组已经训练好的参数处理输入；普通调用不等于重新训练。下面的词表、向量、容量和价格均为教学构造，不对应某个实际模型。无需安装分词库或付费调用 API。
一、Token 是处理单元，不是“字数”的英文名字
Token在这里指文本被编码后，模型处理的离散单元。负责完成这种转换的组件叫 Tokenizer，分词器；整个过程叫 Tokenization，分词或标记化。
中文里“分词”容易让人想到把“人工智能”拆成符合语言习惯的词。但大模型分词不一定以人类词语边界为目标：一个 Token 可以对应整词、词的一部分、标点，或某种字节片段。Hugging Face：分词算法概览
先看四种容易混淆的单位：
| 单位 | 在关注什么 | 需要注意的区别 |
|---|---|---|
| 字符 | 文本中的字符，例如“猫”、字母 a |
软件统计字符的口径也可能不同 |
| 词 | 语言中的词语，例如“复习” | 中文词语不一定由空格分隔 |
| 字节，Byte | 文本在某种编码下的存储单位 | 字节数取决于编码，不等于 Token 数 |
| Token | 指定分词器输出的处理单元 | 必须结合分词器判断数量 |
例如，cat 有 3 个英文字母；“猫”在这个简单例子中是 1 个汉字。两者使用 UTF-8 编码时都占 3 个字节。但仅凭这些信息，仍不能断言它们各占几个 Token。
对于中文，同一段文字可能有多字合成一个 Token，也可能一个汉字被表示成多个 Token。对于英文，一个单词也不保证恰好一个 Token。字符、词、字节与 Token 之间，没有跨模型通用的固定换算比例。
二、亲手把一句话变成编号
沿用第一部分出现过的句子：
我用卡片复习概念
它有 8 个汉字。为了看清流程，我们自己规定一个极小词表，也就是“允许使用哪些单元，以及每个单元的编号”：
| Token | ID | Token | ID |
|---|---|---|---|
| 我 | 0 | 用 | 1 |
| 卡 | 2 | 片 | 3 |
| 复 | 4 | 习 | 5 |
| 概 | 6 | 念 | 7 |
| 卡片 | 8 | 复习 | 9 |
| 概念 | 10 | — | — |
再规定一个仅用于本例的切分规则：从左向右走，每次优先匹配词表中最长的片段。
于是得到：
原文：我用卡片复习概念
片段：[我] [用] [卡片] [复习] [概念]
编号：[0, 1, 8, 9, 10]
这里是 8 个汉字、5 个 Token。编号序列通常称为 Token IDs。将文本转成编号是编码；依据词表和解码规则把编号转回文本，则是解码。
这个例子里的 ID 只是身份编号。复习的 ID 是 9，不说明它比 ID 为 8 的卡片“更重要”，也不说明两者在语义上距离为 1。不能对 ID 直接做加减来计算语义相似度。
如果另一个词表只有前面 8 个单字，这句话就会拆成 8 个 Token。文字没变，长度却变了。另一个分词器还可能让 ID 9 对应完全不同的内容，所以不能随意混用某个模型的权重和另一个模型的分词器。
本例只支持表内片段，没有设计生僻字、空格、标点或未收录内容的处理规则。它不是可用于真实项目的完整分词器，也不是 BPE 的完整实现；它只用来解释“切分—查编号—解码”这条路径。
三、为什么不总是一个字一个 Token
按单字或单字符切分，规则直观，但较长内容会变成很长的序列。如果为每个完整词语都准备编号，词表又会面临人名、新词、专业术语和代码标识符不断增加的问题。
一种常见折中是子词，Subword：保留一些常见片段，把未作为整体收录的词拆成更小的片段。这样不必为所有完整词语各留一个位置。Sennrich 等人的原始研究将子词表示用于处理机器翻译中的罕见词和未收录词。子词单元原始论文
你可能听过 BPE，Byte Pair Encoding。在常见的字符级教学解释中，它从小单元开始，统计训练语料里相邻单元的出现情况，逐步合并频繁的组合，形成更大的片段。例如，在一个虚构语料中，“卡”和“片”经常相邻，就可能形成“卡片”这一条目。
重点是：这种规则通常依据语料统计形成，不是每次先让大语言模型读懂整段话，再决定该怎么分。BPE、WordPiece、Unigram 有不同规则，不能把前面的“从左到右最长匹配”当成所有分词算法的定义。Hugging Face：BPE 与其他子词算法
还有 SentencePiece。它是分词工具，不是某一种大语言模型；可以直接从原始句子训练子词模型，不要求先按空格分出完整词。这个设计对理解中文、日文等文本的处理很有帮助。SentencePiece 论文
这里出现了两种不同的“训练”：训练分词器，是形成词表和切分规则；训练语言模型，是学习怎样利用编码后的序列完成预测等任务。使用已经配套的分词器编码一篇新笔记，通常不会自动扩充词表，也不等于更新语言模型参数。
词表更大、同一段话的 Token 更少，也不必然意味着模型更强。词表、序列长度、训练材料和模型设计之间有取舍；数量只是其中一个方面。
四、编号之后，还要变成向量
一串整数已经可以让程序确定“有哪些单元”，但模型通常不会把 ID 的大小当成语言含义。
常见做法是通过 Token Embedding，Token 嵌入，为每个 ID 取出对应向量。可以把这一层理解为一张可学习的数字表：每行属于一个 Token，每行有固定数量的数。PyTorch 2.9：Embedding 查表与形状
为了看清形状，给本例中用到的五个 ID 指定三维向量。以下数值完全由我们编写，没有来自真实模型，也不为三个坐标指定人类含义：
| ID | 对应片段 | 教学向量 |
|---|---|---|
| 0 | 我 | [0.2, -0.1, 0.5] |
| 1 | 用 | [0.0, 0.4, 0.1] |
| 8 | 卡片 | [0.7, 0.3, -0.2] |
| 9 | 复习 | [0.6, -0.4, 0.8] |
| 10 | 概念 | [-0.1, 0.9, 0.2] |
于是 [0,1,8,9,10] 变成 5 行、每行 3 个数，即一个 5×3 的矩阵。5 是本次序列长度，3 是我们假设的嵌入维数。完整词表有 11 项，若都使用三维可学习向量，那么仅这张表就有 11×3=33 个数；本次取出的 15 个数不是整张参数表。
原始文字
↓ 分词、映射编号
Token IDs：[0,1,8,9,10]
↓ 嵌入查表
5×3 的初始表示
↓ 后续模型层，结合位置和上下文进行计算
用于预测输出的内部表示
在这种查表设计中，同一个 ID 先取出同一行初始向量；之后经过上下文计算，它在不同句子里的表示可以不同。最初的 Token 向量，不能直接当成“这个词在当前句子中全部含义”的最终表示。
也不要把它与“把整篇笔记变成一个检索向量”混为一谈。前者是语言模型输入链路里的单元表示，后者是为了比较文档等对象而设计的表示任务。第二部分第 10 篇会专门讲语义检索。
五、空格、中文和代码，为什么会让估算失准
你在编辑器里看到的是文字，分词器处理的是完整输入字符串及其规则。大小写、空格、换行、数字和标点，都可能改变切分。
例如这些文本看起来关联很强，却不能直接假定 Token 数相同：
复习卡片
复习 卡片
review_card
reviewCard
这里不提供某款模型的具体计数，因为没有指定它的分词器。要获得实际结果，应对这些原样字符串使用目标模型对应的工具进行编码，而不是根据视觉长短猜测。
字节级方法还有一个容易困惑的现象：某个 Token 可能只覆盖一个字符的部分字节，单独把它显示成文字会不完整；要按正确的解码方式组合整个序列。不要因为某个查看工具展示了奇怪片段，就直接判断原文被模型弄坏了。
另外，分词流程可能包含规范化，例如转小写或统一某些字符形式，具体是否发生取决于实现。若原始差异在这个步骤被消去，解码后就未必逐字节还原输入。Hugging Face 的管线文档将规范化、预切分、单元编码与后处理分开，也展示了解码过程。分词处理管线
因此，对复习助手可以保留两份有不同用途的数据：原始笔记用于展示、追溯和忠实性核对；交给模型的实际文本用于分析输入与计数。不要用解码后的文本无条件覆盖原文件。
代码尤其不能为了省 Token 随便删除空白。Python 的缩进会影响代码块，字符串里的空格也可能是内容的一部分。模型的 Token 与编程语言解析器的语法单元也不是同一概念：一个变量名可能占多个模型 Token，并不因此变成多个程序变量。
对于数特定字母、比较精确字符串、检查固定格式等任务，分词方式会影响模型接触这些细节的方式，但并不是所有错误的唯一原因。需要可靠计数时，把原始字符串交给确定的程序计算，再让模型解释结果，通常更容易验证。
六、一条聊天消息之外，还有哪些输入
你在界面里只写了一句“把笔记做成卡片”，模型实际接收的序列可能还包含系统要求、历史对话、笔记正文，以及消息之间的边界标记。
聊天模型通常通过某种聊天模板，Chat Template，把角色和内容组织成它训练时熟悉的形式。不同模型使用的格式和控制标记可能不同；配错模板会影响模型怎样理解对话结构。Hugging Face：聊天模板
可以用下面这个抽象示意理解它，方括号中的标记不是某家服务的真实语法：
[系统角色] 按给定笔记生成一道题 [消息结束]
[用户角色] 笔记：…… [消息结束]
[助手角色] 接下来开始生成回答
这类表示结构的单元通常涉及特殊 Token，用于表达消息边界、序列起止或其他约定。它们不是普通自然语言词语。某段看起来像特殊标记的文本，是否真的被当成控制单元，取决于具体编码流程，不能只看外形。
使用封装好的聊天 API 时，一般由服务处理这些格式；你应按接口传递角色与内容，不要照着某篇截图随意手工拼标记。使用本地开放权重模型时，则要确认分词器和聊天模板与模型配套。
所以，只统计最后一句用户消息的 Token 数，常常会低估请求实际长度。统计对象应尽量接近最终送入模型的内容。
七、把长度限制写成一笔可检查的预算
上下文窗口描述一次处理可容纳的上下文范围，通常用 Token 表示。这里先用一个简化、假想的服务约定练习：输入与预留输出合计不能超过 8000 Token，输出本身也有单独上限。
假设已经按该服务的完整格式统计：
| 项目 | Token 数 |
|---|---|
| 笔记正文 | 5700 |
| 指令、历史消息和格式开销合计 | 1200 |
| 为回答预留 | 1000 |
| 合计 | 7900 |
因此还有 8000−7900=100 Token 的余量。不是看见笔记只有 5700，就以为还能再放 2300 Token 的笔记：这样会挤掉其他输入和回答空间。
若再加入 500 Token 的材料，合计变成 8400，就违反本例约定。需要减少输入、减少可接受的输出预算，或选择合适的服务容量；具体接口遇到超限会报错还是截断，要看其文档，不能假定模型会自动保留最重要的内容。
这个 8000 是教学数字，不能套用到真实模型。实际服务可能分别规定输入、总上下文、最大输出等限制，推理模型还可能有额外的计数口径。第 08 篇会详细解释上下文、缓存与记忆，这里先学会为完整请求留空间。
能装进去，也不等于一定用得好。 两段资料在长度内，并不能保证模型找出它们的冲突；上下文容量与任务效果需要分别检查。
八、Token 怎样进入费用与开发判断
许多模型 API 按输入、输出 Token 数量计费。以 DeepSeek 的官方用量说明为例，它明确说明字符比例只是近似，实际用量应查看服务返回的统计；不能把某个经验比例当成所有文本的精确计数。DeepSeek：Token 与用量
这里只做一笔假想账单，下面的单价不是 DeepSeek 或其他厂商报价：假设输入每百万 Token 收 1 元，输出每百万 Token 收 2 元，没有其他计费项。
沿用前例，完整输入是 6900 Token；假设最终实际输出 600 Token，则：
输入费用：6900 ÷ 1000000 × 1 = 0.0069 元
输出费用： 600 ÷ 1000000 × 2 = 0.0012 元
合计：0.0081 元
前面预留了 1000，实际只生成 600。在这个假设的按实际用量计费方式中，输出按 600 计算。真实服务的价格分类、缓存、推理用量等规则，要另外看当时文档和返回明细。
一次调用的金额很小，也不代表一个任务只需要一次调用。反复重试、多轮对话或多步骤 Agent，都可能带来额外请求；历史内容如果再次作为输入发送，也要按对应服务口径计量。
开发时可以形成一个简短检查顺序：先确定模型与配套分词器，再统计真实请求结构，最后核对服务返回的用量。遇到“同样字数，消耗差很多”，先检查语言、格式、历史消息和工具提供的内容，不要只比较输入框里的字数。
同样，“把中文翻译成英文就一定省钱”也不能成立。翻译会改变文本和可能的分词结果，还可能损失术语细节、增加额外调用。应在相同任务要求下比较总成本与效果，而不是把某种语言当成通用的省 Token 开关。
九、六道理解检查
请用本篇的教学约定回答，不需要询问模型。
- 按本篇词表和最长匹配规则，“我用卡片复习概念”是多少个 Token？ID 序列是什么？
- 同样规则下，“我用卡片”会得到什么 ID 序列？如果每个 Token 的向量是三维，输出矩阵形状是什么？
卡片的 ID 是 8，复习的 ID 是 9，能否据此判断它们语义接近？- 词表含 11 项，每项三维。完整嵌入表有多少个数？输入五个 Token 之后，是不是整个模型只有 15 个参数？
- 输入正文 5700 Token，其他输入 1200，预留输出 1000。在本篇 8000 总预算下，再加 500 Token 是否可行？
- 某段中文有 100 个字，是否一定有 100 个 Token？格式检查通过，是否意味着分词器已经理解了笔记的真实含义？
参考答案
- 5 个，
[0,1,8,9,10]。这仅在我们定义的词表和规则下成立；真实模型需要实际编码。 [0,1,8]，共 3 个 Token，因此是3×3。前一个 3 是序列长度，后一个 3 是向量维数。- 不能。ID 是查表编号，不是语义坐标。初始向量和后续上下文表示才参与模型的相关计算，编号相邻不代表含义相近。
- 嵌入表有
11×3=33个数；五个 Token 取出的表示有 15 个数。它们与整个模型参数量是不同概念，模型通常还包含许多其他层。 - 不可行。
5700+1200+1000+500=8400，超过 8000。需要重新安排预算，而不是只检查正文是否短于窗口。 - 不一定。Token 数取决于分词器与具体文本；分词和格式检查主要完成表示转换及结构检查，不能单独证明模型理解正确，更不能证明内容符合事实。
下一步：单元之间怎样交换信息
现在，文字已经从可见字符变成了 Token IDs，再变成向量序列。但仅给每个单元查一行向量，还不能解释“它”指代谁，也不能把一句话前后的条件联系起来。
下一篇《注意力机制：模型怎样利用上下文中的信息》，会接着这条计算路径，解释模型如何根据当前内容利用其他位置的信息。
上一篇：第一部分第 12 篇：怎样判断 AI 有没有进步 · 第二部分大纲 · 第一部分大纲
资料观察基准：2026 年 10 月 3 日。本文以常见文本分词与嵌入流程为范围，不把所有模型的输入机制概括为同一种实现。