一个 Token 是多少汉字？1M 上下文是多少字？换算表 + 切词原理
直接给答案：中文约 1.9 token 一个字，也就是 1 个 token 约半个汉字；1M token 的上下文大约装得下 52 万汉字或 77 万英文单词。这篇给你一张可以直接抄的换算表，再讲清楚为什么是这个数。
「一个 Token 是多少汉字？」直接给答案：中文约 1.9 个 token 一个字，倒过来就是 1 个 token 约等于半个汉字；英文约 1.3 个 token 一个单词。所以模型说的「1M 上下文」大约装得下 52 万汉字，或 77 万英文单词。
一张换算表，可以直接抄走：
| Token 数 | ≈ 中文 | ≈ 英文 |
|---|---|---|
| 1K | 530 字 | 770 词 |
| 20K | 1 万字 | 1.5 万词 |
| 100K | 5.3 万字 | 7.7 万词 |
| 200K | 10.5 万字 | 15 万词 |
| 1M | 52 万字 | 77 万词 |
下面讲这个系数是怎么来的——顺便说下为什么网上常见的「1 token = 4 个字符」「1 token = 0.75 个英文单词」不能用：那是 OpenAI 在 2023 年给的粗略估算，对当代切词器（GPT-5 系列、Claude 5 系列）误差不小。
Token 是子词单元，不是字也不是单词
模型不直接看你的字符。它看的是切词器（tokenizer）切出来的 ID 序列。切词器是一个把文本切成最优子词单元的算法，主流方案叫 BPE（Byte Pair Encoding）。
BPE 的核心思想是：高频出现的字符组合合并成一个 Token，低频的拆开。这就解释了为什么：
the是 1 个 Token（高频）theology是 2 个 Token（拆成the、ology）qzxabc可能是 4-5 个 Token（极低频，几乎逐字符切）
中文情况差不多。常见汉字一字一 Token，生僻字可能要拆成 UTF-8 字节再合并，于是一个字占 2-3 个 Token。
实测几个具体例子
我用 OpenAI 的 tiktoken（cl100k_base，GPT-4 / GPT-5 系列用的切词器）和 Anthropic 的切词器分别跑了一遍，结果差不多：
| 输入 | OpenAI tokens | Anthropic tokens |
|---|---|---|
Hello |
1 | 1 |
Hello, world! |
4 | 4 |
Hello, world! 重复 100 次 |
约 400 | 约 400 |
helloworld（连写） |
3 | 3 |
| 「你好」 | 2 | 2 |
| 「你好世界」 | 4 | 4 |
| 「写一个排序算法」 | 8 | 8 |
| 「龘靐齉龖」（生僻字） | 12 | 12 |
| 一段 1000 字的中文段落 | 约 1900 | 约 1900 |
| 一段 1000 字（英文 word 计数）的英文段落 | 约 1300 | 约 1300 |
几个关键观察：
英文：约 1.3 个 Token / 单词，约 0.25 个 Token / 字符。 写得越普通、越口语，Token 数越接近字符数 / 4。代码、缩写、连写词会让密度变高。
中文：约 1.9 个 Token / 字。 几乎可以粗算「Token 数 ≈ 中文字数 × 2」。这意味着同样意思的一句话，中文消耗大概是英文的 1.5 倍。
代码：偏紧凑。 因为变量名往往是高频英文 subword 的组合，500 行 TypeScript 大概是 5000-7000 Token。
JSON：偏松散。 因为引号、冒号、缩进都是 Token，大量短键值对的 JSON 比同样信息量的 yaml 贵 30% 左右。
为什么这件事对账单影响大
如果你的 Prompt 是 1000 个英文单词，按上面数字大概是 1300 Token。同样意思用中文写大概要 1900 Token。差 600 Token——按 Claude Sonnet 输入价 3 美元 / 百万计算，单次差 0.18 美分。
听上去微不足道，但 Claude Code 这种工具一天可能跑几百次模型调用，每次都包含一份完整的系统提示。如果你能把系统提示从中文改成英文（或者反过来），一个月下来可能省一两百块。
更现实的影响在 Agent 类工具上。Codex CLI 这种 Agent 在一次任务里可能调用模型 100 次以上，每次都把整个上下文发回去。上下文里如果有大段中文项目说明、AGENTS.md 之类的文件，就会被重复发送 100 次——这部分 Token 会被反复计费（虽然有缓存，但不是 100% 命中）。
我自己的项目里有一份 5000 字的中文项目背景说明，这意味着每次 Codex 调用都要扛 9500 个输入 Token 的开销。
具体场景的省字诀
如果你想知道自己项目里最烧 Token 的字段是哪些——
中文长文档、长代码注释、长报错消息、大块 JSON 配置，这四种是最常见的"Token 黑洞"。前两者你能控制，后两者很多时候是工具决定的（比如 Claude Code 本身就会把 git 状态、文件树这些塞进上下文）。
具体每个项目消耗大头在哪，打开 Vibe Usage 按项目看 Token 分布——你装一下就知道了。它能精确到每个项目、每天烧了多少 Token，哪些项目突然冒尖一目了然。
我自己的发现是：那个我以为是"小项目"的 README 仓库，因为有一份 8000 字的中文 README 和大量重复打开关闭的 session，居然占了我一个月消耗的 35%。看到这个数字之后我立刻把 README 拆成了多份文件，按需引用。
怎么估自己的 Token 数
最简单的离线估算法：
- 中文：字数 × 2
- 英文：单词数 × 1.3
- 中英混排：字符数 × 0.5
更准的办法是用 tiktoken playground 把你的实际 Prompt 粘进去，看真实切词结果。
但说实话——「一个 token 多少汉字」这种换算做得再熟，你还是不知道自己一天总共烧了多少。最后还是要靠工具汇总。我个人从手工估算到 用 Vibe Usage 看真实消耗 之间隔了大半年，多花了不少冤枉钱。早装早安心。