一个可执行文件跑通 MiniMax-H3：h3-hip.c 的纯 HIP 本地视频生成实践
本文来源： 未署名（公众号：未署名）
原文链接： https://mp.weixin.qq.com/s/VlCihtbY717xgMQ2pglpoA
发布时间： 2026-09-03 18:31
作者： 未署名 发布时间： 2026-09-03 18:31
原文作者：Alex He
摘要
不依赖 Python 与推理框架，一份 C + HIP 源码、一条 make，就能在 ROCm 上把 MiniMax-H3 的「视频 + 原生立体声」跑起来。本文讲清它的来历、环境、第一条可复现命令，以及同机前后的性能实测。
一、先
说结论
大多数本地视频生成方案，第一步是装环境：Python、虚拟环境、深度学习框架、一串版本互斥的依赖。h3-hip.c 换了一条路——它是一个原生 C 程序，GPU 层用纯 HIP 实现，编译产物就是一个可执行文件h3 。
依赖：ROCm（hipcc / libamdhip64） + FFmpeg + ICU
构建：make -j$(nproc) h3
运行：./h3 -d <MiniMax-H3 权重目录> -p "<提示词>" -o out.mp4没有 Python 运行时，没有框架版本地狱，没有服务端。想读它怎么调度 DiT、怎么解码 VAE，直接看源码就行。
二、致敬：
antirez 的 h3.c
这个项目的起点，是Salvatore Sanfilippo（antirez） 写的 h3.c（https://github.com/antirez/h3.c）。
写过 Redis 的人做推理引擎，风格是一以贯之的：用尽量少的依赖，把一件复杂的事讲清楚。 h3.c 把 MiniMax-H3 这样一个多模态视频模型——tokenizer、文本编码器、多模态打包、扩散调度、视频 VAE、音频 VAE、音视频封装——用原生 C 完整实现了一遍，GPU 部分交给 Apple Metal。
它的价值不只是「能跑」，而是可读：
- 模型结构不是被框架抽象藏起来的，而是摊开在几千行 C 里；
- 每个阶段的张量形状、时间步、latent 对齐规则，都能一路读到底；
- CLI 就是全部接口，没有隐藏的运行时魔法。
对想真正理解视频扩散模型是怎么一步步跑出来的开发者来说，这种实现比任何一篇论文复现都直接。
h3-hip.c 做的事很克制：保留 antirez 的全部主机侧结构与 CLI，只把 GPU 后端换成 HIP。
MiniMax-H3 官方权重（Hugging Face）
│
├── antirez/h3.c GPU 层：Apple Metal
└── h3-hip.c GPU 层：HIP / ROCm ← 本文主机代码、tokenizer、加载器、调度、VAE、命令行——同一套。换掉的是 kernel 与内存管理。上游怎么用，这边就怎么用。
三、环境到底有多简单
图注：由本文所述构建产物在 ROCm 上生成，864×480 / 56 帧。标题文字为后期 ffmpeg 叠加，模型本身不渲染可读文本。
依赖清单（全部）
| 类别 | 内容 |
|---|---|
| 运行时 | Linux + ROCm（hipcc、libamdhip64） |
| 工具 | FFmpeg / FFprobe（在 PATH 中） |
| 库 | ICU（libicu-dev） |
| 权重 | 官方 MiniMax-H3 BF16 checkpoint（FL2VA/，可选Ref2VA/） |
构建与自检
git clone https://github.com/alexhegit/h3-hip.c
cd h3-hip.c
make -j$(nproc) h3
./h3 --info -d /path/to/MiniMax-H3--info 只校验模型清单和设备，不会映射全部权重，适合先确认环境是否就绪。Linux 下 Makefile 默认走 HIP 后端。
四、第一条可复
现命令：fox-fast
这是上游教程里那条「第一个快速视频」的参数，也是本项目性能记分板使用的预设。建议所有人从这开始
MODEL=/path/to/MiniMax-H3
./h3 --profile -d "$MODEL" \
-p "A red fox walks through fresh snow in a pine forest. Medium tracking shot, natural winter light, realistic fur, soft footsteps and wind." \
--width 512 --height 512 --frames 22 \
--steps 20 --layers 45 --reuse 2 \
-o outputs/fox-fast.mp4 参数说明
| 参数 | 含义 |
|---|---|
| --frames 22 | 输出帧数，需对齐5 + 17×N（22 帧约 0.9 秒） |
| --steps 20 | 去噪步数 |
| --layers 45 | 保留的 DiT 残差块数（50 为完整） |
| --reuse 2 | 去噪器复用；此处实际只做11 次 DiT 评估 |
| --profile | 打印各阶段耗时与显存分配 |
图注：fox 预设输出帧。生成结果自带原生立体声音轨。
这条命令在本文实测机器上：端到端约 95 秒，其中 denoise GPU 约 28 秒。
注意：首次运行要从磁盘加载权重（T2VA 路径约 107 GiB 读取），这部分是固定成本，和 prompt 无关。
两个好用的观察开关
--show：在支持的终端里实时预览每一步去噪结果--frames-dir DIR：把每一帧解码结果写成 PPM，边生成边看
五、还能做什么
同一个二进制、同一套 CLI，支持三类条件输入：
| 模式 | 输入 | 说明 |
|---|---|---|
| T2VA | 纯文本 | 文本→ 视频 + 原生立体声 |
| FL2VA | --first-frame/ --last-frame | 首帧、末帧锚定，模型补中间运动 |
| Ref2VA | --ref-image/ --ref-video/ --ref-audio等 | 有序参考素材约束生成 |
下面几个例子都由本项目在 ROCm 上生成，仅作能力示意，不再展开命令（完整参数见仓库 README）。
图注：T2VA。864×480 / 56 帧，--layers 50 --reuse 1。原生音频包含环境风声与键盘声。
图注：Ref2VA。以两张参考图约束服装与画面风格，864×480 / 56 帧。
图注：长片测试。864×480 / 362 帧（约 15.1 秒），采用分镜式提示词。
关于长视频，实测数据值得先说清楚，避免误解：
| 时长 | 对齐帧数 | 端到端 | 其中 denoise |
|---|---|---|---|
| 约 10.1 秒 | 243 | 约 24.7 分钟 | 约 21.2 分钟 |
| 约 15.1 秒 | 362 | 约 45.0 分钟 | 约 40.4 分钟 |
长片的时间几乎全在 denoise 上，且随时序 token 数超线性增长。15 秒不是「等 15 秒」，而是「等 45 分钟」。模型上限为 362 帧。
六、性能：同机前后
对比
先讲口径，再看数字。
所有加速比，都是本项目与它自己第一次可跑的 HIP profile 相比——同一台机器、同一份官方权重、同一条 CLI。
实测机器：AMD Ryzen AI MAX+ 395 / Radeon 8060S 集成显卡（gfx1151），ROCm，v0.9.0 标签。
| 预设 | 计时口径 | 首次 HIP profile → v0.9.0 |
|---|---|---|
| fox-s2 端到端 | wall | 约 257 s → 83–87 s |
| fox-s2 denoise | HIP event | 40.3 s → 6.3–6.5 s（约 6.3×） |
| fox-fast denoise | HIP event | 95.6 s → 28.4 s（约 3.4×） |
图注：denoise GPU 时间的优化阶梯，每一级对应一次被保留的工程改动。
没有牺牲质量：fox-s2 输出 MP4 的 md5 仍是1731f95c4aa582597cf83d57f46b8f9e —— 快了 6 倍多，输出字节级一致。没有蒸馏，没有微调，没有降精度换分数。
提速主要来自三处
1. 把热点搬到矩阵核
分块 WMMA 注意力，部分 F32 计算走 BF16 矩阵指令，替换原先的标量路径。手写 INT8 tile 的上限只有 BF16 WMMA 峰值的个位数百分比，所以最后一级不是继续调参，而是换架构。
2. INT8 DiT 权重走 hipBLAS
运行时对 DiT 权重做 INT8 量化、激活保持 BF16，交给 hipBLAS 执行，并对 FC2 做分组打包，而不是全靠手写点积 tile。
3. 重新设计权重放置
这台机器 128 GB 统一内存中，BIOS 把 96 GiB 划给 GPU carveout，Linux 侧只剩约 31 GiB；而一次 T2VA 要读约 107 GiB 权重——页缓存根本装不下工作集。
于是权重改为常驻设备内存，通过可回收的 pinned staging buffer 上传，而不是去 page-lock 那个很小的主机池；AdaLN 投影提前预取，视频 VAE 在独立线程加载并与计算重叠。
这一步之后，短预设已经不再主要受 GPU 限制，NVMe 读取成了新的固定成本。这也是集成 GPU 场景与数据中心卡最不一样的地方：优化对象从 kernel 变成了内存放置与 I/O 重叠。
七、这
些数字不代表什么
工程记录要经得起追问，所以边界必须写清楚：
- 不是跨厂商评测。 这是同一个移植在同一台机器上的前后对比。上游在不同硬件上公布的是不同阶段的指标，把它们除成一个比值，混淆的是两套 GPU、两套内存系统和两种测量定义。
- 端到端会波动。 31 GiB 主机内存缓存不了 107 GiB 工作集，wall time 随页缓存状态变化，所以端到端给区间，GPU event 时间才是稳定量。
- 目前验证目标是 gfx1151。 其他 AMD 设备可能可用，但尚未达到同等验证程度——这也正是最需要社区实测反馈的地方。
八、动手试试
如果你手上有 ROCm 环境，这个项目的门槛只有三步：clone、make、跑 fox-fast。
- 仓库：https://github.com/alexhegit/h3-hip.c
- 项目页（优化过程与示例）：https://alexhegit.github.io/h3-hip.c/
- Wiki（上手与长视频说明）：https://github.com/alexhegit/h3-hip.c/wiki
- 上游致敬：https://github.com/antirez/h3.c
- 官方权重：https://huggingface.co/MiniMaxAI/MiniMax-H3
欢迎提 Issue、贴上你机器的实测数据，或者贡献新的 AMD 目标支持。
模型权重遵循 MiniMax-H3 许可证。本项目为社区开发者实践，主机与 CLI 代码沿用 antirez/h3.c。
本文转载自微信公众号「未署名」，仅供学习交流使用。
觉得内容不错？我要
