价格对比公式怎么算

很多人在比价时，看到 A 家写「每百万 token 若干元」、B 家写「按次计费」、C 家还给折扣和赠送额度，凭感觉就下了结论，事后才发现每月账单差出一截。这篇不给你现成数字，而是给一套能自己套用的公式：先把口径对齐成同一单位，再算绝对差额，再算百分比，最后判断这个差距在什么情况下会被抹平。

很多人比价的方式是打开两个网页，看一眼单价，心里估摸一个「差不多」或者「贵不少」，然后就下了结论。问题是 AI 服务的价目表很少长一个样：A 家按每百万 token 报数，B 家按调用次数报数，C 家挂着一个折扣再叠一层赠送额度。单位不一样、口径不一样，凭感觉比出来的结论基本都是错的。

这篇不给你任何现成数字，只给一套能自己套用的算法：先把口径对齐成同一单位，再算绝对差额，再算百分比，最后判断这个差距在什么情况下会被抹平。算完能落到一句话上：差距属于哪一档，对应该换、暂缓还是不动。

凭感觉比价，为什么总比错

凭感觉比价的错误集中在三处。第一是计价单位不同，一边按量计费一边按次计费，两个数字根本不在同一维度上；第二是币种与结算口径不同，标价是一个币种、实际结算和税费是另一回事；第三是没把折扣和赠送额度算进去，挂牌价和实付价能差出一大截。这三点任何一个没对齐，后面的计算都白做。

比价的目的其实不是找一个「最便宜」的供应商，而是判断差距够不够大到值得你动一次手。换服务要迁移、要改代码、要重新压测，这些成本是实打实的。如果两家差距只落在误差级别，折腾一圈反而亏了时间和人力成本。

• 常见误区一：拿每百万 token 的报价直接对比按次报价，单位层面就没对齐
• 常见误区二：只看挂牌价，忽略阶梯、折扣和赠送额度带来的实际差异
• 常见误区三：把输入价和输出价混成一个平均数，掩盖了结构性的成本差异
• 判断顺序：先看差距是否肉眼可见，再看你的月度用量有没有大到让差额值得处理
• 不用算公式的情况：两家的差距已经大到闭眼都能看出来，或者你的用量本身极小

第一步：把所有价格拉成同一个单位

对齐单位是整套算法里最容易翻车的一步。你要先确定各家到底按什么计价：按 token、按字符、按调用次数、按分钟、还是按月订阅。这几种基准之间的换算关系不一样，不能凭一个想当然的系数就乘过去。遇到按次计费的，就得先估出你自己的平均单次消耗量，才能换算到可比的口径上。

接着统一币种和结算口径。标价用的币种、结算时实际走的币种、税前还是税后、有没有最低消费门槛，这些都要问清楚。外币结算还要把换汇成本和可能的汇损算进来，这部分在量大的时候不是小数目。

最后把折扣、阶梯价、赠送额度写成系数，而不是写成具体数字。比如阶梯折扣可以记成一个小于一的折扣因子，赠送额度可以折算成等效的免费用量比例。写成系数是为了后面能直接代进公式，也方便你换一个假设条件重新算。

第二步：算绝对差额，先看「差多少钱」

口径对齐之后，先算绝对差额：单价 A 减去单价 B。这里有一个硬性要求，输入价和输出价必须分开算，不要为了让数字好看而混成一个平均数。很多服务的输入价和输出价结构差异很大，混算出来的结果会在你自己的用量结构下完全失真。

算出单价差额只是中间结果，真正有意义的是把它乘以你的实际用量，得到每月的绝对差额。这一步决定了这事值不值得管。用量统计要拆成三部分：输入、输出、缓存命中。这三部分的单价通常不一样，混在一起算等于默认它们的价格相同，误差会悄悄放大。

1. 列出两家单价把输入价、输出价、缓存命中价分别写出来，两边口径必须已对齐，缺哪一项就标注「无此项」而不是留空。
2. 算单价差额输入价相减得到输入差额，输出价相减得到输出差额，缓存价同理。差额可能是负的，负号代表方向，别直接取绝对值。
3. 统计你的用量结构分别统计每个月输入量、输出量、缓存命中量，用最近一个完整周期的数据，别用记忆里的估算值。
4. 乘出月度差额三个差额分别乘以对应的量，相加得到月度绝对差额。这个数才是你要拿来决策的成本。
5. 验证数量级用另一套假设条件重算一遍，比如用量翻倍，看差额是否同比例变化，不同比例说明有固定成本项没拆出来。

