A Review Said H3 Couldn’t Run on a Mac. Then the Redis Guy Wrote One in C.

Salvatore Sanfilippo, better known as antirez and the creator of Redis, published h3.c on August 9, 2026. It is a native inference engine written in C that runs MiniMax-H3, a 33 billion parameter open-weights video and audio generation model, directly on Apple Silicon using Metal. Text to video, first and last frame conditioning, plus ordered image, video and audio references all work end to end. A four-pass render finishes in about 3.5 seconds on an M5 Max against 26.4 seconds for the 29-pass reference. Published a week earlier, an independent hardware review concluded H3 was not a supported Mac-local recommendation because no official Metal or MLX recipe existed. MIT licensed, 104 stars at the time of writing, climbing fast. Best for Mac owners with serious unified memory. Not ideal for anyone expecting a one-click app.

A hardware review published last week reached a fairly clear conclusion about running MiniMax-H3 on a Mac.

No official MPS, Metal or MLX recipe existed, according to the hardware review. No measured Apple Silicon result was available. A high-memory Mac might hold the quantized files in unified memory, but the kernels, the activation headroom and the performance were all unverified. The verdict was that H3 was not a supported Mac-local recommendation.

Meanwhile, over on the Hugging Face model card, someone had already asked when Mac support was coming. Another user told them inference speed on Mac was very bad and the full self-attention made it unusable. The reply they got was to buy better hardware.

Then somebody just did it

On August 9, Salvatore Sanfilippo published a repository called h3.c.

Native MiniMax-H3 inference for Apple Silicon. Written in C. 117 commits. Text to video with synchronised audio, first and last frame conditioning, ordered image plus video plus audio references, all working end to end.

The review was not wrong when it was published. It described the situation accurately: no recipe, no measurements, no supported path. What it could not account for was somebody deciding to build the missing piece over a weekend.

What Was Verified

Firstly, everything here came out of the GitHub API and the project’s own documentation. Nothing from memory.

One caveat on that star count. The API returned 104 twice in a row, while GitHub’s cached page render was still showing 27. At this velocity the number is stale within hours, so treat it as a snapshot rather than a fact with a shelf life.

Who Wrote It

Notably, Salvatore Sanfilippo created Redis, which is one of the most widely deployed pieces of infrastructure software in existence. He is also the author of linenoise, a tiny line-editing library used as a replacement for readline in countless projects.

The linenoise source files also sit in this repository. He is using his own library from years ago to build the interactive prompt for a video model.

That is worth pausing on, because it tells you something about the approach. This is not somebody wiring together PyTorch and diffusers. It is a systems programmer writing Metal shaders and safetensors parsers by hand, in the tradition of llama.cpp, applied to a model that nobody had made work on this hardware.

What H3 Actually Is

So MiniMax-H3 is an omni-modal generation model released as open weights. It produces video with synchronised audio from a text prompt. It also works from image or video references.

The architecture is heavy, though. A 33 billion parameter dense transformer, 50 layers, hidden size 5,376, 56 attention heads. Sitting alongside it is a full Qwen3-VL-32B encoder supplying hidden states from its 50th layer. The checkpoint on disk runs to 37 GiB.

MiniMax’s own model card says the initial open-source drop provides inference with full attention only, with the sparse attention implementation coming later. That single line explains why the Mac situation was bad. Full attention across tens of thousands of tokens on a dense 33B diffusion transformer is an enormous amount of compute. Apple Silicon has plenty of memory but far less raw throughput than a rack of H200s.

Which makes what follows more interesting than a straight port.

The Numbers From the Repository

Certainly the documentation is unusually specific, which is rare for a one-day-old project. These are the project’s own measurements, not independent verification.

A four-pass render at 512 by 512, 22 frames, took about 3.5 seconds of denoising on an M5 Max. The 29-pass reference took 26.4 seconds. Structural similarity against that reference measured 0.556 on the fox test clip and 0.547 on an independent surfer test.

Token reduction, an optional mode that pairs adjacent horizontal video tokens inside the middle transformer blocks, cut a 512 by 512 denoise from 39.13 seconds to 28.06. That is a 28.3% saving. Applied on top of the already-reduced default profile, it went from 16.69 seconds to 12.60.

Ultimately the int8 path is where the larger gains sit. On a fixed 50-layer, 19-transition 512 by 512 render, the BF16 MPS route measured 36.30 seconds. Switching the MLP to native int8 brought that to 25.80 seconds. Quantising the QKV projection took it to 19.32. Adding the attention-output projection reached 19.18.

Peak tensor storage dropped from 36.4 GiB on the BF16 path to 25.9 GiB with int8 weights.

End to end, a clean image-plus-audio render completed in 74.58 seconds on a 128 GB M5 Max, with an embedded-video-plus-audio render at 76.99 seconds. Peak physical footprint around 40.1 GB. Zero swaps.

