Tools · · 2 min read

antirez wrote a MiniMax-H3 inference engine in C — 3.5s for a 4-step denoise on M5 Max, against 'a bit over an hour' for the ComfyUI GGUF path

The Redis creator published h3.c on August 9, 2026: a self-contained Metal implementation of MiniMax-H3 video+audio generation for Apple Silicon, MIT licensed, no inference libraries. It hit 971 stars in two days. The speed numbers are real but not apples-to-apples with the MLX port, and the README is unusually explicit about which knobs cost you quality.

Salvatore Sanfilippo (antirez, creator of Redis) published h3.c on August 9, 2026 — a native MiniMax-H3 inference engine for Apple Silicon written in C against Metal, with no external inference libraries. (Source: GitHub API repository metadata, retrieved 2026-08-11)

Key facts:

  • The repository is MIT licensed and had 971 stars and 46 forks two days after creation (created 2026-08-09T09:12Z, last push 2026-08-11T13:53Z).
  • It is written in C, self-contained: the only runtime dependencies are FFmpeg and FFprobe on PATH, plus Apple’s Metal framework.
  • Build is make -j8, run is ./h3 -d ./MiniMax-H3.
  • A 4-step denoise at 512×512 takes about 3.5 seconds on an M5 Max, against 26.4 seconds for the 29-pass reference render. (Source: h3.c README, retrieved 2026-08-11)
  • The default 20-step / 45-layer / reuse-2 render takes 16.69 seconds, dropping to 12.60 seconds with --token-reduction (24.5% faster).
  • Quality cost of the 4-step path is 0.556 full-video SSIM against the 29-pass reference (0.547 on an independent test clip).
  • Clean end-to-end image+audio renders completed in 74.58 seconds on a 128 GB M5 Max, at ~40.1 GB peak physical footprint and zero swaps.
  • Int8 quantization drops peak tensor storage from 36.4 GiB to 25.9 GiB by releasing BF16 weights after quantizing, and cuts a fixed 50-layer render from 25.80s to 19.32s.
  • antirez credits code from Liu Liu (Draw Things) in the repo, and has invited him to take back whatever parts are useful. (Source: @antirez on X, 2026)
MiniMax H3 system overview diagram: raw multimodal instructions feed H3-Context-IR, producing a structured context representation that drives H3-Base to a 768p video, then optionally H3-Regenerate-2K to 2K video.
The MiniMax-H3 pipeline that h3.c reimplements: context understanding, base generation, optional 2K regeneration. antirez's engine replaces the Metal execution of H3-Base end to end rather than wrapping an existing runtime. (Diagram: MiniMaxAI, official model card, 2026)

What this means if you generate video locally

1. The speed comparison everyone is quoting is not apples-to-apples — and the honest version is still impressive. The h3.c README’s 16.69-second figure is for 512×512 at 22 frames (~0.917 seconds of video). The hour-plus figures circulating on Hacker News are for much larger renders. In the thread, one user reports a ~9-second 480×864 clip at 20 steps taking “a bit over an hour” via ComfyUI with GGUF quantization on an M5 Pro 64 GB; another reports 15s at 480p taking an hour and a half on an M4 Max Mac Studio. antirez’s own reply claims “a few minutes for the same video” on a 128 GB M5 Max. (Source: Hacker News discussion, 348 points, 2026-08-11) That is roughly an order of magnitude, not the 100x you would infer by putting 16.69 seconds next to “an hour.”

2. Compare it to our earlier MLX numbers with the same caution. When we covered the MLX 8-bit port of MiniMax-H3, the measured cost was ~8.8 minutes per denoising step for a 5-second 768p clip on an M3 Ultra — 37,966 packed rows. h3.c’s headline runs are at 512×512 and under a second of video. Both projects are honest about their configurations; the mistake is yours if you cross-multiply them.

3. The tuning knobs are documented with their failure modes, which is rare. The README names six independent controls — denoising passes (--steps), denoiser reuse (--reuse), active DiT blocks (--layers), core residual reuse (--core-reuse), token reduction, and internal render canvas. It also names the combination that breaks: do not add --token-reduction on top of --layers 40 and --reuse 3, which produced colour ringing and ghosted artifacts. Rendering internally at 320×320 and upscaling to 512×512 with vImage cuts DiT time from ~15.82s to 8.02s — a legitimate trick if your output is going to be watched at small size anyway.

4. Weight residency is the technique worth stealing. On M5, h3.c maps persistent transformer weights directly from the safetensor shards instead of copying them, keeping the 37 GiB file-backed and reclaimable. Combined with the int8 path releasing BF16 weights post-quantization, that is how a 33B diffusion transformer stays inside a 40 GB footprint with zero swaps. This is the same class of trick as the AdaLN precomputation in the MLX port — the wins in local diffusion right now are memory-layout wins, not quantization wins.

Before you clone it. This is a two-day-old repository with 11 open issues and active daily pushes; the README describes itself as a sequence of working vertical slices, not a finished product. Native 128×128 canvas is unsupported. --render-width/--render-height must keep the output aspect ratio. And the honest ceiling comparison from the same HN thread: an RTX 5090 generated identical parameters in 2 minutes, because diffusion is compute-bound and Macs are not where that fight is won. h3.c makes local Mac video generation usable; it does not make it competitive.

For the hosted route to MiniMax models rather than 115 GB of local weights, see our MiniMax M3 guide. For the general local-model sizing calculus, how to run GLM-5.2 locally and how to speed up Gemma 4 with MTP cover the same trade-offs on the language side.

Sources

Source: GitHub — antirez/h3.c