方法论
一份订阅是怎么被测量的
下面每一个选择,都是为了让同一句话站得住脚:如果你把同样的用量从 API 买回来,这个套餐的额度值这么多钱。这里没有任何一句声称还原了 provider 内部是怎么计量的。
口径
美元,不是 token
token 数量在不同模型、不同 provider 之间不可比。输出 token 大约是输入的五倍价,一次缓存读取大约是十分之一,而每家 provider 的权重都不一样——所以「82M token」在小模型上和在大模型上说的不是一回事。要让 token 可比,就必须选定一组权重,而官方 API 价目表本身就是一组权重:公开、权威,而且由 provider 自己维护着。
更深一层的区别:token 口径是在猜 provider 怎么计量,美元口径是在算用户省下了多少。后者无论 provider 内部发生什么都成立——这就是它成为本站记录口径的原因。
公式
从一个区间到月度上限
价目表是版本化的。每个区间按记录当天生效的价目表计价,价目表以带 effective_from 日期的数据文件存在仓库里——否则一次降价和一次降额在历史曲线上长得一模一样。
只有 Binding Window 允许外推。乘数是儒略月长 30.4375 天除以窗口天数——weekly 为 30.4375/7 ≈ 4.35。从 5 小时窗口外推,得到的是被周上限卡死、永远拿不到的数字——它被禁止出现在任何公布结果里。
发布实体是套餐,不是模型。同一个套餐用小模型测和用大模型测,折算出的美元值必须收敛到同一个数;模型之间的差距折进 Confidence 等级。
数据模型
快照、观测、增量
- Quota Snapshot(额度快照)
- 某一时刻对每个窗口的一次读数:已用百分比与重置时间戳。
- Observation(观测)
- 一对快照,加上这期间记录下来的本地 token 明细。
- WindowDelta(窗口增量)
- 一次观测对单个窗口意味着什么。质量评分挂在这里,而不是挂在观测上:同一个区间可能因为跨了一次重置而对 5 小时窗口毫无价值,同时对周窗口完全合格。
一条增量算高质量,要满足
- 区间没有跨过窗口重置——以官方 reset 时间戳判定。
- 区间足够短。
- 用量增量足够大——百分比字段是整数,增量越大,舍入误差占比越小。
- 本地 token 日志在整个区间内连续。
- 使用的模型可以确定。
- 客户端状态在区间中途没有改变。
- 理想情况:单设备、单客户端。
低质量的增量被保留并降权,而不是删除——它们仍然携带着关于漂移的信息,而悄悄丢弃数据本身就是另一种不诚实。
已知噪音
难在哪里
- 一份订阅的额度是和网页端、桌面端、手机端共享的。本地完全没有记录的用量,照样会推动百分比。
- 用户报告过对不上的额度状态——日窗口显示 0%,周窗口却已经在限流——以及显示值与实际截断点不一致的情况。
- 百分比字段被量化到整数,所以每一个小增量都带着最多半个百分点的舍入误差。这就是为什么宁可要大的增量,而不是频繁的增量。
- 读数按会话缓存:同一账号下的两个活跃会话,在同一瞬间可能报出不同的百分比。因此增量只能取自单个会话自己的序列。第 0 天的实测 →
- 容量本身随 context 大小、effort level、缓存命中率浮动。没有哪家 provider 承诺固定的 prompt 次数。
来源分级
每个数字从哪里来
| 分级 | 含义 |
|---|---|
| Measured(实测) | 从我们自有并运营的 probe account 读到的。 |
| Community measured(社区实测) | 由用户贡献的匿名遥测推算得出。 |
| Derived(推导) | 由实测套餐经官方倍率换算而来,且只在同一个窗口内使用。 |
| Estimated(估算) | 其余全部,并如实标注。估算值绝不会以官方额度的面目出现。 |
Confidence(High / Medium / Low)按样本量、独立贡献者数量、跨模型的一致程度,以及套餐里是否存在没有公开 API 定价的模型来评级。
发布判据
数字什么时候才会上线
当前这场实验把同一批高质量增量归一化两次——一次按美元,一次按 token——然后比较方差。这张决策表写在数据到来之前:
| 结果 | 结论 |
|---|---|
| 美元口径方差明显小于 token 口径 | 计量跟着成本走。方法成立,这一页会照实写出来。 |
| 美元口径方差在 ±10% 以内 | 足以往下做:继续推进 CLI 与聚合管线。 |
| 两种口径的方差都在 ±50% | 计量里存在没被建模的维度。先搞清计量单位,再谈发布任何 Benchmark。 |
在前两行之一成立之前,排行榜一直空着。当前进展 →