That last detail matters more than the times. Zero swaps means the whole pipeline fits in unified memory without the machine thrashing, which is the actual difference between a demo and something usable.

The Honesty Is the Notable Part

Generally, projects at this stage publish only the good numbers. This documentation publishes the failures alongside them.

On the low-budget sampling schedule, the README lists what was tried and rejected: actual-video-sigma linear spacing, quadratic and cubic warps, exact 30-point tail subsets, mild power warps, zero-order held full-grid velocities, linear velocity extrapolation, plus RES. The tail-heavy candidates sharpened the subject but damaged motion or left a repetitive woven background.

Secondly, there is a specific warning against combining token reduction with both aggressive layer thinning and aggressive reuse. That configuration produced chromatic ringing, visible outlines and ghosted limbs, despite the numerical measurements looking acceptable.

Rendering at 256 by 256 is described as mechanically allowed for diagnosis but not a supported quality preset, because a manual test produced garbage.

There is even a correction to prior work, incidentally. The original MLX reference interleaved left and right audio samples, while the official PyTorch path folds intact stereo channels into the batch dimension. The native encoder here matches the corrected version to a relative L2 of 3.59e-6.

Anyone who read our Fresh Commits roundup knows the license column and the issue count are the fast signals on a new repo. This is the slower signal: documentation that tells you what breaks is written by somebody who expects other people to actually run it.

How You’d Use It

The interface is simply a single binary with two modes.

One-shot generation takes a prompt and writes an MP4:

./h3 --profile -d ./MiniMax-H3 \
  -p "A red fox walks through fresh snow in a pine forest." \
  --width 512 --height 512 \
  --frames 22 --steps 20 \
  --layers 45 --reuse 2 \
  -o outputs/fox-fast.mp4

Drop the prompt flag and the same binary opens an interactive session instead. It keeps the prompt conditioning, the prepared transformer and the video decoder resident in memory, so re-rolling the same prompt with a new seed skips the loading and encoding entirely. Commands include !seed random, !seconds 2, !save output.mp4 and !cache.

First and last frame anchors persist across a session:

h3> !first opening.png
h3> !last ending.png
h3> The camera moves slowly around the subject.

Additionally, there is a terminal preview mode. With --show in Kitty, Ghostty, iTerm2, WezTerm or Konsole, it displays a representative frame after every denoising transition, then all final frames when the render completes. That costs preview decode time plus roughly 10 GiB of temporary residency, which is a real tradeoff on a machine already holding 37 GiB of weights.

FFmpeg and FFprobe need to be on your path. Generated frames and 32 kHz stereo audio are piped through concurrently, so no intermediate uncompressed file gets written.

The Dials You Actually Turn

Six controls trade speed against quality. All are documented as independent unless noted.

Denoising passes run from 50 at the slow reference down to 4 for aggressive previews, with 20 as the default. Whole denoiser reuse computes fewer fresh evaluations and extrapolates the rest. Layer thinning runs 40 or 45 of the 50 transformer blocks, which reduces both time and resident weights. Core residual reuse refreshes the patch and head work every step while running the expensive core less often. Token reduction pairs video tokens inside the middle blocks. Internal canvas renders smaller then upscales with vImage.

The layer thinning implementation is smarter than a straight cut. It ranks the checkpoint’s actual AdaLN gates while protecting the structurally important first and final blocks, then drops the unused weights entirely rather than skipping them at runtime.

Resolution has hard limits, obviously. Width and height must each be multiples of 32. Their product cannot exceed 768 by 1344 pixels. The project marks 512 square as the safest development size and 768 square as validated close quality.

Duration is quantised too. H3 emits 24 fps and rounds frame requests upward to a legal shape, so 22 frames gives 0.917 seconds, 243 gives 10.125, then 362 gives 15.083. Asking for 10 seconds gets you 10.125.

What This Costs You

Nothing in dollars. Rather a lot in hardware.

The 37 GiB checkpoint has to live somewhere. On M5 hardware the weights get mapped directly from their safetensor shards rather than copied into anonymous buffers, which keeps the file reclaimable by the OS. M3 uses the older copied-buffer path.

Meanwhile the benchmark machine throughout is a 128 GB M5 Max. Peak physical footprint on a full render was about 40.1 GB. A 64 GB machine would need the int8 path plus probably aggressive layer thinning. Nothing in the documentation claims that configuration has been validated.

Finally, there is a thermal warning worth taking seriously. The documentation says to compare performance using repeated runs and to alternate variants while machines warm up, because the workload is sensitive to throttling. Anyone benchmarking this on a laptop is measuring their cooling as much as their chip.

For context on what runs comfortably on ordinary hardware, our roundup of GitHub repos worth pairing with Claude Code covers tools with far smaller footprints. The OpenClaw deep dive walks through containerised setups for anything you would rather not run on your main machine. This one is at the opposite end.

