256G 的 M5 Ultra 跑 MiniMax H3:7 分钟,还是 1 小时?
-
-
-
256G 的 M5 Ultra 跑 MiniMax H3:7 分钟,还是 1 小时?
同一台机器,同一个模型,差距 10 倍。差距哪来的。

TL;DR
- M5 Ultra 256G + ComfyUI,MiniMax H3 生成 5 秒视频(864×480):7 分 0 秒
- 勾选工作流里一个 Turbo 开关:3 分 6 秒,提速 2.25 倍
- 我另外把 antirez 的 h3.c 原生引擎在本机编译跑通了:同形状 5 秒片子端到端 2 分 1 秒,比 ComfyUI 标准路径快 3.5 倍——但作者 README 里"512² 二十几步 20 秒"那种数字是 M5 Max + int8 路径的,我这台跑的是 BF16 权重,别直接抄
- 社区里同样跑 ComfyUI 的 Mac 用户:9 秒片子跑 1 小时,15 秒片子跑 1.5 小时
- 一张桌面 RTX 5090 同形状只要 2 分 26 秒——ComfyUI 路径我们慢 2.8 倍
- 差距不在芯片,在配置和引擎。 这篇文章就是把我踩完坑之后的完整配置、实测数据和 h3.c 原生引擎实测摊开给你抄。
1. 先交代机器和口径(不然对比都是耍流氓)
项 值 机器 Mac Studio(M5 Ultra),36 核 CPU + 80 核 GPU,256G 统一内存 系统栈 ComfyUI Desktop 1.1.8 / 引擎 0.43.0 / torch 2.12.1 / MPS 模型 MiniMax H3(int8_convrot DiT 19.5G + int8 文本编码器 25.9G + fp16 视频 VAE) 任务 文生视频 864×480、5 秒、24fps、124 帧 计时 引擎日志 Prompt executed(端到端)+ tqdm(采样)规则 每项跑 2 次,冷启动和稳态分开记;同 seed 会被缓存返回 0 秒假数据,必须换 seed 一个背景冷知识:官方性能基准工具 comfyui-benchmark 在 Mac 上是半残的——它的遥测线程只认
nvidia-smi。Mac 上老老实实从日志抓Prompt executed in X seconds和 tqdm 步时,就是最可靠的数据源。2. 成绩单(ComfyUI 路径)
场景 总耗时 采样 每步 备注 H3 标准 20 步(冷启动) 7 分 4 秒 6 分 12 秒 18.6s 模型加载 ~51.4G H3 标准 20 步(稳态) 7 分 0 秒 6 分 31 秒 19.6s 模型驻留,加载 0 H3 Turbo 8 步(稳态) 3 分 6 秒 2 分 39 秒 19.9s 提速 2.25× Z-Image Turbo 1024² 8 步 6.3 秒 5.8 秒 0.73s 生图对照组 H3 768p(1344×768) 未测完 — 79.1s 预估 26 分钟,主动放弃 
三个值得注意的点:
- 256G 内存的真实价值:冷启动只比稳态慢 4 秒。51.4G 的模型全家桶,统一内存 + mmap 让它们常驻,切换模型不用反复重载——这是大内存机器最被低估的体验优势。
- Turbo 的收益全部来自步数:单步耗时 19.6 → 19.9s 基本没变,20 步变 8 步,总时长直接砍 60%。开关就在官方工作流子图里("Enable Lightning LoRA"),勾选即可,不用手动挂 LoRA。
- 768p 是另一台机器:每步 79.1s,是 480p 的 4 倍——扩散模型的计算量随 token 数超线性增长,想上 720p 请把心理预期乘 4。
3. 三层世界:把 H3 放回全硬件坐标系
跨硬件比较先立规矩,统一归一化:
N = 端到端秒数 ÷ (步数 × 每帧百万像素 × 卡数) 单位 s/(步·MP·卡)
硬件 5 秒视频耗时 N 相对本机 4× H100 80G 13.25 s 0.06 快 768× 8× B300 74.38 s 0.18 快 274× h3.c 原生 Metal(M5 Max)¹ 26.4 s 5.3 快 9.3× 1× RTX 5090 桌面(ComfyUI)² 145.9 s 17.59 快 2.8× 1× RTX 4090D(int8+Sage) 174.9 s 8.47 快 5.8× DGX Spark GB10 128G 255.8 s 30.84 快 1.7× 本机 M5 Ultra(ComfyUI 稳态) 420 s 49.3 基准 本机 M5 Ultra(h3.c 原生) 121 s ≈14.2 快 3.5×(见第 4 节) M4 Max 128G(社区,15s 片等比) ≈1.5 h — 慢 ~12× M5 Pro 64G + GGUF(社区,9s 片) >1 h — 慢 ~8× ¹ 512²×22 帧参考质量档。 ² 与本机完全同形状(864×480/124帧/20步)直读,无需换算:每步 5.3s vs 本机 19.6s。
数据来源:SGLang 官方 H3 cookbook、NVIDIA Sol Engine、antirez/h3.c README、HN 49252179、zenn.dev 实测;h3.c 原生一行为本机实测(见第 4 节口径)。
读表要点:本机跑 ComfyUI 比一张桌面 5090 慢 2.8 倍;换 h3.c 原生引擎后反超 4090D、逼近 5090;比 M5 Max 上的原生 int8 参考档仍慢约 2.7 倍——差距主要在 int8 算子。而比社区里同样跑 ComfyUI 的 Mac 同行快 8-12 倍。你在哪个梯队,取决于配置和引擎。

