一个人写的推理引擎,号称能在苹果新款芯片上几秒钟生成一段视频。这不是营销稿,是GitHub上一个刚更新的项目页面——作者是antirez,也就是Redis的创造者Salvatore Sanfilippo。他最近把精力转向了一个叫h3.c的项目:让MiniMax的视频生成模型H3,原生跑在苹果自家的Metal图形接口上,不依赖NVIDIA GPU,不用云端。
这件事本身没什么可疑之处,本地跑大模型这几年已经成了一条清晰的赛道,从llama.cpp到MLX,苹果统一内存架构一直是被反复验证的“穷人算力”。但h3.c项目页面里最抓眼球的一组数字——M5 Max上3.5秒生成一段视频——目前只挂在这一份README里,没有第二个来源能核对。
h3.c做了什么
项目采用“垂直切片”式的开发节奏:先跑通文本到视频、文本到音频,再加首尾帧条件控制,再加有序的多参考图像/视频/音频输入(Ref2VA)。这几块功能目前都已经端到端跑通,眼下作者在做的是针对M3 Max和M5 Max的Metal专属性能和内存优化。
具体到速度,项目给出了一组可比对照:同样512×512分辨率、22帧的狐狸测试视频,用4步降噪(reuse=1)对比29步的参考版本,全视频SSIM画质相似度为0.556(另一位独立测试者测得0.547),在M5 Max上耗时3.5秒,而29步参考版本要26.4秒。作者本人也提示,打开预览显示(--show)会额外占用约10 GiB的临时内存,这在苹果统一内存架构下不是小数字。
数字看起来很扎实,时间、分辨率、SSIM都写得很具体。但这恰恰是问题所在——所有这些数字,来源都是同一份README,同一个人的机器。
谁验证过这些数字?没有
拆开来看,这份基准至少有三处不该被读者跳过的模糊地带。
第一,M5 Max这枚芯片本身的公开发布与型号信息,目前难以在项目之外的独立渠道核实,这意味着“在M5 Max上测得”这句话的可信度,首先取决于硬件本身的确定性,而不只是软件优化水平。
第二,MiniMax-H3作为上游模型,它的官方模型卡、参数规模、许可证条款,同样查不到公开确认信息。h3.c是一个第三方逆向实现的Metal推理引擎,如果上游模型的许可证不允许这种第三方分发或修改,项目本身就存在合规风险——这一点原作者的项目页面完全没有提及。
第三,项目页面自己也承认,这份基准跑的是非最激进配置:20步是默认值,50步才是“慢参考”,4到7步是“激进但可用”的区间。作者还专门提醒,这类工作负载对热节流(thermal throttling)很敏感,首次运行要额外承担模型加载和文件系统缓存开销——换句话说,同一台机器,不同的运行顺序都能把这几秒的差距做出明显浮动。
基准数字再精确,没有第二个人测过,就只是一份说明文档
该关心这件事的人,和该等一等的人
对已经在用Mac做视频/图像创作的开发者来说,h3.c确实提供了一条免费、开源、无需依赖云端算力的路径,首尾帧条件控制和多参考输入这些功能设计也贴近实际创作需求。这类人可以拿它当作实验工具跑一跑,但不该拿README里的秒数当作生产力承诺——不同苹果芯片、不同内存配置下的实际表现,目前还缺乏独立验证。
对MiniMax而言,自家模型被第三方做成Mac本地推理引擎,是关注度的免费放大,但也是许可证边界被测试的时刻,官方是否会表态,值得后续留意。
对已经在用ComfyUI、Diffusers这类成熟本地生成框架的用户,h3.c目前还没有和它们做过直接对比,谁快谁稳、谁的画质损失更小,现在都只能是问题,不是答案。