GPT-5.6 与性价比的极限 — 如何在曲线上找到自己负载的位置

• 引言 — 发布三周就降价 80%，这说明了什么
• 7 月 9 日到 7 月 30 日之间变了什么
• 曲线的斜率 — 以及厂商的效率主张
• 别按头条价格算，要按配比算 — 可这次配比不起作用
• 缓存能挪动曲线的区间，和挪不动的区间
• Fast 模式 — 延迟被单独挂上了价目表
• 基准捕捉不到的东西
• 结语 — 曲线会一直往下走，但自己的位置只有自己去量才知道

引言 — 发布三周就降价 80%，这说明了什么

2026 年 7 月 30 日，OpenAI 把 GPT-5.6 Luna 的价格下调了 80%。从每 100 万 token 输入 1 美元、输出 6 美元，变成输入 0.20 美元、输出 1.20 美元。中间档 Terra 下调 20%，变成输入 2 美元、输出 12 美元；最顶端的 Sol 仍是输入 5 美元、输出 30 美元。GPT-5.6 系列正式发布是在 7 月 9 日，所以这是三周之内的调整。

同一天发布的第二项内容，把这次动作的性质说得更清楚。原来的 Priority processing 改名为 Fast 模式，并且只对 Sol 提供最高相当于标准 2.5 倍的速度，价格是标准价的 2 倍。OpenAI 的 API 文档明确写着这是「只提速，不改变智能」。也就是说，下面的档位靠降价守住量，上面的档位则开始把延迟拆成单独的商品来卖。

有一个数字常被当作背景引用。多家媒体援引 CNBC 的报道称，按 OpenRouter 口径，美国企业 token 用量的 46% 被中国模型拿走了。这个数字最初是怎么统计出来的，我没能确认，所以只当作被报道的说法来处理。不过降价幅度的不对称(下面 80%，上面 0%)瞄准的是哪里，似乎不必特意解释。

本文的主题不是降价这条新闻。每单位能力的成本已经沿着一条曲线下落了好几年，单次降价只是这条曲线上的一个点。有用的问题只有一个 — 我的负载在这条曲线的哪个位置，这次移动是否真的挪动了那个位置。

7 月 9 日到 7 月 30 日之间变了什么

把 Artificial Analysis 在发布时汇总的指标和这次降价放进同一张表，就是下面这样。指数任务单件成本的降价后数值，是我直接套用降价比例算出来的，并假定 token 消耗量不变。

在同一指数上，Claude Fable 5 的最高强度分数被记为 60。也就是说，Sol 在综合智能上落后 1 分，跑完整个指数的成本却只有三分之一 — 这是 Artificial Analysis 在发布当时给出的总结。

竖着读这张表更有意思。智能指数是 59、55、51，每次降 4 分，而指数任务单件成本是 1.04 美元、0.44 美元、0.042 美元，每次掉一个数量级。买下智能指数 4 分所需要的钱，在不同区间上相差十倍。之所以用「曲线」这个词，原因就在这里。在上端，一点点能力要花非常多的钱；在下端，同样的钱能买到多得多的能力。

曲线的斜率 — 以及厂商的效率主张

关于每单位能力成本下降速度的引用满天飞，但大多出处含糊。其中被引用得比较多的一种说法是：把某个基准水平固定住，达到那个性能的价格每年会下降几倍到十倍左右。这次降价是那条趋势线上的一个点，只有三周这个间隔算是异常，方向本身并不新鲜。

这里有一个厂商主张值得验证一下。GPT-5.6 发布时，OpenAI 方面做过一个大意是「在特定任务上 token 效率改善了 54%」的说明，多家媒体也转述了。这是一条带着「特定任务」这个限定语的厂商主张。而独立汇总那一侧的数字要保守得多 — 按 Artificial Analysis 的口径，Sol 处理一件指数任务用掉的输出 token 是 15,000 个，比上一代 GPT-5.5 的 16,000 个约少 6%。

