印度语言Token成本惊人：印地语是英语的4.4倍，马拉雅拉姆语达7.3倍

被忽视的GPU账单：印度语言用户的Token税

如果你为印度语言用户提供LLM服务，你的GPU账单里藏着一个隐藏乘数。一位开发者没有停留在引用结论，而是亲自用Qwen3 tokenizer对1,012条FLORES devtest句子做了实测：印地语（Hindi）每句消耗的token是同一句英语的4.44倍，马拉雅拉姆语（Malayalam）则高达7.27倍。按词计算更加悬殊——马拉雅拉姆语平均每词13.47个token，英语仅为1.27个。

这个数字的工程含义很直接：更多token意味着每个用户占用更大的KV-cache，同一张GPU能并发的用户数成比例缩水。模型没变、硬件没变，但一个印度语言用户的并发成本可能是英语用户的数倍。这不是模型能力问题，而是分词器（tokenizer）层面的结构性开销。

FLORES devtest 是 Meta AI 发布的 FLORES-200 多语言评测数据集中的开发测试集，覆盖 200 种语言，每语言约 1,012 句，取自维基百科等公开文本并经人工校对。它被广泛用于机器翻译和跨语言分词效率研究，因为同一语义在不同语言中有平行对照，便于直接比较 token 消耗。Token 是分词器将文本切分后的最小单元，LLM 按 token 计费和占用显存；KV-cache 则是推理时缓存的历史键值对，其大小与序列 token 数成正比，直接决定单卡可并发请求数。

分词器选择比服务优化更关键

同一个印地语句子，换成不同分词器，结果完全不同：

• Qwen3 / Qwen2.5：4.44倍
• Sarvam-M：1.79倍
• Gemma-3：1.31倍

这组对比直接推翻了「印度文本天生昂贵」的笼统判断。Gemma-3上的印地语开销仅为英语的1.31倍，已经接近可接受范围；而Qwen3系列则高达4.44倍。换句话说，选哪个模型对成本的影响，可能超过任何服务层调优技巧——量化、批处理、缓存优化在分词器层面的数量级差异面前都显得次要。

对部署印度语言服务的团队来说，这提供了一个明确的决策依据：在模型选型阶段就把分词效率纳入评估，而不是等上线后才发现GPU账单失控。

分词器（tokenizer） 是 LLM 的前置文本处理器，负责把原始字符串切分为子词单元并映射为整数 ID。其词表构成和训练语料决定了同一文本的切分粒度：词表对某语言覆盖越差，该语言文本被切得越碎、token 数越多。Qwen 系列词表以中英文为主，印度语言子词覆盖有限；Gemma-3 和 Sarvam-M 则在训练中纳入了更多印度语言数据，因此切分更高效。分词器通常在模型训练前固定，服务层无法更改，这正是“选型比调优更关键”的技术根源。

罗马化不是免费解药

一个直观的绕行方案是用拉丁字母拼写印地语（罗马化）。但作者实测发现这个方案并不通用：在Qwen3上，罗马化把开销从4.44倍降到2.06倍，确实有效；在Gemma-3上反而从1.31倍恶化到1.85倍。

作者也坦诚标注了方法局限：他使用的ITRANS转写方案保留了schwa音、按发音拼写借词，并非自然的Hinglish聊天文本。因此他把这个结果标记为「限制」而非「关于真实聊天文本的结论」。这种自我设限的做法在AI工程博客里并不多见，也提醒读者不要过度外推罗马化的收益。

先验证自己，再发布数字

在信任自己的测量之前，作者先复现了此前发表的「The Tokenizer Tax」表格：66个单元格中66个误差在0.5%以内；cl100k_base下的平均税率算出8.03倍，原论文为8.0倍；o200k_base下为2.14倍，原论文为2.1倍。此外，他还用每个分词器的第二套独立实现做了交叉验证，44个「模型×语言」组合零误差。

一个容易被忽略的发现：许多FLORES句子并非Unicode NFC规范化形式——孟加拉语1,012句中有609句、旁遮普语573句、印地语93句。如果不先做规范化，token计数会漂移。这是一个对复现者而言非常实用的坑位提醒。

Unicode NFC（Normalization Form C） 是 Unicode 标准定义的规范化形式之一，将字符序列转换为预组合形式，例如把“基字符+组合元音符号”合并为单一码点。印度语言大量使用组合附加符号，同一文本在 NFC 与非 NFC 形式下字符数和字节数不同，分词器可能因此产生不同切分，导致 token 计数漂移。ITRANS 是一种将印度语言转写为拉丁字母的方案，保留 schwa 音并依据发音拼写，与口语化的 Hinglish 拼写习惯存在差异，这是罗马化实验结论需谨慎外推的原因。

尚未测量的另一半

作者明确划出了边界：GPU侧的实测——FP8 KV-cache在AMD MI300X上能挽回多少——尚未运行，所以文中没有任何GPU数字。项目仓库维护一份claims ledger，每个数字都指向一个结果文件和一个commit，没有对应行的数字不会被发布。这种可追溯的账本式记录，比单纯贴结论更值得借鉴。

仓库地址：indic-kv-tax。作者在文末抛出的问题值得每个做多语言部署的团队自问：你在服务哪种印度语言工作负载，又在为哪个分词器买单？