P6-2.2 从字符串、token 到 token ID 的模型输入¶

Section ID: P6-2.2 Version: v2026.07.26

在 P6-2.1 中，我们把 token 抓成用来解释长度、成本、截断、上下文保留问题的计算单位。现在要阅读这个计算单位在 tokenizer 输出和模型输入中会显示成什么值。

这一节的中心，不是宽泛解释 token 这个词。它要区分 tokenizer 输出中可见的 token 字符串、token 数、token ID，并抓住这些 ID 会作为顺序列(sequence) 成为模型输入。

tokenizer 输出中先要区分的值¶

token 是模型处理输入和输出时数到的基本计算单位。不过，在实际输出画面或日志中，token 不会只以一个值出现。原文字符串、token 字符串、token 数、token ID 往往一起出现；如果把这些值混在一起读，模型输入怎样形成就会变模糊。

token 不是按人容易阅读的意义单位决定的，而是由特定模型 tokenizer 的词汇表(vocabulary)和切分规则决定的。因此，即使原文相同，只要模型或 tokenizer 不同，token 片段和 token 数也可能不同。

这里需要的最小区分如下。

这张表就是本节的标准。先分开读 原文怎样被切开、有几个片段、每个片段变成哪个编号，再看这些编号按什么顺序放进模型输入。

先放下的误解¶

token 可能根据情况显示成下面这些样子。

• 一个单词
• 单词的一部分
• 包含空格的短片段
• 数字和符号混在一起的片段
• 连着标点的片段

也就是说，token 不总是等于人直觉上感到的 单词。看起来像一个单词的东西，可能被切成多个 token；带有前置空格的片段这类人不太会当成单词的部分，也可能被包含在一个 token 边界中。

用下面的表来看，差异会更清楚。

这个差异常常在下面这些场景中显现。

重要的是，上表中的切分并不是说所有模型都会这样输出。实际切分会随 tokenizer 而不同。不过不管结果怎样，判读标准相同。先看原文，再看 token 字符串的边界，最后确认 token 数和 ID。

另一个误解，是把 token 读成 Part 1 中见过的 symbolic AI 的 symbol。symbolic AI 的 symbol 更接近人定下的意义或规则名称。相比之下，LLM 的 token 是 tokenizer 切开原文后得到的计算片段，模型会把这个片段变成 ID 和向量，放入概率计算。

因此，不能把 token 过度解释成逻辑符号。反过来，也不能把 token ID 只当成没有意义的内部数字跳过。现在需要的不是把 token 字符串读成释义，而是读出这个片段变成 vocabulary 的哪个编号，并放在模型输入的哪个位置。

在模型内部怎样使用¶

token 不会原样被计算。模型通常按下面的流程处理输入。

flowchart TD
  A["原文字符串"]
  B["token 字符串<br/>片段边界"]
  C["token 数<br/>片段个数"]
  D["token ID 序列<br/>vocabulary 编号"]
  E["embedding 向量<br/>计算输入"]
  F["模型计算"]

  A --> B
  B --> C
  B --> D
  D --> E
  E --> F

这条流程中重要的是两点。

• 模型不会直接计算原文字符串，而是先把它变成 token 字符串和 token ID 顺序列。
• token ID 随后会被查成向量表示，并进入实际计算。

也就是说，token 与其说本身就是完成的意义单位，不如说更接近模型计算开始的入口。

从工程角度看，这条流程很重要，因为人实际能检查的值也会沿着这条流程改变。

因此，知道 token 是什么，不是背一个术语定义，而是在之后看到 tokenizer 输出或日志时，能区分自己正在读什么。

读 token ID 时，还要再小心一点。ID 更接近 这个片段是 vocabulary 中第几项 的识别符(identifier)。4012 比 812 大，并不意味着它更重要或更复杂。模型计算中重要的不是 ID 数字大小本身，而是这个 ID 会查到哪个 embedding 向量，并怎样进入之后的上下文计算。

输出值区分案例与示例¶

案例 1. 人看到的单词和 token 不同时¶

假设客户支持文档里不断出现 退款政策 这个表达。人会把它读成意思明确的一个词组。因此，很容易以为模型也会把这个词组原样作为一个计算单位接收。

