GPT-6.1 Ultrafast 对比 GPT-6.1 Sol：三项任务，各有定论

问一问GPT-6.1 Ultrafast是否值GPT-6.1 Sol六倍的价格，诚实的答案是：你的三类工作负载中有两类应该原地不动。交互式编码智能体应该迁移过去。隔夜评测扫描不该迁移，批量摘要器也不该，而原因并不是这一档定价过高——而是它们从来买的就不是它所卖的东西。GPT-6.1 Sol 于 2026 年 9 月 29 日发布，Ultrafast 于 2026 年 10 月 8 日作为其上的一个模式推出：相同的检查点、相同的 1,050,000 token 上下文窗口、相同的 128,000 token 输出上限、相同的 2026 年 4 月 30 日知识截止日期、相同的答案，价格为每百万输入 token 12.00 美元、每百万输出 token 60.00 美元，而后者为 2.00 美元和 10.00 美元。速度档位购买的是一份墙钟时间，而只有当某项工作有人正等着要结果时，墙钟时间才值钱。

重新定义框架就是整篇文章的核心。其余部分则是算术，告诉你哪些工作属于等待型，以及无论你是否为之做好规划，都会随倍数一同到来的两项成本。

真正不同的是：一个请求字段和一张账单

没有 Ultrafast 检查点，没有单独的上下文限制，没有替代的知识截止日期，也没有什么可以固定。你发送的是同一个模型标识符，只是设置了一个 service-tier 字段，OpenAI 便会以不同的方式调度该请求；不带该字段发送，你就处于 Standard 层级。开发者据以编写代码的一切都是完全相同的，而在这份清单上不妨保持机械式的列举，因为清单的长度本身就是论据。

• 模型 ID — 两者使用相同的标识符，只有一个默认快照，没有任何带日期的版本可供锁定。

• 上下文——1,050,000 token 的窗口，最大输入 922,000 token，两者最大输出均为 128,000 token。

• 推理档位——低、中（默认）、高、xhigh 和 max，两者均支持；none 和 minimal 两者均不支持。

• 工具面 — 网络搜索、文件搜索、图像生成、代码解释器、托管 shell、应用补丁、技能、计算机使用、MCP 和工具搜索，通过 Responses API 提供，在两者上均可。

• 价格 — Standard 上每百万 token 为 $2.00 输入 / $0.10 缓存 / $2.50 缓存写入 / $10.00 输出，而 Ultrafast 上为 $12.00 / $0.60 / $15.00 / $60.00。

• 超过 272,000 个输入 token 时——整个请求将按 2 倍输入和缓存费率、1.5 倍输出费率重新计价，输入和输出均如此，这使得 Ultrafast 长上下文的价格为 $24.00 / $1.20 / $30.00 / $90.00。

• 速度 — 按定义，Standard 就是基准；Ultrafast 是最高一档，而 O​penAI 唯一公布的、针对特定模型的倍数属于 G​PT-6 Astra，而非本模型。

最后那一行是贯穿其余所有内容的警示，它在下面还有自己单独的一节。首先，说说那些工作。

首要任务：交互式代理。这就是推动一切的那一个。

一个连续发起四十次工具调用的智能体循环，正是这一档位所为之打造的目标买家，因为每一轮的生成时间都会制约下一轮，而用户一直在盯着看。以一个会话为例：在 40 轮中，每轮发送 30,000 个输入 token 并接收 1,500 个输出 token——总计 1,200,000 个输入 token 和 60,000 个输出 token，且每一次请求都远低于 272,000 token 的重新定价阈值。

• Standard — 120 万输入 token 按 2.00 美元计算是 2.40 美元；6 万输出 token 按 10.00 美元计算是 0.60 美元。本次运行三美元。

• Ultrafast — 120 万输入 token，按 $12.00 计算为 $14.40；60,000 输出 token，按 $60.00 计算为 $3.60。这次运行花费十八美元。

• 差价 —— $15.00，即可从一项在其他方面输出完全相同的任务中消除大部分生成延迟。

15.00 美元是否便宜，是一个关于分钟、而不是 token 的问题。如果这个会话在 Standard 上要花二十分钟，在 Ultrafast 上要花四分钟，那么你就是用十五美元买到了十六分钟——大约每分钟 0.94 美元——而真正重要的比较，是这十六分钟让你付出了什么代价。按全成本费率计算，一名开发者的价值超过每分钟一美元，所以在需要人类参与的情形下，答案毫无悬念。而一个等待人工审核队列的智能体，每分钟的价值为零；在那里，同样的十六分钟就是免费的十六分钟，这个档位纯属浪费。

