一台 M5 Max MacBook Pro,下载了约 115GB 的模型文件,跑了将近 45 分钟,吐出一段画面挺像样、但配音是一堆语义混乱的伪语音噪音的 15 秒视频。这是 Simon Willison 两天前记录的一次本地实验:把 MiniMax 刚发布的“全模态生成系统”MiniMax-H3 用一个叫 minimax-h3-mlx 的 MLX 移植版,搬到自己的苹果电脑上跑通。
看起来是一次爽快的极客胜利。但往下拆三层,会发现这件事没那么干净——仓库归属可能认错了人,许可证画了一条谁都没提的地图线,量化带来的“提速幻觉”也经不起细看。
115GB和45分钟,是怎么算出来的
H3 原始 checkpoint 本身只有 69.3GB。跑起来变成 115GB,是因为多模态生成模型的运行时开销比想象中重:transformer 激活值、视频和音频的 latent、两个独立的 VAE、文本编码器状态,再加上 Metal 的缓冲区,层层叠加。这是一个合理的估算,但目前没有针对 M5 Max 跑 H3 的受控实测数据,45 分钟这个数字暂时只能信 Willison 自己的一次记录。
社区常见的直觉是:上了 8-bit 量化,模型应该更快。模型作者自己澄清得很干脆——量化主要是省显存,不提速,因为 H3 是计算瓶颈型任务,不是内存瓶颈型。换句话说,量化让这个模型“能塞进消费级设备”,但没让它“跑得快”。这也解释了为什么加了量化,45 分钟依然是 45 分钟。
- 提醒.量化省的是内存,不是时间——这条对所有想在 Mac 上跑大模型的人都适用。
仓库对不上号,你下的可能不是你以为的东西
原文标注的仓库是 PipeNetwork/minimax-h3-mlx。但公开信息显示,PipeNetwork 在 Hugging Face 上真正发布的,是 MiniMax-M3-MLX-8bit——一个 427B 参数、约 453GB 的文本大模型,和视频生成的 H3 完全不是一回事。目前已知的 H3 视频版 MLX 移植版,是另一位开发者 ddalcu 发布的 MiniMax-H3-FL2VA-MLX-Serve-8bit,需要配合他的 mlx-serve 项目运行。
这不是文字游戏,是实际会导致误装、误用的归属混乱。
没人提的那条地图线
H3 的社区许可证明确写着:美国、欧盟、英国、韩国被排除在允许使用的地域之外。在这些地区使用、复制、修改、分发和展示,字面条款上都被禁止。
Willison 的博客没提这一条,读者跟着他的命令行照抄一遍时,同样不会看到这行字。一个人在受限地区公开分享操作教程、给出下载命令、展示生成效果——这套“轻松跑通”的叙事,和许可证条款之间,存在一道原文完全没有触碰的裂缝。这不是要给谁定罪,而是提醒:下载命令能复制,合规风险不会跟着一起打包提醒你。
跑得通,不等于用得起。
“令人印象深刻”,凭什么
视频生成这条赛道,对手是 Google Veo 3、OpenAI Sora 2、快手 Kling、字节 Seedance、阿里 Wan 2.2。Veo 3 的强项恰恰是原生音视频同步,Wan 2.2 代表的是开源可本地部署路线。H3 打的是“全模态”这张牌,但目前没有出现在任何 VBench、T2V-CompBench 之类的学术基准或社区盲测榜单里,也没有和 Veo 3、Sora 2 的公平对比数据。
Willison 说效果“令人印象深刻”,是一句诚实的主观评价,但背后没有第三方基准撑腰——尤其音频质量,行业几乎没有像样的评测体系。他自己那段音频翻车的样例,恰恰说明了“全模态”这个词和真实体验之间还有距离:没读 prompt 指南,画面能打,声音就是噪音。
- 结论.本地部署前沿多模态模型,门槛从来不只是算力。算力之后还有仓库真伪、许可证地图、缺失的第三方基准——三关都过了,才轮到“效果好不好”这个问题。
热闹的是一台 Mac 就能跑出百亿级模型,冷清的是这条路上埋的雷,大多不会自己冒出来提醒你。