哪款 LLM 处理你的语言最便宜？实测分词成本
目录
处理多语言文本时，没有一款 LLM 始终最便宜。对同一段内容进行实测，GPT-5.5 处理欧洲语言、印地语和韩语时计费 token 最少，Kimi K2.5 处理中文最省，DeepSeek 则在日文上最省。Claude Fable 5、Opus 4.8 和 Sonnet 5 共用同一个 tokenizer，我们发送的所有样本计数都完全一致，但从未拿到最低计数。同一段英文在 Claude 上计为 90 个原始 token，DeepSeek 只计 55 个；扣除固定开销后，Claude 的额外成本从日文的 1.3x 到中文的 2.2x 不等。token 是计费单位，因此输入成本取决于定价页上很少展示的两个因素：一种语言能用多少字符表达相同含义，以及各模型的 tokenizer 对这种文字系统压缩得有多好。两者相乘后的结果，往往和按字符比较得到的印象完全不同。
TL;DR
- Claude Fable 5、Opus 4.8 和 Sonnet 5 共用一个 tokenizer，从未拿到最低计数：在所有语言中都是最低值的 1.2-2.3x。
- 最省 token 的 tokenizer 随语言变化：欧洲语言、印地语和韩语是 GPT-5.5，中文是 Kimi，日文是 DeepSeek。
- 按字符看，CJK 的成本像是高出 3x；按相同语义比较，中文接近持平，日文和韩文则高出 1.5-2.4x。
- 成本等于文字系统密度乘以 tokenizer 覆盖率；覆盖不足会进一步放大成本，GLM 处理印地语时的 token 数是其英文的 4.9x。
- 本地化很少能省钱；应按 token 数为不同语言选择模型。
计数通过 Synthorai gateway 于 2026-07-08 测得，始终采用各 provider 自己返回的计数，从未使用本地 tokenizer。每组测试重复多次，计数都完全一致。
计费单位是 token，不是文本
计费按 token 进行，但 token 既不是字符，也不是单词。每个模型都有自己的 tokenizer 和词表，同一句话在不同模型上会被拆成不同数量的 token。这个数量再乘以每 token 单价，因此有两个变量同时影响成本：文本会变成多少个 token，以及每个 token 的价格。
大多数定价页只展示第二个数字。本文测量第一个。我们向七个模型（claude-fable-5、claude-opus-4-8、claude-sonnet-5、deepseek-v4-flash、glm-5.2、gpt-5.5、kimi-k2.5）发送了三组语义对齐的段落，并读取每个模型计入输入账单的 token 数。
一篇日常叙事文本（周六集市的故事）包含九种语言；一篇技术说明（使用指数退避进行重试）和一篇新闻简报（市政预算表决）包含英文、中文、日文、韩文、德文和印地语。测试集还包括一个 Python 函数和一段 JSON tool-call 数据。非英文版本由机器翻译生成，要求忠实原文、不得压缩，并经过人工抽查。翻译文本的冗长度确实会干扰结果，后文关于语体的章节将这一影响范围限定在约 20%。
计数始终采用 provider 返回的结果：Claude 系列通过真实的 Messages 调用读取 usage.input_tokens，因为 gateway 目前不代理 count_tokens；兼容 OpenAI 的模型则通过小型调用读取 usage.prompt_tokens。本地 tokenizer 可能与账单不一致，而这种偏差正是我们要避免的。有一个控制变量必须处理：每次请求都带有固定 framing，包括 chat template 和 role marker，会产生少量 token。为此，我们测量了一个双字符基线样本并将其扣除。本文所有比例都排除了这部分固定开销，比较的是文本本身，而不是 framing。
同一段文本，五种 tokenizer
下表给出了日常叙事段落按语言和 tokenizer 统计的原始输入 token 数。三个 Claude 模型合并为一列，因为它们在所有样本上返回的计数都完全相同，后文会进一步说明。另两组段落呈现相同规律，并将在后文汇总。字符数列表示对应语言版本的长度。不同文字系统表达含义的密度不同，因此中文用 77 个字符就能表达英文需要 254 个字符才能表达的内容。
| 语言 | 字符数 | fable-5 / opus-4-8 / sonnet-5 | deepseek-v4 | glm-5.2 | gpt-5.5 | kimi-k2.5 |
|---|---|---|---|---|---|---|
| en | 254 | 90 | 55 | 63 | 57 | 60 |
| zh | 77 | 96 | 50 | 58 | 69 | 50 |
| ja | 136 | 136 | 101 | 116 | 114 | 129 |
| ko | 143 | 160 | 104 | 123 | 93 | 129 |
| hi | 196 | 147 | 124 | 192 | 76 | 133 |
| de | 289 | 146 | 92 | 92 | 75 | 104 |
| fr | 259 | 111 | 76 | 79 | 66 | 93 |
| es | 253 | 112 | 75 | 79 | 66 | 91 |
| it | 272 | 127 | 84 | 91 | 78 | 100 |
这里有两个明显结论。Claude 一列同时代表三个模型，是因为 Claude Fable 5、Opus 4.8 和 Sonnet 5 对所有样本都返回了完全相同的计数，无论语言、代码还是 JSON 都一样。三者使用的都是 Opus 4.7 首次引入的 tokenizer，因此测出其中一个模型的计数，也就得到了另外两个模型的计数。除印地语外，Claude 在每一行的 token 数都是最高的；印地语中 GLM 的 192 更高。扣除固定开销后，将每种语言中最省 token 的模型归一化为 1.00，得到下表。因为先扣除了固定开销，所以这些比例不能直接用上表中的原始数字相除得出。
| 语言 | fable-5 / opus-4-8 / sonnet-5 | deepseek-v4 | glm-5.2 | gpt-5.5 | kimi-k2.5 |
|---|---|---|---|---|---|
| en | 1.64 | 1.00 | 1.00 | 1.00 | 1.00 |
| zh | 2.20 | 1.12 | 1.12 | 1.55 | 1.00 |
| ja | 1.33 | 1.00 | 1.07 | 1.11 | 1.24 |
| ko | 1.77 | 1.15 | 1.28 | 1.00 | 1.38 |
| hi | 2.01 | 1.72 | 2.59 | 1.00 | 1.78 |
| de | 2.03 | 1.28 | 1.16 | 1.00 | 1.38 |
| fr | 1.75 | 1.20 | 1.12 | 1.00 | 1.41 |
| es | 1.76 | 1.19 | 1.12 | 1.00 | 1.37 |
| it | 1.68 | 1.11 | 1.10 | 1.00 | 1.27 |
英文一行出现四个并列最低值，并非四舍五入造成：这段文本在 DeepSeek、GLM、GPT-5.5 和 Kimi 上都恰好是 50 个净 token。对这篇叙事文本，Claude 的 token 数是最低值的 1.3x 到 2.2x；综合三类文本，则是 1.2x 到 2.3x。这是词表本身的属性，在模型的整个生命周期中会影响每一次调用。技术文本和新闻文本也呈现相同排名。将两者相加，Claude 处理中文时计为 212 个净 token，Kimi 为 114 个，相差 1.9x；处理印地语时，Claude 为 477 个，GPT-5.5 为 210 个，相差 2.3x。但没有任何一个模型能在所有语言中胜出。最低计数会随语言变化：
- GPT-5.5 处理德文、法文、西班牙文、意大利文、印地语和韩文时最省 token，处理英文时并列最低。英文并列以及法文、西班牙文、意大利文的优势仅在叙事文本中成立。它的词表更偏向拉丁文字，同时对天城文和谚文也有较好支持。
- Kimi K2.5 处理中文时最省 token，在整个 CJK 范围内也很有竞争力。
- DeepSeek-v4 处理日文时最省 token，处理中文时也仅稍落后。
- GLM 5.2 在大多数语言中处于中游，但在印地语上的结果是整个矩阵中最差的：叙事文本中为最低值的 2.59x，GPT-5.5 只需 69 个净 token，它却需要 179 个；正式文本中的差距更大，也是唯一比 Claude 还差的一列。
这种额外成本并不限于自然语言文本。对 Python 函数，Claude 的 token 数是最低值的 1.61x；对 JSON tool-call 数据则为 1.29x。JSON 的差距较小，因为结构化文本主要由标点和简短的 ASCII key 构成，各 tokenizer 的处理方式相近。对于每轮都会重复发送大型 tool schema 的长期运行 agent，这项额外成本会逐轮累积，正适合通过缓存降低。prompt-caching 系列文章详细介绍了相关机制。
按字符比较的误区：CJK 看起来贵得多，实际账单并非如此
上面的表格比较的是不同模型。如果固定模型，只改变语言，token 数依然会变化，但变化规律和按字符观察得到的印象不同。最常被引用的 tokenizer 指标是每字符 token 数，而 CJK 在这个指标上明显最高：在 Claude 上，每 100 个字符，中文约为 114 个净 token，韩文为 106 个，日文为 94 个，英文只有 32 个。只看这一列，CJK 像是多了 3x 的成本。但这个指标并不适合衡量实际账单：费用对应的是语义，而不是字符数，对齐后的各语言段落表达的是相同含义。下表同时列出了 Claude 处理叙事文本时的两种视角：
| 语言 | 字符数 | 净 token 数 | 每 100 字符的 token 数 | 相对英文的 token 数 |
|---|---|---|---|---|
| en | 254 | 82 | 32 | 1.00 |
| zh | 77 | 88 | 114 | 1.07 |
| ko | 143 | 152 | 106 | 1.85 |
| ja | 136 | 128 | 94 | 1.56 |
| hi | 196 | 139 | 71 | 1.70 |
| de | 289 | 138 | 48 | 1.68 |
| it | 272 | 119 | 44 | 1.45 |
| es | 253 | 104 | 41 | 1.27 |
| fr | 259 | 103 | 40 | 1.26 |
最右侧两列得出的印象并不一致，中文最为明显。中文的每字符 token 密度是这组语言中最高的，但按相同语义比较，这段文本只比英文高 1.07x。英文需要 254 个字符才能表达的内容，中文只需 77 个字符。较高的每字符 token 数乘以很小的字符总数，两项几乎相互抵消。综合三篇文本，这种抵消仍然存在，但并非完全抵消：中文平均为 Claude 自身英文 token 数的 1.17x；根据模型不同，该值在 0.95x 到 1.32x 之间。整体接近持平，远没有按字符指标所暗示的 3x 那么高。
日文和韩文说明了另一种情况：同样存在这种错觉，但抵消效果较弱。两者的每字符 token 密度都很高，因为韩文谚文和日文假名大致按一个字形对应一个音节来拼写发音，不像汉字那样经常用一个字符承载整个词。因此，同一段内容中文只需 77 个字符，韩文需要 143 个，日文需要 136 个。更多字符再乘以更高的每字符 token 数，不但无法抵消，反而会叠加。在 Claude 上，综合三篇文本，韩文按相同语义计算的 token 数平均是英文的 1.96x，日文为 1.56x。两者确实更贵，尽管它们的每字符数据看起来与中文很接近。
德文则是中文的反面：每字符 token 数较低，为 48，与英文接近；但这里的德文文本有 289 个字符，是所有语言中最长的，这与德文复合词有关，最终 token 总数仍达到英文的 1.68x。成本是这两个维度的乘积，只看其中任何一个都会产生误导。
数字为何变化：两个因素相乘
上面所有表格都可以归结为一个公式：
一段文本的 token 数 =（表达相同语义所需的字符数）x（每字符 token 数）
第一个因素是文字系统的表达密度，它是语言属性，与模型无关。这是一个连续分布，并非只有中文特殊。表意文字中文通常每个字符都能承载一个语素，处于高密度的一端。日文假名和韩文谚文用于拼写语音，密度较低，需要更多字符。天城文和拉丁字母的密度更低。从中文到英文，每个字符承载的语义量持续下降。
第二个因素是模型词表处理某种文字时，每个字符需要多少个 token，这完全取决于模型。BPE tokenizer 会根据训练语料学习多字符 merge。训练中频繁出现的文字通常能形成更紧凑的 token；很少出现的文字则可能退化为逐字符甚至 byte-level 编码，一个字符可能被拆成两三个 token。以下是三种语言的净每字符 token 数：
| 每字符 token 数 | 中文 | 印地语 | 英文 |
|---|---|---|---|
| Claude | 1.14 | 0.71 | 0.32 |
| DeepSeek | 0.58 | 0.61 | 0.20 |
| GPT-5.5 | 0.81 | 0.35 | 0.20 |
| GLM 5.2 | 0.58 | 0.91 | 0.20 |
| Kimi K2.5 | 0.52 | 0.63 | 0.20 |
这张表能解释三个现象。中文在总数上表现特殊，是因为它在第一个因素上处于极端：即使 Claude 对中文的压缩较弱，每字符需要 1.14 个 token，部分汉字仍会被拆成两个 token，但整段文本只有 77 个字符，总数依然不会很高。面向中文训练的模型能将这一数值压到 0.52 到 0.58，因此中文总 token 数接近各模型自身的英文水平。印地语的额外成本来自第二个因素，而不是表达密度：GLM 处理每个天城文字符需要 0.91 个 token，接近每字符一个 token，因为其词表几乎没有多字符天城文 merge；GPT-5.5 通过覆盖完整的音节组合，将该值降至 0.35。这是同一文字系统上的词表覆盖差距。Claude 则在所有语言中都偏高，因为它即使处理英文，每字符 token 数也达到 0.32，而 DeepSeek 只有 0.20。这个模型级基线会与各语言自身的因素叠加。
这种现象并非我们测试的七个模型所独有。研究文献将其称为 token premium。Petrov et al. (NeurIPS 2023) 对数百组语言对进行了测量，发现了相同的两个根因：表达同一语义所需的字符数不同，不同文字系统的 tokenizer 覆盖率也不同。低资源语言的额外 token 数最高可达 15x，并会带来同样的后果：成本更高、延迟更大、可用 context window 更小，因为高 token premium 的语言会用更少的语义内容填满同样的 context 预算。随着厂商持续投入，这种差距也在缩小。独立测量显示，GPT-3 时代的词表处理中文时，token 数比英文高 +182%；GPT-4o 已缩小到 +24%，与我们在 GPT-5.5 上测得的 +32% 接近，也接近面向中文训练的模型上近乎持平的结果。扩大覆盖率需要占用词表空间，而厂商还在持续为此增加投入。
本地化能省钱吗？
看到上一节，很容易得出两个错误结论：“Claude 在不同语言上的成本基本相同，所以可以忽略本地化”和“中文模型处理中文便宜，所以本地化能省钱”。这两个判断都不对。下表列出了五种拥有完整三篇文本样本的语言，相对于各模型自身英文 token 数的平均值：
| 相对自身英文 | zh | de | hi | ja | ko |
|---|---|---|---|---|---|
| Claude | 1.17 | 2.11 | 2.40 | 1.56 | 1.96 |
| DeepSeek | 1.00 | 1.94 | 3.11 | 1.85 | 1.99 |
| GLM 5.2 | 1.03 | 1.77 | 4.89 | 2.03 | 2.31 |
| GPT-5.5 | 1.32 | 1.53 | 1.70 | 2.09 | 1.72 |
| Kimi K2.5 | 0.95 | 2.20 | 3.15 | 2.18 | 2.41 |
Claude 并非在不同语言上成本相同：韩文是其英文的 1.96x，印地语是 2.40x。中文接近 1.17x 只是单一语言上的特殊情况，并非模型的普遍属性。面向中文训练的模型处理中文时，也不是大幅低于英文，而只是接近持平。整张表中的最低值是 Kimi 的 0.95x，仅比自身英文低 5%，其他单元格都与英文持平或更高。对印地语、日文和韩文，这些面向中文训练的模型相对自身英文的额外成本反而比 Claude 更高，因为这些文字系统离其训练重点更远。规律并不是“某家厂商更便宜”，而是相对于模型自身的英文，各模型处理与其训练数据最接近的语言时通常最省 token。
语体也会改变这些数字。日常叙事文本是最有利的情况；技术和新闻文本会提高几乎所有语言的倍数，因为术语和外来词正是非拉丁文字词表最缺少 merge 的部分。在 Claude 上，德文从日常文本的 1.68x 上升到技术文本的 2.29x；GLM 的印地语在新闻文本上达到其英文的 5.98x。只用一篇文本做 benchmark，结果会偏向翻译最简洁、语体最友好的语言。单篇叙事文本中，Kimi 的中文为 0.80x；综合三篇文本后则是 0.95x。
但相对自身英文比较，本来就不是正确的成本视角。实际支付的是绝对 token 数，而 Claude 在九种语言中的八种都是最贵的，唯一更差的是 GLM 的印地语。某段中文内容“相对 Claude 的英文很便宜”，并不代表它的绝对 token 数低。同一篇叙事文本，Claude 处理中文需要 88 个净 token，Kimi 只需 40 个。因此，正确做法不是为了省钱而本地化，而是让模型与语言匹配：中文选 Kimi 或 DeepSeek，印地语和韩文选 GPT-5.5，日文选 DeepSeek。Claude 在任何语言中都不是 token 成本最低的模型，但它仍可能在质量上胜出。
token 数只决定账单的一半
token 倍数只有与每 token 单价结合才有意义，两者会相乘。Claude Fable 5 的公开输入价格为每百万 token $10，Opus 4.8 为 $5，Sonnet 5 的推广期结束后为 $3。处理中文时，三者共用的 tokenizer 还会将同一文本计为最省模型的 2.2x，因此 token 数差距会进一步放大模型与候选路由目标之间原有的单价差距。反过来也可能出现：某个模型计出的 token 较少，但由于单价高，每次调用仍然更贵。只看任何一个数字都无法得出最终账单。本文没有列出其他厂商的价格，因为价格的变化速度快于 tokenizer；上面的 token 计数才是计算中更持久稳定的一半。
实际比较时，不要只看标价，而应计算有效输入成本：使用真实流量分布，在每个候选模型上统计 token 数，再乘以该模型的输入单价。对于以中文或韩文为主的产品，这种计算可能会彻底改变最便宜模型的排序，而且差距会稳定在 1.5x 到 2x，并非可以忽略的误差。缓存也是同一个道理：真正重要的是按命中率加权后的有效成本，而不是标称价格。provider 对比文章详细分析了这一计算过程。不同版本之间的变化，例如 Sonnet 5 处理同一段英文时为何比 Sonnet 4.6 多计 41%，可参阅 Sonnet 5 tokenizer 文章。
结论
- token 成本等于文字系统密度乘以 tokenizer 覆盖率。语言决定第一个因素，模型决定第二个，只看其中任何一个都会产生误导。
- Claude Fable 5、Opus 4.8 和 Sonnet 5 在所有语言中都是最低 token 数的 1.2x 到 2.3x，因为它们即使处理英文，每字符 token 数也很高。
- 最省 token 的模型取决于语言：欧洲语言、印地语和韩文选 GPT-5.5，中文选 Kimi，日文选 DeepSeek。GLM 处理印地语的表现最差，几乎每个字符都要一个 token。
- 正式和技术语体会提高几乎所有语言的倍数；benchmark 应采用产品实际使用的语体。
- 不要为了省钱而本地化。应先根据绝对 token 数为语言匹配模型，再乘以各模型的单价，比较有效成本。
常见问题
哪款 LLM tokenizer 最便宜？ 取决于语言。对七个模型和相同语义的对齐文本进行测试后，GPT-5.5 处理欧洲语言、印地语和韩文时最省 token，处理英文时并列最低；Kimi K2.5 处理中文时最省，DeepSeek-v4 处理日文时最省。Claude 系列（Fable 5、Opus 4.8、Sonnet 5）从未拿到最低计数，在所有语言和语体中，token 数都是最低值的 1.2x 到 2.3x。
Claude Fable 5、Opus 4.8 和 Sonnet 5 使用相同的 tokenizer 吗？ 是。三个模型对所有样本都给出了完全相同的 token 数，无论语言、代码还是 JSON 都一致。它们使用的是 Opus 4.7 首次引入的 tokenizer，因此其中一个模型的计数可以直接用于另外两个。Fable 5 账单更高，完全来自更高的每 token 单价。
Claude 处理中文比英文更贵吗？ 略贵。按相同语义计算，三篇文本的平均值为 1.17x；面向中文训练的模型则大致持平。按字符看，差距会显得大得多：每 100 个中文字符约为 114 个净 token，英文只有 32 个。但中文只需约三分之一的字符就能表达相同含义，因此最终 token 总数几乎相互抵消。
日文和韩文的表现与中文一样吗？ 只相似一半。它们和中文一样，每字符 token 密度很高；但谚文和假名用于拼写语音，因此表达同一段内容需要更多字符：日文为 136 个，韩文为 143 个，中文只需 77 个。高每字符 token 数无法再被字符总数抵消。因此按相同语义计算，在 Claude 上日文约为英文的 1.6x，韩文约为 2x；在七个模型上则介于 1.5x 到 2.4x。
如何测量自己的 prompt？ 选择几条真实 prompt，使用产品实际上线的语体，分别发送到各个候选模型。应读取 provider 在 usage 字段中返回的输入 token 数，不要依赖本地 tokenizer。一篇语体友好的文本可能会让某种语言的结果偏低约 20%，因此应使用多个样本。最后，将每个计数乘以对应模型的输入价格，即可得到真实流量下的有效成本。