这就是要套用的检验标准，它与模型本身毫无关系。生成时间占用的是谁的时钟，那个时钟又值多少？如果答案是"某个人的，而且非常值钱"，那么 Ultrafast 就是你账单上最便宜的东西。如果答案是"某个调度器的，而且一文不值"，那它就是最昂贵的。

第二项任务：夜间评估扫描。这是一个不

一次评估扫描会让模型跑几千条提示，把结果写入对象存储，然后第二天早上由人来读表格。它的延迟预算不是几分钟，而是一整夜。整条流水线里除了队列中的下一个请求，没有任何东西在等模型。

Ultrafast 并不会消除扫描的实际耗时，因为扫描的实际耗时是你自己做出的调度决策，而不是你所面临的延迟问题。它真正做的，是把账单乘以六，并把任务挪到一个自带按组织速率限制的预算上——这在无人值守的批处理中是一个真实的风险，因为速率限制上限恰恰就是大规模扫描会撞上的失败模式，而层级页面并不公布这个数字。

而同一张费率卡上还有一条通道，它的定价正适合这类任务，且定价方向恰好相反。Batch 和 Flex 的价格是 Standard 的一半，而 API 的 Batch 处理正是为这种形态设计的：大批量、没有交互式截止时间、结果异步返回。按上面的数字，同样的 40 轮 token 总量在 Batch 上花费 1.50 美元，而在 Ultrafast 上要 18.00 美元。对于一项根本分辨不出差别的任务来说，这是 12 倍的价差。

要避免的错误，是把 Ultrafast 当作通用升级选项。它是阶梯的顶端——Batch 和 Flex 为一半，Standard 为一，Fast 为二，Ultrafast 为六——而阶梯并不是一份“更好版本”的菜单。选错梯级，比选错模型更费钱。

第三项：批处理摘要器。同样不行，但原因不同。

假设工作负载是对文档存储进行夜间批处理：输入长、输出短、无人工介入，且 SLA 以小时计。在这种情况下，token 配比反而不利于 Ultrafast，而非对其有利。

272,000 token 的门槛就是原因所在。无论哪个档位，只要单个请求越过这条线，整个请求都会被重新计价——每一个输入 token、每一次缓存读取、每一个输出 token——输入和缓存价格翻倍，输出价格则为 1.5 倍。因此，长上下文 Ultrafast 的价格为每百万输入 token 24.00 美元、每百万输出 token 90.00 美元，而触发重新计价的是整个请求，而非超出这条线的部分。一个偶尔以 300,000 输入 token 发送请求的文档摘要工具，需要为全部 300,000 个 token 支付长上下文价格。

缓存行为会进一步放大这种效应。在这个模型上，缓存读取是成本最低的 token，也是最有效的成本杠杆，而且它们是随层级成比例放大，而不是被层级吸收——标准版每百万缓存输入 $0.10，超快版 $0.60，两者均为未缓存输入费率的 5%。无论缓存 token 与新鲜 token 如何搭配，都无法削弱这一倍数关系，因此，一个经过高度优化的缓存流水线并不能从快速通道中获得折扣。它只是为一个小得多的数字支付六倍的费用。

把两者放在一起看，摘要器正是 Ultrafast 的溢价按绝对值算最大、而收益最小的情形。如果文档确实很长，截止时间也确实是以小时计，那么正确的配置是 Batch 或标准的 Standard，而 Ultrafast 的正确用法是开发中期的循环：你正在反复迭代提示词，且每改一版都有人在等。

随倍数而来的两项成本

六倍费率只是价格中可见的部分。在生产中，两个不可见的部分更为关键。

第一个是速率限制预算。Ultrafast 运行在其自身的限制之下，与 Standard 和 Fast 的预算相互独立，而 OpenAI 是按组织设定这些限制的，并不会在层级页面上公布；建议是在提高流量之前先查看你所在组织的限制，若需要提升则联系客户团队。因此，把工作负载切换到 Ultrafast 会同时带来两件事：账单成倍增加，同时工作负载被移到一个你可能无法查看的上限之下。对于无人值守的智能体来说，先触碰到的是这个上限。

