gpt-4o 和 gpt-4o mini 成本差多少

选型时很容易卡在同一个问题上：同一个功能，用高价那款和低价那款，账单到底差在哪、差多少。光看单价数字没用，因为输入输出配比、上下文长度、缓存命中率一变，结论就反过来。这篇给一套固定口径的对比流程，再给一份能直接照着改的替换清单，帮你判断哪些任务该换、哪些别动。

选型卡住的往往不是「哪个更强」，而是同一个功能用高价那款和低价那款，账单到底差在哪、差多少。光盯单价倍数没意义，输入输出配比、上下文长度、缓存命中率一变，结论就可能反过来。

下面给一套固定口径的对比流程，再给一份能直接照着改的替换清单：哪些任务可以放心换到低价款，哪些别动。全程不写死数字，需要具体价格去站内官方 API 页面对当期数据。

差距从哪来：先对齐三个口径再谈倍数

第一个口径是输入价和输出价必须分开看。两款模型的输出侧加价幅度通常和输入侧不一样，只算一个平均单价会把结论带偏，尤其对输出 token 占比高的任务。

• 渠道要固定：同一款模型在官方直连、云厂商、聚合平台的单价不同，比之前先锁死一个渠道，去 /official-api 核对当期数字
• 上下文与输出上限：低价款常见限制是窗口更小、单次输出更短，限制会改变调用方式，进而改变成本
• 能力支持度：多模态、结构化输出、工具调用的支持程度不同，缺一项就得加后处理，等于变相加钱
• 缓存与批处理：能不能命中缓存、有没有批处理折扣，会直接覆盖掉单价差额

同一件事换模型：怎么算出真实差额

1. 固定样本挑一个代表性任务，准备一批真实输入，两款模型跑同一批，别只跑一条就下结论。
2. 记四项数据输入 token、输出 token、重试次数、实际耗时。输出 token 往往是差额的主要来源，重试次数是隐藏项。
3. 换算成钱把用量导入 /tools/model-cost-calculator 换算，别手算，避免把单价口径搞混。
4. 写成单位成本结论落成「每千次任务差多少」，而不是「单价差几倍」，前者才能进预算表。

还有一个容易被忽略的点：低价款如果上下文短、无法命中缓存，省下的单价可能被重复的输入吃回去。对比时要把缓存命中率一起记录，否则账面省钱、实际没省。

单价差几倍不重要，每千次任务差多少才进得了预算表。

什么活可以换、什么活别换

• 灰度办法：先切一小部分流量，用 /tools/quality-check 比对新旧输出，稳定后再放量
• 兜底规则提前定：某类任务返工率或人工复核比例超过阈值就切回高价款
• 别全量一次性切换：留一条回滚路径，出问题能几分钟切回来
• 记录切换后的真实用量：换完第一个计费周期去对账，看省的钱是不是等于预期

不适用的场景也要说清：如果你的任务输出很长、或者需要模型稳定遵守一长串规则，低价款就算单价便宜，返工和人工复核加起来也未必划算，这类就别换。

选型前的四步检查清单

• 把现有调用按任务类型分组，标出每组的输入输出大致比例和日均调用量
• 挑出占比最高的两三组做替换测试，别全量铺开
• 对比基础成本、返工成本、人工复核成本三块之和，而不是只比单价
• 把结论和触发条件写进监控：单价变动、任务形态变化、上下文变长时重新评估

监控里要留的触发条件具体一点，比如某组任务的输入长度平均值上浮、输出被截断比例升高、重试次数变多，出现任一条就重新跑一遍对比流程。价格是会动的，去 /price-watch 看当前的追踪结果，别拿半年前的印象做决策。