MiniMax H3 在 Mac 本地跑通了 —— 一个 144GB 的音视频生成模型,在 64GB 统一内存的 M5 Max 上真的生出了带声音的片子。这件事过去半年一直卡在”官方不支持 Mac”上,现在有人把它接通了。

这篇把整条链路拆开:为什么官方 ComfyUI 在 Mac 上装得上却跑不动、h3.c 到底改了什么、144GB 权重怎么塞进 11GB 内存、九宫格分镜该怎么用,以及动手前你需要准备的 230GB 硬盘和那台跑满 2 分半的 M5 Max。

MiniMax H3 在 Mac 本地生成的霓虹夜景样片

一、先看成果:这套流程到底能生成什么

测试机是 M5 Max,40 核 GPU,64GB 统一内存。开篇这几段样片全部是本地生成的:霓虹灯夜景里的年轻女性、雪地河岸街上的白围巾、夕阳海边步道的日本女孩,每段 5 秒左右。

MiniMax H3 在 Mac 本地生成的夕阳海边步道样片

因为开源权重走的是无审查模式,生成内容不受平台审核限制,建好流程后可以完全按自己的剧情往下做。

实测下来的两个关键数字,先摆出来:

任务 分辨率 耗时 内存峰值
生成 15 秒片段 640×480 约 10 分钟 23.7GB
生成 5 秒片段 640×480 约 2 分半 20GB 出头

这是整条流水线的形状:从一张九宫格分镜图开始,到变成一段有画面、有声音的影片。

MiniMax H3 本地部署完整工作流:九宫格加提示词经 ComfyUI 面板交给 h3.c 引擎执行

不过本机生成有一个必须提前知道的坑:直接生 10 秒或 15 秒时,画面能出来,声音却可能变成杂音。这个限制贯穿全文,后面会单独讲清楚。

二、MiniMax H3 是什么:画面和立体声一起生成

MiniMax H3 是 2026 年 7 月 31 日发布的通用型开放权重、全模态影片生成模型。它的核心突破在于画面与立体声音轨同步一次性生成。

这意味着模型把画面和原声立体声一起造出来,理论上能直接省掉后期配音和嘴型对齐的流程 —— 这也是它和同期其他开源视频模型最大的差异。想知道它在别的客户端上的表现,可以看这篇《MiniMax H3 上手实测:在 Mac / iPad 用 Draw Things 本地生成音画同步视频》,那是一条完全不同的路线。

三、两种输入模式:FL2VA 和 REF2VA

H3 有两种输入模式,不能在同一次生成里混用。

FL2VA(首帧和尾帧模式) 是最常用的:

  • 完全不放图片,直接文字生影片
  • 放一张首帧,让影片从这张图开始
  • 同时放首帧和尾帧,指定影片最后收在哪一个画面

REF2VA(多素材参考模式) 则是让模型参考角色外观、场景、动作、运镜或声音:

素材类型 上限
图片 9 张
影片 3 支
音讯 3 段
混合总数 最多 12 个

有一个容易踩的限制:音讯不能单独放,至少要搭配一张图片或一支影片。

H3 的两种输入模式:FL2VA 首帧尾帧模式与 REF2VA 多素材参考模式

选哪个?一句话:短片用 FL2VA,要做角色一致性或声音参考才上 REF2VA,代价是权重多下载 62GiB。

四、为什么 Mac 不能直接走官方 ComfyUI

H3 放出时,官方提供了 vLLM、SGLang、Diffusers 和 ComfyUI 等几条路线,主要都以 NVIDIA 显卡环境为主。

卡点出在两处:

  1. ComfyUI 建议的压缩格式在 Mac 的 MPS 路径目前不支援
  2. 官方工作流使用的 Int8 Convert 与 NVFP4 量化路径,走到 Apple Silicon 的 MPS 路径时同样会遇到相容性问题

官方的问题回报区里能看到典型案例:有人用 64GB 的 M4 Ultra 去跑,安装成功、权重载入成功,结果一按开始生成就直接报错。