第二是节省的形态。Ultrafast 缩短的是令牌间时间，而不是首个令牌时间，也不是深思阶段。一个请求如果在其输出任何内容之前的大部分挂钟时间都花在思考上，那么即便切换到 Ultrafast，仍然会感觉很慢，因为该层级加速的是从来都不是瓶颈的那一部分。正是这种失败模式产生了“我们付了六倍的钱，速度却一样”的报告：它测量的是一个延迟存在于该层级触及不到之处的应用。在做出承诺之前，先测量秒数实际花在哪里——首个令牌时间与令牌间时间——因为该层级只拥有其中之一。

为什么“更快”还不是一个你目前能要求 OpenAI 兑现的数字

Ultrafast 以“最高 8 倍”作为卖点，而这一说法背后的测量数据属于另一个模型。已发布的句子说的是：在 Codex 中，G​PT-6 Astra Ultrafast 生成 token 的速度最高可达 Standard 模式下 G​PT-6 Astra 的 8 倍。对于 GPT-6.1 Sol，并没有已发布的等效倍数；也没有任何独立方发布过 Sol 变体的每秒 token 数。该档位的文档将其描述为缩短生成输出 token 之间的时间，并指向一份费率卡。

把这一倍数当作成立是一个合理的先验——两个模型都跑在同一套服务栈上，而且该档位的机制也相同——但"最高可达"这句话里的"最高"是在实打实地起限定作用，而在不同客户端上、针对姊妹模型测出的厂商上限，并不是你的工作负载将会看到的数字。更早的那一档同样如此：Ultrafast 相对于 GPT-5.6 Sol 于 2026 年 8 月以"最高比 Standard 处理快 14 倍"的说法在有限预览中发布，而文档至今仍写着预览访问，且 Ultrafast 费率表恰好只有两行。

你能要求 OpenAI 兑现的是价格，因为价格是公开的，并且对每一个 token 都适用。这意味着本页所讨论的决策，是关于你自己的延迟预算的决策，而不是关于供应商的速度宣称。

在不提交的情况下测试它，然后切换回来

这一层级对所有 API 用户都可用，因此要回答实际耗时问题，成本最低的方法就是在开启和关闭该字段的情况下，将同一组提示词运行两次，并比较 token 数量和耗时。测试中有两点需要注意：你的请求是否会越过 272,000 token 这条线，以及首 token 时间是否会主导 token 间时间。只要出现其中任何一种情况，即便该层级完全按宣传所述正常工作，试验也可能看起来毫无效果。

切回只是一个请求字段，而不是一次迁移；标准通道经由 OrcaRouter，按供应商自己的标价提供服务，即 openai/gpt-6.1-sol —— 每百万输入 token 2.00 美元、每百万输出 token 10.00 美元，0% 加价，供应商的价格原样透传，因此供应商一旦调价，我们这边当天就会生效。Ultrafast 本身并不是我们售卖的东西；它是计费在你自己的 O​penAI 账户上的一项服务层级标记，如实说明比暗示相反的情况更有用。单个密钥真正能买到的，是标准通道，加上同一个兼容 O​penAI 的端点背后的其余目录，以及 跨供应商的自动故障转移——如果你即将把一个昂贵的层级放在生产级智能体前面，并且希望标准通道是一个路由决策而非代码改动，那这一点就值得拥有。

关于快速通道有一点实用说明，不适用于便宜的那一档：WebSockets。O​penAI 建议 Ultrafast 使用持久 WebSocket 连接，这对于需要大量顺序调用的智能体是合适的形态，而对于每个请求一个进程的批处理脚本则不合适。如果你的客户端属于后者，那么该档位自身推荐的传输方式，也就成了夜间任务该放到别处运行的又一个理由。

当裁决改变时

三项进展能让作业从“保留”清单上移走。GPT-6.1 Sol 若公布 Ultrafast 速率限制，就能消除批处理场景中的上限风险。Sol 层级若有公开或可独立复现的速度测量结果，你就能把挂钟时间的节省纳入预算，而不是凭空假设。而快车道上的一个折扣档位——相当于 Batch 的 Ultrafast 版本，该层级依然快速，但价格不是六倍——将改变阶梯中段每一个作业的经济账。

今天这些都不存在。存在的是一个完全名副其实的档位：同一个 GPT-6.1 Sol，只是调度方式不同，而每条线路的价格都是六倍。把交互式 agent 移走，另外两个别动，并先测量你的秒数实际上都花在了哪里，再决定哪一个才是你该选的。