Claude 的 200K 是 token 不是 KB

1. 一个常见的直觉
2. Token 和字节不是一回事
3. 实际换算
   1. 英文为主的文档
   2. 中文为主的文档
4. 真正吃窗口的是什么
5. 速查表
6. 结论

一个常见的直觉

如果 fetch 到一个 150KB 的文档，且全都读进来，那 Claude 200K 的窗口是不是只剩不到 1/4 了？

听起来很合理——150K 占 200K，不就是 75% 吗？

但这里混淆了两个单位：Claude 的 200K 是 200,000 个 token，不是 200KB 字节。

Token 和字节不是一回事

概念	单位	含义
文件大小	字节（Byte）	磁盘上占多少空间
上下文窗口	token	模型能”看到”多少文本片段

token 是模型自己的文本切分单位，粒度介于字符和单词之间。对不同语言，一个 token 对应的字节数差异很大。

实际换算

英文为主的文档

英文 tokenizer 大约 1 token ≈ 4 字节（约 3-4 个字符）。

150KB 文件
= 150,000 字节
÷ 4 字节/token
≈ 37,500 token

37,500 / 200,000 = 18.75%，远不到 3/4。

中文为主的文档

中文 UTF-8 编码每个汉字占 3 字节，而 tokenizer 通常 1 个汉字 ≈ 1~2 token。

150KB 文件
= 150,000 字节
÷ 3 字节/汉字
≈ 50,000 个汉字
× 1~2 token/汉字
≈ 50,000 ~ 100,000 token

即使按最坏情况 100,000 token 算，也只占 200K 窗口的 50%，仍然不到 3/4。

真正吃窗口的是什么

单次读一个 150KB 文件并不可怕。真正容易撑满上下文窗口的是长对话中的累积：

• 反复读取多个大文件
• 大段粘贴代码和日志
• 多轮对话中的历史消息堆叠

不过现代 LLM 工具链通常会自动压缩早期消息来缓解这个问题。而且部分模型提供更大的窗口——比如 Claude Opus 有 1M token 的版本，空间更加充裕。

速查表

文件大小	英文 token 数	中文 token 数	占 200K 窗口
50KB	~12,500	~17K–33K	6%–17%
150KB	~37,500	~50K–100K	19%–50%
500KB	~125,000	~167K–333K	63%–167%

可以看到，英文文档要到 500KB 以上才会真正逼近 200K token 的上限；中文文档因为 token 效率较低，大约 300KB 左右开始吃紧。

结论

200K context window ≠ 200KB。 前者是 token 数，后者是字节数，两者差了大约 2~4 倍。一个 150KB 的文档通常只占窗口的 19%~50%，完全不用担心。