继 DeepSeek V4 Flash 专用推理引擎 ds4 之后，Redis 作者 antirez（Salvatore Sanfilippo）又出手了——h3.c，一个纯 C 语言写成的 MiniMax-H3 原生推理引擎，专门为 Apple Silicon Mac 打造，目标是把文本生成视频这件事从云端搬回本地。
"这个项目
正在作为一系列可工作的垂直切面构建。"antirez 在 README 里写道。从确定性测试、Metal 块级正确性校验，到 prompt 编码、prompt-to-video/audio，再到首/末帧条件控制和多模态引用——他已经把这条路从头到尾走通了。
实际跑出来的数据相当能打。在 M5 Max 上，一个 512×512 分辨率 22 帧的视频，用 4 步去噪只要约 3.5 秒，而 29 步的参考质量模式大约是 26.4 秒。开了 token reduction 之后，45 层 + reuse-2 的去噪配置从 16.69 秒砍到 12.60 秒。更激进一点——int8 量化 MLP + QKV + attention output 全开——50 层 19 个过渡的 512 渲染从 BF16 的 36.30 秒直接降到约 19.32 秒。
工程上最让人佩服的是它的自洽性。整个项目不需要 Xcode 离线 Metal 工具链——Metal shader 在运行时编译。权重加载支持 M5 上的零拷贝映射，37 GiB 的模型可以 file-backed 方式按需读取。int8 模式把峰值张量存储压到约 25.9 GiB。内存优化做到了激活缓冲区别名复用、融合 kernel、图数据缓存——这是一个在 128GB M5 Max 上端到端渲染只占约 40 GB 物理内存、零 swap 的推理引擎。
可配置的速度/质量拨盘是另一个亮点。去噪步数、DiT 层数、速度复用、核心复用、token reduction、内部画布分辨率——这些都可以独立调节，互不冲突。他还提供了一个 Iris 风格的终端交互界面：输 prompt 生成视频，!seed random 换种子，!show 预览，!save output.mp4 导出，!first/!last 设置首末帧锚定图。支持 Kitty/Ghostty 和 iTerm2/WezTerm/Konsole 的终端图形协议，可以在终端里直接预览生成的视频帧。
社区也有一些实际测过的用户。Meleagris 在 M5 Pro 64GB MacBook Pro 上通过 ComfyUI 跑 MiniMax H3："效果非常好。"他用了 Q5_K_M 量化版本，指出 Q8_0（34GB）在 64GB 统一内存下如果控制分辨率也能跑。
linzhangrun 的体验就没那么好了："128GB M4 Max Mac Studio 上生成 15 秒 480p 视频要一个半小时。已经让 Codex 去部署 h3.c 了，希望速度能提升不少。"
antirez 自己在评论区出现了，提到一个有意思的细节：MiniMax 在 AMA 中说 H3 可以支持稀疏注意力，"那会是巨大的速度提升！我正在测试一个基于他们 Reddit 帖子内容的 --sparse-attention 可选模式。"
antirez 用 C 写了 Redis，改变了互联网的基础设施。现在他用 C 写了一个视频生成推理引擎。两次都对工程界有同样的意义——把复杂的东西做到足够简单，让它能在个人设备上跑起来。