前几天有个朋友问我："为什么我用 DeepSeek 写中文，花的钱比写英文多？"另一个朋友更离谱：让 AI 数 strawberry 里有几个 r，AI 居然数错了。这些看似不相关的问题，背后都指向同一个东西——Token。

一、AI 眼里的世界：不是文字，是数字

计算机只认识数字，不认识文字。

这句话你可能听过，但有没有想过：那 DeepSeek、Kimi 这些大语言模型是怎么"读懂"你说的话的？

答案是：它根本没有"读"文字。在 AI 眼里，你输入的每一句话，都会先被切成一块一块的"碎片"，每个碎片对应一个数字编号，AI 处理的始终是这串数字。

这些碎片，就叫 Token（词元）。

举个例子，你输入：

Tokenization is fascinating!

AI 看到的其实是（以 GPT-4o 的 o200k_base 编码为例）：

[4421, 2860, 382, 33733, 0]

对应的碎片是：

["Token", "ization", " is", " fascinating", "!"]

注意：tokenization 这个词被切成了两块——Token 和 ization。这不是 bug，这就是 Token 的工作方式。

还有一类你看不见的 Token

除了你输入的文字，模型还会悄悄插入一些特殊 Token：

这就是为什么 API 返回的 Token 消耗数，有时比你自己数的多几个——那几个就是隐含的特殊 Token。

二、为什么不直接用字母或单词？

一个自然的疑问：为什么不直接用字母（a、b、c……）或者完整单词作为基本单位？我们来看看三种方案各有什么问题：

现代大模型（DeepSeek、Qwen、GPT、Llama）全部采用第三种——子词切分（Subword Tokenization）。

常见单词保持完整，生僻词或新词拆成更小的片段。这样既不会词表爆炸，又能处理任何新词。

三、BPE：Token 是怎么炼成的？

主流的子词切分算法叫 BPE（Byte Pair Encoding，字节对编码），最初是一种数据压缩算法，后来被引入 NLP 领域。

它的核心思想极其简单：把出现频率最高的字符对，反复合并成新的单元。

手工演示一遍

假设训练语料里有这些词：low、lower、lowest

第一步：从最小单位（字符）开始

l o w
l o w e r
l o w e s t

第二步：统计所有相邻字符对的频率，找出最高的

(l, o) 出现 3 次  ← 与 (o, w) 并列最高，按字典序优先选择
(o, w) 出现 3 次
(w, e) 出现 2 次
...

第三步：合并 (l, o) → lo

lo w
lo w e r
lo w e s t

第四步：继续合并 (lo, w) → low

low
low e r
low e s t

第五步：继续合并 (low, e) → lowe

low
lowe r
lowe s t

如此反复，直到词表达到目标大小（GPT-4 的词表约 10 万个 Token）。

最终结果：常见词 low 是一个完整 Token，lower 被切成 low + er，lowest 被切成 low + est。

这里有个关键点：BPE 是从训练数据中"学"出来的，不是人工规定的。训练数据里什么词出现得多，什么词就更可能成为一个完整 Token。上面的演示是简化示例——在真实模型中，lower、lowest 这类高频词经过足够多轮合并后，本身也会成为单个完整 Token。

四、1 个 Token 到底有多大？

有个实用的经验公式：

英文：1 个 Token ≈ 4 个字符 ≈ 0.75 个单词

也就是说，100 个英文单词大约消耗 133 个 Token。

但中文就不一样了。

中文 Token 为什么比英文多？

GPT 系列的 Tokenizer 是在以英文为主的语料上训练的，中文字符在训练数据里出现频率远低于英文，所以大多数中文字没能被合并成高频 Token。

结果就是：在旧版模型上，同等语义的中文往往比英文消耗更多 Token；新版模型已大幅改善，但仍因模型而异。

以 GPT-4o（o200k_base）实测为例：

GPT-4o 的新版 Tokenizer 对中文已经做了大幅优化，简单句子的中英文 Token 数基本持平。但在旧版模型（如 GPT-4 的 cl100k_base）上，同样的中文内容需要多消耗近一倍的 Token。

