LLM 分词器税：语言如何改变 AI 成本和上下文

LLM 分词器税 是一个可测量的成本和上下文惩罚。两个提示可以传达相同的含义，但由于使用不同的语言，它们消耗的令牌数量可能非常不同。

一项 2026 年 7 月的研究测试了 997 个对齐句子，跨越六个分词器。使用 OpenAI 较旧的 `cl100k_base` 编码，十种印度语言的平均词丰度税是英语的 8.0 倍。马拉雅拉姆语达到了 13.04 倍。较新的 `o200k_base` 将平均值降低到 2.1 倍。这项研究并不证明仅仅是分词导致了更差的答案。它确实表明，在模型开始推理之前，价格和可用上下文可能会出现分歧。

受众： 中级

直接答案： 不要根据英语的令牌计数来估算多语言 AI 产品。测试对齐的生产文本上的确切分词器，测量整个请求，单独评估质量，并在模型或分词器更改时重新运行测试。

LLM 分词器税测量的内容

语言模型接收令牌 ID，而不是单词或字符。分词器将文本拆分为令牌单元并将其映射到 ID；一些分词器首先会规范化文本。常见片段可以适合一个令牌。代表性较少的脚本或单词形式可能会拆分为多个令牌或字节。

论文的主要指标是 词丰度：每个以空格分隔的单词的令牌数。它的分词器税是一个语言的词丰度除以在相同分词器下的英语词丰度。

对于生产屏幕，对齐的令牌计数比率通常更容易使用：

text aligned token-count ratio for language L = tokens for aligned content in language L ÷ tokens for the English version

这些指标回答相关问题，但它们不可互换。请命名您报告的指标。两个比较都需要语义上对齐的文本。计算不相关的句子或常见单词列表可能会产生一个吸引人的数字，但对实际应用几乎没有意义。

研究人员还使用 丰度，通常定义为每个单词的令牌数。词丰度是直观的，但在不同语言中，单词边界并不总是同样清晰。当您需要诊断为什么存在差距时，请添加字符丰度、每个令牌的字节数以及未合并字节的比例。

这种区别很重要，因为令牌计数有几种不同的后果：

最后一行是最容易过度声称的。

2026 年研究发现了什么

新的 Tokenizer Tax study 使用了来自 FLORES-200 的对齐句子。它比较了十种印度语言与英语、阿拉伯语、西班牙语和法语，跨越六个分词器。作者测量了词和字符丰度、每个令牌的字节数、未合并的单字节令牌，以及在固定上下文预算下幸存的源文本量。

三个结果对工程决策很重要：

高税语言产生了 27%–43% 的未合并单字节令牌。在样本语言中，具有有效单词边界的语言中，该比率与 `r = 0.89` 的词丰度税相关。作者将差距归因于这些脚本的词汇覆盖不足。

一项 2023 NeurIPS 论文 发现不同语言之间的分词长度差异高达 15 倍。一项 EMNLP 2023 研究 测量了 22 种语言的成本和效用，发现基于令牌的 API 定价可能会对某些语言社区收取更多费用以获取可比内容。

最近的工作还表明，这一差距是设计选择，而不是脚本的不可避免属性。Parity-aware byte-pair encoding (BPE) 改变了合并目标，以帮助当前压缩效果最差的语言。其作者报告称，使用跨语言基尼系数测量，令牌成本不平等最多减少了 89%，全球压缩几乎没有变化。另一项 针对 11 种东南亚语言的控制研究 将 parity-aware BPE 放置在可比 15 亿参数基础模型的效率-公平性帕累托前沿上。该结果并未证明在前沿规模或对齐后存在相同的权衡。

准确性声明需要克制

7 月的研究发现，在 13 个语言点上，丰度与阅读理解准确性之间的原始相关性为 `r = -0.61`。在控制语言资源水平后，部分相关性变为 `r = 0.25`。

