画面每秒 24 帧，操作就跟手了吗？

画面很流畅，为什么按下去还是慢半拍？#

假设一个生成式游戏演示看起来很惊艳：角色走进森林，画面不断变成细致的树木和光影。你按下转向，角色也确实转了，但总觉得手和画面之间隔着一点距离。

这不是本文的实测结果，而是一个需要验收的场景。每秒能生成多少帧，回答的是画面能否持续供应；按下按钮后多久看到正确变化，回答的才是操作是否跟手。

我更关心后一个问题。对互动产品，一段顺畅的视频还不足以证明用户能顺畅地操作它。

EdenLive 做了一次值得注意的分工#

VAST 团队的 EdenLive是一套生成式渲染系统。这里的“渲染”，可以理解为把场景里发生的事情画成用户看到的图像。

它没有把所有游戏规则都交给视频模型猜。上游程序或游戏引擎维护状态、执行规则，先产生较粗略的参考画面；EdenLive 再结合目标首帧和文字描述，把参考视频转换成更细致或不同风格的画面。参考视频负责传递布局、镜头运动和时间关系。

这种分工的意义很具体。门有没有打开、角色站在哪里、一次操作有没有生效，应由上游程序记录。生成画面需要把这些事实表现出来。画得漂亮，并不自动意味着画得准确。

本文关注的新进展，是 LightX2V 在北京时间 2026 年 10 月 18 日 18:40 加入的 EdenLive 实时推理支持。它提供了消费级显卡上的配置和性能表。这个时间对应工程集成更新，不是用一次代码提交推断 EdenLive 的首次发布日期。

24.69 帧和 500 毫秒，分别说明什么？#

该版本的部署文档报告：在一张 RTX 5090 上，基于 Wan2.2 的 5B 分块生成版本，以 1280×704 分辨率、批大小为 1（batch size 1）运行，推理吞吐为 24.69 帧/秒。同一配置的首块延迟为 500.02 毫秒，相邻输出块间隔的 P95 为 492.63 毫秒。

分块生成，就是一小段一小段地出图。P95 则表示所测间隔中，约 95% 不超过这个值。它描述输出节奏，不能直接读作某个玩家按键的等待时间。

这组数字需要一起看：

• 24.69 帧/秒： 在公布的测量条件下，平均供图速度略高于每秒播放 24 帧的要求。它说明持续播放有可能跟上，不能证明任意负载下都不会卡顿。
• 500.02 毫秒： 从推理请求边界到第一块输出的等待。它不包含模型加载、编译和预热，也不是浏览器按键到屏幕显示的完整耗时。
• 492.63 毫秒： 大部分相邻输出块的间隔。它不能替代逐帧显示稳定性，更不能直接证明高速转向、瞄准或碰撞反馈已经足够及时。

原文的推理吞吐包含输入准备和编码，排除了加载、编译、预热、最终视频拼接与 MP4 保存。网络传输、浏览器排队、显示刷新等环节，还需要在完整产品里另测。

这里还有一个容易被省略的条件：5090 配置采用了较低精度的计算与多项加速，并非直接装入默认版本就能得到同一成绩。其生成主干和参考画面编码器使用 INT8 ConvRot，文字编码器使用 FP8 并留在 GPU 上；同时启用了同步流式解码、编译和预热。通俗说，这是一套配好的加速方案，不只是一个模型名字。

文档还报告峰值已分配显存 28.38 GiB、峰值保留显存 28.95 GiB。这两项覆盖完整请求，包括最终拼接和保存。它们提醒我们，“5B”不能直接换算成整个服务的显存需求，也不能拿这次单批次结果推算多人并发容量。

验收要沿着一次操作走完#

对产品团队，我会把测试拆成两条线，再把它们接起来。

第一条线查状态：同一组操作输入，程序有没有得到正确结果？例如门打开后是否仍保持打开，角色有没有穿过禁止通行的位置。第二条线查表现：生成画面有没有及时、准确地呈现这个结果？

两条线可能各自看起来正常，放在一起却出现问题。程序已经判定碰撞，画面仍显示角色在前进；程序已经转向，生成画面过一会儿才跟上。用户感受到的是这个落差。

我会先做一组小而具体的回放：重复转向、急停、遮挡后重新出现、开门后折返，以及连续操作。每次记录输入时刻、程序状态变化和用户实际看到变化的时刻，再检查：

• 操作到画面反馈的完整等待，以及慢的时候到底慢在哪；
• 关键物体在遮挡、转身后是否还保持身份和位置；
• 可见接触与程序判定是否一致；
• 运行时间变长、请求增多后，是否出现停顿或积压。

这些是我提出的产品测试项，不是官方已经给出的通过结果。本文也没有亲自运行 EdenLive。

如果完整反馈还不适合快速操作，可以先在慢节奏探索、视觉风格预览等场景里验证价值。具体能接受多长等待，要由目标用户和任务决定，不能只看“实时”这个标签。

能体验的管线，还要逐项看能否用于生产#

官方仓库已提供 5B、14B 权重、流式推理代码，以及从文字生成粗略可玩游戏的技能和前端。但“一整套都能拿来做商业产品”仍需要单独检查。

仓库明确区分了组件许可：自有代码使用 Apache 2.0，视觉编码器等组件另有许可。完整工作台用于生成首帧的 FLUX.2 klein 9B 组件受非商业、非生产使用限制，因此 README 将完整工作台标为非商业用途。按文档运行已登记游戏的路径不加载 FLUX，但这也不代表其他组件的许可可以跳过。许可范围

文档还说明，工作台生成游戏时会使用跳过交互权限确认的 Claude CLI 模式。对一个让用户输入想法、再生成并运行代码的产品，这意味着权限隔离也要进入设计，不能因为演示顺畅就直接接到含有真实资料的工作环境。

另外，原仓库的常规安装说明与 LightX2V 的 5090 加速路径是不同配置。评估时必须记清自己选了哪一条，否则模型名称相同，资源要求和延迟却未必相同。

我的结论是：EdenLive 最有启发的地方，是把确定的规则与生成的外观分开。下一步产品验收也应尊重这种分工：状态是否正确，画面是否忠实，反馈是否及时，分别取得证据，再判断用户能不能真正用起来。

来源与边界#

• 对象与版本： VAST 的 EdenLive；本文读取官方 README 固定版本，核对上游状态与神经渲染分工、5B/14B 变体、工作台和许可范围。没有把模型描述成独立实现游戏物理、碰撞或多人状态同步的完整引擎。
• 新增证据与日期： ModelTC/LightX2V 的 EdenLive 集成提交，2026 年 10 月 18 日 10:40:44 UTC，即北京时间 18:40:44。以这一明确的工程更新作为选题依据，不将抓取时间或旧开发提交当作首次发布。
• 测量设置： 固定版本性能表及 5090 配置。Wan2.2 5B 自回归版本，1280×704、batch size 1、四步去噪、每块三个潜在帧、18 个潜在帧的注意力窗口及六个固定保留的潜在帧（sink frames），同步 LightTAE 解码。潜在帧是模型内部处理单元，不等于屏幕上显示的一帧。
• 数字边界： 24.69 帧/秒、500.02 毫秒、492.63 毫秒及显存数值均为维护方报告。本文不做跨模型排名，不声称独立复现；官方表未提供足以支持用户操作端到端延迟、多人并发容量或业务成功率的证据。
• 本文判断： 状态与显示分开验收、操作回放、场景取舍和权限隔离，是基于这套架构提出的产品建议。它们需要在具体应用中测试，不能当作 EdenLive 已获验证的效果或安全保证。