Gemini 3.5 Pro 与 Gemini 3.5 Flash：发布前对比追踪
gemini-3.5-pro 或 gemini-3.5-flash。本页面是发布前的对比追踪，而非声称任一模型已经发布。最安全的准备方式是将 Google 已确认的信息与开发者可能希望在 Google 后续发布这些模型名称时评估的内容区分开来。在此之前，请使用当前的官方 Gemini 模型进行生产规划，并将 Gemini 3.5 Pro 与 Gemini 3.5 Flash 的对比视为一个关注主题。
摘要
- 截至 2026 年 5 月 18 日，已检查的 Google 官方文档中未列出 Gemini 3.5 Pro 和 Gemini 3.5 Flash。
- 这些名称没有已确认的官方 API 模型 ID、定价行、上下文窗口、速率限制或发布说明。
- 当前官方 Gemini 3 系列包括 Gemini 3.1 Pro、Gemini 3 Flash 和 Gemini 3.1 Flash-Lite 等模型。
- 在 Google 确认模型和定价之前，请勿发布诸如 "3.5 Pro 更适合编码" 或 "3.5 Flash 更便宜" 之类的固定声明。
- 如果 Google 发布了这两个名称，请按工作负载进行比较：每成功任务的成本、延迟、上下文行为、工具可靠性和回退率。
当前官方状态
| 项目 | Gemini 3.5 Pro | Gemini 3.5 Flash | 监控来源 |
|---|---|---|---|
| 官方发布 | 未确认 | 未确认 | Gemini API 发布说明 |
| API 模型 ID | 未确认 | 未确认 | Gemini API 模型列表 |
| 定价 | 未确认 | 未确认 | Gemini API 定价 |
| Vertex/Google 模型可用性 | 未确认 | 未确认 | Google Cloud 模型文档 |
| 上下文窗口 | 未确认 | 未确认 | 官方模型文档或模型卡片 |
| 工具和 Agent 支持 | 未确认 | 未确认 | 官方能力表 |
这意味着 Gemini 3.5 Pro 和 Gemini 3.5 Flash 之间的任何详细比较目前都是一个准备框架，而非官方产品对比。
Google 当前列出的替代模型
gemini-3.1-pro-preview 和 gemini-3.1-pro-preview-customtools。已检查的官方文档中未提供 Gemini 3.5 Pro 或 Gemini 3.5 Flash 的定价。从 SEO 和事实安全的角度，本文应针对发布追踪意图进行排名，而非声称是一个完整的 Pro 与 Flash 对比。
安全的对比框架
如果 Google 后续发布 Gemini 3.5 Pro 和 Gemini 3.5 Flash，开发者应使用实际的生产测量数据进行比较，而非根据名称进行推测。
| 维度 | Gemini 3.5 Pro 需要验证的内容 | Gemini 3.5 Flash 需要验证的内容 |
|---|---|---|
| 模型 ID | 确切的 API 字符串、预览或 GA 状态、渠道支持 | 确切的 API 字符串、预览或 GA 状态、渠道支持 |
| 定价 | 输入、输出、缓存、批量、弹性和优先级定价 | 输入、输出、缓存、批量、弹性和优先级定价 |
| 延迟 | 复杂任务的首 token 时间和完整生成时间 | 高并发任务的首 token 时间和完整生成时间 |
| 上下文 | 可用上下文窗口、输出限制、长上下文退化情况 | 可用上下文窗口以及短上下文任务是否保持稳定 |
| 工具调用 | Schema 遵循、工具错误恢复、规划质量 | 快速工具子步骤、提取可靠性、重试行为 |
| 实际成本 | 每成功复杂任务的成本 | 每成功高并发任务的成本 |
| 回退行为 | 配额、延迟或质量故障时的处理方式 | Flash 何时应升级到 Pro 或其他模型 |
此对比应仅在模型出现在官方文档中，或您自己的发布后基准测试数据可用后才进行更新。
发布后 Pro 可能更优的场景
如果 Google 发布 Gemini 3.5 Pro 模型，对于质量和推理深度比原始延迟更重要的工作负载，它可能值得优先评估。但不要仅凭名称假设这一点，需要实际测试。
复杂推理
评估多步骤问题求解、任务分解和推理密集型工作流。测量任务完成率、重试率和每成功任务的成本。
编码 Agent
对于编码 Agent，请测试真实的代码仓库任务，而非短代码片段。追踪差异质量、工具调用可靠性、多文件上下文处理能力，以及模型是否能以更少的重试次数完成工作。
长上下文分析
首先检查官方上下文窗口。然后在实际的上下文长度下测试检索准确性、指令保持度和输出质量，包括您的产品实际使用的 token 范围。
高价值请求
对于战略、金融、法律、医疗或企业支持场景，请添加人工审核和安全检查。未来的 Pro 模型可能有助于提升质量，但不应单独替代领域安全措施。
发布后 Flash 可能更优的场景
如果 Google 发布 Gemini 3.5 Flash 模型，对于速度、规模和成本控制比最大推理深度更重要的工作负载，它可能值得优先评估。同样，请等待官方定价并测试实际模型。
低延迟产品流程
测量聊天自动补全、交互式助手、建议和短回复的首 token 时间和端到端延迟。
高并发任务
对于分类、提取、格式化、短摘要和路由决策，请计算每成功任务的成本，而非仅比较 token 价格。
Agent 子步骤
许多 Agent 工作流包含较小的步骤，如参数提取、输出格式化和状态摘要。Flash 模型只有在可靠性足够高、不会导致昂贵重试的情况下，才对这些步骤有用。
为什么路由通常优于固定选择
生产系统很少只有一种工作负载。一个典型的应用包含短请求、长请求、简单转换、困难推理任务、延迟敏感流程和高价值用户操作。静态的纯 Pro 或纯 Flash 配置通常会在成本或质量上有所损失。
| 工作负载 | 发布后更安全的初始路由 | 升级或回退信号 |
|---|---|---|
| 分类 | Flash 候选 | 置信度或准确率下降时升级 |
| 短摘要 | Flash 候选 | 长文档或含糊文档时升级 |
| 复杂分析 | Pro 候选 | 延迟、配额或错误率飙升时回退 |
| 编码 Agent 规划 | Pro 候选 | 与其他编码专用模型进行比较 |
| 工具参数提取 | Flash 候选 | 反复出现 Schema 失败时升级 |
| 长上下文审查 | Pro 候选 | 先验证上下文成本和准确性 |
| 高风险回答 | Pro 加安全措施 | 添加人工审核或多模型验证 |
正确的生产问题不是 "永远选 Pro 还是 Flash？" 而是 "在当前的延迟、成本、质量和可靠性约束下，哪个模型应该处理这个请求？"
成本：不要仅比较 Token 价格
一个更便宜的模型如果产生更多的重试、失败会话、回退或人工审核，可能反而更贵。一个更昂贵的模型如果能以更少的尝试完成特定工作流的任务，可能反而更便宜。
在得出结论之前，请追踪以下指标：
| 指标 | 重要原因 |
|---|---|
| 输入 token | 长提示会放大成本差异 |
| 输出 token | Agent 和聊天工作流可能生成大量输出 |
| 重试率 | 失败的尝试会倍增实际支出 |
| 回退率 | 频繁升级会改变混合成本 |
| 延迟 | 慢响应会损害产品体验和吞吐量 |
| 任务成功率 | 每成功任务的成本才是有用的生产指标 |
避免使用虚假价格发布发布前的示例。一旦 Google 发布官方定价，请使用有来源的计算更新本文。
如何在 Gemini 3.5 发布前做好准备
将模型 ID 保存在配置中
gemini-3.5-pro 或 gemini-3.5-flash。将模型 ID 和路由规则存储在配置中，这样新模型可以在不重写应用代码的情况下进行测试。记录工作负载结果
记录模型 ID、输入 token、输出 token、延迟、错误率、重试次数、回退次数和最终任务结果。这使得新模型在发布后能够快速评估。
设计回退路径
为模型不可用、配额限制、延迟尖峰和质量退化做好规划。健壮的模型层应该能够绕过故障进行路由，而不是将单一模型视为永久依赖。
将发布追踪与建议分开
在发布之前，撰写已确认的信息和需要关注的内容。发布之后，用官方定价、API ID、能力和经过验证的生产建议更新本文。
使用 EvoLink 进行 Pro 和 Flash 评估
EvoLink 提供统一的 API 层，用于比较和管理多个模型系列。对于关注未来 Gemini 模型的团队，这可以减少集成开销，并更轻松地跨提供商测试模型路由、回退行为和工作负载级别的成本。
一旦 Gemini 3.5 Pro 或 Gemini 3.5 Flash 出现在支持的上游渠道中，本页面将更新确切的模型 ID、定价说明、可用性详情和路由示例。
相关文章
- Gemini 3.5 Pro API 发布追踪 - 继续查看同组发布追踪
- Gemini 3.5 Flash API 发布追踪 - 继续查看同组发布追踪
需要监控的官方来源
常见问题
Gemini 3.5 Pro 和 Gemini 3.5 Flash 是否已在 API 中可用？
gemini-3.5-pro 或 gemini-3.5-flash。Gemini 3.5 Flash 比 Gemini 3.5 Pro 更便宜吗？
这一点尚未确认。已检查的官方文档中没有这两个模型名称的定价行。如果两者都发布了，请比较官方 token 定价和实际生产指标，如重试率、回退率、延迟和每成功任务的成本。
哪个更适合编码 Agent？
这一点尚未确认。如果未来的 Pro 模型发布，它可能是编码 Agent 规划和复杂代码仓库任务的候选者，但这必须通过真实的编码工作负载和官方能力详情来验证。
开发者应该为两个模型都做准备吗？
开发者可以通过使模型选择可配置、记录工作负载结果和设计回退路径来安全地做好准备。他们不应依赖推测性模型 ID 或在官方发布详情出来之前发布固定建议。
发布后应该更新什么？
更新本文的确切发布日期、模型 ID、API 渠道、定价、上下文窗口、速率限制、能力表，以及来自真实工作负载的经过验证的对比结果。
