Token 到底是什么？为什么 AI 应用离不开 Token？

Token 到底是什么？为什么 AI 应用离不开 Token？

上一篇我们介绍了大语言模型的基本概念：

《LLM 到底是什么？从 GPT 到 Agent：一文看懂大语言模型的过去、现在与未来》

我们知道，LLM 可以理解问题、生成文本、编写代码、分析文档、调用工具，甚至执行复杂任务。

但模型究竟是如何处理我们输入的文字的？

例如，我们输入：

请解释一下 Java 中 HashMap 的工作原理。

人类看到的是一句完整的话，但模型并不是直接以"句子"为单位处理它。模型首先需要通过 Tokenizer，将文本编码为一系列 Token，再将这些 Token 转换为数字表示，交给神经网络计算。

整个过程可以概括为：

文本
 ↓
Tokenizer
 ↓
Token ID
 ↓
Embedding
 ↓
Transformer
 ↓
预测下一个 Token
 ↓
解码为文本

因此，Token 是理解 LLM、Context、Prompt、RAG、Tool Calling 和 Agent 的基础概念。

不过，本文需要先澄清一个容易被误解的地方：

Token 不是固定的字数单位，也不是模型内部唯一的"语义单位"。它首先是特定 Tokenizer 对输入字符串进行编码后得到的离散符号。

模型真正进行神经网络计算的，是 Token ID 对应的向量，以及这些向量在上下文中的关系。

---

一、Token 是什么？

Token 可以理解为：

特定模型的 Tokenizer 将输入文本编码后得到的离散文本片段或控制符号。

它不是固定意义上的"字"或"词"，而是由具体模型的 Tokenizer、词表和编码规则共同决定的。

一个 Token 可能是：

一个汉字
一个词
一个词的一部分
一个标点符号
一个数字片段
一段代码片段
一个空格与后续文本的组合
一个特殊控制符号

例如：

Hello world

某些 Tokenizer 可能将其切分为：

Hello
 world

这里第二个 Token 可能包含前面的空格。空格是否属于 Token 的一部分，以及具体如何切分，取决于模型使用的 Tokenizer。

再比如：

unbelievable

可能被切分为：

un
believable

也可能被切分成更多片段。

中文同样没有固定规则。例如：

人工智能正在改变软件开发。

某个 Tokenizer 可能将其切分为：

人工
智能
正在
改变
软件
开发
。

也可能采用更细或更粗的切分方式。

因此，最重要的结论是：

Token 不是通用的字数单位，而是特定模型 Tokenizer 产生的编码单位。

---

二、Token、Token ID 和向量分别是什么？

理解这三个概念，可以把"文字如何进入模型"讲清楚。

1. Tokenizer：把文本编码成 Token ID

Tokenizer 是模型配套的文本编码器，负责将字符串转换为 Token ID 序列。

从概念上看：

输入字符串
 ↓
Tokenizer
 ↓
Token 序列
 ↓
Token ID 序列

例如：

Java 是一门编程语言

经过某个 Tokenizer 后，可能得到类似的 Token：

Java
是
一
门
编程
语言

但这只是示意。实际结果必须以具体模型的 Tokenizer 为准。

在工程实现中，Tokenizer 通常会直接输出 Token ID：

文本
 ↓
Tokenizer
 ↓
[15234, 87231, 19384]

Token 主要是便于人类理解的中间表示，模型实际接收的是 Token ID。

2. Token ID：词表中的整数编号

每个 Token 都会对应词表中的一个整数编号。

例如：

Token        Token ID

Java         15234
编程         87231
语言         19384

这些数字只是示意，不代表某个真实模型的词表。

可以把词表理解为：

Token ↔ Token ID

模型通过 Token ID 找到对应的参数和向量。

3. Embedding：把 Token ID 映射为向量

Token ID 会作为索引，查找模型的输入嵌入矩阵，得到对应的向量：

Token ID
 ↓
Embedding Lookup
 ↓
[0.13, -0.27, 0.84, ...]

如果词表大小为 V，模型隐藏维度为 d，那么输入嵌入矩阵通常可以表示为：

