一、引言：为什么你需要理解 Token？
如果你正在使用 ChatGPT、Claude、文心一言、通义千问等大模型产品，或者在你的应用中集成了 OpenAI API、Azure OpenAI、阿里云百炼等服务，那么你一定遇到过"Token"这个词。
"这个请求用了 3500 个 Token。" "GPT-4o 的输入价格是 $2.50/百万 Token。" "Claude 3.5 Sonnet 支持 200K 上下文窗口。"
但对于很多刚接触大模型的开发者来说，Token 仍然是一个模糊的概念。它是什么？和字符（character）有什么区别？和单词（word）又是什么关系？为什么同样的文本在不同模型中消耗的 Token 数量不同？这些问题直接关系到你的应用成本、性能设计和架构选型。
本文将从底层原理出发，帮助你真正理解 Token，成为 LLM 应用的"精算师"。
二、Token 的本质：分词原理深度解析
2.1 什么是 Token？
Token 是大型语言模型处理文本的基本单位。它既不是字符（character），也不是严格意义上的单词（word），而是介于两者之间的一种"子词（subword）"单位。
要理解这一点，我们先来看一个直观的例子：
英文原文: "I love programming!"
字符数: 19（含空格和标点）
单词数: 3
Token 数（GPT-4）: 4 → ["I", " love", " program", "ming!"]在 GPT-4 的分词器中，"programming" 被拆分为 "program" 和 "ming" 两个 Token。这说明 Token 的划分不完全遵循语言学中的"词"的概念，而是由模型的词汇表（vocabulary）决定的。
再看中文的例子：
`
中文原文: "我爱编程"
字符数: 4
Token 数（GPT-4）: 约 4-6 个（取决于具体分词器版本）
Token 数（Qwen2.5）: 约 4 个
`中文的 Token 效率通常低于英文，因为中文每个字符携带的信息密度更高，但分词器往往需要更多 Token 来表示相同的内容。
2.2 分词器（Tokenizer）的工作原理
分词器是将人类可读的自然语言文本转换为模型可处理的数字序列的关键组件。整个过程分为三个阶段：
阶段一：预处理（Pre-tokenization）
将原始文本按照一定的规则进行初步切分。常见的预处理步骤包括：
空格分割标点符号分离大小写处理（部分模型保留大小写，部分统一转小写）特殊字符处理（URL、邮箱、代码等）
阶段二：Token 编码（Tokenization）
使用训练好的分词模型，将预处理后的文本片段映射为词汇表中的 Token ID。这一步是分词的核心，不同的分词算法有不同的策略（下文详述）。
阶段三：数字序列输出
最终输出的是一串整数（Token IDs），这就是模型实际"看到"的内容：
`
# 以 tiktoken 为例
import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
tokens = enc.encode("Hello, world!")
# 输出: [9906, 11, 1917, 0]
`模型通过嵌入层（Embedding Layer）将这些整数转换为高维向量，然后送入 Transformer 进行计算。
2.3 主流分词算法对比
BPE（Byte-Pair Encoding）------ GPT 系列的选择
BPE 最初是一种数据压缩算法，由 Gage 在 1994 年提出。2016 年，Sennemann 等人将其引入 NLP 领域。
核心思想：从字符级别开始，迭代合并出现频率最高的相邻字符对，直到词汇表达到预定大小。
工作流程：
初始化词汇表为所有字符统计训练语料中相邻字符对的出现频率合并频率最高的字符对，加入词汇表重复步骤 2-3，直到词汇表大小达到上限（如 50000、100000）
GPT 系列的分词器演进：
GPT-2: ``gpt2`` 编码器，50257 个 TokenGPT-3: 类似 GPT-2，50257 个 TokenGPT-4: ``cl100k_base`` 编码器，约 100000 个 TokenGPT-4o: ``o200k_base`` 编码器，约 200000 个 Token
BPE 的优势在于能够平衡词汇表大小和未知词（OOV）问题。即使遇到训练中未见过的词，BPE 也能将其拆分为已知的子词单元。
WordPiece ------ BERT 的分词策略
WordPiece 由 Google 提出，最初用于日语和韩语的分词，后被 BERT 采用。
核心思想 ：与 BPE 类似，但合并策略不同。WordPiece 选择合并后能最大化训练数据似然的字符对，而不是简单地选择频率最高的。
数学表达：
`
选择最大化 (count(pair) / (count(first) * count(second))) 的字符对
`这意味着 WordPiece 更倾向于合并那些"在一起出现概率远高于随机"的字符对。
特点：
词汇表大小：BERT 为 30522使用 ``##`` 标记表示子词（如 "playing" → "play" + "##ing"）对英文分词效果好，但对中文支持有限
SentencePiece ------ LLaMA、T5 的统一方案
SentencePiece 由 Google 提出，是一个端到端的分词系统。
核心创新：
- 无需预分词
：直接处理原始字符串，不依赖空格分隔 - 语言无关
：适用于任何语言，包括中文、日文、韩文等 - 统一接口
：支持 BPE 和 Unigram 两种算法
工作原理：
使用 Unicode 字符作为基本单位特殊标记 ``_`` 表示空格例如："Hello world" → "_Hello_world"
LLaMA 系列的 SentencePiece 配置：
LLaMA 1: 32000 词汇表，BPE 算法LLaMA 2: 32000 词汇表，BPE 算法LLaMA 3: 128256 词汇表，Tiktoken 实现（改进版 BPE）LLaMA 3.1: 128256 词汇表
SentencePiece 的优势在于多语言支持和实现简洁。LLaMA 3 将词汇表扩大到 128K，显著提升了中文等多语言的分词效率。
Unigram ------ 多模型融合的趋势
Unigram 语言模型分词器由 SentencePiece 支持，采用不同的策略：
核心思想：从一个大的候选词汇表开始，迭代地移除那些对整体似然贡献最小的 Token，直到达到目标词汇表大小。
与 BPE 的区别：
BPE 是"自底向上"：从字符开始，逐步合并Unigram 是"自顶向下"：从大词汇表开始，逐步精简
优势：
分词结果更加平滑对罕见词的处理更灵活更适合多语言场景
2.4 中文分词的特殊性
中文分词是 LLM 分词器设计中的难点，原因在于：
1. 中文没有天然的分隔符
英文有空格分隔单词，中文的字符之间没有明确的分界。例如：
`
"中华人民共和国"
- 可以作为 1 个词（如果词汇表中有）
- 可以拆分为 "中华" + "人民" + "共和国"
- 也可以拆分为 7 个单字 Token
`2. 信息密度差异
一个中文字符通常携带的信息量相当于 1.5-2 个英文单词。这意味着：
` 中文: "今天天气很好"（6 字符，约 6-12 Token） 英文: "The weather is very nice today"（7 单词，约 7-10 Token） `同样长度的信息，中文在 Token 计数上往往更"贵"。
3. 各模型对中文的支持程度
模型 |
中文分词效率 |
说明 |
|---|---|---|
GPT-4 |
中等 |
cl100k_base 对中文有一定优化 |
Claude 3 |
较好 |
专门优化了多语言支持 |
LLaMA 3 |
较好 |
128K 词汇表包含更多中文字词 |
Qwen2.5/3 |
优秀 |
原生中文优化，分词效率最高 |
DeepSeek V3 |
优秀 |
针对中文专门优化 |
4. 代码分词的挑战
代码分词是另一个特殊场景。编程语言的关键字、标识符、操作符需要精确处理。GPT-4 的 cl100k_base 编码器对代码分词做了专门优化，这也是 GPT 系列代码能力强的原因之一。
2.5 实战：不同模型对同一段文本的分词结果对比
让我们用一段中英文混合的文本，对比不同模型的分词结果：
` text = "OpenClaw 是一个强大的 AI Agent 框架" # GPT-4 (cl100k_base) - 实际测试: 16 Token # 分词结果: [5109, 5176, 675, 55951, 48044, 13870, 118, 27384, 9554, 15592, 21372, 6704, 94, 228, 20119, 114] # GPT-4o (o200k_base) - 实际测试: 12 Token # 词汇表更大，能更好地处理混合文本 # Qwen2.5 # 预估 Token 数: 约 11-13 # 中文原生优化，分词效率最高 `实际测试数据（使用 tiktoken 实测，2026-04-23）：
文本 |
GPT-4 (cl100k) |
GPT-4o (o200k) |
Claude 3 |
LLaMA 3 |
Qwen2.5 |
|---|---|---|---|---|---|
"Hello, world!" |
4 |
4 |
~4 |
4 |
~5 |
"你好，世界！" |
7 |
4 |
~5 |
7 |
~4 |
"The quick brown fox" |
4 |
4 |
~4 |
5 |
~7 |
"人工智能技术正在改变世界" |
14 |
6 |
~11 |
14 |
~9 |
"OpenClaw 是一个强大的 AI Agent 框架" |
16 |
12 |
~13 |
~14 |
~11 |
注：GPT-4 / GPT-4o 数据来自 tiktoken 实际测试（2026-04-23）。其他模型为基于公开资料的预估值。
从数据可以看出，Qwen 系列对中文的分词效率明显优于其他模型，这正是原生中文优化带来的优势。
三、主流大模型分词器对比
3.1 GPT-4 / GPT-4o（tiktoken + cl100k_base / o200k_base）
OpenAI 使用自研的 ``tiktoken`` 库作为分词实现，这是一个用 Rust 编写的高性能分词器。
分词器版本：
cl100k_base``：GPT-4、GPT-3.5-turbo 使用o200k_base``：GPT-4o 使用（2024 年推出）
词汇表大小：
cl100k_base: 100,277 个 Tokeno200k_base: 约 200,000 个 Token
特点：
高性能：tiktoken 比 Python 实现的分词器快数倍开源可用：开发者可以使用 ``tiktoken`` 库在本地计算 Token 数量多语言支持：o200k_base 显著提升了对非英文语言的支持
代码示例：
` import tiktoken # GPT-4 enc = tiktoken.get_encoding("cl100k_base") tokens = enc.encode("Hello, world!") print(f"Token count: {len(tokens)}") # 输出: 4 # GPT-4o enc_o200k = tiktoken.get_encoding("o200k_base") tokens_o200k = enc_o200k.encode("Hello, world!") print(f"Token count (GPT-4o): {len(tokens_o200k)}") # 输出: 4 `3.2 Claude 3/3.5/4（Anthropic 自研分词器）
Anthropic 使用自研的分词器，不对外开放具体实现细节。
分词器特点：
不公开词汇表大小（估计约 100K-200K）对多语言支持较好，特别是中文使用 ``anthropic-tokenizer`` 库（部分功能可用）分词策略基于 BPE 变体，针对对话场景优化
如何获取 Claude 的 Token 数：
由于 Anthropic 不开放分词器 API，开发者可以通过以下方式获取 Token 计数：
- 使用官方 API
：``messages.count_tokens`` 端点 - 使用开源估算工具
：``tiktoken`` 的 ``cl100k_base`` 可以作为近似参考（误差约 5-10%） - 实际调用计费 API
：最准确，但会产生费用
Token 计算：
` # 使用 Anthropic 官方 API 获取 Token 数 import anthropic client = anthropic.Anthropic() response = client.messages.count_tokens( model="claude-sonnet-4-20250514", messages=[{"role": "user", "content": "Hello, world!"}] ) print(f"Input tokens: {response.input_tokens}") `3.3 LLaMA 3/3.1/3.2（SentencePiece → Tiktoken）
Meta 在 LLaMA 3 中做了一个重大改变：从 SentencePiece 迁移到 Tiktoken 实现。
为什么迁移：
Tiktoken 性能更好（Rust 实现 vs C++ 实现）社区生态更完善与 OpenAI 工具链兼容
分词器配置：
词汇表: 128,256 个 Token实现: Tiktoken（自定义编码）特殊 Token: ``<|begin_of_text|>``, ``<|end_of_text|>``, ``<|start_header_id|>``, ``<|end_header_id|>
多语言支持： LLaMA 3 的 128K 词汇表相比 LLaMA 2 的 32K 扩大了 4 倍，显著提升了对中文、日文、韩文等语言的支持。
3.4 Qwen 2/2.5/3（Qwen 自研分词器）
阿里巴巴通义千问系列使用自研分词器，针对中文进行了深度优化。
分词器特点：
原生中文优化，中文分词效率领先Qwen2.5: 约 151K-152K 词汇表Qwen3: 进一步扩词汇表，提升多语言支持使用 Tiktoken 兼容的接口
中文分词优势：
` 文本: "人工智能技术正在改变世界" - GPT-4: 13 Token - Qwen2.5: 9 Token（节省约 30%） `这意味着在处理中文内容时，Qwen 系列的 Token 成本更低。
3.5 DeepSeek V3（DeepSeek 自研分词器）
DeepSeek 系列同样针对中文进行了深度优化。
分词器特点：
词汇表: 约 100K+对中文技术文档、代码混合场景优化高效的中文子词切分策略
3.6 对比维度总结
维度 |
GPT-4o |
Claude 3.5 |
LLaMA 3 |
Qwen2.5 |
DeepSeek V3 |
|---|---|---|---|---|---|
词汇表大小 |
~200K |
~100K-200K |
128K |
~152K |
~100K+ |
分词算法 |
BPE (Tiktoken) |
自研 |
BPE (Tiktoken) |
自研 |
自研 |
英文效率 |
★★★★★ |
★★★★★ |
★★★★★ |
★★★★☆ |
★★★★☆ |
中文效率 |
★★★☆☆ |
★★★★☆ |
★★★☆☆ |
★★★★★ |
★★★★★ |
代码效率 |
★★★★★ |
★★★★☆ |
★★★★☆ |
★★★★☆ |
★★★★☆ |
开源工具 |
tiktoken |
有限 |
transformers |
transformers |
transformers |
四、上下文窗口：Token 的"舞台"
4.1 什么是上下文窗口？
上下文窗口（Context Window）是模型在一次推理过程中能够处理的最大 Token 数量。它包括：
-
输入 Token
：你的 prompt、系统提示、历史对话 -
输出 Token
：模型生成的回复上下文窗口 = 输入 Token + 输出 Token ≤ 最大限制
例如，GPT-4o 的上下文窗口是 128K Token，意味着：
` 如果输入有 100K Token，那么输出最多只能有 28K Token 如果输入有 50K Token，那么输出最多可以有 78K Token `4.2 各模型上下文窗口对比（2026年最新）
模型 |
上下文窗口 |
最大输出 Token |
|---|---|---|
GPT-4o |
128K |
16,384 |
GPT-4o-mini |
128K |
16,384 |
o1 |
200K |
100,000 |
o3-mini |
200K |
100,000 |
Claude 3.5 Sonnet |
200K |
8,192 |
Claude 3 Opus |
200K |
4,096 |
Claude 4 Sonnet |
200K |
8,192 |
Claude 4 Opus |
200K |
32,768 |
LLaMA 3.1 405B |
128K |
8,192 |
LLaMA 3.3 70B |
128K |
8,192 |
Qwen2.5 72B |
128K |
8,192 |
Qwen3 235B |
128K-256K |
8,192 |
DeepSeek V3 |
128K |
8,192 |
4.3 上下文窗口 ≠ 可用空间
这是一个常见的误区。上下文窗口的理论最大值并不等于你实际可用的空间。
系统提示词占用： 每个应用都有系统提示词（System Prompt），用于定义模型的行为。一个典型的系统提示词可能占用 500-5000 Token：
` 系统提示: "你是一个专业的编程助手..." → 约 500 Token 复杂系统提示（包含工具定义、格式要求） → 约 2000-5000 Token `工具调用占用： 如果你使用 Function Calling 或 Tools，每个工具的定义也会占用上下文空间：
` 工具定义: - search_web(name, description, parameters) → 约 200 Token - execute_code(name, description, parameters) → 约 200 Token - read_file(name, description, parameters) → 约 150 Token 3 个工具定义 ≈ 550 Token `实际可用空间计算公式：
` 实际可用输入 = 上下文窗口 - 输出预留 - 系统提示 - 工具定义 - 安全余量 以 GPT-4o 为例： = 128,000 - 16,384 - 500 - 550 - 1000 ≈ 109,566 Token `建议：始终预留 10%-15% 的安全余量，避免边界情况下的截断问题。
4.4 长上下文的挑战
注意力机制的复杂度
Transformer 架构的自注意力机制（Self-Attention）的计算复杂度是 O(n²)，其中 n 是序列长度。这意味着：
` 序列长度翻倍 → 计算量变为 4 倍 128K 上下文 → 计算量是 4K 的 1024 倍 `这就是为什么长上下文模型需要专门的优化技术。
注意力优化技术
1. FlashAttention 通过优化内存访问模式，将注意力的计算复杂度降低，同时减少 GPU 内存使用。
2. 滑动窗口注意力（Sliding Window Attention） Mistral 等模型采用滑动窗口注意力，每个 Token 只关注其前后的固定窗口内的 Token：
` 窗口大小 = 4096 每个 Token 只计算 4096 范围内的注意力 计算复杂度降为 O(n × w)，w 为窗口大小 `3. 稀疏注意力（Sparse Attention） 只计算部分 Token 对之间的注意力，常见的稀疏模式包括：
固定模式：每个 Token 只关注特定位置的 Token局部+全局：大部分 Token 使用局部注意力，少数 Token 使用全局注意力
4. Ring Attention 将序列分片到多个设备上，通过环形通信减少内存占用。
"Lost in the Middle" 现象
Liu et al. (2023) 的研究发现了一个重要现象：模型在长上下文中的表现不是均匀的。
` 上下文位置与模型关注度的关系： 开头 → 高关注度（Primacy Effect） 中间 → 低关注度（Lost in the Middle） 结尾 → 高关注度（Recency Effect） `这意味着：
关键信息放在开头或结尾效果更好放在中间的重要信息可能被忽略在 RAG 应用中，检索到的文档应按相关性排序
检索增强 vs 原生长上下文
方案 |
优势 |
劣势 |
|---|---|---|
原生长上下文 |
简单直接，模型有全局视野 |
计算成本高，可能遗漏中间信息 |
RAG（检索增强生成） |
成本可控，按需检索 |
依赖检索质量，可能遗漏相关信息 |
最佳实践：结合两种方案。使用 RAG 筛选相关内容，再用长上下文模型做深度推理。
4.5 实用技巧：如何高效利用上下文窗口
1. Prompt 压缩
去除冗余描述使用缩写和简洁表达结构化数据使用紧凑格式（JSON > 自然语言）
2. 上下文裁剪
对话历史只保留最近 N 轮使用摘要替代完整历史文档内容只检索相关段落
3. 多步推理
将复杂任务拆分为多步每步使用独立的上下文窗口中间结果通过变量传递
4. 分块处理
大文档分块处理每块独立推理后汇总Map-Reduce 模式
五、Token 计费：钱是怎么算的？
5.1 计费模型解析
大模型服务的计费基于 Token 数量，而非字符数或请求次数。
输入 Token vs 输出 Token：
大多数平台对输入和输出 Token 采用不同的价格：
` 输入 Token（Prompt）: 较便宜 输出 Token（Completion）: 较贵（通常贵 2-5 倍） `原因：输出 Token 需要模型进行自回归生成，计算成本更高。
计费单位：
` 通常以"每百万 Token"为单位报价 例如: $2.50 / 百万输入 Token `部分计费规则：
不足 1 个 Token 按 1 个 Token 计部分平台按 1000 Token 为单位向上取整图片、文件等会转换为等效 Token
5.2 主流平台价格对比（2026年最新）
以下价格为截至 2026 年 4 月的公开报价（以美元计价）：
OpenAI
模型 |
输入价格 |
输出价格 |
上下文窗口 |
|---|---|---|---|
GPT-4o |
$2.50/百万 |
$10.00/百万 |
128K |
GPT-4o-mini |
$0.15/百万 |
$0.60/百万 |
128K |
o1 |
$15.00/百万 |
$60.00/百万 |
200K |
o3-mini |
$1.10/百万 |
$4.40/百万 |
200K |
Anthropic
模型 |
输入价格 |
输出价格 |
上下文窗口 |
|---|---|---|---|
Claude 4 Sonnet |
$3.00/百万 |
$15.00/百万 |
200K |
Claude 4 Opus |
$15.00/百万 |
$75.00/百万 |
200K |
Claude 3.5 Haiku |
$0.25/百万 |
$1.25/百万 |
200K |
阿里云百炼（人民币）
模型 |
输入价格 |
输出价格 |
上下文窗口 |
|---|---|---|---|
Qwen-Plus |
¥0.004/千 |
¥0.012/千 |
128K |
Qwen-Max |
¥0.04/千 |
¥0.12/千 |
32K |
Qwen-Long |
¥0.0005/千 |
¥0.002/千 |
10M |
Qwen-Turbo |
¥0.002/千 |
¥0.006/千 |
128K |
注：Qwen-Long 采用特殊计费，输入价格极低，适合长文档处理。
字节跳动
模型 |
输入价格 |
输出价格 |
上下文窗口 |
|---|---|---|---|
Doubao-Pro |
¥0.0008/千 |
¥0.0020/千 |
256K |
DeepSeek-V3 |
¥0.001/千 |
¥0.002/千 |
128K |
5.3 Token 成本估算实战
场景一：日常对话
假设你与 GPT-4o 进行对话：
` 每次对话： - 输入: 500 Token（用户问题 + 少量历史） - 输出: 1000 Token（模型回复） 单次成本: - 输入: 500 × $2.50/百万 = $0.00125 - 输出: 1000 × $10.00/百万 = $0.01 - 合计: $0.01125 每天 100 次对话: - 日成本: $1.125 - 月成本: $33.75 `场景二：RAG（检索增强生成）
` 每次请求: - 系统提示: 500 Token - 检索内容: 5000 Token（约 5 个文档片段） - 用户问题: 200 Token - 模型输出: 1500 Token - 合计: 7200 Token 单次成本（GPT-4o）: - 输入: 5700 × $2.50/百万 = $0.01425 - 输出: 1500 × $10.00/百万 = $0.015 - 合计: $0.02925 每天 500 次请求: - 日成本: $14.625 - 月成本: $438.75 `场景三：批量文档处理
假设你要用 Qwen-Long 处理 1000 份合同文档：
` 每份合同: - 平均长度: 10,000 中文字 ≈ 15,000 Token - 提取输出: 500 Token 单次成本（Qwen-Long）: - 输入: 15,000 × ¥0.0005/千 = ¥0.0075 - 输出: 500 × ¥0.002/千 = ¥0.001 - 合计: ¥0.0085 1000 份合同: - 总成本: ¥8.5 `可以看到，选择合适的模型和平台，成本差异可以达到数量级。
5.3.1 常用 Token 计算工具推荐
在线工具：
- OpenAI Tokenizer
：https://platform.openai.com/tokenizer（支持 cl100k_base、p50k_base 等） - Tiktoken Web
：多个第三方在线 tiktoken 计算器
Python 库：
- tiktoken
：OpenAI 官方分词器，``pip install tiktoken - transformers
：HuggingFace 分词器，支持所有开源模型 - anthropic
：Anthropic 官方 SDK，含 Token 计数功能
CLI 工具：
` # 使用 tiktoken CLI pip install tiktoken python -c "import tiktoken; enc = tiktoken.get_encoding('cl100k_base'); print(len(enc.encode('你的文本')))" # 使用 transformers python -c "from transformers import AutoTokenizer; t = AutoTokenizer.from_pretrained('meta-llama/Llama-3-8B'); print(len(t.encode('你的文本')))" `5.4 省钱技巧
1. Prompt 压缩
` 优化前: "Please analyze the following text and provide a detailed summary of the main points, including any key arguments, supporting evidence, and conclusions that the author presents." (32 Token) 优化后: "Summarize the key points, arguments, evidence, and conclusions." (12 Token) 节省: 62.5% `2. 缓存复用（Prompt Caching）
OpenAI 和 Anthropic 都支持 Prompt 缓存：
-
重复的前缀部分可以享受折扣（通常 50% off） -
适用于系统提示固定的场景有缓存时: - 缓存命中部分: $1.25/百万（GPT-4o 输入价的一半） - 未命中部分: 正常价格
3. 模型选择策略
` 任务分级: - 简单问答、分类 → GPT-4o-mini / Claude Haiku - 一般对话、摘要 → GPT-4o / Claude Sonnet - 复杂推理、代码 → o3-mini / Claude 4 Opus - 长文档 → Qwen-Long / GPT-4o（视成本而定） `4. 混合调用策略
` RAG Pipeline 优化: 1. 使用廉价模型做初步筛选（GPT-4o-mini） 2. 使用昂贵模型做深度推理（GPT-4o / o1） 成本对比: - 全用 GPT-4o: $0.029/次 - 混合策略: $0.008/次（节省 72%） `5. 中文场景选择国产模型
处理中文内容时，国产模型通常有显著的成本优势：
` 同样处理 10,000 Token 中文: - GPT-4o: $0.025（输入）+ $0.10（输出）= $0.125 - Qwen-Plus: ¥0.04（输入）+ ¥0.12（输出）≈ $0.022 - DeepSeek-V3: ¥0.01（输入）+ ¥0.02（输出）≈ $0.0045 `选择 DeepSeek-V3 可以节省约 96% 的成本。
六、Token 与模型能力的关系
6.1 Token 数量 vs 理解深度
更多的 Token 并不总是意味着更好的理解。关键因素包括：
信息密度：
1000 个 Token 的高质量技术文档 > 10000 个 Token 的冗余内容精炼的 prompt 比冗长的描述更有效
上下文质量：
"Lost in the Middle" 效应意味着中间部分的信息利用率较低重要信息应放在开头或结尾
6.2 上下文长度与推理能力的权衡
长上下文模型虽然在处理大量信息方面有优势，但也存在权衡：
维度 |
短上下文（4K-8K） |
长上下文（128K+） |
|---|---|---|
推理精度 |
高 |
可能降低 |
响应速度 |
快 |
较慢 |
成本 |
低 |
高 |
适用场景 |
对话、简单任务 |
文档分析、RAG |
6.3 Token 效率对应用架构的影响
架构设计时需要考虑：
- Token 预算
：为每个功能模块设定 Token 预算 - 降级策略
：Token 超限时如何优雅降级 - 流式输出
：长输出使用 SSE 流式传输，避免超时 - 分块策略
：大任务拆分为小任务，独立管理上下文 - 成本监控
：实时监控 Token 消耗，设置告警阈值
七、总结与展望
核心要点回顾
- Token 是子词单位
，不是字符也不是单词，由分词器的词汇表决定 - 不同模型的分词效率差异显著
，特别是中文场景，选择合适模型可以节省大量成本 - 上下文窗口 ≠ 可用空间
，需要扣除系统提示、工具定义等占用 - 输入和输出 Token 价格不同
，输出通常贵 2-5 倍 - 长上下文存在"Lost in the Middle"效应
，重要信息应放在开头或结尾 - 选择合适的模型和平台
，中文场景国产模型有显著成本优势
Token 机制的未来演进
- 字符级模型
：一些研究正在探索直接使用字符作为输入单位，避免分词带来的信息损失 - 动态分词
：根据任务类型动态选择分词策略 - Token 压缩
：通过语义压缩减少上下文中的冗余 Token - 统一 Token 标准
：行业可能趋向于统一的 Token 计算标准
对开发者的建议
- 理解你使用的模型的分词器
，用它来优化 prompt - 在本地安装对应的分词工具
（如 tiktoken），准确计算 Token 消耗 - 设计应用时预留 Token 预算
，避免上下文溢出 - 选择合适的模型
，不必盲目追求最强模型 - 关注成本优化
，特别是在生产环境中大规模使用时 - 中文场景优先考虑国产模型
，分词效率和成本都有优势