产品 fal模型与平台更新·原文 2026年9月18日

fal发布H3 Max：5 秒视频生成耗时不到 3 秒，已上线fal平台

fal称H3 Max在人类偏好评估中对阵 12 个领先视频模型，在质量、提示理解和美学三项排名第一，Artificial Analysis与Design Arena的独立基准也将其列为第一。

AI解读：fal发布H3 Max视频生成模型，官方称生成 5 秒视频耗时不到 3 秒，这一速度指标对应的是在已预热GPU上的推理延迟，而非用户实际等待的端到端时间。

fal把H3 Max定位为同时实现高质量和低延迟的模型：此前视频模型提升画质通常靠增加采样步数或换更大模型，速度提升往往以画质下降为代价，而H3 Max试图在两者之间不再二选一。

对直接使用视频生成API的开发者而言，更关键的是端到端延迟。fal在Serverless层提供了控制冷启动、扩容和机器类型的旋钮，这些配置可在运行中的应用上实时修改而无需重新部署，多节点推理等能力目前处于实验阶段。

fal发布H3 Max视频生成模型，官方称其生成 5 秒视频耗时不到 3 秒，在人类偏好评估中对比 12 个领先视频模型，在质量、提示理解和美学三项排名第一，Artificial Analysis与Design Arena的独立基准也将其列为第一。

fal称H3 Max由fal Research团队在fal Compute上进行后训练，目标是在最大化质量的同时最小化推理时间。最终训练运行在一组互连的GB200 NVL72节点集群上完成，耗时约一周到十天，此前用于实验的时间更多。

根据fal的说明，上述 3 秒指的是推理延迟，即在一台已预热的GPU上单次生成所需时间，不包括排队和冷启动；用户实际等待的端到端延迟还取决于排队、冷启动和扩容配置。

H3 Max同时以模型API形式在fal平台开放，调用接口为minimax/h3-max/image-to-video。fal称其模型API层共有 1300 多个端点，共用同一套API接口，底层排队、自动扩容和错误处理由平台负责。

fal表示H3 Max的完整生命周期依次经过fal Compute训练、fal Serverless部署、模型API分发三个层，这三层运行在同一套推理基础设施上。

训练：以保持质量排名为前提做速度优化

fal表示H3 Max由fal Research团队在fal Compute上完成训练与后训练。扩散类视频模型的执行时间大致等于采样步数乘以每步在特定硬件上的计算成本，多数提速做法是减少采样步数，代价是画质下降。

fal称H3 Max走的是fal面向扩散Transformer的后训练和强化学习基础设施，基于高质量数据，方向是同时得到更好的模型和更快的速度。训练贯穿一条规则：任何优化只有在该模型仍保持其质量评估排名时才会被采用，画面在延迟曲线上好看但在输出上悄悄变差的提速方案被拒绝，而不是带着保留条件上线。

模型规模还会向下游传导：它决定所需的机器类型、是否需要多节点推理，以及冷启动时加载权重需要多长时间。

训练集群：互连的GB200 NVL72节点
最终训练运行时长：约一周到十天
fal Compute可供任何团队租用，通常是 16 个节点以上的互连集群，用户对机器拥有完整控制权

推理：拆开冷启动，逐段缩短用户实际等待

fal把端到端延迟拆成请求启动和请求执行两部分。请求在队列中处于IN_QUEUE和IN_PROGRESS状态，背后对应runner的冷启动、空闲和运行等状态。队列没有大小限制，可重试的runner故障会自动重新入队，突发流量被吸收而不是被丢弃。

fal把冷启动定义为从PENDING到IDLE的时间。PENDING是等待调度到可用硬件，fal承担这一阶段且不计费；DOCKER_PULL是拉取环境镜像并缓存，节点已有镜像时完全跳过，同样不计费；SETUP是容器运行应用的setup() 函数并把模型权重加载到GPU，计费从这一阶段开始；IDLE表示可服务请求，RUNNING表示正在生成。

