Qwen 2.5 Coder 32B scorede 92,9 på HumanEval. GPT‑4o lå på 90,2. Det fik et 10-personers team til at køre seks måneders paralleltest mellem deres hidtidige ChatGPT-workflow i skyen og en lokal AI-server. Konklusionen var nøgtern: lokale modeller var ikke “bedre” i absolut forstand, men de var gode nok – og billigere – til langt størstedelen af arbejdet.
Det her er ikke en slagsang for open source, men et regnestykke om kvalitet, pris og drift baseret på målte data.
Hvorfor et benchmark-tal udløste en audit
HumanEval, et udbredt kode-benchmark med 164 problemer på tværs af sprog og problemtyper, placerede Qwen 2.5 Coder 32B foran GPT‑4o. Når en åben model kan matche eller overgå en betalt løsning, kalder det på et realitetstjek. HumanEval er ikke perfekt, men den er konsistent og nyttig til sammenligning på kodegenerering – dér hvor mange teams henter mest værdi.
Pointen var ikke bare scorene, men hvad der sker, når de oversættes til hverdagsopgaver: fejlrettelser, tests, små scripts, SQL og almindelig vedligehold. Benchmarken blev ikke taget som sandhed, men som anledning til en audit.
Seks måneder med to spor
Teamet kørte to miljøer side om side i et halvt år. De loggede output mod reelle opgaver, målte omkostninger, latency og dokumenterede fejl. Før de byggede noget, kortlagde de deres ugentlige opgavefordeling: cirka 45 procent skrivning (mails, dokumentation, referater), 30 procent kodearbejde, 15 procent analyse, 10 procent edge-opgaver med behov for realtidsviden eller usædvanlig dybde.
Metoden var enkel: mål kvalitet mod krav, tid og penge – og noter brudpunkter. Der mangler stadig fuld gennemsigtighed i, hvordan blind A\/B og rubricering var sat op, og hvor mange bedømmere der var med; rammen var dog konsistent hen over seks måneder.
Hardwarevalget der satte grænsen
Opsætningen brugte en brugt RTX 3090 med 24 GB VRAM til omkring 600 dollar. Samlet infrastruktur – inklusiv en genbrugt workstation og 2 TB NVMe – landede omkring 1.200 dollar. 24 GB viste sig praktisk vigtig: under 24 GB kører man komfortabelt 14B-modeller; ved 24 GB åbner døren til 32B-klassen med Q4-quantisering. Det er ikke bare et nørdpunkt – det afgør, om visse kodeopgaver kan løftes uden at ramme muren.
Teamet testede flere åbne modeller mod deres opgaver og endte i en todelt stack: en 14B til det meste og Qwen 2.5 Coder 32B til kode, når det var nødvendigt. Ikke spektakulært. Men stabilt.
Hvad kvaliteten faktisk blev
På skrivning – ofte antaget som en svaghed for lokale modeller – var forskellen ofte ikke til at skelne. I blindtests kunne teamet ikke pålideligt adskille en lokal 14B fra GPT‑4o på e-mails, dokumentation og korte sammenfatninger. På kode holdt benchmark-signalet: Qwen 2.5 Coder 32B leverede idiomatisk output og korrekte funktionssignaturer i Python, TypeScript, Go, Rust og SQL.
Hvor faldt den lokale løsning igennem? På flertrinsopgaver, opgaver med realtidskrav og i kanten af modellens færdigheder. De cirka 10 procent edge-opgaver trak stadig mod skyen – ikke altid, men ofte nok til at gøre et hybridvalg rationelt.
Regnestykket der fik det til at give mening
Cloud-abonnementet stod på 30 dollar per bruger per måned. For et 10-personers team er det 300 dollar om måneden, 1.200 dollar på fire måneder. Det matcher break-even mod den beskrevne hardware-TCO. Det er et groft skøn – TCO bør også indeholde el, køling, vedligehold, sikkerhed og driftstid – men som første pejlemærke er det brugbart og var nok til at sætte en lokal server i spil uden lang binding.
Den praktiske pointe: når 90 procent af opgaverne ikke kræver frontier-kvalitet, betaler man i praksis premium for de sidste 10 procent. Det er ofte et bevidst valg, men beslutningen bør træffes med tal på bordet.
Konkrete driftsændringer
Gevinsten var ikke kun pris. Lokalt gav lavere og mere stabil latency på korte prompts, mindre jitter i travle perioder og et auditspor under egen kontrol. Bagsiden er driften: man skal have deployment-flow, overvågning af throughput og P99-latency, backup\/restore af modelartefakter samt en plan for opdateringer og patching. Og nogen skal reagere, hvis GPUen fejler.
Support og MLOps ændrer sig. I skyen får man stille opdateringer og lejlighedsvise regressioner. Lokalt har man ansvaret for modelstaleness, tokenizer-ændringer og kompatibilitet ved opgraderinger. Det kan holdes nede med en enkel release-kadence og rulleplaner.
Hybrid giver mening i hverdagen
Efter seks måneder landede arbejdsfordelingen som en tommelfingerregel: fortrolige og regulerede data behandles lokalt; lavhængende produktivitetsopgaver som skrivning, kort analyse og standard-kode kører også lokalt; frontier-behov – store kædeopgaver, meget lang kontekst, realtidsviden – bliver i skyen. Det er ikke ideelt at skifte, men med en router-service og simple regler fungerer det glat.
Vigtigt: spær modellen inde per datakategori. Dataseparation og logging skal være klart konfigureret, før noget flyttes i produktion. Ellers forsvinder pointen ved lokalt setup.
Hvorfor VRAM og KV-cache styrer meget af oplevelsen
Lokale modeller begrænses ikke kun af vægtstørrelse. Under inferens vokser KV-cachen med kontekstlængde og samtidighed. Den fylder i hukommelsen og gør decode-trinnet bundet til hukommelsesbåndbredde frem for ren regnekraft. Derfor kan lange samtaler og store dokumenter øge latency markant på lokale GPU’er, selv når modellen passer i VRAM.
Ny forskning eksperimenterer med kvantisering, token-eviction og deling af repræsentationer i cachen for at reducere forbruget uden væsentligt kvalitetstab. Det praktiske råd: planlæg for både vægte og cache, ellers rammer samtidighed og svartider muren.
Governance og compliance skal være på plads
Før migrering bør beslutningstagere definere mål for latency, throughput, TCO og logningskrav. Adskil data pr. miljø og beskriv adgangsmodeller. Beslut hvad der må logges til fejlanalyse, og hvordan følsomme felter pseudonymiseres. Hav en enkel incident-proces, så fejl ikke ender som ustrukturerede Slack-tråde.
Dokumentér også versionsstyring af modeller og tokenizer, samt hvornår en opdatering kræver revalidering af benchmarks i jeres brugsmønster. Få linjer i en driftsrunbook sparer timer ved næste regression.
Hvad en tre til seks måneders pilot bør måle
Kør en fokuseret pilot med en opgavesample, der matcher jeres fordeling. Lav blind A\/B af outputs med rubricerede kriterier for kvalitet og sikkerhed. Track cost per 1.000 tokens, wall-clock latency og P99 over døgnet. Log hændelser: timeouts, hallucinationer, sikkerhedsbrud og fejl i tool-use. Skift modelversion på faste uger, så forbedringer eller regressioner kan spores.
Afslut med en simpel cost-curve: månedlig cloud-udgift mod engangsinvestering med en skygge for drift. Når kurverne krydser efter et realistisk overhead, har I et tal – ikke en mavefornemmelse.
Indvendingerne og hvad dataene svarer
Cloud leverer hurtigere modelopdateringer, bedre SLA og elastisk skalering. En lokal server kan ikke matche det på spidsbelastning. Auditen viste dog, at for et stabilt workload hos et 10-personers team var skaleringen underordnet, og kvaliteten på 90 procent af opgaverne var tilstrækkelig lokalt. På frontier-opgaver holdt cloud sin plads.
En anden indvending er totalomkostningerne. Skjulte poster – el, køling, drift og sikkerhed – kan vælte regnestykket. Det kan de. Auditen angiver et enkelt fire-måneders break-even, men ikke en fuld TCO med alle poster. Det bør kvalificeres, før man binder sig. Det er legitimt at lande på, at cloud stadig er bedst, hvis governance- og sikkerhedskrav spiser besparelsen.
Hvad litteraturen og benchmarks peger på
HumanEval-scorerne fremgår af kilden bag auditen: Qwen 2.5 Coder 32B med 92,9 og GPT‑4o med 90,2. Forskellen var en god indikator for, at en 32B-kodemodel lokalt kunne levere konkurrencedygtigt output til praktiske kodeopgaver. Ret testen mod egen pipeline for at bekræfte det.
KV-cache-udfordringen er veldokumenteret: ved lange kontekster kan cachen overstige modelvægten og gøre decoding hukommelsesbåndbredde-begrænset. Derfor giver teknikker som cache-kvantisering og eviction mening i lokal drift, især hvis man jagter lav latency og samtidighed.
Hvad betyder det for beslutningstagere
Hvis jeres opgavefordeling ligner casen – cirka halvdelen skrivning, en tredjedel kode, resten analyse og edge – er sandsynligheden høj for, at en 14B-lokalmodel dækker det meste, mens en 32B-kodemodel tager de svære sager. Med en hardwareudgift omkring 1.200 dollar når man break-even mod 30 dollar per bruger per måned omkring måned fire for et 10-personers hold, forudsat beskedne driftsomkostninger og accept af “godt nok” på 90 procent af opgaverne.
Omvendt: hvis edge-andelen er større, lang kontekst er normen, eller compliance kræver tunge kontroller og revisionsspor, er skyen eller en ren hybrid ofte bedre. Det er en prioritering – ikke et nederlag.
Hvad der stadig mangler at blive dokumenteret
Auditen er én case med ét team. Der mangler reproduktion på tværs af brancher og opgavetyper. Det er uklart, hvordan blindvurdering præcist blev gennemført, og hvor stringent rubriceringen var. Omkostningsmodellen mangler fuld TCO med el, køling og personale. Der er heller ikke detaljer om opdateringsfrekvens lokalt kontra sky – en nøglefaktor for sikkerhed og modelhygiejne.
Kort sagt: historien er stærk som beslutningsramme, men ikke en garanti. Gentag testen i eget miljø i mindst tre måneder, helst seks, og hold jer til tallene – også når de ikke peger i den retning, man håbede.
Konklusion
Dataene peger mod en nøgtern anbefaling. Lokale modeller betaler sig, når arbejdsbyrden domineres af skrivning, standard-kode og let analyse, når kvalitetskravet er stabilt, og når de svære 10 procent fortsat kan ligge i skyen. De betaler sig ikke, hvis man har kontinuerlige frontier-behov, meget lang kontekst og stramme SLA-krav. Hybrid er ofte det pragmatiske kompromis.
Sidste ord: Mål, før I mener. Tal er nemmere at blive enige om end holdninger.