E ∈ R^(V × d)

某个 Token ID i 对应的初始向量，就是矩阵 E 的第 i 行：

x_i = E[i]

之后，模型还会加入位置信息，例如 RoPE 等位置编码机制，使模型能够区分：

A B

和：

B A

这两个序列中 Token 的顺序差异。

因此，模型处理文本的大致流程是：

文本
 ↓
Tokenizer
 ↓
Token ID
 ↓
Embedding
 ↓
位置编码
 ↓
Transformer

---

三、Tokenizer 是如何切分文本的？

现代大模型通常不会简单地按照"一个字一个 Token"或"一个词一个 Token"进行切分，而是会根据训练语料构建词表，并使用某种子词或字节级编码方法。

常见方法包括：

BPE
Byte-level BPE
WordPiece
Unigram
SentencePiece 体系中的相关算法

不同模型可能采用不同算法、词表和特殊 Token 设计，因此不能假设所有模型使用同一种 Tokenizer。

BPE 的基本思想

BPE，即 Byte Pair Encoding，是一种常见的子词编码方法。

它的基本思路是：

从较小的符号片段开始，根据语料中的统计频率，逐步合并经常一起出现的相邻片段。

例如，假设训练语料中经常出现：

l o w

经过统计后，可能先合并为：

l + o → lo

再进一步合并为：

lo + w → low

于是，low 可能成为词表中的一个 Token。

对于常见词，Tokenizer 可能保留较完整的片段：

computer

对于较长或较少见的词，则可能拆分为多个子词：

computerization

可能被拆分为：

computer
ization

也可能得到其他切分结果。

这种设计有两个主要好处：

1. 常见文本可以用较少的 Token 表示；
2. 新词、专有名词和代码仍然可以通过已有片段组合表示。

字节级 Tokenizer 为什么能处理生僻字符？

许多现代 Tokenizer 会在字符或 Unicode 文本之上引入字节级表示，或者使用能够覆盖任意输入的回退机制。

这样，即使输入中出现：

罕见汉字
特殊符号
Emoji
混合语言
未登录词

Tokenizer 也通常能够将其编码，而不必完全依赖词表中存在一个完整词条。

这也是子词或字节级方法比固定词表分词更具开放性的原因。

---

四、词表和特殊 Token 是什么？

Tokenizer 依赖一套词表，也就是 Vocabulary。

词表可以理解为：

Token ID → Token

例如，概念上可能包含：

Token ID     Token

0            <pad>
1            <bos>
2            <eos>
3            the
4            and
5            Java
6            编程
7            语言
...

实际词表由具体模型决定。

需要注意的是，词表中的内容不一定都是普通文本片段，还可能包括：

序列开始标记
序列结束标记
填充标记
未知或回退标记
对话角色标记
工具调用标记
思考或控制相关标记

不同模型对这些特殊 Token 的命名和使用方式可能不同。

---

五、模型如何通过 Token 生成文本？

LLM 的文本生成通常不是一次性生成完整句子，而是根据已有上下文，逐步预测下一个 Token。

假设输入经过 Tokenizer 后得到：

[t1, t2, t3, t4]

模型会计算下一个 Token 的概率分布：

P(t5 | t1, t2, t3, t4)

选择或采样出一个 Token 后，序列变成：

[t1, t2, t3, t4, t5]

然后继续计算：

P(t6 | t1, t2, t3, t4, t5)

这个过程不断重复，直到：

生成结束 Token
达到最大输出长度
触发停止条件

例如，输入：

请解释 HashMap 的

模型可能预测下一个 Token 为：

工作

于是上下文变成：

请解释 HashMap 的工作

然后继续预测：

原理

最终生成：

请解释 HashMap 的工作原理。

从模型角度看，生成过程更接近：

已有 Token
 ↓
计算下一个 Token 的概率分布
 ↓
选择或采样下一个 Token
 ↓
追加到序列
 ↓
继续预测

这里的"选择"并不一定是每次都选择概率最高的 Token。实际生成还可能受到：

temperature
top_p
top_k
重复惩罚
停止条件
结构化输出约束