所以问题不是 Mac 算得慢,而是官方 ComfyUI 这条路在 Mac 上会先撞上相容性问题。这条判断很关键 —— 它决定了后面所有解法的方向:不是去优化速度,而是换一条执行路径。

五、h3.c:Redis 作者写的 Apple Silicon 原生引擎

针对这个问题,Redis 的作者 antirez(Salvatore Sanfilippo)直接为 Apple Silicon 写了一套新的推论引擎,也就是 h3.c。开源项目,MIT 授权,GitHub 上约 2.8k 星。

h3.c 的 GitHub 仓库页:MiniMax H3 inference engine for Mac computers,MIT 许可,2.8k stars

它改的是执行方式,不是模型

h3.c 不是把 H3 改成另一个模型,也不是永久修改官方权重。它改的是执行方式:用 C、Metal 和 MPS Graph 直接跑官方模型,文字编码器、DiT、影音 VAE 分开载入。

在 M5 上,它还会利用 M5 的神经加速,对模型中的关键层做执行期 Int8 量化、少跑部分层,或者直接从 SSD 读权重同时运算。

h3.c 执行方式示意图:C、Metal、MPS Graph 直接跑官方权重,分阶段载入文字编码器、DiT 与影音 VAE

优缺点都很直白:

  • 优点:Mac 终于有一条真的能跑的本机路线,速度、内存和 Seed 都能自己控制
  • 缺点:权重很大,快速参数会交换一些细节和构图

ComfyUI 是面板,h3.c 才是引擎

这是理解后面所有操作的关键:

ComfyUI 操作面板与 h3.c 生成引擎的关系

h3.c 原本只能在终端机敲一长串指令控制。后来有人把这套操作接成了一个可以用鼠标点的 ComfyUI 面板 —— 文字、首尾画面、图片、影片和音讯参考都能直接接在画布上,解析度、秒数、步数、Seed、SSD 串流这些设定也都能存成工作流重复使用。

但要清醒一点:这不是官方完整的 H3 ComfyUI 工作流。官方的多时间点引导、局部遮罩重绘、H3 专用 LoRA 以及独立采样器和排程器,在 Mac 上并没有完成等效验证;这套面板能覆盖常用功能,但还不能像官方 NVIDIA 工作流那样自由换采样器。

六、SSD 串流:144GB 权重怎么塞进 11GB 内存

这是 h3.c 最实际的功能,它解决的不是画质问题,而是内存问题。

MiniMax H3 的权重档很大,Mac 的 CPU 和 GPU 又共用同一块统一内存。影片模型开始运算时,如果太多权重同时留在内存里,小内存的 Mac 可能还没开始生片,就先因为内存压力跑不动。

h3.c 的做法叫 SSD Streaming,通用一点的名称是权重串流或 Out-of Core Inference:模型哪一批权重等一下要用,才从 SSD 载入统一内存,算完之后再换下一批。

实测同一支 5 秒影片:

指标 关闭 SSD 串流 开启 SSD 串流 变化
内存峰值 约 20.13GB 约 11.08GB 降约 45%
生成耗时 152.6 秒 189.5 秒 慢约 24%

SSD 串流实测:内存峰值 20.13GB 降到 11.08GB,时间 152.6 秒增加到 189.5 秒

用速度换内存,这就是全部代价。

还有一个硬约束:SSD 串流不能和 M5 Int8 FC2 加速同时开启。后者是靠 Metal 4 和 TensorOps 对关键层做 Int8 量化运算来提速的。

所以取舍是二选一:

你的情况 建议
内存够(64GB 统一内存) 关掉 SSD 串流,开 Int8 FC2 加速,更快
内存有压力,或想用小内存 Mac 跑起来 打开 SSD 串流,用速度换内存

七、九宫格分镜:先定人物,再让模型演

九宫格不是 MiniMax H3 官方规定的输入,而是 AI 影片圈用来先排人物和镜头的社群技巧。做法是先生成一张三乘三的分镜图,每一格安排同一个故事的一个镜头。

九宫格分镜图:同一位长发女性在黄昏河堤步道的九种姿态与景别

