哪个 LLM 对你的语言最便宜？实测 tokenizer 成本

多语言文本没有唯一最便宜的 LLM。同一段文字实测下来，欧洲语言、印地语和韩语的计费 token 数 GPT-5.5 最少，中文是 Kimi K2.5 最省，日文则是 DeepSeek。Claude Fable 5、Opus 4.8 和 Sonnet 5 共用同一个 tokenizer（我们发送的每个样本，计数都完全一致），而且从来不是最省的那个：同一段英文，Claude 计 90 个原始 token，DeepSeek 只有 55 个；扣除框架后的溢价从日文的 1.3 倍到中文的 2.2 倍不等。token 是计费单位，所以两件价格页上很少看到的事情决定了你的输入成本：一种语言把语义压进字符的密度有多高，以及每个模型的 tokenizer 对该文字的压缩效果如何。这两者相乘，结果和按字符看的直觉并不一样。

TL;DR

• Claude Fable 5、Opus 4.8 和 Sonnet 5 共用一个 tokenizer，从来不是最省的：在任何场景下都是最低计数的 1.2 到 2.3 倍。
• 最省的 tokenizer 随语言而变：欧洲语言、印地语、韩语是 GPT-5.5；中文是 Kimi；日文是 DeepSeek。
• 按字符看 CJK 差 3 倍，但按语义看，中文几乎持平，日文和韩文则是 1.5 到 2.4 倍。
• 成本等于文字密度乘以 tokenizer 覆盖度；覆盖不足会成倍放大（GLM 对印地语的计费是其英文的 4.9 倍）。
• 本地化很少省钱；按 token 把模型和语言匹配起来。

计数于 2026-07-08 通过 Synthorai 网关实测，始终使用各家自己的计数，从不用本地 tokenizer。每次重复的计数都完全一致。

token 才是计费单位，文本不是

计费按 token 算，但 token 既不是字符，也不是单词。每个模型都自带 tokenizer，各有各的词表，同一句话在每个 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% 以内。

计数始终用各家自己的：Claude 这条线通过真实的 Messages 调用读取 usage.input_tokens（网关目前不代理 count_tokens），OpenAI 兼容模型则通过一个小调用读取 usage.prompt_tokens。本地 tokenizer 和账单对不上，正是这样做要避免的问题。有一个对照很关键：每个请求都带有固定的框架（chat template、角色标记），约几个 token，所以我们测量一个两字符的基线样本并把它减掉。本文的每个比值都已扣除这层框架，比较的是文本本身，而不是框架。

同一段文本，五种 tokenizer

下面这张表列出了叙事段落在不同语言、不同 tokenizer 下的原始输入 token 数。三个 Claude 模型共用一列，因为它们在每个样本上返回的 token 数都完全一致（后面会细说）。另外两个段落也是同样的规律，放在文末合并展示。字符列是各语言版本的长度——不同文字表达信息的密度不同，同样的内容中文用 77 个字符就够了，英文却要 254 个。

有两点很明显。Claude 那列三个模型只有一个数字，是因为 Claude Fable 5、Opus 4.8 和 Sonnet 5 在每个样本上返回的计数都完全相同——不管是各种语言、代码还是 JSON：这三个模型都沿用了 Opus 4.7 引入的那套 tokenizer，所以一个模型的计数就是全部三个的计数。而且除了印地语这一行，这一列在每一行都是最大的；印地语这行 GLM 的 192 更糟。下面按净 token 数归一化，让每种语言下最省的模型读作 1.00（先减去了固定开销，所以这些比值和上面原始单元格直接相除对不上）：

英文那行的四个 1.00 并不是四舍五入的结果：DeepSeek、GLM、GPT-5.5 和 Kimi 在这段上的净 token 数都正好是 50。Claude 在这段上是最省 tokenizer 的 1.3 到 2.2 倍，三段合起来是 1.2 到 2.3 倍——这是词表本身的特性，对该模型生命周期内的每一次调用都成立。技术段落和新闻段落也重现了这个排名：两段相加，Claude 中文按 212 个净 token 计费，Kimi 只要 114（1.9 倍），印地语 477 对 GPT-5.5 的 210（2.3 倍）。但在这之下并没有一个统一的赢家。最省的那一列会随语言变化：

