token 与 tokenization：理解一个模型的资源消耗 LLM

#为什么要谈论tokens

当您通过 Ollama 或 LM Studio 与本地 LLM 进行对话时，您输入的是文本句子。而模型本身并不会直接看到这些原始句子。在任何计算开始之前，您的文本都会被转换为一串数字，每个数字代表一个 token。模型的所有操作——理解、生成——都是在这些 token 层面上完成的，而不是在单词层面。

理解 token 并不只是一个学术细节。它能解释三个非常实际的问题：为什么一份文档能或不能装进上下文窗口，为什么您的模型以某个速度生成内容（也就是常说的每秒多少个 token），以及为什么云端 API 的计费或上下文限制始终以 token 为单位，而不是以词为单位。

#一个 token 究竟是什么？

一个标记是文本的一个片段：有时是整个单词，通常是一个单词的片段，有时是单个字符或标点符号。它既不是字母，也不是严格意义上的单词——而是算法在分词过程中选择的一种统计单位，用于最高效地表示文本。

最实用的经验法则是：在英语中，1 个 token ≈ 4 个字符 ≈ 0.75 个词。换句话说，100 个 token 大约相当于 75 个英语单词。法语的比例则明显没有这么划算，下文会再说明。

"chat"

一个常见且简短的词：通常仅为 1 个 token。

"anticonstitutionnellement"

一个罕见且长的词：被分割成多个token（anti / constitution / nelle / ment…）

" "（空格）

空格通常被包含在下一个 token 的开头，而不是单独成为一个 token。

"123456"

数字通常会逐位拆分，或按几位一组拆分。

😀

一个表情符号可能单独消耗多个 token。

非常常见的词通常各自对应一个 token，因为它们在训练数据中反复出现。罕见词、技术术语，或训练数据中占比较低的语言中的词，则需要由更小的片段拼合而成——因此会消耗更多 token。

#文本实际是如何切分的

大多数现代大语言模型采用 BPE（字节对编码）或其变体（WordPiece、Unigram）算法。原理是：从原始字符开始，逐步融合训练语料中最频繁的符号对，直到形成固定大小的词汇表——通常为 32,000 到 200,000 个 token，具体取决于模型。

1. 01
   初始切分

   文本被还原为其基本字节或字符。没有任何信息丢失：任何字符串均可被表示。
2. 02
   训练中学到的合并规则

   分词器会按频率顺序应用训练时学到的合并列表（例如“t”+“ion”→“tion”）。
3. 03
   转换为标识符

   每个最终token都被替换为其在词汇表中的编号。模型现在仅处理这些整数。

一个重要的结果是：词汇表在训练时就已固定。主要使用英语训练的模型，其词汇表会针对英语优化，并将法语拆分成更小、更多的片段。这就是使用法语时产生额外成本的根本原因。

#为什么法语比英语更昂贵

在内容等效的前提下，法语文本通常比其英文翻译多消耗15%至30%的token。在一些高度偏向英文的模型上，这一差距甚至可能超过50%。这由三个因素共同导致。

词汇分布不均衡

分词器主要基于英文数据进行训练：常见英文单词拥有专属 token，而法语单词则没有。

重音符号和特殊字符

é, è, à, ç, œ… 在词汇中出现频率较低，有时会被拆分为多个 token（甚至多个字节）。

更丰富的形态结构

动词变位、语法一致关系和省音（l'、d'、qu'）使同一个词产生多种形式，而词表对这些形式的覆盖较差。

具体例子：英文句子「The cat is on the table」大约占用 6 个 token。其法语版本「Le chat est sur la table」则通常占用 7 到 8 个 token，具体取决于模型。对于整段文本，这种差异就会变得显著——而且要付出双重代价：既占用上下文窗口的空间，也增加生成时间。

#token 与上下文窗口

模型的上下文窗口以tokens为单位衡量，而非单词或字符。一个宣称拥有32768个tokens上下文容量的模型，在某一时刻最多可「看到」约24000个英文单词——但法语仅约18000至20000个单词，因为法语的token化成本更高。

