MiniMax-H3 是当前开源生态里体量最大的视频生成模型之一：33.1B 参数的全能 DiT 主干 + Qwen3-VL-32B 文本编码器，BF16 全量权重接近 500GB，一次推理要在显存里同时装下视频 DiT、音频 DiT、双 VAE 和一个 32B 的文本编码器。这类模型过去默认跑在 A100/H100 集群上。
这次我们把它搬到了摩尔线程 MTT S5000 的八卡节点上，用 sglang 服务化部署，完成了文生视频（t2va）、图生视频（fl2va）两类任务的端到端验证和性能基线，参考生视频（ref2va）则定位到了一个通信层缺陷。这篇文章记录全过程：哪些顺利、哪些踩坑、数据到底怎么样。
任务 | 状态 | 速度（50 步去噪） | 推荐配置 |
|---|---|---|---|
t2va 文生视频（768p / 8.7s） | 验证通过 | 3.79 s/step（3min08s/条） | bf16_opt + vae_opt + pin=True |
fl2va 图生视频（768p / 8.7s） | 验证通过 | 3.52 s/step（2min59s/条） | 同上 |
t2va 15s 长视频 | 验证通过 | 10.46 s/step（8min32s/条） | MCCL 通用 A2A（唯一可行路径） |
ref2va 参考生视频 | 受阻 | — | MCCL 通信缺陷，见后文定位 |
端到端看：权重常驻后的连续推理约 3.5 分钟出一条 768p 成片；冷启动（含权重加载）约 10.5 分钟。对一款半年前还被认为”国产卡跑不动”的模型规模来说，这个可用性已经超出我们预期。
项目 | 配置 |
|---|---|
GPU | 8 × MTT S5000（每卡 80GB，PCIe 16x，ECC on） |
驱动 / SDK | mtgpu Driver 3.3.8-server / MUSA 4.3.8 |
CPU / 内存 | 192 核 / 1.0 TiB（另配 300GB swap） |
部署框架 | sglang 0.5.6 定制版（torch 2.9.0 + torch_musa） |
并行策略 | 8 卡 SP/Ulysses，MCCL A2A 通信 |
两个部署细节值得提前说。第一，权重放本地盘而不是共享存储：直接读 quarkfs 会让页缓存占用失控，H3 全量 BF16 权重约 498.5GB，本地 SSD 副本是稳定运行的前提。第二，300GB swap 不是可选项：8 个 rank 并发加载权重时 CPU 内存峰值接近 1008GB，1TB 内存的机器也会被顶满。
t2va 文生视频
配置 | s/step | 49 步总耗时 | 相对加速 |
|---|---|---|---|
baseline（无 TileLang 优化） | 4.71 | 3min50s | 1.00× |
bf16_opt（TileLang 开启） | 3.79 | 3min08s | 1.24× |
full_resident（DiT 常驻，VAE offload） | 3.94 | 3min13s | 1.19× |
15s 长视频（13664 tokens） | 10.46 | 8min32s | — |
TileLang BF16 算子优化是这次最干净的收益：t2va 从 4.71 降到 3.79 s/step，提速约 24%，且通过环境变量 MINIMAX_H3_BF16_OPT=0/1 一键开关，A/B 对比可直接复现。fl2va 的同类收益（+4.3%）被 H2D 搬运耗时部分掩盖，后面细说。
fl2va 图生视频：一个值得展开的取舍
配置 | s/step | 状态 |
|---|---|---|
bf16_opt + pin=True | 3.52 | 通过 |
baseline + pin=False | 9.16 | 通过 |
bf16_opt + pin=False | 8.78 | 通过 |
full_resident | — | 失败（TextEncoding 阶段显存耗尽，78/80GB） |
pin_cpu_memory 这个开关是整个适配里最纠结的取舍：
- pin=True：主机到设备的搬运快，fl2va 3.52 s/step；但 pinned buffer 被驱动代理到显存，8 rank 并发时偶发 OOM，我们复现了 4 次。
- pin=False：稳定无 OOM，但速度慢 2.5 倍（3.52 → 8.78 s/step）。
当前生产建议是 pin=True + 单任务串行 + 失败自动重试，用调度层面的串行化换取算子层面的满速。等 pinned memory 实现修复后再重新评估。
15s 视频在 H3 里意味着 13664 tokens 的大序列。默认的 tilescale 路径在初始化阶段就 OOM——A2A 通信缓冲区单卡就超过 80GB，直接撞墙。切到 MCCL 通用 A2A 路径后跑通，实测 10.46 s/step，单条 8min32s。
这不是优化问题而是结构性约束：序列长度翻倍时，通信缓冲区的增长不是线性的。长视频场景在当前硬件上的唯一可行路径就是 MCCL 通用 A2A，速度换可用性。
参考生视频（ref2va）是 H3 最有想象力的能力——最多 9 张参考图锁定角色形象，但它也是这次唯一没能跑通的任务。5 种配置全部失败，失败点高度一致：MiniMaxH3DenoisingStage 的第一个集合通信处超时，内核日志伴随 GPU0 显存上下文被强制销毁。
RuntimeError: MCCL error in: /home/torch_musa/torch_musa/csrc/distributed/MCCLUtils.cpp:48,unhandled musa error, MCCL version 2.11.4
mtgpu 0000:2a:00.0: force destroy app memory context关键的对照实验是：t2va 和 fl2va 用同一套 8 卡基础设施、同一镜像、同日运行，全部通过。ref2va 区别于它们的三个特征——双塔结构（video_dit + audio_dit + dual_tower_bridge）、长序列（A2A 时 seq_lens 达 6328×8）、direct_peer 通信路径——每一个都指向通信层。
我们逐一排除了其余变量：prefetch 1/2 均失败、TileLang/tilescale 开关全开全关均失败、官方 ref2va 专用环境变量修正后仍失败、GPU 残留上下文和 host 内存峰值都已验证排除。结论高度收敛：MCCL 2.11.4 在”长序列 alltoall + 双塔”通信模式下的缺陷，或 mtgpu 驱动 3.3.8-server 在该模式下的显存管理问题。完整证据链（含 37 处 MCCL error 全栈）已整理成 bugreport 提交。
作为参照，同样的 H3 满血模型在 RTX 5090 单卡（4 步 turbo LoRA + ComfyUI）上跑 768p/5s 约 75 秒/条。S5000 八卡跑的是 50 步满血去噪，口径不同不能直接比，但两点可以确认：一是国产卡跑通 33B 视频模型的端到端链路已经没有根本障碍；二是算子层优化空间还很可观——TileLang 的 24% 只是把最容易的收益摘了。
这次适配从环境部署到端到端出片用了一天，性能基线和问题定位三天完成。t2va/fl2va 已经具备服务化条件，ref2va 等通信层修复后即可补齐。对”国产 GPU 能不能跑视频大模型”这个问题，我们的答案是：能跑，且已经有可复现的数字。
所有脚本按环境诊断、权重下载、功能验证、性能 A/B 四组组织，共 30 个，全部数据可复现。三条实测成片（t2va 768p、fl2va 768p、15s 长视频）已随验证报告存档。