很多人做成本对比表,第一反应是把各家每百万 token 的单价抄进 Excel 排个序,结果排完发现跟自己实际花的钱对不上。问题不在数字抄错,而在口径没对齐:输入输出分开计价、缓存有单独价、按次和按量混在一起、还有汇率和倍率在后面等着。这篇给一套做表的结构和填表顺序,让表里的每一列都能回答一个具体问题。
很多人做成本对比表的起点,是打开各家的定价页,把每百万 token 的单价抄进 Excel,按从小到大排个序,然后挑最便宜的那个。排完之后过一个月看账单,发现跟自己花掉的钱对不上。问题通常不在抄错数,而在口径没对齐:有的按输入输出分开计价,有的缓存命中是另一套价,有的按月订阅打包,还有汇率和倍率在后面等着。
这篇不讲哪家便宜,讲这张表本身的骨架应该怎么搭。目标很具体:让表里每一列都能回答一个明确问题,让你把不可比的单价,折算成能横向比较的总价。表做对了,之后换模型、调用量、换渠道,只需要动几行,而不是整张重做。
先把表的行列定下来:比什么、按什么比
行列定错,后面填得再仔细也没用。一个常见毛病是一列里塞了两个含义,比如「单价」这列,A 家填的是输入价、B 家填的是综合价,排完序毫无意义。行放候选方案,列放费用维度,一列只承担一个含义,这是最省事的规矩。
| 列名 | 填什么 | 注意点 |
|---|---|---|
| 按量单价 | 输入、输出分开两列 | 别合并成一列,合并后排序失真 |
| 按次单价 | 每次调用一口价的方案 | 要写清一次调用覆盖多长上下文 |
| 订阅固定费 | 月付/年付打包额度 | 折算前先看额度是否够用 |
| 隐性费用 | 最低充值、并发加价、超额 | 最容易漏,漏了总价就偏 |
| 口径来源 | 官方公示还是渠道说明 | 来源不同不能并排排序 |
- 每列标注口径来源,注明是官方页还是第三方渠道,口径不一致的不能直接排序
- 先定比较单位:一次典型任务、一个月、还是一千次调用,单位换了结论可能反过来
- 同一行里的数字要来自同一时间点,混着不同时期抓的数据会互相打架
- 拿不准的列先留空并写原因,硬填一个估算值比空着更危险
把不同计价方式折算到同一个分母
各家计价方式不一样,有的按量、有的按次、有的按月打包,直接放一起没法比。折算的核心思路是:找一个你自己确定的典型用量,把每种计价方式都换算成「完成这个用量要花多少」。用量假设要来自你自己的业务,别拿官方示例长度凑数。
- 按量转按次先统计你一次典型请求的实际 token 量(输入加输出),再乘上对应单价,得到单次成本,验证方式是用最近一次真实账单反推用量是否接近。
- 按次转按量按最坏情况用量算,而不是平均值,避免套餐看着便宜、用量一上去就被打穿;验证方式是模拟一个高峰日的调用次数。
- 订阅转等效用量把套餐额度按站内折算口径换算成等效用量,再看这个额度覆盖你几成需求,覆盖不到一半的就把超额部分单独算一列。
- 三项归一后同列对比折算完再放进同一列,算不出来的留空并标原因,不要用一个模糊估值凑齐整张表。
折算过程中最容易错的是拿平均用量去套低价套餐。低价套餐的额度通常在你用量上来之后就不够了,超出部分的价格可能比按量方案更高。所以按次转按量这一步,一定要用峰值而不是均值。
填表顺序与自查:先填贵的还是先填准的
填表顺序建议从确定性最高的开始,而不是从最便宜的开始。先填自己确定会用的方案,再填候选方案,最后填兜底方案。这样填的好处是,主要成本先被固定住,候选方案只要比较相对差值,不用每一格都精确到小数。
- 每个数字标一个可信度:官方公示、渠道说明、自己实测,实测的最优先
- 算完横向比一遍量级,出现十倍以上差距通常是用量假设错了,回去查假设而不是改数字
- 表里保留一列备注,写清这个方案在什么情况下不适用,比如限速、并发上限、地域限制
- 把你实际跑出来的账单贴在表旁边做对照,表算出来的总价和账单差多少,差在哪一列
- 可信度标记
- 给每个数字标来源等级,实测高于渠道说明,渠道说明高于道听途说
- 量级校验
- 横向扫一遍,差距异常大的先怀疑假设,不要怀疑自己算错
- 不适用备注
- 写清限速、并发、地域等触发条件,避免方案换了才发现不能用
表不是做完就完:什么时候该重算
成本表最怕的是做完锁死在某个文件里,半年后没人知道里面的数字是什么时候的。要让它活得久,就得定好重算的触发条件和记录方式。重点不是天天更新,而是知道什么时候必须更新。
| 触发信号 | 先动哪部分 | 怎么验证 |
|---|---|---|
| 换了主力模型 | 只更新受影响的行 | 拿新模型跑一周账单对比 |
| 用量结构变了 | 重算折算系数 | 看峰谷比是否明显变化 |
| 渠道计费口径调整 | 核对受影响列 | 到站内价格页对一遍当时数字 |
| 多人协作改动 | 看更新记录列 | 确认谁改的、改了什么 |
具体数字不要写死在表里,改成指向站内当时的数据页,到期就去对一遍。比如各家 API 的价格结构可以到 价格追踪页(/price-watch) 核对当时的口径,候选渠道的可信度可以到 中转站导航(/sites) 看检测结果。这样表里存的是结构和假设,数字留在源头,避免你抄来的数字过期后没人发现。
成本对比表的价值不在某个数字,而在它逼你把用量假设和计价口径写成能复查的东西。下一步先把你的典型用量算出来,再照着上面的列结构搭一张空表,然后去站内价格页核对当时的数字填进去。→
常见问题
成本对比表里要不要写具体单价?
建议不要在正文或长期文档里写死单价,价格和口径会变,写死了下次就得全表返工。更稳的做法是表里只留结构和公式,单价指向站内当时的数据页去核对,比如官方 API 价格页和价格追踪页,每次用表前先对一遍数字。
各家计费方式不一样,真的能放在一张表里比吗?
能比,但前提是先折算到同一个分母,比如都换成「跑完同一批任务要花多少」。折算不出来的项不要硬塞进排序,单独列出来说明原因。按 token、按次、按订阅混着比,结论通常是错的。
我们团队就三五个人,有必要做这张表吗?
如果每月调用量不大、只用一个渠道,可以先不做完整表,只记两条:自己的典型用量、当期单价。等出现第二个候选渠道、或者账单开始明显波动时再搭表,那时候你已经有真实用量数据,表会准得多。