实时视频生成跨过消费速度阈值
MiniMax H3 是开源基座；H3 Max 由 fal 基于 H3 做后训练，并和自己的推理系统一起优化出来。公开口径里，5 秒 768p、带原生同步音频的视频，端到端大约 3 秒返回；fal 给出的后端推理时间约为 2.4 秒。
在这个速度口径下，生成时长短于播放时长。过去生成视频通常先等待结果，再播放一段成片。现在如果一段 5 秒视频能在 3 秒内生成，播放器播完当前片段之前，下一段已经进入 buffer。生成服务可以在播放过程中持续补充片段。
播放 Clip N（5 秒） ─────────────────►
生成 Clip N+1（约 3 秒） ───────► 入 buffer在这种模式下，生成系统是实时媒体系统的上游，产物是持续补充的内容流。
连续生成系统涉及的层
视频模型生成下一段画面和声音。连续播放时，节目状态、输入处理、缓冲与容错由外部系统承接：
节目状态 → Director → 视频生成 → Buffer → 播放器 → 观众输入 → 节目状态
- 节目状态保存角色、地点、关系、已经发生的事件、禁区和当前目标。它可以是可读写的结构化状态，也可以附带视频上下文。
- Director 将观众投票、实时聊天或系统事件转换为下一段的镜头目标，并写入角色与场景约束。
- Buffer 保存已完成但未播放的片段。3 秒是公开样例，不包含网络、排队、审核、提示词扩写等全部环节；服务稳定性要看端到端 p95 延迟与缓冲长度。
- 一致性检查可检测主角换脸、道具消失、空间关系错位、对白与前文冲突；过渡内容和回退片段用于处理生成失败或延迟。
fal.live 已经用实验版 H3 Max Director 做了这个方向的公开演示：观众可以投票影响后续内容，Director 被报道能参照最多约两分钟的历史视频。但它仍是实验产品，不是公开可接入的连续视频 API。
按片段生成与游戏 Runtime
“持续出片” 和 “实时可玩” 依然是两件事。
5 秒一段的结构很适合观众参与的节目：观众在当前段落播放时投票，下一段或下下段兑现结果。玩家感受到的是自己在推动节目发展。这种体验更接近参与式 AI 综艺、互动短剧、持续播出的虚拟角色频道。
实时游戏要求玩家每一帧或每一次操作都得到稳定、可预测的反馈；按片段生成意味着操作会等待下一次生成完成。碰撞、位置、数值、任务和经济等规则，若完全交给概率模型，会增加玩家理解结果因果关系的难度。
一种组合方式是：确定性游戏系统维护规则和世界状态，视频模型生成角色反应、战后新闻、城镇广播、玩家造成的社会后果，或由观众共同推动的世界事件。
最新的 H3-World 预印本将角色和镜头操作翻译为有时间定位的语言指令，再以轻量 LoRA 适配 MiniMax H3。论文报告的是研究原型结果，并未提供可替代传统游戏 runtime 的产品化系统。
公开直播案例
- fal.live：fal 的连续 AI 直播入口。其 Creator 页面 描述为观众在聊天中提交下一幕内容，由 Director 选择后实时生成。
- Infinite Slop：Pieter Levels 的网页频道。页面包含聊天、排队和正在生成状态，观众输入决定后续片段。
- SlopTV YouTube 直播：开源项目 SlopTV 的频道。它读取 YouTube Live Chat，使用 LLM 将评论改写为提示词，以两张 RTX 5090 上的 ComfyUI + 开源 MiniMax H3 生成约 15 秒的竖屏片段，再通过 RTMP 播回 YouTube。它使用的是开源 H3，不是 fal 托管的 H3 Max。
- fal 官方 H3 Max 实测视频：8 分钟录像，包含 5 秒、10 秒、15 秒输出的实际计时与蒸馏说明；它是模型实测讲解，不是连续频道。
这些链接的在线状态会随频道下架、转场或平台审核变化。上述网页入口与 SlopTV 的 YouTube 地址已在 2026-09-03 核实。
持续生成的成本
按 fal 当前公开价格，768p 是每秒 4.8/分钟、$6,912/天，还没有包含参考素材、审核、带宽、存储、Director 和内容运营。