大模型处理字符成为token的核心流程如下：

大模型将字符转换为token的过程是通过分词器（Tokenizer）将原始文本切分成模型能理解的离散语义单元，然后映射为词汇表中的数字ID。

原始文本 → 预分词 → 应用分词算法 → 匹配词汇表 → 数字ID序列

具体步骤分解：

1. 预清洗与标准化

统一编码（UTF-8）、规范化空格、标点、处理特殊字符

2. 主流核心分词算法

• BPE（字节对编码，GPT系列使用）：从字符开始，迭代合并最频繁的相邻符号对
• WordPiece（BERT使用）：类似BPE，但基于概率合并
• Unigram（SentencePiece）：从大词汇表开始，逐步删除最不重要的单元
• 基于规则的分词：针对特定语言（如中文jieba）

3. 以BPE为例的分词过程：

原始文本："unhappy"
字符化：["u", "n", "h", "a", "p", "p", "y"]
BPE训练后学习到的合并规则：
1. "p"+"p" → "pp"（高频组合）
2. "h"+"a" → "ha"
3. "un"+"ha" → "unha"
4. "unha"+"ppy" → "unhappy"

最终分词：["un", "happy"] 或直接 ["unhappy"]（取决于词汇表）

4. 中文分词的特殊性：

传统方法（如GPT）：
"人工智能" → ["人", "工", "智", "能"]（4个token）

优化方法（国产模型）：
"人工智能" → ["人工", "智能"]（2个token，更高效）

5. 映射为数字ID

• 每个token对应词汇表中的一个数字索引
• 例如：{“hello”: 1234, “world”: 5678}
• “hello world” → [1234, 5678]

关键特点：

• 不可逆过程：多个可能字符序列可对应相同token序列
• 词汇表外问题：遇到新词会拆分为子词或单个字符
• 语言差异：对英语效率高，对中文等表意文字效率较低

这个过程是模型理解文本的第一步，决定了后续所有处理的基础。

Token:

token相当于大模型词汇表中的一个基本文本单元，类似英文中的词根或中文中的字词。

一、Token的本质

Token是语言模型字典中的基本文本单元，可以理解为：

• 英语：通常是一个单词或词根（如 “unbelievable” → [“un”, “believ”, “able”]）
• 中文：通常是一个汉字或常见词组（如 “人工智能” → [“人工”, “智能”]）

二、Token与字符/单词的换算

英文文本：

约 1 token = 0.75个英文单词
约 100 tokens = 75个英文单词

例子：
"Hello, how are you today?" 
 大约 6个token（实际分词：["Hello", ",", " how", " are", " you", " today", "?"]）

中文文本：

约 1 token = 1-2个中文字符
约 100 tokens = 80-120个中文字符

例子：
"人工智能正在改变世界"
可能被分词为：["人工", "智能", "正在", "改变", "世界"] = 5个token

三、为什么用Token而不是字符？

1. 效率：减少序列长度，加快处理速度
2. 语义：token能更好地捕捉词汇含义和结构
3. 多语言：统一处理不同语言（中文、英文、代码等）
4. 词汇表限制：模型有固定词汇表大小（通常5万-10万个token）

四、不同模型的分词差异

模型	分词器	中文效率	特点
GPT系列	BPE（字节对编码）	较低	中文1字≈1.3token，效率较低
Claude	自研分词器	中等	对中文优化稍好
国产模型	专门优化	较高	中文1字≈0.8-1token，效率高
代码模型	考虑代码结构	-	能更好处理编程语法

五、实际例子对比

同一段文本的不同token化结果：

英文句子：
"The quick brown fox jumps over the lazy dog."

GPT分词：["The", " quick", " brown", " fox", " jumps", " over", " the", " lazy", " dog", "."]
→ 10个token

中文句子：
"今天天气真好，我们去公园散步吧！"

GPT分词：["今", "天", "天", "气", "真", "好", "，", "我们", "去", "公", "园", "散", "步", "吧", "！"]
→ 15个token（每个汉字基本是1个token）

优化后的中文分词：
["今天", "天气", "真好", "，", "我们", "去", "公园", "散步", "吧", "！"]
→ 10个token（更符合语义）

六、如何估算文本的token数量？

简单估算公式：

• 英文：单词数 ÷ 0.75
• 中文：字符数 × 1.3（GPT系列） 或 × 1.0（优化模型）

准确方法：

使用官方工具：OpenAI的tiktoken库

import tiktoken
encoder = tiktoken.encoding_for_model("gpt-4")
tokens = encoder.encode("你的文本")
print(len(tokens))

在线计算器：许多网站提供token计数器

七、对上下文窗口的重新理解

当说上下文窗口60k时：

• 如果是英文文档：大约处理45,000个单词
• 如果是中文文档：大约处理23,000-46,000个汉字
• 如果是混合内容：需要具体计算

八、重要注意事项

不同的计费方式：

• 大多数API按token收费
• 输入和输出的token都计费

上下文窗口的占用：

• 你的输入 + 模型的输出 ≤ 上下文窗口
• 系统提示词也占用token

优化提示词：

• 精简提示词可以节省token
• 但过度精简可能影响效果

上下文长度

上下文长度在技术领域有一个比较专业的词语：context window。

上下文长度：

LLM的Context Window指模型在单次推理过程中可处理的token序列的最大长度，包括：

1. 输入部分(用户提供的提示词、历史对话内容、附加文档等)
2. 输出部分（模型当前正在生成的响应内容）

例子：比如我们当前打开一个DeepSeek的会话窗口，开启一个新的会话，然后你输入内容，接着模型给你输出内容。这就是一个单次推理的过程，如果当前模型的上下文长度为60k，就说明这一来一回的回复不能超过60000个token.

多轮对话：

当我们进行多轮对话的时候，每一次ai会将我们的历史记录带入到下一次的问答中，会导致随着对话越来越多，Context Window越来越小。

例子：

// 第1轮， 假设占 15 tokens
[
  {"role": "user", "content": "法国的首都是？"}
]
// AI回复后，上下文变为 30 tokens
[
  {"role": "user", "content": "法国的首都是？"},
  {"role": "assistant", "content": "巴黎。"}
]

// 第2轮，用户新问题，上下文变为 45 tokens
[
  {"role": "user", "content": "法国的首都是？"},
  {"role": "assistant", "content": "巴黎。"},
  {"role": "user", "content": "它以什么闻名？"}
]
// AI回复后，上下文变为 60 tokens
[
  {"role": "user", "content": "法国的首都是？"},
  {"role": "assistant", "content": "巴黎。"},
  {"role": "user", "content": "它以什么闻名？"},
  {"role": "assistant", "content": "以埃菲尔铁塔、卢浮宫和时尚闻名。"}
]

// 第3轮，继续增长到 75 tokens
[
  {"role": "user", "content": "法国的首都是？"},
  {"role": "assistant", "content": "巴黎。"},
  {"role": "user", "content": "它以什么闻名？"},
  {"role": "assistant", "content": "以埃菲尔铁塔、卢浮宫和时尚闻名。"},
  {"role": "user", "content": "推荐一个博物馆"}
]
// AI可以基于历史知道“博物馆”指卢浮宫，并推荐

达到限制时的处理：

• 自动截断：丢弃最早的对话内容，保留最近的部分
• 手动总结：用户可要求模型总结之前的对话，然后继续
• 开启新会话：完全重新开始，清空历史