Selvhostet kontra hostet inferens: vLLM, TGI og break-even-regnestykket

Argumentet er overbevisende. Open source-modeller er konkurrencedygtige. GPU’er er tilgængelige. Inferensservere som vLLM, TGI og SGLang er modne. Hvorfor betale et tillæg på 5-10x til OpenAI eller Anthropic, når I selv kan hoste noget tilsvarende?

Virkeligheden er mere kompleks. Selvhosting vinder reelt ved bestemte skalaer. Ved andre skalaer overskygger driftsomkostningen besparelsen på inferens. Break-even-punktet afhænger af arbejdsbelastning, modelstørrelse, krav til latenstid og teamets kompetencer.

Denne artikel går i dybden med regnestykket, de driftsmæssige realiteter og de mønstre, der adskiller teams, som bør selvhoste, fra dem, der ikke bør. Vi antager, at I overvejer det seriøst og ønsker ærlige tal.

Hvornår selvhosting giver mening

Nogle egenskaber taler for selvhosting:

Skala. Stor inferensmængde. Mere konkret er et månedligt API-forbrug på over €5K-10K typisk grund nok til at overveje selvhosting.

Forudsigelig arbejdsbelastning. Stabilt og forudsigeligt forbrug. Selvhosting kræver kapacitetsplanlægning; store udsving spilder kapacitet ved lav belastning eller skaber overbelastning ved spidsbelastning.

Krav til privatliv eller compliance. Data, som ikke må sendes til cloudleverandører (regulerede brancher, bestemte offentlige kontrakter eller rent interne data).

Tilpassede modeller. Finjusteringer, specialarkitekturer eller særlige varianter, som administrerede leverandører ikke tilbyder.

Kontrol over latenstid. Første-token-latenstid under 100ms kræver i nogle applikationer, at modellerne kører på infrastruktur, I kontrollerer.

Omkostning pr. kald under break-even. Når regnestykket reelt viser, at selvhosting vinder.

Når de fleste af disse forhold gælder, fortjener selvhosting seriøs overvejelse.

Hvornår selvhosting ikke giver mening

Den anden side er egenskaber, der taler for administrerede API’er:

Lav eller varierende skala. Inferensforbrug under €5K/month. Besparelsen retfærdiggør ikke driftsomkostningen.

Ujævne arbejdsbelastninger. Brug, der varierer 10x mellem spids- og lavbelastning. Selvhosting spilder kapacitet i dalene.

Behov for frontier-kapacitet. GPT-5.5, Claude Opus 4.8, samt de nyeste ræsonnementskategorier er lukkede og kun tilgængelige via API’er. Hvis jeres arbejdsbelastning reelt kræver frontier-kvalitet, skal I betale for API’erne.

Lille team. Selvhostet inferens kræver driftskompetencer. Uden dedikeret kapacitet går ting i stykker.

Hurtig iteration. Afprøvning af mange modeller, konfigurationer og leverandører. API’er gør det let; ved selvhosting bliver hver ændring en udrulning.

Flere regioner eller globale brugere. Ved selvhosting skal I drive infrastrukturen i hver region. Administrerede API’er håndterer det.

I disse tilfælde er administrerede API’er det rigtige svar, selv ved en betydelig pris.

Omkostningsregnestykket (omhyggeligt)

Lad os gennemgå de faktiske tal for et repræsentativt tilfælde. Antagelser:

• Arbejdsbelastning: 100 millioner inputtokens/måned, 30 millioner outputtokens/måned.
• Kvalitetsmål: Sammenligneligt med Claude Sonnet 5 eller den aktuelle GPT-5.x-kategori.
• Tilgængelig åben model: Llama 3.3 70B (kvaliteten ligger tæt på lukkede flagskibsmodeller til mange opgaver; bemærk, at der ikke findes en »Llama 4 70B« — Llama 4 udgives som Scout/Maverick MoE-modeller).

Mulighed A: API til en lukket model.

• Lukket flagskibs-API (Claude Sonnet 5 listepris, bekræftet 2026-07-07): $3/M input × 100M = $300. $15/M output × 30M = $450. I alt: ~$750/month.

Dette forbrugsniveau retfærdiggør ikke selvhosting.

Lad os opskalere arbejdsbelastningen med 10x:

• 1 milliard inputtokens, 300 millioner outputtokens.
• Lukket API: $7,500/month.

Nu bliver selvhosting interessant.

Mulighed B: API til en åben model hos en administreret open source-leverandør.