这两个数字并不矛盾。54% 出自挑选过的任务，6% 出自整个综合指数。但能放进实务计划里的是后者。厂商一旦挂上「在特定任务上」这个限定语，这个限定语本身就是禁止外推的标记。自己任务上的 token 消耗只能自己直接去测，而这项测量恰恰是换模型之前必须做的事。

别按头条价格算，要按配比算 — 可这次配比不起作用

通常比较两个模型时的第一个坑，是只看输入价格。因为各家厂商的输出对输入倍率不同，同样这两个模型，负载的 token 配比一变，成本排序就会翻过来。

可这次降价，把这个坑在 GPT-5.6 系列内部给填平了。把降价后三个档位的单价并排放：输入是 5、2、0.20，输出是 30、12、1.20。两个轴都恰好是 25 比 10 比 1。

Sol   : 输入 5    输出 30      -> 相对 Luna 25 倍
Terra : 输入 2    输出 12      -> 相对 Luna 10 倍
Luna  : 输入 0.20 输出 1.20    -> 基准

无论代入哪一组(输入 token, 输出 token)，总额比都固定在 25 : 10 : 1。
配比对档位选择不提供任何信息。

如果在系列内部配比改变不了排序，那么档位选择就必须由另一个轴来决定。这个轴是误答成本。用真实负载算一遍。

负载 — 100 万条商品描述的分类
  每次请求输入 4,000 token / 输出 300 token

  Luna  : (4,000 x 0.20 + 300 x 1.20) / 1e6 = 0.00116 美元/件 -> 1,160 美元
  Terra : 上面的 10 倍                                         -> 11,600 美元
  Sol   : 上面的 25 倍                                         -> 29,000 美元

  在这上面加上由人来改一条误答的成本 c(每件)。
  假设 Luna 误答率 4%、Terra 误答率 2%

  Luna  总成本 =  1,160 + 0.04 x 1e6 x c
  Terra 总成本 = 11,600 + 0.02 x 1e6 x c

  两式相等的点:
  10,440 = 0.02 x 1e6 x c   ->   c = 0.522 美元

读法是这样。改一条误答如果花不到 0.52 美元，Luna 更划算；如果超过，Terra 更划算。如果这是一件需要人工投入一分钟的活儿，人力成本早就远超 0.52 美元了。反过来，如果是误答直接重试就能解决的流水线，重试成本是 0.00116 美元，Luna 压倒性地划算。

这笔账给出的教训很简单。只有当误答成本与 token 成本处在同一个数量级时，token 单价 10 倍的差距才会体现为总成本的差距。在多数公司内部的工作流里，误答成本比 token 成本大上两三个数量级。在那样的负载上花几个小时比价目表，是在错误的轴上做优化。

缓存能挪动曲线的区间，和挪不动的区间

GPT-5.6 系列的缓存策略是读取 90% 折扣、写入按输入价的 1.25 倍、最短保持 30 分钟。以在 Terra 上使用一段 40,000 token 的固定前缀为例来算。

前缀 40,000 token，按 Terra 输入 2 美元/1M 计

  无缓存        : 40,000 x 2.00 / 1e6 = 0.080 美元(每次调用)
  缓存写入(1 次) : 40,000 x 2.50 / 1e6 = 0.100 美元
  缓存读取      : 40,000 x 0.20 / 1e6 = 0.008 美元

  N 次调用的盈亏平衡:
  0.100 + (N-1) x 0.008  <=  N x 0.080
  0.092 <= 0.072 N   ->   N >= 1.28   ->  从第二次调用起就赚

盈亏平衡点在第二次调用。真正的约束不是盈亏平衡点，而是那 30 分钟。同一段前缀如果 30 分钟内没有再来，你就只付了写入溢价、什么也没捞到。也就是说，决定缓存是否真正生效的不是折扣率，而是每个前缀的请求密度。在一个一万名用户各用不同前缀、每天各调用两次的服务里，缓存反而会增加成本。

另外再强调一次：折扣率不等于节省率。上面那个负载里，300 个输出 token 的成本是 0.0036 美元，所以输入占了总额的 95%。缓存完全命中的话，每件从 0.0836 美元降到 0.0116 美元，减少 86%。反过来，在输出偏重的负载(输入 2,000 / 输出 10,000)里，输入只占总额的 3%，同样的 90% 折扣连总额的 3% 都削不掉。同一条策略，随负载不同分裂成 86% 和 3%。这笔账的一般形式，LLM API 成本如何真正降下来一文里按各家供应商的价目表逐一追过。