等机制影响。

因此：

LLM 所谓的"生成文字"，本质上是自回归地预测和生成 Token。

---

六、模型为什么能够根据 Token 生成有意义的内容？

仅仅把文本切成 Token，并不会自动产生理解能力。

Token 只是输入表示。模型能力来自训练过程中学习到的参数。

在训练阶段，模型通常会看到大量 Token 序列，并学习预测序列中的下一个 Token。以自回归语言模型为例，训练目标可以写成：

最大化：

P(x1, x2, ..., xn)

根据链式法则：

P(x1, x2, ..., xn)
=
∏ P(x_t | x_<t)

训练时，模型会根据前面的 Token 预测下一个 Token，并通过交叉熵损失更新参数。

简化表示为：

Token 序列
 ↓
Embedding
 ↓
Transformer
 ↓
Logits
 ↓
Softmax
 ↓
下一个 Token 的概率分布

模型并不是在词表中查找"正确答案"，而是根据当前上下文计算整个词表上的概率分布。

如果词表大小为 V，模型最后会输出一个长度为 V 的 logits 向量：

z ∈ R^V

经过 Softmax 后得到概率：

P(token_i) = exp(z_i) / Σ exp(z_j)

推理阶段再根据解码策略选择下一个 Token。

因此，Token 是模型的离散输入输出接口，而"理解"和"生成能力"来自 Transformer 参数对大量模式的学习。

---

七、Token 与 Context Window 的关系

Token 不只是模型内部的技术细节，它还直接影响 AI 应用的上下文容量。

1. Context Window 是什么？

Context Window 表示模型一次请求能够处理的上下文容量，通常以 Token 计算。

例如：

Context Window = 128K Tokens

通常表示该模型在特定 API 或部署配置下，一次请求允许处理大约 128K 个 Token。

但需要注意：

上下文上限是模型和平台共同定义的接口约束，具体还可能受到输入上限、输出上限、模型版本和 API 配置影响。

一次请求中的以下内容都可能占用上下文：

系统提示词
开发者指令
历史对话
用户输入
工具定义
工具返回结果
RAG 检索内容
模型已经生成的内容

因此，用户看到的输入文本并不等于模型实际处理的全部 Token。

2. 输入 Token 和输出 Token 如何计算？

在一次聊天请求中，可以粗略理解为：

输入 Token
=
系统消息
+
开发者消息
+
历史消息
+
用户消息
+
工具定义
+
其他模板和控制信息

输出 Token 则是模型本次生成的 Token 数量。

在某些 API 中，输出 Token 也会占用上下文窗口，因此可近似表示为：

输入 Token
+
输出 Token
≤
可用上下文上限

但具体规则必须以平台文档为准。

---

八、Token 与 API 成本的关系

大多数大模型 API 会根据 Token 计算费用，通常包括：

Input Tokens
Output Tokens

部分平台还会区分：

Cached Input Tokens

也就是缓存命中的输入 Token。

一般来说：

输入 Token 越多
+
输出 Token 越多
 ↓
计算量和调用成本通常越高

但不能简单地认为：

Token 数量 × 一个固定价格

因为实际价格可能受到以下因素影响：

模型版本
输入与输出的不同单价
缓存命中
批处理
区域
服务套餐
推理模式
多模态输入

因此，准确成本应根据具体平台的价格表和 API 返回的 usage 数据计算。

一个通用的成本估算公式可以写成：

总成本
=
输入 Token 数量 × 输入单价
+
输出 Token 数量 × 输出单价
+
缓存 Token 数量 × 缓存单价
+
其他计费项

如果平台对缓存 Token 单独计费，则应使用平台规定的缓存单价。

---

九、Token 与响应速度的关系

Token 数量也会影响延迟，但影响方式需要区分。

1. 输入 Token 影响首 Token 延迟

模型需要先处理输入上下文，才能生成第一个输出 Token。因此，输入越长，通常越可能增加：

Time To First Token，TTFT

也就是从请求发出到第一个输出 Token 到达的时间。

2. 输出 Token 影响生成时长

