同一句意思，用中文、日文或阿拉伯语提问，往往比英文消耗更多 token——这不是错觉，而是分词器设计与训练语料分布共同造成的结构性成本差异。
发生了什么
Hacker News 上一条讨论（标题直译为“不用英文时 AI 模型更贵”）引发关注，核心观察是：主流大模型的分词器以英文语料为主要优化目标，非英文文本在切分后往往产生更多 token，而 API 计费、上下文窗口占用、推理算力都与 token 数直接挂钩。结果是，表达同样信息量的非英文请求，实际成本更高、可用上下文更短。讨论中也有开发者提到，部分语言在输出侧同样“更费 token”，进一步放大了差距。
为什么重要
这并非新问题，但一直缺少足够公开的讨论。分词器（tokenizer）是模型最底层、也最少被审视的组件之一：它决定了文本如何被切分成模型可处理的单元。英文在主流训练语料中占比极高，BPE 类算法自然会为高频英文片段（包括常见词、词根、空格组合）生成更长的合并单元，而非英文往往被切成更细碎的字节或字符级片段。
这意味着所谓“多语言能力”存在两层落差：一层是模型能否理解非英文，另一层是理解同样的内容要付出多少代价。前者已被大量基准测试覆盖，后者却很少被量化。对以英文为中心构建的计费体系而言，这实际上构成了一种隐性的语言溢价——用户为同样的语义支付不同价格。
影响与看点
对开发者，这直接影响成本模型：多语言产品的 token 预算不能简单按英文估算，上下文窗口的实际可用容量也会因语言而异。做 RAG、长文档处理或客服系统时，非英文场景的截断风险和费用超支需要单独评估。
对用户，尤其是中文、日文、韩文、泰文等使用者，同一订阅额度下的实际可用量低于英文用户，这种差异通常不会出现在产品说明里。
值得关注的方向有三个：一是分词器的多语言优化是否会成为模型迭代的显性卖点；二是计费方式是否会出现按字符、按语义或按语言区分的调整；三是基准测试体系是否会引入“同等语义下的 token 效率”这一维度。
一个独立判断：多语言成本差异本质上是训练数据分布不均的延伸，它不会随模型能力提升自动消失，反而可能因为长上下文和 Agent 场景的普及而被放大——token 效率正在从工程细节变成产品竞争力的一部分。
