多语言 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），而不是使用翻译后的提示词进行英语红队演练。

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

加载中…