分词器不同造成的 token 价差是怎么回事？

同一段中文，发给不同的大模型，算出来的 token 数可能差出一大截。分词器不同，价差就从这里来。

同一段中文，两种身价

分词器决定「一个字被切成几块」。切得细，token 数就多；切得粗，token 数就少。主流模型的词表大小和切分规则各不相同，同样一段五百字的中文，在不同模型里可能是 800 个 token，也可能是 1200 个。

而 API 几乎都按 token 计费，输入输出分开算。于是同一段文本，换个模型发，账单就变了。这不是涨价，是计量单位不同。

分词器为什么会让 token 数不同

词表是训练时定死的。词表里收录的常见词越长、越完整，切分时越能「一口吃下一个词」；词表偏小或偏英文的模型，遇到中文只能按字甚至按字节切，token 数立刻膨胀。

数字和符号是另一个隐形大头。一篇带大量表格、日期、编号的文档，切碎之后的 token 数可能远超纯文字段落。做数据处理的团队常在这上面吃亏：预估成本按纯文本算，实际账单翻一倍。

几类常见文本，被切碎的程度差别很大。

可带走的判断是：看模型卡片时，除了单价，还要看它的分词器对中文友不友好。中文占比高的业务，这项差异会被放大成真金白银。DeepSeek、Kimi 的 API 计费都按 token 结算，单价表里能看到输入输出分别标价，对照着算更清楚。

计费口径与上下文占用

价差不只体现在账单上，还体现在上下文窗口里。窗口是按 token 算的，同样一份文档，切分粗的模型塞进去占的位置小，留给回答的空间就大；切分细的模型可能还没读完文档，窗口先满了。

做长文档问答、批量摘要这类任务时，分词效率直接影响一次请求能带多少材料。把 token 单价和同样文本的 token 数乘起来，才是真实成本。

• token 单价：模型卡片上的每千 token 价格
• 实际 token 数：同一段文本在目标模型里的占用
• 真实成本：两者相乘，输入输出分开算
• 省钱动作：选中文友好的分词器、精简输入、约束输出

省钱的三个着力点

一是选对模型：中文为主的场景，优先挑中文友好的分词器。二是精简输入：删掉客套话和重复说明，能省下可观的输入计费。三是管住输出：用提示词约束回答长度，别让模型自由发挥。

三个动作叠加，账单常常能砍掉三成以上。相关话题可以对照稀疏化和剪枝的瘦身差异，以及满血版和蒸馏版的成本差，还有合并模型和原版的区别。

批量场景还有一个技巧是缓存。相同的系统提示、重复的文档前缀，在支持缓存折扣的平台上只需付一次钱，后续请求按缓存价结算。把不变的内容放前面、把变化的内容放后面，命中率会高很多。

换算工具也不难找。主流平台大多提供在线的 token 计算器，把文本粘进去就能出数；开源社区也有可以直接调用的分词库，适合嵌进自己的数据处理流程，批量预估成本。

需要留意的是，模型升级可能换分词器，昨天算好的 token 数今天就得重算。把分词器版本记进项目文档，升级时才能第一时间发现成本曲线的变化。

关于token价差的三个常问问题

• token 数和字数能换算吗？：没有固定比例，中文大致一字一到两 token，英文更低，具体要看模型的分词器。
• 便宜一定是因为分词器吗？：不一定，也可能是模型规格、定位不同，把单价和 token 数放一起看才准。
• 自己能改分词器吗？：普通用户改不了，那是训练阶段定死的配置，只能在选型时挑选适配的。