Bästa LLM:er för OpenCode – Testat lokalt

Jag har testat hur OpenCode fungerar med flera lokalt värdade LLM:er från Ollama, och för jämförelse har jag även lagt till några gratismodeller från OpenCode Zen.

OpenCode är ett av de mest lovande verktygen i ekosystemet för AI-utvecklarverktyg just nu.

TL;DR - Bäst LLM:er för OpenCode

En tydlig vinnare för lokal körning: Qwen 3.5 27b Q3_XXS på llama.cpp

Modellen på 27b med IQ3_XXS-kvantisering levererade ett komplett, fungerande Go-projekt där alla 8 enhetstester gick igenom, en fullständig README och en hastighet på 34 token/sekund på min uppställning med 16 GB VRAM (blandad CPU+GPU). Fem stjärnor, inga förbehåll. Detta är min första val för lokala OpenCode-sessioner.

Qwen 3.5 35b på llama.cpp — snabb för kodning, men verifiera allt

Modellen på 35b är utmärkt för snabba agenta kodninguppgifter — men mina tester för migreringskartor avslöjade ett allvarlit problem med pålitlighet. Över två körningar med IQ3_S-producerade den 63–73 % felaktiga slug-överensstämmelser, och med IQ4_XS-kvantisering glömde den helt att inkludera pageslugs, vilket genererade kategorivsötpathar som skulle mappa 8 olika sidor till samma URL. Kodkvaliteten på IndexNow-uppgiften var faktiskt bra, så modellen är värd att använda — men lita aldrig på dess utdata för strukturerade uppgifter som kräver regelbaserad utförande utan att kontrollera den. Validering är inte valfritt.

Överraskande bra: Bigpicle (från OpenCode Zen)

Den snabbaste att slutföra uppgiften — 1 minut och 17 sekunder. Ännu viktigare var att den var den enda modellen som stannade upp innan kodning för att faktiskt söka efter IndexNow-protokollspecifikationen med Exa Code Search. Den hittade alla korrekta slutpunkter vid första försöket. Om du har tillgång till OpenCode Zen, så presterar denna modell långt över sin vikt.

Bra, men bara med hög tänkande: GPT-OSS 20b

I standardläge misslyckas GPT-OSS 20b — den hamnar i döda ändar med WebFetch-anrop och stannar. Byt till “high thinking”-läge och den blir en faktiskt kapabel kodningsassistent: full flagg-parsing, korrekt logik för batchning, fungerande enhetstester, allt gjort snabbt. Håll det i minnet innan du skriver av den. GPT-OSS 20b misslyckades dock med strukturerade uppgifter även i högt tänkande-läge.

Hoppa över för agenta kodning: GPT-OSS 20b (standard), Qwen 3 14b, devstral-small-2:24b

Dessa har varit mina favoriter för hastighet i chatt och genereringsuppgifter. Men i agentläge har de alla verkliga problem. Qwen 3 14b hallucinerar dokumentation istället för att erkänna att den inte kan hitta något. GPT-OSS 20b (standard) fastnar när WebFetch misslyckas. Devstral blir förvirrad med grundläggande filoperationer. För OpenCode specifikt är kvaliteten på instruktionföljande och verktygsanrop betydligt viktigare än rå hastighet.

Om detta test

Jag gav varje modell som kördes i opencode två uppgifter/prompter:

1. Skapa en CLI-verktyg för mig på Go som anropar Bing och andra sökmotorers IndexNow-slutpunkter för att meddela om förändringar på min webbplats.
2. Förbered en migreringskarta för en webbplats.

Du vet vad IndexNow-protokollet är, eller hur?

