GPT-5.6 Sol Ultrafast 对比 GPT-5.6 Sol：相同的权重，不同的服务层级

GPT-5.6 Sol Ultrafast 并不是一个新模型，这也不是一篇发布报道。厂商于 2026 年 8 月 13 日宣布了这一模式，而同一天，ultrafast 这个取值就出现在了该公司公开的 OpenAPI schema 中，位于规范里 ServiceTierResponses 的说明之中——按其自身措辞，该说明把这一层级限定在 gpt-5.6-sol 端点，并标注为受访问控制。真正让这篇文章重新回到我们待办队列的，是一个更小也更具体的细节：2026 年 9 月 25 日，提交 fe4f7a1 将该取值扩展到了另外两个枚举中，即请求级的 service-tier 参数和 agent 的 service-tier 策略字段。宣布六周之后，该层级仍在等待名单上，仍未公布价格，而如今它接入的 API 面已经超出了它实际能够服务的范围。GPT-5.6 Sol Ultrafast 和 GPT-5.6 Sol 是同一个模型；这场比较唯一能定的是：谁掌控着那个指针，以及谁把成本告诉了你。

所以标题里的这场对决非同寻常。GPT-5.6 Sol Ultrafast 和 GPT-5.6 Sol 是同一个模型。相同的权重、相同的检查点、相同的推理行为、相同的 105 万 token 上下文窗口、相同的 128K 最大输出、相同的答案。OpenAI 自己的说法是“每秒完成更有用的工作”，而不是模型更聪明。在这场比较的两列之间，唯一不同的是 token 的生成方式，以及你的请求体中所称的档位——这使其成为当前阵容中最干净的控制实验，同时也是最难选购的一个，因为这两个档位中有一个根本没有公布价格。

这周究竟发生了什么变化

9 月变更的证据是一次提交，而不是一篇博客文章。OpenAI 维护着 openai-openapi，这个仓库发布其 API 的机器可读 schema；而日期为 2026-09-25 的提交 fe4f7a1 将 ultrafast 添加到两个枚举中：附加到智能体的服务层级策略，以及规范描述为“用于模型请求的服务层级”的请求级字段。这是一次扩展，而非首次亮相：在此提交之前，这两个列表列出的是 auto、default、flex、priority、fast，而该层级自 8 月 13 日起就已经存在于 schema 中。这个提交值得注意，是因为它触及的字段——配置智能体时所用的策略字段——与按请求覆盖属于不同的接口面。

真正重要的描述来自8月13日的那次提交，而非这一次；这是OpenAI在任何地方就该层级所发布过的最具体的说明。除了这个新值之外，规范中还写道："If set to 'ultrafast', then the request will be processed with the access-controlled Ultrafast Processing service tier. This tier is currently available for gpt-5.6-sol; a response served through it will show service_tier=ultrafast."

把这句话读两遍，因为它一举厘清了本对比页面原本不得不含糊其辞的两个问题。该层级仅限定于一个模型——GPT-5.6 Sol 旗舰版，产品线中别无其他——而且它受访问控制，而非开放使用，这与 OpenAI 对候补名单预览的定位一致。它还告诉你如何判断自己是否用上了它：响应会回传实际处理该请求的是哪个层级，因此回退到标准处理在响应正文中就能看到，而不必从延迟去推断。同样的描述同时出现在标准版和 Beta Responses 两套 schema 中，且自 8 月 13 日起便是如此。

第二天，又传来了一个更弱的信号。9 月 26 日的报道描述了一个新的 Speed 选择器——Fast、Standard 和 Ultrafast——即将登陆 Responses API Playground，并预计在 OpenAI 的 DevDay 开发者大会之后，Ultrafast 会获得更广泛的可用性。我们并未亲自见到该选择器，OpenAI 也未发布任何上线说明，因此应将其视为单一来源的报道，而非已经发布的功能。如今可核实之处，是公开 schema 中的两处位置，以及该档位尚无价格表这一事实。

