MiniMax-H3 自托管 vs fal H3 Max

1 · 这些数字分别在什么配置上测的

这一节存在,是因为这份报告是在三次换框架之后长出来的:先把所有东西在 1 卡上测完,然后发现1 卡会系统性地错估每一个杠杆而改到 8 卡,再然后发现 sglang 0.5.18 把启动和单片都砍了一半。三种配置的数字曾经混在一页上、无法分辨来源。下表把每个结论钉回它的配置。

2 · 画面对照

同一个 prompt、同一个种子、同一张首帧。每一行是一个场景,每一列是一条臂。ref2va 的对手不是 H3 Max —— 查 fal 自己的模型库 API 确认:minimax/h3/reference-to-video 存在,但 H3 Max 只有 text-to-video 和 image-to-video 两个端点。所以那一格要和 fal 的基座 H3 比,而那反而是这份报告里唯一一个双方模型完全相同的比较 —— 差的纯粹是工程。

输入素材

ambience

a still frame where the SOUND carries the clip — H3's joint audio is the point

camera

a sustained camera move — temporal coherence

host

a recurring virtual presenter — identity consistency is what a hosted channel lives on

motion

fast multi-subject motion — reportedly the first thing few-step distillation smears

refsubject

ref2va 的身份参考

refsubject2

ref2va 的身份参考

2.1 头对头:配置对齐的对照

只有这张表里的臂是可比的 —— 同 prompt、同种子、同输出规格(ffprobe 核实:两边都是 1344×768 / 24fps / 124 帧 / AAC 立体声 32kHz)。我们这边是 8×B200 · sglang 0.5.18,也就是速度表里那个 2.87 秒的配置。

2.2 人物参考 —— 同一套开源权重,两种采样档

两边都是 MiniMax 的开源基座权重(H3 Max 没有 reference-to-video 端点,查 fal 模型库 API 确认)。输出规格相同(1344×768 / 124 帧)。但采样档几乎肯定不同:我们跑 4 次去噪加 turbo LoRA,服务端 4.93 秒;fal 墙钟 140–194 秒,且其基座端点不返回 timings,所以只有墙钟可比。这不是纯工程对照,而是同一套权重下「4.93 秒」对「约 3 分钟」买到了什么。

2.2 画质轴 —— 全部在 1×B200 · sglang 0.5.17 上渲染

这些臂只改一个变量,用来判断画质。不要拿它们的耗时和上表比 —— 配置不同。在 1 卡上判断画质是合理的:同请求在 1 卡和 8 卡之间画面只差 0.07–2.1%(浮点归约顺序)。

2.3 GPU 数是否改变画面 —— 同请求同种子,只改卡数

左边 1 卡、右边 8 卡,两者都是 sglang 0.5.17。用来检验「画面不随 GPU 数改变」这句断言。

2.1 逐片对照:我们 vs fal

同场景同 prompt 同种子。fal 的列是他们自己的仪表返回的 timings.inference;我们的列是围绕同一个请求的秒表。两者口径不同,所以分开列而不是硬凑成一个比值——fal 的端到端还要加上排队和传输,我们的还要减去 HTTP 轮询。

3 · 速度

3.1 sglang 0.5.18:全部收益都是多卡的

把 pin 从 0.5.17 抬到 0.5.18,8 卡上快了 1.66 倍、冷启动快了 2.1 倍。但 1 卡上没有任何收益——而那个「没有收益」正是解释机制的对照组。

3.2 同一个请求,1 卡 vs 8 卡

这一节存在,是因为报告早期版本里有一句未经验证的断言:「画面不随 GPU 数改变,Ulysses 分的是同一份算术」。它被用来正当化「速度数字取自 8 卡、画面取自 1 卡」。Ulysses 的 all-to-all 改变了 attention 内部的浮点归约顺序,所以逐位相同本来就不该期待。下面是同请求、同种子、只改 GPU 数的实测。

速度:并行效率

3.5 多镜头故事:一次生成里的四个镜头、两个角色

