大模型的 Token 通胀：一个被忽视的成本陷阱

当我们谈论 AI API 的成本时，通常关注的是模型参数规模、推理速度，却忽视了一个根本性的问题：Token 正在经历一场静悄悄的通胀。

01 一个反直觉的事实

同样的 Grok-3 模型调用，不同的语言，成本可以相差一倍。这就是很多 AI 公司不会告诉你的"中文税"现象。

现象很直观：OpenAI、Anthropic、Google 的模型在处理中文时，token 消耗量通常是英文的 1.5-2 倍。成本也随之水涨船高。

原因隐藏在 Tokenizer 里。

Tokenizer 是大模型的"切词器"，它把文字切成模型能理解的最小单元——Token。

英文的 Tokenizer 基于空格和常见词根，一个单词通常对应 1-2 个 Token。"machine learning" → ["machine", "_learning"] → 2 个 Token。

中文没有空格天然的切分边界。一个"学习"就要占 1 个 Token，一句话下来，Token 数轻松是英文的 1.5 倍以上。

这就是为什么中文 Prompt 通常比英文 Prompt 更"贵"。

Token 通胀的本质是信息密度 vs 计算成本的错配。

语言的信息密度不同。中文在纯文字层面信息密度更高——一个汉字携带的语义信息往往超过一个英语单词。但 Tokenizer 不懂语义，它只认统计规律。

训练数据里英文占比高（大约 60-70%），Tokenizer 对英文的切分更精细。对中文就粗糙得多。结果是：同样的语义内容，中文被切成的 Token 更多。

这不是 bug。这是统计学习模式的必然结果。

Token 通胀的影响是真实的。

以一次 10K token 上下文的对话为例：

如果是高频调用场景（日均 thousands of requests），差异累积下来很可观。

很多创业者在计算 AI API 成本时容易忽略这一点。他们按 English-only 的定价模型做财务预测，结果上线后发现账单是预期的 1.5-2 倍。

这是一个典型的"隐性成本陷阱"。

中文开发者有几个实用的应对方式：

Prompt 压缩：在保证语义完整的前提下，尽量精简 prompt 指令。删掉冗余的"请""帮我"这类词。

混用方案：关键指令用英文（比如 system prompt），业务数据用中文。模型对英文指令的 token 效率更高。

批量处理：如果有多条任务，合并在一次 API 调用里处理。减少 API 调用的次数本身就是省钱。

换模型：部分模型（如 Claude 3.5 Haiku、Gemini Flash）对中文的 token 效率更高，适合非核心场景。

Token 通胀不只是中文的问题。

日文、韩文、阿拉伯语都面临类似的"多语言惩罚"。这是 AI 基础设施层面的结构性不平等——模型训练的语料分布决定了谁的成本更高。

林语堂当年用英文写《京华烟云》，不是没有原因的。当工具的设计本身偏向某种语言时，使用那种语言的人天然就占劣势。

今天的 AI Tokenizer 就是当年的打字机。

本文是写作风格研究的实战输出。核心观点：Tokenizer 是 AI 成本的结构性盲点，中文开发者需要意识到这个隐形成本。