但是在模型输入中，标准不是 人是否觉得这是一个词。必须在 tokenizer 输出中确认：这个表达是否保留为一个片段，是否被分成多个片段，每个片段又附上了什么 ID。尤其在中文、韩文或混有词尾、助词、连写表达的句子中，人看到的词边界和 tokenizer 边界很容易错开。

这个案例要确认的结果是：token 不总是等于人感觉到的单词。即使看到同一个表达，也要把原文字符串、token 字符串、token 数、token ID 分开阅读。

案例 2. 一个句子变成 token 序列时¶

会议是明天 10:00 AM。 在人看来是一句日程通知。按人的标准，先看到的是一个句子、一个意思、一个时间信息。

但模型不会把整句直接放进计算。它会先把原文字符串变成 token 字符串的顺序，数这些片段，为每个片段附上 ID，然后准备计算。

刚开始只要分开下面四个层级，也能看出句子和计算输入的差异。

这个案例要确认的结果是：模型首先接收的不是 整句的意义，而是 可以编号的片段顺序。比精确 token 个数更重要的，是区分自己看到的是哪一层值。有了这个区分，阅读 token ID 的顺序 时，这些值就不会像突然冒出来的内部实现细节。

案例 3. token 不是直接被计算时¶

假设日志中同时打印了 token 字符串和 token ID。刚开始只看 token 字符串似乎就够了。因为片段看得见，所以容易感觉模型是在计算这些文字片段本身。

但是 token 字符串是人容易检查的显示值；输入进入模型计算时，每个片段需要对应的 token ID。这个 ID 又必须变成向量表示，才会进入实际计算。换句话说，token 字符串 是容易观察的标记，而 token ID 更接近模型在 vocabulary 中查找 embedding 的 key。

把同一流程最短地压缩，可以如下所示。

这个案例要确认的结果是：不能把 token 字符串和 token ID 看成同一个东西。token 字符串显示原文怎样被切开，token ID 显示这些片段在模型内部以什么编号处理。

把同一场景再压缩成比较表，可以这样看。

换层级提问的练习¶

即使还不能运行实际 tokenizer，也可以像下面这样练习把 人先说的话 改成 模型标准的确认问题。

这张表的重要点不是预先猜中准确值。首先需要的是区分：我现在看到的是单词释义、计算片段、片段个数，还是编号化输入。

这里常常混在一起的，正是这些层级。

• 看到原文字符串时，容易觉得模型计算已经开始。
• 看到 token 字符串时，容易把它当作单词释义。
• 看到 token ID 时，容易因为它太像内部值而无意义地跳过。
• 因为 token 看起来像标记，容易把它读成 symbolic AI 的 symbol 那一层。

要把模型输入读成 token ID 的顺序，必须先能区分这些层级。

把同一区分应用到实际日志或说明画面中，可以如下阅读。

这张表是在当前整合 Section 中再次停下来确认 片段、个数、编号、位置 区分的装置。读者通过这张表后，就能不把 token 看成孤立名称，而是分层阅读 tokenizer 输出和模型输入之间的关系。

tokenizer 输出值判读示例¶

比较 tokenization 类型之前，最好先确认 怎样阅读 token 本身。下面的例子简化展示实际 tokenizer 输出中常见的三个值。它不是为了背诵特定模型的准确结果，而是为了区分输出中应该读什么。

• token 字符串(token pieces)
• token 数(token count)
• token ID(token ids)

例如，假设某个工具按下面形式输出。下面的 token 片段和 ID 数字只是概念说明用的简化例子。实际模型 tokenizer 中，片段边界和 ID 可能不同。

这里读者应该马上读出的结果如下。

读这张表时，可以这样判断。

• token 字符串显示原文被切开的边界。
• token 数显示原文变成了几个计算片段。
• token ID 不是人读的意义，而是 vocabulary 查询结果。
• 同一原文也会因 tokenizer 不同而有不同的 token 字符串、token 数和 ID。

用同样方式读一个英文单词。

这里要确认的是，人的 一个英文单词 感觉，可能不同于模型的 两个计算片段 感觉。

反过来，很短的符号或标点也可能成为单独 token。例如句号 . 或冒号 : 对人来说像附加标记，但在 tokenizer 输出中可能作为独立片段出现。因此，看 token 数时，先看的不是 重要单词有几个，而是 tokenizer 实际制造了几个片段。