• GPT-5.5 在德语、法语、西班牙语、意大利语、印地语和韩语上最省，在英语上并列最省（并列以及 fr/es/it 只在叙事段落成立）。它的词表偏向拉丁文字，在天城文和谚文上也扛得住。
• Kimi K2.5 在中文上最省，在整个 CJK 上都有竞争力。
• DeepSeek-v4 在日语上最省，中文上紧随其后。
• GLM 5.2 在大多数语言上处于中游，但在印地语上给出了整张表最差的单元格：叙事段落是最省 tokenizer 的 2.59 倍（GPT-5.5 只要 69，它要 179 个净 token），在正式段落上更糟，也是唯一一列连 Claude 都比不过的。

这种代价不止体现在散文上。在那个 Python 函数上 Claude 是最省的 1.61 倍，JSON 工具调用上是 1.29 倍。JSON 差距小一些，因为结构化文本大部分是标点和短的 ASCII 键，各家 tokenizer 处理起来都差不多。对于一个长时间运行、每一轮都要重放大型工具 schema 的 agent，这种每轮的开销会累积，这正是缓存发挥作用的地方。prompt-caching 系列讲解了其中的机制。

按字符计费的陷阱：CJK 看起来比实际计费更贵

上面的表格比较的是不同模型。现在把模型固定下来，语言依然会影响 token 数，但影响方式和你从原始字符数看到的并不一样。最常被引用的 tokenizer 指标是每字符 token 数，而 CJK 在这个指标上遥遥领先：在 Claude 上，中文每 100 个字符约 114 个净 token，韩文 106，日文 94，而英文只有 32。只看这一列，CJK 像是要多付 3 倍的税，但这是看错了列：你付费的是含义，不是字符，而对齐后的段落在每种语言里表达的是同样的含义。下面是 Claude 上叙述性段落的两种视角：

右边这两列给出的结论互相矛盾，而中文是最极端的例子：整组语言里每字符密度最高，但在这个段落上按含义算只比英文贵 1.07 倍。英文用 254 个字符表达的内容，中文只用 77 个字符，于是很高的每字符费率乘以极少的字符数，两者几乎相互抵消。三个段落综合来看，这种抵消依然成立，但也不是什么魔法：中文平均是 Claude 自身英文的 1.17 倍，随模型不同在 0.95 倍到 1.32 倍之间，接近持平，而不是每字符那一列吓人的 3 倍。

日文和韩文回答了接下来最自然的问题：同样的错觉，但抵消更弱。两者都有很高的每字符密度，因为韩文的谚文和日文的假名大致是一个字符拼一个音节，而不像中文汉字那样把整个词塞进一个字符里。所以中文用 77 个字符说完的段落，韩文要 143 个字符，日文要 136 个。字符数更多再乘以很高的每字符费率，不会抵消，反而叠加：在 Claude 上，三个段落综合下来韩文按含义算平均是英文的 1.96 倍，日文是 1.56 倍，两者都实打实地贵，尽管它们的每字符那一列看起来和中文差不多。

德文正好是中文的镜像：每字符费率很低（48，接近英文），但字符数是这里所有语言中最多的（289，来自它的复合词），最终仍然是 1.68 倍。成本是这两个维度的乘积，单看其中任何一个都会误导你。

数字为什么会变：两个因素相乘

上面每张表背后其实是同一个公式：

一段文字的 token 数 =（表达这个意思需要多少字符）×（每个字符占多少 token）

第一个因素是书写系统的信息密度，这是语言本身的属性，跟模型无关。它是一条连续的谱系，而不是中文的特例。表意文字的中文把一个语素塞进一个字符里，处在最密集的一端。日语假名和韩语谚文是把发音拼出来的，密度更低，需要更多字符。天城文和拉丁字母则更稀。从中文到英文，每个字符承载的意义在稳步递减。

第二个因素是模型词表在这套文字里每个字符要花多少 token，这完全取决于模型本身。BPE tokenizer 会从训练语料中学习多字符的合并：见得多的文字能拿到紧凑的 token，见得少的文字则退化到逐字符甚至逐字节编码，一个字符可能变成两三个 token。同样这三种语言，每个字符净占的 token 数如下：

