fal 公布的一组数据是：H3 Max 生成一段 5 秒、768p 视频，模型推理时间约为 2.46 秒；H3 Max Turbo 又把这个数字降到了约 1.54 秒。
这已经低于视频自身的播放时长，但要理解这个结果，不能只看 GPU 型号，也不能把它简单归因于某一种加速技巧。
H3 Max 的速度来自几层能力共同作用：基础模型怎样表示视频，后训练怎样调整质量与计算预算，推理系统怎样降低单步执行成本，硬件又怎样释放这些优化空间。与此同时，2.46 秒描述的是模型推理过程，并不等于用户从提交请求到看到视频的完整等待时间。
下面沿着这条链路，拆开这笔速度账。
一、H3 Max 的底座是 MiniMax H3
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 拿到的不是一个完全没有考虑效率的基础模型，这是 H3 Max 后续继续提速的前提。MiniMax H3 官方技术介绍
图1：从多模态输入到 768p 生成，再到 2K 再生成。示意图，根据 MiniMax H3 官方公开资料重绘。
二、fal 做的不只是部署模型
MiniMax 开放 H3 权重以后，fal 没有直接把原模型部署到 GPU 集群上，而是在 H3 基础上继续做了后训练。
后训练可以理解为：基础模型已经具备比较完整的能力，再用新的数据和训练目标，让它朝特定方向继续优化。
fal 公开的信息中，H3 Max 的后训练重点包括 Prompt Adherence、视觉质量和画面美感。Prompt Adherence 是指令遵循，例如要求人物先转身，再向前走两步，最后让镜头推进到面部特写，模型能否按照动作和顺序执行。
H3 Max 的特殊之处在于，后训练目标不只有生成效果，降低推理成本从一开始也被纳入训练目标。
传统流程往往是模型团队先把效果做到尽可能好，模型交付以后，推理团队再做量化、Kernel 优化、并行和调度。H3 Max 更接近协同设计：训练时就考虑未来怎样推理，推理系统能提供什么能力，也会反过来影响模型的训练目标。
fal 将这种思路称为 co-design。模型训练和工程加速不再是两个完全独立的阶段，而是共同寻找质量、速度和硬件效率之间的平衡。fal 关于 H3 Max 训练与推理的说明
三、速度是怎样构成的
视频扩散模型并不是接收一条 Prompt，只计算一次就得到最终视频。它更接近这样一个过程：从随机噪声或初始潜变量出发，经过多轮去噪和修正，逐步得到最终结果。
这些迭代次数就是 Sampling Steps，也就是采样步数。因此，视频生成耗时可以粗略地写成：
总推理时间 ≈ 采样步数 × 每一步的计算成本
沿着这个式子，提速有两个直接方向：少算几步，或者让每一步算得更快。H3 Max 的优化落在这两个方向上，再加一层硬件支持。
1. 让模型适应更低的计算预算
直接减少采样步数，通常会带来画质下降、动作不稳定或者指令遵循变差。真正有价值的不是把原来的几十步机械地砍成几步，而是让模型通过后训练适应更低的计算预算，在更少的采样步骤下仍然保持足够好的生成结果。
fal 的后训练重新调整了质量与推理成本之间的平衡，让减少采样步数不再只是简单地用画质换速度。
2. 降低每一步的实际执行成本
H3 本身是一个很大的视频生成模型。即使采样步数已经降低，单步计算量仍然很高。
fal 公开提到的推理栈覆盖 Kernel、编译、量化、缓存、权重加载、多 GPU、多节点和调度等环节，后续还公开了内部推理引擎 Falcon，用来进一步降低生成模型的执行成本。
3. 用新一代硬件释放优化空间
fal 披露，H3 Max 的训练运行在互联的 NVIDIA GB200 NVL72 集群上。硬件也会影响后续推理系统可以怎样部署和执行，但 GB200 不是 H3 Max 变快的单一原因，把原始 H3 原封不动搬到更快的 GPU 上，并不会自动得到 H3 Max。
真正起作用的是三层叠加：后训练降低计算量，推理系统降低单步成本，新一代 GPU 再把这些优化充分发挥出来。
图2：后训练与推理优化分别作用在质量与延迟上。示意图，根据 fal 公开技术资料重绘。
下面是我们根据公开资料形成的判断，不是 fal 的官方结论：三层中，硬件可以采购；推理引擎需要长期的系统工程积累；后训练还要求团队具备改动模型、组织训练数据和设计训练目标的能力。单靠堆硬件，很难自动复现同一个结果。
四、2.46 秒究竟是哪一段时间
“2.46 秒生成 5 秒、768p 视频”很容易被理解成用户点击按钮后，只要等待 2.46 秒就能看到视频。实际上，这两个时间不是同一个概念。
fal 的 API 将 timings.inference 定义为 GPU 后端的 DiT 去噪时间。也就是说，2.46 秒主要描述模型开始执行生成计算以后，到主要推理完成所花的时间。H3 Max API 计时说明
用户从提交请求到看到结果，中间还可能包含：
- Prompt 处理和 Prompt Expansion；
- 请求排队；
- Runner 启动和模型权重准备；
- 模型推理；
- 视频编码；
- 网络传输。
在高并发服务里，如果 GPU 资源暂时不足，请求还会在队列中等待。因此：
模型推理时间不等于用户感受到的端到端延迟。
图3：一次请求从提交到完成，模型推理执行只占其中一段。示意图，根据 fal 公开技术资料重绘。
在我们此前记录的音乐盒样本中，统计口径是本地提交至结果返回，已经包含中间若干环节；样本规格也与 fal 的测试不同。两组数字不能直接相减，更不能据此计算“快了多少倍”。
但即使只看 inference time，H3 Max 仍然跨过了一个关键门槛：5 秒视频的模型生成时间已经低于视频自身的播放时长。这就是 faster-than-real-time。
它意味着，从计算速度看，当上一段视频仍在播放时，下一段已经有机会提前生成完成。持续生成和流式交互之所以开始值得讨论，首先要满足这个条件。fal H3 Max 发布说明
五、生成得快，是不是因为先出低清再超分
传统视频生成如果想提速，一种自然思路是先生成低分辨率视频，再交给独立的视频超分模型放大到 1080p 或 2K。RealESRGAN 一类模型就属于这种后处理路线。
H3 Max 支持 480p、768p 和 1080p，其中 480p、768p 是原生生成分辨率；1080p 官方描述采用 Latent Refinement，也就是基于原生 768p 结果继续在潜空间中进行高分辨率细化，最后再解码成 1080p 视频。H3 Max API 分辨率说明
它与传统视频超分的主要区别，是高清化发生的位置不同：
- 传统超分是在完整低分辨率成片生成以后，再交给另一个模型处理；
- Latent Refinement 仍处在生成模型自己的潜空间工作流中。
MiniMax H3 的 2K 输出又采用了另一项机制：In-Context Regeneration。模型会把已经生成的 768p 结果与原始多模态上下文一起重新利用，再生成 2K 结果。MiniMax H3 官方技术介绍
传统超分主要看到已经生成的低分辨率画面。如果某些细节在 768p 阶段已经丢失，超分模型只能根据剩余像素推测。In-Context Regeneration 还可以重新参考原始 Prompt、图片、视频和音频，它所做的不只是把低清像素变清晰，而是参考原始生成条件，再生成一次更高分辨率的内容。
需要注意，H3 Max 的 1080p Latent Refinement 和 H3 的 2K In-Context Regeneration，应按各自公开说明分别理解，不能直接当作同一套完整实现。
图4：三种高清化路线，区别在于高清化发生在生成链路之内还是之外。示意图，基于公开资料整理。
从这两条路线可以看到一个共同变化：高清化正在从生成链路末端的独立后处理，逐渐进入生成模型自身的推理过程。对于画质和实时链路团队来说，画质增强不再只是外挂一个独立模块的问题。
六、Turbo 更快了，但生成范式没有改变
H3 Max 之后，fal 又提供了 H3 Max Turbo。按照 fal 公布的数据，同样生成 5 秒、768p 视频，H3 Max 的 inference time 约为 2.46 秒，Turbo 进一步降到了约 1.54 秒。
两者依然属于同一种生成范式：用户发起一次请求，模型生成一个完整的视频 Clip，任务结束。Turbo 继续优化的是一个 Clip 能否更快生成出来。
如果用户希望在播放过程中继续改变故事，让模型根据新指令持续生成后续内容，只把单个 Clip 做快仍然不够。那会进入 Session、上下文保持、连续输出和直播链路接入等另一组问题，适合单独讨论。
判断“实时 AI 视频”时，可以先检查这六项
以后再看到“几秒生成一段视频”或“实时视频生成”的说法，可以依次确认：
- 输出规格：视频多长，分辨率是多少，是否包含原生音频；
- 模型版本：普通版、Turbo 版还是其他蒸馏或加速版本；
- 时间范围：统计 inference time、任务执行时间，还是端到端延迟；
- 服务状态：是否包含排队、冷启动、编码和网络传输；
- 质量代价：减少采样步数后，画质、动作稳定性和指令遵循是否变化；
- 高清化路径：高分辨率是原生生成、潜空间细化、上下文再生成，还是独立超分。
只有把这些条件放在一起，速度数字才具有可比较性。H3 Max 的意义也不只是把一个 benchmark 数字做得更低，而是让基础模型、后训练、推理系统和硬件开始围绕同一个性能目标协同设计。
参考资料与口径说明
- MiniMax H3 官方技术介绍
- MiniMax H3 开放权重入口
- fal H3 Max 发布说明
- fal 关于 H3 Max 训练与推理的说明
- H3 Max API：分辨率与 timings.inference 定义
- 文中 H3 Max 与 Turbo 的速度均为厂商公布数据，不是花椒复测结果。
- 本文属于公开资料分析。花椒此前的样本只用于说明端到端等待时间与模型推理时间的口径差异，不作为厂商 benchmark 的对照实验。
