为什么要在 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