Redis's Creator Just Hand-Wrote an LLM Inference Engine in C. Here's Why That Matters

Salvatore Sanfilippo — better known as antirez, the developer who created Redis — has built something delightfully unnecessary. It’s an inference engine written in C that runs exactly one model: MiniMax-H3. Not a family of models. One. In a world where llama.cpp, Ollama, and MLX already exist and work fine.

That “why bother” is the interesting part. It’s not eccentricity. It’s a fairly precise signal about what’s happening in local AI right now, and it’s worth unpacking.

The engine that does everything isn’t fast at anything

llama.cpp is a genuinely great project. Hundreds of model architectures. Backends spanning CUDA, Vulkan, Metal, ROCm. Georgi Gerganov built something that made local inference accessible to people who don’t have a data center in their garage.

But generality is never free. Every new model architecture adds another layer of abstraction. Attention variants multiply. KV cache handling forks. Quantization formats spawn subformats. The codebase has grown into the hundreds of thousands of lines, and for any single model, a meaningful share of the execution path is branches that never fire.

Target one model and everything changes. Tensor shapes become compile-time constants. Memory layout can be designed around that specific model’s attention pattern instead of a lowest-common-denominator interface. Conditionals disappear. Kernels get simpler, and simpler kernels run faster on a GPU. That’s exactly what h3.c is going after.

The choice of MiniMax-H3 is the tell

Why this model specifically?

MiniMax’s H3 architecture uses hybrid attention — instead of full attention at every layer, it interleaves linear attention with softmax attention. The goal is structural: shrink the KV cache explosion that makes long-context inference brutally expensive.

New structures like this fit badly into existing engines. llama.cpp’s internal abstractions were shaped around standard transformer attention over years of iteration. Bolting on a hybrid design means routing around existing interfaces or carving out special cases. Support arrives late, and when it arrives, it’s often unoptimized for months afterward.

So developers stop waiting and write their own. The more model architectures diverge, the slower general-purpose engines catch up — and the wider the gap that purpose-built engines can exploit in the meantime. This isn’t one developer’s taste. It’s the shape of the problem pushing in a direction.

Apple Silicon quietly became the default

h3.c targeting Metal is no accident either.

The real bottleneck for running big models locally isn’t compute — it’s memory bandwidth and capacity. Every single token requires reading the entire set of model weights out of memory. Consumer NVIDIA GPUs hit a wall here. An RTX 5090 gives you 32GB; step down a tier and you’re at 16–24GB. Not enough to properly host a 70B model, let alone anything larger.

Apple’s unified memory flips the equation. CPU and GPU share one pool. An M4 Max goes to 128GB; the M3/M4 Ultra line reaches 512GB. Bandwidth runs about 546GB/s on the M4 Max and north of 800GB/s on Ultra parts. Those numbers look modest next to a data center GPU. But if you can fit a 100GB model entirely in memory, the bandwidth deficit stops mattering — because the alternative isn’t “slower,” it’s “doesn’t run.”

There’s a second factor that gets undersold: it runs silently on a laptop drawing roughly 60W. No server closet, no dedicated PSU, no thermal engineering project. If you’re an individual developer who wants to poke at a 70B model from your desk, the Mac has quietly become the only realistic option. The local AI community’s shift toward Apple hardware isn’t a preference. It’s arithmetic.

Why hand-written C is appealing again

Here’s the paradox worth sitting with. In an era where AI writes code for us, some of the best developers alive are going the other direction — hand-carving low-level C.

antirez has always worked this way. Redis was C with almost no dependencies, and wherever performance mattered, he designed the data structures himself rather than reaching for a library. h3.c is the same philosophy applied to a new domain: narrow the problem, strip the abstraction, sit directly on the hardware.

There’s a practical payoff too. A framework with hundreds of thousands of lines is nearly impossible to read your way into. A single-model engine is small enough that one person can hold the whole thing in their head. Just as Andrej Karpathy’s llama2.c did, these projects work as both performance tools and teaching material. If you want to understand how a transformer actually computes, one readable codebase beats ten papers.

So is llama.cpp finished?

No. Not remotely.

A purpose-built engine runs one model. The model updates, you rewrite. Quantization options, server mode, tooling integrations — you build all of it yourself. For anyone who swaps between models weekly in real work, that’s a non-starter. Ollama’s success has never been about raw performance; it’s about handling the annoying parts so you don’t have to.

The realistic split looks like this. General-purpose engines remain the infrastructure layer — broad coverage, reliable, well-integrated. Purpose-built engines are the scouts: they squeeze one model to its limits, or probe a new architecture before anyone else supports it. And the optimizations that prove out in a specialized engine get imported back upstream. Several of llama.cpp’s kernel improvements arrived through exactly that path.

The takeaway

What’s happening in local AI is software moving back down toward the hardware. Model architectures are diverging faster than general abstractions can track, and in that gap, hand-carved specialized code becomes competitive again.

So where’s the bottleneck in your own local setup — the model, or the software layer running it? If your honest answer leans toward the latter, you already understand why antirez opened up a C file instead of filing a feature request.