避免因果标题的理由还有很多：丰度数字和准确性分数来自不同的分词器/模型设置，样本量小，翻译的基准句子并不是生产工作负载。论文支持关于令牌计数、上下文和基于令牌的成本的强有力声明。它并没有将分词丰度孤立为较低答案质量的原因。

测量您自己的多语言令牌成本

这项研究给出了警告，而不是您的生产比率。支持助手、检索系统或编码代理都有自己的语言组合和提示结构。

在发布之前和每次模型更改后使用此工作流程。

1. 构建对齐样本

对于初步筛选，从您预期的工作负载中收集 100–1,000 个示例：

使用经过审核的同义翻译。保留一个 ID，将每种语言变体连接起来。不要比较从不同语言语料库中提取的随机文本。此筛选范围不是统计最小值：所需样本取决于语言数量、工作负载方差以及您需要多精确地估计尾部行为。

将样本存储为 JSON Lines：

{"id":"support-001","language":"en","text":"Reviewed English text"} {"id":"support-001","language":"sv","text":"Reviewed Swedish translation"} {"id":"support-001","language":"tr","text":"Reviewed Turkish translation"}

2. 固定分词器

分词器属于模型版本。记录两者。OpenAI 的官方 `tiktoken` 仓库 显示 `cl100k_base` 和 `o200k_base`；其模型映射还显示模型系列可以使用不同的编码。对于封闭模型，优先使用提供者的官方计数器（如果存在）。例如，谷歌的 Gemini API 暴露了 `countTokens` 方法。对于开放模型，加载带有模型文档化分词器管道的确切工件，例如 Hugging Face Tokenizers API 中描述的。

不要假设来自同一供应商的两个模型共享一个分词器。不要假设本地库已经知道昨天发布的模型。

3. 计算分布，而不是一个比率

安装并固定计数器：

bash python -m pip install "tiktoken==0.13.0"

然后运行：

python import json from collections import defaultdict from math import ceil from statistics import mean, median

import tiktoken

BASELINE = "en" ENCODINGS = ("cl100k_base", "o200k_base")

groups = defaultdict(dict) with open("aligned-samples.jsonl", encoding="utf-8") as source: for line in source: row = json.loads(line) groups[row["id"]][row["language"]] = row["text"]

def percentile(values, probability): ordered = sorted(values) index = max(0, ceil(len(ordered) * probability) - 1) return ordered[index]

for encoding_name in ENCODINGS: encoding = tiktoken.get_encoding(encoding_name) counts = defaultdict(list) ratios = defaultdict(list)

for sample_id, variants in groups.items(): if BASELINE not in variants: raise ValueError(f"{sample_id} has no {BASELINE} baseline")

baseline_tokens = len(encoding.encode(variants[BASELINE])) if baseline_tokens == 0: raise ValueError(f"{sample_id} has an empty baseline")

for language, text in variants.items(): token_count = len(encoding.encode(text)) counts[language].append(token_count) ratios[language].append(token_count / baseline_tokens)

for language in sorted(counts): print( encoding_name, language, f"mean_tokens={mean(counts[language]):.1f}", f"mean_ratio={mean(ratios[language]):.2f}x", f"median_ratio={median(ratios[language]):.2f}x", f"p95_ratio={percentile(ratios[language], 0.95):.2f}x", f"max_ratio={max(ratios[language]):.2f}x", sep="\t", )

平均值可能会掩盖一些超出上下文窗口的长请求。在将结果用于容量计划之前，请检查 p50（中位数）、p95（95 百分位数）和最大值。

*使用已部署的分词器测量对齐的生产文本，然后使用分布设置成本和上下文限制。质量仍然是单独的评估。*

4. 测量完整请求

可见的用户消息只是 API 调用的一部分。包括：

这对于代理尤其重要。一个大的 JSON 工具架构可能会主导一个简短的用户请求。一个本地化的 RAG 段落可能会主导一个英语系统提示。每当提供者公开该表示时，请测量最终序列化请求。

