Kör AI-kodningsagenter lokalt på din Mac – så kommer du igång

Varför köra lokalt?

Vi har alla varit där. Du är mitt i en kodningssession, kreativiteten flödar, och så — internet ligger nere. Din molnbaserade AI-assistent blir värdelös, och du står där och stirrar på din kod utan att veta vad du ska göra härnäst.

Det där hände mig nyligen, och det fick mig äntligen att utforska möjligheten att köra en kapabel AI-kodningsagent helt lokalt. Det jag upptäckte förvånade mig: med rätt konfiguration kan du få förvånansvärt respektabel prestanda på Apple Silicon – ofta bättre än specialoptimerade Mac-lösningar.

Konfigurationen som faktiskt fungerar

Efter en hel del testande och benchmarking landade jag i den här setupen på min M1 Max med 64GB unified memory:

Kärnstack:

• llama.cpp byggt med Metal-acceleration
• Gemma 4 26B-A4B i GGUF-format (kvantiserad till Q4)
• Multi-Token Prediction (MTP) som draft-modell för spekulativ avkodning
• Gemma 4 multimodal projector för skärmdumpsstöd
• Pi som terminalbaserad kodningsagent

Det här är inte den mest kraftfulla setupen du teoretiskt sett kan bygga, men det är den perfekta balansen för verklig användbarhet. Du vill ha hastighet mätt i tokens per sekund, inte minuter per svar.

Siffrorna som verkligen spelar roll

Jag körde konsekventa benchmarks med samma prompt över alla konfigurationer:

"Skriv en kompakt Python-funktion som parsar ett unified diff och returnerar de ändrade filvägarna. Förklara sedan två edge cases."

Varje test genererade ungefär 128 tokens, vilket gav en rättvis jämförelse av genereringshastigheten.

Baseline-prestanda:

Att köra Gemma 4 direkt genom llama.cpp med Metal gav oss 58,2 tokens per sekund. Det är användbart, men ärligt talat? Det kändes segt under riktiga kodningssessioner där du gör flera tool calls och väntar på svar.

MTP-effekten:

Här blir det intressant. Multi-Token Prediction låter modellen "spekulera" flera tokens framåt, acceptera korrekta predictioner och rulla tillbaka inkorrekta. Med Q8 MTP draft-modellen aktiverad hoppade prestandan till 72,2 tokens per sekund – en 24% förbättring utan någon förändring av huvudmodellen.

Prompt-bearbetningen stannade i stort sett samma (runt 297-299 tokens/sekund), men det är genereringshastigheten som spelar roll för agent-arbetsflöden. Du skickar inte nya prompts hela tiden – du väntar på att modellen ska generera svar, fatta beslut och exekvera verktyg.

Jag testade draft-token-räkningar från 1 till 6, och på min M1 Max hamnade 3 draft tokens i den perfekta balansen. Värden över 4 började faktiskt sakta ner, vilket gör sense – mer spekulation betyder mer slösat arbete när predictionerna är fel.

llama.cpp vs. MLX: Den överraskande vinnaren

Här blev jag överraskad: jag förväntade mig att MLX ( Apples egna ML-ramverk) skulle dominera eftersom det är specifikt optimerat för Apple Silicon. Verkligheten var annorlunda.

| Runtime | Generering tok/s | |---------|------------------| | llama.cpp Metal + MTP | 72,2 | | llama.cpp Metal | 58,2 | | MLX-LM (Unsloth 4-bit) | 45,8 | | MLX-LM (standard 4-bit) | 43,9 | | MLX-LM (OptiQ 4-bit) | 38,1 |

Llama.cpp med MTP var ungefär 58% snabbare än den bästa MLX-konfigurationen. Åren av optimeringsarbete som lagts ner på llama.cpp har tydligt gett utdelning – det kör utmärkt på macOS trots att det är cross-platform.

Lägga till visionsförmågor

För en ordentlig kodningsagent-upplevelse vill du kunna skicka skärmdumpar. Kanske vill du att agenten ska se vad den byggt, eller granska en UI-ändring du precis gjorde.

Haken? Bara Gemma 4 12B är internt multimodal. Den 26B-modell vi använder behöver den externa multimodal projectorn laddad bredvid.

När jag lade till --mmproj projektorn till llama.cpp så annonserade den korrekt multimodala förmågor till Pi, och bildverktygsutmatningar började flöda genom korrekt. Ännu viktigare – detta introducerade ingen märkbar slowdown – genereringshastigheten stannade på 72,2 tokens per sekund.

Den verkliga upplevelsen

Med den här setupen tittar du på ungefär 17GB modellfiler (16GB för huvudmodellen, plus MTP-headen och projektorn). För någon med 64GB unified memory är det helt hanterbart.

Pi som agent ger ett rent terminal-interface som kopplar till OpenAI-kompatibelt API som llama.cpp:s server-mode exponerar. Det betyder att du kan använda det med vilket verktyg som helst som stödjer OpenAI:s API-format, vilket ger dig flexibilitet utan vendor lock-in.

Den största fördelen? När din internetuppkoppling strejkar – och det kommer den att göra, vid värsta möjliga momentet – så fortsätter du koda. Agenten kanske är lite långsammare än molnalternativen, men den är responsiv nog för att upprätthålla ditt arbetsflöde.

Komma igång

Du behöver bygga llama.cpp med Metal-stöd aktiverat. Projektet har bra dokumentation för macOS-builds, och väl kompilerad ger server-mode dig den OpenAI-kompatibla endpointen.

För modeller är Unsloth GGUF-kvantiseringarna på Hugging Face välinvesterade. Du vill ha Q4_K_XL-kvantiseringen för huvudmodellen och matchande Q8 MTP draft-modell.

Finjustera ditt --spec-draft-n-max-värde – börja på 3 och testa från 1 till 6 för att hitta vad som fungerar bäst på din specifika hårdvara. Olika Apple Silicon-konfigurationer kan ha olika sweet spots.

Är det värt det?

Om du kodar regelbundet med AI-assistenter och har hårdvaran (16GB minimum, 32GB+ rekommenderas), absolut. Oberoendet från internetuppkoppling ensamt gör det värdefullt, och med MTP som tar genereringshastigheterna till genuint användbart territorium är upplevelsen förvånansvärt polerad.

Du kommer inte matcha GPT-4-klass intelligens med dessa open-modeller, men för kodkomplettering, refaktorering, felsökningshjälp och generella kodningsagent-uppgifter? Det är mer kapabelt än de flesta förväntar sig, och det är ditt – körande lokalt, privat, utan latency-spikar eller service-utfall.

Verktygen har mognat betydligt. Om du provat lokala modeller förut och blivit besviken på hastigheten, ge den här setupen en chans. MTP förändrar ekvationen avsevärt.