Fast 模式 — 延迟被单独挂上了价目表

Fast 模式值得单独看，因为它标志着出现了一条与模型选择正交的轴。按 API 文档，在 service_tier 参数里填 fast(或为向后兼容保留的 priority)即可，当前适用对象是 gpt-5.6-sol。长上下文、微调过的模型、嵌入都被排除在外。文档说它「比标准最高快 2.5 倍，且延迟更稳定」，但没有写明倍率，把这部分交给价格页。按发布材料，溢价是标准价的 2 倍。

算起来很简单。这是一笔付 2 倍的钱买 2.5 倍速度的交易，所以只有当 1 秒延迟的价值大于该请求 token 成本的一半时才划算。用户守在屏幕前等待的交互式路径上，这一条大体成立；夜间批处理或者往队列里堆的流水线，则绝不成立。如果这个区分不在代码层面做，而是用项目级设置一刀切，那么批处理流量也会跟着付 2 倍的钱。请确认文档同时提供了按请求和按项目两种设置，并且把默认值留在标准档更安全。

「不改变智能」这句措辞也可以照单接受。只不过这句话保证的是模型权重相同，而不是高负载下尾部延迟会怎样。如果买这个选项是因为需要稳定的延迟，那就去测 p99，而不是平均值。

基准捕捉不到的东西

最后整理一下本文这些数字捕捉不到的东西。首先，排名换一个基准就翻盘这件事本身就是如此。看公开的汇总，SWE-Bench Pro 上 Sol 是 64.6%、Terra 是 63.4%，而 Claude Fable 5 以 80.0% 领先。反过来在 Terminal-Bench 2.1 上，Sol 以 88.8%(ultra 模式 91.9%)处于最高水平；在 Agents' Last Exam 上则据报告拿到 53.6，领先 Fable 5 达 13.1 分。三个基准给出三种排名。想从这里抽出「谁是第一」，这个尝试本身就是错误的问题。

而且还有一些项目，任何基准都不去测。

• 长会话中的指令遵守。多数基准是一次性任务，而真实服务是几十轮的会话。第 20 轮时会不会忘掉系统提示词里的约束，指数里并不包含。
• 工具调用 schema 的可靠度。把 schema 填错的比例决定了智能体流水线实际的失败率，但在汇总分数里只体现为成功或失败。
• 在我这个领域的拒答率与过度安全。在医疗、金融、安全领域，正常请求被拒绝的比例厂商不公开，基准也不去测。
• 尾部延迟与限流。平均响应速度到处都有，但流量高峰时的 p99 和 429 比例，只有自己去测才知道。
• 测量条件与实际设置之间的落差。上表里的指数分数全是在最高推理强度下测出来的。生产环境里用那个强度的流量并不多，而把强度调低之后的分数曲线并没有公开。

结语 — 曲线会一直往下走，但自己的位置只有自己去量才知道

过去三周里，GPT-5.6 下面两个档位的价格下降了 80% 和 20%，上面那个档位价格不动、只把速度拆出来单卖。价格曲线以后还会往下走，每一次都会有降价的新闻。但本文算出的三个数字，与降价无关地留了下来。

第一，降价后三个档位的单价比在两个轴上都锁定为 25 比 10 比 1，所以在系列内部，token 配比对档位选择不提供任何信息。第二，因此真正的决定由改一条误答的成本来定，在示例负载里这个盈亏平衡点约为每件 0.52 美元。第三，缓存在输入主导账单的负载上能削掉 86%，在输出偏重的负载上连 3% 都削不掉。

这三笔账，厂商都没法替你算。需要的输入是你自己日志里的三个数字 — 每次请求输入与输出 token 的中位数、每个前缀在 30 分钟内的复用率、处理一条误答的实际成本。下一次降价消息来的时候，该读的不是头条，而是把这三个数字重新代入后的那张表。