这次没有先准备真人参考照,而是先用文字写清楚她的外观、服装,以及整个故事想安排的九个镜头:开场远景、走过来、脸部特写、回头笑……

这里有三个必须掰扯清楚的点:

第一,短片不一定需要九宫格。 一张人物参考图加上首帧画面和影片提示词,就可以直接开始生成。九宫格更适合长一点的故事,或者要把同一个人物拆成多段短影片的情况。

第二,九宫格不是逐秒的动作剧本,也不保证模型照着九格依次演出。 它更像是先把同一位主角、场景、服装和镜头方向,画成一张视觉分镜表。

第三,真正决定这 5 秒演什么的,还是影片提示词。 实际做法是把整张九宫格当成这段影片的第一个画面,让模型参考角色和整体画面方向;提示词只描述一个动作,比如”女生沿着海边步道走过来,然后回头看向镜头”。

如果同一个人物要跨很多支影片,更稳的流程是:先做一张主参考照和人物设定 → 再让生图模型依照这张照片生成九宫格 → 最后人工检查九格的脸、头发和服装是否一致。

八、完整流程:从装到出片

把 h3.c 跑起来,背后不只要下载模型、编译 h3.c、安装 ComfyUI,还得把 h3.c 接进 ComfyUI,这样画面上的提示词、图片和参数才能正确传过去,生成结果也才能回到 ComfyUI 里预览和存档。

手工设定这些路径极易卡住,所以实操上用的是社区整理好的 H3.c + ComfyUI 操作包:解压后双击安装器,全程只需要你选两件事。

第一步:选择安装位置

安装第一步:选择至少 230GB 可用空间的磁盘或文件夹

H3 的 FL2VA 权重本身大约 144GB,但安装和运行还要留空间,建议这颗磁盘至少留 230GB。内置空间不够的话,这一步直接选外接 SSD。

外接硬盘请用 Mac 格式(APFS),exFAT 不支持。

第二步:选择要安装的模式

安装第二步:先装 FL2VA,或加上 Ref2VA 多素材参考,额外多下载 62.16GiB

第一次建议先选 FL2VA,也就是文字、首帧和尾帧模式 —— 它可以直接文字生影片,也可以放首帧或同时放首尾帧控制影片收尾。之后要放多张角色图、参考影片或参考音讯,再装 Ref2VA,会多下载大约 62.16GiB 的参考权重。第一次不需要全部装满。

第三步:下载并安装

安装器会从固定版本的官方来源下载 H3 模型、下载 h3.c 源码并在这台 Mac 上编译,再建一套独立的 ComfyUI 目录、h3.c 操作节点和本次使用的工作流。

第四步:自动检查

安装后自动检查:h3.c --info 确认权重布局,ComfyUI 节点载入选 HTTP 200

安装结束后它会做两件事:先用 h3.c --info 检查模型布局,再短暂启动一次新的 ComfyUI,确认 H3NativeVideo 节点真的载入。两项都通过,才代表这套目录里的 h3.c、官方模型和 ComfyUI Bridge 已经接好。

如果你担心操作包的安全性:里面的安装脚本、ComfyUI 节点和工作流源码都会一并提供,都是纯文本,可以用「文字编辑」逐行打开看它会做什么;H3 模型仍然从官方 Hugging Face 下载,不会直接被打包进压缩档。

macOS 拦截提示怎么办:双击 .command 时系统可能提示「Apple 无法验证是否为恶意软件」。这是因为没有向 Apple 付费签章,不是文件有问题。做法是:在警告窗口按「完成」(不要按「丟到垃圾桶」)→ 打开「系统設定 → 隱私權與安全性」→ 往下捲到「安全性」→ 按旁边的「強制打開」。或者更省事:在终端机里敲 bash 后跟一个空格,把 .command 文件从 Finder 拖进终端机,按 Return 执行。

第五步:生成第一支影片

双击启动器,它会印出这台 Mac 的本机网址并开启 ComfyUI。第一次先载入 FL2VA 基本工作流,选择首帧图片、贴上影片提示词,确认解析度、秒数和 Seed,按下 Queue Prompt 就会开始生成。

