同一个问题，用英文问和用中文问，烧掉的 token 数可能差两三倍。这不是模型偏心，而是 tokenizer 的偏置直接写进了计费单。对一个英文网页占比七成的训练语料，BPE 学到的合并天然偏英文；中文用户为一个字付的 token，英文用户能换三四个字符。本文量化这个差距，再看大词表怎么把它填平，以及填平的代价。
差距从哪来：UTF-8 的字节税
根源在 UTF-8 的编码效率上。英文字母占 1 字节，常用汉字占 3 字节，韩文音节也是 3 字节，泰文 3 字节。byte-level BPE 从字节起步，词表里又没学到足够的 CJK 合并条目时，一个汉字最坏要 3 个 token（三个字节各自独立），而英文平均 3–4 个字符才 1 个 token——单位信息量的 token 成本差了约 10 倍。即使词表学到了常用汉字整块合并，生僻字、专业术语、人名仍按字节碎开。
这个差距不会被"模型变强"抹平，它是输入编码层的结构性事实。模型能力再强，鱻 这个字该占几个 token 还是 tokenizer 说了算。
三笔连锁账
第一笔：推理计费。 API 按 token 收费，同样的语义内容，中文比英文多付 2–3 倍是常态。粗略量级：一段英文网页约 4 字符/token，一段中文在 32k 英文向词表下约 1.2 字符/token，在 150k 大词表下能到 1.5–2 字符/token。把对话系统的 prompt 从英文翻译成中文，账单立涨——很多产品层的"中文比英文贵"困惑，答案在这一层。
第二笔：上下文长度。 4096 token 的窗口，英文能装约 1.6 万字符，中文在烂词表下只能装 5000 字左右。"支持 128k 上下文"对不同语言是有折扣的，折扣率由词表决定。长文摘要、合同分析这类场景，中文用户实际能喂进去的文本量打了几折，值得在产品设计时算清楚。
第三笔：训练充分性。 词表条目是嵌入矩阵的行，每行要被语料喂到足够次数才能学出像样的表示。CJK 条目在英文主导语料里出现频率低，训练后期它们的嵌入仍带随机初始化痕迹——表现为模型对中文低频词、专业术语的"认识模糊"。加大中文语料比例能缓解，但反过来又稀释英文能力，这是配比层面的权衡，不是词表层面能独力解决的。
大词表怎么填平
路线很直白：把训练语料的语种配比做得足够均衡，让 BPE 在中文、韩文、泰文上学到和英文同等密度的合并条目，用 $V$ 换压缩率。Qwen2.5 的 152k 词表里 CJK 条目占大头，DeepSeek 和 Yi 同样走高词表路线；英文为主的模型（LLaMA 早期 32k、Mistral 32k）则在多语言上明吃亏。词表条目数就是语言公平性的预算，这句话在工程上几乎是字面意义。
但预算不是免费的。条目越多，尾部越长的低频次嵌入（3050 算过 $2Vd$ 的参数账）；条目分布越广，每个语种的平均训练样本越少。实证上一个经验阈值：当某语种的 token 覆盖率（该语种文本被词表条目覆盖的比例）达到 95% 以上，该语种的下游表现就基本不再受 tokenizer 拖累；低于 90% 则出现系统性的理解折扣。覆盖率是可以直接统计的：拿该语种的评测语料过一遍编码器，数单字节 token 的占比即可——单字节占比高，说明词表对该语种是瞎的。
长尾语种：均衡的尽头
填平中英差距之后，更长的尾巴露出来：泰文没有空格分词，音节边界和词边界错位；缅甸文、高棉文的 Unicode 区块在多数词表里覆盖稀薄；低资源语言的语料本身就不够训练 BPE 学到密集合并。这些语言的 token 成本在中英填平之后仍然高出 3–5 倍，而且没有词表层面的廉价修法——语料不够就是不够。工程上的应对是把 ▁ 式空白编码和无空格语言的预切分正则调对（SentencePiece 在这点上比 GPT 系正则友好），把能省的浪费先省掉，剩下的差距只能接受，或者在应用层做语种检测 + 分路处理。
校验方法：别信感觉，数覆盖率
评估一个 tokenizer 对某语种是否友好，两行代码就够：取该语种的代表性语料，统计编码后单字节 token 的占比和词表条目的命中率。占比高于 15% 基本可判定词表对该语种失明。这个指标比"读几条样例"可靠得多，也能直接指导语料配比调整——目标语种单字节占比降不下来，先加语料，再考虑扩词表。
小结
多语言词表问题归结为一个不等式：信息量的字节成本（UTF-8 决定）× 词表覆盖密度（$V$ 和语料配比决定）= 该语种的 token 成本。英文享受了母语词表红利，其他语言在按差距付费。大词表 + 均衡语料能把中英差距压到 1.5 倍以内，长尾语种仍是开放问题。评估 tokenizer 多语言能力时，先数单字节占比，再谈 benchmark 分数。