实时AI决策模型基准实测：延迟如何决定胜负

在实时AI应用里，一个模型即使做出更多正确决策，也未必是更好的选择——因为它可能更慢。Hopsworks团队用一款受《地铁跑酷》（Subway Surfers）启发的电脑游戏，对三款预训练「决策」模型（本质上是分类器）进行了基准测试，结果揭示了实时AI系统中一个常被忽视的核心问题：延迟。

测试设置：一场比模型更快的游戏

这个基准测试的核心思路很直接——要在游戏中跑得更远，你必须更快地做出正确决策。游戏中的奔跑者面对随机生成的障碍物，这些障碍从预设的距离节点开始出现。每个模型接收相同的底层游戏状态，并按各自接口格式化：

{ lane, airborne, ahead }

其中 ahead 字段描述前方的行、它们的距离，以及每条赛道上的障碍。模型必须在奔跑者到达之前决定如何行动。

奔跑者初始速度为 45 m/s，每秒加速 1.6 m/s，最高可达 160 m/s。一旦超过约 5,000 米，游戏会变得极其严苛，生存越来越依赖运气。换句话说，速度越快，留给模型反应的时间窗口越窄——这正是检验实时决策能力的残酷舞台。

三款模型的成绩对比

测试对象是三款预训练决策模型：Kumo、Jev 和 Qwen。成绩如下：

模型	运行次数	平均距离	中位距离	最佳成绩
Kumo	500	2,119 m	—	—
Qwen	500	1,318 m	—	—
Jev	30	—	540 m	1,417 m

Kumo 以 2,119 米的平均距离明显领先，Qwen 次之，达到 1,318 米。而 Jev 在 30 次运行中中位数仅为 540 米，最佳成绩 1,417 米。

值得强调的是部署方式的差异：Kumo 和 Qwen 是本地模型，托管在 Hopsworks 上，游戏也在同一环境运行；而 Jev 是托管在另一个数据中心的远程模型。这一部署差异，成了决定成绩的关键变量。

为什么 Kumo 赢了

Kumo 胜出的原因并不神秘：它在保持良好决策质量的同时，实现了更低的决策延迟和更低的网络延迟。与同样运行在 CPU 上的 Qwen 相比，Kumo 能跑出更高的平均距离。

一个自然的疑问是：换用 GPU 会不会更好？团队给出的回答是「可能会」，但对于小型、延迟敏感的请求，额外的基础设施开销可能抵消算力带来的收益。这仍是一个有待验证的假设。这个判断其实点出了实时推理的一个反直觉之处——更强的硬件未必带来更快的端到端响应，因为调度、传输与冷启动等开销同样计入延迟账本。

CPU 推理在小型模型上有时反而优于 GPU，原因在于 GPU 的延迟构成更复杂：数据需要先从主机内存拷贝到显存（Host-to-Device transfer），CUDA 核函数的启动本身也有固定开销（kernel launch latency），再加上批处理调度带来的排队等待。对于参数量较小、单次推理计算量有限的分类器，这些固定开销占总延迟的比例很高，导致 GPU 的吞吐量优势无法转化为单请求的低延迟优势。相比之下，CPU 推理路径更短、调度更直接，在「每次只处理一个请求、且对响应时间极度敏感」的场景下往往表现更稳定。这与大批量推理（batch inference）场景形成鲜明对比——后者 GPU 的并行优势才能得到充分发挥。

Jev 为何掉队：延迟吃掉了决策

Jev 的瓶颈非常清晰——200 毫秒以上的往返延迟。在约 1,500 米处，游戏速度已经快到让这些响应失去意义。

做一道简单的算术就能理解问题所在：在最高速度 160 m/s 下，200 毫秒意味着奔跑者在等待决策的过程中已经移动了约 32 米。决策再正确，等它到达时，游戏局面早已改变。这正是远程托管模型在实时场景中的致命伤——物理距离与网络往返构成了无法绕过的硬性延迟下限。

网络往返时延（Round-Trip Time，RTT）由多段延迟叠加而成：请求从客户端出发，经过本地网络、互联网骨干链路、目标数据中心入口，到达推理服务器完成计算后，再沿原路返回。即便服务器端的模型推理本身只需几毫秒，跨数据中心的物理光速传播延迟（通常每1000公里约5ms单程）、TCP握手与拥塞控制、以及云服务商的负载均衡层，都会将总 RTT 推高到数十乃至数百毫秒。这就是为什么「就近部署」（co-location）是实时推理的黄金原则——将模型与调用方部署在同一机房甚至同一进程内，可以将网络延迟从「跨城市级」压缩到「微秒级」，从根本上改变延迟量级。

给实时AI的启示：以反应截止时间为标尺

这次测试给出的最大教训是：评估实时AI模型时，不能只看决策质量，而要评估整个决策闭环。团队总结出三个维度：

• 决策质量：它是否选择了正确的行动？
• 端到端延迟：这个行动是否能及时抵达？
• 部署适配性：你的基础设施能否同时支撑前两者？

一个只在准确率上领先、却无法在截止时间内返回结果的模型，在实时系统中毫无价值。延迟不是一个可以事后优化的次要指标，而应作为选型的第一性约束。

整个基准测试——包括所有模型和游戏——都运行在 Hopsworks 自有的办公室基础设施上，完全自托管，没有任何游戏数据流向云端。这种设置本身也呼应了实时与数据隐私场景的常见诉求。

在这个特定基准中，Kumo 是最强表现者。但更广义的结论是：请始终以你自己应用的「反应截止时间」为标尺来评测模型，而不是迷信通用排行榜上的分数。

注：本文基于单一来源（Reddit 发帖）的测试数据，测试规模有限（Jev 仅 30 次运行），部署环境也存在差异，结论应谨慎看待。