这张表说明了三件事。中文在总量上显得特殊，是因为它在第一个因素上处于极端：即便 Claude 对中文的压缩很弱（每字符 1.14 个 token，还把部分汉字拆成两个），也架不住总共才 77 个字符，总量做不大；而中国训练的模型压缩得足够好（0.52 到 0.58），最终跟它们自己的英文水平相当。印地语的溢价来自第二个因素，而非密度：GLM 每个天城文字符要花 0.91 个 token，接近一字符一 token，因为它的词表几乎没有多字符的天城文合并；而 GPT-5.5 只花 0.35，因为它覆盖了整个音节簇——同一套文字上的覆盖差异。Claude 则是哪儿都高，因为它每字符的占用率连英文都高（0.32，而 DeepSeek 是 0.20），这是模型层面的基线，会叠加在语言本身的影响之上。

这些都不是我们这七个模型的偶然特性。研究文献把这个现象称为 token 溢价，Petrov 等人（NeurIPS 2023）在数百个语言对上做了测量，发现的正是这两个根本原因（表达同一意思的字符数不同，tokenizer 对不同文字的覆盖不同），低资源语言的溢价最高可达 15 倍，后果也一样：成本更高、延迟更高、可用的 context window 更小——因为高溢价语言在同样的 context 预算里塞进的意义更少。随着厂商持续投入，这个差距也在缩小：独立测量显示，在 GPT-3 时代的词表上中文比英文多出 182% 的 token，到 GPT-4o 的词表上是 24%，跟我们在 GPT-5.5 上测到的 32%、以及在中国训练模型上测到的持平结果都很接近。覆盖率是用词表槽位换来的，而厂商还在继续买。

本地化真的能省钱吗？

看完前面讲“陷阱”的部分，很容易得出两个结论：“Claude 在各语言上开销都差不多，所以不用管本地化”，以及“国产模型处理中文很便宜，所以本地化能省钱”。这两个结论都错了。下面是每种语言相对于该模型自身英文的开销，取三段文本的平均值，只列出三段都齐全的五种语言：

Claude 并不是各语言都持平：韩文是英文的 1.96 倍，印地文 2.40 倍。中文接近 1.17 倍只是单一语言上的巧合，不是模型本身的特性。国产模型在中文上也没有比英文更省，只是勉强追平：整张表里最好的一格是 Kimi 的 0.95 倍，比它自己的英文低 5%，其余每一格都持平或更贵。到了印地文、日文和韩文，这些模型的额外开销反而比 Claude 更大，而不是更小，因为这些文字离它们的训练重点更远。规律不是“某家厂商便宜”，而是每个模型相对于自身英文最省的，都是离它训练数据最近的语言。

文本语域也会改变这些数字。轻松的叙事体是最省的场景；技术类和新闻类文本几乎会抬高每一个倍率，因为术语和外来词恰恰是非拉丁词汇缺少合并 token 的地方。在 Claude 上，德文从 1.68 倍（叙事体）涨到 2.29 倍（技术类），GLM 的印地文在新闻类文本上达到英文的 5.98 倍。只用一段文本做基准，会偏袒那段翻译最省的语言，所以单看叙事体时中文在 Kimi 上是 0.80 倍，三段一起算就变成了 0.95 倍。

不过“相对于自身英文”本来就是个错误的视角。你实际付的是绝对 token 数，而在这个维度上，九种语言里 Claude 有八种最贵，唯一比它更差的是 GLM 的印地文那一列。所谓“相对于 Claude 英文很便宜”的中文内容，叙事体在 Claude 上仍然是 88 个净 token，在 Kimi 上只有 40 个。所以正确的做法不是为了省钱去做本地化，而是让模型匹配语言：中文用 Kimi 或 DeepSeek，印地文和韩文用 GPT-5.5，日文用 DeepSeek。Claude 在任何语言上都不是 token 成本的赢家，尽管它在质量上可能仍然胜出。

数量只是账单的一半

