The 2 GB Lie (And What's Actually True)

The Redis creator got tired of Python inference stacks. So he's writing one in C and yesterday he made a 37 GB model run in 2 GB of GPU memory. Byteidentical.
antirez has spent the last two weeks building h3-metal: native inference for MiniMax-H3, a 33B video+audio diffusion model, on Apple Silicon. Pure C plus Metal shaders. No Python anywhere in the inference path. MIT licensed.
The commit that landed yesterday is the one worth studying. SSD streaming for the DiT:
➡️ Tracked transformer storage drops from 36.5 GiB to 2.0 GiB. The output is byte-identical to the full-residency path.
➡️ Two block slots alternate: a background reader pulls the next transformer block off SSD while the GPU executes the current one. Measured 13–14.6 GB/s from the internal drive.
➡️ Darwin uncached reads, on purpose so the filesystem cache never holds a second copy of weights that will be read again anyway.
On top of that, his int8 TensorOps path cut a full denoise from 36.3 to 19.3 seconds on M5 Max.
Kimi K3 streaming off NVMe. Gemma 4 26B in a 2 GB budget. Now a 33B video model. Same conclusion three times in one month, from three independent codebases: weights don't need to fit in RAM. They need to arrive on time.
SSD bandwidth is quietly becoming the new VRAM.

✅ Core facts — confirmed

Salvatore Sanfilippo (antirez), the creator of Redis, published h3.c on August 10, 2026. The project has no Python, no PyTorch, no ComfyUI — it's pure C with Metal shaders, directly calling Apple's GPU interface. It's MIT licensed. That all checks out. antirez h3.c: MiniMax H3 Video Gen on Mac in 3.5s | explainx.ai Blog | explainx.ai +2

✅ Model size — mostly right, with a nuance

The post says "33 GB model." MiniMax H3 is a 33.1B-parameter multimodal generation model. The transformer checkpoint pulled from Hugging Face is about 33 GB, and the README puts peak physical memory at approximately 40 GB during end-to-end generation. So "37 GB model" in the post is slightly off — the checkpoint is ~33 GB, and peak RAM usage hits ~40 GB, but neither figure is 37. Minor inaccuracy. KocpcAI Weekly

✅ SSD streaming numbers — confirmed and precise

On M5 Max, tracked DiT storage fell from about 36.5 GiB to 2.0 GiB at 512 square and 2.1 GiB at 864×480. The results were byte-identical in both checks. The "36.5 GiB to 2.0 GiB, byte-identical" claim is accurate. One important clarification the post glosses over: the 2.0–2.1 GiB figure is the DiT's tracked tensor storage, not total system RAM. The post frames it as "2 GB of GPU memory" which is misleading — this is the tracked transformer storage only, not the full memory footprint of the run. GitHubGitHub

✅ Double-buffering / background reader — confirmed

It keeps two DiT blocks in memory and reads the next block from SSD while the GPU runs the current one. The "two block slots alternate" description is accurate. GitHub

✅ Darwin uncached reads — confirmed

Darwin uncached reads avoid retaining a second copy in the filesystem cache. Confirmed verbatim. GitHub

✅ SSD throughput — confirmed

Measurements reached about 13–14.6 GiB/s from the internal SSD. Exact match. GitHub

✅ int8 speedup — confirmed with a small correction

The post says int8 "cut a full denoise from 36.3 to 19.3 seconds." The BF16 MPS baseline takes 36.30 seconds, and adding int8 QKV brings it to 19.32 seconds. The numbers are right. The post says "19.3 seconds on M5 Max" — correct. daily.dev

⚠️ "h3-metal" — minor naming issue

The post calls the project "h3-metal." The actual GitHub repo is antirez/h3.c. "h3-metal" is a common community shorthand but not the official name.

⚠️ "video + audio diffusion model" — slightly loose

MiniMax H3 is a multimodal generation model whose standout feature is the ability to produce both video and a 32kHz stereo audio track in a single pass. Calling it a "diffusion model" is a simplification — it uses a DiT (Diffusion Transformer) architecture, so it's not wrong, but "video + audio diffusion model" undersells the multimodal audio side. Kocpc

❌ "two weeks building" — not confirmed

H3 shipped as open weights on August 3, 2026; seven days later it ran on a Mac, not two weeks. The post's "two weeks" timeline is inaccurate — it was one week from open weights to working engine. Explainx

❌ "tired of Python inference stacks" as the motivation — not confirmed

This is the framing the post opens with, but there's no sourced statement from antirez saying he was "tired of Python inference stacks" and that was his motivation for h3.c specifically. His pattern of writing C inference engines predates h3.c (he did the same for DeepSeek with ds4, for Flux with flux2.c, for Mistral with voxtral.c). It's a reasonable inference about his aesthetic, but it's not a stated reason.

❌ "GPU memory" framing

Apple Silicon uses unified memory, not discrete GPU memory. Calling the 2 GiB reduction a reduction in "GPU memory" is technically inaccurate for this architecture — it's unified RAM, and the specific figure is the DiT's tracked tensor allocation, not a total memory budget.