返回博客首页
开发者最容易被“最高 8 倍快”吸引，却忽略了这是 token 生成速度上限，不是修完一个 bug、跑完测试的时间保证。GPT-6.1 Sol 新增 Ultrafast 后，API 从 $2/$10 到 $12/$60 有三档可选。本文用价格表、同任务算式和试运行清单，帮你判断哪些请求值得加速。
GPT-6.1 Sol Ultrafast 到底更新了什么
OpenAI 10 月 8 日的发布说明确认：GPT-6.1 Sol 增加 Ultrafast 速度档，已用于 API、Codex 和 ChatGPT Work。它不是一个新模型 ID；在 API 中仍调用 gpt-6.1-sol，通过 service_tier: "ultrafast" 指定处理档位。原本的 Standard 和 Fast 仍可选。API 面向所有符合条件的用户开放，但 Codex/Work 的订阅入口有单独的套餐门槛。
发布画面只说明新档位上线；可用范围、价格与速度口径还需分开核对。
这次不是“换一个更聪明的模型”，而是为同一模型购买更快的输出服务。代码质量、推理强度和工具权限不能从速度档位推导出来。你付的钱买的是延迟预算：如果线上故障处理、实时交互或高频 Agent 循环因为等待模型而卡住，可能值；若主要时间花在跑测试、装依赖和人工审阅，收益会被稀释。
发布会现场对 Ultrafast 的演示很直观，不过演示视频的画面速度不等于你自己的任务完成时间。后面会给出可复算的测量方法。
现场演示帮助理解产品定位；生产决策仍要用自己的任务计时。
先把“8 倍快”翻译成可测量的时间
OpenAI 的 DevDay 总结给出的口径是：Ultrafast 在 Codex 中最高可达约 8 倍的 token 生成速度，API 中最高可达约 6 倍，并非所有任务的端到端时间分别缩短 8 倍和 6 倍。标称“最高”也不是每一次调用的保底结果。即便模型输出更快，排队、网络、预填充、工具调用、浏览器加载、执行测试与人工验收的时间不会自动同比减少。
一个简单演算：假设某任务花 100 秒，其中模型生成文字占 40 秒，其余 60 秒是工具与测试。即使文字生成快 6 倍，这个任务也只是从 100 秒降到约 66.7 秒，端到端约快 1.5 倍。如果模型生成只占 10 秒，其他 90 秒不变，6 倍生成速度只能让总时长降到约 91.7 秒。要不要买极速，先看自己的耗时分布。
下面的图是一位开发者公开的单次场景、四轮取中位数测试：图中报告约 304 tok/s 对 42 tok/s，以及 4.3 秒对 17 秒。它可作为“如何同时记录生成速度与总响应时间”的样例，不是官方保证，也不是跨任务基准。
独立用户样例同时呈现 token 生成速率、首字时间和总响应时间；真实 Agent 还要计入工具与测试。
建议至少记四个时间点：请求发出、首个可见输出、模型输出结束、任务真正通过验收。用相同输入、相同 reasoning.effort、相同工具和缓存状态比较三档，并记录 p50 与 p95。只拿一次“最惊艳”的视频片段做结论，很容易买错档位。
三档 API 价格：输入与输出都要一起算
OpenAI 官方价目表在短上下文档给出以下价格，单位为每 100 万 token 的美元价格。Fast 是 Standard 的 2 倍，Ultrafast 是 Standard 的 6 倍。更高价格对应服务速度档，不等同于多 6 倍额度或提高 6 倍任务成功率。
| GPT-6.1 Sol 档位 | 输入 | 缓存输入 | 输出 | 相对 Standard |
|---|---|---|---|---|
| Standard | $2.00 | $0.10 | $10.00 | 1× |
| Fast | $4.00 | $0.20 | $20.00 | 2× |
| Ultrafast | $12.00 | $0.60 | $60.00 | 6× |
价格表适合做第一轮筛选；实际账单还要计入缓存写入、工具费用、长上下文和地区处理加价。
假设一次请求含 2 万个非缓存输入 token、5 千个输出 token，不含工具与其他费用：Standard 为 0.02×$2 + 0.005×$10 = $0.09；Fast 为 $0.18；Ultrafast 为 $0.54。相同 token 结构下，Astra Standard 的纯输入输出成本为 $0.45，因此 Sol Ultrafast 甚至可能比 Astra Standard 贵。Astra 是否更适合，仍须看任务通过率与延迟，不能只按“Sol 比 Astra 小”来猜价格。
有开发者把单个 Three.js 任务的实际 Standard 账单与按 Ultrafast 单价重算的结果并排展示，后者约为前者 6 倍；这反映的是同一 token 用量的计价差异，不是他已经证明了极速模式能在相同质量下把任务做完。
单任务截图能说明“同样 token 乘以新单价会发生什么”，不能代表平均成本。
另一张对照把 Sol Standard、按 Ultrafast 估算的价格和 Astra Standard 放在一起。它提醒我们：与哪个模型、哪个速度档相比，结论可能相反；不要把“Astra Ultrafast 的五分之一价格”误读成“比所有 Astra 方案便宜”。
对照图为个人任务记录与估算；正式选型请以相同输入集和官方价目表复算。
多花的钱要换回多少等待时间
以上面 2 万输入、5 千输出的请求为例，Ultrafast 比 Standard 每次多 $0.45。假设一件工作需要连续调用五次，且每次 token 用量相同，速度溢价就是 $2.25。如果工程师实际被这五次调用阻塞，内部估算的时间成本按每小时 $60 计算，至少要节省 2 分 15 秒的有效等待，账面上才抵得过这笔溢价。若只是后台任务提前完成、工程师本来就在做别的事，就不能把缩短的墙上时间全算成人工收益。这是决策演算，不是官方测速或人力报价。
再看两种相反情形。同样五次调用，若模型生成占关键路径、总验收时间缩短三分钟，按上述假设可节约约 $3 时间成本，超过 $2.25 溢价；若只是首字更快，测试与人工确认不变，最终只早 20 秒，溢价就没有从人工等待中收回。记录表里因此要同时有增量 API 费、阻塞等待时间、合格交付时间，不能只放 tokens/s。
长上下文和缓存会怎样改变账单
模型说明指出，单次提示词超过 272K 输入 token 时，GPT-6.1 Sol 的输入与缓存费率按长上下文档计价，输出费率也上调，且作用于整次请求。Ultrafast 的长上下文标价是输入 $24/百万、输出 $90/百万。例如 30 万非缓存输入加 2 万输出，纯 token 费约为 0.3×24 + 0.02×90 = $9.00；这不是前面短上下文档的 $0.54 样例能外推的结果。
如果大量上下文命中缓存，输入价不能全部按非缓存输入计算。反过来，缓存写入、重复重试、工具调用、地区数据驻留附加费也可能抬高成本。官方价格页注明相关地区处理可能另加 10%；采购前应在自己的组织账单和价目表再次核对。以上算式只是选档示例，不是报价承诺。
API 与订阅版，开放范围不是一回事
API 文档写明：GPT-6.1 Sol 的 Ultrafast 面向 API 用户开放，拥有独立于 Standard/Fast 的速率限制；支持全球处理以及符合条件的美国、欧盟数据驻留。API 账单按 API 价格走，不因为你有 ChatGPT 订阅就免费。
在 Codex 和 ChatGPT Work 中，官方上线说明列出的入口是 Pro 500、符合条件的按量付费 Enterprise，以及按点数计费的 Edu；Enterprise 还需要管理员启用。普通 Chat 标签页不包含 GPT-6.1 Sol，不能把“ChatGPT 中有 GPT-6”理解成“人人都能用 Sol Ultrafast”。具体额度与扣费界面以账号和工作区设置为准；原文提到的某些额度倍率来自其他套餐或早期展示，不应无条件套到每个 Sol 账户。
Pro 500 演示说明订阅入口有门槛；API 的可用资格和计费是另一条线。
有用户公开了短时间消耗大量周额度的体验。它提示试用前先看剩余额度，却不能推出固定的“每分钟消耗百分比”：模型、推理档、上下文长度和任务路径都不同。
个人用量报告不是通用费率表；真正的用量以自己账户的 Usage 页面为准。
API 怎么试，才能比较得公平
一次性请求可以先用 Responses API 的 HTTP 形式做基线。下面的 Python 示例只演示参数形态；需要你自己的 API Key 与已安装的 OpenAI SDK，不会自动运行。把 service_tier 依次改为 default、fast、ultrafast，其余参数和输入样本固定；返回的实际 service_tier 与 usage 应记录下来。若你的项目对默认路由有自定义设置，先确认 default 实际落在哪个服务档。
from time import perf_counter
from openai import OpenAI
client = OpenAI() # 从环境变量 OPENAI_API_KEY 读取密钥
started = perf_counter()
response = client.responses.create(
model="gpt-6.1-sol",
service_tier="ultrafast",
reasoning={"effort": "medium"},
input="请说明 Python 表单校验中空值应如何处理，并列出两个可复现的测试。",
)
print(response.output_text)
print({
"elapsed_seconds": round(perf_counter() - started, 2),
"actual_tier": response.service_tier,
"usage": response.usage,
})
这个非流式示例只测完整响应耗时，不能测首字时间；要比较首字时间，请启用流式响应并记录第一条内容事件的时间戳。
如果 Agent 一轮里要频繁调用工具，官方推荐复用 WebSocket 长连接。每次都重新建立网络连接，会吃掉一部分推理速度收益。官方文档同时给了 HTTP 备选，因此“必须用 WebSocket 才能调用”也不准确。先用 HTTP 验证功能，再用相同任务测长连接能否改善总耗时；不要只看首字速度。
记录表可以很朴素：task_id、tier、reasoning_effort、input_tokens、cached_input_tokens、output_tokens、time_to_first_token、model_duration、tool_duration、end_to_end_duration、accepted、rework_minutes、cost_usd。每档至少跑同一批典型任务，多轮取中位数，并看 p95 是否更稳定。工具超时、速率限制和失败重试也要计入；极速模式有独立限制，业务高峰时尤其要核对配额。
把试运行写成一张可决策的记录表
每个 task_id 在三档各跑同一个验收脚本，失败也保留记录。比如“修复日期输入在空值时崩溃”这个任务，验收条件不是模型说“已修复”，而是指定测试通过、旧表单提交不回归、评审者接受 diff。先在任务级随机交错档位，避免把午间拥塞误认作某一档固有速度；缓存热度、并发数和重试策略也要尽量一致。若无法控制，就在记录中单列，别把它们藏进平均值。
| 任务 ID | 档位 | 首字 / 完整响应 | 工具与测试 | 验收通过时间 | 费用与返工 | 结论 |
|---|---|---|---|---|---|---|
bug-017 |
Standard / Fast / Ultrafast 各一行 | 实测秒数 | 实测秒数 | 实测秒数 | 实际美元 / 分钟 | 达标、失败或重试 |
汇总时按任务类型分别看合格率、p50/p95 和每件合格任务总成本。只对“加速后确实缩短关键路径、且增量成本在预算内”的类别开 Ultrafast；一旦该档限流或没有带来改善，回退到事先验证过的档位。不要把整站流量一次性切过去。
“即时转向”是另一项更新，不是 Ultrafast 的专属能力
ChatGPT 更新日志同时提到 Codex 桌面端正在推出更快的 steering：任务运行时发后续消息，可更快纠正方向。用户可以在 Settings → General → Follow-up behavior 选择消息默认是参与当前运行还是排队到下一轮；Codex 帮助文档也区分了 Steer 和 Queue。这和购买 Ultrafast 速度档不是同一个开关。
转向能力解决的是“中途改要求”的协作问题；是否用 Sol Ultrafast 是另一个选择。
演示里，任务先收到“生成一只猫”的要求，随后用户改成狗，接着又改成三只鸭子。下方两帧分别是中途纠正与最终结果。演示界面显示的模型是 GPT-6 Astra；这些画面不能用来证明 Sol Ultrafast 在同一操作中的耗时或成功率。
第一帧：用户在进行中的任务里加入新的目标。
第二帧：任务朝新目标完成；画面中的 Astra 型号与 Sol 极速档不能混为一谈。
转向适合修正错误前提、补充文件、缩小范围；如果前一步已经修改了代码或外部状态，新的消息并不会自动撤销那些动作。验收时要检查实际文件、测试结果和回退点，而不只看模型是否迅速改口。
什么时候该买 Ultrafast
| 任务 | 推荐起点 | 判断依据 |
|---|---|---|
| 批量摘要、夜间整理、可排队报告 | Standard；能等待时另评估更低价的处理方式 | 用户不在等，速度溢价难回收。 |
| 交互式代码审查、短时人工协作 | Fast 与 Ultrafast 各跑同一批样本 | 看端到端等待和人工返工是否下降。 |
| 线上故障、实时操作、多轮工具调用 | 先试 Ultrafast，保留回退 | 若等待模型占关键路径，速度可能有价值。 |
| 长上下文反复读取、大量缓存命中 | 先重算缓存与长上下文账单 | token 构成可能比速度档影响更大。 |
建议把购买决策写成一个可复算的式子：每件合格任务总成本 = API 费用 + 重试费用 + 人工返工时间成本。再加一条时间指标：从发起到验收通过的 p50/p95。若极速档只让界面更早滚字，却不改变合格交付时间，价格差就难解释；若它把关键路径上的等待减少到足以让工程师少空等、故障更快恢复，再贵也可能有价值。
Code0 团队可以怎样把测速变成路由规则
把任务分成“人工正在等待的短任务”“多轮工具任务”“可离线排队任务”三组。对每组设置一个可接受等待时间，再测各档位的合格交付率。例如代码修复不仅要生成补丁，还要在同一仓库跑测试、确认文件变更范围。若 Standard 通过率与 Ultrafast 相同、但只慢 8 秒，而工程师没有被这 8 秒阻塞，就保持 Standard；若线上修复每节省一分钟都有明确价值，再给该任务单独开极速路由。路由规则写进配置和监控，避免全站切换后才发现费用暴涨。
在 Code0 的任务看板里，可把超时阈值与费用上限放进任务类型配置，而不是绑定整个模型；每周抽查一次实际 service_tier、合格交付率与回退次数。若旧版路由已满足 p95 目标，就没有必要为该类请求默认购买极速。
试运行验收清单
- 选择 20—30 个历史任务，覆盖短答复、工具密集、长上下文三类；固定输入、工具和推理档。
- 三档各测至少两轮；记录首次可见输出、完整响应、整项任务通过验收的时间。
- 保存响应
usage、实际service_tier、失败重试和调用成本；对 >272K 的请求单独分组。 - 由同一规则检查结果质量，记录返工分钟数；不能只按成功返回 HTTP 200 算完成。
- 给出任务级路由：哪些默认 Standard，哪些提到 Fast，哪些只有在明确的时延目标下才用 Ultrafast；设置预算上限与回退。
资料来源
- OpenAI：GPT-6.1 Sol 模型页与官方价格页：模型 ID、定价、长上下文规则。
- OpenAI：Ultrafast 模式指南与发布说明：请求参数、WebSocket、速率限制与开放范围。
- OpenAI：ChatGPT 更新日志与Codex 使用说明：转向、排队及产品入口。
