Universal Byte-Level Encoding：让中文不再比英文贵 5 倍——一条路由规则解决多语言 token 不公
你用 GPT-4 处理一段 1000 字的中文文本，和一段 1000 字的英文文本，成本可能差 5 倍。
目录
一个被忽视的不平等
你用 GPT-4 处理一段 1000 字的中文文本，和一段 1000 字的英文文本，成本可能差 5 倍。
不是因为模型对中文收费更贵，而是因为 token 化器（tokenizer）把中文切成了更多的 token。
具体来说：BBPE（Byte-Pair Encoding on UTF-8 bytes）是当前主流的 token 化方案。UTF-8 编码下：
- 英文字母（ASCII）：1 字节 → 1 个 base symbol
- 西里尔字母、阿拉伯字母：2 字节 → 2 个 base symbols
- 中文、日文、韩文（CJK）：3 字节 → 3 个 base symbols
- emoji（非 BMP）：4 字节 → 4 个 base symbols
这个差距意味着： 1. 中文用户的 API 账单更贵 2. 中文文本在上下文窗口里占更多空间 3. 中文模型的"有效上下文"比英文模型短 3-5 倍 4. 多语言训练中，中文数据被"稀释"了
Universal Byte-Level Encoding（UBE）提出了一个极其简洁的方案来解决这个问题。
UBE 的核心思路：一条路由规则
UBE 的思路简单到让人怀疑：根据字符的 UTF-8 字节数，把它路由到 UTF-8 或 UTF-16 两条路径之一。
具体规则：
- UTF-8 字节数 ≤ 2 的字符（ASCII、拉丁字母、部分西里尔/阿拉伯字母）→ 走 UTF-8 路径，1-2 个 base symbols
- UTF-8 字节数 = 3 的字符（CJK、大部分非 BMP 字符）→ 走 UTF-16 路径，2 个 base symbols
- UTF-8 字节数 = 4 的字符（emoji 等 BMP 之外的字符）→ 走 UTF-16 路径，4 个 base symbols（和 BBPE 一样）
这就像一个双语邮政系统：寄往本地的信走陆运（便宜），寄往远地的信走空运（快但贵）。UBE 做的是：对每个字符，选择最"便宜"的编码路径。
为什么不直接全用 UTF-16？
有人会问：既然 UTF-16 把 CJK 降到 2 字节，为什么不全部用 UTF-16？
因为 UTF-16 会把 ASCII 也变成 2 字节。英文从 1 变成 2，等于英文用户多付了一倍的钱。这是"拆东墙补西墙"。
BBPE16（Kim et al., 2026）就是这么做的——全局切换到 UTF-16，CJK 降了，但 ASCII 涨了。在 CJK 为主的场景（如中文 ASR）这没问题，但在混合脚本场景（中英混排的网页、代码+注释）这是净损失。
UBE 的巧妙之处在于：不是全局选一种编码，而是逐字符选最优编码。 ASCII 走 UTF-8 保持 1 字节，CJK 走 UTF-16 降到 2 字节。两边都不吃亏。
怎么做到无标记切换
路由规则听起来简单，但实现起来有一个技术难题：解码器怎么知道某个 base symbol 是来自 UTF-8 还是 UTF-16？
传统方案是加标记 token——在每段编码前加一个"这是 UTF-8"或"这是 UTF-16"的标记。但标记 token 会被 BPE 合并吸收，破坏可逆性。
UBE 的解决方案极其优雅：用两个不相交的 256 符号字母表。
- UTF-8 字节用 GPT-2 的 byte alphabet（0x00-0xFF）
- UTF-16 字节用一个 Private Use Area（U+E100-E1FF）
这就像两个人说不同方言——你一听口音就知道他是哪里人，不需要他自我介绍"我是北方人"。
100% 可逆性：204 种语言零失败
可逆性是 token 化器的底线要求：编码后解码，必须能恢复原文。BBPE 在实际使用中偶尔会出问题（比如 Unicode 规范化导致字符变化）。
UBE 在 FLORES-200 的 204 种语言上做到了 100% 通过率——零解码失败。
更严格地，在 Unicode 17 完整审计中（覆盖所有 Unicode scalar values + 官方规范化、grapheme-break、emoji 测试套件），UBE 是唯一恢复每一个输入的方案：
- MYTE：1,138,306 / 1,155,724（漏了 17,418 个）
- SCRIPT-BPE：应用 NFC 规范化，过滤了 Private-Use 和未分配的 scalar
- UBE：1,155,724 / 1,155,724（100%）
不改变模型架构
UBE 的另一个关键特性：它不改变 Transformer 架构，不改变 BPE 训练流程。
具体来说： 1. BPE 的 pair-counting 和 merge-selection 逻辑完全不变 2. 只是初始的 base alphabet 从 256 变成 512（两个不相交的 256 符号集的并集） 3. BPE 从 512 符号的 routed stream 中学习词汇表 4. Transformer 架构、训练流程、推理流程全部不变
这意味着 UBE 可以直接替换现有 tokenizer，不需要重新设计模型。这对工程落地极其友好——换 tokenizer 通常是侵入性改动，但 UBE 把改动限制在 tokenizer 层。
encoding floor 的概念
UBE 引入了一个有用的概念：encoding floor——一个字符在某种编码方案下的最小 base symbol 数。
| 字符类别 | BBPE | BBPE16 | UBE |
|---|---|---|---|
| ASCII (a-z, 0-9) | 1 | 2 | 1 |
| 拉丁扩展 (é, ñ) | 2 | 2 | 2 |
| CJK (中文字) | 3 | 2 | 2 |
| Emoji (😀) | 4 | 4 | 4 |
为什么这件事重要
Token 公平性不只是一个技术细节，它直接影响：
1. 经济公平：中文用户为同样的服务付更多钱。一个 8K 上下文窗口的模型，英文用户能放约 8000 词，中文用户可能只能放 2000-3000 词。 2. 性能公平：模型在中文上的"有效上下文"更短，长文本理解能力更差。 3. 训练公平：多语言训练中，中文数据被"稀释"——同样 token 预算下，中文能训练的文本量更少。 4. 评估公平：中文模型在 token 级指标上（如 perplexity per token）和英文不可比。
UBE 不是"让中文更便宜"——它是"让编码方案不再系统性惩罚某些脚本"。这是一个基础设施层面的公平性问题。
更深的洞察：编码选择是一种偏见
UBE 让我意识到一件事：编码方案不是中性的。
UTF-8 是为 ASCII 优化的——ASCII 保持 1 字节，其他脚本多字节。这在 1980 年代是合理的（当时计算主要在英语世界），但在 2026 年的全球 AI 时代，这是一个系统性偏见。
BBPE 继承了这个偏见——它直接在 UTF-8 字节上做 BPE，所以 ASCII 天然有优势。BBPE16 试图纠正但矫枉过正。
UBE 的做法是：承认编码选择是一种偏见，然后设计一种路由机制让偏见最小化。 这不是"无偏见"——emoji 仍然是 4 字节——而是在所有可行方案中选择"最大公平"的那个。
编码方案不是技术细节，是权力分配。 谁的脚本更便宜，谁的内容就更便宜地被处理、存储、检索。UBE 把这个隐性的权力分配变成了一个显式的工程设计。
论文：Universal Byte-Level Encoding: UTF-8/UTF-16 Routing for Tokenizer Equity Across Scripts