大模型价格对比 实时更新

你可能已经存了好几份模型价目表，但过一阵就过期，或者几家单价看着差不多、算到最后总账却差一截。问题通常不在数字本身，而在口径没对齐、更新没节奏。这篇给一套可落地做法：先对齐计费口径，再做一张自己能维护的对照表，最后定下复查节奏和告警线，让比价这件事从一次性动作变成日常流程。

为什么存下来的价目表很快就不能用

很多人做价格对比的第一步，是把某天的价目表截图存下来，之后几个月都拿它当基准。问题在于，你存下的那一刻，这张表只是「那个时点的快照」，不是「现在的行情」。价格调整、限时促销、新模型上线，这三件事任何一件发生，旧表就开始失真。更麻烦的是，失真发生在起点：你后面算出来的单位成本、毛利、报价，全都建在一个过期的地基上。

• 价格调整：厂商随时可以改挂牌价，通常不发大通知，你可能从下个月账单才发现；
• 促销档：首充、限时折扣、阶梯优惠都有有效期，过期后按原价计费，你的表里还写着优惠价；
• 新模型上线：同一档位可能被新模型替代或挤压，老模型的定位、计费口径都会跟着变；
• 套餐/计费单位变更：从按 token 到按请求、按字符、按时长，口径一换，单价数字就没法直接对齐。
• 汇率与结算口径：境外厂商按美元挂牌、按结算日汇率折人民币，你表里的数字和实际扣款不一定同源。

第二类错误更隐蔽：拿不同渠道的单价直接横向比。同一个模型，官方直连、云厂商托管、聚合平台、中转站，报出来的「单价」往往不是一回事。有的只算输入，有的把输入输出分开写，有的把缓存命中价单独列，有的把并发、上下文长度、超时重试的成本藏在使用条款里。看起来每百万 token 便宜一点，实际跑起来可能更贵。

第三类误判是你自己的账：账单涨了，第一反应是「涨价了」，其实很可能是用量结构变了。同样的调用次数，输出占比从三成升到六成，总成本就会明显上去；再叠加重试、长上下文、缓存命中率下降，涨幅跟单价没关系。所以看账单要先拆「量」还是「价」，拆不开就容易把内部变化当成外部涨价，做出错误的采购决策。

1. 先拆量与价把账单按输入 token、输出 token、缓存命中、请求数分开看，确认是总量涨了，还是输出占比或重试率涨了；
2. 再对齐渠道口径同一模型分别记录官方直连、托管、聚合、中转的输入/输出/缓存单价与计费单位，列成同一张对照表；
3. 最后定刷新节奏给价目表设一个复核周期，促销类字段单独标注有效期，到 核对当期数字，别用旧快照做预算。

这套做法适合要出采购建议、做季度预算、给团队选默认模型的人。如果你只是跑几个固定小脚本、月消耗很低，花时间维护价目表不划算，直接按官方挂牌价估算、偶尔看一眼即可，不必追求实时更新——实时对比的收益，得建立在用量足够大、渠道选择影响预算的前提下。

先统一口径，再谈谁便宜

对比大模型价格时最常见的翻车，是把各种费用揉成一个数：输入、输出、缓存读、缓存写加在一起报个总价。这个数字看起来直观，但一放进实际用量里就会误导决策。很多场景输入远大于输出，缓存读写又占大头，合并计算后便宜的那家，未必是你真实账单里便宜的那家。

1. 先统一单位把所有候选模型的报价换算成「每百万 token」再比。站内官方价目表默认就是这个单位，直接照抄即可；如果某个渠道按「每千 token」报价，先乘以一千再放进同一张表。
2. 再拆成四项输入、输出、缓存读、缓存写各占一列，不要写在同一个单元格里。空着的项写「无」，不要留白，避免被当成零。
3. 按场景加权拿你自己的输入输出比例去乘。比如日常问答输入约为输出的数倍，就把输入价乘上这个倍数再看总成本，别直接比两个原始单价。
4. 核对当前数字官方标价到站内官方价目页核对，历史变动到价格追踪页看记录。两边对不上时，以变动记录里的时间点为准。

