等三分钟变成等四十毫秒：VAST 开源 EdenLive，一张消费级显卡就有 24 帧的实时世界

过去两年视频生成的进步有目共睹，但它始终有一个前提：你得等。写好提示词，按下生成，等几十秒到几分钟，看结果，不满意再改。这个循环里，人是停着的——而所有真正需要画面的场景，人都不该停着。

游戏、仿真、虚拟拍摄要的不是「一段好视频」，是「我按下方向键，画面立刻跟着变」。这两件事的差别，不是速度快一点慢一点，而是整个系统架构不一样：前者是批处理，后者是实时循环。批处理可以慢慢算，实时循环必须在几十毫秒内给出答案。

2026 年 10 月中旬，VAST（三启万物）开源了 EdenLive，把这个问题正面回答了：单张消费级显卡 RTX 5090、5B 模型、720P 分辨率，实时帧率超过 24 FPS；从用户操作到画面出现，端到端延迟在百毫秒量级；连续生成可以持续到分钟级。

24 帧是电影的标准帧率。这句话的分量在于：它第一次让「生成」追上了「观看」。在此之前，生成式画面在时间维度上是被观看的；从这一刻起，它开始参与交互。

EdenLive 最关键的设计不是模型结构，而是一句分工：状态归引擎，画面归模型。项目说明里写得很清楚——交互式世界模型把「状态演化」和「外观呈现」拆开，状态由编码智能体或游戏引擎维护，EdenLive 只负责把参考视频渲染成精细视频。

在这之前，世界模型的主流思路是「一个大模型把物理规则和视觉外观一起学」。这条路很优雅，但工程上很难：规则和外观耦合在一个网络里，改一处就动全身，而且模型对状态的理解永远是概率性的——它会「觉得」球应该往下掉，而不是「算」出球往下掉。

EdenLive 走的是另一条路。上游程序输出一段简化的参考画面（Proxy）或参考视频，EdenLive 以这段参考为控制信号，结合目标首帧和文本提示词，把画面渲染成写实或风格化的成品。

这个拆分看起来只是工程解耦，实际影响很大。规则可以改——改游戏逻辑不用重训模型；画面可以换——同一段参考能出写实、二次元、油画等不同风格；状态是确定的——物理位置、碰撞、计分由引擎算，不会因为模型「幻觉」而漂移；延迟是可控的——模型只做渲染，不做全世界的推演。

官方公布的性能口径是：单卡 RTX 5090、5B 模型、720P，帧率超过 24 FPS；支持 480P 与 720P 两档输出；可连续生成到分钟级；端到端延迟百毫秒级。这四个数字要拆开看，因为它们的含义完全不同。

24 FPS 是「能看」的下限，不是「好用」的上限。快节奏动作游戏需要 60 FPS 才不会觉得卡；EdenLive 目前更适合场景漫游、推箱子这类交互频率较低的玩法——官方给的示例也确实落在这个范围。把它当成「实时渲染的起点」，比当成「游戏引擎的替代品」更准确。

「分钟级连续生成」比帧率更值得关注。很多演示能跑三秒，跑三分钟就开始漂移、糊掉、崩坏。能连续跑分钟级，说明状态与画面的一致性维护住了——这才是能进生产的前提。一段三秒的惊艳片段可以拿去做宣传，一段三分钟的稳定画面才能拿去做产品。

百毫秒的端到端延迟已经接近人类感知的「即时」阈值（一般认为 100 至 200 毫秒内感觉不到明显延迟）。这是它能被称为「交互」而不是「预览」的原因。但要注意，这个数字指的是「操作到画面」，不包括上游引擎的状态计算与网络传输。

这次 VAST 放出来的不止权重。按仓库说明，对外开源的内容包括：5B 与 14B 两档模型权重，各含双向（bidirectional）与少步（few-step, chunk-AR）两种推理配置；实时流式推理代码；技术报告，覆盖训练方法、数据与优化方案；端到端 Demo；以及一个叫 Game Prototype Turbo 的技能包。

但工程现实也要说清楚。模型目录总量约 210GB；官方验证环境是 Linux x86-64、80GB 显存的 GPU、CUDA 13 驱动、Python 3.10、PyTorch 的 nightly 版本；5B 双向推理档还需要 SM90 架构、BF16 精度，以及特定版本的 flash-attn 与 cutlass 内核库。

换句话说：24 帧是真的，但「一张 5090 就能跑」说的是推理侧的账单。前期的环境搭建、依赖对齐、显存调优，是另一份账单——而且这份账单通常比硬件更贵，因为它花的是工程师的时间。

