跳到主要内容

Tokenizer 税:除了英语,你的 AI 功能在所有其他语言中成本更高且表现更差

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的定价页面显示每个用户支付的费用相同。但你的成本仪表板却给出了不同的答案。同样的 AI 功能 —— 同样的提示词模板、同样的模型、同样的特性标志(feature flag) —— 为西班牙语用户提供服务的成本要高出 55%,日语用户大约翻倍,而阿拉伯语或孟加拉语用户则超过 3 倍。与此同时,这些用户获得的质量也明显更差:在翻译成不同语言的相同基准测试问题上,当前沿模型脱离英语分布时,其表现会下降 13 到 24 个百分点。

大多数在全球范围内发布 AI 功能的团队从未衡量过这两项数据。他们拥有分地区的定价、分地区的支持 SLA、分地区的法律审查 —— 却只用一套英语评估测试集来代表全球每个用户的体验。

这就是分词器税(tokenizer tax),它与仅靠规模无法弥补的质量差距相互叠加。在你按语言维度拆分数据之前,这两者在仪表板上都是不可见的。而且这两者早在你写下第一个提示词的几年前,就由你无法控制的分词器训练语料库决定了。

税收从何而来

大语言模型(LLM)不按单词或字符计费。它们按 Token 计费,而 Token 并不是一个中立的单位。分词器的词表是通过合并频繁共现的字节序列从其训练语料库中学习而来的。由于网络规模的语料库绝大多数是英语 —— Common Crawl 大约 46% 是英语,其他所有语言都处于长尾部分 —— 因此分词器为英语学习到了大而高效的语义块,而对其他语言则只能切分成碎片。

结果就是研究人员称之为“丰饶度”(fertility)的指标:代表一个单词所需的平均 Token 数。在现代分词器上,英语大约每个单词对应 1.2–1.5 个 Token,每个 Token 约四个字符。中文、日文和韩文文本通常会退化到大约每个字符对应一个 Token。具有丰富形态变化或非拉丁字母的语言 —— 土耳其语、印地语、泰语、阿姆哈拉语 —— 碎片化程度甚至更高。跨语言的系统测量显示,相同的语义内容所需的 Token 数是其对应英语的 1.5 倍到 5 倍以上,一些低资源的非洲语言甚至超过了这个比例。

丰饶度并不是舍入误差。它会成倍地增加你服务经济中的每一项支出:

  • API 成本与 Token 数量呈线性关系。 丰饶度为 2 倍的语言意味着在同一场对话中,输入成本和输出成本永远是原来的 2 倍。
  • 有效上下文按相同比例缩小。 你的 128K Token 窗口只能容纳一半的日语对话历史、一半的检索文档、一半的少样本(few-shot)示例。用户会更快地丢失对话开头的内容,你的 RAG 流水线截断也会更激进 —— 而恰恰是在这些地区,模型需要更多的背景信息(grounding),而不是更少。
  • 延迟随输出 Token 增加。 当回答需要两倍的 Token 时,输出最后一个 Token 的时间(Time-to-last-token)大约会翻倍。你的 P95 延迟 SLO 在不知不觉中变成了分语言的 SLO。
  • 速率限制和配额是以 Token 为单位的。 来自大量使用 CJK 用户群的相同流量,消耗供应商配额的速度是你基于英语进行容量规划时预期的两倍。

更新的分词器有所帮助,但无法根治。将词表从 10 万增加到 20 万或 25.6 万显著缩小了 CJK 的差距,这就是为什么同一段日语在不同供应商那里的计费不同。但排名顺序从未改变:英语永远是最便宜的语言,与长尾语言的差距从未消除,因为你无法在不使嵌入表(embedding table)膨胀的情况下为 300 多种语言添加高效词表 —— 在数百种语言中为每种语言扩展几千个 Token 的词表,会使一个 40 亿参数的模型变成 200 亿参数,而没有任何能力上的增益。

质量差距叠加在成本差距之上

如果非英语用户只是为了同样的质量支付更多的费用,那这只是个定价问题。事实是,他们花了更多的钱,得到的却更少。

由相同问题构建的跨语言基准测试 —— 涵盖 29 种语言的 MMLU-ProX、Global MMLU、涵盖 61 种语言的 MuBench —— 一致显示前沿模型在偏离英语分布时,准确率会下降两位数。对于高资源的欧洲语言,降幅较小;在资源中等的语言中,降幅增大;对于像斯瓦希里语这样的语言,降幅达到 20–30 个百分点。推理链变得更短且更草率。指令遵循能力下降。安全护栏本身大多基于英语红队测试数据训练,在两个方向上都会退化 —— 更多的错误拒绝和更多的遗漏。

丰饶度本身就能预示部分结果。一项针对 16 种非洲语言、10 个模型的研究发现,较高的丰饶度始终与较低的准确率相关 —— 取决于学科和模型,每个单词额外增加的 Token 会导致准确率下降 8 到 18 个点 —— 丰饶度解释了 20–50% 的准确率差异。一旦你理解了其机制,就很直观了:当一个单词破碎成毫无意义的片段时,模型所需的形态学信息在输入层就被破坏了。一个表示格(case)的土耳其语后缀如果从语素中间被切分,就会变成噪声而非信号。在某些语言中承载语义重量的变音符号(diacritics)在生成过程中的损坏率高达 18–50%。在碎片化的脚本中,一个拼写错误可能会产生一个与正确拼写形式完全没有重叠的 Token 序列 —— 因此,你在英语中习以为常的对噪声输入的鲁棒性,在这些语言中根本不存在。

这种叠加效应才是最令人担忧的。模型表现最弱的地区,也正是丰饶度消耗上下文预算最快的地区,这意味着用来补偿弱点的检索文档和少样本示例的存放空间更小。在你最需要缓解措施的地方,你的缓解预算却是最少的。

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates