Redis 之父给 Mac 写了个 MiniMax H3 本地推理引擎

Redis 作者 antirez(Salvatore Sanfilippo)近日在 GitHub 上发布了一个名为 h3.c 的项目,目标是为苹果电脑写一套原生的 MiniMax H3 推理引擎。与社区里基于 MLX 框架的移植不同,h3.c 从词法到 Metal 着色器几乎都用 C 和 Objective-C 重写,专门吃 Apple Silicon 的统一内存,让 Mac 在本地直接跑这个 33B 参数的全模态视频模型。

为什么要在 Mac 上重造一个引擎

MiniMax 在 8 月 3 日把 H3 正式开源,这是一个能同时吃进文本、图像、音频、视频、再一次性吐出最长 15 秒带原生立体声视频的通用生成模型。官方提供了 Hugging Face 权重和基于 SGLang、MLX 等的参考实现,社区也很快出现了 PipeNetwork 的 MLX 移植版。

但 antirez 选择了一条更硬核的路:不依赖现成框架,自己用 C 实现推理内核,再用 Metal 把矩阵运算落到苹果芯片的 GPU 上。这样做的好处是能精细控制统一内存的占用与复用——视频模型权重动辄上百 GB,能否塞进 Mac 的有限内存,取决于推理引擎怎么分批搬运张量。h3.c 目前仍在开发中,仓库显示它已能跑通提示词到视频、首尾帧约束,以及参考图、视频、音频的 Ref2VA 条件控制。

速度能快多少

项目 README 里给出了一组在 M5 Max 上的实测。以一段 512 像素见方、22 帧的红狐踏雪短片为基准:用默认 20 步去噪需要约 26.4 秒;而采用 4 步的激进调度,耗时压缩到约 3.5 秒,画面对照 29 步参考稿的全片结构相似度(SSIM)仍有 0.556,独立的冲浪者测试为 0.547。换句话说,用不到七分之一的时间,就能拿到一个可用、但细节更糙的预览。

模型核心是一个 33B 的稠密 Transformer(H3-Omni-Transformer),文本编码器复用 Qwen 系模型,权重以 BF16 精度常驻。在开启预览的激进配置下,峰值显存占用约 25.9 GiB(int8 估算)。仓库还提供多档预设:默认 20 步、最慢 50 步参考、最快 4 至 7 步,开发者可以一次只调一个旋钮来权衡速度与画质。

能拿来做什么

h3.c 内置了一个类似 Iris 的交互会话:启动时加载模型与分词器,之后输入提示词即可连续生成,重复提示词换随机种子时不必重新加载。它支持首帧与末帧锚定,让镜头从 A 画面运动到 B 画面,也支持按顺序追加多张参考图,标记为图片 1、图片 2,让模型据此生成「让图片 1 里的人挥手」这类指令。

分辨率方面,512×512 是被反复验证的开发尺寸,768p 级别的横竖构图也已验证,画布上限受机械限制约 768×1344。更短的 256 见方预览会自动降低空间位置编码频率,消除长镜头里出现的网格伪影。

对普通用户而言,h3.c 的意义在于把在云端排队、按秒计费的视频生成,变成在自己电脑上离线跑的一件事。代价是需要一台内存充足的 Apple Silicon Mac,以及等待项目继续打磨工程完整度。antirez 本人以把复杂系统写到极简著称,h3.c 最终能否成为 Mac 上跑 H3 的默认选择,还要看后续的内存优化与稳定性。

来源:Hacker News | antirez | https://github.com/antirez/h3.c