Derfor er ikke M-brikken din noen AI-kraftplugg
Derfor stopper Apple Silicon opp når du kjører AI-koding lokalt
Du kjøpte den feteste MacBooken som finnes. M4 Max med 128 GB felles minne. Prisen var stygg, men du tenkte: «Nå kan jeg kjøre skikkelige AI-kodingsverktøy uten å måtte leke med de små modellene.»
128 GB Unified Memory burde jo bety at du har rå kraft nok til å kjøre store språkmodeller uten problemer, ikke sant?
Feil. I alle fall ikke uten kamp.
Løftet som ikke ble innfridd
Apple Silicon var en genuint nytenkende arkitektur. Felles minne betyr at CPU og GPU deler samme buss – ingen dyre kopieringer fram og tilbake. For mange arbeidsoppgaver fungerer dette utmerket.
Men når du prøver å kjøre en skikkelig kodemodell lokalt, snur virkeligheten seg. Selv med aggressive optimaliseringer spesielt bygget for Metal, ender du opp med tall som dette:
| Konfigurasjon | Hastighet | |---------------|-----------| | Llama.cpp Q4_0 | ~71 tok/sec | | MLX 4-bit | ~81 tok/sec | | Optimalisert Qwen3-Coder-Next | ~120 tok/sec | | Optimalisert Qwen3.6-35B 4-bit | ~85 tok/sec |
Mønsteret er tydelig: så snart du beveger deg opp til modeller som faktisk duger til noe (7B+ parametere), treffer du en vegger. Uansett hvor mye optimalisering du kaster på problemet.
Hvorfor skjer dette?
En utvikler som har gravd dypt i dette, peker på minnebandbredde som flaskehalsen. Og det gir mening når du tenker på hvordan transformermodeller egentlig fungerer.
Hver eneste token som genereres krever at du leser enorme deler av modellens vekter fra minnet. M4 Max har riktignok solid bandbredde, men du er uansett begrenset av hvor fort du kan flytte data. Regneoperasjonene kan være raske, men de er kun like raske som dataene som mates inn.
Dette forklarer hvorfor mindre modeller oppleves som rakettraser sammenlignet med de store. En 0,1B-modell kan kanskje gi 1000 tokens per sekund. Hopp opp til 1,5B, og du faller til rundt 140. Scalingen er ikke lineær – den er brutal.
Hva er alternativene dine?
Hvis du trenger 200+ tokens per sekund med modeller som faktisk kan tenke og bruke verktøy, blir landskapet ganske trangt:
Skybaserte løsninger Anthropic (Claude), OpenAI, DeepSeek – de tilbyr enorm regnekraft, men månedskostnadene løper fort. 20 til 200+ dollar i måneden for seriøs bruk er ikke uvanlig. Pålitelig og raskt, men du er avhengig av eksterne tjenester.
Spesialisert maskinvare Cerebras leverer faktisk imponerende hastigheter (deres GPT-oss-120b kjører over 1000 tokens/sek), men prislappen er urealistisk for de fleste utviklere og mange team.
Lokale modeller med justerte forventninger Klarer du deg med 80-120 tokens per sekund? Modeller som Qwen3.5-32B eller lignende med 4-8 bit kvantisering kan gi grei koding assistanse. Nok til å være produktiv, bare du aksepterer litt ventetid.
Det egentlige spørsmålet: Lokalt eller sky?
Valget kommer egentlig an på hva du trenger:
- Velg lokalt hvis du har strenge personvernkrav, ustabil internettforbindelse, eller vil eksperimentere uten løpende kostnader
- Velg sky hvis konstant hastighet betyr mer enn eierskap, du trenger den absolutt beste modellkapasiteten, eller budsjettet tillater abonnementskostnader
For mange utviklere gir en hybrid tilnærming mest mening – lokale modeller til testing og raske oppgaver, sky for produksjonsoppgaver der fart og kapasitet er kritiske.
Konklusjonen
Apple Silicon er imponerende for mange AI oppgaver, men å kjøre rask lokal inferens med kapable kodemodeller er fortsatt en kamp. Maskinvaren ble rett og slett ikke designet for denne arbeidsbelastningen, og verken Metal-optimalisering eller kreative triks kan omgå fundamentale arkitektoniske begrensninger.
Bygger du en AI-assistert utviklingsflyt? Da er det smartest å matche infrastrukturen mot dine faktiske behov – og være ærlig med deg selv om «lokalt først»-tilnærmingen faktisk tjener deg, eller bare bremser deg.
Hva er din erfaring med lokal AI-inferens? Har du funnet oppsett som bryter gjennom disse ytelsesgrensene?