34B世界模型塞进一张5090

昆仑万维旗下Skywork AI近日发布Matrix-Game 4.0，把一套34B参数的实时游戏世界模型部署到了单张NVIDIA GeForce RTX 5090上。按照团队披露的数据，这套系统能够以480p分辨率输出60 FPS画面，按键到画面反馈的端到端延迟约为112ms，运行时峰值显存占用约18.5GiB。

世界模型是能够根据当前环境状态和用户动作，持续预测并生成后续世界变化的模型。 与一次性生成一段视频不同，世界模型必须处理连续输入：玩家向左移动，镜头和场景要随之改变；玩家拾取盾牌，之后受到攻击时就应先扣除盾牌耐久；玩家返回刚刚离开的区域，建筑、车辆和角色不能凭空换位。

Matrix-Game 4.0最有价值的地方并不是“房间秒变草原、抬手就能下雪”这类视觉演示，而是它试图把生成式画面、确定性游戏规则和消费级硬件放进同一条实时链路。过去的世界模型经常更像可以操控的视频，Matrix-Game 4.0则开始接近一套真正可运行的游戏系统。

关键变化不是画质，而是单卡运行

Matrix-Game 4.0把世界模型的部署门槛从数据中心级GPU集群压到了桌面工作站。RTX 5090拥有32GB GDDR7显存，虽然功耗、体积和价格都不算亲民，但它仍是一张可以买到并安装在个人电脑里的消费级显卡，而不是需要专用服务器、液冷机柜和高速互联的GB200集群。

公开信息显示，Matrix-Game 4.0的主要运行指标如下：

| 指标 | Matrix-Game 4.0公开数据 | 实际含义 | |---|---:|---| | 模型规模 | 34B参数 | 属于大型视频生成模型量级 | | 部署硬件 | 1张RTX 5090 | 32GB消费级显存 | | 峰值显存占用 | 约18.5GiB | 显存仍留有一定余量 | | 输出分辨率 | 480p | 优先满足实时性，而非高画质 | | 输出帧率 | 60 FPS | 系统输出或播放吞吐达到实时游戏标准 | | 端到端延迟 | 约112ms | 从玩家操作到对应画面显示 | | 规则执行 | 游戏引擎和代码 | 血量、碰撞、任务等不由视频模型猜测 | | 画面生成 | 视频世界模型 | 负责材质、光照、环境和连续视觉呈现 |

单看480p，Matrix-Game 4.0的画面规格并不会让传统游戏引擎紧张。现代游戏在RTX 5090上追求的是4K、高刷新率和光线追踪，而Matrix-Game 4.0仍处在较低分辨率阶段；它真正证明的是，数百亿参数的视频模型已经可以进入交互式延迟区间。

实时生成是指系统能够在用户可接受的等待时间内，根据连续操作生成后续画面。 对游戏而言，实时不能只看FPS，因为帧率衡量的是单位时间内显示多少帧，交互延迟衡量的则是用户操作多久后真正生效。

112ms延迟与60 FPS并不矛盾。系统可以先生成一个包含多帧的视频块，再以60 FPS连续播放，因此画面看起来流畅，但玩家按键仍可能在约7个显示帧之后才反映到屏幕上。对于快节奏射击游戏，112ms仍然明显高于传统本地渲染；对于探索、模拟、互动叙事和内容原型，它已经跨过“可以操作”的门槛。

模型不再负责记住一切

Matrix-Game 4.0的核心选择是让游戏引擎维护真实状态，让视频模型负责把状态画出来。团队把这套分工称为给视频模型加上Harness，也就是用外部程序约束模型的输入、状态和输出，而不是要求神经网络独自承担整个世界。

显式世界状态是由代码记录并可直接读取的角色、物体、规则和事件数据。 例如盾牌剩余30点耐久、角色生命值为80、车辆位于某个坐标、任务还剩45秒，这些数据可以精确更新，也可以稳定保存。

纯视频世界模型通常把状态隐含在历史画面或内部特征中。它可能从画面判断玩家捡到了盾牌，但经过几十秒移动和镜头切换后，这段信息可能逐渐丢失；它也可能生成一扇视觉上像门的物体，却无法保证这扇门具有稳定碰撞体、钥匙条件和开关状态。