按次、按秒、按张计费的方式要单独放一张表。这类计费和 token 不是一套度量，混在一起排序没有意义：一次图像生成、一秒语音合成、一张识别单据，背后消耗的 token 数可能是浮动的，硬折算成每百万 token 反而会得出错误结论。把它们单列，按「一次任务大约多少钱」来比才合理。什么情况下不适用：调用量极大且能稳定换算成 token 时，才考虑折算，否则保持分表。

• 官方标价：厂商公开的价目，稳定但通常是最贵的一档
• 渠道折算价：中转或代理给出的折扣价，便宜但要确认是否长期有效
• 套餐摊薄价：预充值或包月摊到每次调用上的价格，只在用满额度时成立
• 三者放同一列排序，等于拿最贵的一档和最低的一档比，结论必然失真

排序前先给这三类价格打上标签，同一张表里只比同一类。官方标价和官方标价比，渠道折算价和渠道折算价比；套餐摊薄价最好单独标出「用满才成立」，用不满就是纯浪费。需要核对当前数字时，去站内官方价目页看标价，去价格追踪页看变动记录，两边都确认过再下结论。

做一张自己维护的对照表：字段清单

网上现成的对比表看着全，但字段是别人定的，未必对你团队有用。自己做一张的好处是：字段按你的实际调用习惯来定，更新节奏自己控，谁在维护一目了然。代价是得有人盯，所以先从最小字段集起步，别一上来堆十几列，没人填得动。

1. 先建空表按上面必填列搭出表头，币种、单位、是每千 token 还是每百万 token 统一写在第一行，别放在每格里重复。
2. 再决定建议列按团队真实场景加列：做长文档就加上下文上限，跑批量任务就加批量折扣。加之前问一句「这列谁会去看」，没人看就不加。
3. 定共享位置和唯一负责人放到团队共享文档或表格里，指定一个人负责更新，其他人只读不写。要提改动就在旁边留评论，由负责人统一录进去。
4. 设一个复核节奏负责人固定周期去站内页面核对一遍，把来源页面链接一起更新。改动后顺手更新「更新时间」那格，别人扫一眼就知道哪些行是新的。

• 来源页面留的是站内页面，不是随手截图，截图过期后没人知道原始数字从哪来
• 一列只放一个口径，输入和输出坚决分开，否则后面对不上账
• 占比那列按周更新而不是按月，月度数据太粗，看不出短期切换带来的变化
• 表里只保留团队在用的模型，历史模型移到另一个归档页，避免主表越滚越长
• 负责人只有一个人，别人要改先留言，否则两个版本同时存在，谁都不知道哪份是真的

这张表什么时候不适用？团队只有一个人调用、模型长期不变的时候，维护成本比收益高，直接看站内页面就够了。等出现第二个调用方、或者开始在不同渠道之间切换，再启动这张表。

按你的任务结构加权，而不是按单价排序

各家把单价贴在页面上，很容易让人顺着「每百万 token 多少钱」从低到高排一遍，然后挑最便宜那个。但你的账单不是按单价结的，是按输入和输出分别乘以你实际用了多少结的。同样一个模型，长文档任务里输入占九成，生成任务里输出占大头，两边加权出来的名次可能完全反过来。所以正确做法是先量自己的用量结构，再往回套单价。

