结论先说
如果你的 Gemini 负载可以等，用 Flex。如果用户在等，用 Priority。本指南假设你已经有一个可用的 Gemini API 集成，并且项目已开通付费层级。
这就是 Google 2026-04-02 发布 Flex 和 Priority 推理层级的实际含义。Flex 是面向延迟容忍型工作的低价同步层级，Google 表示其价格比 Standard API 最高低 50%。Priority 是高优先级层级，用于需要在高峰期保持可用的生产流量，Google 表示溢出请求会降级到 Standard 而不是直接失败。
业务上的变化不只是定价。在此之前，很多团队不得不把架构一分为二：标准同步调用处理实时 UX，Batch API 处理更便宜的后台工作。Google 现在推的模式更简单：保持一套同步集成形式，然后按业务重要性路由每个请求。
为什么这条新闻值得关注
Google 于 2026-04-02 发布了 Gemini API 的 Flex 和 Priority 推理层级。值得写的原因是，它改变了使用 Gemini 构建系统的团队面临的一个实际实现选择：你不再需要把更便宜的后台处理和更可靠的交互流量当作两种完全不同的集成模型。
所以有用的框架是工作流，不是新闻回顾。问题不是"Google 发布了什么"，而是"我现在应该怎么改请求路由"。
简短建议
先用这条规则，只在你的流量数据证明它错了的时候再调整。
| 负载类型 | 最佳层级 | 原因 |
|---|---|---|
| 离线数据充实、夜间作业、长时间运行的内部分析 | Flex | 低成本比响应速度更重要 |
| 用户界面聊天、客服、内容审核、紧急操作 | Priority | 可靠性比单价更重要 |
| 没有严格 SLA 需求的常规应用流量 | Standard | 不需要极端优化时的简单默认选择 |
一句话版本：按延迟的后果来路由，而不是按模型偏好。
Google 官方改了什么
截至 2026-04-03，Google 官方发布文章说明：
- Flex 和 Priority 是新的 Gemini API 服务层级。
- Flex 是面向延迟容忍型工作的同步层级。
- Flex 定价比 Standard API 最高低 50%（针对支持的请求）。
- Priority 是面向重要流量的最高优先级层级。
- 如果 Priority 配额用尽，溢出请求以 Standard 层级处理，而不是失败。
- Flex 面向付费层级的
GenerateContent和 Interactions API 请求。 - Priority 面向 Tier 2 和 Tier 3 付费项目的
GenerateContent和 Interactions API 请求。
这些细节足以制定实用的路由策略，不需要猜测 Google 没有声明的模型质量变化。
Flex vs Priority vs Standard
| 层级 | 最适合 | 主要优势 | 主要取舍 | 值得记住的官方说明 |
|---|---|---|---|---|
| Standard | 常规生产流量 | 简单的默认选择 | 没有特别的价格或可靠性优化 | 不需要特殊策略时的基准线 |
| Flex | 后台或可延迟的工作 | 同步请求成本更低 | 可靠性和延迟低于 Standard | Google 表示价格比 Standard 最高低 50% |
| Priority | 用户可见的关键流程 | 高峰期可靠性更高 | 溢价定价和项目资格要求 | 溢出请求降级到 Standard 而非直接失败 |
关键转变在于 Flex 不只是"改了名的 Batch"。Google 把 Flex 定位为同步接口，所以你可以保持相同的请求方式，同时把低价值工作移到更便宜的层级。
什么时候用 Flex
当以下三个条件同时成立时用 Flex：
- 任务不需要立即返回结果
- 更慢或偶尔不可靠的请求是可以接受的
- 成本比让每个请求都保持最高优先级更重要
适合的场景：
- 销售通话结束后标注 CRM 记录
- 为内部看板生成摘要草稿
- 在后台运行的研究或 Agent 任务
- 每晚重新处理内容或客服对话记录
- 批量分类（重试即可，不影响用户）
- 定期数据充实或标注流水线
不适合的场景：
- 阻塞购买流程的结算助手
- 用户已经在等待的实时客服聊天
- 必须立即响应的实时审核关卡
- 超时意味着收入损失或合规风险的流程
一个简单测试：如果请求可以进入队列而不影响用户体验，Flex 通常是首选。
什么时候用 Priority
当延迟的代价超过请求本身的代价时，用 Priority。
适合的场景：
- 活跃对话中使用的客服 copilot
- 应用内的生产聊天
- 位于关键路径上的审核或路由决策
- 实时触发下游系统的操作
Priority 不是所有调用的通用升级。只有当业务影响足以证明其合理性时才是正确选择。否则你会为用户根本不会注意到（如果跑在 Standard 或 Flex 上）的流量支付溢价。
实用路由方案
干净的实现方式是在请求到达 Gemini 之前进行分类。
第一步：按业务重要性给每个请求打标签
一个简单的三级标签足以应对大多数团队：
background：可以等，可以重试，用户未被阻塞interactive：用户在等，但短暂的延迟可以接受critical：用户在等，失败或延迟代价高昂
第二步：把标签映射到 Gemini 服务层级
| 内部标签 | Gemini 层级 |
|---|---|
background |
flex |
interactive |
standard |
critical |
priority |
按任务重要性路由比按团队、功能名称或模型来路由更好。一个产品可以同时包含所有三种流量类型。
第三步：把重试和可观测性与层级选择分开
不要以为选了某个服务层级就可以省掉基本的生产运维。保持：
- 请求超时
- 幂等任务的重试规则
- 后台任务的队列恢复机制
- 延迟、失败率和降级率的监控面板
Priority 降低了风险，但不消除监控的必要性。
请求示例
Google 发布文章说明两个层级使用同样的同步接口，通过 service_tier 参数选择。这意味着集成改动可以很小。
Flex 请求：
{
"contents": [
{
"parts": [
{
"text": "Summarize these 200 support tickets into the top five repeated complaints."
}
]
}
],
"service_tier": "flex"
}
Priority 请求：
{
"contents": [
{
"parts": [
{
"text": "Draft a safe, concise reply for a customer whose payment failed during checkout."
}
]
}
],
"service_tier": "priority"
}
如果你已经把所有 Gemini 调用通过一个内部服务路由，最小的迁移路径通常是：
- 给每个请求加一个业务重要性字段
- 把该字段映射到
service_tier - 记录每个请求请求了哪个层级以及实际由哪个层级处理
第三步很重要，因为 Google 表示 Priority 溢出可以回退到 Standard。你应该监控这种情况何时发生，而不是假设每个关键请求都留在了 Priority。
合理的上线计划
不要一次性全部迁移。
先从 Flex 开始
Flex 是更容易的第一步，因为目标负载本来就是延迟容忍的。选一个非用户面向的工作流，比较：
- 每完成任务的成本
- p95 延迟
- 重试率
- 完成质量
如果工作流仍然满足你的内部阈值，就留在 Flex。如果质量可以接受但延迟太高，移回 Standard 而不是硬凑。
只在窄路径上添加 Priority
Priority 应该从少量明显的高价值路径开始，例如：
- 付费聊天会话
- 客服升级助手
- 审核或合规检查点
从窄路径开始，账单更可预测，降级监控也更容易。
常见错误
错误 1：对所有生产流量使用 Priority
超支是最容易踩的坑。有些生产请求对用户可见，但重要性不足以证明使用溢价路由的合理性。
错误 2：把 Flex 当成免费的质量提升
Google 对 Flex 的价值主张是更低的成本和同步的简洁性，而不是半价获取相同的可靠性。在更慢或不太可靠的响应可以接受的场景下使用它。
错误 3：按模型而不是按任务路由
同一个 Gemini 模型可能服务多种流量类型。层级选择应该反映业务重要性，而不是品牌偏好或内部团队归属。
错误 4：忘记项目资格要求
Google 表示 Priority 面向 Tier 2 和 Tier 3 付费项目。如果你的项目不满足该要求，就不应该设计一条依赖 Priority 可用的生产路径。
常见问题
Flex 和 Priority 取代了 Batch API 吗？
没有。Google 的发布框架是 Flex 减少了在标准同步流量和 Batch API 之间拆分架构的需要，但并不意味着 Batch 变得没用。对于可接受异步处理的大型离线作业，Batch 仍然有意义。
小团队应该立即使用 Flex 吗？
可以，如果他们已经有不需要立即返回结果的后台工作。当你之前在非紧急任务上为同步调用多付了钱时，Flex 最有吸引力。
Priority 是面向用户的应用的最佳默认选择吗？
不一定。对可靠性下降会造成真实业务损失的路径使用 Priority。对不需要溢价层级的较低重要性交互流量保持 Standard。
最简单的迁移路径是什么？
保持一套 Gemini 集成，加一个负载标签，映射到 service_tier，然后监控成本、延迟、重试和降级行为的指标。关于 Gemini 和其他 AI 平台的并排成本对比，参考我们的 AI 平台定价对比。
验证说明
2026-04-03 基于 Google 官方来源验证：
- 发布公告：Google，"Flex and Priority tiers in the Gemini API"（发布于 2026-04-02），说明 Flex 是新的同步成本优化层级，价格比 Standard 最高低 50%，Priority 溢出以 Standard 处理而非失败。
- Gemini API 定价文档：
https://ai.google.dev/gemini-api/docs/pricing，列出了支持模型的 Flex 和 Priority 定价部分。 - Gemini API 速率限制文档：
https://ai.google.dev/gemini-api/docs/rate-limits，描述了 Gemini 付费项目层级和 Priority 推理速率限制。