H3 的镜头语法是 MiniMax 官方文档的,不是社区约定。base guide 4.2:“Do not add a timestamp to the first shot. Use sequential shot numbers for later shots, and begin each one with a strictly increasing cut time that falls within the video duration”,ref guide 5.1 把格式钉成 [Shot N] At MM:SS.mmm,。下面这个 prompt 用了四个镜头,切点 00:04.000 / 00:08.000 / 00:11.500,两个角色各自绑定自己的参考图,同一个 prompt 跑三个时长。ffprobe 核实全部是 1344×768 / 24fps / AAC 立体声 32kHz。

3.3 时间花在哪

SGLang 默认只打印九个 pipeline 阶段里的两个,所以最初的 8 卡测量留下 3.5 秒「测到了但没归属」。把日志级别打开之后:

3.4 汇总

4 · 成本

全成本口径

上表只算 GPU 那一行。这几项核对过 Modal 的定价页,并用我们自己的账单账本交叉验证:

5 · ref2video 持续直播:能不能实时,要几张卡

直播的门槛不是延迟,是 RTF(real time factor)= 片长 ÷ 生成耗时。RTF 必须 > 1.0,否则缓冲会被慢慢耗干,一小时后就断流。本节的每个数字都是 ref2va + 两张人物参考图 + 15 秒片段,也就是要上线的那个形态。

5.1 起点:全部卡数都不实时

5.2 拆解:ref2video 为什么比 t2v 慢 3.1 倍

同一台 4 卡机器、同一次测量、768p / 5 秒:

5.3 消融:唯一有用的是参考图「张数」,不是尺寸,也不是 prompt 长度

4 卡 · 512 · 15 秒,每档 3 次,每个 arm 只改一个变量:

5.4 突破:把那个 2048 常量改掉

每张参考图进 DiT 两次——7,296 个 VAE latent row,加上 7,296 个 <|image_pad|> vision token 拼进 prompt,共 14,592 token。对照目标序列(896×512 / 15 秒 = 47,936 video row + 1,200 audio row),一张参考图就占序列的 22.7%。而我们喂的是 576 高的图,被上采样出来的像素原图里根本不存在。

5.5 优化阶梯:每个配置的完整参数、时间与成本

全部为 ref2video · 两个人物参考图 · 15 秒片段 · 896×512 画布 · 同一 DRAMA prompt。「工作成本」是产出一小时视频消耗的 GPU 秒折算;「常驻成本」是容器不间断运行一小时的账单——RTF 超过 1 的部分是空转,照样计费。

5.6 几张卡:2 卡在 4 步下差最后 7%

5.6 画质 2×2:参考图分辨率 × 去噪步数

同一 2 卡容器、同一 seed(20260830)、同一 prompt、同一画布,只有两个变量在动。左列是 sglang 原生的 2048 参考图,右列是 patch 后的 576;上排 4 步去噪,下排 3 步。右下角就是最便宜的那个配置——它比左上角快 2.5 倍、便宜一半,代价就在这四格的对比里。

5.7 其余片段

6 · 已经排除的路,和我们自己错了什么

负面结果和正面结果一样值钱,而且更容易被重复踩。

6.1 被推翻的自有假设

都是这个仓库自己写下过、后来被实测证伪的。列出来是因为下游的成本模型还引用着它们。

7 · 没测什么

一份只列出「发现了什么」的报告,读起来会比它实际的完整度更完整。这里是明确的空白。

8 · 方法与复现

全部可复现,命令在仓库里:

modal run -m src.lab::bench8 --steps 5,9 --durations 5 — 8 卡延迟
modal run -m src.lab::bench --steps 5 --log-level debug — 分阶段拆解
modal run -m src.samples::fal_reference — fal 对照臂
modal run -m src.samples::our_matrix --variant current — 画面矩阵

每条臂同 prompt 同种子(20260829)。步数字段数的是含末尾零的 sigma 网格点,所以字段 5 = 4 次去噪求值,字段 9 = 8 次——这一点由进度条 0/4 和 8/8 直接确认。