💡 不同模型差异很大：GPT-4（cl100k_base）处理 你好，世界！ 需要 7 个 Token，GPT-4o（o200k_base）只需 4 个——旧版 Tokenizer 对中文支持弱，很多汉字会被拆成多个字节片段。国内模型（如 DeepSeek-V3、Qwen）在中文语料上训练更充分，DeepSeek-V3 处理中文时大约 1.5 个汉字对应 1 个 Token，中文效率较好。

五、上下文窗口：AI 的"工作记忆"

你有没有遇到过这种情况：和 AI 聊了很长时间，它突然"忘记"了你前面说的内容？

这不是 AI 变笨了，而是它的 上下文窗口（Context Window） 满了。

什么是上下文窗口？

上下文窗口是模型一次能处理的最大 Token 数量，包括你输入的内容和 AI 输出的内容加在一起。

可以把它想象成一张有限大小的便利贴：

• 你说的每句话，都贴在上面
• AI 回复的每句话，也贴在上面
• 便利贴写满了，最早的内容就会被"挤掉"

2026 年主流模型的上下文窗口

¹ Gemini 2.5 Pro 最大输出数据截至 2025 年底，以官方最新文档为准。

1M Token 是什么概念？大约相当于一部《红楼梦》的全文（约 73 万字）。

💡 注意上下文窗口 ≠ 最大输出：这是很多人踩过的坑。上下文窗口是模型能"看到"的总量，而最大输出 Token 是模型单次能"说出"的上限。比如 DeepSeek-V3 能读 128K Token 的内容，但单次回复最多只能输出 8K Token。如果你让它一次性生成一篇超长文章，它会在 8K Token 处截断。

六、Token 决定了你的 API 账单

如果你用过阿里云百炼、百度千帆、DeepSeek 开放平台等 API，会发现它们的计费单位不是"次数"，而是 Token 数量。

计费公式很简单：

总费用 = (输入 Token 数 × 输入单价) + (输出 Token 数 × 输出单价)

注意：输出比输入贵。这是因为生成每个 Token 需要模型逐步推理，计算量远大于读取输入。

国内主流平台价格对比（2025 年）

价格随时可能调整，以各平台官方文档为准。DeepSeek 凭借极低的定价在国内市场引发了一轮"价格战"，带动整体 API 成本大幅下降。

实际估算

假设你让 AI 帮你写一篇 1000 字的中文文章（以 DeepSeek-V3 为例）：

• 你的提示词：约 200 字 → 约 300 Token（输入）
• AI 的回复：约 1000 字 → 约 1200 Token（输出）
• 总费用：(300 × ¥0.000002) + (1200 × ¥0.000008) ≈ ¥0.0102

不到 3 厘钱。单次极便宜，但如果你的应用每天有大量请求，Token 成本就不可忽视了。

顺便说个省钱小技巧：精简你的系统提示词（System Prompt）。系统提示词每次对话都会消耗，如果你的 System Prompt 有 2000 Token，每天 1 万次请求，光这一项就是 2000 万 Token 的输入成本。

七、Token 引发的 AI "奇怪行为"

理解了 Token，很多 AI 的"奇怪行为"就能解释了。

谜题一：AI 数不清字母

你问 AI："strawberry 里有几个字母 r？"

很多模型会答错，说 2 个，实际上是 3 个。

原因：strawberry 在 GPT-4o 的 Tokenizer（o200k_base）里被切成 st + raw + berry 三个 Token，模型看到的是三个碎片，而不是 10 个字母。它没有"逐字母扫描"的能力，只能靠训练时学到的模式猜测，所以很容易数错。

谜题二：AI 不擅长反转字符串

让 AI 把 "hello" 反转成 "olleh"，它有时会出错。

原因：hello 是一个 Token，反转意味着要拆开这个 Token 内部的字符，而模型的基本操作单位是 Token，不是字符。

谜题三：9.11 和 9.9 的大小比较

早期模型有时会认为 9.11 > 9.9，背后有 Token 的原因：

"9.11" → ["9", ".", "11"]  三个 Token
"9.9"  → ["9", ".", "9"]   三个 Token（但内部数字表示不同）

模型处理数字时，看到的是离散的 Token 序列，而不是连续的数值。小数点后的 11 和 9 作为独立 Token，模型可能错误地用整数大小关系来比较，导致认为 11 > 9，所以 9.11 > 9.9。

谜题四：代码和 JSON 消耗 Token 特别多

