Local Video Generation Gets Its llama.cpp Moment
antirez's h3.c renders MiniMax's open 33B video-and-audio model in about 75 seconds on Apple Silicon.
Six days after MiniMax open-sourced its H3 video model, Salvatore Sanfilippo — antirez, the creator of Redis — dropped h3.c: a native inference engine, written in C against Apple's Metal API, that renders video with synchronized stereo audio on a Mac in about 75 seconds. It's MIT-licensed, its only real external dependency is FFmpeg, and it hit the Hacker News front page within hours of the repo going public.
If that setup sounds familiar, it should. This is the llama.cpp pattern replaying, almost beat for beat, for video generation — and it says as much about where local AI hardware is heading as it does about antirez's famous inability to stop shipping.
The model is half the story
MiniMax released H3 (Hailuo 3.0) at the end of July and published open weights on August 3. Architecturally it's a genuinely interesting artifact: a 33B-parameter dense, single-stream "omni" transformer that generates video and native stereo audio in a single denoising pass — no separate audio model bolted on afterward. The open H3-Base checkpoint targets 768p output and ships in two task-specific variants: FL2VA for text-to-video with first/last-frame anchoring, and Ref2VA for generation conditioned on reference images, video, or audio clips.
Open-weight video models aren't new — Alibaba's Wan line, Tencent's HunyuanVideo, and Lightricks' LTX-Video have been runnable locally for over a year. But that ecosystem grew up CUDA-first. Mac users got hand-me-down support through PyTorch's MPS backend or GGUF quantizations in ComfyUI, and the results were rough: one Hacker News commenter reported roughly an hour to render a 9-second 480×864 clip at 20 steps through the GGUF route on an M5 Pro. That's not a workflow; that's an overnight batch job.
What a native engine buys you
h3.c's numbers are in a different category. On an M5 Max with 128GB of unified memory, antirez reports clean end-to-end renders — prompt in, H.264 video with stereo audio out — in 74.58 and 76.99 seconds for image-conditioned and video-conditioned generations, with a 40.1GB peak memory footprint and zero swap. The engine quantizes the MLPs and attention projections to int8 with per-channel scales (a slower BF16 path exists as a correctness fallback), fuses the gated AdaLN kernels, and offers an opt-in token-reduction mode that cut one benchmark from 25.8 to 19.3 seconds of denoising at the cost of shifting composition.
The honest caveat: the hour-long ComfyUI figure and the 75-second h3.c figure come from different hardware, resolutions, and step counts, so don't read it as a literal 48x speedup. But the direction is unambiguous, and it's the same lesson llama.cpp taught in 2023: the reference Python stack is built for correctness on NVIDIA clusters, and a purpose-built native engine on the actual target hardware routinely finds an order of magnitude that the general-purpose stack leaves on the table.
There's also a small open-source grace note here. antirez says h3.c contains code from Liu Liu, the developer behind Draw Things, the app that has been quietly doing heroic Metal-optimization work for image models since the Stable Diffusion 1.5 days — and publicly invited him to take whatever's useful back. The Mac inference scene is tiny enough that its key people fit in one X thread, which is both charming and a little concerning for the bus factor.
Unified memory is the actual moat
Here's the structural point that outlasts this particular repo: that 40GB peak footprint doesn't fit on any consumer NVIDIA card. An RTX 5090 tops out at 32GB, and everything below it is worse. A 33B dense diffusion transformer plus a visual VAE, an audio VAE, and a Qwen3-VL-based text encoder simply wants more contiguous memory than gamer GPUs offer — and cloud A100/H100 instances are the standard answer only if you're happy paying per render.
A Mac Studio or MacBook Pro with 64GB or 128GB of unified memory sits in a genuinely unique spot for this workload. We've spent two years talking about Apple Silicon as an LLM machine; H3 is the strongest evidence yet that the same argument extends to large multimodal generation, where memory capacity matters more than raw FLOPS. The ecosystem clearly agrees — within days of the weights dropping, two independent MLX ports of H3 appeared alongside a diffusers integration PR, all targeting big-memory Macs. Nobody's racing to make this pleasant on a 16GB gaming PC.
Running it, and where the edges are
The developer experience is aggressively antirez: clone, make -j8, download the Hugging Face snapshot, and run ./h3 -d ./MiniMax-H3 -p "your prompt" with flags for steps, canvas size, and the quality/speed knobs. Constraints to know before you burn an afternoon: canvas dimensions must be multiples of 32 with a pixel budget capped at 768×1344; reference audio is limited to three inputs totaling 15 seconds; and because H3-Base is natively a 768p model, small canvases visibly degrade quality — the README notes a 128×128 render couldn't even recover a recognizable subject. Realistically you want a 64GB machine as the floor, and the tested configurations are M3 Max and M5 Max.
Is it production-ready? No, and it doesn't pretend to be. The repo is days old, single-author, and explicitly built as incremental "vertical slices" with active kernel work ongoing. If you need dependable local video generation in a pipeline today, ComfyUI's native H3 support — which landed the same day as the weights — is the boring, correct choice.
The llama.cpp question
The interesting question is whether h3.c becomes for video what llama.cpp became for text: the hackable native reference that an ecosystem crystallizes around. I'd bet on a modified version of that outcome. llama.cpp won partly because Georgi Gerganov kept feeding it for years; antirez has a long track record of building small, perfect C artifacts — Redis, kilo, linenoise — and then handing them to the community rather than maintaining them forever. The durable value here may be less the binary than the existence proof: a readable, dependency-free demonstration that a 33B video+audio model is a one-minute, laptop-class workload. Whether the long-term home is h3.c itself, Draw Things, or MLX, the ceiling for local generation on a Mac just moved — and it moved because one person spent a week writing C.
Sources & further reading
- h3.c - MiniMax H3 inference engine for Mac computers — github.com
- Antirez/h3.c - MiniMax H3 inference engine for Mac computers — news.ycombinator.com
- Open General Intelligence - MiniMax H3 Is Now Open Source — minimax.io
- MiniMaxAI/MiniMax-H3 model card — huggingface.co
- MiniMax H3 Open Weights Land With Native ComfyUI Support — comfyui-wiki.com
- antirez on the h3.c release and Draw Things code credit — x.com
Mariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon.
Discussion 1
75 seconds on Apple Silicon for a 33B model is interesting, but what's the actual output resolution and bitrate we're talking about here? that number means something completely different if it's 480p vs 1080p, and i'd want to see it against the original MiniMax implementation to know if we're looking at a real efficiency win or just different tradeoff choices.