Token 税会把语言差异写进账单
AI 服务的标价通常按 token 计算，但不同语言进入模型后的长度并不一致。上个月，Coalition for Language Equity in AI Research 发布研究，给这种差异起了个名字：隐性 token 税。
我最初以为这只是分词效率问题。看到具体数据后，我才意识到它会直接改变开发者的成本模型。
研究覆盖了互联网最流行的 20 种语言。不同语言处理同一段提示所需的 token 量相差很大，最昂贵语言使用的 token 数量是最便宜语言的 1.5-5 倍。扩展到 200 种语言后，一个 AI 模型的 token 成本差距甚至增加了 17 倍。
最昂贵语言使用的 token 数量是最便宜语言的 1.5-5 倍。
这项研究触及了我最在意的定价公平。开发者选模型时，常比较单价、上下文长度和速度。很少有人会把提示语言纳入统一基准。
同一句“帮我订一张明天去上海的票”，换成中文、英语或其他语言，token 数可能完全不同。厂商按输出和输入 token 收费，用户却只看到统一套餐。多语言带来的额外消耗，往往被藏进后台。
分词器决定了谁承担成本
分词机制大致有两个方向。模型可以把文本切成常见词块，也可以切成更细的子词。词表对某种语言覆盖不足时，同一句话会被切成更多片段。
模型厂商未必缺少英语语料。真正影响结果的是，训练数据和词表里哪些语言被充分覆盖。罕见语言会遭遇更多碎片、更多 token、更长上下文。
模型的 token 成本差距甚至增加了 17 倍。
延迟和上下文容量也跟着变化。token 数量越多，处理时间通常越长，有效上下文越少。计算资源有限的地区承担了这部分额外负担，研究因此把 token 税和 AI 经济的参与范围联系起来。
我不同意把这种差异完全归因于用户写法。拼写变体、方言和混合表达确实会增加分词难度，但主流语言之间已经出现了明显差距。这说明词表覆盖和训练分布拥有定价权。
开发者若只拿英文基准压低单次调用成本，算出来的毛利可能经不起多语言用户使用。我的判断很直接：模型选型应该按产品真实语言分布测试，不能沿用英文榜单。
产品定价需要加入语言系数
多语言产品至少需要三项测试：同一语义在不同语言下的 token 数、输出速度、达到相同任务效果所需的调用次数。只测第一项仍不完整，因为用户可能用更多轮次补足模型对某种语言的理解差距。
成本测算也要拆开看。输入 token、输出 token、缓存命中、重试次数和工具调用都可能影响最终账单。研究里提到的公司位于不同城市，实际连接和计算资源也有差别。这属于模型之外的变量。
我更关注产品端如何处理。可以按语言维护独立基准，给高价语言保留更高毛利空间。也可以按任务完成量定价，减少语言长度对用户的影响。还可以把常用语言与专业术语加入测试集，在上线前计算每类用户的预期成本。
这类调整会影响团队的商业模式。过去大家默认用户获得相同能力，平台也按相同资源消耗收费。词表覆盖让部分语言天然消耗更多资源，继续假装成本完全相同，会把技术差异转嫁给用户。
班加罗尔的初创公司可能需要为每次提示和完成支付附加费，奥斯汀的竞争对手则无需支付。
我的实践习惯一向是先测真实输入，再谈统一价格。这篇文章也提醒我，测试集不能只由英文开发者编写。语言分布来自用户日志，定价系数也应该跟着日志更新。
结尾
隐性 token 税最终会进入产品决策，也会暴露模型厂商不愿公开的语言差异。开发者会继续追求更低的调用成本，用户却可能因为母语不同而支付更多。
我还没有找到完全公平的定价方式。按 token 计价透明，却无法消除语言差异；按任务收费更接近用户结果，又要求团队持续追踪真实效果。
如果你的产品已经支持多种语言，你会选择统一价格、按语言调整价格，还是彻底改用按任务收费？