印度语用户交的"分词税"：等效内容多花 8 倍 Token，马来雅拉姆语上下文直接缩到 12%

用 GPT-4 处理非英语内容时，同样的意思，中文、日语或印地语好像比英语多吃了不少 token。不是错觉。最近 arXiv 上挂了一篇论文，专门把这件事量化了——对象是印度语言，数据用 FLORES-200 平行语料库，测了 6 种常见 tokenizer 在 14 种印度语言上的表现。

在 cl100k_base——也就是 GPT-3.5 和 GPT-4 用的那个 tokenizer——下面，印度语言平均要比英语多花 8.0 倍的 token，才能表达同样的语义内容。最极端的马来雅拉姆语（Malayalam），达到了 13.0 倍。英语用户用 4096 token 能读完的一段话，马来雅拉姆语用户的实际可用上下文窗口只剩 12% 左右。付一样的推理成本，买到的是一个大幅缩水的有效容量。

论文把这叫作 "Tokenizer Tax"，分词税。

根因出在 byte-pair merging（BPE）上。这些 tokenizer 的训练语料以英语为绝对主体，遇到印度语言里常见的字符序列，合并步骤经常失败——结果就是一个字符一个字符地碎成单字节 token。论文算了一笔账，合并失败率与分词税之间的相关系数达到 Pearson r = 0.89，几乎就是因果关系。

但论文明确说了，这不是印度文字本身有什么问题。换用专门设计的多语言 tokenizer——比如 XLM-R 或者 OpenAI 后来的 o200k_base——印度语言的平均分词税能降 73%。这完全是可以修的设计问题，很多主流模型默认没修。

放到实际场景里，这笔税的后果很具体。论文做了一个对比：在固定上下文预算下，印度语言文档能保留的原始内容远少于英语文档。往 prompt 里塞同一份材料，英语能塞进去的，印度语可能只塞进去不到一半。对于那些跑 RAG 管道、做多语言客服、或者批量处理非英语文档的团队来说，这不只是多花点钱——效果直接打折，有些场景根本用不好。

论文还顺带看了一眼分词税和阅读理解表现（Belebele 基准）的关系。结论是表面上的相关主要由语言资源的丰富程度解释，而不是分词器本身的行为。一个语言在基准上表现差，更多是因为训练数据里它本来就少，而不只是 tokenizer 多吞了几个 token。

这篇论文不长，核心结论也不算复杂——它把很多人隐约感觉到、但没人认真算过账的隐性成本亮了出来。方向也很明确：多语言 tokenizer 不是可选项。英语主导的 tokenizer 处理非英语语言时，持续交税，税额取决于语言离英语有多远——这份论文就是那张税单。