ComfyUI 里的 H3 Native Video 节点:首帧、提示词、时长 5 秒、124 帧、24fps 等参数一览

底下真正负责生影片的仍然是 h3.c,ComfyUI 在这里负责把原本的终端机指令变成操作面板 —— 你可以用鼠标调整参数、排队、取消、预览和储存。

之后每次使用只要双击启动器,不需要重新编译 h3.c,也不需要重新设定模型路径。

九、Mac 上的已知限制:超过 5 秒声音就崩

这一条必须单独拎出来说。

实测下来,在这台 Mac 的 h3.c 环境下,直接生成超过约 5 秒的片段时,声音品质仍有已知限制,可能直接变成杂音;画面却还是正常的。这就是前面 15 秒测试”画面能出来、声音变杂音”的根本原因。

所以本次实测把一段 5 秒的影片当成主线,不把 10 秒剪接流程纳入。5 秒是这台机器上的实用甜点,而不是模型能力的上限。

另一个小细节:成片开头会先闪一下九宫格。

成片开头会闪一下九宫格,直接剪掉这个开头即可

处理方式就是直接剪掉这个开头。之后的画面就是正常生成的影片内容。

十、老司机版本:本地 LLM 写分镜 + 本地生图拼九宫格

想让九宫格更可控,可以把整条链路也搬到本地:

  1. 先用本机 27B 无审查语言模型写好九个镜头的提示词
  2. 再用本机无审查生图模型分别生成九张单镜头图
  3. 用 Photoshop 或 Python 脚本拼成三乘三九宫格
  4. 最后把九宫格放进 h3.c 生成影片

可以用的模型:

至于最后影片内容的具体动作提示词,还是得靠自己的情节设计。本地跑大模型这摊子怎么铺,可以参考《MiniMax M3.1 Flash 实测:70 亿 Token 主力模型与 Agent 自动剪辑实践》。

十一、你的 Mac 到底能跑哪个模型

开源模型进展很快,不同 Mac 芯片、内存大小,适合的模型完全不一样。144GB 的 H3 只是今天的选择,明天可能就有更小的版本。

有一份 Mac 模型指南可以按你的情况查:选好 Mac 芯片和内存,再填上用途和使用情境,它会列出你这台机器跑得动的模型版本,每个都附中文说明,包括用了什么技术、代价是什么。

Mac 模型指南:选芯片、内存和用途,列出这台 Mac 跑得动的模型

目前它只能列出”你能用的模型”,还不会自动挑出最适合的那一个;邮件更新通知功能也还没正式启用。

总结

MiniMax H3 在 Mac 上跑通这件事,技术上并不神秘:官方 ComfyUI 因为量化和 MPS 路径的相容性问题在 Apple Silicon 上走不通,h3.c 就用 C + Metal + MPS Graph 另写了一条执行路径;144GB 权重塞不进小内存 Mac,就用 SSD 串流把权重一批一批从硬盘换进来,内存峰值从 20GB 降到 11GB,代价是多花 24% 的时间。

真正需要记住的结论有四条:

  • 官方 ComfyUI 在 Mac 上跑不动,是兼容性问题,不是性能问题 —— 别再往调参方向死磕
  • SSD 串流和 Int8 FC2 加速二选一 —— 内存够就关串流换速度,内存紧就开串流换内存
  • 九宫格是视觉分镜表,不是动作剧本 —— 决定 5 秒演什么的永远是提示词
  • Mac 上 5 秒是实用上限 —— 再往上画面还行,声音会崩

动手前先确认三件事:这台 Mac 是 Apple Silicon、有 Python 3.10 以上和 FFmpeg、磁盘至少空出 230GB。

相关工具:

如果这套 h3.c 流程对你有用,欢迎在评论区留下你的机型、内存大小和跑出来的效果,其他人就能照着判断自己的 Mac 能不能跑。也别忘了看看《MINIMAX H3 武打视频生成工作流:12G 显存跑开源视频模型的工程拆解》和《RTX Spark 该不该买:128GB 笔记本对比 2 张 L40S 的回本账》—— 一个讲显存怎么省,一个讲显存要不要买。