Få AI til å kode på din egen Mac

Hvorfor kjøre lokalt?

Alle som jobber med kode har opplevd det. Du er midt i en god arbeidsflyt, kreativiteten flyter, og så – internett faller ut. Din skybaserte AI-assistent blir ubrukelig, og du sitter igjen og stirrer på koden.

Dette skjedde med meg nylig, og det pushet meg til endelig å utforske hvordan man kan kjøre en skikkelig AI-kodingsagent lokalt. Det jeg oppdaget overrasket meg: med riktig oppsett kan du få overraskende god ytelse på Apple Silicon, ofte bedre enn spesialoptimaliserte Mac-løsninger.

Oppsettet som faktisk funker

Etter mye testing og benchmarking, her er konfigurasjonen som leverte beste resultater på min M1 Max med 64GB unified memory:

Kjerneteknologien:

• llama.cpp bygget med Metal-akselerasjon
• Gemma 4 26B-A4B i GGUF-format (kvantisert til Q4)
• Multi-Token Prediction (MTP) draft-modell for spekulativ dekoding
• Gemma 4 multimodal projektor for skjermbilde-støtte
• Pi som terminalbasert kodingsagent

Dette er kanskje ikke det kraftigste oppsettet du theoretisk kan bygge, men det er sweet spoten for praktisk bruk. Du vil ha hastighet målt i tokens per sekund, ikke minutter per respons.

Tallene som betyr noe

Jeg kjørte konsistente benchmarks med denne prompten på tvers av alle konfigurasjoner:

"Skriv en kompakt Python-funksjon som parser en unified diff og returnerer filstiene som er endret. Forklar deretter to edge cases."

Hver test genererte omtrent 128 tokens, noe som ga en rettferdig sammenligning av genereringshastighet.

Baseline-ytelse:

Å kjøre Gemma 4 direkte gjennom llama.cpp med Metal ga oss 58.2 tokens per sekund. Det er brukbart, men ærlig talt? Det føltes tregt under faktiske kodingsøkter der du gjør flere tool-kall og venter på responser.

MTP-forskjellen:

Her blir det interessant. Multi-Token Prediction lar modellen "spekulere" flere tokens fremover, akseptere korrekte prediksjoner og rulle tilbake feil. Med Q8 MTP draft-modellen aktivert, hoppet ytelsen til 72.2 tokens per sekund — en 24% forbedring uten noen endring i hovedmodellen.

Prompt-bearbeidingen forble omtrent den samme (rundt 297-299 tokens/sekund), men genereringshastighet er det som betyr noe for agent-workflows. Du sender ikke nye prompts konstant — du venter på at modellen skal generere responser, ta beslutninger og utføre verktøy.

Jeg testet draft token-tall fra 1 til 6, og på min M1 Max var 3 draft tokens sweet spoten. Verdier over 4 begynte faktisk å bremse ting, noe som gir mening — mer spekulasjon betyr mer bortkastet arbeid når prediksjonene er feil.

llama.cpp vs. MLX: Den overraskende vinneren

Her var det som tok meg på sengen: Jeg forventet at MLX (Apples native ML-framework) ville dominere siden det er spesifikt optimalisert for Apple Silicon. Virkeligheten var annerledes.

| 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 omtrent 58% raskere enn beste MLX-konfigurasjon. Årene med optimaliseringsarbeid som er lagt ned i llama.cpp har tydeligvis båret frukt — det kjører utmerket på macOS til tross for at det er cross-platform.

Legge til synsevne

For en skikkelig kodingsagent-opplevelse vil du kunne sende skjermbilder. Kanskje du vil at agenten skal se hva den har bygget, eller gjennomgå en UI-endring du nettopp gjorde.

Problemet? Bare Gemma 4 12B er nativt multimodal. 26B-modellen vi bruker trenger den eksterne multimodale projektoren lastet sammen med den.

Da jeg la til --mmproj projektoren i llama.cpp, annonserte den multimodal capabilities skikkelig til Pi, og image tool outputs begynte å flyte gjennom korrekt. Enda viktigere: dette introduserte ingen målbar slowdown — genereringshastigheten forble på 72.2 tokens per sekund.

Den virkelige opplevelsen

Med dette oppsettet ser du på omtrent 17GB med modellfiler (16GB for hovedmodellen, pluss MTP-head og projektor). For noen med 64GB unified memory er det helt håndterbart.

Pi som agent gir et rent terminalinterface som kroker inn i OpenAI-kompatibel API som llama.cpp sin server-mode eksponerer. Det betyr at du kan bruke det med hvilket som helst verktøy som støtter OpenAI sin API-format, noe som gir deg fleksibilitet uten vendor lock-in.

Den største fordelen? Når internett feiler — og det vil det, på verste mulige tidspunkt — fortsetter du å kode. Agenten kan være litt tregere enn sky-alternativer, men den er responsiv nok til å opprettholde arbeidsflyten din.

Komme i gang

Du må bygge llama.cpp med Metal-støtte aktivert. Prosjektet har god dokumentasjon for macOS-bygging, og når det er kompilert, gir server-mode deg den OpenAI-kompatible endepunktet.

For modeller er Unsloth GGUF-kvantiseringer på Hugging Face godt optimalisert. Du vil ha Q4_K_XL kvantiseringen for hovedmodellen og matchende Q8 MTP draft-modell.

Tune din --spec-draft-n-max verdi — start på 3 og test fra 1 til 6 for å finne hva som funker best på din spesifikke maskinvare. Ulike Apple Silicon-konfigurasjoner kan ha ulike sweet spots.

Er det verdt det?

Hvis du koder regelmessig med AI-assistenter og har maskinvaren (16GB minimum, 32GB+ anbefalt), absolutt. Uavhengigheten fra internett-tilkobling alene gjør det verdifullt, og med MTP som bringer genereringshastigheter inn i genuint brukbart territorium, er opplevelsen overraskende polert.

Du kommer ikke til å matche GPT-4-klasse intelligens med disse open modellene, men for kodekomplettering, refaktorering, feilsøkingsassistanse og generelle kodingsagentoppgaver? Det er mer kapabelt enn de fleste forventer, og det er ditt — kjører lokalt, privat, uten latency spikes eller service-utfall.

Verktøyene har modnet betydelig. Hvis du har prøvd lokale modeller før og blitt skuffet av hastigheten, gi dette oppsettet en sjanse. MTP endrer ligningen betydelig.