订阅套餐为何敢同价对标：有效容量测算

一、问题背景：订阅套餐里的“隐藏额度体系”

大模型的消费方式主要有两种：按量计费与订阅制。按量计费模式下，缓存命中输入、缓存写入、未命中输入、模型输出四类Token各自明码标价，成本可以精确核算。而订阅制套餐通常采用一套内部额度体系：用户支付固定月费，获得一个抽象的“额度池”，每次请求按内部规则扣减。厂商往往不公布这套规则中每一类Token的扣费率，最多给出一个“大致等效于多少Token”的模糊说法。

问题在于，这四类Token的真实成本差异极大。输出Token需要自回归逐个解码，算力开销最高；未命中输入需要完整的预填充计算；缓存写入要在预填充之外额外存储中间状态；而缓存命中输入复用了已有的计算结果，是四类中最便宜的。一个以智能编程助手为核心场景的订阅套餐，绝大多数请求都在复用同一段系统提示词和仓库上下文，缓存命中占比可以轻松超过九成。这意味着“一份月费能跑多少Token”几乎完全取决于统计口径中的负载假设——假设不同，同一个套餐的“等效容量”可以差出数倍。这也解释了为什么不同厂商能在相近的价格档位上互相对标，且各自都能给出“看起来合理”的论证。

二、实测方法：把四类Token拆开，分别定向消耗

要穿透营销口径，最可靠的办法是实测。业内曾有第三方分析机构做过一套相对客观、全面的反推实验，其核心思路是控制变量：故意把请求设计成“一次只大量消耗一种Token”，然后观察订阅额度掉了多少。

具体做法可以这样拆解：

• 测缓存命中输入：先写入一大段固定上下文，之后反复发送相同或高度相似的请求，确保消耗几乎全部来自缓存命中；
• 测未命中输入：每次请求都更换内容，刻意避开缓存，使消耗集中在未命中输入上；
• 测模型输出：把输入压到极短，把输出长度拉满，让解码成本成为主导项；
• 测缓存写入：通过“首次写入上下文”与“随后读取同一段上下文”之间的额度差分来近似估计。

跑完四组实验，就得到了四类Token各自的扣费率，即“每100万某类Token会消耗多少订阅额度”。

三、精度问题：整数百分比下的累计测量法

实测有一个现实障碍：订阅界面通常只显示整数百分比，单次请求的消耗根本读不出来。一次请求扣掉0.1%的额度，在界面上可能毫无变化。

解决办法是把测量粒度从“单次请求”提升到“完整区间”：

1. 连续发送大量同类请求；
2. 记录额度从一个整数跳到下一个整数（例如从17%跳到18%、从18%跳到19%）时，累计消耗了多少Token；
3. 重复多个完整区间，用平均值抹平取整带来的误差；
4. 全流程多次重复真实测试，剔除限流、服务波动等异常样本。

这样得到的扣费率估计虽不是官方数字，但置信度足以支撑横向比较。这套方法的精妙之处在于：它不依赖厂商公开任何信息，只利用了“额度会减少”这一个可观测事实。

四、从扣费率到有效容量：按真实负载加权

拿到四类扣费率后，下一步是回答用户真正关心的问题：这个套餐到底能承载多少Token？答案取决于你自己的负载结构。把真实编码工作负载中四类Token的占比作为权重，对扣费率做加权求和，再用总额度除以加权成本，就得到有效容量：

有效容量 ≈ 总额度 ÷ Σ(第i类Token扣费率 × 第i类Token占比)

用一段示意代码表达（费率与占比均为演示用假设值）：

