TurboFieldfare: running a 26B LLM on a 8 GB MacBook Air

TurboFieldfare is a Mac inference engine written for a single model: it lets Gemma 4 26B-A4B run on any M-series Mac using only about 2 GB of memory, so a 8 GB M2 Air can run it. The repo was created in Jul 17. A single Show HN gained it 5,400 stars in a month, reaching 7,264 stars and 471 forks by Nov 6. Below: what it built, where the stars came from, who picked it up, and how to approach a project that could earn stars the same way.

One Show HN: "Memory got expensive, so I kept only 2 GB for a 26B model"

On Jul 29, 2026, author gitpusher42 posted on Hacker News: "Show HN: Open-source engine running Gemma 4 26B in 2 GB RAM on any M-series Mac." The body was plain: he has always loved on-device AI and wanted to try "running a model whose weights don't fit in memory." At 4-bit quantization the weights are about 14 GB, and on an 8 GB or even 16 GB Mac, once you count the system, apps and KV cache, ordinary tools barely run it. "I ran 100 experiments, most failed, a few worked."

The post got 919 points and 342 comments (Hacker News, 7-29). Commenters quickly tried it: one user measured 48 tokens per second on a 64 GB M4 Max with 1.9 GB resident memory; another, on an M1 Air still on macOS 15, deleted two lines of code and got it to compile, reaching 5 to 6 tokens per second. Some poured cold water, saying llama.cpp with mmap can also run it at around 2 GB.

The first line of the README is "Memory got expensive." Memory prices rose in 2026, and adding RAM to a Mac became absurdly expensive. The people with 8 GB and 16 GB Macs are the most numerous, and the ones most likely to feel "local LLMs aren't for me." That line is aimed squarely at them.

What it actually does

A mixture-of-experts (MoE) model uses only a small subset of its "experts" for each generated token. Gemma 4 26B-A4B has 26B parameters in total, but each token activates only about 3.88B. TurboFieldfare's approach:

• Keep only the shared core (1.35 GB) and the KV cache in memory;
• For each token, read the experts it needs from SSD on demand, with a small expert cache;
• While the SSD is reading, the GPU computes the shared part of the current layer. The two overlap, so nothing sits idle waiting.

Everything is handwritten in Swift and Metal, not a wrapper around MLX or llama.cpp. It ships with a native Mac app ("Download Model" automatically downloads and repackages the roughly 15 GB model), a command-line tool, and an experimental OpenAI-compatible local server with streaming and tool calls. Measured speeds: on a 8 GB M2 Air, 5.1 to 6.3 tokens per second; on a 24 GB M5 Pro, 31 to 35 (README, 11-06).

The repo also publishes a ledger of 103 experiments and a community benchmark table, and invites others to submit results from their own machines.

Where the stars came from

(GitHub star counts; 7-30 and 8-31 are web-archive snapshots, daily counts from October on. Last commit: 10-26, version 0.9.4.)

The main engine was that one Show HN. About 85% of the stars came within a month of the post. The author had only this one repo on GitHub and no follower base; it rode purely on the title and content.

Reposts came next. From Jul 29 to Aug 3, ai-tldr, developersdigest, Towards AI, Better Stack, hyper.ai and a dozen-plus other tech outlets and aggregators followed. There was a post on r/LocalLLaMA, and YouTube videos like "Local AI On Apple Silicon uses 7X Less RAM" and "Running Gemma 4 26B on a Mac With 2GB of RAM?!" (view counts not checked). Towards AI also wrote a piece titled "...the title is still misleading," arguing the 2 GB claim holds but speed depends on the SSD. The controversy itself drove another round of discussion.

The small early-November bump was not a new surge. There was no new release. The likely timing match was the aggregator earlysignal listing it among that day's trending on Nov 4, plus a few install tutorials appearing around Nov 5 (inferred, causation unverified).

What didn't happen: it never made GitHub's overall trending chart (the repo was under two weeks old at the peak). It only hit the Swift language chart at #15 and #20 in mid-October. How it spread on X is unclear.

Who it's competing with

To be clear: streaming experts from SSD on demand was not invented here. Apple's 2023 paper "LLM in a flash" laid out this idea, and flash-moe built it 4 months earlier. This project wins on positioning.

(GitHub stars, around 11-06)

flash-moe and ds4 are "big model, big Mac." TurboFieldfare is "mid-size model, cheapest Mac." The second audience is far bigger, and that's its edge and why it took off. But the moat is shallow: Edge0 ran the same pitch with a different number and picked up more stars.

What it still gets wrong

• High bar to start. No ready-made installer. You build it yourself with swift build, need macOS 26 and Swift 6.2, and the first run downloads 15 GB.
• Only one model. Gemma 4 26B-A4B. Once it stops being the hot mid-size model, it has to be ported all over again.
• Mac only. iPhone, Android, and Windows thin-and-lights have the same memory squeeze, and it hasn't touched them. Edge0 already has.
• Stars aren't installs. There's no way to see how many people actually use it day to day.

If it were you

Bottom line: the formula "X-billion-parameter model runs on the cheapest Y GB machine" still has room, but the same slot (MoE + Mac + low memory) is already taken by it and Edge0. The opening is to wait for the next hot model, or switch to a hardware tier nobody covers, and launch first with the same formula.

Who it's for: systems-minded developers who know Metal, CUDA, Vulkan, or on-device inference, and who can grind through dozens or hundreds of experiments to squeeze out every performance number.

Who it's not for: people who want to bundle another "2 GB runs Gemma" on a Mac, or people who only call APIs and won't touch the low-level kernels.

How to do it:

1. Watch model releases. Every well-received MoE model with a small active-parameter count opens a new window. Whoever gets it running on the cheapest machine first owns the headline.
2. Switch hardware tiers. 8 GB Windows/Linux thin-and-lights, older iPhones, mid-range Android phones, and Raspberry Pi-class devices all have the same memory squeeze, with far fewer dedicated engines (inferred, not checked one by one).
3. Fill the gaps it left: a one-click install (a signed .dmg or a one-line Homebrew install), or package the same disk-scheduling as a plugin for llama.cpp or MLX so existing users benefit directly.
4. Do one model and one hardware tier, and do it extremely well. Don't launch promising to "support every model."

How to get stars: launch on Show HN, put three numbers in the title (how big the model, how much memory, how cheap the machine); in the body, explain the method and the experiments that failed; in the repo, keep an experiment log and a community benchmark table so users can post their own results. After launch, press, tutorials, and YouTube pick it up on their own. A post that challenges the title is a good thing too.

When this window closes: the window follows model releases and lasts roughly a few weeks each time. The one or two projects that get a new model running first take most of the attention. Longer term, once llama.cpp and MLX make SSD expert-reading a default feature, the "dedicated engine" route stops being news.

Signs you've misread it: within a week of a new model's release, someone has already shipped the same headline on the same hardware tier; or your Show HN doesn't clear 100 points in two days, which means the numbers lacked contrast or someone already said it.