在 OrcaRouter 上对 Google: Nano Banana Pro (Gemini 3 Pro Image Preview)（google）与 Google: Gemini 3.1 Pro Preview（google）进行正面对比——定价、上下文窗口、延迟、吞吐和 benchmark 质量并排呈现，助你为工作负载选对模型。
| 指标 | Google: Nano Banana Pro (Gemini 3 Pro Image Preview) | Google: Gemini 3.1 Pro Preview | 结论 |
|---|---|---|---|
| 输入 $/百万 | — | $2.00 | — |
| 输出 $/百万 | — | $12.00 | — |
| 上下文 | 66K | 1M | Google: Gemini 3.1 Pro Preview 支持的上下文窗口比 Google: Nano Banana Pro (Gemini 3 Pro Image Preview) 大 94%。 |
| p50 延迟 | 4290 ms | 6470 ms | 在中位数下，Google: Nano Banana Pro (Gemini 3 Pro Image Preview) 的响应比 Google: Gemini 3.1 Pro Preview 快 34%。 |
| 吞吐 | — | 751 tok/s | — |
| 质量 | 5.0 | 10.0 | 在综合质量指数上，Google: Gemini 3.1 Pro Preview 比 Google: Nano Banana Pro (Gemini 3 Pro Image Preview) 高 50%。 |
对于延迟敏感的工作负载，Google: Nano Banana Pro (Gemini 3 Pro Image Preview) 能更快返回首个 token。 在 benchmark 质量上，Google: Gemini 3.1 Pro Preview 在综合指数上领先。
Google: Nano Banana Pro (Gemini 3 Pro Image Preview) 和 Google: Gemini 3.1 Pro Preview 都通过同一个 OrcaRouter 端点提供,按供应商成本计费、零 token 加价,因此在两者之间切换只需改一行代码,下面的数字就是你实际支付的费用。本对比拉取了实时定价、官方公布的上下文窗口,以及 OrcaRouter 自己测得的延迟和吞吐数据,让你能针对自己的具体工作负载权衡成本与性能,而不是依赖厂商标榜的 benchmark。正确的选择几乎总是取决于你流量的形状——提示长度、你生成多少文本、你的用户对延迟有多敏感,以及推理有多难——因此下面的章节会逐个维度拆解这个决策,并以一条具体建议收尾。凡是两个模型中有一方缺少某项指标,该行会直接省略而不是猜测,所以这里的每一条论断都有真实数字支撑。
这两个模型中有一个或两个在此处未公开按 token 计费的价格(可能是免费档、按调用计费或尚未定价的模型),因此请将成本列视为参考值,在据此做预算前,先到各模型自己的页面确认实时费率。
Google: Nano Banana Pro (Gemini 3 Pro Image Preview) 最多接受 66K 个 token 的上下文,Google: Gemini 3.1 Pro Preview 接受 1M。上下文窗口决定了单次请求中你能发送多少源材料——文档、代码、先前的对话。更大的窗口让你在处理长输入时可以省去分块和检索的工程管道,但你发送的所有内容仍按输入 token 费率收费,所以更大的窗口是一种能力,而不是折扣。请让窗口匹配你的工作负载实际会产生的最长单次请求,而不是页面上最大的那个数字。还要记住,在任何模型上,当上下文非常长时,末尾部分的质量都可能下降,因此大窗口最好被当作应对偶尔出现的长输入的余量,而不是把每个请求都塞到上限的许可证。
延迟和吞吐决定了模型在生产环境中的实际体感。中位数(p50)响应延迟是典型请求在首个 token 出现前的等待时长;吞吐(每秒 token 数)决定回答开始后的流式速度。对于交互式对话和 agent 循环,低 p50 延迟最重要,因为用户在等待首个 token;对于批量生成和长文本输出,吞吐主导整体耗时,因为回答很长。上方的 7 天趋势图显示了每个模型的延迟是稳定还是漂移,这是单一标榜数字所掩盖的——一个均值很好但尾部抖动的模型,仍可能达不到严格的 p95 SLA。如果你的产品有延迟预算,就要同时看中位数和曲线的形状,并记住端到端延迟还包含你的网络跳转,以及你围绕模型所做的任何检索或工具调用。
Benchmark 分数近似地反映能力,但不能替代在你自己的提示上进行测试。此处显示的综合质量指数汇总了多项公开评测,百分位则标出每个模型在目录中所有可比模型里的位置——这是一个有用的入围信号,而不是对你任务效果的保证。在通用智能指数上领先的模型,在你的领域(编码、抽取、多语言、长上下文推理)上仍可能落后,因此请用这些 benchmark 缩小范围,再让两个模型在你流量的代表性切片上实际跑一跑。请关注与你用例相匹配的那个具体指数,而不是总榜数字:编码密集的产品应看重编码指数,研究助手则看重推理指数。Benchmark 也会随着模型更新而过时,因此请把它们当作一个起始假设,再用你自己的评测集去确认。
如果成本是硬约束,先按你真实的输入/输出比例选用更便宜的模型,只有在质量不达标时才升级。如果响应速度是优先项——面向用户的对话、agent、任何有人在等待的场景——就把 p50 延迟和吞吐看得比小幅价差更重。如果你要做最吃力的推理、编码或长上下文工作,就让 benchmark 和上下文窗口的赢家领头,并在物有所值处接受更高的费率。由于两个模型都在同一套 API 之后,低风险的做法是把一小部分真实流量分别路由给两者,在你自己的提示上对比成本、延迟和回答质量,再做最终决定。一种常见做法是分层(tier):把大量简单、高频的请求发给更便宜或更快的模型,把更强的模型留给真正需要它的请求,这样能以一小部分成本拿到大部分的质量收益。无论选哪个,都要让切换保持可逆——只需一行模型名称的改动,一旦数字或你的需求发生变化,你就能立刻把流量切回去。
在过去 7 天里，Google: Nano Banana Pro (Gemini 3 Pro Image Preview) 保持更低的中位响应延迟。
在社区正面对决赛中，Google: Gemini 3.1 Pro Preview 拥有更高的 Elo 评分（1346 对 1283），这意味着它在与同类模型的直接对决中胜率更高。