你大概遇到过这种场面:想给项目挑算力或模型接口,翻了几个平台的价格页,发现有人按 token 报价、有人按小时租卡、有人按套餐包月,数字看着差好几倍,却根本不知道能不能放一起比。这篇不给你一个「谁最便宜」的答案,而是给一套查询顺序和对比口径,让你自己到站内对应页面把当期数字取出来,再判断哪个适合你。
你大概遇到过这种场面:想给项目挑算力或模型接口,翻了几个平台的价格页,发现有人按 token 报价、有人按小时租卡、有人按套餐包月,数字看着差好几倍,却根本不知道能不能放一起比。更麻烦的是,有些页面写的是折后价,有些把赠送额度一起算进去了,你拿两个不同口径的数字做决策,最后大概率是预算算错、方案选偏。
所以这篇不给「哪家最便宜」的结论,那类数字变化太快,写死了也是过期的。这里只给一套查询顺序和对比口径:先知道该去哪几页取数,再统一单位,再把你的真实用量代进去,最后判断这个价格是不是能当长期基线。每一步你自己到站内对应页面把当期数字取出来,结论才是你的。
先搞清楚价格分几类,各去哪查
很多人比价比不下去,第一步就错了:把四类完全不同的计价方式摆在同一张表里。按 token 的接口、按小时的租卡、包月的订阅、按张按秒的多媒体接口,单位不同、结算周期不同,硬比只会得到无意义的排名。先分类,再去对应页面取数。
| 价格类型 | 典型计价单位 | 去哪一页取数 |
|---|---|---|
| 按量计费的模型接口 | 按输入/输出 token 分别计 | 到 /official-api 看官方价格表 |
| 算力租用 | 按小时或整机包月 | 到 /compute 与 /compute/gpu-rental 核对 |
| 订阅制编程套餐 | 按档位包月含额度 | 到 /plans 和 /coding-plans 看档位说明 |
| 图像视频类接口 | 按张、按秒或按次 | 到 /official-api 与对应厂商分页看 |
| 开源托管与聚合平台 | 各家自定,混合计价 | 到 /inference 和各供应商分页核对 |
- 先把候选按上面五类归位,同类之间才谈得上比较,跨类比只是给自己添乱
- 取数时记下你打开页面的时间,价格随时会改,截图放一周可能就不成立了
- 官方价和中转价要分开看,中转站的报价逻辑和官方不同,别直接拿两边数字相减
- 任何页面上的数字都是当期值,做决策前重新打开一次,不要用上周的截图
对比前先统一口径,否则比了也白比
单位不统一,比出来的差值基本是噪音。最实用的做法是把所有候选折算成「跑完我这一次任务大概花多少」,而不是看单价栏那个数字谁小。折算需要你自己提供两个参数:任务规模、输入输出的比例。
- 统一计价单位把按 token、按小时、按张的报价全部换成「一次任务成本」。按 token 的用你的输入输出比例加权,按小时的用预计运行时长乘,不要只抄单价。
- 剥离非价格因素区分预扣金额和最终结算金额、区分账户余额和赠送额度。赠送额度用不掉的部分不该算进真实单价,否则你会高估某个方案的性价比。
- 折算订阅档位订阅制套餐必须把包含额度换算成按量价才有可比性,具体换算口径看 /coding-plans 下各套餐页的说明,别自己拍脑袋估。
- 确认原价还是折后价倍率、折扣、阶梯价只要有一项没对齐,两个数字就不可比。先问清对方报的是原价、折后价还是首月价,再放进同一张表。
这四步做完,你手上应该是一张单位一致的表。如果某一行怎么也折算不出来,说明它跟其他候选本来就不适合放一起比,单独拿出来评估更靠谱。
一套可复用的查询流程
流程的价值在于可复用。下次换项目、换需求,你按同样的顺序走一遍就行,不用重新想从哪下手。下面这条链路适合大多数「挑接口或挑算力」的场景,顺序别颠倒,颠倒容易先被低价吸引再去找理由。
- 第一步,锁定用量形态:长文档一次性处理、高频短请求、还是持续跑卡,形态不同该看的页面完全不同
- 第二步,按形态去对应页面取两到三个候选的当期数字,每个都记下取数时间
- 第三步,把你的真实用量代进成本计算工具,得到可比的月成本,而不是单价对比
- 第四步,看价格变动记录,判断这是稳定档还是短期促销,促销价不能当长期预算基线
第三步的工具站内就有:模型侧可以用 /tools/model-cost-calculator,按 token 计价的场景用 /tools/token-price-calculator,把你真实的请求量、输入输出比例填进去,输出的数字才有决策价值。第四步去 /price-watch 看变动记录,一个价格如果在短期内反复上下,说明它受促销或供给影响大,拿它做年度预算风险很高。
如果你还在几个中转站之间犹豫,取数之后可以顺手到 /sites 和 /rankings 看一下这些站的接入状态和历史表现,价格只是一部分,能不能稳定拿到服务同样重要。判断标准很简单:价格低但可用性记录差的,适合做备用通道,不适合做主力。
哪些情况下这套对比不成立
这套方法的前提是「价格是主要决策变量」。一旦这个前提不成立,继续比价就是浪费时间甚至误导决策。下面几种情况,建议先换评估维度,再回头看价格。
| 你的情况 | 比价是否适用 | 该先看什么 |
|---|---|---|
| 有合规、数据不出境、私有部署要求 | 不适用 | 先去 /safety 和 /compute 判断方案可行性,价格不是主变量 |
| 调用量极小,偶尔跑几次 | 意义有限 | 比价省下的时间成本可能更高,选接入最省事的即可 |
| 实时业务,对延迟和稳定性敏感 | 需配合实测 | 先到 /tools/speed-test 量基线,便宜但常排队限速的单独评估 |
| 需要长周期锁价 | 按量价参考性低 | 去 /compute/clusters 看整机或合同类方案 |
还有一种容易被忽略的情况:你其实还没确定用量。用量都不清楚,折算出来的成本就是假的。这时候先去把用量估出来,或者用一个短周期实测得到真实数据,再回来比价,顺序不能反。
下一步把上面这条流程走一遍,先到站内价格变动页确认你关注的档位是不是稳定价,再动手选型,能少踩不少预算坑。→常见问题
算力价格查询到底该从哪个页面开始?
先确定你买的是哪一类:模型接口按量就去 /official-api,租卡就去 /compute 和 /compute/gpu-rental,订阅套餐就去 /plans 与 /coding-plans。三类别混着看。定了类再挑两三个候选取当期数字,代进 /tools/model-cost-calculator 换算成同一口径的月成本,才有比较意义。
不同平台报的单价差很多,是不是直接选最便宜的?
不一定。先确认是不是同一口径:有没有算输入输出分开计价、是不是促销价、赠送额度算没算进去、限速和排队是否影响可用性。很多时候便宜的档位在并发或稳定性上有限制,对实时业务不划算。先去 /tools/speed-test 量你自己的延迟基线,再决定便宜值不值得。
价格对比表要记哪些字段才够用?
至少记:取数日期、计价单位、输入与输出单价、是否含缓存价、有无阶梯或促销、限速条件、结算方式。缺一项那两个数字就不可比。整理完再去 /price-watch 确认这价格是新调的还是长期档,避免拿一次促销当预算基线,最后预算和账单对不上。