模型生成输出时，通常需要逐步产生 Token。输出 Token 越多，生成阶段持续时间通常越长。

因此：

输入 Token
 ↓
主要影响首 Token 延迟和预填充计算

输出 Token
 ↓
主要影响持续生成时间

在 Agent 场景中，一次任务可能多次调用模型和工具。如果每一轮都重复携带大量历史内容，Token 数量、延迟和成本都会快速增长。

---

十、不同模型的 Tokenizer 并不通用

这是实际开发中非常重要的一点。

GPT、Claude、Gemini、DeepSeek 和 Qwen 都有各自的模型体系和 Tokenizer。即使输入完全相同的文本，不同模型也可能得到不同的 Token 序列和 Token 数量。

可以简单理解为：

OpenAI 模型
 ↓
对应的 Tokenizer

Claude
 ↓
对应的 Tokenizer

Gemini
 ↓
对应的 Tokenizer

DeepSeek
 ↓
对应的 Tokenizer

Qwen
 ↓
对应的 Tokenizer

因此：

不能使用一个模型的 Tokenizer，去精确估算另一个模型的 Token 数量。

还需要注意一个更细的区别：

同一模型家族的不同版本，也可能使用不同的 Tokenizer、词表或 Chat Template。

所以，不能只根据模型品牌判断 Token 规则。

OpenAI

OpenAI 不同模型使用与模型匹配的 Tokenizer。开发者可以使用官方提供的 Token 统计工具或相应 SDK 进行估算。

tiktoken 常用于部分 OpenAI 模型的 Token 计算，但它不是所有模型通用的 Tokenizer。使用时必须确认编码方式与目标模型匹配。

Claude

Claude 使用 Anthropic 自己的 Tokenizer。不同 Claude 模型或 Tokenizer 版本可能导致相同文本产生不同数量的 Token。

使用 Claude 时，应优先使用 Anthropic 提供的 Token 计数能力，并以实际 API 返回的 usage 为最终依据。

Gemini

Gemini 使用 Google 自己的 Token 机制，并提供 Count Tokens 接口，用于在发送请求前估算输入内容的 Token 数量。

Gemini 的 Token 统计还涉及：

文本
图片
音频
视频
PDF

多模态输入的计量方式不能简单套用文本字符换算。

DeepSeek

DeepSeek 使用自己的 Tokenizer。官方文档提供了大致的字符换算方式，但这只能用于粗略估算。

实际 Token 数量应以具体模型的 Tokenizer 结果或 API 返回的 usage 数据为准。

Qwen

Qwen 使用自己的 Tokenizer，并包含用于对话格式和生成控制的特殊 Token。

使用 Qwen 时，应加载与具体模型匹配的 Tokenizer 和 Chat Template，不能只使用一个通用的文本分词器。

因此，实际开发时应遵循以下原则：

选择具体模型
 ↓
使用该模型对应的 Tokenizer 或 Count Tokens 接口
 ↓
发送请求
 ↓
以 API 返回的 usage 为最终依据

---

十一、特殊 Token 与 Chat Template

除了普通文本片段，模型还会使用一些特殊 Token 来表示序列边界、对话角色或生成控制信息。

常见类型包括：

BOS：序列开始
EOS：序列结束
PAD：填充
对话角色标记
工具调用标记
其他控制 Token

1. BOS、EOS 和 PAD

BOS

Beginning Of Sequence，表示序列开始。

EOS

End Of Sequence，表示序列结束。模型生成到 EOS 后，通常会停止继续生成。

PAD

Padding Token，用于将不同长度的序列补齐到相同长度，常见于批量训练或批量推理。

并不是所有模型都会以完全相同的方式使用这些 Token。有些模型可能没有独立的 PAD Token，或者将某个已有 Token 复用于填充。

2. Chat Template

聊天模型通常不会简单地把消息拼接成：

user:
你好

assistant:
你好

而是会使用特定的 Chat Template，将系统消息、用户消息和助手消息转换为模型训练时使用的格式。

例如：

<system>
...
</system>

<user>
...
</user>

<assistant>
...
</assistant>

