一个汉字到底算几个 token？

因模型而异，且同一个汉字在不同语境下 token 数也可能不同。GPT-4 / Claude 的分词器对常用汉字大约 1-2 个 token，生僻字 3 个。拿 "苹果" 举例：GPT-4 是 3 个 token（苹 2 + 果 1），Claude 约 2 个。准确数字请把文本贴进 tokenizer 工具实测。

为什么有时候增加一个字符 token 数反而减少？

BPE 分词器会把常见组合合成一个 token。比如 "the" 是 1 个 token，但 "th" + "e" 分别是 2 个；"苹果" 可能合成 1 个 token，但单独 "苹" 是 2 个。所以加字符有时能触发合并、token 反而减少——这也是为何 prompt 微调时 token 数的变化不完全是线性的。

输入和输出的 token 价格为什么不一样？

因为成本结构不同。输入可以批量并行 prefill，GPU 利用率高、延迟低；输出必须自回归逐 token 生成，串行且每一步都要跑完整个模型，单 token 成本是输入的 3-5 倍。长 prompt 短回答的任务便宜，长回答的任务贵——算成本要分别估算。

上下文窗口 128k 是指字符还是 token？

token。英文 1 token ≈ 0.75 词 ≈ 4 字符；中文 1 token ≈ 1-2 字符。128k token 装英文约 10 万词（一本短篇小说），中文约 8-12 万字。贴大段代码前先用 tokenizer 估一下——JSON、XML、多语言混排往往比纯文本更占 token。

LLM Tokenizer 原理：为什么中文输入比英文贵一倍

调 LLM API 账单上涨，先检查 prompt 长度。同样的语义，中文输入往往比英文贵 60-100%——这不是定价歧视，是分词器天生结构不同。理解 tokenizer 能显著降低 token 成本。

Token 是什么

LLM 不按字符处理文本，而是按 token。一个 token 可能是：

一个完整单词 apple
一个词根 + 后缀 run ning
一个字节对 qu ick
一个汉字 苹
一个标点 .
一个空格

模型的上下文窗口、推理算力、API 计费都以 token 计。

BPE：主流模型的分词算法

GPT、Claude、LLaMA 都用 BPE（Byte Pair Encoding）的变体：

把文本切成字节（UTF-8）
统计最常一起出现的字节对
合并成新 token
反复迭代，直到词表填满（通常 5 万-20 万）

英文语料丰富，很多常见词整体就是一个 token：the、ing、tion 都是高频合并结果。

中文在训练语料中占比更少，加上每个汉字用 UTF-8 占 3 字节——单字符本身就可能切成 2-3 个 token。常用字如”的”、“是”在大型中文模型里能压成 1 个 token；生僻字基本就是 3 个字节 3 个 token。

英文 vs 中文的 token 密度

拿”Hello world”和”你好世界”对比（GPT-4 分词器）：

文本	字符数	token 数	token/字符
`Hello world`	11	2	0.18
`你好世界`	4	6	1.50

密度差 8 倍。同样 1000 字符的内容，中文 token 数是英文的 2-3 倍，成本也是 2-3 倍。

哪些内容特别”烧 token”

Emoji

🎉 占 3-5 个 token（取决于是不是组合 emoji）。一串 🎉🎉🎉 看起来是 3 个字符，实际可能 15 个 token。

家庭 emoji / 肤色修饰

👨‍👩‍👧‍👦 是用零宽连接符（U+200D）拼起来的：👨 + ZWJ + 👩 + ZWJ + 👧 + ZWJ + 👦，5-11 个 token。

生僻汉字

现代汉语 3000 常用字在词表里压得较紧；扩展区汉字（古字、繁体罕用字、部分地名用字）每字 3 token 起。

代码里的缩进

Python 代码每行 4 空格缩进，4 连续空格在 GPT-4 里是 1 个 token；但如果缩进混用（有的 2 空格有的 4），会破坏合并规律，token 数翻倍。

JSON 结构

{"key":"value"} 看起来紧凑，其实 {"、":、","、"} 这些分隔符片段都被切成独立 token。同样数据用 YAML 或 CSV 往往更省。

URL

长 query string 几乎每几个字符一个 token——URL 编码的 %E5%BC%A0 这种完全无合并空间。

哪些场景 token 数反直觉

加字符反而减少 token

text: "app"    → 1 token
text: "apple"  → 1 token  ← 加了两个字母还是 1 个

因为 apple 在词表里是一个整体 token。反之 appl 会被切成 app + l 共 2 个。

替换同义词省 token

"please note that"  → 3 tokens
"note that"         → 2 tokens
"Note:"             → 2 tokens

prompt 里反复出现的客套话是 token 杀手，用简洁的命令式能省一大把。

数字越长越贵

数字在 BPE 里很难压缩。2026 是 2 个 token（20 + 26），2026-04-23 是 5 个 token。日志里的时间戳、UUID、哈希值都是 token 大户。

降 token 成本的 6 个招

prompt 写英文，输出要求中文——输入便宜，输出按模型决定
压 system prompt：常见模板都藏着一堆客套话（“you are a helpful assistant…”），能删就删
结构化数据用 CSV / TSV，别用 JSON
代码缩进用 Tab，合并更友好
长文档先 RAG 召回，别整篇塞进 context
避免 emoji 和 markdown 装饰，生产场景没必要

怎么准确数 token

不同模型的词表不同，同一段文本 token 数不同：

模型	分词器	中文”苹果”token 数
GPT-4	`cl100k_base`	3
GPT-4o	`o200k_base`	2
Claude 3/4	专有	约 2
Gemini	专有	约 2
LLaMA 3	`tiktoken`-like	4-5

不要拿一个模型的计数估另一个。API 返回的 usage.prompt_tokens 是权威。

上下文窗口的真实容量

宣传 “128k context” 听起来很大，但：

英文：约 10 万词（≈ 200 页书）
中文：约 8-12 万字（≈ 一本短篇集）
代码：约 2-3 万行（取决于语言和缩进）
JSON / 日志：约 5-8 万行

嵌入大段代码前先实测一下——128k 没看起来那么大。

费用怎么估

粗略公式：

费用 = 输入 tokens × 输入单价 + 输出 tokens × 输出单价

以 Claude Opus 为例（假设 $15/M 输入、$75/M 输出）：

一条 5k 输入 / 1k 输出的对话 ≈ $0.15
一个 100 次对话的客服日志 ≈ $15
给全公司 500 人用一天 ≈ $75 × 5 = $375

输出单价是输入的 5 倍，控制输出长度比控制输入更重要。

分词可视化

把文本粘进工具，按 token 边界着色——一眼看到”这一段每个 token 多少字符”、“emoji 吃掉了几个”、“system prompt 里哪些客套话在烧钱”。支持 GPT / Claude / Gemini 多模型切换，费用按官方单价实时估算，本地运行不上传。