大模型比价网站，4个参数比价格更要紧

同一家的模型，在大模型比价网站上能给出两个差一截的单价，你信哪个？多数人是拿单价乘调用量就完事了，算得像模像样，月底一核对不上，差的钱全在价目表底下没写的那几行小字里。比价这事，价格是最后一个才该看的东西，前面挡着四个参数，这四个不拉齐，你算出来的数字就是自己骗自己。

计价单位不统一，比出来全是假数

有的页面写每百万 token，有的写每千 token，中间差三个数量级，眼睛一扫很容易看串，我见过有人把每千的价格当成每百万，兴奋半天。还有输入价和输出价分开算的，输出那一头往往贵一截，你按输入价估预算，结果聊天型业务输出占大头，账单直接翻脸。缓存命中价又是另一档，有的服务商读缓存便宜很多、写缓存另算钱，你业务里如果挂着大段固定的系统提示词，这一项能省不少，反过来没留意就是白扔。所以看比价页面的第一件事不是看数字大小，是把单位、输入输出、缓存这几栏拉到同一口径，口径齐了再谈贵不贵。

大模型比价网站最该盯的是上下文长度

上下文长度在价目表上就一个数，实际影响比单价大得多。你要处理的是一整份合同、一大段日志、几十轮对话记录，塞不进去就得切块，切块就是多次调用，每次调用都从头计费，本来一次能搞定的事拆成五六次，单价再便宜也架不住这么烧。反过来说，上下文特别长的型号单价通常高一档，可你一天只跑那么几百次长文档任务，多付的那点单价换回一次成型，账算下来未必亏。所以比价之前先问自己一句：我一个请求最长要吃进多少 token。答案不清楚，挑型号就是瞎挑。

限流和并发，价目表上基本不写

便宜的那家为什么便宜，很多时候差在限流上。每分钟请求数、每分钟 token 上限、能同时挂几个并发，这几项比价站上常常没有，得翻文档或者直接问客服。限制一紧，程序就会撞 429，然后重试、退避、排队，一个用户请求变成三次调用，省下的单价全被重试吃回去，延迟还很难看。评估办法不复杂，拿你峰值时段的真实流量跑一轮，看排队时间和失败率，别只盯着价格页上那个大号字体。

输出长度这一刀最阴

按 token 计费的模型，输出这一头经常被低估。max_tokens 设得宽，模型话就多，钱跟着多。现在不少模型会先吐一段思考过程再给答案，这段过程也算 token，你以为只付了答案的钱，实际把思考的钱也付了，账单上还不一定给你拆开看。JSON 输出、结构化字段这些，长度又比纯文本回答长一截。做预算的时候，输出倍率按你业务里最长的那类回答去估，别拿最短的那条当样本。顺手把 max_tokens 卡死，超长的内容让它分段吐，别一次放养。

多模型混跑，路由本身也吃成本

不少人图省钱搞混跑，简单活给便宜型号，复杂活转给贵的。思路没错，坑在判断逻辑上。路由判错一次，请求先发给便宜的那家、答得不行再转手，等于两次调用付两份钱，还多一段延迟。这套东西要调，得拿真实请求的回放数据去校，别凭感觉写规则。混跑省下的钱，是先扣掉路由判断本身的开销之后才算数的。

稳定性和版本变更，价格之外的隐形成本

模型会改名、会下线、会调价，也有服务商拿限时优惠拉新，到期恢复原价。这些以官方公告和页面说明为准，别拿一张截图当合同。真正要防的是代码里把模型名写死，人家一改你全线报错。把模型标识做成配置项，留一个能随时切的备用型号，比省那几厘钱重要得多。另外服务可用性、节点地域、数据会不会被拿去训练，这些也得在比价之外单独确认，尤其你手上跑的是客户数据。

我自己的笨办法：拿真实请求跑一遍账单

挑二三十条线上真实请求，长的短的搭配着来，两家各跑一遍，对比账单、失败次数、p95 延迟。方法笨，但比对着价目表摁计算器靠谱得多。跑一轮经常能看到：看着便宜的那家，因为重试和截断，实际花销反而高一点。跑完再决定要不要上量，别一上来就全量切过去，切过去再切回来，光改代码就够你忙半天。

比价的顺序，我建议倒过来

现在是这么排的：先筛掉合规和稳定性过不了关的，再把计价单位、输入输出、缓存口径对齐，然后用真实请求跑账单，最后才回头看单价那个数字。单价是最后一道关，不是第一道。顺序一倒，很多所谓性价比之王自己就露馅了。

顺手留个清单，比价前先填：我单个请求最长多少 token、输出平均多长、峰值每分钟多少请求、每月大概多少次调用、数据敏不敏感、能不能接受模型临时下线。这六条写不出来，就先别急着比价，比了也是拍脑袋。填完了再去看价格，你会发现能选的范围一下子窄了很多，反而不纠结。