单价陷阱

Codex的负责人Tibo甩出了一组数字, 这组数字直接戳破了AI计费行业的遮羞布, 所有人都在拿着「每百万token多少美元」来来回回地比价, 将token当成了像克或者千瓦时那样的标准单位, 然而token根本就不是标准单位, 它仅仅是各家厂商自己切割文字的刀法存在差异罢了。

位于第二位的这家招牌之上所书写的乃是单价更为低下, 其看上去着实是相当划得来的。然而当你把整整一段文字全部运行完毕之后, 居首位的那一家实际扣除费用为十六美元, 而处于第二位的这家却需要二十美元。表面呈现出便宜态势的反倒价格更加昂贵起来, 这才是最为令人头疼不已的所在之处啊。

分词器差异

每一家厂商都运用自身所用的分词器去训练模型, 以此来判定怎样将文字进行切碎处理。平常所常见的词会被完整地吞食下去, 仅仅占据一个token。而生僻的字词则会被拆解成为三四块, 一个词便会消耗掉好几个token。

若是换成英文里的长词, 情况亦是这般, 比如说unbelievable这个词, 有可能会被切割成un、believ、able这样好几块。分词器所依据的规则源自训练语料, 哪些组合出现的频率高，哪些组合就会被单独进行编码标点符号。

文本类型影响大

同一文本, 于各异模型中算出的token数会有三成左右的差异, GPT-5.6 Sol的分词器处理某文本仅需766个token, 然而Opus 5估算得出的却是要1170个, 单价等同, 可输入费用直接相差超30%以上。

代码, JSON, 长串数字那种内容, 两家分词器的差异会更显著。自家文档清楚地写明了, token计数仅是估算之值, 实际创建消息的时候消耗的token数量大概率会有小幅度的出入。

模型升级陷阱

4.7版本以及之后的模型更换了新的分词器, 同样的输入文本情况下, 所产生的token数量相较于早期模型多出大概30%, 具体的增幅是取决于内容以及工作负载形态的, 官方文档给出建议, 若想了解自己的工作负载相差多少, 那就把同一个请求依照两个模型各自数一遍, 然后比对返回的结果。

不要用早期模型所量得的数字去估算新模型的成本, 这是官方明确提醒过的；同一家公司, 同一段文字, 换代之后就能多产出三成token；跨厂商直接对比单价更是不靠谱的。

长上下文加钱

GPT – 5.6 Sol的输入一旦超过272K token , 那么整次请求的输入会按照2倍来计价, 输出则按1.5倍计价。这并非是超出整体部分才加价, 而是整次请求情形下都适用更高的倍率。同样一段代码, 在27万token的上下文里进行询问, 以及在28万token的上下文里询问, 单价就会更换为另一档。

该条限制源自官方定价页面, 上下文篇幅越长, 注意力以及显存的耗费增长速度越快。Tibo还讲述了于Codex里手动完全开启上下文窗口的设置方式, 在~/.codex/.toml里增添三行就能将预算提升至100万token。

然而由实测报告可知, 在特定某版本情形下, Codex目录致使窗口被卡在372K, 而实际能够使用的仅仅为353.4K, 明明购买的是百万数量的窗口, 可实际能用的却仅为三分之一。将阈值推至90万, 这就表明长会话会背负着越来越长的历史不断前行, 每进行一轮都需要重新对这段历史加以计算。

真正成本核算

那分词器之间存在的差异，于短对话当中而言, 仅仅是小数点后面所涉及的微小之事。然而, 一旦会话的长度延伸至几十万token, 历史记录不断地反复带着走, 随后再乘上更高的倍率时, 那这种差异便会即刻形成整数位的成本差距。而真正具有关键意义的是每次成功结果所对应的成本, 基准测试仅仅能够作为起点。

之后该去询问的并非是一百万token究竟价值多少, 而是将这个bug修复好总共所需花费的金额是多少。选取同一段文本、同样的工具定义, 分别调用两家的计数接口从而获取到真实的token数量, 再把缓存命中、输出长度、推理长度以及长上下文倍率计算进去, 最后比较究竟是谁完成这件事所花费的成本更低。

你认为那般「成就一项任务的切实成本」以及「每百万token的单价」哪一个更能够体现出真正的花销呢, 欢迎于评论区域分享你的计费经历。