世界模型的 Demo 一层比一层炸裂，但「能生成」和「能玩」是两回事。能生成，是把一段提示词变成一段像样的视频；能玩，是你在键盘上按一下，画面在下一帧就跟着动，而且这个「下一帧」的延迟要小到大脑察觉不出断连。这一篇不聊画质，也不重复选型账，只算一道题：到 2026 年 10 月，究竟有几家开源项目，真正把「可玩」这一层做到了能上手的程度。
一、先把标尺立起来：三种「实时」不是一回事
横评最容易犯的错，是把各家给的数字直接拉平比大小。可「实时」这个词，在不同原文里至少指三件不同的事：一是模型处理吞吐，每秒能吐出多少帧；二是端到端延迟，从输入动作到画面出现，也就是常说的 action-to-photon；三是呈现帧率，即用户眼睛看到的流畅度。这三个数可以差出好几个数量级，混在一起比，结论一定失真。
最好的证据来自 Matrix-Game 4.0 的 v4 README，它自己就把这条界线划了出来：--fps 40 被明确标注为「target capture cadence, not a throughput or latency guarantee」，也就是采集节奏目标，而不是吞吐或延迟保证；它给出的 A100 数字被标注为在线会话内的「model processing」吞吐，以及服务端在线管线吞吐（含等待游戏帧），并补了一句，这两者都不是浏览器呈现帧率，也不是动作到光子的延迟。一个项目在自家 README 里主动分出三条线，恰恰说明这条界线有多容易被糊过去。
所以本篇的评判规则是：先分口径，再比数字。凡是官方口径，一律标注「未独立复测」；凡是能落到「单卡、分辨率、去噪步数、具体场景」的可复现数字，权重最高。
二、七个对象同台：快照数据总表
先说这篇不写什么。站内 2026-09-14 的《开源不等于可商用：世界模型横评四本账》（open-world-model-comparison-review）算的是许可、硬件、数据、开放度四本账，覆盖 lingbot、gods-eye 等七项；本篇不重复那套选型账，只算「可玩」这一层。站内 07 月的《LingBot-World 2.0 热点》与《小世界模型本地部署 SOP》另有分工：一个讲单项目发布，一个讲部署步骤，本篇只做横向对照，不复述发布节奏与装机流程。下表星数均为 2026-10-16 的 GitHub API 快照，只作事实陈述，不作质量结论。
| 项目 | 星数 | 许可 | 实时/可玩数字 | 硬件门槛 |
|---|---|---|---|---|
| Matrix-Game 4.0（昆仑万维 Skywork） | 2,488 | 代码 Apache-2.0（v4 目录原文）+ 根仓 MIT | 官方口径 480p 60FPS、延迟 <150ms；README 实测 A100 864×480 约 38-39 FPS | A100 80GB / RTX 5090 |
| MineWorld（微软） | 494 | MIT | Diagonal Decoding 4-7 FPS，称可实时交互 | A100 / H100 |
| HY-World 1.5 / WorldPlay（腾讯混元） | 1,619 | 未声明（以仓库原文为准） | README 称 24 FPS；next chunk 为 16 帧 | 28G 到 72G（视并行度） |
| HunyuanWorld-Voyager（腾讯混元） | 1,604 | 未声明（以仓库原文为准） | 非实时：540p 最低需 60GB 显存 | 60-80GB |
| Helios（北大 PKU-YuanGroup） | 2,206 | Apache-2.0 | 单张 H100 19.5 FPS；用户实测 20.89 FPS | 单 H100 |
| PixVerse R1（爱诗科技，闭源对照） | — | 闭源 | 官方称 1080P 通用并主打实时，1-4 步出帧 | 云端 |
| Genie 3（Google DeepMind，闭源对照） | — | 闭源 | 公开报道口径 720p 24fps、约 1 分钟一致性 | 云端 |
三、逐个拆：五强与两个对照
Matrix-Game 4.0（昆仑万维 Skywork）：三方口径并存的样本
仓库在 SkyworkAI/Matrix-Game，仓库地址：github.com/SkyworkAI/Matrix-Game。GitHub API 2026-10-16 快照为 2,488 星、272 fork。许可链要拆开看：根仓 LICENSE 是 MIT（Copyright 2025 SkyworkAI and contributors，系列老代码沿用），而 v4 目录 Matrix-Game-4/LICENSE 是 Apache-2.0 全文，v4 README 的「Security and License」也写明「Project code is Apache-2.0」，并要求 vendored 组件保留各自的原始许可；组件目录里 TAEHV 的许可是 MIT。
它的性能口径有三份并存，必须并读，不能只挑大数：
一是官方发布口径，单张 RTX 5090、480p 60FPS、端到端延迟低于 150ms、单步去噪稳态 83 FPS、显存峰值 18.5 GiB。这是官方口径，未独立复测。
二是官网性能面板目前仍是占位符，显示为 0FPS / 0ms / 0p / 0GPU，页脚自述「project page preview · content will be updated at release」（本站 10-16 实访）。换句话说，官方口号里的数字，官网页面上还没有落数。
三是仓库 README 的自测口径，也是最硬的一份：单卡 A100-SXM4-80GB、864×480 分辨率，两个射击场景在固定 prompt 下约 38-39 FPS（在线会话内的模型处理吞吐），赛车场景固定 prompt 约 38.5、动态 prompt 约 28.9（服务端在线管线吞吐）。README 同时说明，赛车数字来自同架构、同推理配置的早期 checkpoint，仅作性能参考。请注意，这里的 38-39 是吞吐，不是浏览器里看到的帧率。
10-15 新发的是 RTX 5090 专用预设，--preset rtx5090 与 --preset rtx5090-sage，做法是在加载时把 DiT 块的线性权重量化成 FP8、推理时量化激活，Embedding 与输出头保持 BF16，再叠加融合核与 CUDA graphs。官方称 RTX 5080/5070 版下周发布。另外要提醒一句：权重与素材另有独立许可声明，以 HF 模型卡为准；本站对 Hugging Face 的取数被代理挡下，未取到模型卡原文，所以这里不臆测具体许可。
MineWorld（微软）：4-7 FPS 的老实人
仓库在 microsoft/mineworld，仓库地址：github.com/microsoft/mineworld。494 星，MIT 许可。它主推 Diagonal Decoding，并把口径直接写成「generation rate of 4 to 7 frames per second, enabling real-time interaction in open-ended game environments」。这里的「real-time」是针对 Minecraft 这类开放游戏环境的语境，4-7 FPS 就够交互，不能拿它去和 60FPS 的口号比速度。它的硬件建议是高端卡，作者自述开发与测试都在 A100 与 H100 上完成。还有一个必须写进去的事实：2025 年 5 月起，Hugging Face 上的 checkpoint 被「temporally taken down」（临时下架），所以它当前更像一份可复现的研究件，而不是随时能上手的成品。它只训练在 Minecraft 域内，超出范围的输入会生成不连贯画面，这一点作者自己也写得很直白。
HY-World 1.5 / WorldPlay（腾讯混元）：24 FPS 与 16 帧一跳
仓库在 Tencent-Hunyuan/HY-WorldPlay，仓库地址：github.com/Tencent-Hunyuan/HY-WorldPlay。1,619 星。许可方面，GitHub API 侧标记为 NOASSERTION，README 与仓库根目录没有给出具体许可名，仓库未声明许可，以仓库 LICENSE 原文为准，商用风险自担。
数字上，它在 Introduction 里写「generates long-horizon streaming video at 24 FPS」，推理被定义为一个 next chunk 预测任务，一次向前推进 16 帧视频，再由 Reconstituted Context Memory 从历史帧动态重建上下文以维持几何一致性。显存账也给得很细：用基于 HunyuanVideo 1.5 的 AR 蒸馏模型、125 帧推理时，sp=8 为 28G、sp=4 为 34G、sp=1 为 72G；训练侧 sp=8 为 60G。它还在自评表格里把自己标为 Real-time，同时把一批非实时方法标为否，等于自己立了一把尺子。它的价值不只在数字，而在于把数据、训练、RL 后训练、蒸馏这一整条链路都开源了，这是「可玩」这一层少见的系统性交付。
HunyuanWorld-Voyager（腾讯混元）：明确不是实时，但门槛最吓人
仓库在 Tencent-Hunyuan/HunyuanWorld-Voyager，仓库地址：github.com/Tencent-Hunyuan/HunyuanWorld-Voyager。1,604 星，同样是 NOASSERTION，仓库未声明许可，以仓库 LICENSE 原文为准。它的 Requirements 表直接写：540p、batch size 为 1、GPU 峰值显存 60GB，并且最小 60GB、建议 80GB。它的产物是相机可控的 RGB-D 世界视频，以及可导出的点云，用来做场景探索与重建，而不是逐帧跟着你的键鼠走。
延迟表更能说明问题：512×768、49 帧、50 步，单张 H20 是 1925 秒，8 张 H20 才压到 288 秒。把它放进本篇，是为了当一把反向的尺子：同样是世界模型四个字，它的时间尺度是分钟到半小时级别，离「玩」还隔着一个数量级。它属于重资产离线生成，不是可玩层。
Helios（北大 PKU-YuanGroup）：单张 H100 跑 19.5 FPS
仓库在 PKU-YuanGroup/Helios，仓库地址：github.com/PKU-YuanGroup/Helios。2,206 星，Apache-2.0，是五强里许可最干脆的一个。它是 14B 的实时长视频模型，官方口径是在单张 H100 上做到 19.5 FPS 端到端推理，并且明确说没有依赖常规的长视频抗漂移策略，也没有用 KV-cache、因果掩码、稀疏或线性注意力、TinyVAE、量化这些标准加速手段；昇腾 NPU 上约 10 FPS；一位用户在更好的硬件上实测到 20.89 FPS。生成方式上，它按 33 帧一个 chunk 自回归推进。
它最值得记的一点是「可交互」还在路上：模型表里三个 checkpoint 都标了 Interactive，但仓库里交互推理脚本处明确写着该功能 still under development、结果不总符合预期。所以它的 19.5 FPS 应该被读成「高吞吐的长视频生成」，而不是「按一下就动」的游戏级闭环。它还提供 group offloading，能把显存压到约 6GB，但那是用显存换吞吐的卸载模式，不能直接读成「6GB 就能玩」。
两个闭源对照：PixVerse R1 与 Genie 3
PixVerse R1（爱诗科技）为闭源，官方称是全球首个支持 1080P 的通用世界模型并主打实时能力（2026-01 发布，邀请制），核心是「瞬时响应引擎」把 50 多步采样压到 1-4 步，以上为官方与媒体转引口径，未独立复测。Genie 3（Google DeepMind）同样闭源，公开报道口径为 720p、24fps、约 1 分钟一致性、不支持多人，本口径与站内 09-14 旧横评一致，属二手转引。两者都不给权重、不给显存，因为根本不给部署：这一层的「实时」是云端的，你只能租，不能自持。
四、硬件门槛：从一张消费级显卡到 80GB 显存
把上面七项按硬件排一遍，落差大得离谱。消费级单卡这一档目前只有 Matrix-Game 4.0，它给了 RTX 5090 专用预设，并称 5080/5070 下周到。再往上是单张 H100 这一档，Helios 用一张 H100 跑出 19.5 FPS，但它跑的是长视频生成、交互模式仍在开发。再往上就是 60-80GB 显存的重资产档：Voyager 的 540p 最低要 60GB，且它本身不是实时；HY-WorldPlay 在 sp=1 时也要 72G。最后是云端闭源档，PixVerse R1 与 Genie 3 免部署，代价是不可自持。
这里还有一个容易误读的陷阱：Helios 的 group offloading 能把显存压到约 6GB，看着像消费级友好，但那是拿带宽和吞吐换显存，不能把「6GB 可跑」直接当成「6GB 能玩」。判断能不能玩，永远要同时看显存和吞吐两个数，只看其中一个都会被带偏。
五、开放度分层与许可原文
按许可分成四层，边界很清楚。第一层 Apache-2.0，代表是 Matrix-Game 4.0 的 v4 代码和 Helios，商用友好，要求保留声明、注明改动，并附带专利授权条款。第二层 MIT，代表是 MineWorld，以及 Matrix-Game 根仓的老代码和它引用的 TAEHV 组件（后者的许可是 MIT，Copyright 2025 Ollin Boer Bohan）。第三层是未声明，代表是 HY-WorldPlay 与 Voyager，GitHub 侧识别为 NOASSERTION，仓库里核不到具体许可名，只能写「仓库未声明许可，以仓库 LICENSE 原文为准」，商用风险自担。第四层是闭源，PixVerse R1 与 Genie 3。
要强调的是，许可决定的是能不能用，不是好不好用。星数只作快照事实，把 2,206 星直接读成「最强」，或者把 494 星读成「最弱」，都是拿流量当结论。真正该问的是：这个许可覆盖不覆盖我的用途，这个显存我买不买得起，这个吞吐能不能撑起我要的交互。
六、按需求怎么选：三档建议
第一档，要自持、要改代码。先看许可，再看显存。要 Apache-2.0 加消费级卡，Matrix-Game 4.0 是当前少见的、同时满足「消费级预设」与「明确许可」的选项；要 14B 级吞吐加 Apache-2.0，看 Helios，但接受它的交互仍在开发。
第二档，只求体验、不碰部署。PixVerse R1 与 Genie 3 免部署、开箱即用，代价是不可自持、口径多为官方或二手，且分辨率与时长都有边界。
第三档，要在自己的硬件上做长时探索与重建。Voyager 与 HY-WorldPlay 更合适，但预算要按 60-80GB 显存来做，并且接受它们的时间尺度不是逐帧可玩。
如果只做研究复现，MineWorld 老实、轻、可读，4-7 FPS 的可交互口径已经把它的定位说清楚了。一句话概括：能生成的项目很多，能玩的项目很少，而「能玩」这件事，同时被口径、显存和许可三把锁锁着。
延伸阅读
FAQ
Q1： 三种「实时」到底怎么分？
**A1：**分成模型处理吞吐、端到端延迟、呈现帧率。吞吐是每秒模型处理多少帧；延迟是输入动作到画面出现的时间，即 action-to-photon；呈现帧率是用户看到的流畅度。Matrix-Game 4.0 的 README 自己就区分了这三者，并明确 --fps 40 只是采集节奏目标，不是吞吐或延迟保证。比数字前先对齐口径，否则不可比。
Q2： Matrix-Game 4.0 的 480p 60FPS 能信吗？
**A2：**要分开看。官方口径的 480p 60FPS、延迟低于 150ms、显存峰值 18.5 GiB 属于官方口径，未独立复测，而且官网性能面板当前仍是占位符。仓库 README 的自测口径是 A100 864×480 约 38-39 FPS，而且那是模型处理吞吐，不是浏览器呈现帧率。官方 60FPS 描述的是目标场景下的呈现表现，README 的 38-39 是实测吞吐，两个数不是一回事。
Q3： NOASSERTION 的项目能商用吗？
**A3：**不能想当然。HY-WorldPlay 与 Voyager 在 GitHub 侧被标记为 NOASSERTION，仓库里核不到具体许可名。正确做法是只写「仓库未声明许可，以仓库 LICENSE 原文为准」，并在商用前逐字核对 LICENSE 原文、权重许可与素材许可。许可没写清，就意味着风险由你自己承担。
Q4： 手里只有一张消费级显卡，能跑哪些？
**A4：**按当前快照，明确给了消费级预设的是 Matrix-Game 4.0，它提供 RTX 5090 专用预设，并称 5080/5070 版下周发布。Helios 通过 group offloading 能把显存压到约 6GB，但那是显存换吞吐的卸载模式，吞吐会下来。其余项目要么需要单张 H100，要么需要 60-80GB 显存，要么只在云端提供。
Q5： 星数高的就更可玩吗？
**A5：**不是。星数只是 2026-10-16 的快照事实，不代表可玩性。2,206 星的 Helios 吞吐亮眼但交互仍在开发，1,604 星的 Voyager 明确不是实时，494 星的 MineWorld 反而老老实实给了 4-7 FPS 的交互口径。判断可玩性要看口径、显存与吞吐三件事，而不是看流量。
写在最后
这一轮横评下来，最该记住的不是谁的帧率高，而是「实时」这个词在不同项目里指向的根本不是同一件事。能生成已经不难，难的是把吞吐、延迟、呈现三件事同时做到「玩」的门槛以上，而这道门槛又被许可和显存两道墙夹着。挑项目时，先认清你要的是哪一种实时，再看许可和显存，最后才轮到帧率。