这不是缺点，是这类系统的正常形态。真正值得注意的是官方把「技术报告 + 推理代码 + 权重 + Demo」一次性放全了——这在世界模型领域并不常见。多数团队只放论文和 Demo 视频，让你相信；VAST 把可复现的东西也给了，让你验证。

在所有开源内容里，最值得单独讲的是 Game Prototype Turbo。它做的事情很朴素：输入一句提示词，生成一个能走、能玩的简化原型（Proxy Game）；游戏运行产生的状态数据，直接输入 EdenLive，实时渲染成精细画面，再反馈给玩家。

这条链路的每一环都不是新发明——代码生成、3D 生成、实时渲染各自都成熟了一段时间。EdenLive 的价值是把它们串成了一条可以在本地跑通的流水线，并且把源码放了出来。

对内容行业来说，这意味着「原型」的成本结构变了。以前做一个可玩的原型，需要一个程序、一个美术、一个关卡设计，两周起步；现在一个人一个下午能出一个「能走能看」的东西——虽然粗糙，但足够用来做决策：这个玩法值不值得往下做。

这个变化的影响不在「省了多少钱」，在「多做几次」。原型成本高的时候，团队一年只能试三个方向；原型成本接近于零的时候，可以试三十个。创新的瓶颈从「能不能做出来」变成「能不能选出对的」。

大多数企业不会自己去部署一个 210GB 的渲染模型。但这件事会通过三条路径影响到他们，而且影响的是「报价」而不是「技术选型」。

第一条是采购。当供应商告诉你「这段三维演示视频需要两周」，你现在可以问一句「能不能用实时渲染做一个可交互的版本」。报价的锚点变了——不是「视频多少钱一分钟」，而是「这个场景多少钱一套」。对采购方是好事，对供应商是压力。

第二条是培训与仿真。安全生产、设备操作、应急处置这些培训，过去靠视频和纸质手册，学员看完了事。现在可以做成交互式场景：学员操作，画面实时响应，做错了立刻看到后果。这类内容的制作成本，正在从「按分钟计价」往「按场景计价」滑。

第三条是资产治理。当风格可以随时切换、画面可以实时生成，企业真正需要管理的就不再是「成品文件」，而是「参考资产 + 提示词 + 参数」。这意味着数字资产管理的对象要往前移一层——不是管最终交付物，是管「生成它的那套输入」。

生成式渲染出来的画面，版权归属在多数司法辖区仍不明确。企业的实际做法通常是两条：一是要求供应商提供训练数据来源说明与 indemnity（侵权赔付）条款；二是对关键素材保留人工创作的部分，确保作品有可主张的人类作者贡献。

审核比版权更麻烦。离线生成的视频，发布前可以逐帧看、逐句审；实时生成的画面，是即时产生、即时呈现的——你没法在玩家看到之前审一遍。这意味着合规控制必须前移到「参考资产」和「提示词模板」这两层：素材先审，模板先审，实时输出才敢放出去。

还有一个更细的问题：风格模仿。把真人视频转成动漫风格，技术上很酷，但如果参考视频里是真人，转换后的人物形象仍然可识别，就可能涉及肖像权。这类边界在离线场景已经被讨论过一轮，实时场景只是把它放大了——因为转换是连续的、批量的、几乎零成本的。

被放大的还有基础设施账。离线生成一段视频，你只需要存一个成品文件；实时生成一段三十秒的交互画面，背后是每秒二十四个新画面在产生——不落盘，但要走显存、走显存带宽、走网络，还要保证每一帧的时间预算不被打破。这意味着团队要开始像游戏工作室那样思考「帧预算」：渲染占多少毫秒、通信占多少毫秒、留给意外情况的余量有多少。

这也是为什么 VAST 在技术报告里花了大量篇幅讲优化，而不是只讲效果。实时系统里，优化不是锦上添花，它决定了这个功能存在与否。

我不认为 EdenLive 会让 3A 游戏或电影级 CG 立刻消失。它现在的能力边界很清楚：低频交互、中等画质、分钟级时长、需要专业环境部署。

但它证明了一件事：生成式渲染可以进入实时循环。一旦这件事成立，剩下的就是工程迭代——帧率会上去，分辨率会上去，成本会下来。这条曲线我们在语音合成、图像生成、视频生成上都见过一遍，每一次都比预期快。

所以对企业的建议不是「现在就去部署」，而是「现在就开始想：如果实时生成的成本降到可接受，我们的哪一块业务会变」。想清楚这个问题的企业，在成本降下来的那一天会立刻动手；没想过的企业，会再用半年时间做调研。

五件事，按优先级排：