英伟达Realtime-Bench实测：GPT-6-Astra实时任务成功率仅44%

网页结构再复杂，大模型也看得懂；游戏规则再绕，它们也能理清。

可要是换成稍纵即逝的抢票窗口，或者在俄罗斯方块里赶在方块落地前完成旋转、移动，它们还顶得住吗？

英伟达和 UT-Austin 等机构的研究人员为此提出了 Realtime-Bench，专门测模型的实时能力，12 种前沿模型都上了考场。环境实时推进的情况下，成绩最好的 GPT-6-Astra 任务成功率也只有 44%。

• 论文标题：Realtime-Bench: Can Frontier Models Solve Real-Time Interactive Problems?

• 论文链接：https://arxiv.org/abs/2610.22155

• 项目主页：https://realtimeagents.org

• Huggingface paper: https://huggingface.co/papers/2610.22155

实时交互中，世界不会等待模型

抢票时，模型得盯住不断变化的界面，在有限时间内做出决策并完成操作。这类实时交互任务对模型有三项核心能力要求：

• 1. RT-Perceive：看环境怎么变。眼下是什么状态、手上的信息有没有过期、还有没有出手的机会，都得先判断清楚。

• 2. RT-Deliberate：按时间调整推理。还能想多久、接着想下去值不值，是这一步要定的事。

• 3. RT-Act：抓住动手的火候。该再等等还是马上操作，以及选一个执行时依然有效的动作。

模型得先发现放票，再根据购买窗口剩下多少时间来决定思考多久，然后及时下单。哪个环节掉链子，机会都可能溜走。

围绕这些能力，Realtime-Bench 把模型置入持续变化的环境，看它能不能在时间约束下完成观察、推理和行动。

行动早晚会改变结果

Realtime-Bench 的任务有两个共同点：环境随时间自己变，达成目标的机会又有时间限制。

操作本身没错，但做得太早或太晚，任务照样可能失败。

如下图所示，实时拍卖里，模型要在倒计时归零前出价，还得应付对手随时加价；贪吃蛇里，蛇一直在往前爬，模型必须及时转弯才吃得到苹果。

Realtime-Bench 的 30 个网页任务和 20 个游戏任务都带着这类时机要求，场景覆盖出行、电商、服务、安全，以及街机、解谜、策略和模拟共八类。

模型推理的时候，环境时间到底怎么往前走？Realtime-Bench 设了 3 种推进方式来做对比。

Wall Clock 按推理实际耗费的时间推进：模型生成响应用了多久，环境就往前走多久。Paused Clock 则等模型推理结束才推进，推理期间环境状态是冻结的，这种方式被当作理想化对照，用来分清模型失败是因为推理能力不够，还是被时间卡住。Token Clock 按模型生成的 token 数推进时间，token 出得越多，行动执行得越晚；它排除了 API 服务延迟的干扰，方便观察模型自身的实时能力。

图 3：Realtime-Bench 用三种时钟协议评估模型的实时交互能力。Wall Clock 依据实际推理耗时推进环境；Paused Clock 在推理期间让环境暂停；Token Clock 按生成的 token 数推进模拟时间，把实际服务速度的影响排除在外，考察模型的时间感知。

实验结果：放到真实时间里，模型依然难以完成实时任务。

Realtime-Bench 一共测试了 12 个前沿模型，分三类。标准异步模型有 GPT-6 Astra、GPT-5.6 Sol、Claude Fable 5.1、Claude Opus 5、Gemini 3.8 Flash、DeepSeek V4.1 Flash 和 Kimi-K3；实时流式模型是专门为实时交互优化延迟的一批大语言模型，包括 GPT-Realtime-2、Gemini 3.1 Flash live 和 Gemini 3.8 Live；决策模型只输出决策、不输出自由文本，主打低延迟，包括 OpenAI Decisions 和 Jev 1.13。

实时交互讲究稳定性，失败一次就没有重来的机会，比如抢票失败后没法再试一遍。因此 Reatime-Bench 把 Pass^3 当作主要指标。Pass^3 指同一任务重复测试三次全部成功的概率，用来衡量模型在实时任务上的可靠性。

环境按实际推理延迟推进（Wall Clock）时，表现最好的 GPT-6 Astra 在高推理强度下 Pass^3 也只有 36%。大多数模型的延迟超过 1 秒；Jev 虽然把延迟压到了 1 秒以内，Pass^3 却只有 8%。

这说明低延迟本身并不足以保证可靠的实时表现。模型既得及时响应，也得有完成任务所需的推理能力。

图 4：12 个前沿模型在 Realtime-Bench 上的表现

把推理强度调高，实时任务的成功率就一定会涨吗？答案并不乐观。

在 Paused Clock 模式下，推理不占用环境时间，情况则不同：六个模型成功率全部走高。GPT-5.6 Sol 由 42% 升到 58%，Claude Opus 5 从 62% 涨到 70%。

可一旦环境在模型思考时继续变化，推理加码的效果就分模型了。Token Clock 下，Claude Opus 5 的成功率由 44% 滑到 30%，Kimi-K3 反而从 24% 升到 36%。Wall Clock 下同样有分化：GPT-5.6 Sol 从 16% 掉到 8%，Gemini 3.1 Flash Live 则从 6% 升到 8%。

可见实时任务里的推理存在取舍：多想一会儿，模型或许能挑出更合适的动作，但也可能把动手的时机耽误掉。

压缩推理造成的行动延迟，有效果，但效果有限。

推理长度不变、耗时缩短，成功率会不会上去？研究团队在 Token Clock 下做了调整：每秒模拟时间对应的生成 token 数从 32 依次提到 64、128，最后把生成过程的时间开销彻底去掉。这样生成同样多的 token，行动前的模拟延迟被一步步压缩。

从整体结果看，时间限制放宽对成功率有拉动。每秒对应 32 个 token 时到完全去掉推理时间开销，Claude Opus 5 的成功率由 30% 升到 62%，Kimi-K3 由 22% 升到 60%。

不过成功率并非对每个模型都随延迟缩短一路走高。即便推理不再占用环境时间，仍有大量任务做不完。延迟降下来有帮助，可实时交互里的难题并未因此全部化解。

Realtime-Bench 中的任务，要求模型看清正在变化的状态，再结合还剩多少时间决定思考时长，同时判断什么时候该等、什么时候该动手。往后模型得把这些环节协调得更灵活：时间宽裕就多比较几种方案，窗口快关上就赶紧出手，新信息一到就改掉已经过时的计划。