你可能正卡在这一步：手上列了三五个候选模型，各家价格页的单位、口径、阶梯都不一样，算下来完全没法比。或者你按官方单价估了个预算，账单出来却差了一截。这篇不讲哪个模型强，只讲怎么把不同厂商的计费方式掰到同一把尺子上量，给一套可执行的对比流程和判断标准。
手上列了三五个候选模型，打开各家价格页准备算账，结果发现根本对不上：这家按 token 量计费，那家按调用次数收，还有一家给你一个套餐额度让你自己折算。单位都不一样，直接比单价纯属自欺欺人。更别扭的是，你按官方标价估了个预算，月底账单出来还是差一截——差的那部分通常藏在你压根没注意的计费档位里。
这篇不讲哪个模型强，也不给你一个「最划算」的结论，因为划算与否取决于你自己的请求分布。它只解决一件事：怎么把不同厂商的计费方式掰到同一把尺子上量。下面给一套可执行的对比流程和判断标准，顺带说清哪些情况下这种对比压根不适用，省得你拿一张漂亮表格去做了个错误决策。
先把计费口径对齐，再谈谁贵谁便宜
横向比价的第一步不是打开价格页抄数字，而是先确认各家用的到底是不是同一种「货币」。常见的计费单位有三种：按 token 量、按调用次数、按套餐额度折算。拿一个按次计费的模型去和一个按 token 计费的模型比数字，就像拿斤去比米，结论没有意义。
- 按 token 量
- 按输入和输出分别计价，长文本代价随长度线性放大，适合请求长度波动大的场景。
- 按调用次数
- 每次请求一个固定价，请求越长越划算，但短请求会显得很亏。
- 按套餐额度
- 先买一份额度池，实际单价取决于你用掉多少，用不完就相当于单价上浮。
即便同为 token 计费，还要确认输入和输出是否分开定价、有没有缓存命中价、有没有批处理通道价。同一个模型在不同档位之间的差距，往往比你换一个模型带来的差距还大。这些口径各家会随时调整，别凭印象记数字，到站内的官方 API 资料页核对当时的写法。
- 先记单位，再记数字：单位没对齐之前，任何数字都先放一边
- 同一模型拆成几档看：标准档、缓存命中档、批处理档分别记一行，不要合并
- 确认计费边界：哪些算输入、哪些算输出、失败请求是否计费，写进你的对比表备注列
- 口径来源固定：以官方 API 页面和模型平台分类页为准，社区转述只能当线索不能当依据
单价之外，真正拉开差距的四个变量
把单价对齐之后你会发现，候选模型之间的差距常常没那么大。真正让账单跑偏的，是四个藏在单价背后的变量。它们不容易在价格页上直接看到，但会实打实改变你每月的支出结构。
| 变量 | 它怎么影响成本 | 你可以做什么 |
|---|---|---|
| 上下文长度 | 长输入请求常触发更高档位单价，平均长度偏大时总价抬升明显 | 先统计自己请求的输入长度分布，再挑匹配的档位，别用最短的那档估预算 |
| 并发与限流 | 限流引起排队和重试，重试按新请求计费，时间成本也真实存在 | 把峰值并发写进对比表，必要时用限流规则更宽松的档位 |
| 缓存与批处理 | 可复用的重复前缀能按低价计，批处理通道通常另有折扣 | 能批量的任务就别走实时通道，能命中缓存的前缀就固定下来 |
| 失败重试与流式中断 | 重试按新请求扣，流式断流前已生成的 token 照扣 | 靠日志复盘重试率和中断率，这两项高了再便宜的单价也顶不住 |
这张表的使用方式很简单：每次对比都把四个变量过一遍，凡是会命中你实际场景的就打勾，只在打勾的候选之间做终选。没打的变量不用纠结，纠结它只是在给自己增加决策噪音。
做一次横向对比的可执行步骤
下面这套流程适合刚开始选型、手上还没有历史账单的人。核心思路是先建骨架再填数，避免一上来就陷进各家价格页的细节里出不来。整个流程走完大概半天，比反复横跳地看价格页高效得多。
- 先立表头建一张表，列固定为：候选模型 / 计费单位 / 输入价档 / 输出价档 / 缓存价 / 限流条件。字段先齐再填数，缺字段的候选先标记为待补，不要用估计值糊过去。
- 统一换算基准用站内的 token 价格换算器把不同单位折算到同一基准，把换算时的假设写在表格备注里。换算工具会随口径更新，去工具目录页找当前入口。
- 按真实分布估拿你自己近期的请求日志统计输入输出长度、请求频次、峰值并发，别用行业平均值硬套。峰值场景单独算一遍，避免平均值把风险抹平。
- 标注附加口径汇率、地区价、套餐折算规则都标在表里。跨区订阅和按量 API 是两套账，混在一起算就会得出错误的对比结论。
- 留一列复审备注记下你的假设和不确定项，两周后拿真实账单回来对一遍，看哪一列估得最不准，下次优先修正它。
流程里最容易偷懒的是第三步。很多人图快，直接用一个「平均每次请求大概多少 token」的模糊数字乘总量，结果长请求占比一高，预算就崩了。宁可多花半小时做一次真实分布统计，也别在估算上省这点功夫。
哪些情况下这种对比不适用
横向比价有它的射程，超出射程就该换个判断方法。下面几种情况里，把单价拉到同一把尺子上量不但没意义，还会误导你做出看起来理性、实际吃亏的选择。
- 任务对延迟敏感：便宜档位往往排队更久，省下的预算可能换来更差的响应体验，此时该比的是稳定延迟而不是单价
- 质量差距过大：两个模型在同一任务上的可用输出比例差很多，单价低不等于总成本低，返工和人工兜底都要算进去
- 合规或数据驻留要求：可选项被提前收窄，比较只能在合规清单内做，清单外的模型再便宜也不能用
- 套餐与按量混用：订阅额度用不完和用超后按量补，边际成本是分段的，拿单一单价乘总量必然算错
- 请求量极小：总量本来就小，凑各种折扣档位花掉的时间成本可能超过省下的钱，直接挑最省事的方案就行
判断标准可以简化成一句话：如果你的核心约束不是「每单位调用花多少钱」，那这份对比就不是你的主决策依据。这种情况下，把比价表当参考，把延迟、可用率、合规这些硬约束放到前面来筛。
下一步：把你这张表填成活的静态的价格表三天就过期。去价格追踪页看各家计费口径和价格的变动记录，再回到官方 API 资料页核对当前口径，把你上面那张对比表的数字更新一遍。→常见问题
不同厂商的 token 计费为什么对不上？
因为切分规则不同：同一段中文，不同分词器切出的 token 数能差不少，标点、代码、多语言的差异更明显。所以对比时别只看单价，要拿你自己的一段真实素材分别跑一遍，比较实际消耗的 token 数和最终费用，单价比对只作为初筛。
按量 API 便宜还是订阅套餐便宜？
看调用是否稳定。用量平稳且能跑满额度，订阅折算下来通常更划算；用量忽高忽低、有长时间空档，按量更安全。判断依据是你自己的日均调用曲线，不是哪家宣传的折算价。到 /coding-plans 和 /plans 看当时的额度口径再决定。
缓存和批处理降价值不值得为它改架构？
只有当你的请求里有大段可复用的固定前缀，或者任务本身能接受延迟时才值得。硬凑缓存前缀会把提示词写得很别扭，反而影响效果；批处理只适合离线任务。先量化命中率能到多少，再决定改不改。
