谈论大模型时，Token 几乎无处不在：上下文窗口用 Token 计量，API 按 Token 计费，模型的生成速度也常写成 tokens/s。但 Token 不是“一个字”，也不等于“一个单词”。
Token 是模型读取和生成文本时使用的基本符号单位。 一段文字会先经过分词器，被转换为一串 Token ID，模型真正处理的是这些数字，而不是人眼看到的句子。
从文字到 Token
大模型不能直接理解字符串。输入通常经历三步：
- 文本规范化，例如处理空格或特殊字符；
- 分词器把文本切成 Token；
- 每个 Token 映射为词表中的整数 ID。
例如一句简单英文：
The model is tokenizing text.
它可能被切成完整单词、词根、后缀和标点。不同模型的词表与分词算法不同，因此同一句话在不同模型中可能得到不同数量的 Token。
ℹ️ Token 不是自然语言单位
Token 的边界由分词器和词表决定，不遵循语文课里的“字、词、句”边界。空格、换行、标点、emoji 和代码缩进都可能占用 Token。
为什么不直接按字或单词处理
如果把每个完整单词都放进词表，词表会非常庞大，而且无法优雅处理新词、拼写变化、网址和代码。如果只按单个字符处理，序列又会太长，计算成本上升。
现代分词器通常采用子词方案，在词表规模与序列长度之间折中：
- 高频词可能是一个 Token；
- 低频词会拆成多个子词；
- 未见过的新词仍可由已有片段组合；
- 代码、数字和多语言文本使用同一套可计算表示。
常见方法包括 BPE、WordPiece 和 Unigram。工程上不必死记算法细节，但要知道：词表设计会影响模型对不同语言和内容类型的效率。
中文为什么不能简单换算
“一个汉字约等于一个 Token”只是非常粗糙的经验。较新的多语言词表可能把常见中文词组编码成单个 Token，冷僻字、特殊符号或中英混排也可能被拆分。
| 内容类型 | Token 特征 |
|---|---|
| 常见中文 | 单字或常见词组可能成为 Token |
| 英文 | 高频单词较省，长词会被拆分 |
| 数字 | 长数字可能被切成多个片段 |
| 代码 | 标识符、空格、缩进和标点都会计数 |
| emoji | 一个可见符号可能对应多个 Token |
因此，估算只能用于预算。需要精确值时，应使用目标模型对应的 tokenizer，而不是套用固定的“字数乘系数”。
Token 与上下文窗口
上下文窗口是模型一次请求能处理的 Token 总量，通常包括：
系统提示词 + 历史对话 + 用户输入 + 工具结果 + 模型输出
假设模型支持 128K 上下文，并不意味着可以输入 128K 后再无限生成。输入和输出通常共享同一个预算，还要给系统消息、结构化数据和安全余量留空间。
当上下文超限时，应用可能截断早期消息、压缩历史、检索少量相关资料，或者直接拒绝请求。长上下文也不等于模型能同等准确地利用每个位置的信息；“放得下”和“用得好”是两件事。
Token 与成本
商业 API 通常分别计算输入 Token 和输出 Token：
总成本 = 输入 Token × 输入单价 + 输出 Token × 输出单价
输出往往更贵，因为生成是逐 Token 进行的。缓存命中的输入、批处理请求或不同模态 Token 可能使用不同价格，具体规则必须以服务商文档为准。
降低成本不能只靠缩短用户问题。真正占预算的常见部分包括：
- 每轮重复发送的长系统提示词；
- 没有裁剪的完整聊天历史；
- 检索返回过多或重复文档；
- 工具输出包含日志、HTML 或无关字段；
- 要求模型输出冗长但无人消费的解释。
Token 与速度
推理性能常见两个阶段：
- Prefill：模型一次读取输入 Token，输入越长，首 Token 延迟通常越高；
- Decode：模型逐个生成输出 Token，速度常用 tokens/s 表示。
相同的 tokens/s 不一定代表相同体验。用户更敏感的是多久看到第一个字、后续输出是否稳定，以及长对话后延迟是否明显上升。
⚠️ 不要只看上下文上限
更大的上下文窗口会增加 KV Cache、显存和计算压力。产品设计应先检索、筛选和压缩信息，再把真正相关的内容交给模型。
Token 在工程中的五个实践
1. 在发送前估算
对系统提示词、历史消息、检索结果和预留输出分别计数，接近上限时主动裁剪。
2. 按信息价值分配预算
稳定规则放系统提示词，背景资料按需检索；不要让低价值日志挤占关键事实。
3. 保留输出余量
如果请求需要生成 JSON、代码或长报告，应显式预留输出 Token，避免结果在结构闭合前被截断。
4. 记录真实使用量
监控每类请求的输入、输出、缓存命中、延迟和失败率。平均值会掩盖极端长请求，P95 或 P99 更有运营意义。
5. 使用正确的 tokenizer
模型升级后重新校准。不同词表会改变计数、截断位置与成本，不能假设所有模型完全兼容。
一个直观心智模型
可以把大模型想成一台按“信息片段”工作的机器：
- Token 是片段；
- 词表定义可用片段；
- 上下文窗口是工作台容量；
- 推理成本取决于送入和生成多少片段；
- 分词器决定原始文本如何装进工作台。
结语
Token 连接了语言与计算。它决定模型看到什么、一次能记住多少、响应需要多久，以及 API 最终花多少钱。
理解 Token 后，许多大模型问题会变得具体：上下文为什么溢出、中文为何计费不同、长提示词为什么变慢、RAG 为什么需要裁剪。比起背诵一个固定换算比例，更重要的是围绕目标模型测量真实 Token，并把预算留给真正有价值的信息。