Waarom je M4 Max MacBook niet zo snel draait als je hoopt

Je hebt net een MacBook Pro met M4 Max en 128GB unified memory gekocht. Je stelt je voor dat je moeiteloos een lokale AI coding assistant draait, toch? 128GB unified memory moet toch flinke spierkracht betekenen voor het draaien van large language models.

Helaas, zo ontdekte één developer aan den lijve, valt dat een beetje tegen. Zijn reis door custom Metal inference engines, agressieve optimalisaties en verschillende model-architecturen onthulde iets frustrerends: er zit een plafond rond de 80-150 tokens per seconde zodra je met enigszins bruikbare modelgroottes werkt.

De belofte versus de praktijk

Apple Silicon bracht met de unified memory architectuur daadwerkelijk innovatie. Geen data meer verplaatsen tussen CPU en GPU—alles woont bij elkaar, wat theoretisch snellere verwerking voor AI-taken mogelijk maakt. Voor veel taken klopt dat ook.

Maar voor het draaien van large language models voor coding assistance vertellen de cijfers een ander verhaal. Zelfs met agressief geoptimaliseerde inference engines specifiek gebouwd voor Metal,，稳定在 voorspelbare niveau's:

• Llama.cpp Q4_0: Ongeveer 70.9 tokens/seconde
• MLX 4-bit: Circa 80.6 tokens/seconde
• Custom geoptimaliseerd Qwen3-Coder-Next: Ruwweg 120 tokens/seconde
• Custom geoptimaliseerd Qwen3.6-35B op 4-bit: Rond 85 tokens/seconde

Het patroon wordt duidelijk: zodra je op "bruikbare" parameter-aantallen zit (over het algemeen 7B+ voor coding-taken), loop je tegen een muur aan—onafhankelijk van je optimalisatie-inspanningen.

Waarom gebeurt dit?

De developer achter deze benchmarks vermoedt dat memory bandwidth, niet pure rekenkracht, de bottleneck is. En dit maakt intuïtief wel sense als je nadenkt over hoe transformer models werken.

Elke token-generatie vereist het uitlezen van een flink deel van de modelgewichten uit het geheugen. Zelfs met de indrukwekkende bandwidth van de M4 Max, ben je uiteindelijk beperkt door hoe snel je data kunt verplaatsen. Matrix vermenigvuldigingen kunnen snel zijn, maar ze zijn alleen zo snel als de data die erin gaat.

Dit verklaart waarom kleinere modellen dramatisch beter presteren—er is simpelweg minder data te verplaatsen. Een 0.1B parameter model haalt misschien 1.000 tokens/seconde, maar spring naar 1.5B en je zakt naar zo'n 140 tokens/seconde. De schaling is niet lineair; het is meedogenloos.

Wat zijn je opties?

Als je coding assistance zoekt met 200+ tokens/seconde met behoud van redenering en tool-calling capaciteiten, wordt het landschap een stuk smaller:

Cloud-oplossingen Hosted models van providers zoals Anthropic (Claude), OpenAI en DeepSeek bieden flinke rekenkracht, maar komen met abonnementskosten tussen de €20 en €200+ per maand voor serieus gebruik. Ze zijn betrouwbaar en snel, maar je bent afhankelijk van externe diensten en hun beschikbaarheid.

Specialized Hardware Cerebras biedt werkelijk indrukwekkende inference snelheden (hun GPT-oss-120b model draait op 1000+ tokens/seconde), maar de prijs maakt het onbereikbaar voor de meeste individuele developers en veel teams.

Lokale modellen met aangepaste verwachtingen Als je lokale inference nodig hebt, overweeg dan of je iets langzamere snelheden kunt accepteren. Modellen zoals Qwen3.5-32B of vergelijkbare architecturen op 4-8 bit quantization kunnen degelijke coding assistance bieden op 80-120 tokens/seconde—genoeg voor productief werk als je workflow iets meer latency toestaat.

De echte vraag: Lokaal versus cloud

Dit debat komt uiteindelijk neer op je specifieke behoeften:

• Kies lokaal als je strikte data-privacy-eisen hebt, onregelmatige internettoegang, of wilt experimenteren zonder doorlopende kosten
• Kies cloud als consistente snelheid belangrijker is dan eigendom, je de absolute beste model-capaciteiten nodig hebt, of je compute-budget subscriptions aankan

Voor veel developers is een hybride aanpak het meest praktisch—lokale modellen voor experimentatie en snelle taken, cloud voor productieworkloads waar snelheid en capaciteit kritiek zijn.

De conclusie

Apple Silicon is indrukwekkend voor veel AI-taken, maar snelle lokale inference met capabele coding models draaien blijft uitdagend. De hardware is simpelweg niet ontworpen met deze specifieke workload in gedachten, en geen hoeveelheid Metal-optimalisatie kan fundamentele architectuurbeperkingen overwinnen.

Als je een AI-ondersteunde development workflow opzet, is je beste gok om je infrastructuur af te stemmen op je daadwerkelijke behoeften—en eerlijk te zijn over of de "lokaal first" aanpak je helpt of juist beperkt.

Wat is jouw ervaring met lokale AI inference? Heb je configuraties gevonden die door deze performance-barrières breken?