先算差多少钱，再算差几个点；顺序反了，你会被一个很大的百分比吓到，却忽略了它对应的绝对金额其实很小。

第三步：算百分比，看清「差了几个点」

百分比差有两种算法，这是最容易被含糊过去的地方。以贵的一方为基数，算出来的是「贵的那家比便宜的那家高出多少」；以便宜的一方为基数，算出来的是「便宜的那家比贵的那家省了多少」。两个基数不同，得出来的数字不一样，报数之前务必要先说清楚用的是哪一个基数，否则同一组价格能算出两个都「正确」的结论。

「高几个点」和「贵了百分之多少」这两种说法也容易混。前者一般指百分比差本身，后者强调的是相对变化幅度。跟同事沟通或者写进内部文档时，直接写清公式和基数，比用模糊的口语说法更省事，也避免后续扯皮。

算出百分比之后，把它代回你自己的账单规模判断档位。差距小到和月度用量波动一个量级，属于可忽略；差距明显但还在预算弹性范围内，属于值得优化；差距大到足以覆盖迁移成本并且有余，才属于必须换。具体落到哪个档位，要结合你自己的用量数字，而不是套用别人的结论。

对照站内数据核一遍，别用记下来的旧数字

价格是会变的，你上周截图记下来的数字，这周可能已经不一样了。官方挂牌价这类基础数据到 /official-api 核对；订阅和套餐类价格到 /plans 和 /coding-plans 核对，这两处的口径不一样，别混着看。

动手算之前，先去 /price-watch 看一眼有没有近期调整记录。如果目标服务刚调过价，你手里的旧数字直接作废，得重新取一遍。这一步花不了几分钟，但能避免整篇计算建立在过期数据上。

算完之后，用 /tools/model-cost-calculator 或 /tools/token-price-calculator 反算一遍。手工算最容易错在单位换算和系数代入这两处，计算器反算一次能很快暴露出量级不对的地方。两次结果差得多，先怀疑自己的换算，再怀疑数据源。

• 官方挂牌价：到 /official-api 核对，注意区分输入与输出
• 套餐与订阅价：到 /plans 和 /coding-plans 核对，两边口径不同
• 价格变动记录：到 /price-watch 看近期有没有调整
• 反向验算：用 /tools/model-cost-calculator 或 /tools/token-price-calculator 复核量级
• 核对时机：取数前核一次，算完后反算一次，两次都不能省

这些情况下，算出来的百分比不作数

公式算的是钱，但实际成本远不止钱。限速、并发上限和排队带来的时间成本没有进公式，便宜但慢的那家，在你有实时性要求的场景里实际可能更贵。如果你的业务对响应时间敏感，比价时必须把这一项单独拎出来看，而不是默认它不存在。

质量不达标导致的返工和重试，会让纸面上的价格优势直接反转。一次调用返回的结果不能用，就得重试一次，重试的成本要算进有效单价里。对于输出质量波动大的服务，实际有效单价可能比挂牌价高出一截，这个偏差比两家的价格差本身还大。

批量、缓存、预留等折扣路径不同，两条链路的价格比法本身就不对称。一方支持缓存命中折扣而另一方不支持，在缓存命中率高的场景下，两边的实际成本结构根本不在一个模型里，硬算出来的百分比没有参考意义。遇到这种情况，应该按实际链路分别建账，而不是强行套一个统一公式。

一张可复用的比价清单

下面这张清单可以直接拿去用。每次比价按顺序走一遍，不用重新想流程，也不容易漏项。用完把结论写成一句话存档，下次遇到同类问题直接翻出来看，比重新算一遍快得多。

1. 口径三问问清计价单位是什么、币种与结算方式是什么、有没有折扣和赠送额度。三问有任何一项没答案，先别往下算。
2. 算式三步对齐单位、算绝对差额、算百分比差。每一步的结果都写下来，不要跳步心算。
3. 复核三步到站内官方价页核对、到价格变动页核对、用计算器反算。三次核对里任何一次对不上，回到上一步重来。
4. 决策一句把差距归到可忽略、值得优化、必须换三档之一，写清对应的用量假设和基数选择。

整套方法的核心其实很朴素：单位对齐、差额算清、百分比说清基数、最后核对一遍。它不承诺你一定能省钱，只保证你下的结论不是拍脑袋来的。当差距落在可忽略档时，不动也是一种正确决策，把精力留给差距真正大的那一项。