你可能已经在好几家平台之间来回切页面，官方价目表一套口径，中转站目录又一套口径，订阅套餐折算下来又是第三种算法，看完更晕。这篇不替你做决定，只给一套挑比价站点的判断标准和动手顺序：先明确你要比的是哪一类东西，再拿几个维度去筛站点，最后自己回原页面核对一遍。
你可能已经在好几家平台之间来回切页面了：这边官方价目表一套口径，那边中转站目录又一套口径，订阅套餐折算下来还是第三种算法，看完比看之前更晕。问题多半不在你，而在于你拿不同类别的东西在互相比。这篇不替你做决定，只给一套挑 AI 价格对比站点的判断标准和动手顺序。
顺序是三步：先明确你要比的到底是哪一类价格，再拿几个维度去筛站点，最后把关键数字回原页面自己核对一遍。任何一步跳过，比出来的结论都容易失效。下面每一节都给到具体动作，你照着走一遍，至少能排掉大部分看着便宜、算下来不便宜的选项。
先分清你到底要比的是哪一类价格
这是最容易被忽略、也最容易出错的一步。按量 API 单价、订阅套餐月费、编程类套餐的额度折算、算力租用，是四套互不相干的账。把它们塞进同一张表比大小，结论基本没有参考价值，因为计价对象、计量单位、有效期都不一样。
先确定你属于哪一类需求，再去找覆盖这一类的比价站。绝大多数比价站只做其中一到两类，覆盖面之外的空白不是它藏起来了，而是它本来就没做。你先去站内确认它覆盖哪一类，再决定要不要用它做初筛。
- 按量 API 单价
- 按 token 或按次计费，用多少付多少，适合调用量波动大的场景
- 订阅套餐月费
- 固定月付换固定额度，适合用量稳定的个人或小团队，超出部分另算
- 编程类套餐额度折算
- 把月费除以额度得到一个虚拟单价，只有在你能用满额度时才成立
- 算力租用
- 按小时或按卡时计价，和 API 计费完全不是一个维度，别混排
同一类里还要再分渠道：官方直连、云厂商托管、聚合平台、转售渠道，这四种的报价口径天然不同。官方直连通常最透明，云厂商托管常带资源绑定条件，聚合平台看的是打包价，转售渠道则受汇率和结算方式影响。比价前先给自己限定一个渠道范围，不然表里全是不可比的数字。
挑比价站点时值得逐条过的几个维度
不是所有叫价格对比的站点都值得放进你的书签。下面这几个维度可以当筛子用，逐条过一遍，不合格的直接淘汰，省得后面反复回去核对。
- 数据来源是否标注到官方页或站内价格页，还是只甩一个孤零零的数字，没有出处就没法追溯
- 更新频率与更新方式：是人工维护还是抓取，改价之后有没有回填记录，能看出它是不是长期在维护
- 是否区分输入输出、缓存读写、批量与阶梯等计价项，只给一个单价的表参考价值很有限
- 能不能按你的用量结构排序，而不是只按绝对值从低到高排，排序维度体现它懂不懂真实成本
- 有没有把限额、限速、并发写进表里，这些约束不写清楚，便宜单价等于半张表
过筛的时候有个实用技巧：随便挑三五个模型，去它标的来源页核对一眼。如果有两三个对不上，或者干脆点不进来源，那这张表后面的数字你也不用太当真了。能长期维护出处和回填记录的站点不多，遇到一个就留着用。
拿到一张对比表，怎么读才不吃亏
表是一样的表，读法不同结论差很多。建议固定一个阅读顺序：单位、条件价、限额限速、结算口径，四步走完再谈谁便宜。
| 先看什么 | 要确认的点 | 没确认会怎样 |
|---|---|---|
| 计量单位 | 按 token、按次、按小时还是按订阅 | 单位不同直接比大小，结论作废 |
| 条件价 | 默认档是否只是最贵那档，缓存批量阶梯在不在表里 | 按默认档估算，实际成本被高估或低估 |
| 限额限速 | 有没有并发上限、速率限制、日调用上限 | 单价低但被限速卡住，单位成本反而上升 |
| 结算口径 | 币种、汇率、代币额度怎么折算 | 外币或代币额度没折算，排序全是错的 |
还有一点：表里的数字往往是某个时间点的快照。你要是拿它做正式预算，务必去站内价格页核对当时的数字，比如到 /price-watch 看价格变动记录，看这个数在你决策的这段时间里有没有动过。
任何比价站的数字都要回原页核对一遍
比价站是帮你缩小范围的，不是帮你拍板的。真正拍板之前，至少做一遍自己核对，把差额找出来。下面这套顺序照着做一遍，大概十几分钟。
- 选样本挑三五个你真正会用的模型或渠道，别挑你不用的便宜货去对比，没意义。
- 回官方页逐个对去站内对应的官方价格资料页，逐个对输入输出单价，确认口径一致。
- 对齐时间确认比价站标的更新时间和官方当前价是不是同一期，跨期就重新取数。
- 灌用量算总账把官方价和你实际账单里的用量结构灌进成本计算工具，算出真实月成本。
- 看差额落点差得多就再查倍率、汇率、赠送额度，弄清楚差在哪再下结论。
如果你的用量主要跑在缓存命中率高的场景，或者有大量低峰批量任务，那对比重点应该放在缓存读写价和阶梯价上，而不是主单价。这类条件价在通用比价表里经常被简化掉，一定要回原页看。
什么情况下不该只靠比价站做决定
比价站解决的是「同类可比的数字放一起看」这个问题，它不解决所有选型问题。下面几种情况，单看比价表很容易做出错误判断。
- 用量集中在长上下文、出图、出视频这类特殊计价场景，通用比价表基本覆盖不到
- 需要合规、数据不出境、发票与合同的企业采购，价格不是第一顺位，渠道资质才是
- 任务本身质量差距明显时，单价便宜不等于单位任务便宜，返工成本要算进去
- 小体量调用、免费额度占大头的情况，把额度规则搞清楚比价比什么都重要
- 需要 SLA 或技术支持响应承诺的场景，比价表不会告诉你谁半夜有人值守
换个说法：比价站适合用来初筛和排除明显不划算的选项，不适合用来直接定最终方案。当你发现候选之间只差一点点，那决定权其实在服务稳定性、结算便利度和团队熟悉度上。
自己搭一张够用的比价表：字段和填法
与其每次重新翻别人的表，不如自己维护一张小表，只放你真正会用到的组合。字段不需要多，关键是每格记的东西口径统一。
| 表头字段 | 填什么 | 注意 |
|---|---|---|
| 候选渠道 | 官方直连、托管、聚合、转售各一列 | 同一类才放同一张表 |
| 任务类型 | 你实际会跑的任务，不是全部模型 | 按任务排比按模型排有用 |
| 名义单价 | 官方页抄来的单价 | 注明抄录来源和时间 |
| 折算月成本 | 按你当前用量算出的月度支出 | 这是排序的真正依据 |
| 限制条件 | 限速、并发、预充、是否可退 | 便宜的往往卡在这一列 |
维护节奏也很简单：改价或换模型时，只更新对应那几格，别整张重做。固定一个复盘周期，比如每季度过一遍，比一年后翻出旧截图重新查要省事得多。站内的价格变动记录页可以当作提醒来源，变动了再去改你那几格。
几个一看就知道会踩的坑
下面这些坑的共同点是：看起来是在比价，实际上是在拿两套不同规则的东西硬凑。遇到类似情况，先停下来问一句「这两个数字是一回事吗」。
- 拿订阅套餐月费和按量单价直接比，忽略额度上限以及超出之后的计价方式
- 只看单价不看结算渠道，卡网订阅、代金券、地区差都会产生额外成本
- 把能力榜单的排名当成性价比结论，榜单衡量的是能力，不是价格
- 用很久以前的截图表格做决策，中间可能已经改过价，务必回站内核对当时数字
- 只比主单价，不看缓存、批量、阶梯这些条件价，实际账单往往对不上
比价的第一原则不是找到最便宜的那个，而是让放在一起比的两个数字，真的是同一件事。下一步先去站内价格资料与价格追踪页，把你关心的那几项当时的数字抄下来，再回你实际要用的渠道官方页核对一遍，然后填进自己的小表。→
常见问题
有没有一个网站能把所有 AI 价格都放一起比？
严格说没有。按量接口、订阅套餐、编程额度、算力租用是四套不同的计价体系，任何单一站点都只能覆盖其中一部分。可行的做法是按你要买的那一类去找对应栏目，再自己拉一张表把候选渠道填进去，跨类别的数字不要直接比。
比价站上的数字和我账单对不上，谁错了？
多数情况是口径问题而不是谁写错。比价站通常给的是官方挂牌单价，你的账单里还叠了缓存、批量、倍率、汇率、赠送额度抵扣等环节。先确认比价站写的是哪天的哪一档价，再回站内官方价格页核对，最后用成本计算器把用量代进去看差额。
中转站的价格比官方低很多，可以当成划算吗？
低不等于划算，要先看它低在哪：是汇率口径、是额度折算、还是限速与并发上的让步。建议先用站内中转站目录看它的可信度与计费说明，再小额试跑，把实际单位任务成本和你自己的用量对上，别只看标价。
多久核一次价格比较合适？
没有统一答案，取决于你用量规模。用量小、金额低的话，按季度对一次就够；用量大或者刚换了主用模型，建议在改价、上新、换渠道这几个节点各核一次。站内的价格变动追踪页面可以帮你少跑几趟原页面。
选型时价格应该占多大权重？
看你的任务对质量有多敏感。质量差距明显的任务上，先按质量筛一轮再看价格；质量拉不开差距、又是大批量重复调用时，价格才值得排到前面。另外别忘了把限速、合规与结算方式这些非价格因素一起列进去。
