De Mac Studio in de meterkast — en wat eronder ligt

Een long-read over de verleiding van lokaal AI-hosten, de rekensom die lijkt te kloppen, en de vraag die eronder hoort te liggen.

Een groepschat vol goede intenties

In een WhatsApp-groep met twee bevriende ondernemers ging het onlangs over het zelf hosten van grote taalmodellen. Het begon met een link naar een Beelink mini-pc en eindigde enkele uren later bij een nieuwe Mac Studio van vijfduizend euro en een terugverdientijd van zeven maanden. Tussen die twee punten lag een overtuigende redenering, gebouwd op reële frustraties en bijeengeharkte kennis. Niemand in de groep had kwade bedoelingen. Niemand was dom of onwetend. En toch kwam uit de optelsom iets wat bij nadere beschouwing niet klopte.

Ik was een van de drie aan tafel. En hoewel ik in die draad een sceptische positie innam, moest ik achteraf toegeven dat ook ik ergens onderweg een technische claim had gepost die niet klopte. Niet uit onwetendheid — als je me er rustig naar vraagt weet ik beter — maar omdat je in een WhatsApp-groep op een donderdagochtend iets typt dat net genoeg klopt om de discussie te laten doorgaan. Dat is ongeveer het niveau waarop dit soort aankoopbeslissingen in de praktijk genomen wordt.

Die ervaring is het startpunt voor deze long-read. Want de discussie die wij hadden, wordt op dit moment in ontelbaar veel kringen gevoerd. Onder zelfstandigen die Claude of ChatGPT intensief gebruiken en zien wat dat per maand kost. Onder ontwikkelaars die een Mac Studio op hun bureau zien staan en zich afvragen of ze daarmee af kunnen van hun abonnement. En in toenemende mate ook binnen organisaties, waar mensen met enthousiasme en een half begrepen artikel over Apple Silicon bij hun IT-afdeling binnenlopen met een voorstel dat op het eerste gezicht logisch klinkt.

Het probleem is niet de aankoop. Het probleem is dat de verkeerde vraag gesteld wordt, en dat de rekensom die uiteindelijk gemaakt wordt niet meet wat ze denkt te meten.

De verleiding — en waarom ze echt is

Laten we de positie van de mensen die deze stap overwegen serieus nemen. Hun frustratie is reëel, hun redenering plausibel, en het zou onfair zijn om de discussie te openen met een karikatuur.

Wie intensief gebruikmaakt van een frontier-model zoals Claude of GPT-5 merkt al snel dat de kosten oplopen. Een Pro-abonnement van twintig euro per maand volstaat voor incidenteel gebruik, maar wie serieus werkt met agentische workflows, grote codebases, of lange contextvensters komt vrijwel onvermijdelijk in het domein van pay-per-token-API-gebruik. Een creditcard die aan het eind van de maand voller is dan verwacht, is een terugkerende ervaring. De stap naar de gedachte dat het goedkoper moet kunnen kán is menselijk.

Tegelijkertijd heeft Apple Silicon in de afgelopen jaren iets bijzonders mogelijk gemaakt. Omdat CPU en GPU op deze chips het geheugen delen — de zogenaamde unified memory — kan een Mac Studio met 128 of 192 gigabyte geheugen modellen draaien die op een klassieke pc een datacenter-GPU van tienduizenden euro's zouden vereisen. De tools zijn volwassen geworden: Ollama, LM Studio, MLX, llama.cpp. Installatie is geen weekendproject meer maar een middag. Een open-weight model zoals Llama 3.3 70B of DeepSeek draait daadwerkelijk op zo'n machine.

Dan volgt de rekensom. Vier zware gebruikers betalen elk honderd à tweehonderd euro per maand aan een Claude-abonnement. Bij elkaar is dat zevenhonderd euro per maand. Een nieuwe Mac Studio van vijfduizend euro is daarmee in zeven maanden terugverdiend. En ook na die zeven maanden blijft het ding daar staan, voor nog jaren. Op papier: een no-brainer.

Dit is het punt waarop de meeste discussies stoppen. De som klopt, de hardware werkt, de case is rond. Alleen meet de som niet wat ze denkt te meten — en daar begint het eigenlijke verhaal.

Wat de rekensom niet meet

