同一份文本在不同平台跑要花多少钱？实测账单对比

不少人做选型时习惯直接看单价表，觉得数字小的那家就一定便宜。真跑起来才发现：同一段文本，两家的账单能差出好几倍，而差异未必来自单价本身。这篇给一套可复用的对照做法——先固定输入和参数，再逐项对齐计费口径，最后回到站内页面核对当时的数字，避免拿一个不对等的对比下结论。

做选型时只盯单价表，很容易得出一个反直觉的结论：同一段文本，在两家的账单能差出好几倍，而差距未必来自单价本身。真正决定账单的，是你固定的输入、对齐的口径和平台各自的计价规则。

这篇给一套能复用的对照做法：先把输入和参数钉死，再把账单拆成能对齐的几项，然后回到站内页面核对当时的数字，最后把结论落到选型上，而不是停在「哪家便宜」。

第一步：把输入和参数钉死，否则对比没有意义

很多人对比时直接拿一段随手找的文本去两边跑，结果第三次跑出来又不一样。问题不在平台，在于输入和参数没固定。同一段中文，改一个标点、加一句提示词、换个全角空格，切分结果就可能变，账单自然没法比。

1. 复制同一段原文用完全一致的字符，不做二次改写、不加提示词包装。中英文混排和全半角标点都会影响切分，跑之前把文本原样贴过去。
2. 逐项固定可比参数系统提示词长度、是否带历史对话、输出上限、是否开启流式、是否复用缓存、重试次数，全部写成一张对照表，两边保持一致。
3. 确认自己用的是哪个口径先分清官方直连、中转、还是订阅制额度。这三种的账单结构本来就不一样，混着比没有意义。
4. 跑两到三次取中间值单次结果容易被排队、降级、重试干扰。同一个任务多跑一次，看账单落在哪个区间，再拿去对比。

第二步：把账单拆成能对齐的几项，别只看总额

账单总额是个结果，不是原因。要把总额拆成输入、输出、缓存读、缓存写这四项，才能看出差在哪。有些平台把缓存合在输入里报，需要按口径换算后再比，否则你比的可能是两种不同的东西。

• 至少拆成四项看：输入、输出、缓存读、缓存写，别只看总额。
• 注意输出侧是否含推理过程、是否把工具调用参数算进输出，这两项常让账单比预估高一截。
• 对照站内 /usage 与 /price-watch 看当时的实际用量分布与价格变动记录。
• 回到 /official-api 与 /ai-nav/category/ai-model-platform 核对厂商侧口径，确认自己理解的是同一套规则。
• 把「单价×用量」和实际扣费对一次账，差额落到哪一项上，问题就在哪一项。

第三步：差异通常来自这四个地方

对齐之后你会发现，同一段文本的账单差异，基本能归到四类原因上。逐类排查，比笼统说「这家贵」有用得多，也方便你判断这个差异是长期结构性的，还是这次任务碰巧触发的。

切分方式不同

同一段中文在不同分词口径下 token 数不一样，长文档会把差距放大。

计价项覆盖范围不同

有的含缓存、有的不含，有的对失败请求也计费，有的按成功计。

倍率与分组

中转站报价单上的倍率、分组、计价项三列要分开读，别看成一个数。

汇率与结算方式

外币结算的订阅或充值，真实成本要把通道费算进去；具体数字到 /plans 与 /card-prices 看当时的对照。

排查顺序建议从切分开始：先确认两边的 token 数是否一致，不一致就先解决这个；一致了再去看计价项覆盖范围，最后才看倍率和结算。顺序反了，容易在最后一层反复算，却解决不了前一层的问题。

第四步：把结论落到选型上，而不是停在「哪家便宜」

实测账单的价值不在于告诉你哪家便宜，而在于帮你判断：这个任务对成本到底敏不敏感，要留几手。先按任务分类，再决定投入多少精力做对比。

• 先按任务分类：高频短请求、长文档处理、编程类长会话，三者的成本结构完全不同，别用一次对比覆盖全部场景。
• 给每个场景挑两到三家做备份，主力加降级组合比死磕一家更稳，具体路由做法可以参考多模型路由相关文章。
• 把这次实测的输入、参数、账单三项记下来，作为后续价格变动时的基线；价格改了就重跑一次，别沿用旧结论。
• 什么情况下这套对比不适用：你的量很小，或者任务本身就要求特定模型能力时，成本差异不足以成为决策依据。