价格对比软件

要给别人推荐方案时，最头疼的不是拿不到价格，而是拿到的价格互相对不上：有的按 token、有的按次、有的按订阅，还有的混着赠送额度。这篇不讲某家多少钱，而是把「比价软件」按用途分成几类，告诉你每类能解决什么、什么情况下会失效，以及校验一份比价结果的具体动作。

做导购选型的人最常遇到的情况是：价格拿了一堆，放一起却对不上。有的按 token 算，有的按次算，有的走订阅套餐，还有的混着赠送额度和渠道倍率。问题不在于数据少，而在于口径没统一。这篇不讲某家多少钱，而是把能做比价的工具软件按用途分成几类，说清每类能解决什么、什么情况下会失效，以及拿到一份比价结果后该怎么核。

结论先放这儿：比价软件不是用来替你下结论的，它是用来把不同口径拉齐的。真正拍板的那个人仍然需要知道用量、可接受的波动范围和交付时间。所以下面每一节都尽量给判断标准和动作，不给绝对承诺。数字一律去站内页面看当时的值，别抄二手结论。

先分清：能「比价」的软件其实有四种

很多人把「比价软件」理解成一个网站打开就能看全。实际上能帮上忙的工具按用途至少分四层，混着用就会乱。第一层是数据源，第二层是换算，第三层是追踪，第四层是你自己维护的表格。前三层都是给第四层喂料的，最后一张表才是交付物。

• 数据源型目录：把各家官方价目集中在一页，看的是口径是否统一，例如到 /official-api 核对官方口径，渠道和站点另去 /sites 看；
• 换算型计算器：把单价、用量、汇率折成一次任务的花费，例如 /tools/model-cost-calculator 与 /tools/token-price-calculator，注意输入的是你自己的用量；
• 追踪型：记录价格什么时候改过，适合长期跟进，参考 /price-watch，重点看的是变动记录而不是当前值；
• 表格型：就是你自己维护的对比表，前面三种的输出最终都落到这张表上，它才是能给同事看的东西。

这四层里最容易漏掉的是追踪层。价格不是常数，今天比完的结论过一段时间可能就废了。如果你的推荐会被沿用一个季度以上，追踪这一层不能省，否则复查的时候连自己当初看的哪个数都说不清。

挑工具时只看这五项，别被界面骗了

界面好不好看和比价准不准没关系。挑工具时按下面五项打分，任何一项做不到就把它降级成「仅供参考」。这五项的核心逻辑是：能不能拆、能不能追、能不能带上你自己的用量。

还有个常被忽略的点：工具是不是区分「官方价」和「渠道价」。渠道有倍率，倍率会变，跟官方价放一列比就是自欺欺人。遇到这种工具，先把它拆成两张表再谈比价。

数据源这一层：目录怎么用才不出错

数据源这一层的作用是给基准。基准只能有一个，多了就乱。正确做法是先在官方价目页定死一个口径，再去别处找渠道和站点价，而且两者永远放两张表。官方价去 /official-api 找，站点与渠道的对比参考 /sites 与 /rankings。

• 官方价目页负责给基准，先在这里把计量单位和计价口径定死，再看别处；
• 中转站与渠道价另开一层，参考 /sites 与 /rankings，不要和官方价放同一张表；
• 订阅制套餐单独一张表，它的单位是「额度」或「席位」而不是 token，参考 /coding-plans 与 /plans；
• 算力类再单独一张表，租卡和自建的成本结构完全不同，参考 /compute/platforms 与 /compute/gpu-rental。

如果某项价格你只能从一个渠道拿到，没有第二个来源可以对照，那就在表里标清楚「单来源，未交叉验证」。这不是丢人的事，藏着不说才会出事。

换算这一层：把单价变成「一次任务的成本」

单价本身没法比，因为大家卖的单位不一样。换算这一层要做的就是把单价变成「完成一次任务要花多少」。顺序很重要：先量出你自己单次任务的用量，再乘单价。反过来的话，算出来的是个跟自己无关的数。

1. 量化单次用量用你自己的真实任务跑出输入输出量或调用次数，别用官方示例，示例的用量结构和你的不一样。
2. 区分主成本与附加项缓存读写、重试重发、失败重跑这些单独列一列，不要混进主单价，混进去之后没法判断是哪一项在吃钱。
3. 单独处理结算因素外币结算、汇率、结算周期各占一列，它们是成本的一部分但不是单价的一部分，参考 /tools/model-cost-calculator 的输出结构。
4. 校验换算结果拿一两个方案去 /tools/verify 实测，换算算得再对，连不上就等于不存在。

换算结果只用于同口径横向比较，不能直接当预算数用。预算要考虑波动、重试和临时加量，那是另一个层面的工作，参考 /usage 里关于用量口径的说明。

表格这一层：自己维护一张能长期用的对比表

前几层的输出最后都要落到一张表上，这张表才是给同事和领导看的东西。表的设计决定了它能不能长期用。横向放候选方案，纵向放口径项，任何一行都要标来源和时间。

还有一列建议留着：备注。比如「该方案只适合批量、不适合实时」「需要单独申请额度」。这类信息不写下来，下次还得重新踩一遍。模板结构可以直接参考 /tools/model-cost-calculator 的输出，省得每次重新设计。

拿到一份比价结果，按这个顺序核一遍

不管这份比价结果是自己做的还是别人给的，都按下面顺序核。顺序不能乱，因为前一步错了后面全白搭。这套顺序的目的不是找茬，是让你在被追问的时候答得上。

1. 核对计量单位确认两边单位是否一致，不一致先换算再比，单位不同直接比大小是无效操作。
2. 核对赠送与折扣确认结论里有没有算入赠送额度和折扣，含与不含是两个不同结论，参考 /plans 的套餐说明。
3. 核对时间点确认数据是什么时候看的，价格改过之后旧结论作废，去 /price-watch 看有没有变动记录。
4. 抽测可用性抽一到两个方案去 /tools/verify 实测，便宜但连不上等于不存在，这一步不能省。

比价的目的不是找出最便宜的那个，而是找出在你的用量下最不容易翻车的那个。

什么情况下这套比价软件不适用

比价不是所有场景都值得做。下面几种情况，花在比价上的时间可能比省下的还多，或者根本比不出有意义的结果。识别这些情况，比多跑几个计算器更有用。

• 任务量极小、一次性验证：比价的时间成本高于省下的钱，直接挑熟悉的方案更划算；
• 强合规或必须走特定云厂商：可用范围被锁死，比价空间只剩同厂商内的档位选择；
• 对延迟和稳定性有硬要求：价格不是第一变量，先看 /tools/speed-test 与 /ai-status 的实际状态；
• 用量波动极大：单点比价意义有限，应改用区间估算加上预算告警的方式管理。

还有一种情况容易被忽略：团队里没有人能持续维护这张表。如果维护成本没人承担，那张表很快就会过期，过期的表比没有表更危险，因为它会让人以为已经有了答案。

给导购型岗位的交付清单

如果你是给别人做选型建议的那个角色，最后交出去的东西至少包含四部分：对比表、口径说明、来源清单、不适用场景。缺了后面两项，对方拿去做决策的时候容易踩坑，回过头还是找你。

交付时把结论拆成「省钱向」和「省事向」两栏。不同团队要的东西不一样，小团队可能更在乎省事，大团队更在乎可控。混在一栏里讲，两边都不满意。