{"user": "Alice", "age": 30, "city": "Beijing"}

这段 JSON 里每个引号、冒号、花括号都是独立的 Token，比普通文字消耗更多 Token。这也是为什么让 AI 处理大量结构化数据时，成本会比预期高。

💡 核心规律：凡是需要"字符级精确操作"的任务（数字母、反转字符串、精确计算字符位置），都是 Token 化机制的天然弱点。遇到这类需求，不要依赖 AI 直接完成，用代码处理更可靠。

八、不同模型用的 Tokenizer 不一样

Token 不是一个统一标准，不同公司、不同模型用的 Tokenizer 可能完全不同。

主流的切分算法有三种：

💡 SentencePiece 是框架，不是算法：你可能还听过 SentencePiece，它是 Google 开源的一个 Tokenizer 工具库，内部可以跑 BPE 或 Unigram 算法。T5 用的就是 SentencePiece 框架 + Unigram 算法。两者不是同一个层次的概念。

同一句话，不同 Tokenizer 切出来差多少？

以 "你好，我想了解一下 Token 是什么？" 为例：

同样的内容，GPT-4o 只需 9 个 Token，GPT-4 需要 16 个——新版 Tokenizer 对中文的支持提升了近一倍。这也意味着跨模型迁移时，Token 数估算要重新计算，不能直接套用。

九、怎么自己数 Token？

方法一：用 tiktoken 库（适用于 GPT 系列）

import tiktoken

# gpt-4o 使用 o200k_base 编码
enc = tiktoken.encoding_for_model(“gpt-4o”)

text = “你好，我想了解一下 Token 是什么？”
tokens = enc.encode(text)

print(f"Token 数量：{len(tokens)}“)
print(f"Token 列表：{[enc.decode([t]) for t in tokens]}”)

实际输出（GPT-4o，o200k_base）：

Token 数量：9
Token 列表：['你好', '，我', '想', '了解', '一下', ' Token', ' 是', '什么', '？']

方法二：在线可视化工具

• OpenAI Tokenizer：platform.openai.com/tokenizer，输入文本即可看到每个 Token 的边界和 ID
• DeepSeek / 通义千问：各平台控制台的 API 调用返回值中包含 usage.prompt_tokens 和 usage.completion_tokens，可直接查看实际消耗

方法三：经验估算

💡 最可靠的方式永远是用对应模型的官方 Tokenizer 实测，经验估算仅供粗略参考。同一段文字在不同模型上的 Token 数可能相差 1 倍以上，在做成本预算时务必用目标模型实测。

十、Token 的未来：越来越长的上下文

Token 和上下文窗口的发展速度，比大多数人预想的快得多。

• 2020 年：GPT-3 上下文窗口 2048 Token（约 1500 英文单词）
• 2023 年：GPT-4 扩展到 128K Token
• 2024 年：Gemini 1.5 Pro 支持 100 万 Token；通义千问 Qwen-Long 在特定场景下支持超长上下文（官方标称最高可达千万级 Token，适用于超长文档处理场景）
• 2025 年：DeepSeek-V3 支持 128K Token，Qwen-Max 扩展至 1M Token
• 2026 年：多个模型进入百万 Token 时代，部分模型测试 200 万 Token

上下文窗口的扩大，正在改变 AI 的使用方式：

• 以前：需要把长文档切片，分批喂给 AI
• 现在：直接把整本书、整个代码库扔进去，让 AI 全局理解

但更大的上下文窗口也带来新问题："大海捞针"效应——当上下文太长时，模型对中间部分的注意力会下降，容易忽略埋在中间的关键信息。这是当前研究的热点方向之一。

Token 不只是文字

2026 年，多模态模型已经是主流。图片、音频、视频同样会被转换成 Token 再送入模型：

• 图片：被切成固定大小的图像块（patch），每个 patch 对应若干 Token。一张普通图片通常消耗几百到几千个 Token
• 音频：按时间帧切分，转换为音频 Token
• 视频：帧 + 音频联合编码，Token 消耗量极大

这意味着多模态任务的成本远高于纯文本，发一张图给 AI 分析，可能比发一段文字贵 10 倍以上。说到底，Token 就是"信息的最小处理单元"——无论文字、图片还是声音，进入模型之前都要先变成 Token。

总结