1. 第一步：拉近一个月的用量账从你的调用日志或控制台导出近一个月的记录，按模型分别汇总输入 token 和输出 token 两个总量，算出各自的占比。没有日志就粗略估：随便挑五到十个典型请求，看它们平均输入多少、输出多少。
2. 第二步：给任务分类打标签把请求按用途分几堆，比如长文档阅读、多轮对话、内容生成、改写润色。每堆单独算输入输出比，因为同一家公司里不同业务的曲线差得很远，混在一起平均会互相抵消掉信息。
3. 第三步：代入单价算加权成本拿每一堆的输入占比乘以该模型的输入单价，加上输出占比乘以输出单价，得到一个「你这边的有效单价」。各家单价到站内价格页看当时的数字，别用记忆里的旧值。
4. 第四步：把隐性开销补上去在有效单价基础上再叠重试率和失败请求比例、缓存命中带来的折扣，以及同一段内容被重复发送的浪费。最后得到的是「实际每完成一次任务花多少」，不是每百万 token 多少。

• 任务量太小的时候别排：一个月几百次调用，随机波动就能把名次掀翻，看趋势比看排序靠谱
• 任务结构波动大的时候别硬排：这个月做摘要、下个月做生成，加权结果下个月就作废
• 重试率高的模型要单独拎出来看，失败请求照样计费的部分要算进有效成本
• 缓存命中率差别很大的两家放一起比单价没有意义，先把命中率对齐再比
• 加权算完的排序只对你当前的任务结构成立，业务一换就得重算

这套算法唯一的输入就是「你自己近一个月的用量结构」。结构不稳的时候，结论自然不稳，这时候正确姿势是拉长时间窗看趋势，而不是盯着一周的排序下决心。想拿各家当前单价做代入，直接去站内价格页面核对当时的数字，再用上面的步骤算自己的加权账。

更新节奏：多久看一次，看什么

价格页面天天都在动，但你不必天天看。真正把事情做乱的，往往是「一天刷三次」的人：看到某个数字变了就慌，结果那只是别人家新上的一个档位，跟你手上的活儿一点关系没有。稳住节奏反而更省心——每周扫一次变动，每月做一次完整核对，两次的深度和目标都不一样。

每周那次，目标只有一个：确认你正在用的东西有没有被动过。每月那次，才去横向比一圈，看有没有新出现的低价档、有没有同类替代品悄悄降下来了。频率降下来，每次看的范围反而能看得更细，不会漏。

每周扫一遍：只盯三件事

• 你正在用的模型有没有调价：包括单价、计费单位、是否有最低消费门槛，去站内模型资料库对你实际在用的那几个，别顺手把没用过的也扫一遍；
• 有没有同类替代品降价：同档位、同能力区间的其他选项，记下名字就行，先不动手切换；
• 有没有新增低价档：新上线的档位往往先进「低价」区间试水，看到就记一条，等月度核对时再评估。

这三件事里，只有第一件需要你立刻反应。后两件都只是「登记」，记下来即可。很多人把登记当成决策，看到别家降了就马上想换，结果迁移成本和适配时间全算进去，反而不划算。什么情况下不适用：如果你手上跑的是长期批处理、对单价极其敏感，那第二件事的优先级可以提到前面。

每月做一次完整核对

1. 先把上月的记录翻出来对照你自己维护的那份清单，标出本周扫到但还没确认的条目，逐条回到站内模型资料库确认现状。
2. 再横向比一轮同档位按能力区间分组比，不要按厂商名字一个个点。同一组的放到一起看，才看得出谁在哪个位置。
3. 核对额度与套餐规则这一项经常被跳过，但它比单价更容易让账单超预期。把计费周期、赠送额度是否清零、速率限制这类规则单独列一栏。
4. 更新你自己的成本估算表成本表里只写「用哪个页面、什么时候看的」，金额一律留空或写「以站内当期页面为准」，等真要下单时再代入具体数字。

还有一件事值得单独拆出来：价格变动和额度、套餐规则变动，最好分成两张表记。原因很直接——单价涨一点，你可能只是多花一点；但赠送额度取消、计费周期从月变周、速率上限调低，这些规则层面的变化对实际支出的影响往往更大，而且更不容易在价格页一眼看出来。混在一张表里，你只会盯着数字，忽略规则。

