gpt-6.1-sol 的 Fast 与 Ultrafast 模式：怎么开、怎么选、怎么确认生效

Fast 和 Ultrafast 是什么，gpt-6.1-sol 都能用吗

两者都是 OpenAI API 的服务等级（service tier），用来换取更快的输出速度，不改变模型本身。Fast 模式原名 Priority processing，2026 年 7 月 30 日更名，官方 Fast 模式指南（https://developers.openai.com/api/docs/guides/fast-mode）说明它提供更快、更稳定的延迟，适合对延迟敏感、流量平稳的面向用户的应用，请求里写 service_tier 为 fast 或 priority 效果相同。

Ultrafast 模式是 OpenAI API 里最快的服务等级。官方 Ultrafast 指南（https://developers.openai.com/api/docs/guides/ultrafast-mode）写明它面向 GPT-6 Astra 和 GPT-6.1 Sol，对所有 API 用户开放，用于速度值得付出更高费用的场景。OpenAI 更新日志（https://developers.openai.com/api/docs/changelog）10 月 8 日条目写明：在 Responses API 中为 gpt-6.1-sol 加入 Ultrafast 模式，用 service_tier 等于 ultrafast 来缩短生成 token 之间的间隔。

需要注意：Responses 接口参考里对 ultrafast 取值的说明仍写着「受访问控制、目前用于 gpt-5.6-sol」，与 Ultrafast 指南和更新日志不一致。本文以较新的 Ultrafast 指南和 10 月 8 日更新日志为准；如果你的请求被拒绝，以实际返回的错误信息为准。

请求里怎么写：Fast 与 Ultrafast 的参数和接口

Fast 模式：在 Responses API 或 Chat Completions 的请求体里加 service_tier，值为 fast。官方示例的 Responses 请求体是 {"model": "gpt-6.1-sol", "input": "...", "service_tier": "fast"}。直连 OpenAI 时，也可以在控制台 Settings → General → Project Service Tier 里改成 Fast，此后未写 service_tier 的请求默认走 Fast，官方说明项目内请求会逐步切换过去。通过中转服务调用时，你通常改不到上游项目设置，应在每个请求里显式写 service_tier。

Ultrafast 模式：把 model 设为 gpt-6.1-sol、service_tier 设为 ultrafast。官方 HTTP 示例的请求体是 {"model": "gpt-6-astra", "input": "...", "service_tier": "ultrafast"}，把模型名换成 gpt-6.1-sol 即可，请求地址是 Responses API 的 /v1/responses。官方文档只给出了 Responses API 的 Ultrafast 写法，Chat Completions 接口参考里 service_tier 的可选值也没有 ultrafast，所以不要在 /v1/chat/completions 上用 ultrafast。

如果你原来用 Chat Completions，迁移到 Responses API 还有另一个理由：gpt-6.1-sol 官方模型页（https://developers.openai.com/api/docs/models/gpt-6.1-sol）写明调用工具必须使用 Responses API。用工具的应用本来就要走 Responses，顺带就能用上 Ultrafast。

Fast 与 Ultrafast 都只是服务等级，模型的其他设置照旧。gpt-6.1-sol 的 reasoning.effort 支持 low、medium（默认）、high、xhigh、max，不含 none；推理档位越高，模型思考用的时间和 token 一般越多，调速度时可以把档位和服务等级一起考虑。

Ultrafast 为什么推荐配合 WebSocket

官方 Ultrafast 指南强烈建议使用 WebSocket，尤其是连续多次调用工具的智能体应用：如果没有常驻连接，每次请求的网络开销会抵消一部分 Ultrafast 带来的提速。Ultrafast 也支持普通 HTTP 请求，只是官方推荐在工具调用频繁的场景下用 WebSocket。

WebSocket 模式（https://developers.openai.com/api/docs/guides/websocket-mode）连接的是 /v1/responses。每一轮由客户端发送一个 response.create 事件，内容与普通 Responses 请求体相同，只是不使用 stream、background 这类传输字段；Ultrafast 指南要求在每个 response.create 事件里都写上 model 和 service_tier 为 ultrafast。后续轮次只发送新的输入，并把上一轮的响应 ID 填进 previous_response_id。

官方列出的 SDK 依赖：Python 为 openai[realtime] 3.8.0 及以上，JavaScript 为 openai 7.10.0 及以上加 ws 包。单个连接最多同时处理 16 个进行中的响应，超出的会排队；最多使用 32 个不同的命名 stream_id。

通过中转服务调用时，先确认对方是否支持 /v1/responses 的 WebSocket 连接；不支持就用 HTTP 方式发送 service_tier 为 ultrafast 的请求，官方说明这种方式同样可用，只是少了常驻连接带来的那部分收益。

怎么确认真的走了 Fast 或 Ultrafast

不要只看请求里写了什么。Responses 接口参考写明：设置了 service_tier 时，响应体里的 service_tier 表示这次请求实际使用的处理方式，可能与请求里写的不同。