• Llama 3.3 70B hos Together AI: $0.88/M for input og output (listepris, bekræftet 2026-07-07).
• 1B input × $0.88/M = $880. 300M output × $0.88/M = $264. I alt: ~$1,144/month.

En besparelse på ~85% i forhold til en lukket model. Betydeligt.

Mulighed C: Selvhostet på lejede GPU’er.

• En kvantiseret (INT8/FP8) 70B-model passer på én H100 med 80GB; planlæg med ~2 H100’er til FP16-vægte eller ekstra batchkapacitet — dimensioneringen nedenfor antager 2 for kapacitet.
• Lejede H100’er: $2-3/hour pr. enhed.
• 2 H100’er × $2.50/hour × 730 hours/month = $3,650/month alene til beregning.
• Dertil: lagring, netværk og driftstid.

Til denne arbejdsbelastning slår en åben model hos en administreret leverandør selvhosting på den direkte omkostning. Selvhosting vinder kun, hvis I også har brug for kontrol (privatliv eller en tilpasset model), eller hvis kapacitetsbehovet er langt højere.

Mulighed D: Selvhostet på ejede eller langsigtet reserverede GPU’er.

• 2 H100’er købt eller reserveret langsigtet: effektivt $1-2/hour.
• 2 H100’er × $1.50/hour × 730 hours = $2,190/month.
• Højere udnyttelse kan fordele omkostningen: Hvis GPU’erne håndterer flere arbejdsbelastninger, bliver omkostningen pr. arbejdsbelastning lavere.

Nu er vi konkurrencedygtige med administrerede open source-leverandører. Men den driftsmæssige overhead er reel.

Den centrale indsigt: Ved denne skala (~1.3B tokens/month) er besparelsen ved selvhosting i forhold til administrerede open source-leverandører marginal. Besparelsen i forhold til lukkede API’er er dramatisk, men administrerede open source-tjenester henter det meste af den.

Ved 10x denne arbejdsbelastning (~13B tokens/month) begynder selvhosting klart at vinde. Ved 10x mindre er hosting svaret.

Driftsomkostningen

Ud over den direkte inferensomkostning kommer driftsomkostningen ved selvhosting.

Første opsætning:

• Valg af den rigtige inferensserver (vLLM, TGI eller SGLang).
• Konfiguration til jeres model og hardware.
• Opsætning af GPU-infrastruktur (cloud eller ejet).
• Netværk, sikkerhed og observerbarhed.
• Kvantisering og optimering.

Typisk: 1-4 udvikleruger til den første udrulning.

Løbende drift:

• Overvågning (latenstid, kapacitet, fejl og GPU-udnyttelse).
• Kapacitetsplanlægning.
• Opgraderinger (nye modelversioner, opdateringer til inferensserveren og sikkerhedsrettelser).
• Hændelseshåndtering (GPU-fejl, OOM-nedbrud og softwarefejl).
• Skalering (flere GPU’er, efterhånden som belastningen vokser).

Typisk: 0.25-1 udviklerårsværk løbende, afhængigt af skalaen.

Skjulte omkostninger:

• Prisudsving på GPU’er.
• Omkostninger til cloud-egress i hybride løsninger.
• Specialkompetencer (CUDA, kvantisering og optimering).
• Udskiftning og fejlomkostninger ved ejet hardware.

Ved €100K-200K pr. udvikler/år i samlet omkostning er selv deltidsopmærksomhed fra en udvikler betydelig. En besparelse på €5K/month på inferens forsvinder under €15K/month i udviklingsomkostning.

Det er her, teams undervurderer omkostningen ved selvhosting. Inferensregnestykket ser godt ud isoleret, men de samlede ejeromkostninger er langt højere.

Inferensserverne

Hvis I vil selvhoste, er de vigtigste muligheder:

vLLM. Open source. Sandsynligvis den mest populære til servering af åbne LLM’er. PagedAttention, kontinuerlig batching og bred modelunderstøttelse. Standardvalget.

TGI (Text Generation Inference). Hugging Faces server. Moden, bred modelunderstøttelse og god ydelse. Den seneste tid mindre hurtig funktionsudvikling end vLLM.

SGLang. Nyere, meget høj ydelse. Stærk til struktureret generering. Aktiv udvikling.

LMDeploy. Fra InternLM-teamet. Stærk kvantisering, høj hastighed.