5. 将令牌转换为操作限制

对于简单的基于令牌定价的 API：

text monthly input cost = monthly calls × mean input tokens × price per million tokens ÷ 1,000,000

假设一个假设的 API 每百万输入令牌收费 1 美元。一百万个请求，每个请求 1,000 个输入令牌，成本为 1,000 美元。如果另一种语言的对齐请求平均为 2,500 个令牌，则输入部分在缓存或折扣之前变为 2,500 美元。

上下文需要单独计算：

text usable input budget = context window

将观察到的语言比率应用于内容部分，而不是盲目应用于整个请求。

AI 推理令牌成本指南 解释了为什么令牌预算需要产品限制，而不仅仅是模型限制。对于 RAG 和编码系统，跨仓库上下文设计 显示了为什么发送更多上下文并不自动有用。如果 API 选择仍然开放，现有的 免费 AI API 案例研究 提供了更广泛的比较框架。

设置多语言接受门

较低的令牌比率只有在模型仍然满足产品要求时才有用。使用四个单独的门：

对于多语言 RAG 系统，按已部署的分词器进行分块，而不是共享字符计数。对于代理，测量工具跟踪和重试以及第一次请求。对于支持产品，跟踪每个解决案例的成本，而不是每个调用的成本。这些选择阻止令牌指标变成虚荣基准。

仅在它改善完整评分卡时使用特定语言的路线。更便宜的分词器与较弱的模型配对可以节省输入令牌并增加重试。更大的上下文窗口可能会隐藏较差的分块，直到账单增加。正确的单位是完成的用户任务。

团队可以改变的内容

应用团队无法重新训练商业模型的分词器，但他们仍然有选择：

训练自己模型的团队有更深的选择。平价感知 BPE 的结果表明，分词器目标可以减少跨语言不平等，而不会牺牲太多整体压缩。东南亚研究增加了控制证据，表明公平性和效率不必朝相反方向发展。

将分词器视为模型合同的一部分。对其进行版本控制、基准测试，并在迁移审查中包含它。

证据的局限性

最新的研究是预印本。它使用翻译的 FLORES-200 句子，语言集较少，并且基于空格的单词度量并不适合每种书写系统。其字节检测方法是特定于分词器的。

最强的结论是模型无关的：当一种对齐语言产生更多令牌时，它在固定令牌窗口中获得的文本更少。当提供者以相同的单价计费这些额外令牌时，成本结论成立。缓存政策和批量折扣可以改变最终发票。

准确性需要自己的测试。训练数据覆盖、模型架构、后训练、评估设计和文化背景都会影响结果。令牌丰度可能会导致差距，但 7 月的论文并没有将这种因果效应孤立出来。

多语言分词器检查表

常见问题解答

为什么某些语言使用更多 LLM 令牌？

子词词汇反映了它们的训练数据和合并规则。常见的英语片段通常被有效地表示，而代表性较少的脚本可能会被拆分为更小的片段或字节。差距的大小取决于确切的分词器和文本。

更高的令牌计数是否意味着更差的答案？

不。它直接影响基于令牌的成本和适合令牌窗口的文本量。它并不证明较低的答案质量。请在每种语言的审核示例中单独测试质量。

如何在 API 调用之前计算令牌？

在可用时使用提供者的官方计数端点。对于 OpenAI 编码，`tiktoken` 可以在本地计数。对于开放模型，加载与模型一起提供的确切分词器工件。固定版本，以便后续更新不会静默更改测量。

切换模型是否可以消除分词器税？

它可以缩小差距。7 月的研究发现 `cl100k_base` 和 `o200k_base` 之间有很大改善。模型切换还会改变质量、输出成本、缓存、延迟和操作行为，因此请比较完整的工作负载，而不仅仅是令牌计数。

来源

声明检查

| 更高的分词器税导致较低的答案准确性 | 未建立 | 7 月论文的调整分析不支持简单的因果阅读