在fal给出的一个示例中，runner冷启动共 524 秒：26 秒用于获取B200 GPU（PENDING），1.56 秒用于拉取镜像，496 秒用于setup。fal称这个比例是典型情况，加载数十GB权重是启动大型模型最昂贵的部分。

FlashPack：fal开源的张量加载器，在不使用GDS的情况下以最高 25 Gbps从磁盘向GPU流式加载权重，H3 Max的Transformer、两个VAE和文本编码器都通过它加载
编译内核缓存：第一个runner完成torch.compile内核编译后，后续runner直接加载结果而不重新编译
三层缓存：/data文件系统分为本地NVMe、数据中心级缓存和对象存储三层，随应用流量增加缓存自行变热
自动扩容参数：min_concurrency保持热启动下限，concurrency_buffer预留备用runner，keep_alive决定空闲runner存活时长，scaling_delay避免短时尖峰触发不必要的扩容

多机器类型路由与预留容量

H3 Max采用多应用路由模式：公开端点是一个小型CPU应用，负责校验、提示词扩展、安全检查、计费等不需要GPU的工作；生成任务运行在不同机器类型的独立GPU应用上，各自独立扩容。路由本身是应用代码而非平台功能，CPU应用掌握每个集群的容量和进行中的生成数量，请求优先发往有空位的最快集群，占满后溢出到下一个，腾出空间后流量马上切回。某个集群错误率上升会被降级，所有集群都满时请求排队而不是失败。

fal称这与回退机器类型不同：回退解决的是扩容时硬件可用性问题，路由决定的是请求在飞行过程中发往哪里。

在容量分配上，fal Serverless的企业客户通常分两层：一是预留容量，每种机器类型固定数量的GPU，7×24 独占、与共享池隔离；二是超出基线后向共享池突发的容量。突发池由企业客户共享，争用时的PENDING等待可能长于预留容量。预留价格按合同固定，非合同用量按当期价格计费，可能变化。

H3 Max在GB200上以多节点推理方式服务，单个应用跨多个GPU节点运行、以一个端点对外，每个节点加载部分模型，主节点处理请求
fal称该多节点推理能力目前是实验性的，仅向早期访问客户开放
单节点内最多可使用 8 块GPU做多GPU推理，机器类型覆盖Hopper到Blackwell

可观测性与实时流：同一套仪表盘，另加WebRTC原语

fal称H3 Max用到的每一项能力都直接显示在Serverless仪表盘上：队列等待、冷启动各阶段、推理耗时。所有部署的应用使用同一套仪表盘。App Analytics提供吞吐量、错误率和按百分位拆分的延迟，Runner Analytics提供单个runner的侧边视图、实时GPU遥测和日志。对已有自有可观测性栈的团队，OpenTelemetry追踪和日志导出可输出同样的数据。仪表盘还支持在运行中的应用上调整机器类型和扩容参数，改动立即生效、无需重新部署，并在后续部署中保留。

fal还介绍了一个面向交互式模型的Serverless原语WMA（World Model Accelerator），通过WebRTC提供服务，客户端经wma.fal.run桥接一次后，runner保持实时会话，媒体直接推流给客户端，控制消息走数据通道。fal解释不直接使用请求或WebSocket的原因：请求适合生成单条视频，不适合持续流；WebSocket跑在TCP上，一个丢包会卡住后面所有帧，且交付原始数据需要应用自行解码、控制播放节奏和同步音频；WebRTC把媒体轨道交给浏览器，浏览器原生完成硬件解码、节奏控制和音画同步，丢帧时跳过而不阻塞，握手后媒体直接在runner与客户端之间流动、不经过中间网关。

fal.live被列为生产环境中的例子：持续播出AI视频和音频频道并由观众实时操控，每个频道是一个WMA会话，观众观看的是该会话的广播，因此一个频道给十名观众和一万名观众消耗的GPU相同。fal称WMA目前也是实验性的。

fal称模型API是整个生命周期的最后一步，也是最不需要额外技术的一步：fal上每个模型API（包括H3 Max）都是运行在共享认证模式下的Serverless应用，使用同样的runner、缓存和分析。