60 dager er ikke lenge
Bedriften deres har bygget en arbeidsflyt rundt Claude eller GPT. Kanskje er det en kundeservicebot, en intern kunnskapsassistent, eller et automatisert saksbehandlingsløp. Så en dag kommer varselet: modellen dere har bygget på, pensjoneres.
Anthropic garanterer minst 60 dagers varsel før en offentlig tilgjengelig modell tas ut av drift. Det er en reell forpliktelse, ikke bare en floskel — og til sammenligning er den strengere enn mange forventer. OpenAI gir minst seks måneder for sine ordinære modeller, men for forhåndsversjoner (alt med "preview" i navnet) kan varselet være så kort som to uker.
To uker er ikke nok tid til å teste, validere og rulle ut en erstatning for noe som kjører i produksjon. Selv 60 dager er stramt hvis dere ikke har forberedt noe på forhånd.
Dette er ikke et argument for å forlate Claude eller GPT. Det er et argument for å ikke bygge alt på én skjør tråd.
Problemet er ikke leverandøren — det er fraværet av en plan B
De store leverandørene er der de er av gode grunner: kvalitet, sikkerhet, support, og et økosystem som fungerer. Det er ikke noe galt med å bygge kjernen av virksomheten deres på Claude eller GPT.
Problemet oppstår når hele arbeidsflyten er hardkodet mot én modell, ett API, én leverandør — uten noen vei ut hvis noe endrer seg. Modeller pensjoneres. API-er endres. Priser justeres. Tjenester går ned. Ingen av disse hendelsene bør kunne stanse virksomheten deres helt.
Løsningen har tre lag, og de bygges i økende grad av alvorlighet — de færreste bedrifter trenger å bygge alle tre på dag én.
Lag 1: Et gateway-lag mellom applikasjonen og leverandøren
Det enkleste laget er å legge et tynt lag mellom applikasjonskoden deres og selve AI-leverandøren, slik at et bytte av modell ikke krever et bytte av kode.
To verktøy dominerer dette rommet: LiteLLM og Portkey. Begge er åpen kildekode og lar dere definere en primærmodell med en liste av reserver — hvis primærmodellen feiler eller blir rate-limitet, ruter systemet automatisk til neste i køen, uten at applikasjonen merker forskjell.
Vær ærlige med dere selv om hva dette faktisk krever. LiteLLM som selvhostet proxy trenger egen database og gjerne Redis i tillegg, og realistisk oppsett tar gjerne 2–4 uker for et team som ikke har gjort det før — pluss løpende drift og oppdateringer etterpå. Portkey har en mer produksjonsmoden feilhåndtering med innebygde sikringsmekanismer, men den fulle funksjonaliteten ligger i en betalt, hostet tjeneste.
Verdt å nevne: Portkey er i skrivende stund i ferd med å bli kjøpt opp av Palo Alto Networks. Det er en fin påminnelse om at heller ikke verktøyene dere velger for å unngå avhengighet, er immune mot konsolidering. Bygg med åpne øyne, ikke med en falsk følelse av at ett valg er permanent trygt.
For de fleste norske SMB-er er konklusjonen enkel: et selvhostet gateway-lag er noe dere bygger når dere har dedikert kapasitet til å drifte det — ikke noe dere setter opp en fredag ettermiddag.
Lag 2: Det innebygde alternativet, hvis dere allerede er på Azure
Hvis bedriften allerede kjører Microsoft 365 og Azure — noe de fleste av kundene våre gjør — finnes det et enklere sted å starte. Model Router i Azure AI Foundry ruter automatisk mellom over 25 modeller fra ulike leverandører, med feilhåndtering påslått som standard for standardoppsettet.
To presiseringer som er verdt å kjenne til før dere setter det opp: For egendefinerte utvalg av modeller må dere velge minst to modeller for at automatisk feilhåndtering skal fungere — velger dere kun én, er redundansen borte. Og skal Claude være en del av utvalget, må den settes opp som en egen distribusjon i Foundry først — den er ikke automatisk inkludert.
Dette er, for de fleste bedrifter i vår målgruppe, det mest realistiske første steget. Det krever ikke ny infrastruktur, bare riktig konfigurasjon av noe dere allerede betaler for.
Lag 3: Åpen kildekode som siste skanse
Det tredje laget er en åpen modell dere kan kjøre selv — ikke som daglig driver, men som nødløsning for to konkrete scenarioer: leverandøren gjør noe dere ikke aksepterer (vilkårsendring, priseksplosjon, en policy som ikke lenger passer virksomheten), eller data av juridiske grunner må bli i EU og ikke kan sendes til en amerikansk sky.
Kvalitetsgapet er ikke borte — det har flyttet seg
Det var lenge en vanlig påstand at åpne modeller hadde tatt igjen de lukkede på ren kunnskap. Det stemmer, men er samtidig litt misvisende: MMLU-testen som ofte brukes til å måle dette, regnes nå som "mettet" — de fleste ledende modeller, åpne som lukkede, scorer 88–94 prosent. Testen skiller ikke lenger godt mellom dem. På vanskeligere kunnskapstester som GPQA Diamond består det fortsatt et gap på rundt sju prosentpoeng til fordel for de lukkede modellene.
Der gapet er reelt og fortsatt betydelig, er på agentiske oppgaver og produksjonskoding — nøyaktig de tingene norske SMB-er faktisk vil bruke AI til i praksis. På SWE-bench, en av de mest brukte målestokkene for AI som løser ekte kodeoppgaver, ligger de beste lukkede modellene rundt 12 prosentpoeng foran de beste åpne. Og dette gapet er, ifølge Stanfords AI Index-rapport, i ferd med å øke igjen etter en periode hvor det så ut til å krympe. Opus- og GPT-5-klassen leder fortsatt tydelig her.
Konklusjonen: bruk gjerne en åpen modell som nødløsning eller for oppgaver med lavere krav til presisjon. Ikke forvent at den matcher Claude eller GPT på komplekse, flertrinns oppgaver som krever ekte resonnering.
Kostnad: ikke automatisk billigere
Den vanligste misforståelsen er at selvhosting er billigere fordi dere "eier" modellen. Det er sant først ved høyt og jevnt volum — og break-even-punktet varierer mye mer enn folk tror, avhengig av hvilken API dere sammenligner mot og hvilken GPU-leverandør dere bruker. Som en grov tommelfingerregel trenger dere gjerne et sted mellom 2 og 30 millioner tokens per dag i jevnt trafikkvolum før selvhosting begynner å lønne seg mot en dyr API — og mot en billig åpen API kan tallet bli langt høyere.
I tillegg kommer driftskostnaden dere ikke ser på fakturaen: en fungerende selvhostet stack krever løpende overvåking, oppgraderinger og feilsøking. Vårt anslag, basert på hva vi ser hos kunder som har forsøkt dette selv, er et sted mellom 20 og 30 prosent av en ingeniørs arbeidstid — men dette er en indikasjon, ikke en fasit. Det finnes ingen god snarvei her.
For de aller fleste norske SMB-er med moderat, variabelt volum er konklusjonen enkel: selvhosting lønner seg ikke på ren kostnad. Det gjøres for kontroll, ikke for å spare penger.
Hvis dere likevel skal drifte selv
Motoren de fleste velger er vLLM eller TensorRT-LLM — begge er modne, produksjonsklare inferens-motorer. SGLang har også dukket opp som et reelt tredje alternativ, spesielt for arbeidslaster med mye repeterende kontekst, som agentiske oppgaver og RAG.
For skalering orkestreres dette gjerne i Kubernetes, men for en enkelt GPU-node holder det ofte med en ren Docker-container og vLLM. Ikke bygg mer infrastruktur enn oppgaven faktisk krever.
Hvis dere ikke vil drifte GPU-er selv, finnes det managed inference-leverandører som Together AI og Fireworks AI, i tillegg til at Azure og AWS tilbyr hosting av åpne modeller direkte. Prisen der ligger typisk godt under Claude eller GPT sin API-pris, men over ren selvhosting ved høyt volum — et fornuftig mellomsteg for de fleste.
De beste åpne modellene akkurat nå
Landskapet endrer seg fort, men per i dag: Kimi K2.7 Code fra Moonshot AI (modifisert MIT-lisens) er sterk på koding og agent-oppgaver. DeepSeek V4 (MIT-lisens) er fortsatt et solid valg på resonnering og matematikk. Qwen 3.5 fra Alibaba (Apache 2.0) regnes som den beste allround-modellen — vær obs på at nyere Qwen-versjoner delvis har gått bort fra full åpen lisens. GLM-5.2 fra Zhipu tilbyr én million tokens kontekst og er sterk på agentiske oppgaver. Llama 4 Scout fra Meta har fortsatt 10 millioner tokens kontekst og bred plattformstøtte, selv om Meta ikke har lansert noen etterfølger ennå. Mistral er fortsatt det naturlige valget for dere som trenger en europeisk forankret leverandør. Gemma 4 fra Google er best egnet for lokal eller kantnær bruk med begrensede ressurser.
Orkestrator-mønsteret: la den dyre modellen tenke, la de billige modellene jobbe
Et mønster som får stadig mer oppmerksomhet er å la en dyr, kraftig modell — Opus eller GPT-5-klassen — planlegge og kvalitetssikre arbeidet, mens billigere eller åpne modeller som Qwen eller DeepSeek gjør selve grovarbeidet.
Her sirkulerer det tall om 5–10 gangers kostnadsreduksjon. Det tallet gjenspeiler den rene prisforskjellen mellom en frontier-modell og en liten modell, ikke det dere faktisk sitter igjen med etter at systemet er bygget og satt i drift. De mest solide, målte tallene vi fant — fra forskningsprosjektet RouteLLM og fra Anyscale — viser en reell kostnadsreduksjon på 70–85 prosent, altså grovt sett 3–7 ganger, mens kvaliteten holdes på rundt 95 prosent av hva den dyre modellen alene ville gitt. Fortsatt betydelig, men ikke like dramatisk som 5–10x antyder.
Mønsteret har også reelle svakheter en balansert vurdering bør nevne: feil fra en billig modell kan forplante seg videre i kjeden, feilrutet arbeid til en modell som ikke er god nok kan gi kvalitetstap som er vanskelig å oppdage, og selve kompleksiteten i å feilsøke på tvers av flere modeller er ikke gratis. Skal dette gjøres seriøst, trenger dere en evalueringsprosess som fanger opp kvalitetsfall før det når kunden — ikke bare et kostnadsregnskap.
Hva vi faktisk anbefaler
Ikke bygg alle tre lagene på én gang. De fleste norske SMB-er bør starte slik:
- Sjekk om dere allerede har Azure Model Router tilgjengelig. Hvis dere er på Microsoft 365 og Azure, er dette det billigste og raskeste redundans-laget dere kan sette opp — konfigurasjon, ikke ny infrastruktur.
- Bygg et gateway-lag først når dere har volumet og kapasiteten til å drifte det, ikke fordi det høres smart ut.
- Behold en åpen modell i bakhånd som nødløsning, ikke som daglig driver — og vit at den ikke matcher Claude eller GPT på komplekse oppgaver ennå.
Det dette handler om, i bunn og grunn, er ikke teknologivalg. Det er struktur — å vite hvilke avhengigheter dere har, hva som skjer hvis en av dem svikter, og hvem som bestemmer hva dere gjør da. Det er akkurat den typen kartlegging vi gjør i en AI Ready-vurdering, sammen med resten av governance-arbeidet rundt en AI-implementasjon.
AI starter ikke med teknologi. Den starter med struktur.