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