llama.cpp / Ollama. Til mindre modeller og lavere kapacitet. CPU-venlig. Produktionsklar til visse brugsscenarier.

Hugging Face TGI Inference Endpoints. Administreret selvhosting. Betaling pr. time for instanser; HF driver dem. En mellemvej mellem fuld selvhosting og en administreret tjeneste.

Modal, RunPod, Replicate. Function-as-a-service til inferens. Lavere binding end fuld selvhosting; højere pris end at drive det selv.

For de fleste teams: vLLM eller SGLang til selvhosting i produktion. Begge er modne, hurtige og veldokumenterede.

Valg af hardware

GPU-spørgsmålet:

NVIDIA H100. Aktuel state of the art til inferens. ~$2-3/hour i leje. Giver 80GB VRAM og hurtig inferens. 70B-modeller kører godt på én H100 med kvantisering eller 2x uden.

NVIDIA H200. Efterfølgeren til H100 med mere VRAM (141GB). Til meget store modeller.

NVIDIA L40S. Mere tilgængelig, ~$1-2/hour. God til modeller af moderat størrelse (op til ~30B med kvantisering).

NVIDIA A100. Forrige generation, fortsat bredt tilgængelig. ~$1-2/hour. Arbejdshesten i mange produktionsudrulninger.

AMD MI300X. Konkurrencedygtig med H100 til visse arbejdsbelastninger. Stadig mere tilgængelig. Noget mindre moden software end NVIDIA-stacken.

Apple M-serien. Til meget små modeller (under 8B) fungerer Mac Studio eller Mac Pro med samlet hukommelse. Et nichetilfælde.

Til de fleste produktionsmiljøer med selvhosting i 2026: H100 eller H200 til store modeller; L40S eller A100 til moderate modeller.

Udlejningskilder: AWS, GCP, Azure (almindelige), Lambda Labs, Runpod, Together og Vast.ai (specialiserede). Priserne varierer. Spot- eller preemptible-instanser kan spare 50-70% hvis I kan tåle afbrydelserne.

Kvantisering

De fleste selvhostede produktionsudrulninger bruger kvantiserede modeller. Afvejningerne:

FP16 (16-bit). Standardpræcision. Fuld kvalitet. Størst hukommelsesforbrug.

INT8 / FP8 (8-bit). Halverer hukommelsen med et lille kvalitetstab. Et almindeligt produktionsvalg.

INT4 (4-bit). En fjerdedel af hukommelsen, et mere mærkbart kvalitetstab, men stadig nyttigt. Et aggressivt valg.

AWQ, GPTQ, GGUF. Forskellige kvantiseringsformater med forskellige afvejninger.

For en 70B-model:

• FP16: 140GB VRAM.
• INT8: 70GB VRAM.
• INT4: 35GB VRAM.

H100 har 80GB VRAM. INT8 passer komfortabelt; FP16 kræver 2 GPU’er.

Kvalitetspåvirkning:

• INT8: normalt <1% forringelse i benchmarks.
• INT4: 1-5% forringelse, afhængigt af opgaven.

Test på jeres arbejdsbelastning før udrulning. Nogle opgaver (især struktur og kode) er mere følsomme over for kvantisering end andre.

Kapacitet og kapacitetsplanlægning

Et centralt planlægningsspørgsmål: Hvor mange tokens/second har I brug for?

Kapacitet ved én forespørgsel.

• 70B-model på H100, INT8: ~50-80 tokens/second til én bruger.

Batchet kapacitet.

• Flere samtidige forespørgsler: 1000-3000 tokens/second samlet på tværs af forespørgsler (vLLM med god batching).

Overvejelser om latenstid.

• Første-token-latenstid: typisk 100-500ms.
• Latenstid pr. token: 10-30ms.

Til kapacitetsplanlægning:

• Estimér det maksimale antal samtidige forespørgsler.
• Estimér den gennemsnitlige forespørgselslængde.
• Beregn det samlede behov i tokens/second.
• Tilføj 50% reservekapacitet.

Et team, der håndterer 1M tokens/hour med 50 samtidige brugere ved spidsbelastning, har typisk brug for 2-4 H100’er med god udnyttelse.

Pålidelighed og fallback

Selvhosting betyder, at I ejer pålideligheden.

Sundhedstjek. Kontinuerlig sundhedsovervågning. Genstart defekte instanser.

Kontrolleret degradering. Når kapaciteten er mættet, bør langsomme svar foretrækkes frem for fejl.