Ultrafast：接口参考写明，经 Ultrafast 处理的响应会显示 service_tier 为 ultrafast。看到这个值才算生效。

Fast：接口参考写明请求写 fast 或 priority 时响应显示 priority，Fast 模式指南则把这一点限定为 GPT-5.6 及更早模型，没有单独写明 gpt-6.1-sol 返回哪个值，所以核对时重点看它是不是 default。Fast 模式指南写明，如果流量增长过快，系统可能把部分 Fast 请求降为标准速度并按标准价格计费，这时响应里是 service_tier 为 default。官方给的经验是：流量达到每分钟 100 万输入 token 后，每 15 分钟增长不超过 50%，切换模型或快照时也要逐步放量，不要用 Fast 跑大批量 ETL 或批处理任务。

通过中转服务调用时，如果响应里没有 service_tier 字段，或者一直是 default，说明这次没有按你选的等级处理，或者中间服务没有转发这个参数，需要向服务方确认它是否支持 Fast 和 Ultrafast、按什么价格计费。

一个简单的核对办法：同一个提示词分别用不写 service_tier 和写 ultrafast 各发几次，记录响应里的 service_tier 和你这边测到的输出速度，确认字段为 ultrafast 且速度有明显变化，再把业务流量切过去。

限额和数据驻留：Ultrafast 与 Fast 不一样

限额：Fast 模式与标准模式共用同一个模型的速率限制，用量按相同方式计入。Ultrafast 则有独立于标准模式和 Fast 模式的速率限制。Ultrafast 指南列出的 gpt-6.1-sol 默认 Ultrafast 限额为：Build 档每分钟 1,000,000 token，Launch 档 4,000,000，Grow 档 40,000,000；需要更高限额的组织可以联系 OpenAI 客户团队。这些是 OpenAI 组织层面的限额，通过中转调用时实际可用的并发与限额以服务方为准。

数据驻留：gpt-6.1-sol 的 Ultrafast 支持美国、欧盟数据驻留和全球处理（GPT-6 Astra 的 Ultrafast 只支持美国数据驻留和全球处理）。Fast 模式指南写明 Fast 支持 gpt-6.1-sol 的欧盟数据驻留，并兼容零数据保留（ZDR），具体以各模型的可用性为准。

费用和选择建议

两种模式都按高于标准模式的单价计费：Fast 模式按 token 收取溢价，缓存输入的折扣仍然适用；Ultrafast 的输入、缓存输入、缓存写入和输出单价单独列在官方价格页的 Ultrafast 表里。具体单价和倍数以 OpenAI 官网价格页（https://developers.openai.com/api/docs/pricing）为准；通过中转调用时，以服务方价格页为准。

怎么选：面向用户、需要延迟稳定的对话或接口，可以先试 Fast，它两个接口都能用，改动最小；智能体编程、计算机操作这类工具调用一轮接一轮的任务，等待时间会逐轮累积，适合 Ultrafast 加 WebSocket；对延迟不敏感的批量任务不要用这两种模式，官方另有价格低于标准模式的 Batch 和 Flex。

上线前建议做一个小规模对比：同一批代表性请求分别用标准、Fast、Ultrafast 跑一遍，记录每种方式响应里的 service_tier、总耗时和 usage 里的 token 数，再按自己的价格表算出费用，确认提速值得多花的费用后再切换。

常见问题

在 Chat Completions 里写 service_tier 为 ultrafast 可以吗？Chat Completions 接口参考列出的 service_tier 可选值里没有 ultrafast，更新日志写的也是在 Responses API 中提供。要用 Ultrafast，请改用 /v1/responses。

写了 fast，响应里却是 default？Fast 模式指南说明，流量增长过快时部分 Fast 请求会被降为标准速度、按标准价格计费，响应显示 default。按上面的放量建议逐步增加流量；如果是通过中转调用，还要确认服务方是否转发了 service_tier。

Ultrafast 和 Fast 能同时写吗？不能。service_tier 一次只能取一个值，Responses API 的可选值包括 auto、default、flex、scale、priority、fast、ultrafast。不写时默认是 auto，按项目设置处理，项目没有单独设置时就是 default。

开了 Ultrafast 后上下文和输出上限会变吗？官方 Ultrafast 指南没有提到改变模型规格。gpt-6.1-sol 官方模型页写明上下文窗口 1,050,000 token、最大输入 922,000 token、最大输出 128,000 token。

还有其他问题？完整文档与客服入口见 gpt-6.1-sol API 中转站。

这个站还有这些内容

• gpt-6.1-sol API 在国内怎么接入？接入步骤与可直接复制的代码
• gpt-6.1-sol 用官方直连还是中转？逐项对比逐项对比，含中转方案的局限
• gpt-6.1-sol API 常见问题接入时最常遇到的问题

开始使用

确认分组倍率并开始测试 gpt-6.1-sol API

注册后创建 API Key

账号入口：OpenLux