大模型能看懂复杂的网页结构，也能理解各种游戏的通关规则。
但如果让它们在稍纵即逝的窗口期内抢购一张热门门票，或者在俄罗斯方块游戏中，赶在方块落地前完成旋转和移动，它们还能应对自如吗？
为了测试模型的实时能力，英伟达和 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 的任务都具有两个特点：环境会随着时间自行变化，而完成目标的机会存在时间限制。
即使操作正确，执行得太早或太晚，也可能导致任务失败。
如下图所示，在实时拍卖中，模型要在倒计时结束前出价，还要应对对手随时加价；在贪吃蛇中，蛇会持续前进，模型必须及时转弯，才能吃到苹果。
图 1：Realtime-Bench 的典型任务示例
Realtime-Bench 的 30 个网页任务和 20 个游戏任务都包含这类时机要求，覆盖出行、电商、服务、安全，以及街机、解谜、策略和模拟等八类场景。
图 2：Realtime-Bench 的任务分布
模型推理时，环境的时间怎么算
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 上的表现
提高推理强度，未必能提高实时任务的成功率
图 5：三种时钟协议下的任务成功率。
在 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%。
并非所有模型的成功率都会随延迟缩短而持续上升。即使推理不再消耗环境时间，仍有不少任务无法完成。 降低延迟有帮助，但还不足以解决实时交互中的全部困难。
图 6：时间压力对任务成功率的影响
Realtime-Bench 里的任务要求模型识别正在变化的状态，根据剩余时间决定思考多久，并判断何时等待、何时行动。未来的模型需要更灵活地协调这些环节：时间充足时比较方案，窗口即将关闭时尽快行动，新信息到来后及时修正过时的计划。
作者简介：
Realtime-Bench 是由顶尖高校与科技企业共同打造合作项目。该基准测试由得克萨斯大学奥斯汀分校（UT Austin）、西北大学（Northwestern）、俄亥俄州立大学（OSU）、伊利诺伊大学厄巴纳-香槟分校（UIUC）联合英伟达（NVIDIA）与 Steadyworks 共同研发。核心研究团队包括：来自 UT Austin 的博士生 Jingyu Tang、硕士生 Xu Yang 及助理教授 Jiaxin Pei；西北大学的 Manling Li；OSU 的 Zhehao Zhang；UIUC 的 Zheng Wang 与 Haozhe Zhao；以及来自工业界的 NVIDIA 研究员 Qi Cheng 和 Steadyworks 的 Wenxuan Li 与 Xide Xia。
