MacBook Pro M4 Max och drömmen om lokal AI – en verklighetscheck

Du har precis investerat i ett MacBook Pro med M4 Max och 128GB unified memory. I huvudet ser du redan hur du kör en kraftfull lokal AI-kodningsassistent utan att ens behöva tänka på det. 128GB unified memory – det borde väl vara mer än nog för att köra stora språkmodeller?

Tro det om du vill. Men verkligheten är som så ofta mer komplicerad.

Löftet som inte riktigt håller

Apple Silicon var verkligen en innovation. Unified memory-arkitekturen betydde att data inte längre behöver skuffas fram och tillbaka mellan CPU och GPU-minne. Allt ligger tillsammans, och teorin var att detta skulle ge snabbare bearbetning för AI-arbetsbelastningar.

För många uppgifter stämmer det utmärkt.

Men när vi pratar om att köra stora språkmodeller för kodningsassistans? Då börjar siffrorna tala ett annat språk. Själv med specialbyggda Metal-inference-motorer som optimerats aggressivt, så platåar prestandan på förutsägbara nivåer:

• Llama.cpp Q4_0: Cirka 70,9 tokens/sekund
• MLX 4-bit: Ungefär 80,6 tokens/sekund
• Egenoptimerad Qwen3-Coder-Next: Runt 120 tokens/sekund
• Egenoptimerad Qwen3.6-35B vid 4-bit: Omkring 85 tokens/sekund

Mönstret är tydligt: så fort du börjar köra modeller i "användbara" storlekar – vanligtvis 7B parametrar eller mer för kodningsuppgifter – så slår du i en vägg. Oavsett hur mycket du optimerar.

Varför händer det här?

Utvecklaren bakom dessa benchmarks misstänker att minnesbandbredden, inte råprocessorkraften, är flaskhalsen. Och det intuitiva i den förklaringen blir tydligare när du förstår hur transformer-modeller fungerar.

Varje token-generering kräver att en stor del av modellens vikter läses från minnet. Och även med M4 Max:s imponerande bandbredd är du i slutändan begränsad av hur snabbt du kan flytta data. Matrismultiplikationer kan vara blixtsnabba, men de är bara så snabba som data som matas in i dem.

Det förklarar varför mindre modeller presterar så mycket bättre – det hela handlar helt enkelt om hur mycket data som måste flyttas. En 0,1B-modell kan kanske nå 1000 tokens/sekund, men hoppa upp till 1,5B och du rasar till runt 140 tokens/sekund. Skalningen är inte linjär – den är brutal.

Vilka alternativ finns det?

Letar du efter kodningsassistans i 200+ tokens/sekund samtidigt som du vill behålla resonemangsförmåga och verktygsanrop? Då krymper landskapet betydligt.

Molnlösningar Hostade modeller från Anthropic (Claude), OpenAI och DeepSeek levererar rejäl datorkraft, men kommer med månadskostnader på allt från 20 till 200+ dollar för seriöst bruk. Tillförlitliga och snabba, men du är beroende av externa tjänster och deras tillgänglighet.

Specialiserad hårdvara Cerebras levererar verkligen imponerande inferenshastigheter – deras GPT-oss-120b-modell kör i över 1000 tokens/sekund – men prissättningen placerar det utom räckhåll för de flesta enskilda utvecklare och även många team.

Lokala modeller med justerade förväntningar Behöver du lokal inferens? Fråga dig då om du kan acceptera lite långsammare hastigheter. Modeller som Qwen3.5-32B eller liknande arkitekturer vid 4-8 bitars kvantisering kan ge hyfsad kodningsassistans i 80-120 tokens/sekund – tillräckligt för produktivt arbete om ditt arbetsflöde tillåter lite extra latens.

Den verkliga frågan: Lokalt eller moln?

Den här diskussionen handlar i grunden om dina specifika behov:

• Välj lokalt om du har strikta dataskyddskrav, intermittent internetuppkoppling, eller vill experimentera utan löpande kostnader
• Välj moln om konsekvent hastighet väger tyngre än ägande, du behöver de absolut bästa modellkapaciteterna, eller din beräkningsbudget klarar av prenumerationer

För många utvecklare är en hybridstrategi mest rationell – lokala modeller för experimentering och snabba uppgifter, moln för produktionsarbetsbelastningar där hastighet och kapacitet är kritiskt.

Sammanfattningen

Apple Silicon är verkligen imponerande för många AI-uppgifter, men att köra snabb lokal inferens med kapabla kodningsmodeller förblir en utmaning. Hårdvaran helt enkelt inte designad för den här specifika arbetsbelastningen, och ingen mängd Metal-optimering kan överkomma fundamentala arkitektoniska begränsningar.

Bygger du ett AI-assisterat utvecklingsarbetsflöde? Då är din bästa strategi att matcha infrastrukturen med dina faktiska behov – och vara ärlig mot dig själv om huruvida "lokalt först"-tänket verkligen tjänar dig, eller snarare håller dig tillbaka.

Vad är din erfarenhet av lokal AI-inferens? Har du hittat konfigurationer som bryter igenom dessa prestandabarriärer?