重度用 AI 的人迟早会遇到这个问题:手里几个套餐看着都便宜,但真用起来某个月账单翻倍,或者额度早早见底、后面按量补扣贵得离谱。麻烦在于各家套餐的额度口径不一样,有的按输入输出分开算,有的把缓存和推理 token 打包,有的限速不限量。这篇不替你做决定,而是给你一套把不同套餐拉到同一把尺子上量过去的流程,量完你自己就知道该买哪档。
重度用 AI 的人迟早会撞上这个问题:手里几个套餐看着都便宜,真用起来某个月账单翻倍,或者额度早早见底、后面按量补扣贵得离谱。麻烦不在单价,而在各家套餐的额度口径根本不一样,有的输入输出分开算,有的把缓存和推理 token 打包,有的限速不限量。拿宣传页上的大数字互相比,基本等于没比。
这篇不替你拍板买哪家,而是给一套流程:先量清自己的用量,再把各档额度拉到同一把尺子上,最后算总账、按场景挑。量完你会自己发现该买哪一档。下面每一步都给判断标准和去哪核对,数字一律到站内页面看当时的。
第一步:先把你自己的用量基线量出来
比价之前先比对自己。没有基线,你只能被别人的「这家便宜」带着走,而那家便宜很可能只对短请求、小上下文的用量成立。花半小时把最近一周的调用翻出来,输入多少、输出多少、峰值一天几次、有没有反复重试,这几项决定了你该看哪一档套餐,而不是别人说哪家划算。
- 统计一周真实消耗从你的调用日志或账单导出,分别记输入 token 和输出 token,再标出峰值那一天的调用次数。输入和输出占比不同,后面能选的档位完全不同。
- 折成统一单位到 /tools/token-price-calculator 用单价换算把你的用量折成统一单位,别用「次」或「万字符」这种各家定义不一的口径。
- 和真实用量对一遍到 /usage 看真实用量榜,确认你这种用量规模在别人那儿大概落在什么档,避免高估或低估自己。
第二步:把套餐额度拉到同一口径再比
各家标价看着接近,口径差出来的钱往往比标价差更大。看任何一档套餐,只问三件事:额度按什么单位算、有没有区分输入输出价、超了之后按什么价补扣。这三项口径不同的档位,直接拿总额度互比是没有意义的。核对时到 /coding-plans 的编程套餐目录和 /plans 官方订阅地区价里对,别只看宣传里那个总额度数字。
| 口径项 | 要确认的点 | 容易踩的坑 |
|---|---|---|
| 额度单位 | 按 token、按次、还是按时间窗口 | 单位不同,总额度数字不可比 |
| 输入输出 | 是否分开计价,比例多少 | 输出贵的档位做长回答会爆 |
| 超量补扣 | 超了按什么价、是否自动续 | 补扣价常比套餐单价高不少 |
| 限速与并发 | 限速不限量还是限并发 | 高并发被排队,时间成本也是钱 |
「不限量」不等于便宜。很多不限量套餐对高并发或大上下文另有隐形限制,到 /per-call-vs-usage-billing 那套口径里对一遍更稳。什么情况下不适用:如果你几乎只用一种模型、上下文也稳定,口径差异对总价影响不大,那就优先看稳定性和续费条款,别在换算上绕太久。
- 先把候选套餐的超量补扣价单独拎出来比,这一项最容易被忽略却最贵
- 确认额度是每月重置还是滚动,滚动口径对用量不稳的人更友好
- 问清失败重试是否计费,重度用户被重试吃掉的额度经常比想象多
- 同档位对比时固定同一个模型和上下文长度,否则比出来的都是噪音
第三步:算总账,而不是只看月费
月费只是入场券。真正决定划算与否的是月费加超量补扣加失败重试,再算上并发排队浪费的时间和被掐断上下文重来的成本。重度用户往往不是被月费吃掉的,是被超量和重试吃掉的。把这几项列进同一张表,再决定买哪档,比只看首屏价格靠谱得多。
| 成本项 | 怎么估 | 去哪核对 |
|---|---|---|
| 月费/订阅 | 固定支出,直接看档位 | /plans |
| 超量补扣 | 按你基线里的峰值算溢出部分 | /tools/token-price-calculator |
| 失败重试 | 估重试率乘单次成本 | /usage |
| 上游涨价传导 | 看这档定价是否跟着上游走 | /official-api |
还要看这档定价稳不稳。到 /price-watch 的价格变动追踪和 /official-api 的官方 API 价格对一下,判断这个套餐是不是被上游涨价推着走,会变的档位要给自己留换的余地。第一次上手别一次买满一档,按 /first-recharge-budget 里那套把预算分成两份试,跑满一个周期再决定加码。
什么情况下不适用:如果你已经稳定用了几个月、用量曲线平直,那就不用再反复比价,转向盯条款和站点稳定性更重要,反复横跳反而浪费时间。
按场景挑:你的活属于哪一类
同样一档套餐,对不同活儿的性价比完全不同。与其问哪家划算,不如先给自己的活分类,再回到对应的判断标准上。下面这张对照表帮你把场景和该看的指标对上,具体各家的档位和数字到对应站内页面看当时的。
| 你的场景 | 优先看什么 | 什么样的档位不划算 |
|---|---|---|
| 高频短请求(客服、批量改写) | 单位价格、限流策略 | 额度口径影响小,谁不卡谁划算 |
| 大上下文长任务(读长文档、改仓库代码) | 输入计价、上下文上限 | 便宜但截断上下文的那档其实最贵 |
| 团队共用一把 Key | 权限、对账、换人成本 | 只算人均不看对账成本,容易后悔 |
- 写一页纸对齐四条用量基线、口径换算、超量补扣价、试用金额,四条写在同一页上,对齐之后再下单,避免被单个数字带跑。
- 先试一小档按 /first-recharge-budget 的思路先买最小可用档,跑满一个计费周期,对比实际消耗和你的基线差多少。
- 跑一轮再决定加码如果实际消耗远低于额度就维持,接近或超了就换档或换家,别凭感觉一次买满。
划算不是看谁的标价低,而是看谁的额度口径、超量价和限流策略,跟你的用量曲线最贴。下一步:把候选套餐拉到同一张表上先去站内的编程套餐目录和价格追踪页,把你在意的两三档的额度单位、超量补扣价、限速策略抄进同一张表,再到工具页把你的用量基线折成同口径,量完你自己就知道该买哪一档。→
常见问题
是不是单位价格最低的那个套餐就一定最划算?
不一定。单价低但区分输入输出计价的套餐,做长上下文任务时可能比看起来贵的套餐更烧钱;再加上限速和失败重试,实际成本还会往上走。建议你把自己的用量折成统一单位,再到站内 /tools/token-price-calculator 换算一遍,用总账而不是单价做判断。
重度用户该选不限量的套餐吗?
看你的调用形态。请求量高但每次都很短,不限量确实容易划算;但如果是大上下文、长输出,很多「不限量」套餐会在此处加限速或降级,排队时间也是成本。先确认它的限制写在哪一条,再决定是否比按量更省。
买之前怎么验证自己有没有算错?
先用一份小额预算跑满一个完整周期,把实际消耗和你事先估的数字对一遍,差值超过预期就说明口径看漏了,回去重估。站内 /usage 的用量榜可以当外部参照,看同类型用户的消耗量级是否和你接近,差太多通常是你对口径的理解有问题。