北京
一次偶然的代理抓包，暴露了AI计费体系里一个被大多数人忽略的事实：同样的文本，不同模型计费时token数可能相差20%。
一位开发者在本地运行捕获代理审计token时，发现自己的编码代理CLI连续派生了两个子代理——任务相同、工作目录相同、代码路径相同，唯一区别是一个被路由到中档模型，另一个被路由到小模型。由于代理记录了完整的请求体，他得以逐字节对比这两个请求。
字节几乎相同，计费却差出20%
两个请求体分别为615,341字节和617,134字节，相差仅1,793字节（约0.3%）。系统提示词脚手架、工具定义、对话历史、任务描述——所有内容都几乎一致。如果token数是文本本身的属性，这两个请求的计费token数应该相差无几。
但实际计费结果令人意外：中档模型的请求被计为246,525个输入token，而小模型的请求虽然字节数还多了0.3%，却只被计为196,892个输入token——少了49,633个，降幅达20.1%。换算成每字节token数，中档模型为0.390，小模型为0.310。
需要强调的是，这里的“计费token”不是估算值，而是API响应中实际返回的计费字段——也就是决定请求成本的那个数字。这是供应商自己的用量统计系统为近乎相同的输入分配的数字。
token数是“请求+模型”的属性，不是请求本身的属性
这个发现指向一个更本质的结论：token数不是请求的属性，而是（请求，模型）这个二元组的属性。同样的字节，在不同模型的token化或计费规则下，会产生不同的数字。
作者也坦诚地划定了结论的边界：他直接证据证明的是计费差异本身——同一对请求，字节几乎相同，计费token差20.1%，且只测量了一次。最可能的机制是两个模型使用了不同的tokenizer词表，导致同一段文本被切分成不同数量的片段。这是此类现象的标准解释，也与观察结果吻合。
但他并未做隔离机制的实验：没有离线用各模型的tokenizer对同一字符串做分词并直接计数，也没有排除计费口径差异的可能性——比如缓存命中内容、工具定义开销，或供应商端其他计费范围差异，而非tokenizer本身的差异。
对普通开发者而言，这个发现的实用价值在于：在比较不同模型的成本时，不能假设“同样的输入=同样的token数”。选择模型时，除了关注单价，还应考虑同一任务在不同模型下的实际token消耗差异——这可能比价目表上的单价差异更影响最终成本。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
