fal 最新披露的一组数据，把视频生成速度推进到一个新的参照系：生成一段 5 秒、768p 视频，H3 Max 的模型推理时间约为 2.46 秒；H3 Max Turbo 进一步压缩到约 1.54 秒。由于这个时间已经短于视频本身的播放时长，行业开始认真讨论一个过去不太敢想的问题：视频生成是否正在接近实时。
不过，2.46 秒并不是用户从点击到拿到成片的完整等待时间。它描述的是模型在 GPU 上执行主要生成计算所需的时间，更接近“推理耗时”，而不是端到端体验耗时。真正值得关注的，也不是一个孤立的跑分，而是这项成绩背后的工程结构：基础模型如何表示视频，后训练如何重排质量与成本，推理系统如何降低单步开销，硬件如何承接这些优化。H3 Max 的速度，是多层能力叠加后的结果。
底层模型先为效率留出了空间
H3 Max 并不是 fal 从零训练的新模型，它建立在 MiniMax 开放权重的 H3 之上。MiniMax 对 H3 的定位并非单一的文生视频模型，而是一套通用多模态生成模型。文本、图片、视频、音频可以进入同一个上下文，由模型理解不同素材之间的关系，再决定最终视频如何生成。
这种能力并不只是“支持更多输入格式”。例如，当模型同时接收一张人物图片、一段运镜视频和一段音频时，它需要判断人物、镜头运动和声音分别在整个生成任务中承担什么角色。这部分工作由 H3-Context-IR 参与完成，负责对 Prompt、图片、视频和音频进行理解、整理与对齐，再把结构化的生成上下文交给后续模型。
另一个直接影响计算成本的组件是 H3-VAE。视频原始数据量庞大，如果模型直接在 768p 甚至 2K 的 RGB 帧上完成主要计算，训练与推理成本都会显著上升。因此，视频生成模型通常会先用 VAE 将原始视频压缩成更紧凑的潜空间表示，让 Transformer 在更小的空间内完成生成，最后再解码回视频帧。H3 重新设计了 VAE，目标之一是提高压缩效率。同一段视频如果能用更短、更紧凑的潜空间序列表示，后续 Transformer 需要处理的数据量就会下降。
H3-Omni Transformer 则进一步统一不同生成任务。文生视频、图生视频、人物参考、动作参考等能力，不再必然对应彼此完全独立的模型，而是更多通过输入、上下文和指令来区分。这种设计同时影响训练与推理成本，也让 fal 后续优化有了更高的起点。
后训练不只追求画质，也把推理成本写进目标
MiniMax 开放 H3 权重后，fal 并没有把原始模型直接部署到 GPU 集群，而是在 H3 基础上进行了后训练。所谓后训练，是在基础模型已经具备较完整能力的前提下，用新的数据和训练目标继续向特定方向优化。
从公开信息看，H3 Max 的后训练重点包括 Prompt Adherence、视觉质量和画面美感。Prompt Adherence 指模型对指令的遵循能力，例如是否能按照“人物先转身，再向前走两步，最后镜头推进到面部特写”这样的要求，准确执行动作和顺序。
H3 Max 的特殊之处，在于降低推理成本从一开始就被纳入训练目标。传统流程里，模型团队通常先把效果做到尽可能好，模型交付后再由推理团队做量化、Kernel 优化、并行和调度。H3 Max 更接近一种协同设计：训练阶段就考虑未来如何推理，推理系统能提供哪些能力，也会反过来影响训练目标的设定。fal 将这种思路称为 co-design。模型训练和工程加速不再彼此割裂，而是共同寻找质量、速度与硬件效率之间的平衡。
视频扩散模型并不是接收一条 Prompt 后一次计算完成，而是从随机噪声或初始潜变量出发，经过多轮去噪和修正逐步得到结果。这些迭代次数就是采样步数，因此推理时间可以粗略理解为“采样步数 × 每一步的计算成本”。提速的路径也因此相对清晰：要么减少步数，要么降低每一步的计算开销。
直接减少采样步数，通常会带来画质下降、动作不稳定或指令遵循变差。H3 Max 的后训练价值，不在于机械压缩步数，而在于让模型适应更低的计算预算，在更少采样步骤下仍保持足够好的生成结果。换句话说，减少步数不再只是用画质换速度。
推理系统与硬件共同承接速度
即便采样步数已经降低，H3 本身仍是一个规模很大的视频生成模型，单步计算量并不低。fal 公开提到的推理栈覆盖 Kernel、编译、量化、缓存、权重加载、多 GPU、多节点和调度等环节，并披露了内部推理引擎 Falcon，以进一步降低生成模型的执行成本。
硬件同样是这条链路的一部分。fal 披露，H3 Max 的训练运行在互联的 NVIDIA GB200 NVL72 集群上。硬件会影响推理系统后续的部署与执行方式，但 GB200 并不是 H3 Max 变快的单一原因。把原始 H3 原封不动搬到更快的 GPU 上，并不会自动得到 H3 Max。
真正起作用的，是三层能力的叠加：后训练降低整体计算量，推理系统降低单步执行成本，新一代 GPU 再把这些优化充分释放出来。按照公开资料形成的判断，硬件可以采购，推理引擎需要长期系统工程积累，后训练还要求团队具备改动模型、组织训练数据和设计训练目标的能力。单靠堆硬件，很难自动复现同样的结果。
还需要厘清一个常见误读：2.46 秒并不等于用户最终等待时间。fal 的 API 将 timings.inference 定义为 GPU 后端的 DiT 去噪时间，也就是说，2.46 秒主要描述模型开始执行生成计算后，到主要推理完成所花的时间。用户从提交请求到看到结果，中间还可能包含排队、调度等环节；在高并发服务中，如果 GPU 资源暂时不足，请求还会在队列中等待。模型推理时间不等于用户感受到的端到端延迟。
“比播放更快”开始改变实时交互的可能性
即使只看推理时间，H3 Max 仍跨过了一个关键门槛：5 秒视频的模型生成时间已经低于视频自身播放时长，也就是 faster-than-real-time。这意味着，从计算速度看，当上一段视频还在播放时，下一段已经有机会提前生成完成。持续生成和流式交互之所以开始值得讨论，首先要满足这一条件。
H3 Max 的另一个信号，来自高清化路径的变化。传统视频生成提速的一种常见思路，是先生成低分辨率视频，再用独立的视频超分模型放大到 1080p 或 2K。H3 Max 支持 480p、768p 和 1080p，其中 480p、768p 是原生生成分辨率；1080p 官方描述采用 Latent Refinement，即基于原生 768p 结果，在潜空间中继续进行高分辨率细化，最后再解码成 1080p 视频。
它与传统视频超分的区别，在于高清化发生的位置不同。MiniMax H3 的 2K 输出则采用另一项机制：In-Context Regeneration。模型会将已生成的 768p 结果与原始多模态上下文一起重新利用，再生成 2K 结果。传统超分主要面对已经生成的低分辨率画面；如果某些细节在 768p 阶段已经丢失，超分模型只能基于剩余像素推测。In-Context Regeneration 则还可以重新参考原始 Prompt、图片、视频和音频，不只是把低清像素变清晰，而是参考原始生成条件，再生成一次更高分辨率内容。
需要注意的是，H3 Max 的 1080p Latent Refinement 与 H3 的 2K In-Context Regeneration，应按各自公开说明分别理解，不能直接当作同一套完整实现。但从这两条路线可以看到一个共同变化：高清化正在从生成链路末端的独立后处理，逐渐进入生成模型自身的推理过程。对画质和实时链路团队而言，画质增强不再只是外挂一个独立模块的问题。
H3 Max 之后，fal 又提供了 H3 Max Turbo。按照公开数据，同样生成 5 秒、768p 视频，H3 Max 的推理时间约为 2.46 秒，Turbo 降至约 1.54 秒。两者仍属于同一种生成范式：用户发起一次请求，模型生成一个完整视频 Clip，任务结束。Turbo 继续优化的是单个 Clip 能否更快生成。如果用户希望在播放过程中继续改变故事，让模型根据新指令持续生成后续内容，只把单个 Clip 做快仍然不够，那将涉及 Session、上下文保持、连续输出和直播链路接入等另一组问题。
在 AI 视频生成领域，“几秒生成一段视频”这类说法并不罕见，但不同表述背后的统计口径可能差异很大。H3 Max 这次给出的 2.46 秒，至少把一个更清晰的判断标准摆到了台前：速度数字只有和分辨率、视频时长、推理阶段定义放在一起，才具备可比性。而它更值得关注的地方，也不只是把某个 benchmark 做得更低，而是基础模型、后训练、推理系统与硬件开始围绕同一个性能目标协同设计。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/5-miao-shi-pin-2-46-miao-sheng-cheng-wan-bi-h3-max-ba-kuai