这个例子的目标不是背诵特定 tokenizer 的准确数字。首先需要的是清楚区分：在 tokenizer 输出中，我现在看到的不是单词释义，而是计算片段、个数、编号。

tokenizer 输出可以用下面三个问题收束。

这个例子要收束的判断，不是像背词典一样背 token 是什么。只要能区分 tokenizer 输出中的 片段、个数、编号 分别是什么，就足够。

token ID 顺序列怎样成为模型输入¶

前面把 token 分成 token 字符串、token 数、token ID 来读。现在要看这些值在模型输入中怎样使用。

核心不是一个 token 的释义，而是 token 的顺序列(sequence)。模型不是接收整句原文，而是接收 token ID 排成一列的输入，并在这个顺序上继续下一步计算。

比一个 token 更重要的是顺序列¶

token 不会只作为单个单位使用。在模型输入中，多个 token 会按顺序放置，这个顺序成为构成句子结构的材料。

如果没有 token 顺序，像 可以退款 和 不可以退款 这样包含相似片段的表达，也很难稳定区分。模型不仅要读每个 token 是什么，还要一起读它前后有什么 token。

这里的 顺序列 不只是把 token 排成一行。每个 token 在输入中都有自己的位置，这个位置会和前后 token 一起被解释。即使是同一个 token ID，只要前面是什么 token、后面接什么 token 不同，在下一步计算中承担的角色也可能不同。

写得很小，输入可以这样读。

这张表的重要点不是背 ID 数字。它是说，即使片段列表相同，也要一起看它们放在什么位置、前后接着什么片段，才能阅读模型输入。

token ID 是进入计算的编号列¶

前面看到的 token ID 不是简单标签。模型接收的是 token ID 的顺序，而不是字符串本身，并把这些 ID 变成向量表示来计算。

非常简单地写，流程如下。

这里重要的不是现在就详细解释 tokenization 规则，而是先抓住 模型不是直接读整句，而是把 token ID 顺序列作为输入接收 这个结构。

更细一点说，阅读模型输入时，要一起看三件事。

因此，模型输入既不是单纯的 ID 列表，也不是 单词释义列表。它是一起看 哪个 ID 以什么顺序和位置放置 的结构。

ID 顺序列案例与示例¶

案例 1. 相同片段的顺序改变时，输入也改变¶

假设在客户支持文档中自动分类 可以退款 和 不可以退款。人会立刻按意义区分这两个表达，但第一次看到 tokenizer 输出的读者，可能因为两者都含有 退款 和 可以，而觉得输入很相似。

这个标准的局限在于，它把 token 看成 包含的片段列表。在模型输入中，重要的不只是有哪些片段，还包括每个片段插在什么位置。如果 不 这样的否定片段放在 可以 前面，即使同样包含 退款 和 可以，输入顺序列也会不同。

这个案例要确认的结果是：不要把 token 当作集合收集起来看，而要读成 从前往后延续的编号列。数字只是说明用例。

因此，这个案例中更安全的判断不是停在 包含哪些 token，而是确认 这些 token 以什么顺序放置。

案例 2. 同一个 token 重复出现但位置不同时¶

会议是明天。请发送会议资料。 这个输入中，会议 出现了两次。人可能先看到同一个词重复，tokenizer 输出中也可能看到同一个 token 字符串或同一个 ID 出现两次。

但是，仅凭 同一个 ID 出现两次，不能说两个位置承担相同角色。第一个 会议 放在打开日程通知的位置，第二个 会议 放在 资料 和 发送 这个请求前面。即使是同一个 token，只要位置和周围 token 不同，在模型输入中读到的角色也可能不同。

这个案例要确认的结果是：模型输入不是 token 种类列表，而是 带有位置的 token 顺序列。

因此，这个案例中更安全的判断不是先看 是不是同一个 token，而是先看 同一个 token 位于输入的什么位置，并和哪些周围片段一起出现。

案例 3. 输出 token 接在输入 token 后面时¶

假设用户问 请用一句话说明不能退款的情况，模型开始生成回答。人通常先把回答句子看成完成后的产出物。因此，很容易感觉输出是按句子单位一次生成的。

