Top
Best
New

Posted by gitpusher42 8 hours ago

Show HN: Open-source engine running Gemma 4 26B in 2 GB RAM on any M-series Mac(github.com)
Hi HN,

I built a specialized inference engine for running 4-bit Gemma 4 26B-A4B-IT on any M-series Mac using about 2 GB of RAM. It is called TurboFieldfare and is written in Swift and Metal.

I have always adored on-device AI. It feels like magic that you can run a powerful NN on your Mac or iPhone. So I wanted to push the limits a bit and run a model whose weights don’t fit in memory.

The model’s 4-bit quantized weights occupy roughly 14 GB, which makes running it with conventional inference tools almost impossible on an 8 GB or even 16 GB Mac once the OS, applications, and KV cache are included.

The trick is to keep the shared part of the model and the KV cache in RAM, then stream only the routed experts needed for each token from SSD. An SSD is way slower than RAM, so the runtime uses a small expert cache and bounded parallel `pread`. While those reads are in flight, the GPU runs the shared part of the layer.

I ran more than 100 experiments. Most didn’t work. A few got me here. The experiments are described in the GitHub repo.

It currently generates 5–6 tok/s on an 8 GB M2 MacBook Air and 31–35 tok/s on an M5 MacBook Pro.

I also added an experimental OpenAI-compatible local server. It supports streaming and tool calls, and reuses one prompt prefix from the KV cache.

Try it! The Mac app is easy to install. On the first run, it will download 15 GB of weights from Hugging Face. The model is surprisingly capable.

I would love any kind of feedback!

566 points | 197 commentspage 4
cagz 5 hours ago|
Is the 1/10+ reduction in memory usage applicable to larger models, i.e. would be possible to run a 200Gb model, by using 20Gb of memory?
gitpusher42 4 hours ago|
Size reduction is mostly based on Experts size. And it is limited by SSD speed. Check for Colibri and Flash-Moe, they are doing similar things with bigger models, but tok/s is not high
h2aichat 7 hours ago||
Hope you can do it for Windows users also (and small graphics cards). Thanks
gitpusher42 7 hours ago|
Uh, I’m afraid it is Apple only. It is written using Apple’s GPU language, Metal, and heavily relies on the Apples’s shared memory architecture

Windows PCs would require a completely different approach

agcat 3 hours ago||
This looks great. going to try it
gitpusher42 2 hours ago|
Thank you! Let me know how it goes and share your tok/s results
dboreham 1 hour ago||
I'm intrigued to try a slightly different experiment:

Did LLMs arise because a) humanity created circuits so large and so fast and so easy to use in parallel that only then did it become possible to run an LLM, or b) because sufficient data useful for training was accumulated such that experiments in different neural network arrangements could be done to see what came out?

My hunch is (b) and so I further wonder how far back in time could we have made a usable LLM if we had only known to try? E.g. can you run any sort of LLM on a VAX 11/780?

gitpusher42 1 hour ago|
There was an ai winter for very long time. The math for NNs was already here, but not enough compute/data

I saw a pretty cool project to run an llm on an esp32 device https://github.com/slvDev/esp32-ai

y42 5 hours ago||
Dont want to crash the party here, but I am still sceptic about all those on-premise-llm-approaches.

I think we strongly need something like that (shameless plug, I tried to build something around bitNet for the same reason: https://github.com/nickyreinert/bitNetRTR).

But at the end, all aproaches I saw, however genius they are: the actual results are always a mess. It's a better chat buddy, nothing else. It's e.g. far away from an decent coding assistants. I fine tuned Gemma with domain specific knowledge. Running it on a 16GB VRM GForce. Even then it's okai'sh but far way from a mind blowing experience. I ran some of the promised open source model on my 36GB MBPro M3, in Pi, Hermes, Continue. Can't compare the results to what Claude or Codex are offering.

You need at least something that's far away from consumer hardware, like those 7k'ish GForce machines with 96GB VRAM to get an idea of a good competitive model.

But... please, proof me wrong! =)

limecherrysoda 5 hours ago||
Gemini uses MoE and context caching, which is a similar approach.

You are not really accessing the biggest frontier model every time, and you're not really doing an end-to-end LLM request on each prompt.

I would go so far to say frontier models have peaked and improvements from here come from clever (or very elaborate) harnessing. "LLLMHs" - Large Large Language Model Harnessing !

TheRealPomax 5 hours ago||
This is an odd comment: the project is right there for you to use, so just try it and see if it holds up to the claims? Then you can comment about the fact that it either doesn't hold up, with numbers to back that up, or on how awesome it is because it works =)
memre12 5 hours ago||
Impressive if the numbers hold. Would love a table with per-token bytes read, measured SSD bandwidth, and cache hit rate—those four numbers would make the tok/s claims land better.
gitpusher42 3 hours ago|
I double checked m2 logs. Cache hit rate is about 59-69%. 250-320MB went through `pread` per generated token. It is 3gb/s during this i/o phase.
WithinReason 7 hours ago||
Nice job implementing expert caching!
gitpusher42 7 hours ago|
Thank you! Under good conditions it achieves approx a 67% cache hit rate with 16 expert slots
WithinReason 5 hours ago||
That's great, now I wonder how cache hit rate scales for larger models. Do you have any plans trying Qwen 3.6 or larger?
cyanregiment 6 hours ago||
You’re a mad man - thank you!

Do I understand correctly that Ollama doesnt do that, and that’s why responses hang forever on a M3 running the same model through Ollama?

trollbridge 5 hours ago||
Please don’t use Ollama.

https://sleepingrobots.com/dreams/stop-using-ollama/

reddguard 5 hours ago|||
Doesn't Ollama use llama.cpp so their point stands even if they used it directly?
cwillu 4 hours ago||
It wouldn't be the first time ollama's llama.cpp fork reintroduced bugs and was missing important optimizations.
lemonlimesoda 5 hours ago|||
[dead]
gitpusher42 1 hour ago||
Thank you!

afaik ollama relies on llama.cpp and mmap. mmap loads pages on demand and doesn't use the same explicit cache or parallel reads like my engine. Most likely ollama/llama.cpp will be way slower in this case

Pragmata 6 hours ago||
Would it be possible to use this for kimi k3?

what are the limitations

touwer 7 hours ago|
Cool! Is there any info on this doing harm to the SSD? (Or other parts?)
wtallis 7 hours ago||
Reads don't wear out flash memory to any meaningful extent.
gitpusher42 6 hours ago||
AFAIK it should not because it is only reading
More comments...