Frontier-modellen zoals Claude Opus of GPT-5 zijn niet uitwisselbaar met de open-weight modellen die op een Mac Studio draaien. Dat is niet een marginaal kwaliteitsverschil. Het zijn verschillende producten met een oppervlakkig vergelijkbare interface. De redenering dat je het ene tegen het andere kunt inruilen, behandelt ze als fungibel. Maar een hamer en een elektrische boor zien er ook allebei uit als een stuk gereedschap; dat maakt ze nog niet inwisselbaar.

Het scherpst voelbaar wordt dit verschil bij serieus, iteratief werk. Code schrijven waarbij meerdere bestanden tegelijk doordacht moeten worden, agents die over langere taken redeneren, complex analytisch werk met grote context. Hier zit het verschil niet in tien procent maar in aard. Een goed lokaal 70B-model produceert een antwoord dat lokaal correct is maar het grotere geheel mist. Een frontier-model houdt de samenhang vast. Wie dit aan den lijve heeft ervaren weet wat ik bedoel; wie het nooit echt heeft vergeleken vermoedt dat het meevalt.

Daar komt bij dat de ervaring van werken met een frontier-model niet alleen in het model zit. Die zit ook in de agentische infrastructuur eromheen — de manier waarop Claude Code of vergelijkbare tools meerdere bestanden tegelijk kunnen lezen en wijzigen, shell-commando's uitvoeren, zelfstandig debuggen, een project als geheel begrijpen. Een lokaal model installeren is één ding. Die hele omgeving nabouwen is een apart project, en een die zelden realistisch wordt ingeschat aan de voorkant.

Het tempo is de derde factor. Een lokaal 70B-model op een Mac Studio produceert globaal acht tot vijftien tokens per seconde. Claude zit op zestig tot honderd. Op papier een factor vijf tot tien, in de praktijk zwaarder omdat iteratief werk in cycli gaat. Als elke cyclus drie keer zo lang duurt, verschuift het werkritme fundamenteel. Mensen die dit serieus proberen rapporteren vrijwel zonder uitzondering dat ze binnen twee weken terug zijn bij hun frontier-abonnement — niet vanwege de kwaliteit, vanwege het tempo.

De rekensom van zeven maanden terugverdientijd veronderstelt dat de Mac Studio het Claude-gebruik daadwerkelijk vervangt. Precies die aanname is waar de som in elkaar zakt.

Een tussenstap: wat er onder de motorkap gebeurt

Om de discussie in eigen kring scherper te kunnen voeren, is enige technische achtergrond nodig. Niet omdat iedereen expert hoeft te worden, maar omdat de meeste aankoopbeslissingen struikelen over terminologie die net verkeerd begrepen wordt.

Een groot taalmodel bestaat uit miljarden parameters — getallen die tijdens training geleerd zijn en samen de 'kennis' van het model vormen. Voor elke vraag die je stelt, moeten al die parameters door het geheugen. Voor een 70B-model betekent dat ongeveer veertig tot vijftig gigabyte aan gewichten in geheugen, afhankelijk van compressie. Voor een 405B-model vier à vijf keer zoveel. Voor frontier-modellen zoals Claude Opus of GPT-5, waarvan de precieze groottes niet openbaar zijn, vermoedelijk aanzienlijk meer.

Hieruit volgt de eerste harde grens: je kunt geen model draaien dat groter is dan het beschikbare geheugen. Een Mac Studio met 64 gigabyte draait Llama 70B maar net, en laat geen ruimte voor grotere modellen of lange context. Een Mac Studio met 192 gigabyte heeft wél ruimte. Dat is het eerste verschil dat telt.

Het tweede verschil is snelheid. Hoe sneller het geheugen de parameters door de chip kan verplaatsen — de memory bandwidth — hoe meer tokens per seconde je krijgt. Hier schuilt een interessante praktische observatie: een tweedehands M1 Ultra Studio met 128 gigabyte geheugen en 800 gigabyte per seconde bandbreedte is voor LLM-werk feitelijk sneller dan een nieuwe M4 Max Studio met 64 gigabyte en 546 gigabyte per seconde — ondanks dat de M4-chip drie generaties nieuwer is. Voor alle andere toepassingen wint de M4. Voor deze specifieke toepassing niet.