这个标准的局限在于，它把输入和输出看成彼此断开的块。LLM 生成回答时，新的输出 token 会接在已经进入的输入 token 后面；刚刚接上的输出 token，也会在选择下一个输出时成为前文的一部分。现在要抓住的不是选择方式细节，而是输入和输出都会在同一个顺序列上继续。

这个案例要确认的结果是：token 不只是读取输入时使用的标记，也是输出继续下去的基本单位。

因此，这个案例中更安全的判断不是把 输入是输入，输出是结果 切开看，而是读成 输出 token 接在输入 token 后面，同一个顺序列变长。

把 token 读成顺序列¶

看到下面的场景时，先区分自己是在 逐个看 token，还是在 把 token 看成顺序列。

这里需要的应用水平，不是复杂的模型内部公式，而是把 token 读成 有顺序的输入单位，而不是 单个名称。

如果在实际日志或说明画面中看到同样判断，可以按下面顺序确认。

token ID 顺序列中要留下的标准¶

token 不是单纯的概念词，而是模型输入和输出延续下去的基本单位。现在要收束的问题不是运营判断，而是 token 在模型内部被用作 有顺序的输入。

理解这条流程后，把原文字符串变成这种 token 顺序列的程序，也就是 tokenization 为什么必要，也会自然连接起来。

练习与示例¶

这个练习的目标不是猜中 tokenization 规则。它是看着给定的 token 片段和 ID，把模型输入读成 带位置的顺序列，而不是 单个列表。每一题先自己选择答案，再和下面解说比较。

练习 1. 在相同片段列表中找顺序差异¶

下面两个输入都包含相同片段 退款、不、可以。

先自己回答。

• 可以把两个输入看成同一个输入吗？
• 如果不同，最先看到的是哪个位置差异？
• 这个差异能只靠 token 种类列表 说明吗？

解说：两个输入即使包含相同片段，也不是同一个输入。在 A 中，920 放在 7731 前面；在 B 中，920 放在最后。按本节标准，先看的是 哪个 ID 以什么顺序放置，而不是 包含了什么。

练习 2. 读取同一个 token 的位置¶

下面是同一个 token ID 5100 出现两次的简化输入。

先自己回答。

• 两个 会议 是同一个 ID，所以能说它们承担同一个角色吗？
• 要把两个位置读得不同，还必须看什么值？
• 如果把这个输入缩成 {会议} 这样的 token 种类列表，会消失什么？

解说：同一个 ID 重复出现，也不能断定它承担同一个角色。两个 token 位于不同位置，后面接着的片段也不同。缩成 token 种类列表后，位置和前后上下文会消失，因此阅读模型输入所需的核心信息会丢失。

练习 3. 追踪输出 token 接在哪里¶

下面是问题后面一个个接上输出 token 的简化过程。

先自己回答。

• 第二个输出 token 损坏 是和问题分离的新句子块吗？
• 第二个输出接上时，模型参考的前部顺序中有什么？
• 如果只把输出过程读成 出现一个完成句子，会漏掉什么？

解说：损坏 是接在前面问题和第一个输出 token 后面的新 token。第二个输出接上的时刻，不只有问题 token，已经生成的 产品 也成为前文的一部分。所以输出不是完成句子一次出现，而是现有顺序列按 token 单位变长的过程。

完成三个练习后，应该能用下面一句话整理。

模型输入不是 token 种类的集合，而是 token ID 以顺序和位置延续的编号列。

检查清单¶

• 能说明模型输入不是整句，而是 token ID 顺序列吗？
• 能在 tokenizer 输出中把 token 字符串、token 数、token ID 区分为不同值吗？
• 能说明比一个 token 名称更重要的是前后顺序和位置吗？
• 能说明输入 token 后面接上输出 token，回答因此被制造出来吗？

来源与参考资料¶

• OpenAI Help Center, What are tokens and how to count them?, 确认日期：2026-07-19。用于确认 API 请求文本会被分成 token，响应会作为 token 序列生成后再转换成文本。
• OpenAI, tiktoken README, 确认日期：2026-07-19。用于确认语言模型看到的不是人阅读文本的方式，而是 token 编号序列。
• Daniel Jurafsky, James H. Martin, Speech and Language Processing, 3rd ed. draft, online manuscript released January 6, 2026, 确认日期：2026-07-19。用于将 Words and Tokens, Large Language Models 章节作为 token 顺序列和语言模型输入说明的背景依据。