Matrix-Game 4.0把这部分工作交回代码和游戏引擎。玩家中弹时，程序先判断盾牌是否存在，再扣除盾牌耐久；盾牌归零后，伤害才进入生命值；生命值归零，游戏状态切换为结束。视频模型接收这些结果并生成对应画面，而不是自行决定游戏规则。

这套架构意味着生成式游戏不必在“传统引擎”和“世界模型”之间二选一。传统引擎擅长物理、碰撞、状态同步和确定性规则，视频模型擅长把有限的结构信息扩展为丰富画面，两者的组合比让34B模型同时扮演裁判、数据库、物理引擎和美术团队更现实。

它更像实时“精装修”，不是凭空画世界

Matrix-Game 4.0通过结构画面降低了视频模型每一帧需要解决的问题。团队使用UE5制作成对训练数据：一侧是保留几何结构、物体位置和运动轨迹的简化画面，另一侧是具有材质、光照和环境细节的目标画面。

结构条件是由引擎提供的场景布局和运动提示，用来约束生成画面的空间关系。 它相当于先让引擎搭好毛坯房，再让视频模型完成材质、天气、光影和视觉风格，而不是让模型在每一帧里重新猜测墙在哪里、道路朝哪个方向延伸。

结构画面还不能表达所有语义，因此系统会读取当前可见对象及实时状态，动态生成文字描述。一个简单方块在几何图里可能代表盾牌、障碍物或NPC，文字条件负责告诉模型它究竟是什么，以及当前正在发生什么。

这套流程减少了生成模型的自由度，却提高了游戏系统真正需要的一致性。对于图片生成，偶然多出一盏灯通常没有影响；对于游戏，多出一堵不存在的墙、改变一辆车的位置，或者让敌人的武器突然消失，都会直接破坏交互。

34B为什么能装进18.5GiB显存

34B参数和18.5GiB峰值显存同时出现，说明参数量不能再直接等同于推理显存。按照最简单的静态权重计算，340亿参数使用FP16存储约需要63.3GiB，使用FP8约需要31.7GiB，即使压缩到4 bit也需要约15.8GiB，而且这还没有计算激活值、缓存、解码器和游戏引擎占用。

因此，18.5GiB这一数字背后必然依赖低精度权重、运行时内存复用、分块推理、选择性加载或其他压缩手段中的一种或多种。现有公开报道尚不足以确定每一项节省来自哪里，34B究竟是总参数量、每步参与计算的参数量，还是包含多个组件的系统口径，也需要以团队后续技术报告和开源权重为准。

这个口径问题很重要。一个标称34B但每一步只激活部分参数的模型，与一个每帧都完整计算34B稠密参数的模型，在运算量、功耗和可扩展性上并不是同一种产品；只比较参数数量，很容易高估或低估工程难度。

不过，峰值显存约18.5GiB仍然是一个有意义的部署指标。它意味着系统不仅能放入RTX 5090的32GB显存，理论上还为操作系统、图形管线和其他组件留出了空间，也让未来适配24GB显卡出现了可能性，尽管这需要更激进的量化或内存调度。

与英伟达方案相比，数字很抢眼，但不能直接排座次

英伟达研究团队同期展示的StreamRender-H3同样采用“代码运行世界、视频模型生成画面”的路线。公开演示使用8张GB200 GPU，每个视频块执行两步去噪，单个流式扩散步骤耗时约218ms；把视频块收集、解码和播放计算在内，国内报道估算其完整反馈约为545ms。

按照这组数据粗略计算，Matrix-Game 4.0约112ms的操作反馈时间是545ms的20.6%，也就是接近五分之一。硬件配置则从8张数据中心级GB200降到1张RTX 5090，部署规模相差一个数量级。

| 产品或路线 | 主要硬件 | 公开延迟 | 输出规格 | 状态管理方式 | 当前优势 | |---|---|---:|---|---|---| | Matrix-Game 4.0 | 1张RTX 5090 | 约112ms端到端 | 480p、60 FPS | 引擎和代码显式维护 | 单卡本地部署、延迟较低 | | StreamRender-H3 | 8张GB200 | 扩散步骤约218ms；完整反馈估算约545ms | 公开口径不同 | 代码与视频生成结合 | 数据中心算力和研究验证 | | Genie类纯世界模型 | 通常为云端研究环境 | 不同版本口径不一 | 以交互演示为主 | 更多状态隐含在模型中 | 开放环境生成能力更强 | | 传统游戏引擎 | 消费级GPU即可 | 通常为数毫秒至数十毫秒 | 可达1080p或4K | 完全由程序显式维护 | 清晰度、响应速度和确定性成熟 |