Het derde verschil is wat je níét nodig hebt. Een veelgehoorde aanname is dat de Neural Engine in Apple Silicon de reden is dat Macs zo geschikt zijn voor LLM-werk. Dat is feitelijk onjuist. Ollama, llama.cpp en MLX — de tools die lokaal LLM-werk mogelijk maken — gebruiken de Neural Engine helemaal niet. Ze draaien op de GPU via Metal. De reden dat Apple Silicon populair is, is uitsluitend de unified memory. Dit onderscheid is niet academisch: het beïnvloedt welk model Mac je koopt. Wie een M4 koopt in plaats van een oudere Ultra 'vanwege de betere Neural Engine' baseert die keuze op een verkeerd model van wat er onder de motorkap gebeurt.

Wie de werkelijke variabelen begrijpt — geheugengrootte, memory bandwidth, aantal GPU-cores — kan scherper kiezen. En komt vaak uit op een andere configuratie dan de marketing suggereert.

De vraag die bijna niemand stelt

Alles wat hierboven staat over kwaliteit, tempo en hardware is relevant, maar behandelt een tweede-orde-vraag. De eerste-orde-vraag is een andere, en die wordt in de meeste gesprekken overgeslagen: wat ga je er precies mee doen?

Niet wat je ermee zou kunnen doen, want dat antwoord is altijd 'van alles'. Niet wat je ermee wil experimenteren, want dat is legitiem maar iets anders dan een business case. De concrete vraag: welke taak, met welk volume, onder welke kwaliteitseis, ga je daadwerkelijk uitvoeren op deze machine?

Bij die vraag valt veel weg. Dagelijkse productiviteit — mails, rapporten, samenvattingen, brainstormen — draait prima op een frontier-abonnement van twintig euro per maand. Coding op serieus niveau vereist een frontier-model, eveneens via abonnement. Voor die twee samen, die voor de meeste kenniswerkers het leeuwendeel van hun AI-gebruik vormen, is de Mac Studio simpelweg niet het juiste antwoord.

Er zijn echter categorieën waar lokaal hosten wél bijzonder nuttig is, en het is waardevol die scherp te onderscheiden. Wie grote volumes tekst moet classificeren of transformeren — duizenden documenten samenvatten, productbeschrijvingen in batch genereren, embeddings bouwen voor een eigen zoeksysteem — komt op een breakeven-punt waar lokaal goedkoper is dan API. Wie eigen data niet buiten de deur wil of mag hebben, om juridische of regulatoire redenen, heeft lokaal hosten als serieuze optie. Wie wil leren, experimenteren met fine-tuning, of agents wil bouwen die in lange loops werken zonder tokenangst, vindt lokaal een waardevol speelveld.

Geen van die use cases is hetzelfde als 'ik wil af van mijn Claude-abonnement'. En juist dat verschil maakt het verschil tussen een uitgave van enkele duizenden euro's die nuttig besteed is, en een apparaat dat na twee maanden enthousiast gebruik grotendeels stof vangt terwijl het abonnement gewoon weer actief is geworden.

De eerlijke vraag is niet 'kan deze machine Claude vervangen' maar 'welke taak rechtvaardigt deze machine, onafhankelijk van Claude'. Dat is een volkomen andere vraag, en ze leidt tot volkomen andere aankoopbeslissingen.

Van keukentafel naar bestuurskamer

Dit zou allemaal een privé-aangelegenheid kunnen zijn — een groep enthousiastelingen die thuis spullen koopt en daar hun lol mee hebben. Maar hetzelfde denkpatroon speelt op dit moment ook in serieuze organisaties, waar het meer kost dan een Mac Studio en waar de gevolgen verder reiken dan een stoffig apparaat in de meterkast.

In veel bedrijven en instellingen wordt gesproken over het 'zelf gaan hosten' van AI. De motieven zijn vaak oprecht: datasoevereiniteit, compliance, onafhankelijkheid van grote Amerikaanse aanbieders, controle over kosten. Die motieven zijn te respecteren en in bepaalde gevallen dwingend. Maar daaronder ligt soms hetzelfde patroon als in mijn WhatsApp-groep: een aanname dat lokaal hosten een directe substitutie is voor frontier-API-gebruik, zonder dat de use case scherp is gespecificeerd, en zonder dat het verschil tussen frontier-kwaliteit en open-weight-kwaliteit expliciet is gemaakt.

