你在做模型选型，看到 Step 5 Preview 这个入口，第一反应是「它多少钱」；网上一堆截图数字互相打架，官方页面又没说清是订阅价还是按量价。这篇不给你背数字，而是给一套查价顺序和一个计费口径的判断框架：先分清你买的是订阅额度还是 API 按量，再去站内对应当期页面拿数字，最后用真实用量反推一个月大概花多少。
你在做模型选型，翻到 Step 5 Preview 这个入口，第一反应基本都是「它多少钱」。麻烦在于网上一堆截图数字互相打架，有的写月费、有的写每百万 token 单价，官方页面又没说清这个价到底是订阅价还是按量价。照着别人的截图做预算，很容易差出一大截。
这篇不帮你背数字，而是给一套查价顺序加一个计费口径的判断框架：先分清你买的是订阅额度还是 API 按量，再去站内对应页面拿当期数字，最后用你自己的真实用量反推一个月大概花多少。中间还会给一个账单对不上的排查顺序，按这个走基本能定位到问题出在哪一环。
先分清你买的是哪一种「价格」
Step 5 Preview 这类入口通常同时存在订阅额度和 API 按量两条路径，价格标签完全不是一回事。订阅侧看到的是月费，按量侧看到的是每百万 token 的单价，两者只有在做额度折算的时候才能放一起比。很多比价文章把这两种价混着读，结论自然不可靠。
- 订阅额度
- 按月或按档付费，给你一个额度池，超出后要么降级要么加购
- API 按量
- 按实际消耗的输入、输出 token 计费，用多少算多少，没有固定月费
- 折算口径
- 把订阅额度除以月费，得到一个等效单价，只有这时才能和按量单价放一起看
- 判断方法一：看你的调用是走网页或客户端登录态，还是拿 key 直接打接口，前者看订阅页，后者看官方 API 价格页
- 判断方法二：看你的账单是不是有固定扣费日，有固定扣费的偏订阅，纯按调用量跳动的偏按量
- 判断方法三：看你有没有并发限制被卡住的经历，订阅档通常限速更硬，按量档一般看账号等级
- 不适用的情况：只想试几次、没有稳定调用量的读者，比价意义不大，先用免费额度或最低档跑通再说
数字去哪看：三个入口各管什么
站内把不同维度的信息拆到了几个页面，查价时按这个顺序走，比到处翻截图靠谱得多。任何具体金额都请你到这些页面核对当期数字，本文不写死价格，避免你照着过期的数做预算。
| 你要确认的信息 | 去哪看 | 为什么影响价格 |
|---|---|---|
| 模型规格、上下文长度 | /models | 长文档任务会不会触发更高档位的计价，取决于上下文上限 |
| 当期单价、输入输出分开的价格 | /official-api | 站内按厂商归口，价格变动在这里更新，比二手截图可靠 |
| 订阅档位、地区差价 | /plans 与 /coding-plans | 同一档在不同地区开出来的月费不一样，支付渠道也会影响实付 |
| 历史价格变动 | /price-watch | 判断现在是涨了还是降了，别在调价窗口做长期承诺 |
规格页决定你的任务会不会踩到高档计价，价格页决定单价，订阅页决定月费口径。这三者缺一个，算出来的预算都是缺腿的。如果只是想知道「大概什么量级」，看价格页就够；要做年度预算，三个都得走一遍。
计费单位：输入、输出、缓存分开算
主流按量口径都是输入和输出分开计价，输出通常更贵，写作类、生成类任务尤其明显。如果你拿一个笼统的「每次多少钱」去估，误差会很大，因为同样的调用次数下，输出长度翻一倍，成本可能就翻一大截。
如果 Step 5 Preview 支持缓存写入与缓存读取，命中部分会走另一套单价。这一点对重复提示词很多的应用很关键，比如系统提示词固定、只换用户输入的场景，缓存命中能把大部分输入成本压下来。生效与否要看平台文档，别默认它一定命中。
- 拆单次任务把一次典型调用的输入 token 和输出 token 分别记下来，别合并成一个数
- 乘对应单价输入部分的 token 数乘输入单价，输出部分的 token 数乘输出单价，两段分开算
- 加总得单次成本两段相加才是这一次调用的真实成本，再乘调用次数才是月度估算
- 验证跑一批真实样例，把算出来的成本和实际账单对一下，偏差大就说明有漏项
从你的用量倒推月成本：四步走
单价是别人给的，用量是你自己的，只有两个凑一起才有意义。下面这套四步走不需要任何模型内部数据，只靠你自己的调用记录就能做，适合做预算前先估个量级。
- 抓一周真实记录记下每次调用的输入长度、输出长度、调用次数，别用「大概平均」糊弄自己，一周数据里通常藏着高峰日
- 折算月量周 token 总量乘 4.3 得到月量，再留一点波动余量，业务有促销或季节性的话余量要留更大
- 拆段乘单价把月量拆成输入和输出两段，各自乘当期单价，再相加得到按量月成本
- 和订阅档比拿按量月成本和订阅档月费对比，看哪个更划算，同时把额度和限速一起考虑进去
如果按量算出来明显高于订阅档，说明你是重度用户，订阅更合适；反之就按量用，别被包月绑住。这个对比每个季度值得重做一次，因为用量和价格都可能变。具体数字请到 /official-api 和 /plans 核对当期值。
Preview 阶段要额外留意的三件事
Preview 往往意味着规格、限速、计价口径都可能调整。做预算时按「会上浮」而不是「会下降」留余量，这样即使调价也不会打乱你的计划。这不是唱衰，而是把不确定性当成成本的一部分先放进去。
- 限速和并发上限会间接影响成本：并发被卡住时你可能改用更大的模型或增加重试，实际花销比单价算出来的高
- 如果任务对稳定性要求高，Preview 不适合放在主链路上，先放影子流量或内部工具跑一段时间再决定
- 计价口径本身可能变，比如从按 token 改成按请求，或者缓存规则调整，这些都会改写你的估算
- 不适用的情况：内部试验、一次性数据清洗这类可容忍中断的场景，用 Preview 拿较低价位是合理的
Preview 的便宜是给容错空间的补贴，不是给主链路的折扣。
账单和预估对不上，按这个顺序排查
预估和实际账单对不上很常见，多数不是平台算错，而是口径没对齐。下面这个顺序从最粗的口径往最细的地方查，按顺序走能省很多来回。
- 核计费口径先确认你用的是订阅额度还是按量扣费，两套账别混着看，混淆口径是最常见的错误来源
- 核缓存命中看有没有缓存写入和缓存读取没算进去，命中部分的单价和全价输入不同，漏算会让预估偏高或偏低
- 核重试与失败限速被拒后重发的部分有些平台照样计费，去 /tools/verify 看中转链路的实际行为
- 核倍率如果通过中转站调用，实际单价等于官方价乘倍率，先去 /sites 看这个站的口径再回头算账
| 症状 | 最可能的原因 | 下一步动作 |
|---|---|---|
| 账单比预估高一大截 | 走了中转站且有倍率，或重试被计费 | 去 /sites 看该站倍率口径，核对调用记录 |
| 账单比预估低 | 缓存命中没算进去，或部分请求走了更低价档 | 去 /official-api 核对缓存单价，复盘样例 |
| 忽高忽低没规律 | 订阅额度和按量扣费混在一起 | 分开统计两条路径的消耗，别合并看 |
怎么用它做选型决定
把 Step 5 Preview 当成一个候选，而不是默认选项。先明确你的任务类型，是长文档、代码生成还是多轮对话，不同任务对输入输出的比例影响很大，同样是十万 token，输入为主的场景和输出为主的场景成本差很远。
- 拿同一批测试样例，在两个候选模型上各跑一遍，记录 token 消耗和结果可用率，再比成本，别只比单价
- 如果价差在可接受范围内而质量差明显，优先选质量；如果两者质量接近，再按单位任务成本排序
- 把失败重试的成本也计进去，可用率低的模型名义单价再低，摊到有效结果上未必便宜
- 决策后留一个季度复看的时间点，价格和规格都可能变，到 /price-watch 看变动记录
常见问题
Step 5 Preview 是订阅制还是按量计费？
两条路通常都有。走网页或客户端、用登录态调用，看的是订阅档月费；走 key 直接打接口，看的是按量单价。判断自己属于哪种，看扣费记录里是「按次扣额度」还是「按 token 扣余额」，两种账不能混着算。
为什么不直接告诉我具体多少钱？
因为 Preview 阶段的单价、限速和档位调整比较频繁，任何写死的数字都可能在你看到时已经过期。正确的做法是去 /official-api 看官方当期单价，去 /plans 看订阅档地区价，两个页面加起来才是你需要的那组数。
用它做小项目，成本大概什么量级？
取决于你的输入输出比例和调用频次，没有普适答案。实操建议是先跑一周真实调用、记录 token 消耗，再按当期单价折算月成本，和最低档订阅月费对比一下，哪边低走哪边。免费额度或最低档通常够验证阶段用。
Preview 版和正式版价格会差很多吗？
一般来说 Preview 阶段的定价策略会更灵活，可能偏低也可能因为限速更严导致重试成本上升，整体不一定就便宜。别只看单价，把限速、并发、稳定性一起算进「单位可用任务成本」再判断。
通过中转站调用，价格和官方一样吗？
不一定。中转站的实付单价通常是官方价乘一个倍率，倍率因站而异，还有额度折算、汇率等额外口径。比价前先去 /sites 确认这个站的计费规则，否则你算出来的成本没有可比性。
