一句话结论：在英伟达联合德州大学奥斯汀分校等机构推出的 Realtime-Bench 上，12 款前沿模型按真实推理耗时推进环境时，最高任务成功率只有 44%，三次全部成功的比例只有 36%，实时交互仍是智能体落地最薄的一环。
基准论文的 arXiv 版本在 10 月 22 日更新到 v3，论文作者来自德州大学奥斯汀分校、俄亥俄州立大学、伊利诺伊大学厄巴纳-香槟分校、西北大学与 Steadyworks，英伟达研究团队参与。11 月 5 日，这套基准对外正式发布，随即成为各家模型在实时交互能力上第一次被放在同一把尺子下量。
基准怎么设计：50 个任务与三种时钟
Realtime-Bench 的出发点很直接。此前的实时流式模型评测集中在对话质量、流式感知和打断处理上，模型只要在静态环境里答对就算过关。而真实场景里更常见的失败是另一种：智能体看见了机会，但还没来得及动手，机会就没了。抢票、竞拍、限时操作都属于这一类。
任务集共 50 个，其中 30 个网页任务、20 个游戏任务。网页任务里有一个是在实时拍卖窗口关闭前出价成功，游戏任务是操控贪吃蛇连吃五个苹果。每个任务都配了自己的成功判定条件，时间窗口被刻意压到必须及时出手才能过线的程度。
观测采用每秒 1 帧的固定频率，截图之外叠加了一层只读的 Set-of-Marks 标注，把可交互元素和可用动作直接标出来，避免 GUI 定位能力成为评测瓶颈。动作空间是通用的桌面操作集合，点击、输入、滚动、等待都在内。环境时间最多走 5 分钟，到时未达成判定条件即算失败。
真正的设计核心是三套时钟协议，用来把推理延迟和模型本身的实时决策能力拆开看。
| 时钟协议 | 环境推进方式 | 考察目标 |
|---|---|---|
| Wall Clock | 按实际推理耗时推进 | 真实部署条件下的端到端表现 |
| Paused Clock | 推理期间环境冻结，延迟记为 0 | 去掉服务延迟的理想化上限 |
| Token Clock | 按动作提交前消耗的生成 token 数推进 | 剥离物理速度后的时间感知能力 |
Token Clock 是这套基准新引入的一层。模型思考越久、吐出的 token 越多，模拟时间就走得越远，动作落地时机会越差。它把时间成本标准化成 token 账单，从而单独检验模型是否知道自己还剩多少时间。论文里给了一个具体例子：token 预算设成每秒 64 个 token 时，一次 200 token 的回复落在拍卖最后 5 秒喊价之内，在贪吃蛇的单格回合窗口里却已经晚了 0.46 秒。
12 款模型榜单：GPT-6-Astra 44% 领跑，实时流式模型反而落后
Wall Clock 下的完整成绩如下，每款模型跑三轮，每轮 50 个任务，延迟取平均推理耗时。
| 模型 | 类型 | 第 1 轮 | 第 2 轮 | 第 3 轮 | Pass^3 | 平均延迟 |
|---|---|---|---|---|---|---|
| GPT-6-Astra（high） | 标准异步 | 42% | 42% | 44% | 36% | 3.99 秒 |
| GPT-6-Astra（low） | 标准异步 | 42% | 40% | 44% | 30% | 3.34 秒 |
| Gemini 3.8 Flash（low） | 标准异步 | 28% | 26% | 28% | 22% | 2.71 秒 |
| Gemini 3.8 Flash（high） | 标准异步 | 24% | 24% | 26% | 14% | 3.38 秒 |
| Claude Fable 5.1（low） | 标准异步 | 18% | 16% | 14% | 10% | 5.48 秒 |
| Claude Opus 5（low） | 标准异步 | 18% | 14% | 14% | 10% | 3.66 秒 |
| GPT-5.6 Sol（low） | 标准异步 | 16% | 14% | 24% | 6% | 4.49 秒 |
| GPT Realtime 2（low） | 实时流式 | 16% | 12% | 18% | 6% | 1.62 秒 |
| Gemini 3.1 Flash Live（low） | 实时流式 | 6% | 16% | 18% | 6% | 3.26 秒 |
| Claude Opus 5（high） | 标准异步 | 14% | 12% | 12% | 4% | 5.20 秒 |
| GPT-5.6 Sol（high） | 标准异步 | 8% | 10% | 14% | 4% | 5.74 秒 |
| DeepSeek V4.1 Flash（low） | 标准异步 | 8% | 10% | 8% | 4% | 3.42 秒 |
| Kimi K3（low） | 标准异步 | 18% | 12% | 10% | 4% | 4.98 秒 |
| Kimi K3（high） | 标准异步 | 6% | 8% | 6% | 2% | 7.17 秒 |
| Gemini 3.8 Live | 实时流式 | 8% | 4% | 6% | 2% | 3.26 秒 |
| OpenAI Decisions | 决策模型 | 8% | 12% | 8% | 4% | 1.13 秒 |
| Jev 1.13 | 决策模型 | 16% | 10% | 10% | 8% | 0.47 秒 |
Pass^3 衡量的是三次尝试全部成功的比例，对时效性场景来说这个指标比单轮通过率更有参考价值，因为它直接对应只有一次机会的现实处境。
榜单上有几个反直觉的地方。最显眼的低延迟模型 Jev 1.13 平均只花 0.47 秒，是全表最快的，但最高也只有 16% 的单轮通过率。延迟低不等于实时能力强，这两者之间隔着判断准不准。另一边，专为实时流式设计的 GPT Realtime 2 延迟只有 1.62 秒，最高通过率 16%，落后于标准异步的 GPT-6-Astra。
原因在论文里有交代：流式模型把算力摊到了逐帧的连续感知上，单次决策可用的推理深度反而更浅。实时不只是一项延迟指标，它需要感知、推理、动作三者的重新配比。
三种时钟对照：延迟是主因，但拆掉延迟也不能保证成功
论文挑选了 6 款模型在三种时钟、两种推理强度下交叉跑，共 6 组设置。Wall Clock 高低推理记作 WL 与 WH，Paused Clock 记作 PL 与 PH，Token Clock 记作 TL 与 TH。
token 速率消融实验给出了更细的结论。改变每秒 token 预算 B，看同一模型在不同时间压力下的成功率变化。
| 模型 | B=32 | B=64 | B=128 | B 无限 |
|---|---|---|---|---|
| Gemini 3.8 Flash | 56% | 54% | 58% | 60% |
| Claude Opus 5 | 30% | 44% | 56% | 62% |
| Kimi K3 | 22% | 24% | 58% | 60% |
| GPT-5.6 Sol | 26% | 34% | 32% | 42% |
| GPT-Realtime-2 | 8% | 22% | 18% | 16% |
| Gemini Live | 4% | 2% | 18% | 22% |
Claude Opus 5 从每秒 32 token 时的 30% 一路升到不限 token 时的 62%，Kimi K3 在 128 token 预算处出现 24% 到 58% 的跳升，时间压力对不同模型的影响量级差别很大。GPT-Realtime-2 与 Gemini Live 反而在预算放宽时出现回落，说明它们的问题不在思考时间，而在别处。
更关键的一条发现是，Paused Clock 下高分推理强度对 6 款模型全部有提升，但换到有真实时间压力的条件下就变成混合效果。同时，Token Clock 下相对 Paused Clock 仍然存在明显差距。这意味着一件事：即使物理服务速度足够快，模型本身的时间感知能力仍然是独立的一道坎。
失败的三种面孔
论文逐帧看了失败回放，把失败归成三类，这部分比分数更有信息量。
第一类是缺乏时间意识，记作 RT-Deliberate。模型不会根据紧迫程度调整思考长度。在五子棋任务里只剩 10 秒落子时，Gemini 3.8 Flash 在高推理强度下生成了 1845 个 token，相当于消耗掉 28.8 秒模拟时间，机会直接过期。论文的判断是，模型仍按题目静态难度分配思考量，没有把时间约束纳入预算。
第二类是跟不上环境状态变化，记作 RT-Perceive。在 Google Snake 里，Kimi K3 一直向左移动到 37 秒撞墙，而苹果就在它下方一格。论文认为这可能源于模型过度依赖文本上下文而不是画面变化，或者死守之前的解法。
第三类是误判该不该动手，记作 RT-Act。Claude Opus 5 在道路从第 6 秒开始塌陷之后，又等了大约 2 秒才转向离开。该动的时候不动，不该动的时候乱动，两头都错。
论文对下一阶段的判断是自适应推理。推理力度应该同时考虑任务难度和剩余可用时间，而不是一个固定档位。在俄罗斯方块里，方块还远的时候可以多比较几种摆法，接近堆叠时必须缩短思考把动作做完。同一个任务内部，合理思考量是会随时间变化的。
和现有基准的差别，以及对落地的含义
把 Realtime-Bench 放到站内的几套基准序列里看，位置比较清楚。
谷歌的 PLE 物理工程最后考试基准测的是工程交付的通过率，Claude Opus 5.5 拿到 41.3%；CloudOpsBench v1.0 测的是云运维任务解决率，Claude Fable 5.1 只有 60.6%；普林斯顿的 SSoN 空间基准测的是空间智能，人 83.3% 对大模型 39.7%。这几套的共同点是任务环境基本是静态的，答案对不对就结束，不需要模型跟时间赛跑。Realtime-Bench 把这一层补上了。
对做产品的团队来说，一个可操作的结论是：不要用静态基准的成绩去推断实时场景的表现。GPT-6-Astra 在这套实时基准上只有 44%，而在 BenchCAD 硬件设计任务上拿到 0.594 分、在 DeepSeek Super-agent 的 P95 延迟对比里也有不错表现，能力维度之间并不互相担保。
另一个结论是推理强度不能当成一个固定的性能旋钮。实时场景里把推理强度拉满有可能适得其反，Gemini 3.8 Flash 的 high 档在多数模型里反而低于 low 档，Kimi K3 的 high 档 6% 对 low 档 18%，差距明显。
常见问题
Realtime-Bench 测的是什么，和 Terminal-Bench 有什么区别
Terminal-Bench 衡量模型在真实终端环境里完成工程任务的能力，环境不会因为你思考太久而变化。Realtime-Bench 的环境持续演化，思考本身会消耗掉时间预算，超过窗口就直接失败。两者都是工程任务基准，但一个测能不能做对，一个测能不能赶得上。
为什么最高分只有 44%，是不是环境设置过难
论文对每个任务都做了人类可行性验证，并按场景调整了目标和时间约束。更能说明问题的是三种时钟的对照：在完全冻结环境的 Paused Clock 下，最强模型的通过率也只到六成出头，而 Token Clock 下相对 Paused 仍有差距。这说明瓶颈在模型的时间感知能力，而不是单纯把窗口收得太紧。
Pass^3 为什么比单轮通过率更值得看
单轮通过率里混着运气成分，一个模型偶然成功一次就会被计分。Pass^3 要求三次全部成功，衡量的是稳定性。实时场景常常只有一次机会，一次就够的稳定性指标更贴近实际。GPT-6-Astra 单轮最高 44%，Pass^3 掉到 36%，这 8 个点的落差就是不稳定带来的损失。
小结
Realtime-Bench 的价值在于把实时交互从模糊的体感变成了可复算的数字。12 款模型、50 个任务、三种时钟、8.8 万字符的失败归类，指向同一个结论：延迟只是表面原因，真正缺的是模型对自己还剩多少时间的判断。论文给出的方向是自适应推理与连续感知，两者都要在模型和承载框架两层同时动手。
相关阅读
- PLE 工程基准：Claude Opus 5.5 交付通过率仅 41.3%
- CloudOpsBench v1.0 榜单：Claude 云运维解决率仅 60.6%
- 普林斯顿 SSoN 空间基准：人类 83.3% 与大模型 39.7% 的差距
- GPT-6 Astra 一周设计出硬件：BenchCAD 得分 0.594
- VAST 开源 EdenLive：单卡 RTX 5090 跑出实时世界模型
延伸阅读
- 沙钢接入千问办公：单炉复盘 30 分钟压到 3 分钟6 天前
- JOLT 师生同模训练：MATH 72.14%，训练 token 省 6.5 倍2 周前
- GPU Unlock 解锁 RTX 30 系：3090 Ti BF16 算力提升 80%2 周前
- 腾讯QClaw 12月24日停运：一键迁移WorkBuddy，3月24日删数据4 周前
继续读
同一批更新里这几篇值得一看：
- Soniox STT v6 发布：60+ 语言语音识别与智能体回声消除2026-11-06
- 高通 HBC 验证完成：AI250 内存带宽 133 TB/s 与 18 倍对比2026-11-03
- OpenAI 重构 Model Spec：5 项核心价值与 4 层失配监控2026-10-30
想快速查定义？对应的词条在这里：
- AI Agent词条 · AI 自学笔记