Google 在 Gemini API 中新增了 Flex 与 Priority 两个服务层，允许开发者通过统一同步接口在成本与可靠性之间做精细化调优；Flex 面向容忍延迟的大规模后台任务，价格约为标准层的半价，而 Priority 为关键实时交互提供最高保障并在超额时优雅降级到标准层。该功能适配 GenerateContent 与 Interactions API，开发者只需设置 service_tier 参数即可切换。
概览
– 新增两种推理服务层：Flex（成本优化）和 Priority（高可靠性）。
– 两者都通过现有同步端点使用，无需回退到异步 Batch API 的复杂流程。
Flex（成本优先）
– 目标：延迟容忍型、大规模背景工作负载（如 CRM 更新、研究模拟、代理“思考”流程）。
– 主要特点：
– 成本：相比 Standard 约节省 50%。
– 接口：同步调用，保留熟悉的端点，无需管理文件或轮询。
– 使用：在请求中设置 service_tier=Flex；适用于 GenerateContent 与 Interactions API，适用于所有付费等级。
Priority（可靠性优先）
– 目标：对延迟和可用性有严格要求的实时应用（如客服机器人、实时内容审核、时间敏感请求）。
– 主要特点：
– 最高关键性保障：在平台高峰期也优先调度，减少被抢占。
– 优雅降级：超出 Priority 配额的溢出请求自动退到 Standard 层而非直接失败，保证连续性。
– 可见性：响应中会注明实际服务请求的层级，便于性能与计费透明化。
– 使用：在请求中设置 service_tier=Priority；可用于 Tier 2/3 付费项目的 GenerateContent 与 Interactions API。
开发与迁移要点
– 无需改用异步 Batch API：同一同步接口即可区分背景与交互任务，简化架构。
– 开始方式：在请求中传入 service_tier 参数；查看 Gemini API 文档获取完整定价与示例代码（官方 cookbook 提供可运行示例）。
适用场景建议
– 用 Flex 处理高吞吐、可延迟的批量或代理后台任务以降低成本。
– 用 Priority 保障关键用户交互与时间敏感流水线的稳定性与连续性。
替代方案与限制
– Flex 降低了可靠性以换取成本，需权衡业务可容忍的错误和延迟窗口。
– Priority 需满足付费项目等级要求（Tier 2/3）；超额仍会回退到 Standard，需监控配额和成本。
这是把异步批处理优势带回同步调用的实用改进，能显著简化多类型工作负载的工程设计。