De auteur beschrijft een lokale AI-infrastructuur gebaseerd op een M4 Pro Mac mini met 48 GB RAM. Met behulp van de oMLX-inference-server en Tailscale is een privaat netwerk opgezet waardoor diverse apparaten, zoals een iPhone en MacBook, toegang hebben tot lokale modellen (waaronder Qwen3.6-35B en Gemma-4).
De belangrijkste motivaties voor deze overstap van cloud-API's naar lokale hardware zijn:
- Privacy en Soevereiniteit: Geen afhankelijkheid van externe providers en volledige controle over gevoelige data.
- Kosten en Efficiëntie: Wegvallen van variabele API-kosten, lagere latentie en het ontbreken van rate limits.
Het artikel bevat een technische uiteenzetting over het geheugengebruik van LLM's, waarbij specifiek het verschil tussen dense modellen en Mixture-of-Experts (MoE) modellen wordt uitgelegd. De auteur biedt een praktische gids om te berekenen of een model binnen het unified memory van Apple Silicon past, rekening houdend met quantisatie, OS-overhead en context-windows. De setup wordt afgerond met een workflow voor het eenvoudig wisselen van modellen via een admin-dashboard.
Mijn lokale model-setup op een M4 Pro Mac mini
De stack
- Qwen3.6-35B-A3B-OptiQ-4bit: mijn hoofdmodel voor alles wat redenering of diepgang vereist.
- Gemma-4-E4B-it-OptiQ-4bit: een lichtgewicht model voor eenvoudige chats, opmaak en andere routinetaken.
- oMLX: de inference-server.
- Tailscale: het tailnet dat de Mac mini, mijn iPhone en mijn MacBook met elkaar verbindt.
Hermes fungeert als de agent-backend op de Mac mini, waarbij mijn MacBook de desktopclient draait en mijn telefoon Telegram gebruikt. Voor gebruik buiten Hermes gebruik ik Apollo op iOS voor snelle chats (leest als Claude, goed voor incidentele vragen), Pi als mijn coding-agent, en Raycast AI op mijn Mac voor diverse kleine taken.
Waarom de moeite nemen?
De belangrijkste reden om lokaal te draaien is dat cloud-API's "gehuurd land" zijn. Aanbieders kunnen hun prijzen wijzigen, gebruikslimieten instellen of het model dat achter de schermen wordt aangeboden vervangen wanneer ze dat willen. Ik bereikte regelmatig de limieten van twee abonnementen van $200 per maand en had het gevoel dat de output op verschillende momenten varieerde; soms was een model prima, dan weer degradeerde de kwaliteit zonder vooraankondiging.
Gegevensprivacy is een ander punt. Je weet niet wat deze bedrijven met je data doen zodra ze die hebben. Ze kunnen het gebruik beperken, de data verkopen of deze per ongeluk blootstellen. In elk geval creëert dit een risico voor de operationele veiligheid. Als je werkt met gevoelige code, klantgegevens of eigen workflows, is het versturen hiervan naar een externe API een beslissing die je slechts één keer kunt nemen en niet ongedaan kunt maken.
Daarnaast is er AI-soevereiniteit. Ik heb gezien hoe de Amerikaanse overheid de uitrol van verschillende modellen heeft beperkt. Dit kan op elk moment door elke overheid gebeuren, om elke reden, en je hebt er geen controle over. Als je workflow afhankelijk is van een cloudmodel dat wordt beperkt, moet je stoppen of halsoverkop een alternatief zoeken. De enige manier om dit te voorkomen is door je eigen rekenkracht (compute) te bezitten.
Andere praktische voordelen:
- Voorspelbaarheid van kosten: API's zijn variabel; als je gebruik piekt, stijgt je rekening. Bij lokale hardware zijn de kosten beperkt tot de aanschaf van de hardware en de elektriciteit. Daarna is elke inference gratis.
- Latentie: Het ontbreken van een netwerk-roundtrip betekent snellere reacties voor dagelijkse taken. De media-engine van de M4 Pro handelt inference af op snelheden die voor de meeste prompts onmiddellijk aanvoelen.
- Offline mogelijkheden: Het werkt ook zonder internet. Voor agent-workflows die op de achtergrond draaien, is dit belangrijker dan het lijkt.
- Geen rate limits: API-providers knijpen je af wanneer je gebruiksdrempels bereikt. Je eigen machine geeft niet om hoeveel je draait.
Hoe ik het in de praktijk gebruik
De Mac mini staat altijd aan. Hij staat op mijn bureau en ik merk hem nauwelijks op, behalve wanneer ik hem nodig heb.
Hermes draait op de Mac mini en maakt gebruik van een lokaal model op dezelfde machine. Ik heb toegang tot mijn agent via Telegram (op mijn telefoon) en de Hermes-desktopapp op mijn MacBook. De desktopapp fungeert als een 'shell' en verbindt met een Hermes-backend op een ander apparaat (in dit geval de Mac mini). Hierdoor deel ik een backend, gesprekshistorie en vaardigheden over al mijn apparaten.
Daarnaast gebruik ik het volgende:
- Apollo op iOS: voor snelle, incidentele chats. Ik wilde iets dat leest als Claude, maar geen API-sleutel of abonnement vereist. Door Apollo te verbinden met
http://[mac-mini-tailnet-url]/v1 is het klaar. Ideaal voor vragen als "herschrijf deze alinea" of "wat betekent deze foutmelding".
- Raycast op Mac: voor willekeurige taken waarvoor ik geen aparte software wil installeren.
- Pi: voor coderen.
Het doel is niet om API-gebaseerde modellen volledig te vervangen, maar om de 80% van de verzoeken af te handelen die geen GPT-5 of Claude Opus vereisen. Wanneer ik die wel nodig heb, zijn ze nog steeds beschikbaar. Lokaal gebruik dekt simpelweg een groter deel van mijn dagelijkse bezigheden gratis af.
Uitleg over de modellen
Het lokaal draaien van een groot model komt neer op één ding: hoeveel RAM er daadwerkelijk in het geheugen moet passen. Veel mensen kijken naar het aantal parameters en trekken de verkeerde conclusie, omdat het verschil tussen dense modellen en mixture-of-experts (MoE) modellen cruciaal is op consumentenhardware.
Zo lees je een identifier:
Qwen3.6-35B-A3B-OptiQ-4bit
- Qwen3.6: modelfamilie en versie.
- 35B: totaal aantal parameters over alle experts.
- A3B: actieve parameters per token (3 miljard, niet 35).
- OptiQ-4bit: mixed-precision quantisatie (grotendeels 4-bit, 8-bit op gevoelige lagen).
gemma-4-e4b-it-4bit
- gemma-4: de Gemma 4-familie van Google.
- e4b: encoding-grootte, ongeveer 4 miljard parameters in totaal.
- it: instruction-tuned.
- 4bit: uniforme 4-bit quantisatie.
Het cruciale verschil is het "A3B"-gedeelte. Een dense 27B-model heeft voor elk enkel token 27 miljard parameters in het RAM geladen. Een MoE-model zoals de Qwen3.6-35B-A3B heeft 35 miljard parameters verdeeld over 256 experts, maar er worden er slechts ongeveer 3 miljard geactiveerd per token. De overige 32 miljard staan in het RAM zonder actief te zijn.
Op mijn 48GB Mac mini neemt de Qwen3.6-35B-A3B in 4-bit ongeveer 20GB RAM in beslag. Dat laat 28GB over voor context-windows, het besturingssysteem en andere processen. De Gemma-4-E4B is ongeveer 2,4GB, klein genoeg om aan te houden voor simpele taken waarbij het grote model overkill zou zijn.
Ter vergelijking: de MacBook Air van een vriend had 16GB in totaal. Een dense 27B in 4-bit heeft ongeveer 14GB nodig. Dat is vrijwel alles wat de machine heeft, minus de ruimte voor het OS. Het werkt dan even, maar zodra het geheugen vol is, schakelt hij over naar de SSD (swapping), wat het proces traag maakt.
MoE verandert dit. Het 35B-model uit mijn setup zou op diezelfde MacBook passen, omdat er per token slechts 3B parameters actief zijn. De GPU/Media Memory footprint is daardoor vergelijkbaar met die van een dense 6B-model, hoewel de volledige 35 miljard parameters in het unified memory staan.
Hoe controleer je of een model op jouw hardware werkt?
- Kijk eerst naar de quantized bestandsgrootte. Een 4-bit model is ongeveer gelijk aan het aantal parameters in gigabytes (35B params $\approx$ 17-20GB, afhankelijk van de quantisatiemethode).
- Trek de OS-overhead ervan af. macOS verbruikt op Apple Silicon ongeveer 6-8GB.
- Houd rekening met context-windows. Elke paar duizend tokens voegen megabytes toe aan de KV-cache. Reken op 8-16GB overhead als je lange gesprekken verwacht.
- Bij MoE-modellen is het totale aantal parameters misleidend. Kijk naar het aantal "actieve parameters" om het werkelijke geheugengebruik tijdens inference te begrijpen.
- Buffer. Als het model plus de context in het beschikbare unified memory passen met een buffer van 10-15%, zit je goed. Alles wat daar dichterbij komt, zal gaan swappen naar de SSD.
Modellen eenvoudig wisselen
Dit is het aspect waar weinig over wordt gesproken: je kunt je lokale modellen elke paar weken vervangen zodra er nieuwe versies uitkomen. Het is simpelweg een kwestie van downloaden en herstarten.
De workflow:
- Download het nieuwe model naar
~/models/.
- oMLX herkent dit automatisch vanuit de modeldirectory.
- Selecteer het model in de oMLX-app of herstart de server.
- Klaar.
Het admin-dashboard van oMLX heeft een ingebouwde HuggingFace modelbrowser. Zoek een model, klik op download, pas het model aan in Hermes, Pi, Raycast en Apollo, en het is geregeld. Veel van dit alles kan via de CLI, waardoor ik via SSH vanaf elk apparaat op de Mac mini kan inloggen.
Het gat tussen lokale modellen en API-modellen wordt snel kleiner. Wat een jaar geleden "matig" was, is nu competitief voor de meeste praktijktoepassingen, vooral op het gebied van coderen, redeneren en tool-gebruik. De 4-bit quantisatie van OptiQ houdt de kwaliteit verrassend hoog; de 35B-A3B op 4-bit verliest slechts ongeveer 1-2 punten in de meeste benchmarks vergeleken met BF16 (16-bit floating point, de ongecomprimeerde baseline). Dat is een acceptabele ruil voor een geheugengebruik van 48GB in plaats van 70GB.
Het netwerk
Tailscale creëert een mesh-netwerk tussen al mijn apparaten. De Mac mini, iPhone en MacBook zitten allemaal in hetzelfde private netwerk, zonder dat er iets openstaat naar het publieke internet.
De oMLX-server luistert op poort 8000. Elk apparaat op het tailnet kan verbinding maken. Raycast, Apollo iOS en de Hermes-desktopapp op mijn MacBook maken allemaal verbinding met hetzelfde eindpunt, waardoor er geen configuratieverschillen tussen apparaten ontstaan.
De KV-cache persistentie van oMLX is ook essentieel in deze setup. Coding-agents keren in een sessie vaak terug naar eerdere context. oMLX cachet elk blok naar de SSD, zodat wanneer de agent terugkeert naar een eerder prefix, dit in milliseconden vanaf de schijf wordt hersteld in plaats van opnieuw te worden berekend. Dat maakt de lokale setup daadwerkelijk bruikbaar voor agent-werk, waar Hermes zich op richt.
Conclusie
Lokale modellen op Apple Silicon zijn geen zijproject meer. De M4 Pro Mac mini handelt dit moeiteloos af, de modellen zijn goed genoeg voor de meeste taken en je kunt ze wisselen wanneer je wilt. Je betaalt niet per token en je stuurt geen gevoelige data via externe endpoints. En wanneer er volgende week een beter model uitkomt, kun je dat met minimale inspanning en enkel de kosten van wat schijfruimte uitproberen.
Ik heb al een 128GB M5 Max Mac Studio besteld voor later dit jaar, maar ik ben tot nu toe ontzettend tevreden over de prestaties van deze M4 Pro Mac mini. Als je andere Apple Silicon-apparaten hebt, probeer het dan uit; je moet wellicht het model aanpassen aan je specificaties, maar de algemene setup blijft hetzelfde.
Mijn lokale model-setup op een M4 Pro Mac mini
De stack
- Qwen3.6-35B-A3B-OptiQ-4bit: mijn hoofdmodel voor alles wat redenering of diepgang vereist.
- Gemma-4-E4B-it-OptiQ-4bit: een lichtgewicht model voor eenvoudige chats, opmaak en andere routinetaken.
- oMLX: de inference-server.
- Tailscale: het tailnet dat de Mac mini, mijn iPhone en mijn MacBook met elkaar verbindt.
Hermes fungeert als de agent-backend op de Mac mini, waarbij mijn MacBook de desktopclient draait en mijn telefoon Telegram gebruikt. Voor gebruik buiten Hermes gebruik ik Apollo op iOS voor snelle chats (leest als Claude, goed voor incidentele vragen), Pi als mijn coding-agent, en Raycast AI op mijn Mac voor diverse kleine taken.
Waarom de moeite nemen?
De belangrijkste reden om lokaal te draaien is dat cloud-API's "gehuurd land" zijn. Aanbieders kunnen hun prijzen wijzigen, gebruikslimieten instellen of het model dat achter de schermen wordt aangeboden vervangen wanneer ze dat willen. Ik bereikte regelmatig de limieten van twee abonnementen van $200 per maand en had het gevoel dat de output op verschillende momenten varieerde; soms was een model prima, dan weer degradeerde de kwaliteit zonder vooraankondiging.
Gegevensprivacy is een ander punt. Je weet niet wat deze bedrijven met je data doen zodra ze die hebben. Ze kunnen het gebruik beperken, de data verkopen of deze per ongeluk blootstellen. In elk geval creëert dit een risico voor de operationele veiligheid. Als je werkt met gevoelige code, klantgegevens of eigen workflows, is het versturen hiervan naar een externe API een beslissing die je slechts één keer kunt nemen en niet ongedaan kunt maken.
Daarnaast is er AI-soevereiniteit. Ik heb gezien hoe de Amerikaanse overheid de uitrol van verschillende modellen heeft beperkt. Dit kan op elk moment door elke overheid gebeuren, om elke reden, en je hebt er geen controle over. Als je workflow afhankelijk is van een cloudmodel dat wordt beperkt, moet je stoppen of halsoverkop een alternatief zoeken. De enige manier om dit te voorkomen is door je eigen rekenkracht (compute) te bezitten.
Andere praktische voordelen:
- Voorspelbaarheid van kosten: API's zijn variabel; als je gebruik piekt, stijgt je rekening. Bij lokale hardware zijn de kosten beperkt tot de aanschaf van de hardware en de elektriciteit. Daarna is elke inference gratis.
- Latentie: Het ontbreken van een netwerk-roundtrip betekent snellere reacties voor dagelijkse taken. De media-engine van de M4 Pro handelt inference af op snelheden die voor de meeste prompts onmiddellijk aanvoelen.
- Offline mogelijkheden: Het werkt ook zonder internet. Voor agent-workflows die op de achtergrond draaien, is dit belangrijker dan het lijkt.
- Geen rate limits: API-providers knijpen je af wanneer je gebruiksdrempels bereikt. Je eigen machine geeft niet om hoeveel je draait.
Hoe ik het in de praktijk gebruik
De Mac mini staat altijd aan. Hij staat op mijn bureau en ik merk hem nauwelijks op, behalve wanneer ik hem nodig heb.
Hermes draait op de Mac mini en maakt gebruik van een lokaal model op dezelfde machine. Ik heb toegang tot mijn agent via Telegram (op mijn telefoon) en de Hermes-desktopapp op mijn MacBook. De desktopapp fungeert als een 'shell' en verbindt met een Hermes-backend op een ander apparaat (in dit geval de Mac mini). Hierdoor deel ik een backend, gesprekshistorie en vaardigheden over al mijn apparaten.
Daarnaast gebruik ik het volgende:
- Apollo op iOS: voor snelle, incidentele chats. Ik wilde iets dat leest als Claude, maar geen API-sleutel of abonnement vereist. Door Apollo te verbinden met
http://[mac-mini-tailnet-url]/v1 is het klaar. Ideaal voor vragen als "herschrijf deze alinea" of "wat betekent deze foutmelding".
- Raycast op Mac: voor willekeurige taken waarvoor ik geen aparte software wil installeren.
- Pi: voor coderen.
Het doel is niet om API-gebaseerde modellen volledig te vervangen, maar om de 80% van de verzoeken af te handelen die geen GPT-5 of Claude Opus vereisen. Wanneer ik die wel nodig heb, zijn ze nog steeds beschikbaar. Lokaal gebruik dekt simpelweg een groter deel van mijn dagelijkse bezigheden gratis af.
Uitleg over de modellen
Het lokaal draaien van een groot model komt neer op één ding: hoeveel RAM er daadwerkelijk in het geheugen moet passen. Veel mensen kijken naar het aantal parameters en trekken de verkeerde conclusie, omdat het verschil tussen dense modellen en mixture-of-experts (MoE) modellen cruciaal is op consumentenhardware.
Zo lees je een identifier:
Qwen3.6-35B-A3B-OptiQ-4bit
- Qwen3.6: modelfamilie en versie.
- 35B: totaal aantal parameters over alle experts.
- A3B: actieve parameters per token (3 miljard, niet 35).
- OptiQ-4bit: mixed-precision quantisatie (grotendeels 4-bit, 8-bit op gevoelige lagen).
gemma-4-e4b-it-4bit
- gemma-4: de Gemma 4-familie van Google.
- e4b: encoding-grootte, ongeveer 4 miljard parameters in totaal.
- it: instruction-tuned.
- 4bit: uniforme 4-bit quantisatie.
Het cruciale verschil is het "A3B"-gedeelte. Een dense 27B-model heeft voor elk enkel token 27 miljard parameters in het RAM geladen. Een MoE-model zoals de Qwen3.6-35B-A3B heeft 35 miljard parameters verdeeld over 256 experts, maar er worden er slechts ongeveer 3 miljard geactiveerd per token. De overige 32 miljard staan in het RAM zonder actief te zijn.
Op mijn 48GB Mac mini neemt de Qwen3.6-35B-A3B in 4-bit ongeveer 20GB RAM in beslag. Dat laat 28GB over voor context-windows, het besturingssysteem en andere processen. De Gemma-4-E4B is ongeveer 2,4GB, klein genoeg om aan te houden voor simpele taken waarbij het grote model overkill zou zijn.
Ter vergelijking: de MacBook Air van een vriend had 16GB in totaal. Een dense 27B in 4-bit heeft ongeveer 14GB nodig. Dat is vrijwel alles wat de machine heeft, minus de ruimte voor het OS. Het werkt dan even, maar zodra het geheugen vol is, schakelt hij over naar de SSD (swapping), wat het proces traag maakt.
MoE verandert dit. Het 35B-model uit mijn setup zou op diezelfde MacBook passen, omdat er per token slechts 3B parameters actief zijn. De GPU/Media Memory footprint is daardoor vergelijkbaar met die van een dense 6B-model, hoewel de volledige 35 miljard parameters in het unified memory staan.
Hoe controleer je of een model op jouw hardware werkt?
- Kijk eerst naar de quantized bestandsgrootte. Een 4-bit model is ongeveer gelijk aan het aantal parameters in gigabytes (35B params $\approx$ 17-20GB, afhankelijk van de quantisatiemethode).
- Trek de OS-overhead ervan af. macOS verbruikt op Apple Silicon ongeveer 6-8GB.
- Houd rekening met context-windows. Elke paar duizend tokens voegen megabytes toe aan de KV-cache. Reken op 8-16GB overhead als je lange gesprekken verwacht.
- Bij MoE-modellen is het totale aantal parameters misleidend. Kijk naar het aantal "actieve parameters" om het werkelijke geheugengebruik tijdens inference te begrijpen.
- Buffer. Als het model plus de context in het beschikbare unified memory passen met een buffer van 10-15%, zit je goed. Alles wat daar dichterbij komt, zal gaan swappen naar de SSD.
Modellen eenvoudig wisselen
Dit is het aspect waar weinig over wordt gesproken: je kunt je lokale modellen elke paar weken vervangen zodra er nieuwe versies uitkomen. Het is simpelweg een kwestie van downloaden en herstarten.
De workflow:
- Download het nieuwe model naar
~/models/.
- oMLX herkent dit automatisch vanuit de modeldirectory.
- Selecteer het model in de oMLX-app of herstart de server.
- Klaar.
Het admin-dashboard van oMLX heeft een ingebouwde HuggingFace modelbrowser. Zoek een model, klik op download, pas het model aan in Hermes, Pi, Raycast en Apollo, en het is geregeld. Veel van dit alles kan via de CLI, waardoor ik via SSH vanaf elk apparaat op de Mac mini kan inloggen.
Het gat tussen lokale modellen en API-modellen wordt snel kleiner. Wat een jaar geleden "matig" was, is nu competitief voor de meeste praktijktoepassingen, vooral op het gebied van coderen, redeneren en tool-gebruik. De 4-bit quantisatie van OptiQ houdt de kwaliteit verrassend hoog; de 35B-A3B op 4-bit verliest slechts ongeveer 1-2 punten in de meeste benchmarks vergeleken met BF16 (16-bit floating point, de ongecomprimeerde baseline). Dat is een acceptabele ruil voor een geheugengebruik van 48GB in plaats van 70GB.
Het netwerk
Tailscale creëert een mesh-netwerk tussen al mijn apparaten. De Mac mini, iPhone en MacBook zitten allemaal in hetzelfde private netwerk, zonder dat er iets openstaat naar het publieke internet.
De oMLX-server luistert op poort 8000. Elk apparaat op het tailnet kan verbinding maken. Raycast, Apollo iOS en de Hermes-desktopapp op mijn MacBook maken allemaal verbinding met hetzelfde eindpunt, waardoor er geen configuratieverschillen tussen apparaten ontstaan.
De KV-cache persistentie van oMLX is ook essentieel in deze setup. Coding-agents keren in een sessie vaak terug naar eerdere context. oMLX cachet elk blok naar de SSD, zodat wanneer de agent terugkeert naar een eerder prefix, dit in milliseconden vanaf de schijf wordt hersteld in plaats van opnieuw te worden berekend. Dat maakt de lokale setup daadwerkelijk bruikbaar voor agent-werk, waar Hermes zich op richt.
Conclusie
Lokale modellen op Apple Silicon zijn geen zijproject meer. De M4 Pro Mac mini handelt dit moeiteloos af, de modellen zijn goed genoeg voor de meeste taken en je kunt ze wisselen wanneer je wilt. Je betaalt niet per token en je stuurt geen gevoelige data via externe endpoints. En wanneer er volgende week een beter model uitkomt, kun je dat met minimale inspanning en enkel de kosten van wat schijfruimte uitproberen.
Ik heb al een 128GB M5 Max Mac Studio besteld voor later dit jaar, maar ik ben tot nu toe ontzettend tevreden over de prestaties van deze M4 Pro Mac mini. Als je andere Apple Silicon-apparaten hebt, probeer het dan uit; je moet wellicht het model aanpassen aan je specificaties, maar de algemene setup blijft hetzelfde.
Groetjes,