这个窗口包含所有内容：系统提示词、对话历史、您当前的消息、粘贴的文档，以及正在生成的回答。当总量超过限制时，模型会截断内容——通常是最早的部分——并“忘记”对话的开头。

系统提示

每次调用都会计入。冗长的系统提示词会不断占用上下文空间。

历史记录

每一轮对话的内容都会累积。长时间的讨论最终会填满上下文窗口。

文档（RAG、复制粘贴）

一份 10 页的 PDF，往往就有数千个 token。

生成的回复

输出也会占用空间：必须为生成回答预留足够的空间。

#Token 与本地运行速度

大语言模型的运行速度以每秒 token 数（tok/s）衡量，这是基准测试中的通用单位。有两个阶段需要区分，它们经常被混淆。

提示词 / 预填充

“读取”您的整个提示词所需的时间。输入的 token 越多，开始生成第一条回复前的等待时间就越长。

生成 / 解码

响应令牌的输出速度，一个接一个地输出。这是屏幕上观察到的 tok/s。

这对法语的直接影响是：由于相同内容对应更多 token，模型处理法语提示词、生成长度相当的法语回复时，自然会花费更多时间。“用法语时更慢”的感觉并非主观判断——原因就在于 token 数量。

解码速度主要取决于模型和硬件（每个 token 的活跃参数数量、内存带宽、量化）。但在硬件不变的情况下，减少输入 token 的数量——缩短系统提示词、精简历史记录——能显著缩短首个 token 的等待时间。

#自行计算文本中的 token 数量

建立直观认识的最佳方法是实际测量。下面介绍三种方法，从最简单的到最精确的。

#粗略估算

无需安装任何软件即可快速估算：英文文本用字符数除以 4，法文文本用字符数除以 3 至 3.5。这个估算比较粗略，但足以判断一份文档是否能放进上下文窗口。

#在 Python 中使用实际的分词器进行计数

要精确计数，请使用模型的分词器。Hugging Face 的 tokenizers / transformers 库可以加载开放权重模型实际使用的分词器：

from transformers import AutoTokenizer

# Remplacez par le modèle que vous faites tourner en local
tok = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B")

texte_fr = "Le chat est sur la table."
texte_en = "The cat is on the table."

print(len(tok.encode(texte_fr)), "tokens (fr)")
print(len(tok.encode(texte_en)), "tokens (en)")

# Voir le découpage réel
print(tok.tokenize(texte_fr))

用您自己的文本运行这个脚本，是最直观的练习：您可以亲眼看到哪些法语词被拆分，以及英语究竟紧凑多少。

#通过 Ollama API 读取计数

Ollama 已经在响应中显示了 token 计数。守护进程默认监听在 http://localhost:11434；API 调用返回 prompt_eval_count（提示词 token 数）和 eval_count（生成 token 数）：

curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:7b",
  "prompt": "Explique la tokenization en une phrase.",
  "stream": false
}' | grep -o '"eval_count":[0-9]*'

您还可以找到 eval_duration：通过将 eval_count 除以持续时间，即可获得您设备上实际的每秒 token 生成速率，该速率基于您所使用的量化方式。

#节省 tokens 而不牺牲质量

每个 token 都会占用上下文空间并影响速度，因此养成几个简单的习惯就能带来明显改善，尤其是在使用法语时。

简洁的系统提示

每次调用都要重新发送系统提示词。每一句多余的话都会在每一轮产生费用。

清理对话历史

将较早的对话概括成摘要或删去，而不是一直携带整段对话。

使用 RAG，而不是把全部内容粘贴进去

仅注入文档中的相关段落，而非整个文档

设置输出长度

请求简短回答会生成更少的 token——因此响应更快。

#深入了解

Token 是连接多个基础概念的纽带。另有三篇指南直接延伸本指南的内容：第一篇详细介绍 token 所填充的上下文窗口，第二篇解释量化如何影响以 token/秒衡量的速度，第三篇展示 Transformer 如何在内部处理这些 token。