这张表不能当成严格跑分榜。Matrix-Game 4.0与StreamRender-H3的分辨率、视频块长度、画面复杂度、去噪设置和延迟统计边界并不一致，112ms与545ms也未必从同一个时间点开始计时；没有统一场景、统一画质和统一测量工具，五倍差距只能说明工程方向，不能证明模型能力全面领先。

据国内报道，Matrix-Game项目还获得了英伟达相关奖项认可，但奖项本身不能替代可复现评测。真正有说服力的材料仍然是完整权重、部署脚本、测试场景、显存监控以及从输入事件到显示器呈现的统一延迟测量。

Coding Agent让玩法修改不必重新训练模型

Matrix-Game 4.0把规则留在代码中，也让生成式游戏获得了更低成本的玩法修改能力。开发者可以让Coding Agent调整武器射速、任务目标、车辆行为或胜负条件，游戏引擎执行修改后的逻辑，视频模型继续负责呈现结果。

Coding Agent是能够读取、修改并验证软件代码的智能代理。 在这套系统里，它改变的是确定性规则，而不是重新训练34B视频模型，因此把计时赛改成追击战，不需要重新收集大量视频并训练一套新的世界模型。

这种分工比完全由提示词控制更可靠。提示词可以要求“让暴风雪变大”，却不适合精确规定“护盾吸收前100点伤害，剩余伤害按0.8系数扣除生命值”；后者最好保留在可测试、可审计的程序里。

更现实的产品形态可能不是一句话生成完整3A游戏，而是设计师先搭建规则和低精度场景，再由世界模型实时完成视觉呈现。短期内，互动短片、关卡原型、虚拟拍摄、训练模拟和UGC游戏会比竞技射击更适合这套技术，因为这些场景能容忍较低分辨率和约百毫秒延迟，却非常看重内容生产速度。

消费级世界模型真正跨过了哪条线

Matrix-Game 4.0跨过的是部署可达性，而不是产品成熟度。单张RTX 5090可以运行，意味着高校实验室、独立开发团队和高端个人用户有机会在本地复现、微调和修改系统，不必先获得数据中心GPU配额。

本地运行还会改变隐私和迭代方式。用户操作、摄像头输入、室内画面和未发布游戏资产可以留在本机，开发者修改代码后也能立即验证结果，不必反复上传视频或等待远端任务排队。

Matrix-Game 4.0距离替代传统渲染仍有明显距离。480p不足以满足主流PC游戏画质，112ms延迟难以支持强调操作精度的玩法，视频模型还需要回答长时间一致性、多人同步、画面可控性、版权数据和功耗等问题。

34B模型的运行成本也不能被“消费级”三个字掩盖。RTX 5090本身属于高端显卡，整机还需要足够的电源、散热和CPU配置；如果系统长时间满负载运行，电力和噪声成本都明显高于传统游戏渲染。

更值得期待的下一步是把同样能力压到24GB甚至16GB显存，并把分辨率提升到720p或1080p。若团队能在保持百毫秒级延迟的同时完成这两点，世界模型才会从少数高端桌面设备进入更广泛的开发者工作流。

结论：这是工程转折点，不是画质终点

Matrix-Game 4.0最重要的判断是，世界模型不需要吞掉整个游戏引擎。让代码维护规则、让引擎提供结构、让视频模型负责视觉，可以同时获得确定性和生成能力，也把一个34B系统压进了单张RTX 5090。

单卡运行比“全球首款”之类标签更值得关注。前者可以通过显存、帧率和延迟复现，后者往往取决于如何定义游戏世界模型、实时和消费级硬件。

截至2026年10月23日，Matrix-Game 4.0仍更像一套高完成度的研究原型，而不是可以直接取代Unity或UE5的通用产品。但它已经给出一个明确方向：下一代生成式游戏不会只靠更大的视频模型硬猜世界，而会让模型、游戏引擎和智能代理分别承担最擅长的工作。

参考来源

• SkyworkAI GitHub组织主页：用于核对团队公开项目、代码仓库及后续开源更新。
• 知乎：昆仑万维诞生世界上第一款消费级显卡视频大模型游戏：介绍Matrix-Game 4.0的480p、60 FPS、单张RTX 5090部署及低于150ms延迟等公开信息。