实际模板可能使用特殊 Token，而不是普通的 XML 标签。

这些格式标记也会被 Tokenizer 编码，并可能占用上下文长度。

因此：

你看到的 Prompt 文本，不一定等于模型最终处理的完整输入。

在本地部署模型时，Chat Template 尤其重要。即使使用相同的基础模型，如果对话格式不符合训练时的模板，也可能影响模型表现。

---

十二、同一段文本为什么在不同模型中产生不同 Token 数量？

假设我们要调用三个不同模型，并发送下面的内容：

请分析下面这段 Java 代码，并指出可能的并发问题：

public class Counter {
    private int count = 0;

    public void increment() {
        count++;
    }
}

人类看到的是同一段文本。

但不同模型可能因为以下原因产生不同 Token 数量：

词表不同
空格处理方式不同
中文切分方式不同
代码符号切分方式不同
换行处理方式不同
特殊 Token 规则不同
Chat Template 不同

因此，不能简单地说：

这段文本有 100 个 Token

更准确的做法是：

模型 A
 ↓
使用模型 A 的 Tokenizer
 ↓
得到 Token 数量 A

模型 B
 ↓
使用模型 B 的 Tokenizer
 ↓
得到 Token 数量 B

如果是聊天 API，还要把完整消息结构和 Chat Template 考虑进去。

生产环境最终应记录 API 返回的：

input_tokens
output_tokens
total_tokens

---

十三、为什么用户只输入一句话，却消耗了很多 Token？

假设用户只输入：

帮我分析这个订单为什么没有发货。

表面上，这句话很短。

但实际请求可能包含：

系统提示词：2,000 Token
工具定义：3,000 Token
历史对话：8,000 Token
RAG 检索结果：6,000 Token
用户问题：20 Token

那么本次请求的输入 Token 可能接近：

2,000
+
3,000
+
8,000
+
6,000
+
20
=
19,020 Token

用户输入只占很小一部分。

如果 Agent 后续又调用了两个工具，并将每次工具返回结果继续放入上下文：

第一次工具结果：4,000 Token
第二次工具结果：5,000 Token

后续模型调用的输入可能进一步增长。

这说明：

Token 消耗的主要来源，往往不是用户问题，而是系统提示词、历史记录、工具定义和检索结果。

---

十四、Token 在 RAG 中的作用

假设知识库中有：

100 万 Token 的企业文档

不可能每次都把全部文档发送给模型。

RAG 通常会先检索与问题相关的内容，再将有限片段放入上下文：

用户问题
 ↓
查询理解或向量化
 ↓
检索候选文档
 ↓
过滤与重排序
 ↓
选择必要片段
 ↓
放入 Context
 ↓
LLM 生成回答

例如：

知识库：

1,000,000 Token

        ↓

检索与重排序

        ↓

相关内容：

8,000 Token

        ↓

LLM

这样可以减少：

输入成本
上下文压力
无关信息干扰
响应延迟

但 RAG 不是"检索越少越好"。

如果相关信息被截断，模型可能无法完成任务。因此，真正的目标是：

在保证任务所需信息完整的前提下，减少无关内容。

RAG 中的 Chunk 与 Token

文档切分时，通常会设置 Chunk 大小和重叠范围。

例如：

每个 Chunk：500 Token
重叠：50 Token

但这里的 Token 必须使用与后续 Embedding 模型或生成模型相匹配的 Tokenizer 进行估算。

需要注意：

Embedding 模型的 Tokenizer 和生成模型的 Tokenizer 也可能不同。

因此，文档切分既要考虑检索效果，也要考虑最终生成模型的上下文预算。

---

十五、Token 在 Tool Calling 中的作用

模型调用工具时，需要看到工具名称、描述、参数结构和使用规则。

例如：

{
  "name": "get_weather",
  "description": "查询指定城市的天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "城市名称"
      }
    },
    "required": ["city"]
  }
}

工具定义本身可能占用输入 Token，工具返回结果也会进入后续上下文。

因此：

工具数量增加
+
工具描述变长
+
工具返回结果变多
 ↓
上下文和 Token 消耗增加

