多语言 Token 税：为非英语用户构建 AI 的实际成本

你的产品路线图写着“进军日本和巴西市场”。你的财务模型显示 LLM API 支出项为每月 $X。这两个数字都是错的，而且你直到国际化推广前几周才会发现这一点。

Tokenization（分词）——将用户文本转换为模型可处理的整数的步骤——对英语有着深刻的偏向。一段日语文本所需的 Token 数量可能是同义英语句子的 2–8 倍。这个倍数直接影响到 API 成本、上下文窗口余量和响应延迟。那些根据英语基准测试来模拟 AI 预算，然后直接切换语言选项的团队，通常会被比预期高出 3–5 倍的账单吓一跳。

这种意外会进一步叠加，因为这不仅仅是成本问题。多语言提示词工程（Prompt Engineering）的失败方式往往不会出现在你现有的评估（Eval）中。除英语以外的语言，安全护栏会变弱。在聚合数据中看起来很棒的基准测试分数，掩盖了低资源语言超过 20 个百分点的性能差距。本文涵盖了这三个问题的机制以及能够真正解决这些问题的工程模式。

Token 肥沃度问题

现代 LLM 分词器——无论是 BPE、SentencePiece 还是 WordPiece 变体——主要是在英语文本上训练的。它们的词表经过优化，可以高效地编码英语：典型散文大约每个 Token 对应 4 个字符。非英语语言需要支付一种名为“肥沃度”（Fertility）的税，衡量标准是每个单词的 Token 数。

这些数据对比鲜明：

• 韩语：与英语相比，每个单词约 ~2.36 倍 Token
• 日语：每个单词约 ~2.12 倍 Token，个别句子甚至达到 8 倍
• 中文（普通话）：每个单词约 ~1.76 倍 Token，但与英语约每 4 个字符一个 Token 相比，中文大约是每个字符一个 Token
• 阿拉伯语、印地语、缅甸语：3–4 倍很常见；形态复杂的黏着语甚至更高

经济后果是直接的：如果你的系统提示词和 RAG 上下文在英语中是 50,000 个 Token，那么在韩语中同样的内容大约需要 118,000 个 Token。按 GPT-4o 的定价，在你生成哪怕一个输出 Token 之前，成本就已经增加了大约 2.36 倍。如果你的用户发送的是带有大量上下文的多轮对话，你每条请求的成本可能是英语基础设施成本的 3–4 倍。

上下文窗口也面临着平方级的压力。一个能轻松容纳 30,000 个英语单词的 128K Token 上下文，可能只能容纳 12,000–15,000 个单词的韩语对话。对于需要大上下文的任务——如 RAG 流水线、长文档分析、多轮支持会话——你会更快地耗尽窗口。

双倍成本法则

肥沃度与成本的关系并非线性。“Token 税”研究表明，Token 肥沃度翻倍会导致训练成本和推理延迟增加约 4 倍。这是因为注意力机制（Attention）在序列长度上是呈二次方增长的——更长的序列不仅意味着更多的 Token，还意味着每个 Token 的计算量更大。

在生产环境的推理规模下（而非训练），直接影响是 API 定价：你按输入和输出 Token 付费，因此 2 倍肥沃度约等于 2 倍 API 账单。但延迟的影响更为微妙。输出生成是顺序进行的，更多的输出 Token 意味着成比例地消耗更多时间。对于一段 200 个单词的日语回复，如果英语编码需要 200 个 Token 而日语需要 400 个，那么即使首字响应时间（Time-to-first-token）没有变化，完成整个响应的时间也会翻倍。

这对于延迟 SLO（服务水平目标）非常重要。如果你的英语流水线能轻松保持在 2 秒的 p95 延迟内，那么你的日语流水线——即使面对同样的模型、同样的硬件、同样的供应商——在处理长回复时也可能会经常超时。基于英语基准测试进行的容量规划，会低估非英语工作负载所需的 GPU 工时。

为什么你的评估发现不了这些问题

标准的多语言评估说法是：“我们在 10 种语言中运行了 MMLU，获得了 82% 的准确率。”这在两个方向上都具有误导性。

首先，大多数多语言基准测试都是英语任务的机器翻译版本。翻译保留了事实内容，但剥离了文化背景，改变了成语/习语的难度，并引入了人工痕迹。INCLUDE 基准测试（2025）使用了来自当地考试的母语问题，发现模型在母语内容上的表现比在翻译后的等效内容上更差——这意味着翻译后的基准测试系统性地高估了非英语用户的实际体验。

