同一段文字，三家大模型数出三个价

「Claude那行差了12%，Gemini那行反方向差了15%，没人说得清为什么。」一位工程师的预算表，暴露了AI行业最隐蔽的成本陷阱。

问题出在计数器上。OpenAI、Anthropic、Google三家的大模型，对同一段文字会给出完全不同的数字。不是近似，是系统性偏差。你的成本预测建立在沙滩上。

为什么token计数成了黑箱

大模型按token收费，但token没有统一标准。OpenAI用tiktoken库，公开了cl100k_base和o200k_base两种编码。Anthropic不公开Claude的分词器，模型文件封闭，没有pip install能装的库。Google Gemini用SentencePiece，配合Unigram语言模型，词表25.6万。

三家三种实现。OpenAI的BPE（字节对编码）按合并表逐对压缩。Google的Unigram考虑所有可能切分，选概率最高的路径。Claude的具体算法外界看不到。输入同样的字符串，输出不同的整数序列。

更麻烦的是获取方式。OpenAI的tiktoken本地运行，毫秒级返回。Claude必须调用网络端点POST /v1/messages/count_tokens。Gemini同样要走client.models.count_tokens(...)的服务端请求。后两者免费，但有速率限制，且依赖网络。

这意味着什么？你的成本估算工具如果内置了tiktoken，对Claude和Gemini的预测全是估算。估算误差在10%-15%区间浮动，取决于文本类型。

实测：三种文本的偏差现场

我们用一段代码测试了三家的计数差异。Python脚本同时查询OpenAI、Anthropic、Google的官方接口，打印并行结果。环境变量提前配置好三家密钥。

第一种情况：纯英文技术文档。三家的数字接近，偏差控制在3%以内。BPE和Unigram对拉丁语系的分词逻辑相似，空格和标点规则差异小。

第二种情况：混合格式——Markdown表格、代码块、JSON。差距拉开。Claude对缩进和换行的处理更激进，单个制表符可能拆成多个token。Gemini对代码符号的切分更细，花括号和方括号常独立成token。OpenAI的o200k_base相对"吝啬"，相同代码量数字最小。

第三种情况：中文与emoji。这里最混乱。Claude对CJK字符（中日韩统一表意文字）的切分颗粒度粗，常见词组合并为单token。Gemini的Unigram模型对高频中文搭配有优化，但生僻字可能逐字拆开。OpenAI介于两者之间，且对emoji的编码长度固定为2-4 token，另两家波动更大。

一个具体例子：字符串"你好世界"（含地球emoji）。OpenAI报6 token，Claude报4 token，Gemini报5 token。成本计算时按谁的标准？选错基准，月度账单预测直接失真。

工程师的应对规则

原文给出的工作法则很直接：绝不用你没在生产环境实际调用的分词器来报数。

执行层面三条：

第一，预算表按模型分栏，每栏调用对应厂商的官方计数接口。不要用一个数字乘以三家的单价。Claude的token数走Anthropic API，Gemini走Google SDK，OpenAI走tiktoken或API。

第二，缓存计数结果。Claude和Gemini的计数端点免费但有频率限制，批量预估时先落库，避免实时调用拖慢响应。

第三，监控实际偏差。跑一个月后对比预测token数与实际账单，计算每家模型的系统性偏移系数，修正后续预测模型。

这件事的隐蔽性在于：分词器差异不是bug，是设计选择。BPE追求压缩率，Unigram追求概率最优，各家词表训练语料不同。没有对错，只有不兼容。

但商业后果真实。一个每月消耗千万token的中型企业，15%的预测误差意味着数万美元的成本漂移。财务团队追问时，工程师如果回答"分词器不一样"，会议室里没人想听这个解释。

行业层面的信号

三家厂商对分词器的态度本身就有信息量。OpenAI选择开源tiktoken，降低开发者接入门槛，同时巩固其标准制定者地位。Anthropic封闭Claude的分词器，可能是技术保密，也可能是预留调整空间——词表可以随时更新而不破坏外部依赖。Google文档化SentencePiece参数，走中间路线，既展示透明度，又保留服务端控制的灵活性。

这种分化短期内不会收敛。大模型竞争进入精细化运营阶段，token计价是核心商业杠杆。厂商有动力保持分词器的差异化，甚至策略性调整词表来影响"感知成本"——同样输出，token数少看起来便宜。

对采购方而言，这意味着比价不能看单价。Claude 3美元/百万token和GPT-4 5美元/百万token，如果前者对同一段文本数出更多token，实际成本差距会缩小甚至逆转。必须按真实工作负载跑一轮三家计数，再折算有效单价。

技术团队现在需要一张新表：不是"模型-单价"对照表，是"文本类型-模型-实际token系数"的三维矩阵。文本类型至少分：英文长文、代码、多语言混合、结构化数据（JSON/XML）、对话历史。每类抽100条样本，跑通三家计数，建立误差分布。

这件事的麻烦程度，和当年云厂商的"同规格虚机性能不一"类似。AWS的m5.large和Azure的D2s_v3都标2核8G，实际跑分差距20%。现在大模型的"token"成了新的不透明单位。

区别在于，云厂商最终推动了标准化基准测试（如SPEC Cloud）。大模型分词器的标准化，目前看不到动力。相反，随着多模态扩展，图像、音频的"token"定义还在快速演变，统一标准更加遥远。

你的成本预测流程，准备好应对这种碎片化了吗？