两张表分开之后，你会发现自己对「贵不贵」的判断清楚了：单价表帮你算单位成本，规则表帮你算实际可用量。只算前者，很容易得出一个偏乐观的结论。想看成体系的对比框架，可以去站内价格对比页面按你实际的使用量口径再核一遍，那里给的是当期口径，比自己堆数字靠谱。

看到更便宜的，先过这张清单再换

看到别家单价更低就想换，先别急。单价只是账单里最容易被看见的那一格，真正决定你省不省的是「单价 × 用量 × 返工次数」。同一个任务，便宜的那家如果要多试两次、被限速卡住、或者上下文塞不下要拆成两段，省下来的那点差价很容易被吃回去。下面这张清单，照着走一遍再决定动不动。

1. 先算迁移量把现在用的提示词、输出解析逻辑、工具调用清单列出来，逐条问：换一家要不要改。改的行数多、解析规则要重写，就先记一笔迁移成本。
2. 再跑同一批任务挑一批你线上真实遇到过、有明确对错的任务，两边各跑一遍，结果并排看。别只看单价，也别只看一两个讨巧的样例。
3. 把隐性成本记成数字统计观察期内：失败要重试几次、有没有被限速排队、长输入有没有被截断导致返工。这些都要折成时间或调用量。
4. 设退出条件观察期开始前就写清楚：综合成本（含迁移工时+返工）没比原来低，就换回去。别因为「已经改完了」硬扛。

• 提示词：是原样能用，还是每段都要微调语气和格式
• 输出格式：JSON/表格能不能直接解析，还是要写容错兜底
• 工具调用：参数结构、并行调用、报错返回是否兼容
• 长上下文：超长输入会不会被截断，要不要自己拆段
• 限速：高峰期会不会排队，排队时业务受不受影响

哪些情况这张清单不适用？如果你只是临时试个新玩法、或者这个任务本来就允许出错重来，那迁移和返工成本可以放低权重，直接上手试就行。反过来，如果这条链路是线上的主流程、下游有人依赖你的输出格式，那哪怕单价便宜不少，也要把迁移和质量这两关走完再动。想核对当时各家的公开报价和模型资料，到站内价格对比页看当时的数字。

把对照表接到预算和告警上

光有对照表没用，得让它去管钱。做法是按模型分组各拉一条预算线，比如「对话主力模型」「批处理便宜模型」分开算，因为它们的消耗节奏完全不同。快触线的时候，优先降级模型或砍非关键任务，而不是一上来就停机。

1. 分组预算线按模型分组设月度预算，每组单独一条线。验证方式：随便挑一天，看某组消耗是否只算进了这组，没串到别组。
2. 触线动作顺序先降级模型，再削减非关键任务，最后才考虑停服。验证方式：模拟一次触线，看动作是否按这个顺序自动触发，而不是直接全停。
3. 口径切换把预算口径从「看余额」改成「预估消耗 × 单价」。验证方式：对比两种口径当天的数字，余额波动但预估消耗平稳，说明切对了。
4. 每月复盘偏差每月对一次账，问一句：实际花费和对照表估算差在哪，是调用结构变了，还是单价变了。验证方式：偏差能归到具体某一项原因，而不是笼统说「用多了」。

预算口径这块最容易踩坑。直接看账户余额，会被充值节奏带偏——刚充完钱显得很宽裕，快没钱了又突然紧张，跟真实消耗没关系。用「预估消耗 × 单价」算，才是这段时间真正烧掉多少。单价从哪来？到 站内价格对照页（/pricing） 按当时数字核对，别记死一个数。

记录字段的核心是能追溯。至少要有调用方（人还是项目）、模型分组、预估消耗与单价、账期这几项，否则月底对不上账时根本无从查起。至于单价本身会变，去 站内价格对照页（/pricing） 看当时数字，别拿旧值当准数。