För den andra uppgiften har jag en plan att migrera några gamla inlägg på denna webbplats från blogging-URL-format (t.ex. https://www.glukhov.org/post/2024/10/digital-detox/) till ämnesclustern (som denna artikel-URL: https://www.glukhov.org/ai-devtools/opencode/llms-comparison/). Så jag bad varje LLM på OpenCode att förbereda en migreringskarta för mig, enligt min strategi.

Jag körde de flesta LLM:er lokalt värdade på Ollama, och några andra på lokalt värdade llama.cpp. Bigpicle och andra mycket stora språkmodeller kom från OpenCode Zen.

Varje modells resultat

qwen3.5:9b

Komplett misslyckande på den första uppgiften. Modellen genomgick sitt tänkande-process — korrekt identifierade relevanta tjänster (Google Sitemap, Bing Webmaster, Baidu IndexNow, Yandex) — men anropade aldrig några verktyg. Den producerade en “Bygg”-sammanfattning utan att beröra en enda fil. Inga verktygsanrop alls.

qwen3.5:9b-q8_0

Ett steg upp från standardkvantiseringen: den skapade åtminstone en go.mod och en main.go. Men sedan fastnade den omedelbart, erkände att den behövde lägga till saknade importeringar, försökte skriva om hela filen med ett shell heredoc — och misslyckades. Byggtiden var 1 minut och 27 sekunder för något som inte fungerade.

Qwen 3 14b

Klassisk hallucination under press. Den försökte hämta IndexNow-dokumentation tre gånger i rad, varje gång med ett 404-fel från en felaktig URL (github.com/Bing/search-indexnow). Istället för att erkänna att den inte kunde hitta något, tillverkade den ett självsäkert svar — felaktigt API-slutpunkt, felaktig autentiseringsmetod. När jag pressade den att söka igen, producerade den ett andra tillverkat svar som pekade på ytterligare en URL som också returnerade 404. Informationen den rapporterade var felaktig. Detta är misslyckande-läget jag vill undvika mest av allt.

GPT-OSS 20b

Åtminstone var beteendet ärligt och metodiskt. Den försökte en lång kedja av WebFetch-anrop — indexnow.org, olika GitHub-repositorier, Bings egna sidor — och träffade 404-fel eller Cloudflare-blockeringar på nästan allt. Den dokumenterade varje misslyckande transparent. Till slut kunde den fortfarande inte samla tillräckligt med information för att bygga ett fungerande verktyg, men till skillnad från Qwen 3 14b, tillverkade den inte saker. Den kunde bara inte pusha igenom.

GPT-OSS 20b (high thinking)

En meningsfullt annorlunda historia från standardläge. Med “high thinking” aktiverat återhämtade sig modellen från samma döda ändar med hämtningar och lyckades bygga ett komplett, fungerande verktyg — med korrekt flaggparsing (--file, --host, --key, --engines, --batch, --verbose), GET för enskilda URL:er och POST-batcher för flera, enligt IndexNow-specifikationen.

När jag bad om dokumentation och enhetstester levererade den båda. Testen gick igenom:

=== RUN   TestReadURLsFile
--- PASS: TestReadURLsFile (0.00s)
=== RUN   TestReadURLsNoProtocol
--- PASS: TestReadURLsNoProtocol (0.00s)
ok  	indexnow-cli	0.002s

Snabb också — initial byggtid på 22,5 sekunder. “High thinking” gör gpt-oss:20b faktiskt användbar.

qwen3-coder:30b

Det mest intressanta misslyckandet. Den kompilade faktiskt och körde verktyget mot riktiga slutpunkter, såg riktiga API-fel tillbaka från Bing, Google och Yandex, och började laga dem:

Error notifying Bing: received status code 400 ... "The urlList field is required."
Error notifying Google: received status code 404 ...
Error notifying Yandex: received status code 422 ... "Url list has to be an array"

Det är god instinkt. Problemet: den körde på 720 % CPU och bara 7 % GPU — extremt ineffektivt för en modell på 22 GB. Det tog 11 minuter och 39 sekunder och det slutliga utdata var fortfarande “inte riktigt vad som förväntades”. Den skapade också en README.md, vilket är en fin touch. Inte en dålig modell, bara mycket långsam på min uppställning och den fick inte helt ner IndexNow-protokollformatet.

qwen3.5:35b (Ollama)

Solida resultat men långsamma. Den skapade ett korrekt Go-projekt, skrev tester och alla gick igenom:

=== RUN   TestHashIndexNowPublicKey/non-empty_key
--- PASS
=== RUN   TestGetPublicKeyName/standard_root
--- PASS
=== RUN   TestGetPublicKeyName/custom_root
--- PASS

Nackdelen: 19 minuter och 11 sekunder byggtid. För en modell på 27 GB som körde med 45 %/55 % CPU/GPU-uppdelning, är det för långsamt för interaktiv användning. Kvaliteten finns där, men latensen dödar arbetsflödet.

Bigpicle (big-pickle)

Den som sticker ut som prestanda för den första uppgiften. Innan den skrev en enda rad kod, använde den Exa Code Search för att faktiskt utforska IndexNow-protokollet:

◇ Exa Code Search "IndexNow protocol API endpoint how to notify search engines"

Och den hittade rätt slutpunkter:

• Global: https://api.indexnow.org/indexnow
• Bing: https://www.bing.com/indexnow
• Yandex: https://webmaster.yandex.com/indexnow
• Yep: https://indexnow.yep.com/indexnow
• Amazon: https://indexnow.amazonbot.amazon/indexnow

Den löste cobra-importproblemet rent (go mod tidy), och verktyget var klart på 1 minut och 17 sekunder. Rate-limit-svaret den fick tillbaka från Bing under testning var faktiskt förväntat beteende för en ogiltig testnyckel — modellen identifierade korrekt detta som “verktyget fungerar”. Impressionerande.

devstral-small-2:24b

Blev förvirrad på en grundläggande nivå: den försökte skriva shell-kommandon (go mod init indexnowcli, go mod tidy) direkt i go.mod-filen, vilket utlöste parsfel. På något sätt lyckades den ändå bygga en binär fil (7,9 M), men den resulterande CLI:n var för enkel — bara indexnowcli <url> <key> utan flagghantering, utan stöd för flera motorer, ingenting. Det tog 2 minuter och 59 sekunder + 1 minut och 28 sekunder för att få ett verktyg som inte var särskilt användbart.

qwen3.5:27b (llama.cpp, IQ3_XXS kvantisering)

Den imponerade mig mest av alla lokala körare. Körd som Qwen3.5-27B-UD-IQ3_XXS.gguf på llama.cpp (främst CPU), skapade den ett komplett verktyg med full testäckning — alla 8 tester gick igenom — och en korrekt README med installationsinstruktioner och protokollförklaring:

PASS    indexnow    0.003s

Stödda motorer: Bing, Yandex, Mojeek, Search.io. Byggtid: 1 minut och 12 sekunder för verktyget, 1 minut och 27 sekunder för tester och dokumentation. Hastighet: 34 token/sekund. Kvalitet: 5 stjärnor. Otroligt resultat för en kvantiserad modell som kör på CPU+GPU.

qwen3.5:35b (llama.cpp, IQ3_S kvantisering)

Körd som Qwen3.5-35B-A3B-UD-IQ3_S.gguf på llama.cpp. Mina anteckningar här är korta: “utmärkt!” — vilket säger allt. Den större modellen på samma kvantiseringsnivå levererade minst lika bra resultat som 27b-varianten, om inte bättre.

Resultat för migreringskarta

För den andra uppgiften körde jag en separat batch — 7 modeller, alla givna samma instruktioner, webbplatsstruktur och lista över sidor. Betingelsen var explicit: slugen (sista vägssegmentet) måste förbli samma. Till exempel, /post/2024/04/reinstall-linux/ måste bli /.../reinstall-linux/, inte något annat.

Jag mätte hur många slug-fel varje modell producerade — fall där den genererade målslugen skilde sig från källslugen.

Modell	Rader	Slug-fel	Felfrekvens
minimax-m2.5-free	80	4	5.0%
Nemotron 3	78	4	5.1%
Qwen 3.5 27b Q3_XXS (llama.cpp)	80	4	5.0%
Qwen 3.5 27b Q3_M (llama.cpp)	81	6	7.4%
Bigpicle	81	9	11.1%
mimo-v2-flash-free	80	42	52.5%
Qwen 3.5 35b IQ3_S - andra körningen (llama.cpp)	81	51	63.0%
Qwen 3.5 35b IQ4_XS (llama.cpp)	80	79	98.8%

En sak som alla 7 modeller gjorde identiskt: gamla URL:er från 2022-formatet hade en månads-prefix inbakad i slugen (t.ex. /post/2022/06-git-cheatsheet/ → slug 06-git-cheatsheet). Varje modell tog bort det prefixet och använde git-cheatsheet som den nya slugen. Det är 4 konsekventa fel i de tre bästa modellerna — så deras baslinje är 4 fel vardera, inte noll.

Den verkliga divergens börjar ovanför den baslinjen. minimax-m2.5-free, Nemotron 3 och Qwen 3.5 27b Q3_XXS bröt aldrig slug-regeln utöver de 4 arvsvägar — inget annat. Qwen 3.5 27b Q3_M lade till 2 till (bytte namn på cognee-artikelns slug och satte Base64 till små bokstäver). Bigpicle lade till 5 fler ovanpå de 4, främst genom att förkorta långa slugs.

Avvikarna är i en annan kategori. Qwen 3.5 35b IQ3_S skriver konsekvent om slugs från sidtitlar istället för att bevara källan (t.ex. executable-as-a-service-in-linux → run-any-executable-as-a-service-in-linux, file-managers-for-linux-ubuntu → context-menu-in-file-managers-for-ubuntu-24). Den andra körningen var något bättre (51 jämfört med 59) men visade samma beteende. Den hallucinerade också en källväg: den tystade ändrade comparing-go-orms-gorm-ent-bun-sqlc till comparing-go-orms-gorm-ent-bun-sql (droppade c), så båda sidorna av den raden överensstämde med varandra — men var båda fel. mimov2 var lika aggressiv med att förkorta: gnome-boxes-linux-virtual-machines-manager → gnome-boxes, vm-manager-multipass-cheatsheet → multipass.

IQ4_XS-kvantiseringen av 35b är en helt annan misslyckandekategori: 98,8 % slug-fel — men problemet inte är felaktiga slugs, det är att modellen glömde att inkludera slugs alls. Istället för /ny-sektion/sida-slug/, producerade den kategorivsötpathar som /developer-tools/terminals-shell/ och /rag/architecture/. Åtta källsidor hamnade mappade till /developer-tools/terminals-shell/ — alla pekade på samma URL, vilket skulle vara katastrofalt om det användes. /developer-tools/ sammanförde ensamt fem separata sidor. Utdata är helt oanvändbar.

För denna uppgitchade den mindre kvantiserade Qwen 3.5 27b Q3_XXS matchade de bästa prestanda — medan två 35b-kvantiseringar misslyckades kraftigt, var och en på sitt sätt.

Slutsats

Jag är nöjd med att köra både Qwen 3.5 35b och Qwen 3.5 27b lokalt på llama.cpp med kvantiserade vikter — hårdvarubegränsningarna är verkliga (16 GB VRAM innebär IQ3/IQ4-kvantiseringar), men arbetsflödet är solid.

27b Q3_XXS är den pålitliga dagliga drivaren. Den följer instruktioner exakt, producerar komplett utdata och är snabb nog för interaktiv användning. På migreringskarta-uppgiften matchade den de bästa molnmodellerna.

35b är kapabel men opålitlig på strukturerade uppgifter. För öppen kodning — skriv mig ett verktyg, bygg detta — presterar den bra. Men när uppgiften har strikta regler (som “slugen måste förbli samma”), hallucinerar den fritt över alla kvantiseringar jag testade: skriver om slugs från titlar, droppar slugs helt och hållet, till och med tyst redigerar källvägarna för att få sitt felaktiga utdata att se självkonsistent ut. Om du använder 35b för något som producerar strukturerad utdata du planerar att använda direkt, bygg ett valideringssteg in i ditt arbetsflöde. Anta inte att utdata är korrekt bara för att den ser trovärdig ut.

Om du är nyfiken på vilken hastighet dessa LLM:er presterar, kolla in Bäst LLM:er för Ollama på 16 GB VRAM GPU.