不同分词器对中文token计数差异高达20%

同一段文本过两个分词器，结果差了 20%。

这是一个你花五分钟就能复现的小实验。取一段中文文本，用两个分词器分别处理，然后比较结果：

cl100k_base（GPT-3.5/4 系列模型的编码器）：2,496 tokens

o200k_base（GPT-4o 类模型）：1,949 tokens

同一段字符串，同样的语义，却差了 20%。两者都没有「错」—— 分词器本质上就是词表，不同的词表只是把同一段文本切在了不同的地方。

真正的问题在于：一旦你用错了分词器去估算成本，就麻烦了。

DeepSeek 估算结果存在结构性偏差

DeepSeek 使用的是自己的词表，而这个词表的公开程度远不及 OpenAI。所以所有声称能估算 DeepSeek 用量的成本工具，实际上都是在用一套基于不同数据训练的 tiktoken 编码器来近似计算。这个误差不是四舍五入的问题，而是结构性的偏差——方向明确，且因语言而异：中文文本受损更重，因为词表匹配度更差。

我见过一些仪表盘展示 DeepSeek 调用的「估算 token 数」，偏差高达 20-30%。没人指出来，那个数字看起来就是权威的。

修复成本为零

每一个 DeepSeek API 响应都包含真实的 token 计数。input_tokens、output_tokens，以及缓存命中的调用还有 cache_hit_tokens，全部都返回在响应对象里。

直接读取这些真实数据，别再估算了。如果你的成本工具显示的数字不是来自真实 API 响应，那它就是一个穿着仪表盘外衣的猜测。

为什么这个问题比听起来更重要

成本优化会放大测量误差。上周我写的关于 30 倍缓存杠杆的文章，核心依赖的是 cache hit tokens——如果你的工具在输入端就数错了 20%，那你的缓存命中率也会错 20%，后续每一个优化决策都会继承这个误差。你无法管理你测量错了的东西。

这对你的技术栈意味着什么

• 如果你追踪 LLM 成本，请记录响应里的 token 字段，而不是估算值
• 如果某个工具声称支持 DeepSeek，请问清楚它用的是什么分词器
• 对于中文占比高的工作负载，对任何估算值都要比平时更警惕

最后一点正是 SpendGuard 选择直接读取真实响应计数的原因：缓存命中率作为一等公民指标，按模型和按项目分别统计，数字里没有任何猜测成分。开源、本地优先：github.com/caresotin/spendguard。

这周去查一下你自己的数字。如果你的成本工具无法告诉你数据从何而来，答案就在那里。