token 倍率只有和单价放在一起才有意义，而且两者会相乘放大。Claude Fable 5 的输入价格是每百万 token 10 美元，Opus 4.8 是 5 美元，Sonnet 5 在优惠价结束后是 3 美元；处理中文时，它们共用的 tokenizer 还会把同样的文本按最省 token 模型的 2.2 倍来计数。于是 token 数量上的溢价，会在原本就存在的费率差之上再叠一层——相对于你本来会路由过去的那个备选模型而言。反过来也成立：某个模型可能计数很省，但因为费率高，每次调用反而更贵。单看任何一个数字都说不清账单。这里不列其他厂商的费率，因为费率变得比 tokenizer 快得多；上面这些计数才是这道计算题里更稳定的那一半。

务实的做法是别再比标价，而是比有效输入成本：拿你真实的流量组合，在每个候选模型上分别计数，再乘以该模型的输入费率。在以中文或韩语为主的产品上，这样重新排序可能会颠覆哪个模型最便宜的结论，而且差距稳定在 1.5 到 2 倍，不是可以忽略的舍入误差。这跟做缓存时道理一样：真正该看的数字是按命中率加权后的有效成本，而不是标称费率，provider comparison 里对此做了推演。这个故事在版本之间的切面——为什么同样的英文 Sonnet 5 比 Sonnet 4.6 多算 41%——见 Sonnet 5 tokenizer 那篇。

结论

• token 成本 = 文字体系的密度 × tokenizer 的覆盖度。语言决定第一个因子，模型决定第二个，单看任何一个都会误导。
• Claude Fable 5、Opus 4.8 和 Sonnet 5 在每种语言上都是最省模型的 1.2 到 2.3 倍，因为它们即便在英文上单字符费率也很高。
• 最省的模型因语言而异：欧洲语言、印地语和韩语用 GPT-5.5，中文用 Kimi，日语用 DeepSeek。GLM 在印地语上最弱，接近每字符一个 token。
• 正式和技术性文体在几乎所有语言里都会推高倍率；用你真正会上线的文体去做基准测试。
• 别为了省钱做本地化；先按绝对 token 数把模型和语言匹配好，再乘以各模型的费率来比较有效成本。

常见问题

哪个 LLM tokenizer 最便宜？ 这取决于语言。在同一批对齐文本上测试七个模型后，GPT-5.5 在欧洲语言、印地语和韩语上最省（英语上与其他并列），Kimi K2.5 在中文上最省，DeepSeek-v4 在日语上最省。Claude 系列（Fable 5、Opus 4.8、Sonnet 5）在任何语言和文体上都不是最省的，token 数是最低值的 1.2 到 2.3 倍。

Claude Fable 5、Opus 4.8 和 Sonnet 5 用的是同一个 tokenizer 吗？ 是的。三者在每个样本上的 token 数完全一致，无论是各种语言、代码还是 JSON 都一样。它们用的是 Opus 4.7 引入的那个 tokenizer，所以在一个模型上的计数可以直接套用到另外两个。Fable 5 账单更高，纯粹是因为它的单 token 价格更贵。

在 Claude 上中文比英语贵吗？ 略贵：按语义计算是 1.17 倍，这是三段文本的平均值（在中国训练的模型上则基本持平）。按字符看差距要大得多（每 100 个中文字符约 114 个净 token，英语只有 32 个），但中文表达相同语义只需要大约三分之一的字符量，所以总量几乎抵消了。

日语和韩语的表现和中文一样吗？ 只对了一半。它们和中文一样有很高的单字符密度，但谚文和假名是拼读表音的，同一段内容要用多得多的字符（日语 136、韩语 143，而中文是 77）。这样一来单字符高费率就抵消不掉了，所以在 Claude 上按语义计算，日语约为英语的 1.6 倍，韩语约为 2 倍；在七个模型上分布在 1.5 到 2.4 倍之间。

我该怎么针对自己的 prompt 来测量？ 用你实际线上会用的文体，把几条真实 prompt 分别发给每个候选模型，然后从 provider 返回的 usage 字段里读取它自己算出的 input token 数，别依赖本地 tokenizer。单独一段友好的文本可能会让某种语言的数字虚低约 20%，所以要多用几段。最后把每个计数乘以该模型的 input 价格，就能得到你实际流量下的有效成本。

← 返回博客