核验清单

  • ✓打开用量页，把 Responses 或 Chat Completions 按 service tier 分组，不要只看模型名合计。
  • ✓对账时读响应体里的 service_tier，不要只存请求参数。返回 default 就是按标准价，即使请求写了 fast。
  • ✓查项目设置里的 Project Service Tier。代码没写 service_tier 时走的是项目默认，不是「标准价」。
  • ✓Flex 的 429 Resource Unavailable 不应出现在账单里。若重试时删掉了 service_tier，下一笔可能已经离开 Flex 价。
  • ✓旧模型用量里 Fast 可能显示成 priority。按 fast 这个字符串筛账单，会把同一档漏掉一半。

1. 贵的不是换接口，是同一条请求上的延迟档

上一档容易和 Batch API 搞混。Batch 是另一条路径：上传 JSONL，最多等 24 小时，折扣写在那条端点上。Flex 和 Fast 不是这条路径。它们仍是 Responses 或 Chat Completions 的同步请求，只是多了一个 service_tier。

OpenAI 把处理档写成三层。不写参数或写成 auto，用的是项目设置里的档；项目没改过，默认是 default，也就是标准价、标准延迟。写成 flex，token 按 Batch API 的价格，还可以再叠 prompt caching 折扣，代价是更慢，而且容量不够。写成 fast（旧名 priority，两个值等价），买的是更低、更稳的延迟，按 token 加价。

模型名可以完全一样。财务若只按「这个月 gpt 多少钱」对账，会把半价的离线任务和翻倍的在线对话揉成一条单价，然后去换模型。该换的是档位，不是权重。

2. Flex 便宜，是因为失败可以免费

Flex 文档写得很直：适合评测、数据补充、异步作业，不适合要立刻返回的生产对话。价格对齐 Batch，但请求还在这次 HTTP 里等结果。官方 SDK 默认超时 10 分钟；Flex 示例把超时拉到 15 分钟。超时返回 408 时，SDK 会自动重试两次再抛错。

容量不够时返回 429 Resource Unavailable，这次不计费。这是 Flex 和「慢一点的标准请求」的分界。标准请求慢，仍然按标准价；Flex 没排上容量，账单上不该有这一笔。

重试策略会把折扣吃回去。文档给了两条路：指数退避，继续 Flex，等容量回来，单价不变；或者把 service_tier 改成 auto，或干脆删掉这个参数，改走项目默认档。第二条不是「再试一次还是半价」。项目若被改成 Fast，这次「便宜重试」会按加价档出去。日志里只记了「Flex 失败后重试成功」，对不上账单。

3. Fast 成功了，不代表你按 Fast 付了钱

Fast 文档写明：2026 年 7 月 30 日 Priority 更名为 Fast，请求里 priority 和 fast 是同一档。响应里的 service_tier 才是实际用来处理这次请求的档。GPT-5.6 及更早的模型，无论你写 fast 还是 priority，返回值都是 priority。用量页按 service tier 分组时，这些请求也显示成 priority。

加价不是一张统一的「两倍券」。文档给的例子是 GPT-5.6 Sol 的 Fast 为对应标准价的两倍，短上下文输入 8 美元/百万 token、输出 40 美元，长上下文输入 16、输出 60，促销价至少维持到 2026 年 11 月 21 日。别的模型乘数以定价页为准。缓存输入的折扣在 Fast 上仍然有效。微调模型和 embeddings 不支持 Fast。

更隐蔽的是降档。流量爬得太快时，系统可以把一部分 Fast 请求降回标准速度，并按标准价收费，响应里变成 service_tier: "default"。官方的经验值：到了每分钟 100 万输入 token 之后，每 15 分钟增幅不要超过 50%，实际阈值还随模型和当时容量变。爬坡限制按组织算，不是按单个项目。换模型、换快照、把整晚 ETL 丢进 Fast，都会踩到。

降档的请求是成功的。监控如果只看 4xx/5xx，什么都不会响。用户觉得「今天 Fast 没那么快」，财务看到同一模型两条单价。两边都不会先去读响应字段。

4. 项目默认、限流池和 Scale 是三本账

项目设置里可以把 Project Service Tier 改成 Fast。此后没写 service_tier 的请求会逐步切到 Fast，不是立刻全部切换。代码审查看不到 diff，账单会在几小时里变贵。反过来，项目若禁止某一档，错误码说明写明：请求显式指定、或 auto/省略参数最终落到不允许的档，都会 400，param 是 service_tier。fast 在这套项目策略里按 priority 评估。Scale Tier 不在这套限制里。

Fast 和标准档共用同一套按模型的限流，不另开池。这和 Batch API「独立限流池」相反。买 Fast 买不到额外 TPM。Scale Tier 又是另一本账：Fast 的费用单独算，不扣你买下的 Scale TPM；Scale 溢出的流量也不会自动改走 Fast。

GPT-6 Astra 的 Fast 没有延迟 SLA。更早模型的 Fast 与 Scale 走同一套 SLA 口径，企业合同里才可能有未达标的服务积分。付了加价、没有延迟承诺，这在最新模型上是写明的，不是客服口误。

5. 对账拆档位，席位续费不要和 API 额度绑一张卡

复盘至少留三列：请求参数、响应里的 service_tier、用量页按 service tier 的金额。三列不一致时，先信响应和用量页。参数写 fast、响应是 default，是降档，不是丢单。用量显示 priority、代码写 fast，是别名，不是另一笔消费。

API 预付积分和 ChatGPT 网页席位仍是两本账。档位折扣发生在 service_tier 上，不发生在卡 BIN 上。网页席位续费用可设额度的虚拟卡隔开，例如 RDVCC，避免订阅自动续费和 API 充值抢同一条卡。虚拟卡改变不了 Flex 的 429，也改变不了 Fast 被降回标准价。