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