在 MiniMax 于 8 月 3 日放出 H3 视频生成模型权重后，开发者社区迅速在 ComfyUI、SGLang、vLLM 等框架中完成了适配。这些方案依赖 Python 生态和 NVIDIA GPU 集群。Redis 之父 Salvatore Sanfilippo（antirez）在 8 月 10 日发布了 h3.c——一个用 C 和 Metal Compute Shaders 直接编写的 H3 推理引擎，专门为 Apple Silicon 设计，绕过了所有 Python 框架。
这不是一个 "在 Mac 上跑模型" 的概念验证。h3.c 在 M5 Max 上用 4 步去噪路径生成 512×512 分辨率的 22 帧视频片段仅需 3.5 秒，默认 20 步路径需要 16.69 秒。模型文件约 33GB，端到端生成时峰值物理内存占用约 40GB。整个项目是 antirez 一人开发，MIT 协议开源。
MiniMax H3：原生音频视频一体化生成
理解 h3.c 的工程价值，需要先看它运行的是什么模型。
MiniMax H3 是一个 331 亿参数的稠密 Omni Transformer 架构。与之前 Wan 2.1/2.2 等开源视频模型的分工模式（文本生成视频、单独的语音模型、后期拼接音频）不同，H3 在一次前向传播中同时生成画面和 32kHz 立体声音频。模型读取文本、图片、视频片段和音频片段作为统一上下文，通过自然语言指令描述这些输入之间的关系——例如"用 Video 1 的镜头运动，让 Image 2 中的人物歌唱，声轨与 Audio 3 对齐"。
H3 架构由四个关键部分组成：
上下文全模态表示（Contextual Omni Representation） 是模型的标注和注解层，将约 10 万 token 的原始素材压缩到约 4 千 token，描述上下文元素与目标视频之间的关系。这是 H3 能遵循复合跨模态指令的原因。
H3-VAE 是完全重写的 tokenizer，压缩比远超此前方案，带来约 4 倍的有效序列长度增益。这是原生 2K 分辨率在经济上可行的前提。
H3-Omni Transformer 放弃了 Hailuo-02 的架构，针对多模态上下文带来的序列长度方差，将理解和生成工作负载分离训练，报告端到端训练吞吐量提升近 30%。其中约 130 亿参数位于 AdaLN 分支中，在推理时可以预计算并缓存。
上下文内重生成（In-Context Regeneration） 取代了传统的超分辨率模块。基座模型在重新读取原始多模态上下文的同时重新生成自己的低分辨率输出，使小号文字和品牌标志在放大到 2K 时得以保留。
H3 开源了两个检查点分区：FL2VA 支持文本到视频和首尾帧生成；Ref2VA 支持联合引用最多 9 张图片、3 个视频片段和 3 个音频片段进行生成。两者共享编码器和 VAE，但 DiT 主干独立。
h3.c 的核心设计：用 Metal 着色器替代 Python 框架
h3.c 没有使用 MLX、PyTorch MPS 或任何高层推理框架。它直接调用 Apple 的 Metal Compute API 和 MPSGraph，将 H3 的 Diffusion Transformer（DiT）逐块实现为 Metal 着色器内核。整个项目以一系列可工作的垂直切片构建：先做确定性的宿主/模型元数据，再做可移植的 Metal 块一致性校验，然后是 prompt 编码和 prompt 到视频/音频的生成路径。
这种逐层 C 实现带来了框架层级省不掉的控制开销消减：
检查点内存映射。在 M5 级 GPU 上，持久 Transformer 权重直接从 safetensors 分片映射，而非复制到匿名共享缓冲区。33GB 模型保持 file-backed/reclaimable 状态，统一内存压力更低。M3 使用较快的拷贝缓冲路径。
流式 Qwen 文本编码器。H3 使用 Qwen3-VL-32B 作为文本编码器。h3.c 预分配一个小型未来层缓冲环（ring），用 8 个 I/O worker 线程在 Metal 执行当前层的同时填充后续层。环深度在 M3 上为 2 层，在 128GB 内存的 M5 上为 3 层。这种预取隐藏了 32B 编码器的层间 I/O 延迟。
Metal 4 TensorOps 原生 BF16 矩阵运算。在 M5 GPU 上，DiT 的 QKV 投影和注意力输出投影自动使用 Metal 4/TensorOps 原生 BF16 路径，序列长度上限 2048。一个 Morton 调度将 Q/K/V 直接路由为 head-major 注意力输入，避免三次 MPSGraph 输入转置。
int8 量化：从 36 秒到 19 秒
h3.c 在 M5 上的完整 int8 路径是性能差异最大的优化。路径分三层：
| 路径 | M5 Max 50 层 19 步 512×512 耗时 | 峰值张量存储 |
|---|---|---|
| BF16 MPS | 36.30 秒 | 36.4 GiB |
| int8 MLP | 25.80 秒 | — |
| int8 MLP + QKV + Attention Output | 19.32 秒 | 25.9 GiB |
int8 引擎动态量化激活值，使用逐输出通道权重缩放，对敏感的 FC2 输入给予每 1024 通道一个缩放因子。FC2 内核将缩放部分积保留在私有协作片段中，避免反复溢出 32KiB 线程组 tile。
量化的精度代价经 antirez 验证：起始、中间和最终解码帧保持了相同的主体、构图和运动，细微的边缘和毛发细节可能不同。四步狐狸测试的全视频 SSIM 为 0.919，冲浪者测试为 0.828（对照 BF16 基线）。在上传时的混合 A/B 测试中，int8-QKV-only 路径和完整 int8 路径分别产生 0.556 和 0.547 的全视频 SSIM（对照 29 步参考）。
DiT 融合内核：减少全局内存往返
h3.c 对 DiT 块内部的内核融合做了一系列优化，每项都附带了 byte-identical 验证（保证数值结果不变）和 H3_DISABLE_* 环境变量回退到分步 oracle 的 A/B 开关。
门控 AdaLN 融合。每个活跃 DiT 块将其注意力残差门与后续 MLP AdaLN 融合。舍入的 BF16 残差仍然精确写入，但同一行保留在线程组内存中用于归一化，消除一次 dispatch 和一次全局重读。在非 token 缩减边界处，MLP 残差门还产生下一个块的注意力 AdaLN，跨循环携带归一化状态。
最终片层直接绑定。音频/视频 AdaLN 内核直接绑定到残差流的偏移量，避免两次切片 blit 和 512 类几何下的 18.8 MiB 临时存储（864 类为 29.4 MiB）。BF16 最终头在加载 16×16 投影 tile 的同时应用 AdaLN，再节省 37.5/58.9 MiB。
激活缓冲别名。DiT 激活缓冲区遵循其块内实际生命周期：QKV 投影 arena 先复用于注意力头，再复用于归一化 MLP 输入；当前注意力输出 arena 在其分支被消费后成为 MLP 输出。这在不改变 dispatch 或算术的情况下移除了 512 类几何的 61.25 MiB 和 864 类的 99.63 MiB。
这些融合的叠加效果：512×512 22 帧的完整渲染中，每一步节省的内存往返和 dispatch 数量累计起来，使得 h3.c 在单台 M5 Max 上实现了原本需要多 GPU 集群才能达到的推理速度。
Token 缩减：28% 的去噪时间消减
--token-reduction 是一个可选的激进 DiT 模式。在 block 3 之后，它将相邻的水平目标视频 token 配对，同时保持文本、音频、条件和引用 token 不变。完整的全分辨率状态作为旁路保留。在前十次噪声评估中，旁路在 block 40 之前恢复；后续细节形成评估在 block 30 之前恢复。每个 token 返回其原始值加上配对学习的更新，因此配对内的细节不被丢弃。
在热平衡的 512×512×22 帧测试中，19 次 forward 的 M5 Max A/B 对比显示，token 缩减将去噪时间从 39.13 秒降至 28.06 秒（28.3%）。最终视频/音频潜变量的相对 L2 为 5.56%/15.14%。它与已验证的 --layers 45 --reuse 2 设置组合时，将该配置从 16.69 秒降至 12.60 秒（24.5% 边际）。
antirez 标注了 token 缩减的安全边界：不要将它同时与 --layers 40 和 --reuse 3 组合——那个 6.47 秒的实验产生了色环和鬼影肢体，尽管潜变量范数可接受。
速度/质量预设矩阵
h3.c 将所有控制参数暴露为独立的 CLI 标志。用户通过组合以下控制来选择速度/质量平衡：
| 控制 | 慢速参考 | 默认 | 激进 | 主要影响 |
|---|---|---|---|---|
| 去噪步数 | --steps 50 | --steps 20 | --steps 4..7 | 实际去噪传递次数 |
| 整体去噪器复用 | --reuse 1 | --reuse 2 | --reuse 3 | 20 步时：20/11/8 次新鲜 DiT 评估 |
| 活跃 DiT 块 | --layers 50 | --layers 45 | --layers 40 | 减少计算和常驻 Transformer 权重 |
| 核心残差复用 | --core-reuse 1 | --core-reuse 4 | --core-reuse 6 | 每 step 刷新 patch/head 但少跑核心 |
| Token 缩减 | 关 | 可选 | --token-reduction | 块 3 后配对水平 token |
| 内部画布尺寸 | 384 | 320 | 以更小尺寸跑 DiT/VAE 再放大 |
这些控制大多数可独立组合。--reuse 和 --core-reuse 互斥；层裁剪可与两者之一组合。最小预算（4 步）时保持 --reuse 1 以确保每次请求的传递都执行模型。
引用系统：Ref2VA 的多模态条件控制
H3 的 Ref2VA 检查点支持丰富的引用条件，h3.c 完整实现了这些路径：
首尾帧锚定（FL2VA 路径）：--first-frame 和 --last-frame 指定起始和结束画面。首图拉伸到目标画布尺寸；尾图以 aspect-cover 方式缩放并居中裁剪，与参考实现一致。
有序引用（Ref2VA 路径）：--ref-image、--ref-video、--ref-audio 可重复使用，命令行顺序保持不变。图片以 <Picture N> 方式呈现，视频片段以 <Video N> 呈现，音频以有序引用呈现。一次生成最多引用 9 张图片、3 个视频片段和 3 个音频片段。音频引用必须 2-15 秒，总共解码时长上限 15 秒，且必须与图片或视频引用组合使用。
音频处理。引用音频以 32kHz 立体声 F32 PCM 解码，通过 AudioVAE 后验均值路径编码，混合为 0.999 干净潜变量加 0.001 种子噪声，固定在音频条件时间步 1.0，打包为与视觉引用在同一旋转时间线上的 width-32 行。h3.c 修正了原始 MLX 实现中的一个 reshape 错误：MLX 原始实现交错左右声道采样，而官方 PyTorch/SGLang 路径将完整立体声通道折叠到批次维度。修正后的原生音频编码器与修正后的 MLX oracle 在真实 2 秒立体声夹具上的相对 L2 为 3.59e-6。
硬件适用性与限制
h3.c 当前验证的硬件仅限 M3 Max 和 M5 Max。其他 Apple Silicon 芯片的适配取决于 Metal 4/TensorOps 的可用性和统一内存容量。
模型各阶段分别加载和释放，因此 33B Transformer、Qwen 编码器和解码器不需要同时驻留在统一内存中。端到端生成的峰值物理内存约 40GB。在 128GB M5 Max 上，完整图+音频和嵌入视频+音频的渲染分别在 74.58 秒和 76.99 秒完成，峰值物理占用约 40.1GB，零 swap。
h3.c README 明确标注了几项不保证：
与参考 MLX 实现的数值像素一致性不被期望，因为随机数和执行引擎不同。所描绘的内容和运动应该一致。
测试硬件覆盖面窄，仅 M3 和 M5 Max。项目以 MIT 协议发布。
H3 的开源许可（MiniMax H3 Community License）存在地区限制，据第三方分析显示授权范围排除了美国、欧盟、英国和韩国。部署前需查阅许可文件确认适用性。
antirez 与底层 C 实现的传承
Salvatore Sanfilippo 于 2009 年创建了 Redis，领导该项目十余年后于 2020 年暂离。2024 年底重返 Redis，推动了 Vector Sets 类型（用于高维嵌入向量相似性搜索）和 Redis Array 类型（内存知识库与服务端正则）。2025 年 5 月发布 Vector Sets，2026 年 5 月合入 Redis Array PR。
h3.c 延续了 antirez 一贯的工程风格：底层 C 实现、最小依赖、逐层验证。项目引入了 liuliu（Draw Things 应用开发者）的部分代码，antirez 在发布时表示欢迎 liuliu 取回 h3.c 中任何有用的部分用于 Draw Things。整个推理引擎从 Hugging Face 快照的 safetensors 文件直接加载，不需要安装 Python 运行时或 PyTorch。编译依赖仅限 Xcode 的 Metal 运行时编译工具链（make 即可），FFmpeg 用于媒体输入输出。
Simon Willison 在分享 h3.c 时评论道，这类项目展示了个人开发者在 Apple Silicon 平台上能做什么。一个完整的全模态视频生成模型——文字到视频、图片条件、视频续写、音频引用——在单台 Mac 上以秒为单位生成，不经过云端往返。
来源：antirez/h3.c GitHub 仓库（MIT 协议）、MiniMax H3 模型卡、antirez 在 X 上的发布公告