P6-2.1 限制输入和输出的 token 单位¶
Section ID:
P6-2.1Version:v2026.07.26
一旦开始实际使用 LLM(large language model)，马上就会出现另一个问题。为什么有些输入比预想更贵，为什么长文档会在中间被截断，为什么同样是一行句子，写法不同就会让长度感觉发生变化？
模型处理输入时，依据的不是字数或句子数，而是 token 数。
也就是说，token 首先不是作为 定义 进入的概念，而是作为解释长度限制、成本、截断、输入拆分问题所需的计算单位进入。
这时，重要的是不要立刻把 token 断定为 一个词 或 一个意思。token 不是人在词典里查找的单词，也不是一次性装下整句意义的标签。在这个阶段，把它先抓成 模型为了计算输入和输出而使用的计算片段 会更安全。它到底怎样被切分，会在后面的 P6-2.2 和 P6-2.3 中再说明。
为什么只看字数或句子数不够¶
人通常会像下面这样阅读输入。
- 句子短不短？
- 文件有几个？
- 段落有几段？
- 在画面上看起来有多长？
但是模型不会直接用这些单位来计算。因此，按人的标准看起来相似的输入，在模型那里可能会被读成完全不同的长度和不同的成本。
例如，可以这样比较。
| 人的标准问题 | 实际上需要重新问的问题 |
|---|---|
| 句子短不短？ | 实际输入 token 数是否小？ |
| 是一个文件吗？ | 整个输入是否放得进 token 限制？ |
| 段落看起来整齐吗？ | 需要的上下文是否留在同一个片段里？ |
这里的核心是，人先数的单位 和 模型实际计算的单位 可能不同。
因此，这一节的第一个判断，与其说是 这个 token 是什么意思，不如说是 模型把这个输入看成多长的计算片段。意义解释会在后面经过 embedding 和 Transformer 时再处理；这里先抓住一点：输入进入模型计算之前，就已经可能偏离人的长度感觉。
token 视角下先暴露的问题¶
需要 token 视角的问题，通常会先出现在下面这些场景中。
1. 输入长度限制¶
放入长文档时，人很容易想：只是一个文件，应该能一次读完。 但模型看的不是文件数量，而是整体输入在计算单位上的长度，因此后面的结论或例外条款可能会被截断。
2. 成本¶
看起来很短的句子，只要混入数字、符号、英文标记、URL，实际输入成本就可能更快变大。所以 只是短公告，应该便宜吧 这种直觉经常失准。
3. 上下文保留¶
切分 RAG 或搜索用 chunk 时，人会先看段落数，但实际更重要的是问题与条件、原则与例外是否留在同一个输入束里。这个问题最终也会连接到把什么看成计算单位。
把相同场景重新整理成实务判断，可以如下所示。
| 情况 | 人先数的东西 | 模型侧先看的东西 | 立刻改变的判断 |
|---|---|---|---|
| 简短的一行问题 | 句子数、字数 | 实际 token 数 | 预期成本和输入长度 |
| 一个长文档文件 | 文件数、页数 | 总 token 长度 | 是否可以整体输入 |
| 搜索用段落切分 | 段落数、看起来合适的长度 | 同一片段中的上下文保留 | chunk 设计和召回质量 |
非常简单地画出来¶
flowchart TD
A["同一个 token 问题"]
B["一个句子<br/>会被读成几个片段？"]
C["长文档<br/>完整 token 序列能放进去吗？"]
D["成本检查<br/>会按多少 token 计费？"]
A --> B
A --> C
A --> D
这张图需要确认的是，即使任务不同，先碰到的问题也很相似。短句、长文档、成本计算这些场景不同，但最后都必须重新看 模型实际把什么读成几个计算片段。
案例与示例¶
案例 1. 看起来很短的句子让成本感觉摇晃时¶
今天天气很好 和 会议是明天 10:00 AM。资料请参考 https://example.com/report 都可能看起来像简短的一行。因为人通常先按句子数或画面长度判断。
但是数字、时间标记、英文、URL、符号混在一起时，模型数到的输入片段可能会以不同于人对一行句子的感觉而增加。如果只按字数或句子数预测成本，就会出现 明明是短请求，为什么成本比想象中大 这种问题。
需要确认的结果不是 看起来短不短，而是 模型实际数成几个输入·输出单位。因此，要说明成本，就需要 token 这个共同计算单位。
| 输入场景 | 人的第一印象 | 从 token 视角重新看的东西 |
|---|---|---|
今天天气很好 | 简短的一行 | 作为基准的输入片段数 |
会议是明天 10:00 AM | 简短的日程通知 | 数字和英文标记怎样被计数 |
| 带 URL 的公告 | 仍然是一句话 | 符号和长字符串会把输入长度增加多少 |
案例 2. 明明是一个文件，却没有读到最后时¶
把 30 页会议记录整份放进去时，人很容易想：只是一个文件，应该能一次读完。 但模型遇到限制时，依据的是整个输入包含多少 token，而不是文件数量。
如果表、数字列表、附录、代码片段很多，输入长度可能比人感觉到的页数更快变大。超过限制后，后面的结论或例外条款可能被截断，或者一开始就必须把请求拆开。
需要确认的结果不是 文件有几个，而是 是否有足够的 token 预算把内容留到最后。因此，要说明输入限制，也需要 token 标准。
| 文档场景 | 人的第一判断 | 从 token 视角改变的判断 |
|---|---|---|
| 一个 30 页会议记录文件 | 一个文件，所以似乎能一次读完 | 整个输入是否放得进限制 |
| 表和附录很多的报告 | 页数看起来差不多 | 标记元素是否更快增加 token |
| 结论集中在最后的文档 | 已经放到最后，所以结论应该也读到了 | 后面的核心结论是否被截断 |
案例 3. 段落看起来整齐，但搜索答案摇晃时¶
切分 RAG 文档时，人容易觉得 两个段落就合适。但如果原则段落和例外段落被分到不同输入束中，搜索可能只拿回原则，错过重要例外。
在这个场景中，比段落形状是否自然更重要的是，问题所需的条件、原则、例外是否留在同一个输入单位里。绑得太长，限制和成本会变大；切得太短，必要上下文会散开。
需要确认的结果不是 段落漂亮吗，而是 必要上下文是否留在同一个 token 束里。因此，判断上下文保留时也需要 token 视角。
| 搜索场景 | 人的第一判断 | 从 token 视角改变的判断 |
|---|---|---|
| 两段规定文本 | 段落单位看起来整齐 | 原则和例外是否留在同一束里 |
| 很长的 FAQ 项目 | 是一个项目，所以想放在一起 | 是否不超过限制和成本 |
| 切得很短的 chunk | 搜索候选变多，看起来不错 | 回答所需条件是否散开 |
经过这三个案例后，如果又把 token 读成 意义单位，仍然会混乱。在成本问题中，即使意思相似，写法不同也会让长度感觉改变；在长文档问题中，即使在一个文件里也会碰到计算限制；在搜索问题中，看起来整齐的段落也可能无法保留回答所需条件。这里需要的 token 感觉，比起 承载意义的名称，更接近 进入计算的片段和长度。
把人的标准改成模型标准¶
即使还不能数出实际 token 数，也可以像下面这样练习把 人的标准单位 改成 模型标准单位。
| 现在看到的输入 | 人的标准下容易先说的话 | 从 token 视角先改问的话 |
|---|---|---|
| 混有数字和 URL 的一行公告 | 很短，所以成本也小 | 实际输入·输出 token 数是多少？ |
| 一个会议记录文件 | 一个文件，所以会被整体读完 | 整个输入是否放得进 context window？ |
| 两段规定文本 | 段落形状自然，搜索也应该没问题 | 原则和例外是否留在同一个 token 束里？ |
这张表的重要点不是猜对数字，而是改变 应该先数什么。
用更短的方式练习同一个标准，可以这样读。
| 现在出现的问题 | 先想到的 token 视角 |
|---|---|
| 回答比预想更贵 | 先看实际 token 数，而不是表面长度 |
| 长文档尾部消失 | 先看总 token 长度，而不是文件数 |
| 搜索答案漏掉例外 | 先看同一 token 束中的上下文保留，而不是段落形状 |
在这个阶段，只要能马上说出这三行就足够。即使还不能数出精确 token 数，至少已经开始区分：成本问题、截断问题、上下文保留问题 都无法只靠人的长度感觉来解释。
三个案例再压缩，可以这样看。
| 一开始容易抓住的标准 | 为什么不够 | 因此需要的标准 |
|---|---|---|
| 一行、字数 | 数字、符号、URL 混入时，实际计算长度和成本可能改变 | 输入·输出 token 数 |
| 文件数、页数 | 限制卡住的是模型能接收的长度，不是文件数量 | 总 token 长度和 context window |
| 段落形状 | 必要条件被分到不同束时，答案会摇晃 | 同一 token 束中的上下文保留 |
| 单词数、意义个数 | token 不总是等于一个词或一个意义 | 模型实际数到的计算片段 |
这张表的目的不是让读者背诵精确 token 数。它是为了抓住：为什么处理 LLM 时，很难直接使用 人先看到的单位，为什么需要单独的模型标准计算单位。
把三个案例重新合起来，标准会聚到一个点。像一行、文件数、页数、段落形状、单词数这样人先抓住的单位，并不足以稳定说明输入成本、context window、搜索 chunk、输出长度。因此，处理 LLM 时，必须先问的不是 在人眼中看起来有多长，而是 模型实际读写了几个计算片段。
所以 token 登场¶
在这个位置需要的就是 token。token 是模型处理输入和输出时数到的计算单位。
前面三个案例其实都在说同一件事。
- 要预测成本，必须看实际输入·输出 token 数，而不是表面长度。
- 要处理长文档，必须看总 token 长度和 context window，而不是文件数量。
- 要拆分搜索用输入，必须看必要上下文是否留在同一个 token 束里，而不是段落形状。
也就是说，token 不是为了再学一个新术语而登场的。它之所以出现，是因为只靠人先看到的句子、单词、字数感觉，很难稳定说明 LLM 的输入和输出，所以需要模型标准的计算单位。
token 本身到底是什么，和单词有什么不同，在模型内部怎样计算，会在 P6-2.2 中继续。这里看到 回答比预想更贵、长文档尾部消失、搜索答案漏掉例外 这些场景时，先放下人的长度感觉即可。接下来要问的问题只有一个：这个输入和输出按模型数到的计算片段来看有多长，哪里还留在同一个上下文里？
练习与示例¶
阅读下面三个输入场景，并分别选择一个要先确认的 token 视角。刚开始时，可以遮住右侧 示例答案 后自己先选。
| 输入场景 | 先判断的问题 | 示例答案 |
|---|---|---|
| 一行公告里有很多时间、价格、URL | 选择这是成本问题、截断问题，还是上下文保留问题 | 成本问题：看起来短，实际输入·输出 token 数也可能增加。 |
| 放入长会议记录后，回答没有提到后面的结论 | 选择这是成本问题、截断问题，还是上下文保留问题 | 截断问题：即使是一个文件，整体 token 长度也可能超过限制。 |
| 规定搜索中原则是对的，但漏掉例外 | 选择这是成本问题、截断问题，还是上下文保留问题 | 上下文保留问题：原则和例外可能被分到不同 token 束。 |
| 把同义句改得更短，却不确定成本感觉是否会相同 | 判断是否可以把单词数和 token 数看成同一件事 | 只看单词数不够。实际 token 数必须按 tokenizer 制造的计算片段重新看。 |
这个练习的目标不是数出精确 token 数。它是为了养成习惯：看到同一个输入时，先想到 模型数到的计算单位中会出现什么问题，而不是先问 在人眼中短不短、文件有几个、段落是否好看。
检查清单¶
- 能说明为什么只看字数或句子数难以解释 LLM 输入问题吗？
- 是否理解长度限制、成本、上下文保留问题都需要不同的计算单位？
- 能否不把 token 断定为一个词或一个意义，而先说明为模型数到的计算片段？
- 能否说明 token 首先是作为
解决问题的计算单位登场？
来源与参考资料¶
- OpenAI Help Center, What are tokens and how to count them?, 确认日期：2026-07-19。用于确认 token 是模型处理的文本片段，输入·输出 token 数会连接到使用量和限制判断。
- OpenAI, tiktoken README, 确认日期：2026-07-19。用于确认 OpenAI 模型用 BPE tokenizer，以及把文本转换成 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章节作为 token 与 word 边界说明的一般 NLP 背景依据。