一个实际案例

假设 Agent 注册了 100 个工具，每个工具定义平均占用 150 Token：

100 × 150 = 15,000 Token

即使用户问题只有几十个 Token，模型每次调用也可能先承担约 15,000 Token 的工具描述成本。

如果当前任务实际上只需要 5 个工具，那么动态加载相关工具：

5 × 150 = 750 Token

就可能显著减少输入上下文。

这也是为什么生产级 Agent 通常需要：

工具分组
工具检索
按任务动态加载
简化工具描述
限制工具返回结果

---

十六、Token 在 Agent 中的作用

Agent 通常需要多轮调用模型和工具：

用户任务
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM

如果每一轮都携带：

完整历史
全部工具定义
冗长工具结果
重复系统提示词

Token 会快速增长。

假设每一轮都把之前的全部内容重新发送：

第 1 轮：5K Token
第 2 轮：10K Token
第 3 轮：15K Token
第 4 轮：20K Token

四轮累计输入量并不是 20K，而是：

5K + 10K + 15K + 20K = 50K Token

这就是 Agent 中常见的上下文累积问题。

生产环境通常需要设置：

最大执行步骤
最大输出 Token
最大总 Token
超时时间
重试次数

同时，还应对历史和工具结果进行：

摘要
裁剪
结构化保存
去重
按需加载

---

十七、如何准确统计 Token？

1. 区分预估值与实际值

在发送请求前，可以使用对应模型的 Tokenizer 或 Count Tokens 接口进行预估。

但预估值不一定等于最终计费值，因为实际请求可能还包含：

Chat Template
系统字段
工具定义
平台包装字段
缓存状态
多模态处理结果

因此：

预估用于预算和校验，API 返回的 usage 用于最终统计。

2. 记录实际 usage

生产环境不要只统计用户输入，而应记录完整的调用数据：

input_tokens
output_tokens
cached_input_tokens
total_tokens

不同平台的字段名称可能不同，应以具体 API 文档为准。

例如：

{
  "input_tokens": 8200,
  "output_tokens": 1300,
  "total_tokens": 9500
}

如果平台提供更细的统计，还可以记录：

缓存命中的输入 Token
推理或思考 Token
多模态 Token
工具调用相关 Token

但这些字段并非所有平台都提供，不能假设跨平台一致。

---

十八、如何优化 Token？

Token 优化的核心不是"把内容删得越多越好"，而是减少无关信息，同时保留完成任务所需的上下文。

1. 减少重复上下文

如果系统提示词、工具定义或其他内容在多次请求中保持不变，可以考虑使用平台提供的 Prompt Caching 或缓存机制。

但需要注意：

缓存是否生效、缓存粒度如何定义、缓存如何计费，都取决于具体平台。

缓存通常不会改变模型需要理解的内容，但可能降低重复输入的成本和处理开销。

2. 管理对话历史

不要无限保留完整聊天记录。可以根据任务需要组合使用：

最近几轮对话
+
历史摘要
+
必要的长期记忆

摘要不能只追求压缩，还要保留完成任务所需的：

事实
约束
用户偏好
已做决策
未完成事项

3. 控制 RAG 内容

RAG 应该经过：

检索
过滤
重排序
去重
截断

避免把大量低相关内容直接放入上下文。

具体保留多少内容，不能固定为某个数字，而应根据：

任务类型
文档质量
检索准确率
模型能力
上下文预算

进行评估。

4. 控制输出格式

如果任务只需要结构化结果，就不必要求模型生成冗长解释。

例如：

{
  "passed": true,
  "reason": "符合要求"
}

结构化输出有助于程序解析，也能减少不必要的输出 Token。

5. 精确提供代码上下文

在 AI Coding 场景中，不要默认把整个代码仓库发送给模型。更合理的流程是：

用户问题
 ↓
定位相关文件
 ↓
定位相关类和方法
 ↓
读取必要上下文
 ↓
发送给模型

例如：

整个项目：

500K Token

        ↓

相关模块：

20K Token

        ↓

相关类：

5K Token

        ↓

相关方法：

