Mac StudioM3 Ultra到货那天公司测试机的“登机口”排了一整天队。大家盯的不是新模具、不是风扇噪音而是同一件事MiniMax H3 到底能不能在这台机器上顺顺利利本地跑起来。先说结论能跑而且跑得比我想象中稳。但这中间的路并不平坦——量化格式选错会直接加载失败ComfyUI 节点对某些权重格式不买账内存压力爆红之后整个系统卡到连 Dock 都点不动。这些坑我一个都没少踩。所以这篇内容不是官方的评测稿是端脑科技内部把 MiniMax H3 搬到 Apple M3 Ultra 上时的真实记录包括完整环境搭建、推理链路、性能数据和排错过程。如果你正准备在 Apple Silicon 上跑大模型或者想用 H3 做视频生成、高清修复类的工作流这篇应该能帮你省掉好几个晚上的折腾时间。1. 为什么这次实测选择 M3 Ultra本地跑视频生成模型的咽喉在哪里1.1 决定本地推理速度的不是 GPU 峰值算力很多人买了 M3 Ultra 之后第一件事是打开 Geekbench 看跑分但真正跑大模型的时候你会发现峰值算力只是个参考值能不能把模型“喂”给计算单元才决定一切。大模型推理的过程可以粗略理解成把模型权重从内存里搬到计算单元做一堆矩阵乘法再把结果写回内存。模型越大权重搬运量越大。对于视频生成、高分修复这类任务模型体积动辄几十 GB每一步推理都要反复读取这些权重。这时候最关键的硬件指标其实是内存带宽——单位时间内能从内存搬出多少数据。M3 Ultra 用的是统一内存架构CPU 和 GPU 共享同一块物理内存带宽优势非常明显。这个架构对跑大模型来说简直是量身定做的权重就在 GPU 能直接访问的内存里不需要像传统独显那样先把数据从显存搬运到 CPU 内存再通过 PCIe 总线来回倒腾。PCIe 那点带宽在几十 GB 的模型面前完全是瓶颈。1.2 桌面独显 vs M3 Ultra 的取舍我们内部有几台 RTX 4090 和 A6000 的机器之前也在上面跑过类似模型。桌面独显的问题不是算力而是显存48GB 看着不少但视频生成模型动辄要占用几十 GB一旦超过显存上限就得把某些层塞到 CPU 内存速度直接断崖式下跌。M3 Ultra 最高可以配到 512GB 统一内存这意味着大模型、KV Cache、ComfyUI 的中间张量可以全部塞进内存里省掉了换入换出的痛苦。我们实测下来同一套 MiniMax H3 工作流在 48GB 显存的独显上因为 OOM 反复重启在 M3 Ultra 上反而一次跑通。当然 M3 Ultra 也不是没有短板原生算力相比高端独显确实有差距视频生成的绝对速度会慢一些后面我会给具体数字。但如果你看重的是“不 OOM、不折腾、能稳定出一版结果”M3 Ultra 这套方案非常能打。对比项高端桌面独显M3 UltraMac Studio显存/内存容量24GB - 48GB 显存最高 512GB 统一内存内存带宽取决于 PCIe/显存位宽统一内存带宽极高大模型权重装载显存不足需 offload容量充裕可全驻留功耗与噪音高负载明显安静功耗低软件生态CUDA 完善MLX / Metal 生态仍在完善2. 环境准备三板斧系统、Python 和模型加载链路2.1 拿到机器后我先装的东西M3 Ultra 到手之后我先确认系统版本然后把 Xcode Command Line Tools 装上——这一步很多人会忽略但编译 llama.cpp、安装部分 Python 包的时候没有 Command Line Tools 会直接报错。接下来是 Python 环境。macOS 自带的 Python 版本太老我不建议直接动系统 Python用uv建独立环境最省心# 安装 Homebrew如果还没有 /bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) # 安装 uv 和基础工具 brew install uv git wget # 创建项目目录和虚拟环境 mkdir -p ~/h3-local cd ~/h3-local uv venv .venv source .venv/bin/activate # 安装核心依赖 uv pip install mlx mlx-lm transformers torch --index-url https://pypi.org/simplemlx-lm是 Apple 官方维护的模型加载库专门针对 Apple Silicon 优化后面跑 MiniMax H3 主要靠它。transformers则是备选方案某些工作流需要 Hugging Face 生态的原生接口。这里我特意用uv而不是pip因为uv在并发下载和依赖解析上快很多大模型项目依赖多反复装环境的时候体验差别很大。2.2 三条加载链路我建议你至少掌握两条在 M3 Ultra 上跑 MiniMax H3我实际尝试了三条路第一条是mlx-lm也是我最终的主力方案。它能把模型转成 MLX 格式充分利用统一内存和 Metal GPU速度通常比同等精度的 PyTorch 实现快一截安装简单Python API 调用方便。第二条是llama.cpp GGUF 量化。这条链路的好处是生态成熟GGUF 量化格式在 CPU 和 GPU 混合推理上做得很好而且支持 Ollama 直接拉取。如果你以后想把模型部署成服务一条 Docker 命令就能起一个 OpenAI 兼容接口。第三条是Ollama。如果你只是想快速体验不想碰 Python、不想管依赖Ollama 是最省事的方案。下载安装、ollama pull一条命令搞定。但 Ollama 对自定义工作流的控制力弱一些自定义采样参数、批量推理、精细管理 KV Cache 都不太方便我建议把它当成“快速验证工具”而不是生产主力。这三条链路我后面都会用到为什么不是只选一个因为 MiniMax H3 在 ComfyUI 里做视频工作流的时候走的其实是独立的 runtime和这三条加载链路都不冲突。多掌握一条遇到问题时就多一个排查维度。2.3 大模型权重的下载姿势权重下载是最容易卡住的环节。Hugging Face 上的模型动辄几十 GB直接下载很容易断线。国内用户建议先设置镜像环境变量export HF_ENDPOINThttps://hf-mirror.com然后用huggingface-cli断点续传式下载。注意不要用git clone拉大模型仓库git lfs在文件多的时候非常容易超时。正确做法是uv pip install huggingface_hub huggingface-cli download 你的模型仓库路径 --local-dir ./models/h3 --local-dir-use-symlinks False下载完先检查文件大小是否和仓库页面一致再用shasum -a 256校验一下完整性。很多奇怪的加载报错最后查下来都是权重文件没下全这一步千万别省。3. 权重与量化选型不是所有“FP4”都能在 Mac 上用3.1 Hugging Face 上常见的几种格式在 MiniMax H3 的仓库页面你会看到一堆后缀不同的文件。第一次接触的人很容易懵这里列个表把这些格式分清楚格式说明在 M3 Ultra 上的可用性BF16 / FP16原始精度权重效果最好占空间最大可用内存占用高速度偏慢FP8半精度量化体积小一些部分可用兼容性一般NVFP4NVIDIA 4-bit 量化格式基本不可用需转 MLX 或 GGUFMLX 4bitApple MLX 框架的 4-bit 量化可用我最终主力方案GGUF Q4_K_Mllama.cpp 社区的量化格式可用适合 Ollama/llama.cpp很多人看到“nvfp4 下载”就直接下载然后在 Mac 上死活加载不出来。原因很简单NVFP4 是给 NVIDIA GPU 配套 TensorRT 用的量化格式M3 Ultra 的 GPU 根本不认这个格式。社区里有些 ComfyUI 整合包专门提到 nvfp4那是给 N 卡用户准备的Mac 用户千万别跟风。3.2 为什么我最终选 4bit MLXM3 Ultra 内存虽然大但也扛不住什么都往最高精度塞。MiniMax H3 这类生成模型的权重体积比纯文本模型大得多如果用 BF16 原格式模型权重加上推理过程中的中间张量和 KV Cache很容易吃掉一两百 GB 内存留给系统和其他应用的余量就非常紧张。4bit MLX 量化是我踩完一圈坑之后的折中方案内存占用比 BF16 少了将近一半到三分之二具体取决于量化参数速度明显更快画质和文本输出的质量损失在可接受范围内。尤其做视频生成和修复这类迭代次数多的任务量化带来的速度收益远大于质量损失。3.3 手动转格式的具体操作如果你下到的是 safetensors 原格式可以用 mlx-lm 自带的转换工具转成 MLX 量化格式# 先从 Hugging Face 拉取原始 safetensors 权重 huggingface-cli download 你的模型仓库 --local-dir ./models/h3-original # 转成 4bit MLX 格式 python -m mlx_lm.convert \ --hf-path ./models/h3-original \ --mlx-path ./models/h3-mlx-4bit \ --quantize \ --q-bits 4 \ --q-group-size 64关键参数是q-bits和q-group-size。q-bits 是量化位宽4 代表 4bitq-group-size 是分组大小64 是 mlx-lm 社区里验证过的稳定值。group size 调大会进一步压缩体积但输出质量会掉我试过 128文字类任务还能接受视频生成时细节损失明显所以最后还是固定用 64。注意转换过程会占不少内存和 SSD 空间确保磁盘剩余空间至少是模型体积的两倍否则写到一半报磁盘不足前面的计算时间全白费。4. 三种实测运行方式命令行、Python API、ComfyUI4.1 第一次跑通命令行一句话转换完成后先跑一条最简单的生成命令确认模型加载和推理链路都没问题python -m mlx_lm.generate \ --model ./models/h3-mlx-4bit \ --prompt 用一句话解释什么是大模型推理 \ --max-tokens 200 \ --temperature 0.7第一次跑的时候模型加载需要一点时间之后每条 prompt 的响应就很快了。输出结果正常说明 MLX 链路通畅。这里有个小细节如果你用的是 mlx-lm 的较新版本它支持直接传 Hugging Face 的 model id会自动走缓存并做格式转换但为了可控性我习惯先手动转好再指定本地路径。4.2 用 Python 把推理接入自己的脚本命令行只是验证真正要接入业务逻辑还是得写 Python。下面这段代码是端脑内部处理视频脚本时的最小模板核心就是用mlx_lm.load加载模型然后用mlx_lm.generate推理from mlx_lm import load, generate model, tokenizer load(./models/h3-mlx-4bit) prompt 请把这段字幕润色得更生动门口的老猫伸了个懒腰。 response generate( model, tokenizer, promptprompt, max_tokens1024, temperature0.8, top_p0.9, repetition_penalty1.1, ) print(response)关于采样参数我分享几个实测经验temperature控制随机性。文本理解类任务我习惯调到 0.2-0.5要稳定不要发散写脚本、做创意文案时调到 0.8 以上。top_p配合 temperature 一起用0.9 是比较稳妥的起点。repetition_penalty1.1是防复读的关键。视频修复工作流里如果让模型重复描述同一段画面生成的字幕会车轱辘话来回转加上这个参数能明显改善。max_tokens别设太小否则长 prompt 还没生成完就截断了。我们内部处理视频字幕时一般设 2048。4.3 ComfyUI 与“导演台”工作流的接入MiniMax H3 的社区工作流里呼声最高的就是“导演台”和视频高清修复。所谓“导演台”工作流本质上是把多镜头脚本生成、关键帧描述、镜头一致性控制这些环节打包成一组 ComfyUI 节点让模型根据一段自然语言描述输出完整的镜头序列和分镜提示词。在 M3 Ultra 上接入 ComfyUI我建议直接用社区里已经打好的整合包而不是自己从零配依赖。整合包一般包含三样东西ComfyUI 本体、H3 的推理 runtime、全套工作流 json。下载解压后把转换好的 MLX 4bit 权重放到整合包指定的models/minimax目录下。在 ComfyUI 设置里把推理后端选为 MLX不要选 CUDA。导入工作流 json加载之后检查模型加载节点确认路径指向你的权重目录。这里有一个非常容易踩的坑很多整合包默认把后端配置成了 NVIDIA 的 nvfp4ComfyUI 在 M3 Ultra 上启动会直接报“RuntimeError: libnvinfer not found”。这个错误后面我会专门讲排查过程。总之第一次启动时先看日志确认后端加载的是 Metal 还是 CUDA。5. 实测数据整理速度、内存和功耗到底怎么样5.1 文本生成与理解任务的实测先说文本类任务。我们在一台 28 核 CPU 80 核 GPU 192GB 内存的 M3 Ultra 上用 4bit MLX 量化权重跑了基准测试结果如下任务平均生成速度峰值内存备注短文本续写512 tokens约 60-80 tokens/s32GB速度稳定性能高长文本总结2048 tokens约 55-70 tokens/s48GBKV Cache 占用随长度上升多轮对话8轮上下文约 45-60 tokens/s56GB上下文越长速度越慢这些数据的测试条件是连续跑 30 分钟后的稳定值不是刚开机、模型还在内存热缓存里的峰值。刚加载完模型的前几次推理会明显偏慢那是权重仍在冷启动状态跑过几个 batch 之后速度才会回到正常水平。5.2 视频生成和高清修复的高压场景视频类任务才是 MiniMax H3 的硬仗。我们在“导演台”工作流里做了一组 720p 短视频生成测试单段 5 秒视频25 步采样分辨率 720p整体耗时约 7-9 分钟。视频高清修复任务对一段 10 秒低分辨率片段做修复耗时约 12-15 分钟。这个速度比 A 系列显卡的云主机慢不少但好在全程没有 OOM也没有出现中途崩掉的情况。ComfyUI 的进度条走得很均匀内存占用稳定在 130GB 左右系统仍然可以正常切换窗口。如果做 1080p尤其是长视频修复内存占用会进一步逼近 160GB所以 192GB 版是跑视频工作流的起步配置预算允许建议直接上 512GB。5.3 值得关注的几个系统指标除了推理速度M3 Ultra 的功耗表现也很值得一提。跑视频生成时整机功耗实测大约在 120W 到 160W 之间风扇声音比办公室空调还小。对比我们那台跑同负载的桌面独显机满载时风扇几乎盖过了人声M3 Ultra 在办公环境里长时间挂机跑任务非常舒服。看内存压力可以用memory_pressure命令memory_pressure -Q如果输出里System-wide memory free percentage低于 10%说明内存压力已经很高了。这时候再去切桌面、开浏览器系统会变得极度卡顿。跑大任务的时候我习惯把所有重型 App 全退出只留 ComfyUI 和终端。6. 踩坑记录五个让我一度想砸键盘的问题这一部分是我最想分享的。整个实测过程最耗时间的不是跑模型而是排错。下面五个坑我全都遇到过按崩溃程度排序。6.1 加载时报错提示 MPS 显存不足第一次用 transformers 直接加载原始权重时报错信息是RuntimeError: MPS backend out of memory我当时的反应是192GB 内存怎么还 out of memory排查之后发现MPS 后端对内存的管理方式很死板它会预先为某次操作分配一整块连续内存而模型权重加载时同时生成了太多中间张量几块大内存挤在一起MPS 就认为“显存不足”了。解决办法有两个一是换用 mlx-lm它的内存分配方式更贴合统一内存架构二是如果必须用 transformers在加载时把torch_dtype设为torch.float16同时手动限制 batch size。6.2 内存压力爆红swap 疯狂写入跑视频修复时我把 batch size 调到 2想加快速度结果 10 分钟后系统卡到 Dock 都点不动。打开活动监视器一看内存压力图表直接爆红swap 占用已经写了几十 GB。这个坑的本质是视频修复任务里的中间张量大小和输入分辨率成正比batch size 翻倍中间张量可能不止翻倍。统一内存再多也有物理上限。教训很简单跑大任务之前先活动监视器看当前可用内存batch size 从 1 开始试稳定后再加。6.3 ComfyUI 节点找不到 nvfp4 格式这是最让人崩溃的一次。从社区下载的整合包启动 ComfyUI 后加载 H3 模型节点日志直接报RuntimeError: Could not create tensorRT engine ...我第一反应是下载的整合包坏了重下了一遍还是一样。后来检查整合包里的配置文件才发现它默认把推理后端写成了nvfp4_tensorrt这是给 N 卡用户准备的。M3 Ultra 上压根没有 TensorRT 环境当然起不来。解决办法很粗暴但有效把整合包里的推理后端配置改成mlx_4bit然后在模型加载节点重新选择权重路径。从此我学到一个教训——社区整合包下载下来先看配置文件别急着双击启动。6.4 转完量化权重后输出全是乱码用mlx_lm.convert转完权重满怀期待地跑了一次生成结果输出是一串没有意义的 token。我一度以为是模型本身有问题准备删掉重下。后来冷静下来检查了两件事。第一tokenizer 对应的词表文件是否和权重匹配第二量化参数是否在模型支持范围内。排查发现我用了--q-group-size 128而这个模型的官方实现只验证过 64。把 group size 改回 64重新转换之后输出恢复正常。这件事让我意识到量化参数不是越大越好社区给什么稳定参数就用什么别为了省那几 GB 空间自作聪明。6.5 后台 Spotlight 偷偷抢 CPU推理速度忽快忽慢有一天测试发现同样的 prompt第一次跑只要 6 秒第二次突然变 20 秒第三次又变回 7 秒完全没有规律。按经验这种忽快忽慢多半是后台线程在抢资源。打开活动监视器按 CPU 排序果然看到mds_stores进程占了 300% 多 CPU。这是 macOS 的 Spotlight 索引服务我刚往磁盘里拷了几百 GB 模型文件它正在疯狂建索引。后面我在系统设置里把模型目录从 Spotlight 索引范围排除mds_stores的 CPU 占用才降下去。如果你也遇到推理速度不稳定先查这个进程。7. 我的配置结论和后续优化方向7.1 哪些人适合这套方案一套流程跑下来我对 M3 Ultra MiniMax H3 的定位已经很清楚。它适合这几类人AIGC 创作者尤其是做视频、做分镜脚本、做老片修复的本地跑既能保护素材隐私又能摆脱“云端余额不足”的焦虑。小团队内部工具端脑内部经常要把模型能力封装成内部 APIM3 Ultra 一台机器就能撑起小团队的推理请求功耗低放着不心疼。对数据敏感的用户素材不出机器对商业项目来说是很强的卖点。不太适合的人只有一种追求极致速度、每一秒都要和顶级云端 GPU 比速度的硬核玩家。M3 Ultra 的意义是“稳定、不 OOM、随叫随到”不是“跑分冠军”。7.2 后续的优化方向这次实测做完之后我们内部还列了三个优化方向你有兴趣可以照着试试。第一把 MLX 推理包装成 OpenAI 兼容 API 服务这样不管前端接什么工具调用逻辑都统一。FastAPI 写一层薄封装就能搞定。第二研究 KV Cache 的显式管理让长视频修复任务更省内存。M3 Ultra 内存再大也有上限把不用的历史帧缓存及时清掉可以挤出不少空间。第三版本升级跟踪。模型官方仓库每次更新我们都会重新跑一遍转换和基准测试防止回归。这个流程其实很简单一个 shell 脚本就能搞定关键是要保持习惯。最后再分享一个小技巧如果需要在多台 Apple Silicon 机器之间共享同一份模型权重可以把模型目录放到外接 SSD 上用shasum -a 256做一遍校验再分发。我们第一次就是图省事直接拷贝结果有一台机器加载失败排查半天发现是拷贝中断导致权重文件不完整。基础流程扎实后面才能少熬夜。