什么没有改变，这一点同样重要。目前依然没有 Ultrafast 的价格。9 月 27 日查看的 OpenAI 定价页面上，仍是此前的四个标签页——Standard、Batch、Flex 和 Fast——而“ultrafast”这个字符串在任何地方都没有出现。访问权限仍被描述为面向部分客户的有限预览，并会随着容量增长而逐步扩大。这一层级同时存在于合同之中、又不在价目表之上，而这就是它真实的状态。

两个层级，并排对比

由于没有任何能力能将这两者区分开来，比较几乎完全落到了服务与计费上。下面的每一行都在同一行中同时呈现双方。

• 模型 — 相较于 GPT-5.6 Sol 标准处理，GPT-5.6 Sol Ultrafast 所运行的是完全相同的 GPT-5.6 Sol 检查点；同一检查点，无蒸馏，无规模缩减。

• 输出吞吐量——每秒最高 750 个输出 token，最高可达标准版的 14 倍；根据 OpenAI 8 月 13 日的公告，对比对象是在 GPU 集群上运行的标准 GPT-5.6 Sol 处理，14 倍这一数字正是以此为基准测得的。

• 硬件——Cerebras 晶圆级芯片，权重常驻片上 SRAM：这是 OpenAI 于 2026 年 1 月与 Cerebras 建立的算力合作（据报道三年价值约 100 亿美元）所推出的首个产品；相比之下，传统 GPU 推理的大部分时间都耗费在内存与计算单元之间搬运权重上。

• 价格 — 截至 2026 年 9 月 27 日尚未公布，而每百万 token 输入 $4.00 / 输出 $20.00 为 OpenAI 当前的促销价，另加每百万缓存输入 $0.40。

• 可用性 —— 面向特定客户的候补名单式受限预览，而默认通道则任何持有 API 密钥的人均可调用。

• 你收到的回答——原则上相同 vs 原则上相同；若它们对同一个提示词产生分歧，那是一项发现，而非一项特性。

关于速度的宣称，以及对其设定的上限

头条数字是 14×，它理应得到与本页其余内容同样的审慎对待。OpenAI 称，相较于标准处理，每秒最多可生成 750 个输出 token——这是一个关于 输出 token 的吞吐量数字，而非声称每个请求都会快 14 倍完成。端到端时间还包括输入处理和模型自身的推理，晶圆级硬件并不会以相同比例压缩这两者。正因如此，该公司将 14× 标为最大值，而不是实测值。

已发布的对比数据来自表格两端的厂商自报，其中一项还跨越了两家厂商的技术栈。一次包含 2,500 道题的 Humanity's Last Exam 运行据称在 Ultrafast 上于 11 小时 11 分钟内完成，而 Claude Fable 5 用了 78 小时 27 分钟，准确率相当——这是 OpenAI 和 Cerebras 在向我们说明一个包含竞争对手模型的基准测试，而关于此次发布的独立报道援引了同一运行中更窄的、约 11× 的生成速度对比，同时 Cerebras 自己的数据则意味着总测试时间约为 7×。14×、11× 和 7× 之间的差距并不矛盾；当三方测量的是同一工作负载的不同部分时，就会出现这种情况。Cerebras 另行报告在 GDP-Val 上端到端达到 5.6×，且无可测量的质量损失。这一切都尚未被第三方复现。

这份价格表有个漏洞。

正是在这里，两个层级不再对称。GPT-5.6 Sol 有四档已公布的费率，而 Ultrafast 并不在其中。

• 标准 GPT-5.6 Sol — 每百万 tokens {{1}}输入 $4.00 / 输出 $20.00{{/1}}，缓存输入为 $0.40，当输入超过约 272K tokens 后，{{2}}长上下文档位为 $8.00 / $30.00{{/2}}。

• 快速模式 — $8.00 / $40.00，恰好是标准费率的两倍。该档位于 2026 年 7 月 30 日从 Priority processing 更名而来，API 接受 service_tier: "priority" 或 service_tier: "fast"。它最高可将输出速度提升至约 2.5 倍。

• 批量与灵活——$2.00 / $10.00，相较标准价格直降50%，代价是更宽松的日程安排。