2K Token

但也不能机械地只发送一个方法。代码任务通常还需要：

调用方
被调用方
类型定义
配置文件
测试代码
错误日志
相关接口

因此，代码上下文选择的目标不是"越少越好"，而是：

提供足以支持正确判断的最小完整上下文。

6. 限制 Agent 的循环

Agent 必须设置：

max_steps
max_output_tokens
max_total_tokens
timeout
retry_limit

同时，对工具调用设置：

返回结果大小限制
分页
字段筛选
错误重试上限

否则一个冗长的工具结果可能在多轮调用中被反复携带。

---

十九、Token 的几个常见误区

误区一：一个汉字一定等于一个 Token

错误。

中文字符可能被单独编码，也可能与其他字符组合，具体取决于 Tokenizer。

误区二：一个英文单词一定等于一个 Token

错误。

常见短词可能接近一个 Token，但长词、少见词、带空格的词和代码标识符可能被拆成多个 Token。

误区三：Token 数量在所有模型中都一样

错误。

不同模型的词表、编码算法和特殊 Token 规则可能不同。

误区四：Token 就是模型理解的最小语义单位

不准确。

Token 是输入编码单位。模型的语义表示是在多层 Transformer 计算中形成的，不等于某个 Token 本身就具有完整、稳定的语义。

误区五：Context Window 只包含用户输入

错误。

系统消息、历史对话、工具定义、RAG 内容和模型输出都可能占用上下文。

误区六：Token 越少，效果一定越好

错误。

如果删除了任务所需的信息，Token 虽然减少，回答质量也可能下降。

正确目标是：

减少无关信息，而不是盲目减少所有信息。

---

二十、Token 的核心认识

Token 可以从三个层面理解。

第一，Token 是模型的输入输出编码单位

文本需要先被 Tokenizer 编码为 Token ID，模型再基于这些 ID 对应的向量进行计算和生成。

第二，Token 是上下文和成本的计量单位

Context Window、输入费用、输出费用和很多性能指标，都与 Token 数量有关。

第三，Token 是 AI 应用的工程约束

RAG 返回多少内容、Agent 保留多少历史、工具暴露多少描述、代码读取多少上下文，最终都会受到 Token 预算影响。

因此，Token 优化的目标不是单纯追求数量最少，而是：

用尽可能少的无关信息，为模型提供完成任务所需的完整上下文。

可以概括为：

低冗余
+
高相关性
+
足够的信息完整性
+
合理的输出长度

---

二十一、总结

把整篇文章压缩成一条链路：

文本
 ↓
Tokenizer
 ↓
Token ID
 ↓
Embedding
 ↓
位置编码
 ↓
Transformer
 ↓
Logits
 ↓
采样或选择下一个 Token
 ↓
解码
 ↓
文本

需要记住的重点有：

1. Token 不是固定意义上的字，也不是固定意义上的词。
2. Token 是具体模型 Tokenizer 产生的文本片段或控制符号。
3. Tokenizer 通常将文本编码为 Token ID，Token ID 再映射为向量参与模型计算。
4. LLM 的生成过程，本质上是根据上下文逐步预测下一个 Token。
5. Context Window 通常以 Token 计算，并可能包含输入、输出、工具定义和其他上下文内容。
6. API 成本和响应速度通常会受到输入、输出 Token 数量影响。
7. 不同模型的 Tokenizer 不通用，精确统计应使用对应平台的工具或 API。
8. RAG、Tool Calling 和 Agent 都需要进行 Token 和上下文管理。
9. 生产环境应区分预估 Token 和实际 usage，并以 API 返回的 usage 作为最终统计依据。
10. Token 优化不是简单删除信息，而是减少无关内容、提高信息密度，同时保留任务所需的完整上下文。

如果上一篇文章回答的是：

LLM 是什么？

那么这一篇回答的是：

LLM 用什么单位读取和生成信息？

更准确的答案是：

Token 是模型对文本进行编码和生成时使用的离散单位

理解 Token 之后，才能进一步理解：

Context Window
RAG
Memory
Tool Calling
Agent
Context Engineering