In de context van grote organisaties is dat patroon duurder. Niet een Mac Studio maar een gespecialiseerd GPU-cluster van enkele tonnen. Niet een stoffig apparaat maar een AI-platform-team dat onderhoud moet plegen. Niet een teleurgestelde hobbyist maar een portfolio van toepassingen die achterblijven bij de verwachting, omdat het lokale model simpelweg niet doet wat het bedoelde frontier-model zou hebben gedaan.

Voor programma- en projectmanagers die dit type discussie in hun opdrachtgeversorganisaties meemaken, is de les dezelfde als voor de groepschat: de eerste vraag is niet welke hardware, maar welke taak. En de tweede vraag is niet welk model, maar welk kwaliteitsniveau die taak werkelijk vereist. Pas als die twee vragen eerlijk beantwoord zijn, is de derde vraag — zelf hosten of uitbesteden, open-weight of frontier, on-premises of cloud — productief te beantwoorden.

In veel gevallen blijkt die uitkomst een hybride te zijn: frontier-modellen via een hyperscaler onder bestaande cloud-contracten voor het werk dat hoge kwaliteit vraagt, aangevuld met lokaal gehoste open-weight modellen voor specifieke taken waar data-soevereiniteit of volume het rechtvaardigt. Dat is een nuchterder antwoord dan 'wij gaan zelf hosten', en het heeft als bijkomend voordeel dat het daadwerkelijk werkt.

De WhatsApp-groep en de bestuurskamer stellen dezelfde vraag op verschillende schaal. En struikelen over hetzelfde misverstand.

De WhatsApp-groep als slechte raadgever

Er is een kleine knipoog die in deze long-read niet mag ontbreken, al was het maar om mezelf eraan te herinneren. De groepschat is een slechte plek om technische aankoopbeslissingen van duizenden euro's te nemen. Dat klinkt vanzelfsprekend maar is het niet, want precies daar worden ze wél genomen — of in elk geval ingeleid.

De dynamiek is herkenbaar. Iemand post een link. Iemand anders reageert met enthousiasme. Een derde corrigeert. Iemand rekent door. De anderen typen iets wat ongeveer klopt maar niet helemaal. Gaandeweg verschuift de toon van sceptisch naar 'misschien toch interessant'. Niemand leest tegen die tijd nog kritisch mee; iedereen bouwt voort op wat ervoor staat. En voor je het weet heb je een Mac Studio in je winkelmand staan.

Het is niet dat de mensen in zulke groepen dom zijn. Ik had in mijn eigen draad precies de claim geplaatst die technisch niet klopte — niet uit onkunde, maar omdat je op een mobiele telefoon, tussen twee vergaderingen door, iets typt dat goed genoeg lijkt. Dat is de werkelijke kwaliteit van ad hoc-kennisuitwisseling: niet fout, niet goed, net rijp genoeg om de discussie verder te laten dwalen.

De remedie is niet de groepschat vermijden. De remedie is om een aankoopbeslissing van enige omvang uit de groepschat te tillen en ergens anders rustig te doordenken. Liefst met iemand die je tegengas durft te geven, of met een instrument dat je dwingt om je use case eerlijk te formuleren. Dat kost twintig minuten. Een verkeerde aankoop kost duizenden euro's en een half jaar leerproces.

Wat wel een goede beslissing is

Zelf ben ik er na dit hele denkwerk nog niet uit of ik die tweedehands Mac Studio ga kopen. Wat ik wel weet, is dat ik de vraag nu anders stel dan aan het begin van die donderdagochtend. Niet 'vervangt dit mijn Claude-abonnement' — het antwoord daarop is nee. Maar: 'zijn er concrete taken waarvoor ik deze capaciteit serieus ga inzetten?' Op die vraag heb ik nog geen sluitend antwoord. En dat is de eerlijke plek om te staan voordat er iets besteld wordt.

Voor wie zichzelf of zijn organisatie op vergelijkbaar terrein ziet staan, is dat misschien de bruikbaarste les van dit hele verhaal. Niet welk apparaat, niet welk model, niet welk abonnement. Maar: welke taak, met welk volume, onder welke kwaliteitseis, gaat deze investering daadwerkelijk dragen?

Pas als die vraag eerlijk beantwoord is, is elke vervolgvraag productief te beantwoorden. Zonder dat antwoord is elke aankoop een gok — of die nu duizenden euro's kost of honderdduizenden.

Een Mac Studio in de meterkast is geen oplossing. Het is het begin van een vraag waarvan de meesten van ons niet eens wisten dat ze nog niet gesteld was.