OpenAI Ultrafast mode routing 让 GPT-5.6 Sol 多了一条 14 倍预览快车道

OpenAI 又把服务层级变成了一个路由问题。8 月 13 日的 API changelog 增加了 Ultrafast mode，这是给 GPT-5.6 Sol 的限量预览服务层，OpenAI 称它的速度最高可达 Standard processing 的 14 倍。它没有换一个模型别名。它给同一个前沿模型家族加了第二种延迟承诺，网关该在哪里做决策也随之改变。

运营者眼下要关心的不是 GPT-5.6 Sol 会不会更快。路由表必须把延迟、成本、预览资格和 fallback 行为分开。如果它们仍然被塞进同一个模型字符串，OpenAI Ultrafast mode routing 很难安全落地。

OpenAI Ultrafast mode routing 是服务层决策，不是模型迁移

官方来源给了三个确定事实。Ultrafast mode 面向 GPT-5.6 Sol，处于 selected customers 的限量预览，OpenAI 称速度最高可达 Standard processing 的 14 倍。changelog 还没有给出新 endpoint、新 model ID 或公开价格表。

这个空白本身就很重要。如果只是从 gpt-5.6-sol 迁移到另一个模型 ID，网关很容易隔离。服务层 flag 则不同。已经使用 OpenAI Fast mode 的团队见过这种模式，service_tier policy 可以在不换模型家族的情况下改变延迟等级。Ultrafast mode 把这个拆分推得更远，它宣传的是一条可能只对部分组织开放的预览层，幅度也高过此前长上下文 2.5 倍加速。

安全的网关至少应该把 route key 拆成四个字段。

• provider 保留 openai
• model family 保留 gpt-5.6-sol
• service tier 记录 standard、fast 或 ultrafast
• eligibility 记录账号、项目或客户审批状态

如果这些字段被压成 openai-gpt56-best 这样的单一字符串，你就无法解释为什么某个请求走了更贵的快车道，而另一个没有。

OpenAI Ultrafast mode routing 的请求形状要加一层 policy

在这次公告之前，很多团队会给紧急的 GPT-5.6 Sol 请求写一个简单规则。

{
  "model": "gpt-5.6-sol",
  "service_tier": "fast"
}

Ultrafast mode 出现后，这个形状需要被 policy 包住。请求本身不应该自己决定它配不配走预览层。

{
  "model": "gpt-5.6-sol",
  "service_tier": "ultrafast",
  "metadata": {
    "latency_budget_ms": 1200,
    "workload_lane": "interactive-agent",
    "fallback_allowed": true
  }
}

真正的变化不在 JSON 属性名，而在外层决策。路由选择应该检查项目是否获准使用 Ultrafast mode，工作负载是否真的有严格延迟预算，预览层不可用时 fallback 路径能不能保住足够质量。等待阻塞式代码编辑的 coding agent 可能符合条件。夜间 eval batch 通常不该走这条路。

跨 provider 看，这不只是 OpenAI 加速新闻

过去两周出现了三种不同的路由压力。DeepSeek 开始引入 peak 和 off-peak pricing，同一个模型在指定 UTC 窗口会贵 2 倍。OpenAI Fast mode 把速度变成 GPT-5.6 的付费层。现在 OpenAI Ultrafast mode routing 又给顶层 Sol 加了需要资格的低延迟车道。

这三件事不是同一个旋钮。DeepSeek 的变化是按时间段做成本路由。Fast mode 是付费延迟路由。Ultrafast mode 是带资格门槛的延迟路由。模型 router 如果把它们都当成 provider 脚注，最后会得到糟糕的成本报表和事故复盘。

router 视角应该把它们归一成几个 policy 维度。

• time window 影响成本
• service tier 影响延迟和价格
• preview eligibility 影响可用性
• fallback target 影响质量和兼容性

所以这条新闻应该放在此前的 OpenAI Fast mode long-context routing coverage 旁边，而不是扔进普通模型发布分类。同一个模型现在可以有多种运营性格。

这一周该改的网关配置

先把模型选择和服务层选择拆开。日志、billing exports 和 routing config 里都应该分别记录 gpt-5.6-sol 与 ultrafast。如果 usage ledger 不能按 service tier 分组，你就无法证明预览快车道到底改善了体验，还是只烧掉了预算。

其次，为 Ultrafast mode 设置明确 allowlist。限量预览意味着有些请求能用，有些请求不能用。预览层不可用时，网关应该 fail closed 到 Standard 或 Fast mode，而不是盲目重试到延迟更差。

第三，按工作负载更新 fallback policy。交互式 agent turn 可以从 Ultrafast 退到 Fast，再退到 Standard，随后才考虑另一个前沿 provider，前提是 tool-call 和 reasoning 语义还能接受。Batch jobs 通常应该直接跳过 Ultrafast。

最后，内部链接不要猜细路径。相关的 TheRouter 模式是基于 policy 的 AI API routing 和 accounting，可以从稳定的 TheRouter documentation 开始。OpenAI changelog 给出了信号，运营工作是确保低延迟车道不会变成看不见的模型别名。