Hvorfor jeg skiftede til lokalt AI: En personlig oplevelse

De fleste udviklere kender scenariet. Du er midt i en produktiv arbejdssession, tankerne flyder, og så无可 — internetforbindelsen dør. Din cloud-baserede AI-assistent bliver ubrugelig, og du står tilbage med uafsluttede funktioner og halve rettelser.

Sådan en oplevelse fik mig til at undersøge muligheden for at køre en fuldt funktionel AI-kodningsagent lokalt. Resultatet overraskede mig: Med den rette konfiguration kan du opnå bemærkelsesværdig god ydelse på Apple Silicon — ofte bedre end dedikerede Mac-optimerede løsninger.

Konfigurationen der virker

Efter grundig test og benchmarking landede jeg på denne opsætning til min M1 Max med 64GB unified memory:

Basiskomponenter:

• llama.cpp bygget med Metal-acceleration
• Gemma 4 26B-A4B i GGUF-format (kvantiseret til Q4)
• Multi-Token Prediction (MTP) draft model til spekulativ dekodning
• Gemma 4 multimodal projektor til screenshot-understøttelse
• Pi som terminal-baseret kodningsagent

Dette er ikke den absolut kraftigste konfiguration, du kan bygge. Men det er sweet spot for praktisk brug. Hastighed handler om tokens per sekund, ikke minutter per svar.

De tal der betyder noget

Jeg kørte konsistente benchmarks med denne prompt på tværs af alle konfigurationer:

"Skriv en kompakt Python-funktion der parser en unified diff og returnerer de ændrede filstier. Forklar derefter to edge cases."

Hver test genererede cirka 128 tokens, hvilket giver et fair sammenligningsgrundlag for genereringshastigheden.

Baseline resultater:

Gemma 4 kørt direkte gennem llama.cpp med Metal gav 58,2 tokens per sekund. Det er anvendeligt, men ærligt talt? Det føltes trægt i praksis, hvor du skifter mellem flere tool calls og venter på svar.

Multi-Token Prediction forandrer spillet:

Her bliver det interessant. MTP lader modellen "spekulere" flere tokens fremad, acceptere korrekte prediction og rulle forkerte tilbage. Med Q8 MTP draft modellen aktiveret, sprang ydelsen til 72,2 tokens per sekund — en 24% forbedring uden ændringer til hovedmodellen.

Prompt-behandlingen forblev næsten uændret (cirka 297-299 tokens/sekund), men genereringshastigheden er det, der tæller i agent-workflows. Du sender ikke konstant nye prompts — du venter på at modellen genererer svar, træffer beslutninger og eksekverer tools.

Jeg testede draft token counts fra 1 til 6, og på min M1 Max ramte 3 draft tokens det optimale punkt. Værdier over 4 begyndte faktisk at sænke hastigheden, hvilket giver mening — mere spekulation betyder mere spildt arbejde, når predictions er forkerte.

llama.cpp vs. MLX: Den overraskende vinder:

Her blev jeg taget på sengen. Jeg forventede at MLX ( Apples native ML-framework) ville dominere, da det er specifikt optimeret til Apple Silicon. Virkeligheden var en anden.

| 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 cirka 58% hurtigere end den bedste MLX-konfiguration. Årenes optimeringsarbejde i llama.cpp har tydeligvis båret frugt — det kører fremragende på macOS på trods af at være cross-platform.

Vision-evner tilføjet**

For en ordentlig kodningsagent-oplevelse vil du have mulighed for at sende screenshots. Måske vil du have agenten til at se, hvad den har bygget, eller gennemgå en UI-ændring du lige har lavet.

Ulempen? Kun Gemma 4 12B er nativt multimodal. Den 26B model vi bruger, kræver en ekstern multimodal projektor lastet sammen med den.

Da jeg tilføjede --mmproj projektoren til llama.cpp, advertised den korrekt multimodale evner til Pi, og image tool outputs begyndte at flyde igennem. Endnu vigtigere: Dette introducerede ingen målbar slowdown — genereringshastigheden forblev på 72,2 tokens per sekund.

Den virkelige oplevelse

Med denne opsætning bruger du cirka 17GB model-filer (16GB til hovedmodellen, plus MTP-head og projektor). For en med 64GB unified memory er det helt håndterbart.

Pi som agent giver et rent terminal-interface, der kobles til den OpenAI-kompatible API, som llama.cpp's server mode eksponerer. Det betyder, at du kan bruge det med ethvert værktøj der understøtter OpenAI's API-format — fleksibilitet uden vendor lock-in.

Den største fordel? Når din internetforbindelse fejler — og det vil den, på det værst mulige tidspunkt — holder du bare koden. Agenten er måske en smule langsommere end cloud-alternativer, men den er responsiv nok til at holde din workflow intakt.

Sådan kommer du i gang

Du skal bygge llama.cpp med Metal-support aktiveret. Projektet har solid dokumentation til macOS builds, og når det er kompileret, giver server mode dig det OpenAI-kompatible endpoint.

For modeller er Unsloth GGUF kvantiseringer på Hugging Face veloptimerede. Du vil have Q4_K_XL kvantiseringen til hovedmodellen og den matchende Q8 MTP draft model.

Justér din --spec-draft-n-max værdi — start på 3 og test fra 1 til 6 for at finde det optimale på din specifikke hardware. Forskellige Apple Silicon-konfigurationer kan have forskellige sweet spots.

Er det værd at prøve?**

Hvis du koder regelmæssigt med AI-assistenter og har hardwaren (16GB minimum, 32GB+ anbefalet), absolut. Uafhængigheden fra internetforbindelse alene gør det værdifuldt, og med MTP der bringer genereringshastigheder ind i reelt anvendeligt territorium, er oplevelsen overraskende poleret.

Du kommer ikke til at matche GPT-4 klasse intelligens med disse open models, men til kode-frem Completering, refaktorering, fejlfinding og generelle kodningsagent-opgaver? Det er mere kapabelt end de fleste forventer, og det er dit — kører lokalt, privat, uden latency spikes eller service-udfald.

Værktøjerne er modnet betydeligt. Hvis du har prøvet lokale modeller før og var skuffet over hastigheden, så giv denne konfiguration et skud. MTP ændrer ligningen markant.