非洲语言税:量化前沿大语言模型中分词非洲语言的成本、延迟和上下文惩罚
摘要
本文系统量化了20种非洲语言在11个前沿和开源分词器上的分词惩罚,发现推理成本和延迟最高可达8.9倍,有效上下文窗口仅为英语的11%,突显了子词词汇表中编码的结构性数字鸿沟。
arXiv:2606.24460v1 公告类型:新提交
摘要:商业大语言模型按token计费、扩展延迟和预算上下文。然而,分词器为某些语言中的相同含义分配比其它语言更多的子词token,因此具有高token生育率的语言的使用者在调用模型之前就付出了结构性惩罚。这种惩罚在一般多语言环境中已有记录,但尚未在部署经济学和认知上下文能力层面对非洲语言进行系统测量。我们测量了20种非洲语言,涵盖五个语系和三种文字(拉丁字母、吉兹/埃塞俄比亚文字、N'Ko;其中19种出现在主要FLORES-200+语料库中,尼日利亚皮钦语仅通过MAFAND-MT测量),使用平行语料库以隔离语言对内容的影响。在FLORES-200+上的11个前沿和开源分词器中,每种非洲语言都带有高于英语的分词溢价(GPT-5 / o200k_base中位数为1.88倍,N'Ko高达8.92倍);惩罚最大的是埃塞俄比亚文字和N'Ko文字(达到7-9倍),并且跨语料库几乎不变(FLORES与SIB-200的皮尔逊相关系数r=0.9998)。转化为部署术语,这导致推理成本高达8.9倍,以及等量的生成延迟倍数(GPT-5上N'Ko对比英语;阿姆哈拉语为7.4倍),有效上下文窗口仅为英语的11%。当前对非洲语言最好的分词器Gemma 4将平均溢价从3.31倍(cl100k_base)降至2.38倍,但没有分词器能消除该惩罚。我们发布了一个开源测量工具(afri-fertility)、一个公开排行榜、一个结果数据集以及为非洲开发者提供的缓解指南。惩罚最重地落在那些最负担不起的语言使用者身上,这是一种直接编码在子词词汇表中的数字鸿沟。
查看缓存全文
缓存时间: 2026/06/24 07:47
# 非洲语言税
来源:https://arxiv.org/html/2606.24460
Olaoye Anthony Somide, DataLens Africa Research · CipherSense AI Technologies Ltd \(2026年6月\)
### 摘要
商用大语言模型按 token 计费、按 token 规模扩展延迟、并按 token 预算上下文。然而,分词器对某些语言中相同含义分配的子词 token 数多于其他语言,因此高 token 繁殖率语言的用户在调用模型之前就已承担结构性惩罚。这种惩罚在一般多语言环境中已有记载,但尚未在企业管理部署经济性和认知上下文容量层面针对非洲语言进行系统测量。我们使用平行语料库(这样语言效应能与内容隔离)测量了涵盖五个语系和三种文字(拉丁字母、吉兹/埃塞俄比亚字母、N'Ko 字母;其中 19 种出现在主要 FLORES\-200\+ 语料中,尼日利亚皮钦语仅通过 MAFAND\-MT 测量)的 20 种非洲语言。在 FLORES\-200\+ 上的 11 个前沿和开放分词器中,每种非洲语言都比英语承担更高的分词溢价(GPT\-5 / o200k\_base 上中位数为 1.88 倍,N'Ko 字母高达 8.92 倍);埃塞俄比亚字母和 N'Ko 字母文字的惩罚最大(达到 7–9 倍),且跨语料(FLORES 与 SIB\-200 Pearson r = 0.9998)近乎不变。换算成部署条件,这导致推理成本最高增加 8.9 倍,生成延迟倍数相当(N'Ko 字母对英语 on GPT\-5;阿姆哈拉语为 7.4 倍),有效上下文窗口仅为英语的 11%。目前最适合非洲语言的分词器 Gemma 4 将平均溢价从 3.31 倍(cl100k\_base)降至 2.38 倍,但没有一个分词器能消除惩罚。我们发布一个开放测量工具(afri\-fertility)、一个公共排行榜、一个结果数据集以及针对非洲开发者的缓解指南。惩罚最重地落在那些最无力承担的语言使用者身上——一种直接编码在子词词汇中的数字鸿沟。
### 关键词
分词、子词繁殖率、非洲语言、LLM 推理成本、多语言 NLP、分词器公平性、低资源语言、AI 公平性
## 1. 引言
### 1.1 推理前的成本层
在大语言模型对提示中的任何一个词进行推理之前,它必须先将文本转换为 token。商用 LLM 提供商按 token 定价 API,生成延迟随生成的 token 数量扩展,并通过固定 token 上下文窗口限制对话。因此,分词并非中立的预处理步骤:它是设定使用模型的经济性的层面。两个携带完全相同含义但分词成不同 token 数量的提示,处理成本不同,回答所需时间不同,消耗的可用上下文比例也不同(实际上降低了模型的“操作记忆”,迫使更早截断对话历史),而这一切发生在模型的质量、准确性或能力进入考量之前。这一点很重要,因为分词器并不平等地分割所有语言。一个从英语和其他高资源、网络丰富的语言中学习到的子词词汇能用紧凑方式表示这些语言,而将其他语言碎片化为许多短片段。这种效应的标准度量是*繁殖率*(分词器每个词发出的子词 token 数),且语言间的差异很大且已有充分记录。Petrov 等人 2023 (https://arxiv.org/html/2606.24460#Sx13) 表明,在当前分词器下,相同内容在不同语言中可能需要多达约十五倍的 token 数;Ahia 等人 2023 (https://arxiv.org/html/2606.24460#Sx13) 则证明这种长度差异直接转化为跨类型多样语言的 API 成本和不平等的效用。该惩罚是结构性的:由分词器的词汇固定,每次请求都适用,下游用户无法通过工程手段规避。
### 1.2 为什么是非洲语言,为什么是现在
跨语言分词差距已在一般多语言环境中被记录,而最直接针对欧洲语言的是 Ovcharov 2026 (https://arxiv.org/html/2606.24460#Sx13),他在平行文本上测量了 25 种语言的“分词税”,发现英语约 1.2 token/词,希腊语和马耳他语达到约 3.1 倍,效率排名跨文本类型几乎不变。该研究与我们方法最接近的先例,但其最大惩罚落在仍然共享拉丁、希腊或西里尔文字系且具有相当网络存在的欧洲语言上。非洲语言在这一分辨率上尚未被测量,尽管它们恰好具备应将惩罚推过该上限的属性:非拉丁文字(吉兹/埃塞俄比亚字母、阿拉伯/Ajami 字母、N'Ko 字母)、黏着和声调形态学,以及在分词器训练语料中的代表性远为薄弱。差距后果严重:部署客户服务、临床分诊和农业咨询服务的非洲开发者必须在生产规模上越来越多地使用本地语言,而在这些市场计算资源最不便宜;同时非洲 NLP 社区在准确性基准(IrokoBenchAdelani 等人 2025 (https://arxiv.org/html/2606.24460#Sx13)、AfroBenchOjo 等人 2023 (https://arxiv.org/html/2606.24460#Sx13))上投入了大量精力,而它们之下的推理前成本层尚未被量化。一个模型可以在任务上得分很高,但用它所写的语言运行起来仍然不经济。我们通过平行语料测量来解决这个问题。因为平行语料在每种语言中表达相同含义,对于固定分词器,token 数量的差异反映的是语言及其文字,而非内容,从而隔离了我们想要测量的效果。我们将这些结果转化为决策者使用的术语:美元和当地货币成本、延迟倍数以及模型上下文窗口的有效容量。
### 1.3 贡献
本文做出三项贡献:
1. 首次对非洲语言分词溢价进行全面审计,建立 20 种非洲语言和 11 个当前前沿及开放分词器的数字公平性基线。我们报告每种语言-分词器对多个文字系的繁殖率和英语相对溢价,并附有语料级别的聚合和 bootstrap 置信区间。
2. 一个企业成本模型,将繁殖率转化为美元和当地货币(尼日利亚奈拉 NGN、南非兰特 ZAR、肯尼亚先令 KES)成本,既考虑 token 繁殖率,也考虑当地货币相对于美元定价 API 的波动复合效应。我们进一步量化了生成延迟倍数和上下文窗口侵蚀,后者减少了模型的“操作记忆”,迫使非洲语言应用在相同成本下处理更短的对话历史。我们将该模型实例化在三个具体的部署场景上:银行客服助手、临床分诊热线和短信农业咨询服务。
3. 开放性工件:afri-fertility (https://github.com/CipherSenseAI/afri-fertility),一个确定性测量工具,内置非洲测试套件;一个公共非洲分词税排行榜;一个已发布的结果数据集;以及一份面向非洲开发者的一页缓解指南。这些共同将已知但抽象的不平等转化为针对非洲部署场景的可测量、可重现且经济上可理解的惩罚,并附带可供任何人重新运行和扩展测量的工具。
## 2. 背景与相关工作
### 2.1 子词分词与繁殖率
现代 LLM 使用从训练语料中学习到的子词词汇进行操作,通常通过字节对编码 (BPE)、Unigram/SentencePiece 或字节级 BPE 变体,如近期 OpenAI 模型使用的 `tiktoken` 系列。词汇表固定了任何字符串的分割方式:训练语料中频繁出现的序列被合并为单个 token,而罕见的序列则被保留为许多短片段,直至词汇表几乎不覆盖的文字的单个字节。这种行为的标准标量总结是*繁殖率*(每个词发出的 token 数,Rust 等人 2021 (https://arxiv.org/html/2606.24460#Sx13)),Rust 等人将其与下游模型质量联系起来,我们在此采用它作为英语相对*溢价*的基础。由于词汇表是训练混合比例的冻结产物,它在给定语言上的繁殖率在训练时固定,并在后续每次请求中承担;部署用户无法在不改变模型的情况下降低它。
### 2.2 跨语言分词不平等
繁殖率在不同语言之间变化剧烈,且这种变化系统性地与语言在训练数据中的代表性有关,这一点现已得到充分证实。Petrov 等人 2023 (https://arxiv.org/html/2606.24460#Sx13) 记录到,在当前分词器下,相同含义在不同语言中可能需要多达约十五倍数量的 token,并将其视为内嵌于分词器本身的不公平。Ahia 等人 2023 (https://arxiv.org/html/2606.24460#Sx13) 直接将长度差异与部署联系起来:在按 token 定价的 API 下,高繁殖率语言的用户为相同服务支付更多费用,且更快耗尽固定上下文窗口,该研究覆盖了 22 种类型多样的语言。这两个结果确立了该现象及其在一般多语言语境中的经济后果。但两者都未深入隔离非洲案例,且都早于我们测量的当前一代前沿分词器。
### 2.3 近期“Token 税”框架
最近两项工作将该效应命名为“税”。Lundin 等人 2026 (https://arxiv.org/html/2606.24460#Sx13) (*The Token Tax*) 用一般术语描述了多语言分词中的系统性偏差。与我们方法最接近的是 Ovcharov 2026 (https://arxiv.org/html/2606.24460#Sx13) (*Tokenizer Tax across 25 European Languages*),他在平行文本上测量了 25 种欧洲语言和十个基础模型的分词税,报告繁殖率从英语约 1.2 token/词到希腊语和马耳他语约 3.1(约 2.5 倍惩罚),效率排名跨语类几乎不变(相关性 > 0.97),在形态边界处碎片化,并发布了所有测量结果为公开数据集。Ovcharov 是我们构建方法论的模板:跨多个分词器的平行语料繁殖率,公开发布。决定性区别在于范围和框架。欧洲上限由保留拉丁、希腊或西里尔文字且具有相当网络存在的语言设定;非洲语言增加了非拉丁文字(吉兹/埃塞俄比亚字母、阿拉伯/Ajami 字母、N'Ko 字母)、更重的黏着和声调形态学,以及更薄弱的训练代表性;且没有先前工作将由此产生的繁殖率转化为非洲部署者必须考虑的企業成本、延迟和上下文术语,也没有将测量作为开放工具和排行榜发布。
### 2.4 非洲 NLP 评估
非洲 NLP 社区已建立了以模型*准确性*为重点的大量评估基础设施。IrokoBenchAdelani 等人 2025 (https://arxiv.org/html/2606.24460#Sx13) 和 AfroBenchOjo 等人 2023 (https://arxiv.org/html/2606.24460#Sx13) 在许多非洲语言和任务上对前沿和开放模型进行基准测试;更广泛的 Masakhane 生态系统(包括我们用作主要测量集的 FLORES\-200\+ 平行语料库,NLLB Team 2024 (https://arxiv.org/html/2606.24460#Sx13))提供了该领域所依赖的平行和标注数据。这些工作衡量模型在某种语言中是否*正确*。它没有衡量正确性之下的成本层:无论准确性如何,该语言消耗多少 token,进而消耗多少美元、多少延迟、多少上下文。两者是互补的,我们通过将每种语言的溢价与已发表的 IrokoBench/AfroBench 准确性相关联来直接结合它们,以测试更高成本的语言是否也趋向于更低准确性 (H4)。此外,Ndomba 等人 2025 (https://arxiv.org/html/2606.24460#Sx13) 发现语言特定的分词器可以在非洲语言任务上优于多语言默认值,这激发了我们的缓解分析(§8)。
### 2.5 定位
本文是第一个跨多个语系和文字、在平行语料和当前前沿分词器上测量非洲语言分词惩罚的研究,并将其转化为具体的企業成本、延迟和上下文模型,以开放工具、排行榜和数据集形式发布。表 2.1 (https://arxiv.org/html/2606.24460#Sx2.SSx5) 定位了我们的贡献与最近的先前工作。
表 2.1:相关工作定位
| 工作 | 所做内容 | 本文不同之处 |
|------|----------|----------------|
| Petrov 等人 2023 (https://arxiv.org/html/2606.24460#Sx13) (NeurIPS) | 跨语言分词器不公平性;多达约 15 倍长度差异 | 非洲语言深度关注;当前前沿分词器;企業成本模型 |
| Ahia 等人 2023 (https://arxiv.org/html/2606.24460#Sx13) (EMNLP) | 跨 22 种类型多样语言的 API 成本/效用 | 非洲语系/文字深度覆盖;命名部署场景 |
| Lundin 等人 2026 (https://arxiv.org/html/2606.24460#Sx13) (*The Token Tax*) | 多语言分词偏见(一般性) | 非洲语言特定;平行语料;经济学;开放工具 + 排行榜 |
| Ovcharov 2026 (https://arxiv.org/html/2606.24460#Sx13) (*Tokenizer Tax across 25 European Languages*) | 欧洲语言的平行语料繁殖率 | 非洲语言和非拉丁文字;企業框架 |
| 非洲 NLP 基准:IrokoBenchAdelani 等人 2025 (https://arxiv.org/html/2606.24460#Sx13), AfroBenchOjo 等人 2023 (https://arxiv.org/html/2606.24460#Sx13) | 准确性基准 | 测量*推理前*成本层;链接到其准确性用于 H4 |
## 3. 定义与度量
### 3.1 符号与计数约定
设一个*文档*为语言 \(L\) 中的一段文本,由分词器 \(T\) 分词。对于一个文档,我们定义四个基本计数,每个计数均在同一固定约定下计算,该约定对所有语言相同,因此没有语言获得特殊预处理:
- • \(W(L)\),词数,通过 Unicode 分词 (UAX\-29,通过 ICU/uniseg) 获得。我们预先指定分词,因为大多数目标语言以空白分隔,且选择必须跨语言相同以保持繁殖率可比。如果主要分词器不可用,则在运行元数据中记录一个 `\regex \\w\+` 回退。
- • \(N(L,T)\),token 数:分词器 \(T\) 产生的子词 token 数量,*排除*特殊 token、BOS 和 EOS token。这是预先指定的,以便固定的每序列开销不会不均地夸大短句计数。
- • \(\mathrm{chars}(L)\),Unicode 标量值中的字符数。
- • \(\mathrm{bytes}(L)\),UTF\-8 字节数。
所有文本在进行任何计数前均归一化为 Unicode NFC。空或仅空白输入返回零计数而无错误。
### 3.2 度量(固定公式)
从基本计数中我们推导出研究的五个度量。较低的繁殖率(即较低溢价)更好。
**繁殖率**,每词 token 数;主要效率度量。
\[
F(L,T) = \frac{N(L,T)}{W(L)}
\]
**溢价(平价)**,相对于基线语言(默认为英语)的繁殖率;主要数值。
\[
P(L,T) = \frac{F(L,T)}{F(\text{eng},T)}
\]
\(P\) 直接解读为:*语言 \(L\) 的使用者为相同含义支付英语使用者所支付 token 数的 \(P\) 倍。* 根据构造,对于每个 \(T\),\(P(\text{eng},T)=1\),并且我们预期处处 \(P>0\)。
**每 token 字符数**,压缩效率。
\[
\mathrm{CPT}(L,T) = \frac{\mathrm{chars}(L)}{N(L,T)}
\]相似文章
跨25种欧洲语言的Tokenizer税:领域不变性、跨语言少样本效应与乌克兰语惩罚
本文在平行文本上测量了25种欧洲语言的分词器标记率,发现从英语到希腊语/马耳他语的差距达到2.5倍,其中乌克兰语承受15-18%的惩罚。研究证明了标记率排名的领域不变性,分析了子词碎片化,并评估了跨语言少样本效应。
非洲语言NLI评估的样本量缩放
本文利用AfriXNLI基准测试,研究标注数据大小对16种非洲语言自然语言推理性能的影响。结果表明,缩放行为对语言敏感且通常非单调,挑战了常见的单调改进假设,并强调了需要为特定语言创建数据集以及更强的多语言策略。
兼顾公平与效率:多语言大语言模型分词器的实证研究
本文系统比较了涵盖11种东南亚语言的公平性分词器在多语言大语言模型中的表现,发现Parity-aware BPE在效率与公平之间取得了最佳平衡,并且跨语言公平性与分词效率并非根本冲突。
通过令牌剪枝优化韩语中心的大语言模型
本文系统地评估了令牌剪枝这一压缩技术在韩语中心的LLM任务上的应用,该技术通过移除与无关语言对应的令牌和嵌入参数来压缩模型。研究评估了流行的多语言模型(Qwen3、Gemma-3、Llama-3、Aya)在不同词汇配置下的表现,发现令牌剪枝能显著改进生成稳定性并降低特定领域部署的内存占用。
我对LLM代码风格与Token成本的发现
本文讨论了LLM代码风格选择如何影响Token消耗和成本,并提供了优化建议,如使用Web API标准和更简单的缩进以减少输出Token。