4. h3.c 原生引擎实测:同一台机器再快 3.5 倍
antirez(Redis 作者)开源了一个纯 C + Metal 的 MiniMax H3 推理引擎 h3.c,不走 PyTorch、不走 ComfyUI。我在本机 clone 源码、静态审过之后编译跑通,做了完整验收。
4.1 怎么测的
- 本机
make构建,加载 BF16 权重(README 里的 int8 加速档是作者自己在 M5 Max 上测的,我这边没跑 int8 路径——下面所有数字都是 BF16) - 任务与 ComfyUI 完全同形状:864×480、124 帧、24fps、5.17 秒
- 连跑 3 条做稳态复现测试(同提示词 2 条 + 参考条件 1 条)
4.2 用时
项 数字 单条端到端(含加载) 约 2 分 1 秒 对比 ComfyUI 标准稳态(7 分 0 秒) 快 3.5 倍 对比 ComfyUI Turbo(3 分 6 秒) 快 1.5 倍,且不用挂 Lightning LoRA 三条连跑总时长 约 60 分钟(含一次交互会话 stdin 管道挂死的排查重跑;纯生成远少于这个数) 诚实口径:2 分 1 秒是端到端墙钟(含权重加载与 VAE 解码),采样时间没有单独打点;h3.c 是交互式会话,复用加载后的进程还能更快。
4.3 质量:两级验收都过了
第一级:确定性机器指标(ffmpeg 解码灰度帧 + numpy,三条抽样首/中/末帧):
- 帧像素 std 23–52,无死帧(std<1)、无全黑/全白/NaN 特征,min/max 覆盖 0–255 正常动态范围
- 径向 FFT 高频能量比 0.27–0.30,三条高度一致,无噪声污染特征
- 跨文件中帧像素差 mean|diff|:同提示词两条之间 11.8(复现性好),与不同参考条件的对照条约 29(差异符合预期)
第二级:人工验收:三条片子人眼对比,"差不多,没看出来差别太大"——同引擎同提示词下输出一致、不漂移,这正是稳态复测的目标。
结论:h3.c 原生引擎在本机连续生成可复现、产物无损,验收通过。
4.4 对照作者 M5 Max 的参考数字(别跟我M5 Ultra搞混了)
档位(512²×22 帧,20 步) 耗时 BF16 36.30 s int8 25.80 s int8 + int8 QKV 19.32 s 再加 attn-out-proj int8 19.18 s 另外几个实测特性:4 步少步数去噪约 3.5s(vs 29 步参考 26.4s,SSIM 0.556,质量换速度很激进);SSD 流式加载把 DiT 驻留内存从 36.5 GiB 压到 2.0 GiB,代价是 864×480 下前向慢 26%——24G 显存以下的 Mac 也能跑 H3 靠的就是它。
4.5 三条片子同框对比
ComfyUI 标准 7分0秒 ComfyUI Turbo 3分6秒 h3.c 原生 2分1秒 |

|

|