Why It Matters Beyond Macs

Three things. Only one of them is about Apple.

The first is that a single developer closed a hardware gap in a weekend that a vendor had left open. MiniMax shipped deployment recipes for SGLang across four H200s. Apple Silicon got nothing. That gap is now filled by someone with no relationship to either company.

The second is the pattern. This is llama.cpp applied to video generation. Someone reads the weights, writes the kernels by hand, then the model runs on hardware the original authors never targeted. Text generation went through this in 2023. Video is going through it now, roughly two years later and considerably faster.

The third is what it does to the economics. Video generation is currently a per-second billing product. Every clip costs money, every regeneration costs money again, since a regeneration task rebills the original input materials. A local pipeline changes that to a fixed hardware cost with unlimited iteration on top, which matters enormously for anyone doing creative work where the tenth attempt is the good one.

That said, the machine required is not cheap. Seventy-four seconds for a clip under a second long is not a workflow most people will enjoy. The interesting part is the direction of travel rather than today’s numbers.

The llama.cpp Pattern, Two Years Later

Worth putting this in sequence, because it is the third time the same thing has happened.

Text generation went first, of course. Meta released Llama weights. The supported path was Python and CUDA. Within weeks Georgi Gerganov had a C++ implementation running on a MacBook. That project became the reason a whole category of local model tooling exists.

Image generation followed. Stable Diffusion shipped with a PyTorch pipeline. Ports to Metal, Core ML and quantised formats arrived quickly enough that running it locally became normal within months.

Video is the current front

The difference this time is speed. MiniMax published H3 weights with SGLang recipes for four H200s. Apple Silicon support arrived from outside the company inside a fortnight.

Overall, each round follows the same shape. A lab releases weights aimed at datacenter hardware. Somebody who owns different hardware finds that annoying. They read the checkpoint format, write the kernels, publish the result under a permissive license, then everyone else builds on top.

What changes each round is the gap between release and port. Text took months. Images took weeks. This took days.

The interesting question is what breaks that pattern. Model size is the obvious candidate here, since a 33 billion parameter transformer plus a 32 billion parameter encoder is already at the edge of what consumer memory holds. The other candidate is licensing. H3 ships under a community license rather than a standard open source one. A stricter license on the next release would stop this happening regardless of who wants to write the kernels.

What to Watch Next

Three specific things, all checkable.

Firstly, whether the sparse attention implementation lands. MiniMax said full attention only for the initial release, with sparse coming later. Sparse attention would cut the compute problem that makes this hard on Apple hardware in the first place. It would probably reset every benchmark in this article.

Secondly, whether anyone reproduces the numbers. Every figure here is self-reported by a project one day old. That is not a criticism, it is just the state of it. Independent measurement on a different M-series machine is the thing that turns these into facts.

Thirdly, whether smaller machines get validated. The documented benchmark hardware is a 128 GB M5 Max. Plenty of people own 36 GB and 48 GB machines. The int8 path plus layer thinning theoretically brings the footprint down. Nobody has published what actually happens at those sizes.

Our own hands-on test of this is going in a future Fresh Commits issue, on isolated hardware with the terminal session recorded. Until somebody does that, treat everything above as a well-documented claim rather than a measured result.

What This Is Not

Being precise here, since the headline invites some wrong conclusions.

Firstly, it is not a product. There is no installer, no GUI, no model download step handled for you. You clone it, run make, then point it at a Hugging Face snapshot you fetched yourself.

Secondly, it is not finished. The author describes the work as a sequence of vertical slices, with the current focus on incremental Metal performance and memory optimization. Zero open issues on a repository this new means nobody has stressed it, not that nothing is wrong.

Thirdly, it is not benchmarked independently. Every figure in this article comes from the project’s own measurements. Nobody outside has reproduced them yet. The documentation is careful to note that numerical pixel identity with the MLX reference is not expected because the random number and execution engines differ.

It is not going to run on your MacBook Air. A 37 GiB checkpoint and a 40 GB peak footprint rule that out.

The Part Worth Keeping

A review looked at the hardware requirements, checked what recipes existed, then concluded that H3 on Apple Silicon was a capacity thought experiment rather than a practical workflow.

That was accurate when it was written, certainly. It stopped being accurate about six days later, because one person decided to write the missing kernels himself.

The gap between what a model supports and what a model can do is usually filled by whoever finds it annoying enough. In this case that was a guy who has spent twenty years writing C for things other people said were solved.

None of which means you should go buy a 128 GB Mac. It means the assumption that video generation belongs on somebody else’s servers lasted about a fortnight after the weights went public, which is worth knowing before anyone signs an annual contract for credits.

Charts and Blocks

Denoise time by optimisation path

The speed and quality dials

FAQ