其次，聚合分数掩盖了各语言之间的差异。涵盖 29 种语言的 MMLU-ProX 基准测试（2025）显示，高资源语言和低资源语言之间存在高达 24.3 个百分点的差距。一个在英语上得分 85%、在德语上得分 78% 的模型，在斯瓦希里语上可能只有 62%。你的单一聚合数字并不能告诉你，你的斯瓦希里语用户在三分之一以上的情况下得到的都是错误答案。

你需要的评估方法论不是“针对翻译后的输入运行你的英语评估套件”。而是：

1. 从领域专家或当地考试语料库中获取母语测试用例
2. 根据你实际的生产内容分布（而非通用文本）测试 Token 肥沃度
3. 独立测试每种语言的安全性和拒绝行为——安全护栏的失败模式与准确性不同，下文将详细说明。

安全对齐差距

这是操作上最危险的失效模式，也是讨论最少的。

LLM 的安全对齐主要是在英语数据上训练的。在英语中能可靠拦截有害输出的防护栏，在其他语言中会出现明显的性能下降。2025 年的一项关于多语言 LLM 安全的研究发现，当模型使用非英语提示时，毒性（toxicity）始终更高——而且模型在非英语环境下会产生在英语环境下会被过滤掉的有害内容。

其机制显而易见：RLHF 和宪法 AI（Constitutional AI）过程主要使用英语人类反馈。当模型接收到韩语的提示词注入（jailbreak）尝试时，它通过一个置信度较低的路径映射语义，导致拒绝行为的可靠性降低。

亚太地区语言（韩语、马来语、印尼语、泰语、越南语）在非英语提示下的安全绕过率特别高。如果你的 AI 功能在这些地区运行，你需要进行特定语言的红队演练（red team exercise），而不是使用翻译后的提示词进行英语红队演练。

操作层面上的影响是：你的英语安全评估并不能覆盖你的非英语用户。这既是合规性问题，也是产品质量问题。

提示工程在无声中失效

除了分词（tokenization）成本和安全差距之外，多语言提示工程（prompt engineering）还有其特有的失效模式，这些模式在仅限英语的开发中并不会出现。

内部英语推理。经过大量英语训练的模型即使在使用另一种语言提示时，内部仍会继续使用英语进行推理。隐式流水线变成了：将日语输入翻译成英语 → 用英语推理 → 将输出翻译回日语。这在两端都引入了翻译错误，而且对微妙推理的回译（back-translation）往往会降级。复杂的多步问题受影响最大。

指令遵循漂移。模型在非拉丁文字语言中遵循指令的精确度系统性地较低。如果你的英语提示词说“以恰好三个要点进行回答”，日语版本可能会产生四个要点、散文段落，或者切换到列表格式。格式化指令需要在每个目标语言中进行显式测试。

习语提示模式无法迁移。在英语中有效的提示工程技巧——思维链（chain-of-thought）措辞、角色设定语言、少样本（few-shot）示例结构——在翻译后往往无法产生同样的效果。对于非母语者来说看起来正确的翻译后的少样本示例，可能使用了改变模型解释指令方式的习语或结构。由母语人士编写的特定语言提示示例，其表现始终优于翻译后的英语提示。

代码混用与语言混淆。模型在输出中会无意中混杂语言，特别是当系统提示词是英语而用户输入不是时。对于代码切换（code-switching）很常见的多语言支持应用（例如使用西英混合语 Spanglish 或在对话中途切换语言的用户），这成为了低质量回答的潜在来源。

行之有效的工程模式

有几种模式可以解决生产环境中的这些问题。

使用特定语言的系统提示词，而非翻译。最有效的改变是使用每个目标语言的原生语言编写系统提示词，并配以母语人士编写的示例。翻译后的英语提示词并不等效。做出这一改变的团队——包括 Duolingo 的 AI 辅助语言内容团队——报告称，相比翻译后的提示词，其准确性有了显著提升。

对多语言资产进行提示词缓存（Prompt cache）。静态内容——术语表、行为指令、领域知识块——应该放在提示词缓存中。对于具有大型稳定系统提示词的应用，提示词缓存可以将缓存部分的成本降低 60–90%。对于系统提示词较大的非英语系统（因为你需要更多示例来克服翻译推理差距），这是最可靠的成本杠杆。