• Ultrafast — 没有资费表。不是我们凭猜测填上的空白，而是 OpenAI 留下的空白。

Fast-mode 那一行是任何人给 Ultrafast 定价时唯一真正能参照的先例，而对任何做预算的人来说，这一先例都令人清醒：OpenAI 唯一真正给出数字的速度档位，价格恰好是标准费率的两倍，换来的是两倍半的速度。Ultrafast 是一个更大的速度承诺，依托的是更稀缺的硬件——Cerebras 的晶圆产能并非大宗商品——因此最终溢价的方向毋庸置疑。有疑问的是幅度。在价目表出现之前，你在任何地方看到的任何“GPT-5.6 Sol Ultrafast 价格”数字都是某人的推断，包括我们的任何推断。

你实际会怎么称呼它

schema 变更告诉了你最终调用的形态。如果这个层级沿用其他层级的模式，它就会作为额外字段出现在你已经在发出的请求里：你仍然保留 model gpt-5.6-sol，保留你的提示词，只需加上层级选择器——就像今天选择 Fast 模式那样，把 priority 换成 fast。你的响应解析不会有任何变化，因为模型本身没有任何变化。这正是服务层级相较替换模型的全部吸引力所在，也是像这样一个对比页面几乎无可对比的原因。

你今天无法做的是调用它。枚举值是存在的；但对大多数账户而言，它背后的容量并不存在。因此，未来几周的实际问题不是在这两个层级中选哪一个——而是在该选择不可用期间运行什么。

这个问题，网关比等待名单更能给出答案。该模型的标准层级现已在 OrcaRouter 上线，标识为 openai/gpt-5.6-sol，按提供商自身的费率提供服务，对 token 零加价，通过 api.orcarouter.ai/v1 的 OpenAI 兼容端点访问——因此 OpenAI 的促销价 $4 / $20 以及其长上下文档位的 $8 / $30 会原样直通，而不是由我们重新定价；这些价格一旦变动，OpenAI 那边生效的同一天，我们这边也会生效。同一个密钥可调用 200+ 个模型，这一点在这里比平时更重要：因为你无法通过设置 service_tier: "ultrafast" 就得到答案，如今购买低延迟的方式是把工作分流到不同路径——把交互式调用发给目录中能最快达到你质量门槛的模型，把夜间批处理留在能通过的最便宜通道上。等该层级真正开放时，路由器就是你会拨动开关的地方；在那之前，它就是等待名单与可行方案之间的区别。

哪一个属于生产环境？

先别管“versus”这个词，因为这里根本不存在质量上的取舍。如果你优化的是每 token 成本，那么标准版 GPT-5.6 Sol 就是答案；而任何可以等待的任务，答案就是打五折的 Batch 通道。如果你优化的是一个人要盯着加载转圈图标等多久，那么只要能拿到 Ultrafast，它就是答案——而 OpenAI 为这次预览点名的那些工作负载，恰恰说明了原因：在线上故障中一边开着日志和 diff 做事故响应、针对不断变化的数据做欺诈检测、半秒沉默就会被当成产品坏了的客服对话，以及过去要跑一整夜、如今被压缩进一个工作时段的研究循环。

关键线索在于请求图的形状，而不是提示词的大小。单次长生成在纸面上能获得 14× 的提升，但在实践中要小得多，因为输入处理和推理并不会按这个比例压缩。一个用户可见操作背后有四十次顺序工具调用，所获得的提升会接近完整倍数，因为每一次往返都是用户正在等待的延迟。如果你的工作负载像第二种，这个档位就是为你准备的；如果像第一种，标准通道本来也完全够用。

有两件事需要留意，而这两件都不是我们在这里就能定论的传闻。第一，价目表：没有标价的高级档位无法编入预算，而 Fast 模式的前例表明它不会便宜。第二，候补名单是否真如报道所说，在 DevDay 前后放宽限制——因为一个大多数账户都无法使用的 service_tier 值只是文档，而非可用性，而这两者的差别，就是计划与承诺之间的差别。