MiniMax H3 在 Jetson AGX Thor 上的早期公开 Benchmark：FL2VA、Ref2VA 与 INT8 ConvRot 测试方案
MiniMax H3 刚开放不久，社区里已经开始出现 BF16、FP8、INT8 ConvRot、NVFP4、FL2VA、Ref2VA 等不同版本的讨论。但真正面向 NVIDIA Jetson AGX Thor 的公开测试还很少。
这篇文章的目标不是做一次随手试跑，而是建立一套可复现的早期公开 benchmark：同一台 Thor-JD、同一组输入素材、同一套 API 调用、同一套日志字段，把 FL2VA、Ref2VA 和 INT8 ConvRot 的容量、速度、输出有效性都记录下来。
2026-08-07 更新：继续测试了 Abiray/Minimax-H3-nvfp4-INT4-INT8-Convrot。结论更新为：BF16 FL2VA 在 Thor-JD 上没有跑通；但 NVFP4/ComfyUI 路径已经在 Thor 专用
fire-smoke-train:cu130容器里跑通 smoke test，生成了有效 MP4。 这次不是完整质量 benchmark，而是256x256、5 frames、1 Euler step的最小链路验证。
2026-08-07 追加：基于 Chipmark 侧记录，Thor-JD 已完成
608x352、243 frames、20 steps的 ComfyUI 正式快速基线。Thor Docker CUDA 13 + NVFP4 热跑约300.03sexternal /284.64sComfyUI，采样约12.82s/it；同一 INT8 ConvRot FL2VA 权重热跑约400.04sexternal /395.13sComfyUI，采样约18.46s/it。
一、测试机器：Thor-JD
| 项目 | 数值 |
|---|---|
| 主机 | 100.98.98.105 |
| 用户 | nvidia |
| 设备 | NVIDIA Jetson AGX Thor |
| 操作系统 | Linux 6.8.12-tegra，aarch64 |
| NVIDIA-SMI | 580.00 |
| CUDA | 13.0 |
| 内存 | 122 GiB |
| 存储 | 936 GB NVMe，FL2VA 下载后可用约 266 GB |
| 当前状态 | 测试前停止了 sglang-qwen25-7b 容器以释放内存 |
| 测试时间 | 2026-08-06 20:55 CST |
| SGLang 镜像 | nvcr.io/nvidia/sglang:26.04-py3 |
| 基础 SGLang 版本 | 0.5.10+516d57ac |
| 实测运行栈 | 容器内 source SGLang + PYTHONPATH=/tmp/sglang-src/python + Transformers 5.12.1 |
| swap | 0 GiB |
| ComfyUI 实测 | ComfyUI 0.30.0 + comfy-kitchen 0.2.26 |
| PyTorch 实测 | 失败路径：2.5.1 / CUDA 12.4，不含 Thor sm_110 kernel；成功路径：2.11.0+cu130 / CUDA 13.0，包含 sm_110 |
Thor 的关键优势不是峰值算力，而是 统一内存容量。MiniMax H3 的原始分区非常大，传统 24 GB 显卡通常需要量化、分层 offload 或多卡；Thor 的 122 GiB 统一内存让它成为一个很适合测试“大模型是否能在边缘设备上跑起来”的平台。
二、MiniMax H3 的测试对象
根据 SGLang MiniMax-H3 文档，H3 是一个视频和同步音频联合生成模型，公开任务分成三类：
| 任务 | API task | 使用的 checkpoint 分区 | 输入条件 |
|---|---|---|---|
| Text-to-Video+Audio | t2va | fl2va | 仅文本 |
| First/Last-Frame-to-Video+Audio | fl2va | fl2va | 第一帧、最后一帧或两者 |
| Reference-to-Video+Audio | ref2va | ref2va | 图像、视频、音频 reference |
SGLang 文档特别指出：fl2va 分区同时服务 t2va 和 fl2va，ref2va 需要单独以 --model-variant ref2va 启动。Video-to-video 不是第四个任务值，而是 ref2va 的一种 reference 用法。
参考链接：
- SGLang MiniMax-H3 cookbook
- MiniMaxAI/MiniMax-H3 on Hugging Face
- ComfyUI_RH_MinMaxH3
- DmitryDB MiniMax-H3 ComfyUI Quants
三、为什么单独测 INT8 ConvRot
原始 H3 分区的容量压力很大。社区 INT8 ConvRot checkpoint 的意义在于：它把主要矩阵压到 INT8，同时保留部分 BF16 语义矩阵，目标是让单卡 24 GB 或 32 GB 机器也能跑。
在 Thor 上测 INT8 ConvRot 有两个价值：
- 容量验证：Thor 是否能不用激进 offload，稳定装下 FL2VA / Ref2VA。
- 速度验证：统一内存大并不等于快，INT8 ConvRot 是否能降低生成时间，需要真机数据。
- 质量边界：如果 INT8 ConvRot 明显降低 reference 遵循度，速度提升就不能单独作为结论。
因此 benchmark 不只记录“跑了多久”，还记录输出文件是否有效、视频时长、音频流、分辨率、文件大小和失败原因。
四、Benchmark 协议
固定输出规格
| 参数 | 数值 |
|---|---|
| 输出时长 | 5 秒 |
| 帧率目标 | 24 FPS |
| 短边 | 768 |
| 音频 | AAC stereo / 32 kHz，按模型输出为准 |
| steps | 50 |
flow_shift | 12.0 |
audio_flow_shift | 3.0 |
| 输出数量 | 1 |
固定测试 case
| Case | 任务 | 分区 | 输入 |
|---|---|---|---|
t2va_text_only | t2va | FL2VA | 文本 |
fl2va_first_frame | fl2va | FL2VA | 固定第一帧 PNG |
ref2va_image_audio | ref2va | Ref2VA | 固定 reference PNG + WAV |
ref2va_video | ref2va | Ref2VA | 固定 MP4 reference |
记录指标
| 指标 | 含义 |
|---|---|
| Load result | 模型是否能完成加载 |
| Submit latency | /v1/videos 提交请求耗时 |
| Total generation time | 从提交到状态 completed 的总耗时 |
| RTF | 生成耗时 / 输出视频时长，越低越好 |
| Output validity | MP4 是否可下载、ffprobe 是否能解析 |
| Video metadata | 时长、分辨率、编码、帧率 |
| Audio metadata | 是否有音频流、采样率、声道 |
| Memory note | 加载前后系统内存、峰值内存、是否 OOM |
五、复现脚本
本仓库新增了一个可复现测试目录：
scripts/minimax-h3-benchmark/
生成固定素材：
cd scripts/minimax-h3-benchmark
python3 -m pip install pillow
python3 make_media_assets.py
启动 FL2VA：
bash serve_sglang_fl2va.sh
跑 T2VA + FL2VA：
python3 run_sglang_video_benchmark.py \
--base-url http://127.0.0.1:30010 \
--variant fl2va \
--out-dir results/fl2va
启动 Ref2VA：
bash serve_sglang_ref2va.sh
跑 Ref2VA：
python3 run_sglang_video_benchmark.py \
--base-url http://127.0.0.1:30010 \
--variant ref2va \
--out-dir results/ref2va
生成 Markdown 汇总表：
python3 summarize_results.py results
六、首批实测结果
SGLang BF16 / 官方分区启动测试
| 测试 | 命令关键参数 | 退出码 | 结果 | 备注 |
|---|---|---|---|---|
| FL2VA 官方路径 | --model-variant fl2va --performance-mode memory | 2 | 失败于参数解析 | 当前 SGLang 0.5.10+516d57ac 不识别这两个参数 |
| Ref2VA 官方路径 | --model-variant ref2va --performance-mode memory | 2 | 失败于参数解析 | 同上，未进入 checkpoint 下载或模型加载 |
实际错误：
sglang serve: error: unrecognized arguments: --model-variant fl2va --performance-mode memory
sglang serve: error: unrecognized arguments: --model-variant ref2va --performance-mode memory
这一步说明：Thor-JD 当前预装的 NVIDIA SGLang 镜像还不是 MiniMax H3 cookbook 所需的软件栈。所以后续测试没有停在这里，而是在同一个 NVIDIA 容器基础上构建 source SGLang 继续跑。
Source SGLang / FL2VA 加载实测
为了进入 MiniMax H3 分支，本轮在容器里做了四件事：
- 克隆 SGLang source，并用
PYTHONPATH=/tmp/sglang-src/python强制走源码。 - 升级 Transformers 到
5.12.1，解决transformers.vision_utils导入问题。 - 对容器内 xgrammar 兼容性做最小 patch，让 SGLang source 能完成 import。
- 通过
HF_ENDPOINT=https://hf-mirror.com下载MiniMaxAI/MiniMax-H3的 FL2VA 分区，缓存约 135 GiB。
| Run | 关键参数 | HTTP ready | MP4 | 结果 | 关键日志 |
|---|---|---|---|---|---|
fl2va-live5 | --model-variant fl2va --performance-mode memory | 否 | 否 | transformer 加载后长期不 ready | text encoder 成功加载；SGLang 报 consumed GPU mem: 57.86 GB, avail GPU mem: 11.23 GB；容器 RSS 约 98 GiB |
fl2va-live6 | --dit-layerwise-offload --layerwise-offload-components dit text_encoder vae --dit-offload-prefetch-size 0 --dit-layerwise-resident-layers 0 --warmup-mode off | 否 | 否 | OOM killed | text encoder 报 consumed GPU mem: 85.44 GB, avail GPU mem: 18.61 GB；transformer 13 个 safetensors shards 加载后 scheduler 死亡，退出码 -9 |
kernel OOM 记录：
Out of memory: Killed process 1114391 (sgl_diffusion::) total-vm:782713380kB,
anon-rss:57248772kB, file-rss:115516kB, shmem-rss:52471808kB
这轮最重要的结论不是速度，而是容量边界：单台 122 GiB、无 swap 的 Thor-JD，在当前 source SGLang + BF16 FL2VA 路径下没有完成服务启动。 这比“没测”更有价值，因为它已经跨过了参数解析、依赖、模型下载和 FL2VA 分区选择，失败点落在真实模型加载阶段。
Ref2VA 官方分区
| 路径 | 结果 | 备注 |
|---|---|---|
| Ref2VA source SGLang | 未运行 | 当前 Hugging Face 缓存里只有 FL2VA/model_index.json；Ref2VA 分区尚未下载。考虑到 FL2VA 已在加载阶段触发 OOM，Ref2VA 需要单独下载和单独记录，不能把它推断成“已测”。 |
INT8 ConvRot / 社区量化
| 路径 | Runtime | Checkpoint | 结果 | 备注 |
|---|---|---|---|---|
| FL2VA INT8 ConvRot | ComfyUI / H3 node | 未发现 | 未运行 | Thor-JD 上未发现 ComfyUI、MiniMax H3 custom node 或 INT8 ConvRot checkpoint |
| Ref2VA INT8 ConvRot | ComfyUI / H3 node | 未发现 | 未运行 | 需要先安装节点并下载具体 checkpoint，后续必须记录 hash |
| SGLang diffusion quant | source SGLang | 无 INT8 ConvRot recipe | 未运行 | 当前 diffusion runtime help 暴露的是 fp8 / mxfp4 等 transformer 量化入口，没有可直接复现的 INT8 ConvRot 参数组合 |
Abiray NVFP4 / ComfyUI 路径
2026-08-07 补测了社区仓库 Abiray/Minimax-H3-nvfp4-INT4-INT8-Convrot 的 FL2VA NVFP4 组合：
| 文件 | 大小 | SHA256 |
|---|---|---|
MiniMax_H3_FL2VA_pruned_nvfp4.safetensors | 12.5 GB | 6ab7f0c48141e7919b32f925ca3def22e06a6aebeb9e0b6f5a0be0fe8409976f |
qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors | 15.7 GB | 33e69e3edab846d52949bafdb00378bd3f5a93f78124fc83d5ef109dc4a1fcbb |
minimax_h3_audio_vae_fp32.safetensors | 605 MB | 83043bf3afccf4cab4d7e114f6e04607e9687bef16930a2f6088d721a893d3c4 |
minimax_h3_video_vae_fp16.safetensors | 5.21 GB | 88539d729fd7e9f9de765498428cd8e9152b8420317ec0e7542a362fffb7e0e1 |
这个仓库的文件末尾带有 L2P_bypass_... 标记，标准 safetensors 会报 file not fully covered。本轮保留原文件，并生成了截断尾部标记的本地 fixed copy；fixed copy 可以被 safetensors 正常读取。权重 key 中带有 comfy_quant，README 也明确它是 ComfyUI 本地推理格式，因此这条路径不是 SGLang 原生 Diffusers 分区。
ComfyUI 0.30.0 core 已内置 MiniMax H3 节点。object_info 能看到：
UNETLoader识别MiniMax_H3_FL2VA_pruned_nvfp4.safetensorsCLIPLoader(type=minimax)识别qwen3vl_32b_minimax_h3_nvfp4_awq.safetensorsMiniMaxH3ImageToVideo/MiniMaxH3SigmaShift节点可用
第一轮用宿主机 Python / PyTorch 2.5.1 提交了一个极小 smoke prompt：256x256、5 frames、1 Euler step、T2VA/FL2VA、SaveVideo 输出。模型能加载，但采样失败：
| 阶段 | 结果 |
|---|---|
| Video VAE / Audio VAE | 成功加载 |
| Text encoder | 成功加载；日志显示 14960.20 MB loaded |
| MiniMaxH3 NVFP4 DiT | 成功识别 mixed precision quantization；日志显示 11945.45 MB loaded |
| 采样 | 失败 |
| 输出 MP4 | 未生成 |
失败日志：
NVIDIA Thor with CUDA capability sm_110 is not compatible with the current PyTorch installation.
The current PyTorch install supports CUDA capabilities sm_50 sm_80 sm_86 sm_89 sm_90 sm_90a.
RuntimeError: CUDA error: no kernel image is available for execution on the device
这说明 NVFP4 方向比 BF16 更接近可用：失败点不再是容量 OOM，而是 PyTorch / CUDA kernel 架构不支持 Thor sm_110。
随后切换到 Thor-JD 本地已有的 fire-smoke-train:cu130 容器。这个镜像内的 PyTorch 是 2.11.0+cu130，torch.cuda.get_arch_list() 明确包含 sm_110：
2.11.0+cu130 13.0 ['sm_80', 'sm_90', 'sm_100', 'sm_110', 'sm_120']
在这个容器中重新启动 ComfyUI，复用同一组 NVFP4 fixed weights，重新提交同一个 smoke prompt。结果成功：
| 项目 | 结果 |
|---|---|
| 容器 | fire-smoke-train:cu130 |
| PyTorch | 2.11.0+cu130 |
| ComfyUI | 0.30.0 |
| comfy-kitchen | 0.2.26，CUDA backend 可用，包含 nvfp4 capability |
| Prompt | 256x256、5 frames、1 Euler step |
| 执行时间 | 46.21s |
| 输出 | minimax_h3_nvfp4_cu130_smoke_00001_.mp4 |
| 状态 | success |
ffprobe 元数据：
| 流 | 结果 |
|---|---|
| Video | H.264，256x256，24 FPS，5 frames，0.208s |
| Audio | AAC LC，32 kHz，stereo，0.200s |
| 文件大小 | 30,261 bytes |
这意味着：Thor-JD 可以跑起 MiniMax H3，但目前成立的是 Abiray NVFP4 + ComfyUI + Thor cu130 PyTorch 容器的 smoke test，不是 BF16，也不是完整 5 秒 50 steps benchmark。
Thor CUDA 13 / ComfyUI 快速基线
随后在同一台 Thor-JD 上继续跑了更接近真实生成的快速 benchmark。这个基线不是前文定义的 768 短边、5 秒、50 steps 正式协议，而是 Chipmark 侧用于横向比较 3090 主机的标准快速规格：
| 参数 | 数值 |
|---|---|
| 分辨率 | 608x352 |
| 长度 | 243 frames |
| Steps | 20 |
| Thor 运行方式 | Docker fire-smoke-train:cu130 + ComfyUI |
| PyTorch | 2.11.0+cu130，CUDA 13.0，支持 Thor sm_110 |
| NVFP4 FL2VA 权重 | MiniMax_H3_FL2VA_pruned_nvfp4.safetensors |
| INT8 ConvRot FL2VA 权重 | minimax_h3_fl2va_pruned_int8_convrot.safetensors |
Thor-JD 实测结果：
| Host | 模式 | Total time | ComfyUI time | Sampling time | Sampling speed | 备注 |
|---|---|---|---|---|---|---|
| thor | Docker CUDA 13 NVFP4 cold / --lowvram | 300.04s | 288.13s | 4:16 | 12.81s/it | 使用 Thor 容器 NVFP4 FL2VA 权重 |
| thor | Docker CUDA 13 NVFP4 hot / --lowvram | 300.03s | 284.64s | 4:16 | 12.82s/it | 模型 warm-up 后 |
| thor | Docker CUDA 13 NVFP4 full-vram cold | 300.03s | 294.92s | 4:15 | 12.77s/it | 不加 --lowvram |
| thor | Docker CUDA 13 NVFP4 full-vram hot | 300.03s | 282.34s | 4:16 | 12.81s/it | 不加 --lowvram，速度没有明显改善 |
| thor | Docker CUDA 13 INT8 ConvRot full-vram cold | 443.51s | 433.23s | 6:14 | 18.71s/it | 使用和 3090 基线相同的 INT8 ConvRot FL2VA 权重 |
| thor | Docker CUDA 13 INT8 ConvRot full-vram hot | 400.04s | 395.13s | 约 6:09 | 约 18.46s/it | 模型 warm-up 后 |
与 RTX 3090 CUDA 13 快速基线对照：
| Host | 模式 | Total time | Sampling time | Sampling speed | 备注 |
|---|---|---|---|---|---|
| giga3090 | CUDA 13 hot | 213.05s | 约 3:09 | 约 9.46s/it | 模型 warm-up 后 |
| rog3090 | CUDA 13 cold | 521.55s | 3:07 | 9.37s/it | 包含首次模型初始化，约 143s |
| rog3090 | CUDA 13 hot | 206.07s | 3:07 | 9.38s/it | 模型 warm-up 后 |
当前比较要谨慎解读：
- Thor NVFP4 hot 比 3090 CUDA 13 INT8 hot 总耗时约慢
1.38x-1.46x，采样速度约慢1.36x；但这不是纯硬件对比，因为 Thor NVFP4 和 3090 基线使用的 FL2VA 权重不同。 - 去掉
--lowvram没有明显提升 Thor NVFP4 速度，采样基本稳定在12.77-12.82s/it。 - 使用和 3090 相同的 INT8 ConvRot FL2VA 权重时，Thor hot 采样约
18.46s/it，约为 3090 hot9.38s/it的1.97x。
Thor 侧生成文件记录：
/workspace/ComfyUI/output/thor_minimaxh3_cu130_benchmark_cold2_608x352_len243_steps20_00001_.mp4
/workspace/ComfyUI/output/thor_minimaxh3_cu130_benchmark_hot2_608x352_len243_steps20_00001_.mp4
/workspace/ComfyUI/output/thor_minimaxh3_cu130_fullvram_benchmark_cold_608x352_len243_steps20_00001_.mp4
/workspace/ComfyUI/output/thor_minimaxh3_cu130_fullvram_benchmark_hot_608x352_len243_steps20_00001_.mp4
/workspace/ComfyUI/output/thor_minimaxh3_cu130_int8convrot_fullvram_benchmark_cold_608x352_len243_steps20_00001_.mp4
/workspace/ComfyUI/output/thor_minimaxh3_cu130_int8convrot_fullvram_benchmark_hot_608x352_len243_steps20_00001_.mp4
本轮可审计文件
本次测试留下了可审计记录：
scripts/minimax-h3-benchmark/actual-results-2026-08-06.json
scripts/minimax-h3-benchmark/results-env/
scripts/minimax-h3-benchmark/results-fl2va-live5/
scripts/minimax-h3-benchmark/results-fl2va-live6/
scripts/minimax-h3-benchmark/results-comfy-nvfp4/
scripts/minimax-h3-benchmark/results-comfy-nvfp4-cu130/
七、早期判断
现在已经可以给出一个更明确的早期结论：Thor-JD 不能稳定跑通当前 BF16 SGLang FL2VA 路径，但可以通过 CUDA 13 PyTorch Docker + ComfyUI 跑 MiniMax H3 量化权重，并已经完成 243 帧、20 steps 的快速基线。
- 基础 NGC SGLang 26.04 镜像不能直接跑 MiniMax H3 cookbook 命令：
--model-variant和--performance-mode在0.5.10+516d57ac中不可用。 - source SGLang 能把 Thor-JD 带进 FL2VA 真实加载路径：依赖修复后，FL2VA 分区可以被正确识别，text encoder 和 transformer shards 都开始加载。
- 122 GiB 无 swap 对 BF16 FL2VA 仍然不够稳：最激进的 layerwise/offload 配置仍被 OOM killer 杀掉，没有 ready，也没有 MP4。
- Abiray NVFP4 / ComfyUI 路径已经跑通并完成快速基线：Thor Docker CUDA 13 热跑约
300.03sexternal /284.64sComfyUI，采样约12.82s/it。 - INT8 ConvRot FL2VA 也已经在 Thor 上跑过快速基线：同一 INT8 ConvRot FL2VA 权重热跑约
400.04sexternal /395.13sComfyUI，采样约18.46s/it。 - Ref2VA 仍需单独测：当前 Ref2VA 分区未下载，不能从 FL2VA / T2VA 结果推断。
八、下一步
下一轮要先补齐软件栈，再补生成数据：
- 固化
fire-smoke-train:cu130+ ComfyUI 的复现脚本，避免每次临时安装依赖 - 把 NVFP4 / INT8 ConvRot 快速基线扩大到 768 短边、5 秒、50 steps 的正式 benchmark
- 记录正式生成的 wall time、峰值内存、RTF、MP4 元数据和主观质量
- 下载 Ref2VA 分区，单独记录是否能完成加载
- INT8 ConvRot Ref2VA checkpoint 的加载与生成结果，优先走 ComfyUI core MiniMax H3 节点
- 每个 case 的输出 MP4、
ffprobe元数据、生成耗时和失败日志 - 与 RTX 3090 / 4090 社区结果的横向对比
如果这些测试跑通，这会是一个非常早期的 MiniMax H3 on Jetson AGX Thor 公开 benchmark。更重要的是，它不是只给结论，而是把脚本、输入、参数和结果字段全部公开，后续别人可以复跑、纠错、补充。