Fallback til API’er. Mange teams kører primær trafik selv og falder tilbage til administrerede API’er ved overbelastning. Det bedste fra begge verdener; kompleksiteten er reel.

Reservehardware. GPU’er fejler. Hav ledig kapacitet klar.

Flere regioner. Replikér til globale brugere. Eller brug administrerede API’er i fjerne regioner.

Opdateringsstrategi. Nye modelversioner og serveropgraderinger. Brug blue-green-udrulninger for at undgå nedetid.

Hvert punkt er udviklingsarbejde, som administrerede API’er håndterer for jer.

Et gennemarbejdet eksempel: et teams beslutning om selvhosting

Et konkret eksempel. Et SaaS-team med AI-funktioner har månedlige inferensomkostninger på administrerede API’er på €18,000.

Regnestykket:

• 80% af inferensen er klassifikation og udtræk (kan køre på en mindre åben model).
• 20% er kompleks generering (kræver en lukket frontier-model).

Planen:

• Selvhost Llama 3.3 70B til 80% af arbejdsbelastningen.
• Behold Claude/GPT-API’et til de 20%.
• 3 H100’er reserveret hos Lambda Labs: ~€4,500/month.
• Udviklingsopsætning: 4 uger, €25K som engangsomkostning.
• Løbende drift: 0.25 udviklerårsværk, ~€30K/year.

Resultat efter 6 måneder:

• Inferensomkostningen faldt fra €18K/month til €6K/month (€4.5K selvhostet + €1.5K lukket API til svære opgaver).
• Nettobesparelse i forhold til tidligere: €12K/month = €144K/year.
• Fratrukket udviklingsinvesteringen: €25K én gang + €30K/year ≈ €55K det første år (€30K/year derefter).
• Finansiel nettogevinst: €89K det første år (€114K/year derefter).

Skjulte kompleksiteter:

• Ét udfald, da en udrulning havde en konfigurationsfejl. 2-hour delvis degradering.
• Flere ugers løbende finjustering for at optimere kapaciteten.
• Udvikleren med ansvar for selvhosting ønskede at arbejde på andre ting.

Resultat: Økonomisk positivt, men driftsmæssigt tungere end forventet. Teamet fortsætter med selvhosting; faldt volumen med 50%, ville de vende tilbage til en administreret tjeneste.

Sådan ser en reel, vellykket beslutning om selvhosting ud. Ikke magi — udviklingsarbejde med målbar ROI.

Et gennemarbejdet eksempel: et teams beslutning om at »vende tilbage til API’er«

Et andet team med et lignende udgangspunkt.

Oprindelig opsætning: Selvhostet Llama 3 70B på lejede GPU’er. Inferensomkostning: €3K/month i leje. Dertil løbende udviklingsarbejde på ~€20K/year.

Ændringen:

• Prisen på åbne modeller hos administrerede leverandører faldt 50% over 18 måneder.
• Teamet voksede, men ansatte ikke dedikeret MLOps-kapacitet.
• Selvhosting krævede en større indsats for at følge med nye modeller.

Beslutningen:

• Stop selvhosting.
• Flyt til Together AI til hosting af åbne modeller.
• Omkostning: €2.5K/month for den administrerede åbne model. En lille besparelse og lavere kompleksitet.
• Frigør udvikleren.

Resultat:

• Moderat økonomisk besparelse.
• Udviklertid frigivet til produktarbejde.
• Mindre driftsmæssig belastning.

Resultat: Det rigtige valg for dem. Selvhosting vinder for nogle teams, ikke for alle.

Hvornår beslutningen skal genovervejes

Beslutningen er ikke permanent. Genovervej den regelmæssigt:

Ændret volumen. Betydeligt op: selvhosting bliver mere attraktivt. Betydeligt ned: mindre attraktivt.

Prisændringer. Lukkede API’er bliver billigere eller dyrere. Administrerede åbne modeller bliver billigere. Hardware bliver billigere.

Modelforbedringer. Nye open source-modeller matcher lukket kvalitet. Nye lukkede modeller trækker fra.

Driftskapacitet. Teamets ML- og driftskompetencer vokser eller skrumper.

Ændrede krav til privatliv eller compliance. Nye krav gør selvhosting obligatorisk.

En kvartalsvis gennemgang er rimelig. Ikke konstant revurdering, men heller ikke »besluttet én gang«.

Almindelige fejl

Mønstre, vi ser i beslutninger om selvhosting:

