OpenAI Fast Mode 打开长上下文限制：路由团队现在要做哪些判断

8 月 5 日之前，大上下文请求走不了 Fast mode，这件事从来没有被明说过。发送一条超过 200K token 的 prompt 并附带 service_tier: "fast"，系统会静默降级到 Standard tier，响应里的 service_tier 字段会变成 "default"。你以为在付优先处理的钱，实际上没有。

跑全仓库代码分析、大文档 RAG pipeline、或者多轮 agent 会话积累到 200K 以上 token 的团队，一直被困在 Standard tier 里，不管配置了什么。

8 月 5 日这个情况变了。OpenAI 更新了 GPT-5.6 Sol、Terra 和 Luna，让 Fast mode 现在可以接受超过 272K token 的请求，最快比 Standard 快 2.5 倍。service_tier: "fast" 和 service_tier: "priority" 两个参数在长上下文路径上都能生效了。

API 行为变化

8 月 5 日前，带 service_tier: "fast" 的 300K token 请求会被降级，响应返回 service_tier: "default"。这是静默失败，日志里没有报错，只是没达到预期。

8 月 5 日后，同样的请求走 Fast mode，响应返回 service_tier: "priority"。文档里写明了一个行为细节，GPT-5.6 模型不论你发的是 fast 还是 priority，响应里统一返回 priority，不是 bug。

定价溢价还在，GPT-5.6 Sol 的 Fast mode 是 Standard 的两倍价格，Terra 和 Luna 有各自的 Fast mode 溢价。速度提升最高 2.5 倍覆盖全部三个模型。

Ramp rate limit 对长上下文的意义变了

Fast mode 的 ramp rate limit 不是新增的，但它对长上下文工作负载的影响规模变了。触发条件是每分钟发送至少 100 万 token，且在 15 分钟内提升超过 50%。触发后，部分 Fast mode 请求会被降级到 Standard 速度并按 Standard 计费，响应返回 service_tier: "default"。

短 prompt 高频请求很难意外触发这个限制。长上下文就不同了。一个跑大型 monorepo 代码索引的 agent，同时处理 50 个文件、每个 20K token，一分钟就凑够了 100 万 token，根本不用刻意。

应对方式是把 ramp rate limit 当作流量整形约束来处理，而不是背景注意事项。用 feature flag 把长上下文路由逐步迁移到 Fast mode。批量操作，整仓库索引、大量文档摄取、离线 ETL，留在 Standard tier，或者拉长处理窗口。Fast mode 的设计场景是用户在等待结果的交互请求，不是吞吐量优先的批量作业。

三个模型各自的路由判断

GPT-5.6 Sol 是旗舰，适合延迟最敏感的场景。用 Sol 跑大上下文任务并且有真实用户在等结果的场景（深度代码分析、长 agent 会话），Fast mode 现在能让 2× 的价格溢价有对应的效果。

GPT-5.6 Terra 定位是能力和成本的平衡点。7 月 30 日降价 20%，加上现在的 Fast mode 支持，Terra 是大多数生产级长上下文工作负载首先要测的路由候选。Fast mode Terra 比 Standard Terra 贵，但如果更低的延迟能减少 long agent session 里的重试次数，净成本可能反而更低。

GPT-5.6 Luna 本来就是面向高并发、成本敏感场景的选项，7 月 30 日降价 80%。Luna 上的 Fast mode 适合用户可见的低成本大上下文应用，Luna 的价格基数让 Fast mode 溢价更容易被吸收。

其他 provider 目前没有这一层结构

Anthropic 和 Google 目前都没有提供与 Fast mode 对等的、按请求计费的优先处理 tier，专门面向长上下文场景。Claude Opus 5 和 Sonnet 5 支持很大的上下文窗口，但 Anthropic 没有公开一个类似的延迟溢价 tier。Google Gemini 2.0 Pro 支持 2M token，标准 API 层面同样没有按请求收费的优先 tier。

Azure Foundry 的 Provisioned Throughput 和 AWS Bedrock 的 Provisioned Capacity 对长上下文工作负载提供性能保障，但这是承诺制，需要容量规划、预留支出，通常还有合同周期。OpenAI Fast mode 是按需的，每个请求付溢价，不需要提前分配容量。对于长上下文需求峰谷不定的团队，这两种风险结构是不一样的。

现在需要改哪些配置

现有的长上下文路由使用 service_tier: "default" 或者没有设置 service tier 的， 梳理哪些路径对延迟有真实要求。用户在等待结果的交互请求，而不是后台索引或离线分析，是切换到 service_tier: "fast" 的候选。

已经在长上下文路径上设了 service_tier: "fast" 的， 验证行为实际变了。检查响应里的 service_tier 字段，8 月 5 日前如果一直返回 "default"，现在应该返回 "priority"。

运行大批量或 ETL 任务、prompt 很长的， 不要切换到 Fast mode。Ramp rate limit 的触发条件和批量作业的流量特征高度吻合，触发后会按 Fast mode 定价收费但只得到 Standard 速度。

Project 级别的配置入口在 OpenAI 控制台，Settings → Project → General → Project Service Tier → Fast，会把项目内所有没有显式设置 service_tier 的请求默认切到 Fast mode。混跑批量和交互请求的项目要谨慎使用。

TheRouter 用户需要确认的事

通过 gateway 路由 GPT-5.6 时，确认 service_tier 参数在 passthrough 过程中没有被丢弃或改写。一个静默重写请求参数的 gateway 会让 Fast mode 在这次更新之后仍然无法生效。

使用 TheRouter 的多 provider 路由、同时接多个上游的团队，要注意 Fast mode 的触达范围是 GPT-5.6，不影响路由到其他 provider 的请求。如果 GPT-5.6 Terra 的 Fast mode 是主路由，fallback 到 Claude Sonnet 5 或其他 provider 时按 Standard 定价计算预算，除非你刻意让每一跳都走优先 tier。