# 演示数据，仅用于说明计算方法
quota_total = 100.0  # 订阅总额度（抽象单位）
# 实测得到的扣费率：每 100 万 Token 消耗的额度
rate = {
    "cache_read":  0.20,
    "fresh_input": 1.00,
    "cache_write": 2.00,
    "output":      4.00,
}
# 开发者自己的负载画像（四类占比之和为 1）
mix = {
    "cache_read":  0.70,
    "fresh_input": 0.25,
    "cache_write": 0.03,
    "output":      0.02,
}
cost_per_million = sum(rate[k] * mix[k] for k in rate)
effective_capacity = quota_total / cost_per_million
print(f"套餐有效容量约 {effective_capacity:.1f}M tokens")

同样的套餐，换不同的负载画像，结果截然不同。做一个粗略的敏感性分析（同样基于上述演示费率）：

场景	缓存命中	未命中输入	缓存写入	输出	有效容量（演示值）
乐观	97%	2.5%	0%	0.5%	约 418M tokens
中性	70%	25%	3%	2%	约 189M tokens
悲观	40%	45%	8%	7%	约 103M tokens

同一份月费，理论容量可以在四倍区间内浮动。这还是演示数据下的结论，真实差异可能更大。

五、理论值为什么偏乐观：缓存命中率假设的脆弱性

回到本文的核心问题：为什么有的套餐敢于把定价标到与头部旗舰产品相同的档位？部分第三方比价口径给出的测算是“在特定缓存命中率、负载结构和额度全部用满的前提下，理论上能处理多少Token”。以某种编码场景的假设为例：缓存命中输入约97%、未命中输入约2.5%、输出约0.5%——也就是说，每处理100万Token，其中97万来自缓存命中，真正的输出只有5000。这是一个对编码场景极度友好的理想负载。

但实际使用很难维持这种理想状态：

• 任务切换：从A仓库切到B仓库，缓存全部失效，未命中输入占比瞬间飙升；
• 缓存生命周期：缓存条目通常有有效期，隔夜或隔几个小时回来继续工作，之前的上下文大概率要重新写入；
• 任务类型波动：代码评审、答疑、写文档类任务的输出占比，远高于“反复迭代同一个文件”的场景；
• 多项目并行：并行度越高，缓存被“挤出”的频率越高。

这个道理和新能源车一样：标称续航500公里，是连续空载、低限速、风阻良好条件下的理论值；冬天开暖风、高速巡航，实际可能只有六七折。套餐容量的“标称值”与“实际值”之间同样存在这样一层折扣，而折扣系数就写在你的使用方式里。

同理，拿一款轻量档套餐与另一款旗舰档套餐直接比标价，而不交代各自的额度体系与负载假设，结论同样站不住脚——标价相同不代表等效容量相同，标价不同也不代表性价比有差距。

六、给开发者的实操建议

1. 先画自己的负载画像。多数智能编程工具和模型开放平台都会提供用量明细，或可通过日志服务聚合统计。先弄清楚自己的四类Token占比，再去看任何套餐宣传。
2. 小成本实测扣费率。参照第二、三节的方法，用小额订阅或试用额度做一轮定向测量，比看十篇对比文章都有说服力。
3. 做三档敏感性分析。不要只接受一个“等效Token数”，用乐观、中性、悲观三档负载假设分别算一遍，看结论是否翻转。
4. 关注非价格因素。缓存有效期、并发与限流策略、上下文长度上限、工具链兼容性，这些都会实质影响同样额度能完成的工作量。
5. 优先选择计费口径透明的平台。无论选择哪家服务商——例如百度智能云这类提供大模型开放服务的平台，还是其他厂商——“先看计费口径、再做小成本实测”的评估流程都是通用的。口径越透明，你的测算误差越小。

七、结语

订阅套餐的比较，本质上不是标价的比较，而是“你的负载结构 × 隐藏扣费率”的比较。厂商敢于把套餐定价标到与头部产品同一档位，底气来自对自家额度体系和目标用户负载结构的精细设计；而用户不被宣传数字误导的唯一办法，就是掌握这套“定向消耗—累计测量—负载加权”的实测框架，用自己的数据回答“这个套餐对我来说值不值”。