你的语言被多收了税：为什么中文在语言模型里天生吃亏

一个看不见的税

假设你和一个英文母语者同时学同一种语言模型。你们喂给它同样多的训练算力，同样长的训练时间，同样的架构。唯一不同的是——你喂的是中文，他喂的是英文。

结果呢？英文模型每个字符的预测准确率，可能就是比你高。

这不是因为中文难学，也不是因为模型偏心。而是因为一个你几乎从未想过的问题：UTF-8 编码本身，就在对中文收税。

一篇刚出炉的论文《When does text encoding matter for language modeling?》（arXiv: 2611.14459，Northeastern University & EleutherAI，2026 年 11 月 10 日）系统性地把这件事拆开看了。结论比预想的更复杂，也更有意思。

UTF-8：一个为英文量身定制的方案

先回忆一下 UTF-8 是什么。它是目前互联网上最通用的字符编码标准，把每个字符编码成 1 到 4 个字节。

关键在于"1 到 4"这个范围。

• 基本拉丁字母（a-z, A-Z, 0-9）占 Unicode 早期码点，1 个字节搞定。
• 西里尔字母（俄文等）在 U+0400–U+04FF，2 个字节。
• 泰米尔语在 U+0B80–U+0BFF，3 个字节。
• 中文、日文汉字，3 个字节。

这意味着：同样写一个"Hello"，英文花 5 个字节。同样写一个"你好"，中文花 6 个字节。

更狠的是，UTF-8 的两字节序列最多只能表示 1,920 个码点——这对中文这种大字符集根本不够用，所以中文只能被推到三字节区。

论文作者 Eugene Jang、Catherine Arnett 和 Terra Blevins 把这种现象叫做 "byte premium"——字节溢价。你的语言字符在 Unicode 里的位置越靠后，你为同样信息付出的字节代价就越高。

在语言模型的世界里，这意味着：同样一段语义内容，中文的序列长度比英文长得多。模型要预测的 token 更多，训练更费力，BPC（bits per character）更高。

Aether：一个"因地制宜"的编码方案

为了搞清楚编码选择到底有多大影响，作者提出了 Aether——一种混合编码方案。

核心思路很简单：不同语言用不同的编码，但保留 UTF-8 作为兜底。

具体来说：

• 对目标语言，设计一种"脚本特定编码"（script-specific encoding），让这种语言的字符尽可能用更少的字节表示。
• 对所有非目标字符，回退到标准 UTF-8。

这样既压缩了目标语言的字节成本，又保留了完整的 Unicode 覆盖——不会出现某些字符编码不了的问题。

作者用 Aether 框架测试了四种书写系统差异极大的语言：中文、韩文、格鲁吉亚文、泰米尔文。

出乎意料的结果：有些语言在乎，有些不在乎

实验结果分成了截然不同的两组：

第一组：中文和韩文——编码选择影响巨大。

这两种语言的字符"信息密度高"——每个字符本身承载的语义信息很多。对它们来说，更压缩的编码（让每个字符用更少字节）带来了显著的性能提升。模型用同样的算力学到的东西更多，BPC 更低。

第二组：格鲁吉亚文和泰米尔文——编码选择几乎没影响。

这两种语言的字符"信息密度低"——单个字符承载的信息少，需要多个字符组合才能表达完整语义。对它们来说，即使编码的压缩率差了 7 到 8 倍，模型性能也几乎不变。

这个结果为什么反直觉？因为直觉上你会觉得"压缩率越高越好"。但论文揭示了一个更深层的规律：编码选择的影响，取决于字符本身的信息密度。

为什么会这样？一个类比

想象你在搬家。

中文像是一个个塞得满满的箱子——每个箱子里装了很多东西，箱子的"信息密度"高。这时候箱子的体积（字节长度）就很关键。如果你能把箱子做得更小（压缩编码），同样一辆卡车能运更多东西。

格鲁吉亚文和泰米尔文像是一堆只装了一两件东西的箱子——每个箱子本身没装多少。这时候箱子大一点小一点无所谓，因为瓶颈不在箱子体积，而在你拆箱、整理、组合这些东西的时间。

换句话说：当字符本身是"信息单元"时，编码效率很重要；当字符只是"零件"时，编码效率无所谓。

这意味着什么

这篇论文的深层含义比"换个编码"要大得多。

第一，语言模型领域存在系统性的跨语言不平等。 这不是某个模型的 bug，而是整个技术栈的默认选择造成的。UTF-8 是为英文设计的——它让英文用 1 字节，让中文用 3 字节。这个"税"从底层就开始收了，上层再怎么调都绕不开。

第二，"一刀切"的编码方案是错的。 论文的核心主张是：文本编码应该是一个语言特定的设计决策，而不是一个被默认接受的通用标准。不同语言的书写系统差异极大，强行用同一套编码方案，就是在让某些语言天生吃亏。

第三，这解释了为什么字节级模型在多语言场景下表现不稳定。 之前人们把字节级模型的多语言性能差异归结为"训练数据不够"或"模型容量不足"。这篇论文指出了另一个嫌疑犯：编码本身就在制造不平等。

更大的图景：默认值的力量

这篇论文让我想到一个更普遍的现象：系统里的默认值，往往是最隐蔽的偏见。

UTF-8 在 1993 年被设计出来时，主要考虑的是和 ASCII 的兼容性——让英文世界不需要做任何改动就能迁移。这个设计目标完美达成了，但代价是：所有非拉丁语系的语言，都不得不为这个兼容性买单。

类似的现象在技术世界里随处可见：

• QWERTY 键盘布局是为了防止打字机卡键设计的，现在卡键问题早不存在了，但布局还在。
• RGB 色彩空间是为 CRT 显示器设计的，OLED 时代还在用。
• 512 字节的磁盘扇区大小用了几十年，直到 4K 扇区出现。

每一个"默认值"都有它被设计时的合理性，但当世界变了，默认值就成了拖累。

UTF-8 的字节税，是语言模型时代第一次系统地暴露这个问题。之前不是不存在，而是没人认真去量它。这篇论文量了，结果发现：这个税，比想象的重，但收税的方式，比想象的微妙。

一个未解的问题

论文最后留了一个开放问题：这些结论是否适用于 subword tokenizer（比如 BPE）？

BPE 是目前主流大模型（GPT、LLaMA、Claude）都在用的分词方式。它不直接在字节层面工作，而是把高频字节序列合并成 token。理论上，BPE 可以"消化"掉一部分编码不平等——如果"你"这个字出现频率高，它会被合并成一个单独的 token，不管底层是 3 字节还是 2 字节。

但实际上，BPE 的词表大小有限（通常 3-10 万），高频的英文 token 会占掉大量位置，低频的非拉丁语系 token 被挤压。这就是为什么 GPT-4 的中文 token 效率仍然比英文低——BPE 缓解了字节税，但没有消除它。

Aether 的思路——语言特定的编码——是否能延伸到 subword 层面？这是一个值得期待的方向。

结语

技术世界里最深的偏见，往往藏在最底层。UTF-8 不是恶意的，它只是 1993 年的一个工程妥协。但这个妥协的后果，在 30 年后的语言模型时代才被充分暴露。

这篇论文做了一件很简单但很重要的事：把一个被默认接受的参数，变成了一个需要被审视的设计选择。

中文在语言模型里天生吃亏这件事，不是命运，是工程。是工程，就可以改。

论文链接： https://arxiv.org/abs/2611.14459

开源代码： https://github.com/genesith/AetherModels

作者： Eugene Jang, Catherine Arnett, Terra Blevins (Northeastern University / EleutherAI)