Fejl 1: Omkostningsregnestykke uden driftsomkostning. »Selvhosting sparer €10K/month« — men ser bort fra €15K/month i udviklingsomkostning. Negativ ROI.

Fejl 2: Selvhosting for tidligt. Udviklingsindsats bruges på selvhosting, mens arbejdsbelastningen er lille. For tidlig optimering.

Fejl 3: Forsøg på frontier-kvalitet med små åbne modeller. »Vi kan spare penge med en mindre model« — men kvaliteten falder, og brugerne klager. Teamet falder tilbage til API’er.

Fejl 4: Ingen fallback. Den selvhostede infrastruktur går ned uden kontrolleret degradering. Et udfald, som API-kunder ikke ville have haft.

Fejl 5: For lille investering i optimering. En 70B-model kører på én GPU med 5 tokens/sec, mens en korrekt opsætning giver 50. Det meste af værdien går tabt.

Fejl 6: Kvalitetsdrift ignoreres. Den selvhostede model er blevet dårligere i forhold til den aktuelle lukkede model. Kunderne opdager det; teamet gør ikke.

Fejl 7: Ingen genovervejelse. Når først teamet selvhoster, vurderes beslutningen aldrig igen. Den kan have været rigtig for to år siden og forkert nu.

Fejl 8: Spot/preemptible uden kontrolleret håndtering. 60% sparet på beregning; udfald med få timers mellemrum, når instanserne inddrages.

En beslutningstjekliste

Træf beslutningen bevidst:

• Er API-forbruget mindst €5-10K/month?
• Er arbejdsbelastningen stabil og forudsigelig?
• Har teamet eller kan det ansætte kompetencer inden for MLOps og inferens?
• Findes der en open source-model med tilstrækkelig kvalitet?
• Er kravene til latenstid forenelige med selvhosting?
• Har I lavet et detaljeret regnestykke inklusive driftsomkostninger?
• Har I en fallbackplan?
• Tvinger compliance- eller privatlivskrav ikke én bestemt vej?
• Vil I genoverveje beslutningen kvartalsvis?

Hvis de fleste svar er ja, fortjener selvhosting seriøs overvejelse.

Hybride mønstre

Det er ikke alt eller intet. Mange teams kører hybridt:

Selvhostet til hovedparten; API’er til de svære tilfælde. Klassifikation og enkel generering selvhostes; kompleks ræsonnering bruger lukkede API’er.

Selvhostet til basisbelastning; API’er til spidsbelastning. Selvhosting håndterer grundbelastningen; API’er absorberer toppene.

Selvhostet til følsomt; API’er til generelt. Følsomme data behandles selvhostet; generelle forespørgsler går gennem API’er.

Selvhostet til finjusteringer; API’er til basismodeller. I driver selv tilpassede modeller; standardmodeller leveres fra API’er.

Hybrid drift tilføjer kompleksitet, men fanger ofte det bedste fra begge verdener. For teams i stor skala er hybrid ofte det rigtige svar.

Konklusionen

Selvhosting af LLM-inferens er reelt levedygtigt i 2026. Open source-modeller er konkurrencedygtige. Inferensserverne er modne. Hardware er tilgængelig.

Men driftsomkostningen er reel og let at undervurdere. Break-even-punktet over for administrerede API’er ligger omkring €5-10K/month i inferensforbrug; under det tjener udviklingsinvesteringen sig ikke hjem.

Teams, der lykkes med selvhosting:

• Har lavet et ærligt regnestykke inklusive driftsomkostninger.
• Har eller kan opbygge MLOps-kompetencer.
• Kører i tilstrækkelig skala til at retfærdiggøre investeringen.
• Har stabile arbejdsbelastninger.
• Har ikke behov for kapacitet, der kun findes i frontier-modeller.
• Planlægger pålidelighed, overvågning og opdateringer.

Teams, der bør blive på API’er:

• Lavere skala.
• Ujævne arbejdsbelastninger.
• Behov for hurtig iteration.
• Små teams uden driftskapacitet.
• Behov for lukkede frontier-modellers kapacitet.

Det rigtige svar afhænger af jeres situation. Gennemgå tallene omhyggeligt. Vurdér driftskapaciteten ærligt. Vælg som udgangspunkt API’er, medmindre selvhosting klart vinder.

Når selvhosting vinder, vinder det stort — økonomisk og arkitektonisk. Når det ikke gør, er det en dyr måde at opdage, at administrerede API’er hele tiden var det rigtige valg.