你在赛车游戏里按下左转，通常是游戏引擎按预先写好的规则计算车辆会去哪里。Neural Drive 换了一种做法：它看最近 7 帧画面，再结合你的操作，直接生成下一帧。车会不会转、赛道怎样向前展开，都由模型预测，而不是由底层游戏引擎计算。更值得注意的是，这套 SuperTuxKart 世界模型被装进了浏览器，并在访问者自己的 GPU 上运行。
这里的“世界模型”，指学习环境如何随动作变化、进而预测未来状态的模型。它更像一个可以操控的生成式模拟器，不追求像传统游戏引擎那样严格执行物理和场景规则。本专题的技术细节与效果描述均来自项目发布方的 Hugging Face 模型卡，目前没有独立测试数据。
它怎样把赛车“想”出来？
Neural Drive 接收两类信息：过去 7 帧，以及玩家当前的控制。控制共有 6 项，包括加速、刹车、左转、右转、氮气和漂移。这叫“动作条件生成”——模型不只是顺着旧画面续写视频，玩家按下什么，也会改变它接下来生成什么。
模型输出的画面分辨率是 384×192。为了减少计算，它不会直接在所有像素上推演。ConvVAE 编解码器先把画面压缩到“潜空间”——也就是更小的内部表示；LatentDiT 动力学模型再在这个压缩空间里预测变化，最后由解码器还原成画面。可以把它理解成：先用一份紧凑的赛道速记推演下一刻，再把速记展开成完整图像。
发布方列出的 LatentDiT 配置为 12 层、维度 768，参数量 130.8M。这个数字看起来只对应动力学模型，不是整个系统的总参数量。它采用 rectified flow 和 per-frame diffusion forcing：前者学习怎样把噪声逐步推向目标画面，后者把逐帧生成纳入训练。浏览器版本还使用了少步蒸馏。所谓“蒸馏”，就是让较小或更快的学生模型模仿教师模型；这里教师版本使用 8 步采样，学生版本把过程压到 2 步，以减少每生成一帧所需的计算。
浏览器不只是播放器
演示通过 WebGPU 运行。WebGPU 是浏览器调用本机 GPU 做通用计算和图形处理的接口，因此模型不必把每次操作都送到云端，也不要求用户安装单独的应用。
浏览器使用的单图帧生成器约 262 MB，采用 ONNX 格式和 fp16 精度。ONNX 是便于模型跨运行环境部署的格式；fp16 则用较少位数表示参数，通常可以降低存储和计算负担。模型会先填入一次 7 帧上下文，随后在同一计算图中完成两步去噪，并使用 KV-cache——保存先前计算中间结果的“草稿纸”，避免每一帧都从头处理全部历史。
项目还准备了 18 组出生点上下文，每组都包含 7 帧压缩状态。它们相当于模型开始生成前的不同起跑记忆。训练在 PyTorch 中完成，动作数据从游戏过程自动提取。发布方称 PyTorch 与浏览器运行时来自同一套权重；更谨慎地说，它们应是同一模型参数的不同导出或精度版本，因为 PyTorch 检查点标为 fp32，网页生成器标为 fp16，而 VAE 解码器又保留 fp32。
为什么值得现在看？
有意思的不是“AI 也能画赛车”，而是生成、控制和本地运行被放进了同一个网页演示。普通生成视频通常由提示词一次性决定内容；Neural Drive 则持续接收方向和速度相关操作，让生成结果成为一个可以反复干预的过程。浏览器也不再只是播放模型预先做好的内容，而成了模型实际推演世界的运行环境。
这展示了一条不同于传统游戏的路径：交互场景未必全部来自人工编写的规则，也可以由模型根据近期画面和人的动作逐帧预测。它仍是实验，而不是游戏引擎的成熟替代品，但已经把世界模型从离线视频样例推进到可亲手操控的浏览器界面。
局限与未知
- 模型卡没有提供实测帧率、操作延迟、显存需求、画质指标或基线比较，因此不能据此判断它是否流畅、性能是否领先。
- “在浏览器运行”仍取决于浏览器、操作系统和 GPU 对 WebGPU 的支持，不能理解为所有设备都能使用。
- 发布页称模型训练自 gameplay，同时引用了题为“from Mobile Gameplay Videos”的相关工作，但两者的关系和具体训练数据来源没有交代清楚。