按语言拆分你的评估套件。为每种语言维护一套带有原生测试用例的评估工具。在每次模型版本更新和每次重大的提示词更改时运行它。多语言聚合评分作为回归检测器几乎毫无用处——一个让英语提升 3% 但让韩语下降 8% 的更改在聚合视图中看起来是中性的。

模型选择对多语言而言比英语更重要。在闭源模型中，Gemini 2.0 拥有最好的分词肥力（tokenization fertility，使用针对非英语优化的、具有大词汇量的 SentencePiece）。GPT-4o 的 o200k_base 分词器比早期的 GPT-4 分词器有显著改进。在主要的闭源模型中，Claude 的分词器据报道肥力最差。对于重度使用中日韩文字（CJK）的应用，模型选择对 API 成本有 30–50% 的直接影响——这是一个采购决策，而不仅仅是质量决策。

对于开源部署，Llama 3.1 显示出最佳的分词效率。社区还为中文和阿拉伯语构建了特定语言的词汇表扩展，进一步提高了这些文字的分词肥力。

在基础设施层按语言进行路由。在达到足够规模时，按语言而非仅按任务进行路由是有意义的。一个用于创意写作任务的日语查询在不同模型上的表现可能优于同一个任务的英语查询。特定语言的路由还允许你应用不同的安全策略、不同的提示词模板和不同的成本模型，而不会将它们纠缠在应用逻辑中。

对于高风险用例，推理模型可以缩小差距。DeepSeek 式和 o1 式推理模型在复杂推理任务上将英语与非英语的性能差距缩小了 8–12 个百分点，在一些评估中将非洲语言的差距几乎减半。权衡之处在于延迟和成本——推理模型更慢且更贵——但对于低资源语言准确性至关重要的领域（医疗、法律、金融），缩小差距带来的收益可能值得这些开销。

你真正需要衡量的指标

在发布到非英语市场之前，请进行以下指标评估：

1. Token 肥沃度（Token fertility）审计。 从每个目标区域抽取 1,000 个真实用户输入样本。衡量每个请求的平均 token 数。除以你的英语基准值。这就是你的成本倍率。如果你还没有真实用户数据，合成基准测试会低估这一数值。

2. 原生任务的单语言准确率。 不要使用翻译过的英语测试用例。如果你无法获得原生用例，可以使用 MMLU-ProX 或 INCLUDE 进行初步定向，但请注意，这些仍然是通用知识基准测试 —— 你的特定领域表现可能会更差。

3. 安全绕过测试。 针对每种语言，尝试使用该语言中排名前 20 的英语越狱（jailbreak）模式。在你的应用中运行它们。记录拒绝率（refusal rate）。如果拒绝率显著低于英语，说明你存在合规风险。

4. 分语言的延迟剖析。 逐个 token 的延迟大致是恒定的，但如果你的日语回复需要 2.5 倍的输出 token 才能传达相同的信息，那么你的 P95 延迟也会高出 2.5 倍。在做出 SLO 承诺之前，请先进行剖析。

5. 提示词指令遵循度。 对于提示词中每个关键的行为指令（格式、长度、结构），测试其在每种目标语言中是否被正确遵循。

总结性估算

如果你是基于英语 API 基准测试来预算 AI 基础设施成本的：

• 韩语或日语用户：预计每个请求的成本是英语的 2–2.5 倍
• 阿拉伯语或印地语用户：预计每个请求的成本是英语的 2.5–4 倍
• 高肥沃度语言（缅甸语、藏语、部分非洲语言）：4–8 倍也是可能的

这不是舍入误差。它决定了一个功能在某个市场是否具有经济可行性。它还决定了一个产品是仅对你的英语 QA 团队有效，还是也能对说不同语言的真实用户有效。

那些在生产环境而非规划阶段才发现这一点的团队，通常是因为他们使用了英语基准测试来评估多语言 AI 产品并发布，结果却不得不面对满载非英语用户投诉的支持队列，以及未曾建模的成本超支。

倍率是已知的。失败模式是有据可查的。解决这些问题的模式也已存在。剩下的唯一问题是，你是在发布前还是发布后去衡量它们。

---