【纯水】一种基于Tokenizer测试Opus4.7相关计费的方法

背景 这是今天在这位楼主的帖子下面突然想到的 星辰AI出来解释下呗 我说opus说话怎么一股异味,做了个探针查一下Tokenizer,对比一下官方订阅 这种测Tokenizer的方法一定程度上可以测出Opus4.7和其他模型之间的区别。但是值得注意的是有这样一种可能: 星辰AI出来解释下呗 上游由于...
【纯水】一种基于Tokenizer测试Opus4.7相关计费的方法
【纯水】一种基于Tokenizer测试Opus4.7相关计费的方法

背景

这是今天在这位楼主的帖子下面突然想到的

星辰AI出来解释下呗

我说opus说话怎么一股异味,做了个探针查一下Tokenizer,对比一下官方订阅

image

这种测Tokenizer的方法一定程度上可以测出Opus4.7和其他模型之间的区别。但是值得注意的是有这样一种可能:

星辰AI出来解释下呗

上游由于逆向渠道等原因自行添加了System prompt

Claude Code相关的订阅转出来本身就是需要有一个You are Claude Agent SDK之类的预填充prompt;此外有的时候会填几个统一的预填充的prompt头,大概原理是让Anthropic的开头建立缓存的时候缓存到一起之类的?或者添加随机性?

总之如果只看input_tokens,有可能会对应加一些随机的小常数(这实际上可能对应一些固定的手续费,或者可能会让缓存率偏低,所以理论上上下文比较长手续费占比可能比较高hh),按照这种分词器分出来的token数的比例,可能需要按照比较长的效果来评判。

方法

那么有没有什么说服力更强的方法呢?这里想到一种用output_tokens来交叉检验。具体来讲,我想到的方法有这几种:

  1. 重复prompt,例如:
原样输出下面的内容:“Hello! It looks like your message came through as just a period. How can I help you today?”

这个对应的Opus4.7的output_tokens应该是28,Opus4.6的是24

  1. 强制要求调用某个工具,并指定参数

这种可能可以一定程度上辨别工具调用会不会可能是提示词出来的。毕竟现在的模型格式遵循能力也挺强了,理论上如果是提示词出来的,那用的输出token可能会多一些。

结语

长期以来大家都在纠结于中转站的模型API真不真,无论站内站外大家都遇到很多这种掺水的事件,可以说是深恶痛绝。另一方面,Anthropic的模型又三天两头降智,更是带来诸多不便。

但是相对让人高兴的是,国内的模型迎头赶上,像是我在特定的Agent构造下和Coding领域下,GLM-5.1、Deepseek V4 Pro之类的模型完全能替代Opus 4.5/4.6的效果甚至做得更好。其中我最认同的还是Deepseek在Infra方面的努力。想来,那个SOTA模型token便宜到人人都能不限量用,将这些中转站在中间赚“剪刀差”空间基本消灭的一天应该已经能望见曙光了。

许愿一个Deepseek价格和上下文、GLM-5.1的编码和工具调用能力的模型.jpg

6 个帖子 - 5 位参与者

阅读完整话题

来源: linux.do查看原文