Gemini Flex inference 被抢占怎么办：可让渡请求、重试边界与离线任务取舍

离线评测跑到一半，几条 Gemini 请求突然返回 503；把同一请求改回默认层级后又能成功。这个现象不一定是代码写错，Gemini Flex inference 本来就是用较低价格换取可让渡容量：它适合能等几分钟的后台任务，不适合把用户正在等待的答案直接压在这条链路上。

把 Flex 当作“可被打断的同步请求”来设计：先判断任务是否能承受等待，再处理 429/503 和超时；不要期待服务端替你自动切回 Standard。

Flex inference 解决的不是“所有请求都降价”

官方把 Flex inference 定义为预览中的推理层级。它使用非高峰期的可让渡算力，调用仍是同步的，不需要像 Batch 那样先提交任务、再等异步结果；代价是延迟和可用性都不是强保证。标准 API 的省心程度、Flex 的价格和 Batch 的吞吐，不能只看同一个“50%”数字。

因此，先问业务一句：这条调用如果晚几分钟，或者本次失败后延迟到下一轮，结果还能用吗？能用，才有资格进入 Flex。

最小调用只改一个 service_tier

如果使用 Google Gen AI SDK，可以在一次同步调用中指定 service_tier='flex'。下面的示例故意保留业务层的返回值和异常边界，方便把它放入评测或后台数据丰富任务，而不是藏在一个“万能重试”函数里。

from google import genai

client = genai.Client()

def run_flex(prompt: str):
    return client.interactions.create(
        model="gemini-3.7-flash",
        input=prompt,
        service_tier="flex",
    )

官方示例同时展示了 Interactions API 的 Python、JavaScript 和 REST 写法；这里的关键不是模型名，而是显式传入 service_tier。省略它时，请求走默认的 Standard。

429、503 和超时要分开处理

503 更接近“当前 Flex 容量不可用”，429 则可能表示速率限制或资源耗尽。它们都不是“改成 Standard 就一定能成功”的证据，也不应该无条件高速重发。每次请求至少关联自己的任务 ID、尝试次数和最终层级，避免同一批任务在重试时失去对账线索。

import random
import time

def call_with_retry(prompt, max_attempts=4):
    for attempt in range(max_attempts):
        try:
            return run_flex(prompt)
        except Exception as exc:
            status = getattr(exc, "status_code", None)
            retryable = status in (429, 503)
            if not retryable or attempt == max_attempts - 1:
                raise
            delay = min(60, 2 ** attempt) + random.random()
            time.sleep(delay)

这段代码只表达“可重试的暂态边界”，并没有替你决定是否升档。生产代码还要给整个调用设置足够长的客户端超时；可以把 10分钟超时 作为总等待预算的显式检查点，官方页面针对可能排队的 Flex 请求建议考虑 10 分钟或更长，而不是沿用交互接口常见的几十秒超时。

重试不是自动升档：把降级写成显式策略

Flex 容量被抢占或驱逐时，服务端不会为了让请求成功而自动把它升级为 Standard。若你的业务允许失败后转 Standard，应该在自己的策略层记录这次决定，并限制范围，例如只对小批量、可计费的后台任务启用；涉及用户实时答案时，直接从入口选择 Standard 通常更清楚。

一个实际的分流顺序可以是：先以 Flex 发起；遇到 429/503，按指数退避重试有限次数；超过等待预算，就看任务是不是允许异步。如果允许，转入 Batch 队列；如果不允许，不要静默升级或无限重试，返回可追踪的失败状态。

什么时候应改用 Batch

Flex 和 Batch 都可能带来 50% 的价格差异，但它们解决的是不同问题。Flex 仍然是同步请求，适合多步链路中“上一步结果出来后才能继续下一步”的场景；Batch 是异步批处理，适合样本相互独立、可以统一对账的评测或数据预处理。

• 需要马上拿到每一条结果，并且下一步依赖上一条结果：优先评估 Flex。
• 一批请求彼此独立，晚些时候统一下载和核对：优先评估 Batch。
• 用户正在页面上等待，失败会直接影响主流程：用 Standard 或更高可靠性的服务层级。

不要用一次成功的 Flex 请求推断全天可用。把 429、503、超时、重试次数和最终层级写进指标，连续观察后再调整任务分流。

常见问题：Flex inference 的几个边界

Flex 会自动切回 Standard 吗？

不会。容量不足时，应用需要自己决定重试、转异步或失败收口；若主动切换 Standard，也要把它当成明确的成本与可靠性策略。

Flex 适合在线聊天吗？

通常不适合把它放在用户必须即时看到的主请求上。分钟级等待和可让渡容量会让交互体验不可预测，除非业务已经设计了异步等待。

429 和 503 都可以无限重试吗？

不可以。设置最大尝试次数、指数退避和总等待预算，超过预算就记录最终失败；否则重试流量可能进一步放大拥塞。

Flex 与 Batch 能互相替代吗？

不能完全替代。Flex 是同步、低成本、可被抢占的推理层；Batch 是异步批量接口。按是否依赖即时结果和是否能统一对账来选。

落地前的检查清单

1. 确认任务能接受分钟级等待，且不是用户实时主链路。
2. 确认模型和 SDK 支持 service_tier=flex，并在配置中显式记录所选层级。
3. 给 429/503 设置有限重试、指数退避、总超时和最终失败状态。
4. 决定是否允许应用层转 Standard；允许时记录成本与层级变化。
5. 对独立大批量任务比较 Batch，不要只因折扣相同就忽略接口形态。

Flex 的价值在于给非紧急工作多一个成本档位。把等待、抢占和失败都当成正常状态建模，才不会在容量波动时把“便宜的同步调用”误当成“稳定的后台队列”。