|5. 为什么慢:两个反直觉的真相
真相一:扩散模型是 compute-bound,大内存救不了速度
统一内存让很多人以为"内存大 = 快"。错了一半:
- 内存大决定跑得起来(H3 全家桶 48G 权重,24G 显存的卡根本装不下)
- 速度由算力决定。扩散模型每步都要把全部权重过一遍全矩阵乘法,batch=1 就已打满 GPU——ComfyUI 作者 comfyanonymous 原话(issue #12426)
- 实证:M2 Ultra 128G 跑 HunyuanVideo 53 分钟,RTX 3060 12G 只要 20 分钟——显存只有对方 1/10 的卡快了 2.6 倍
所以"多开队列提吞吐"在 Mac 上也是伪命题:GPU 已经满了,多开只会排队。
真相二:Mac 上的 int8 是"假 int8"
我在 ComfyUI 里选了 int8 权重,以为在跑 int8 算力。查了源码才发现:
supports_int8_compute()对 MPS 返回 False- PyTorch MPS 后端 87 个算子里没有 IntMM,
torch._int_mm直接NotImplementedError - 现在的 int8 = 权重存 int8、算时反量化成 fp16:内存省一半,算力一点不省
这正好解释了第 3 节的表:h3.c 作者用 C 手写 Metal int8 kernel,同代 M5 Max 上 512² 档从 BF16 的 36.3s 干到 int8 的 19.3s——int8 算力本身就有近 2 倍收益,只是 PyTorch MPS 给不了你。comfy-kitchen PR #249 正在给 MPS 补这块(H3 INT8 从 38-74 s/step → 8.4-11.8 s/step),合入后 ComfyUI 路径的速度故事要重写,值得盯。
彩蛋:Mac 上 bf16 比 fp16 慢 1.75 倍(走模拟路径),VAE 用 bf16 比 fp16 慢 5-10 倍(官方 PR #16996)。"新精度更快"在 Mac 上不成立——这也是我 VAE 坚持用 fp16 的原因(int8 VAE 在 Mac 上直接报错,bf16 VAE 慢到没法用)。
6. 抄作业:Mac 跑 H3 的正确配置
DiT → minimax_h3_fl2va_pruned_int8_convrot (int8 省内存) 文本编码器 → qwen3vl_32b_minimax_h3_int8_convrot (必须 int8,nvfp4 是 N 卡专属) 视频 VAE → fp16 (int8 报 _int_mm 错,bf16 慢 5-10×) 音频 VAE → fp32 速度 → 工作流里勾选 Enable Lightning LoRA(8 步 Turbo) 常驻 → 别手动卸载模型,256G 装得下全家桶,切换零成本想再快一档:clone h3.c 源码,静态审完
make编译,BF16 权重直接跑——同形状端到端 2 分 1 秒,比 ComfyUI 标准路径快 3.5 倍。第三方引擎,先审后装,别裸跑。生图侧顺带一句:Z-Image Turbo 在 Mac 上是速度比较快的模型——bf16 原生、无量化坑、1024² 出图 6.3 秒,8 步直出。Mac 用户想快速出图先玩它,但别比质量。
7. 结论
- Mac 能不能跑视频生成? 能,而且配置对了是"好用"级别:ComfyUI Turbo 3 分钟,h3.c 原生引擎 2 分钟出一条 5 秒片子。
- Mac 适合当视频主力机吗? 看预算。同预算的 5090 桌面机(ComfyUI 2 分 26 秒)仍略快于本机 h3.c(2 分 1 秒基本打平),而且 N 卡的 int8/SageAttention/EasyCache 优化生态全都能用;但 Mac 靠 h3.c 已经从"不能用"进到"能上桌"。
- Mac 的正确定位:生图主力(Z-Image 6 秒一张快)+ 视频尝鲜 + 开发验证。256G 内存买的是"跑得起来 + 多模型常驻",不是"跑得比 N 卡快"。
- 下一个值得等的东西:comfy-kitchen PR #249 的 MPS int8 kernel。合入后 ComfyUI 跑 H3 有望进入 10s/it 时代,那才是质变。
实测环境:Mac M5 Ultra 256G / ComfyUI 0.43.0 / torch 2.12.1;h3.c 本机源码构建(BF16 权重),2026-10-31 至 11-01。所有数字来自引擎日志与产物落盘的原始记录,测试脚本与原始数据可复现。对比数据来源见文中说明。
-
@cc-tgo 我最近也在关注M5 ULTRA,一直纠结的就是comfyui和H3在M5上的速度问题,可能是出货量的原因,目前能获得的实例很少,但通过有限的资料看对M5 ULTRA的神经元加速还是支持不好,没有充分发挥性能,导致速度不理想。看了大哥的评测,是不是可以理解,已经有能完全适配M5神经元加速跑原生FB16的方案了,且速度比4090D还快?如果是这样,那96G满血版就很有性价比了。
-
@liu-big comfyui对mac的支持个人体感不是很好。目前在用mlx-serve推理平台,跟oMLX比更优,同时直接支持生图,生视频,生音乐。给你一个参考数据,我用的mlx-serve平台,模型使用MiniMax-H3 (Hailuo 3.0) 8-bit — video + native audio跑16步,生成960×544分辨庇率 / 260帧 (10.8秒视频时间) 总耗时表现7分54秒。
下面是生成视频截图

-
-
-
-
-
版主审定:本帖设为优秀,作者 +3 积分奖励,继续加油!
本帖由优秀升级为精华(两者互斥,只补差价),作者 +3 积分,累计 6 分。