At selvhoste en open-weight LLM vs. et API: Den reelle omkostningsmatematik

Dit produkt sendes i luften, det kalder et LLM-API, og regningen er kravlet op hver måned. Så du gør det, enhver builder til sidst gør: du åbner en ny fane og spekulerer på, om det ville være billigere at leje en GPU og køre Llama selv.

Spørgsmålet om selvhostings-LLM-omkostninger har et svar, men det er ikke det ene tal, som de øverste søgeresultater og AI Overviews bliver ved med at gentage. Det afhænger af tre ting, som de artikler flader ud: hvilket API du sammenligner mod, hvor travlt din GPU har, og de driftsomkostninger, ingen sætter i regnearket.

Her er den korte version før detaljerne: for de fleste solo-buildere vinder selvhosting ikke på omkostninger lige nu. Men der er en bestemt linje, hvor det vender, og du kan beregne den på din egen regning på cirka to minutter. Nedenfor er 2026-matematikken (aktuelle priser, VRAM-tal per model og en formel, du kan køre).

Den korte version

• Break-even er ikke ét tal. Det er tre, afhængigt af hvilket API du sammenligner mod. Mod et frontier-API (GPT-5.x, Claude Sonnet 5 / Opus 4.8, Gemini Pro) går selvhosting hurtigst i break-even. Mod et budget-open-weight-API (DeepSeek, DeepInfra, Together til nogenlunde $0.14–$0.50 per million tokens) vinder det næsten aldrig på omkostninger alene.
• Udnyttelse er den multiplikator, der dræber solo-casen. En lejet GPU koster det samme i tomgang, som den gør ved fuld belastning, så en GPU, der kører ved 10% udnyttelse, koster nogenlunde 10× per token af, hvad den koster ved fuld belastning. Stødvise solo-workloads ligger ved lav udnyttelse som standard.
• Under break-even er omkostningssejren som regel at skifte til et budget-open-weight-API, ikke selvhosting. Selvhosting tjener sit ophold, når vedvarende volumen mod frontier-priser klarer linjen ved 60%+ udnyttelse, eller når du har en ikke-omkostningsmæssig grund (privatliv, latens, kontrol over fine-tuning).
• Kør formlen på dine egne tal, før du lejer noget. Break-even-tokens ≈ månedlig GPU VPS-omkostning ÷ din blandede API-pris per token.

Hvad dette ikke dækker

• Multi-node eller datacenter-skala GPU-klynger. Dette er en solo-omkostningsbeslutning, ikke en flåde.
• Fine-tuning-økonomi i nogen dybde (en separat beregning med sine egne afvejninger).
• En trin-for-trin Ollama-vs-vLLM-opsætningstutorial. Omfanget her er pengespørgsmålet, ikke installationen.
• Ejet hardware som dit primære middel. Antagelsen hele vejen igennem er en lejet GPU, da det er den realistiske vej for en builder uden en GPU, der allerede står på et skrivebord.

Hvad driver omkostningen (og hvor de populære tal går galt)

Søg "self host LLM vs API cost", og du lander på et pænt break-even-tal: noget i retning af 11 milliarder tokens om måneden, eller omkring $4,200 i månedligt API-forbrug, citeret af braincubers omkostningsanalyse og gengivet næsten ordret i AI Overview øverst på siden. Det er et rent tal. Det er også tæt på ubrugeligt i sig selv, fordi det skjuler de to variabler, der afgør dit svar.

Grunden til, at dette er glat, er, at de to sider af sammenligningen har forskellige omkostningsformer. En API-regning er en variabel omkostning: du betaler per token, så regningen skalerer op og ned med, hvor meget du bruger den. En lejet GPU er en fast omkostning: du betaler den samme månedlige sats, uanset om du sender en milliard tokens gennem den eller lader den stå i tomgang. At sammenligne en variabel omkostning med en fast omkostning med ét tal kræver, at du lader som om, du ved præcis, hvor mange tokens der vil flyde, og i solo-skala ved du det som regel ikke.

Det efterlader tre håndtag, der flytter break-even:

• Hvilket API du sammenligner mod. Et frontier-API og et budget-open-weight-API er adskilt af nogenlunde to størrelsesordener i pris. Break-even mod hver er vildt forskellig.
• Din GPU-udnyttelse. Den faste omkostning betaler sig kun, hvis GPU'en har travlt. Tomgangstid er penge, du brugte for ingenting.
• Den skjulte driftsomkostning. Dine timer, model-opdaterings-churn og de VRAM-overraskelser, der ikke dukker op, før du er i produktion.

Prissæt hver af dem, og tågen letter. Det er resten af denne artikel.

Sektionens hovedpointe: break-even er ikke ét enkelt tal. Det er tre tal, ét per API-niveau, og at vælge det forkerte niveau at sammenligne mod er der, hvor de fleste omkostningsestimater går galt.

Trevejs-break-even: Frontier vs. mellemniveau vs. budget-API

At selvhoste en open-weight LLM på en GPU VPS slår et frontier-API (GPT-5-klasse, Claude Sonnet 5 / Opus 4.8, Gemini Pro) ved nogenlunde et par millioner tokens om dagen, forudsat at du holder GPU'en på sund udnyttelse (lad os sige 60% eller højere). Mod et budget-open-weight-API til omkring $0.14–$0.50 per million tokens vinder det sjældent på omkostninger overhovedet. Den forskel er hele historien, og det er derfor, ét break-even-tal ikke kan være rigtigt.

Her er formen på det på tværs af de tre niveauer. Behandl disse tærskler som retningsgivende intervaller, ikke hårde linjer. De kommer fra community-estimater og 2026-priser, som begge bevæger sig hurtigt.

Priser fra OpenAI, Anthropic, Google, DeepInfra, Together, og DeepSeek prissætningssiderne pr. July 2026. Hvert eneste af disse tal har en holdbarhed målt i måneder, så tjek de aktuelle sider, før du forpligter dig.

Nu den kontrære pointe, fordi det er den, der ændrer beslutninger. Der går et højlydt og korrekt argument rundt om, at budget-API'er dræbte selvhostings-break-even. Open-weight-API'er som DeepInfra og Together serverer nu Llama- og Qwen-modeller til en brøkdel af frontier-priser, og frontier-priserne selv er faldet kraftigt siden 2025. Mod de budgetsatser løber per-token-break-even op i milliarder af tokens om måneden. En solopreneur sender ikke milliarder af tokens om måneden. Så hvis dit eneste mål er en lavere regning, er det første træk som regel ikke "lej en GPU", det er "skift til et budget-open-weight-API og hold nul drift".

Selvhostings omkostningssag overlever to steder: sammenlignet mod dyre frontier-priser ved ægte høj, vedvarende volumen, og de ikke-omkostningsmæssige grunde (privatliv, latens, kontrol over fine-tuning) dækket længere nede. Alle andre steder vinder budget-API'et pengeargumentet.

Break-even-formlen

break-even tokens per month ≈ GPU VPS monthly cost ÷ your blended API price per token

Gennemregnet eksempel, solopreneur-skala: lad os sige, at en enkelt high-end GPU VPS koster omkring $1,000/måned (2026-katalogets interval for et top-single-GPU-niveau), og du er på et frontier-API med en blandet sats omkring $6 per million tokens (nogenlunde $0.000006 per token). Det er ~$1,000 ÷ $0.000006 ≈ 167 millioner tokens/måned, før GPU'en betaler sig selv på papiret. Lav den nu om mod et budget-open-weight-API til $0.40 per million ($0.0000004/token): ~$1,000 ÷ $0.0000004 = 2.5 milliarder tokens/måned. Samme GPU, samme faste omkostning, og break-even flytter sig med mere end 10× rent afhængigt af, hvilket API du sætter i nævneren. Dette er før udnyttelse, som gør tallet værre.

Sektionens hovedpointe: Det API, du sammenligner mod, kan flytte din break-even med 10× eller mere, så "kør tallene" betyder at køre dem mod det specifikke API, du faktisk ville erstatte.

Hvad udnyttelse gør ved omkostningen per token

Tag den ~167 millioner-token frontier-break-even og tilføj den variabel, formlen stille antager bort: din GPU har travlt hele tiden. Det har den ikke. En lejet GPU fakturerer det samme, uanset om den er mættet eller i tomgang, så din effektive GPU VPS LLM-omkostning per token skalerer omvendt med udnyttelse. Kør ved 10% belastning, og hver token, du serverer, bærer nogenlunde 10× den omkostning, den ville have ved fuld belastning, fordi du betaler for de 90% kapacitet, du ikke brugte. Community-estimater og praktiker-redegørelser sætter den praktiske bund ved omkring 50–60% vedvarende udnyttelse, før tallene holder op med at gøre dig forlegen (retningsgivende tal, ikke laboratoriekonstanter).

For en stødvis solo-workload (trafik der spidser i løbet af dagen og fladdør natten over) er vedvarende 60% udnyttelse svær at ramme. Det er fælden. Her er, hvad det gør ved omkostningen per million tokens på tværs af nogle konkrete punkter, ved brug af 2026-katalogets GPU-priser divideret med grov månedlig gennemstrømning på hvert udnyttelsesniveau:

De absolutte cents-per-token afhænger af din model, kvantisering og hvor mange samtidige forespørgsler du kan pakke på kortet, så behandl kolonnerne som visende formen af straffen frem for et tilbud. Pointen er multiplikatoren: gå fra fuld belastning til en fjerdedels belastning, og din omkostning per token firdobles nogenlunde. Det er som regel det, der dræber solo-selvhostings-casen, ikke GPU'ens listepris.

Der er én strukturel nødudgang, og det er grunden til, at leje kan slå ejerskab ved spidsbelastet efterspørgsel: du kan stoppe en lejet instans, når den er i tomgang. Ej hardwaren, og den afskrives og trækker strøm, uanset om du bruger den eller ej. På time- eller on-demand-lejemål kan du stoppe eller rive instansen ned, når jobbet er gjort, og undgå at betale for tomgangstimer. På faste månedsplaner er regningen stadig fast for faktureringsperioden, så udnyttelse forbliver det primære omkostningsproblem. Det løser ikke en workload, der reelt har lav udnyttelse hele dagen, men for efterspørgsel, der har travlt i stød og er død ind imellem, er evnen til at slukke måleren det ene håndtag, der får leje-vs-eje til at hælde mod leje.

Sektionens hovedpointe: udnyttelse, ikke GPU'ens månedlige pris, er som regel det, der afgør, om selvhosting går op, og det er den variabel, de populære break-even-tal helt udelader.

Hvilken model passer til hvilken GPU: VRAM-virkeligheden

Planen, der brister først, er "jeg kører bare en 70B på en 4090". Det kan du ikke. En 70B-model ved Q4_K_M-kvantisering kræver nogenlunde 40–46 GB VRAM, og et 24 GB RTX 4090 eller et 32 GB RTX 5090 har simpelthen ikke pladsen. Tving den ned på et 24 GB-kort, og du er nede på Q2_K-kvantisering (omkring 21 GB) med synligt kvalitetstab, eller modellen løber over i system-RAM og genereringshastigheden kollapser. VRAM er den hårde mur, der afgør, hvilke modeller der overhovedet er på bordet for en given GPU.

Her er, hvad der passer hvor. VRAM-tal er omtrentlige: de er udledt af standard bytes-per-parameter-aritmetikken (FP16 ≈ params × 2 med ~15% overhead; Q4_K_M ≈ params × ~0.55 med overhead), så behandl dem som dimensioneringsvejledning, ikke garantier.

VRAM-tal er krydstjekket mod NVIDIAs officielle GPU-spec-sider for hvert kort. A100 giver en kvantiseret 70B mere komfortabel hovedplads; RTX 6000 Ada kan fungere til strammere Q4-opsætninger, mens 24 GB- og 32 GB-consumer-kort ikke har nok VRAM til en normal 70B Q4-udrulning. Hvis du vil have den fulde gennemgang af, hvordan GGUF, GPTQ, AWQ og EXL2-formaterne forbruger hukommelse, er det et kaninhul, der er sit eget læsestof værd: GGUF, GPTQ, AWQ, EXL2: hvordan LLM-kvantiseringsformater faktisk bruger hukommelse.

Community-sweet-spottet for et enkelt 24 GB-kort er en 24B-til-32B-model (Mistral Small 3.1 eller Qwen 3 32B ved Q4). Det er den størrelse, der giver en solo-builder en brugbar model på det billigste GPU-niveau uden at kæmpe med VRAM hele vejen. Hvis du vejer, hvilket kort du overhovedet skal leje, sammenligner vores H100 vs RTX 4090-benchmark for AI-workloads niveauerne på gennemstrømning.

Pro-tip: budgettér for KV cache, ikke bare vægtene. Den absolut mest almindelige første-udrulnings-overraskelse: du dimensionerer GPU'en for modelvægtene, indlæser den, og den passer. Så kommer forespørgslerne ind, KV cache vokser med kontekstlængde og samtidighed, og du løber tør for VRAM, mens du serverer dine første par brugere. Når VRAM løber over, og modellen løber over til CPU, falder genereringshastigheden med 10–100×. Efterlad hovedplads over vægttallene i tabellen til cachen, især hvis du serverer lange kontekster eller flere brugere på én gang.

De skjulte omkostninger, der udsletter den naive besparelse

Regnearket, der siger, at selvhosting er billigere, har næsten altid én linje: GPU'ens månedlige pris. Regningen, du betaler, har flere linjer. Der er din tid (hver time du bruger på at patche, genstarte en hængt inferensserver eller jagte et out-of-memory-nedbrud er en time, du ikke brugte på produktet). Der er model-opdaterings-churn: den open-weight-model, du udrullede, bliver afløst, og genbenchmarking og genudrulning er tilbagevendende arbejde, ikke en engangsopsætning. Der er VRAM- og KV-cache-overraskelsen fra sidste sektion. Og der er tomgangsspild, de timer GPU'en sidder og fakturerer, mens intet kører.

Praktikere, der har talt disse, sætter den sande omkostning til nogenlunde 1.3–2× den rå GPU-pris, når først driftstid er foldet ind, og nogle går højere, til 3–5×, på rodede opsætninger. Det er retningsgivende multiplikatorer fra community-redegørelser, ikke reviderede tal, men retningen er pointen. Som en bredt citeret formulering udtrykker det: en GPU i tomgang er ikke et aktiv, det er en forpligtelse faktureret per time. For en solo-builder er den rigtige måde at prissætte dette ikke en MLOps-lønlinje, det er dine egne timer, som er det knappeste, du har. Hvis selvhosting sparer dig $200 om måneden på papiret, men koster dig seks timers drift, du ellers ville bruge på at sende, er det ikke oplagt en sejr.

Når selvhosting alligevel vinder: Privatliv, latens og fine-tuning

Omkostning er ikke den eneste grund til at køre din egen model, og for nogle buildere er det ikke engang den vigtigste. Under omkostnings-break-even, hvor pengene siger "bliv på API'et", er der tre grunde til at selvhoste alligevel. Datasuverænitet: at holde dine brugeres prompts og data ude af en ekstern AI-udbyders pipeline, hvilket betyder noget for nogle produkter uanset hvad tallene siger. Forudsigelig latens: ingen delt-tenant-kø, ingen rate limits du ikke selv satte, ingen overraskende opbremsninger under andres trafikstød. Og fuld kontrol: friheden til at fine-tune, kvantisere, skifte modeller og pinne versioner uden at vente på en leverandør.

Der er et forbehold ved privatlivspunktet, og at springe det over ville være uærligt. En lejet GPU VPS kører stadig på en andens hardware i en andens datacenter. Det er meningsfuld suverænitet fra AI-udbyderens trænings- og loggings-pipeline (dine prompts flyder ikke gennem en modelleverandørs systemer), men det er ikke det samme som on-premises-udstyr, du fysisk kontrollerer. Hvis dit krav er ægte on-prem-isolation, får en lejet VPS dig ikke derhen. Hvis dit krav er "hold vores data ude af en tredjeparts-modelleverandørs hænder", gør det. Ved hvilket af dem du har brug for.

For workloads, der kører i restriktive netværksmiljøer, kan en selvhostet model på infrastruktur, du kontrollerer, også omgå afhængigheder af eksterne endpoints, der måske er uopnåelige, en evne der betyder noget uafhængigt af, hvor du udruller den.

Så skal du selvhoste? Et ligefremt svar efter situation

Alt ovenstående sorterer ned i en kort beslutning. Du har en regning, en grov fornemmelse af din månedlige token-volumen, og nu de tre break-even-niveauer, udnyttelsesstraffen og skjult-omkostnings-multiplikatoren. Kortlæg din situation til en af disse:

• Du er under frontier-break-even, og omkostning er din eneste bekymring. Bliv på et API, og prissæt seriøst et budget-open-weight-API (DeepSeek, DeepInfra, Together) før noget andet. Det er som regel omkostningssejren, ikke selvhosting. At skifte API'er er en config-ændring; selvhosting er et andet job.
• Du har vedvarende, høj volumen mod frontier-priser og kan holde en GPU på 60%+ udnyttelse. Det er her, selvhosting betaler sig. Kør formlen mod din frontier-sats, bekræft at du klarer tærsklen med vedvarende udnyttelse (ikke spids), og en lejet GPU VPS begynder at vinde.
• Du har en ikke-omkostningsmæssig driver: privatliv, latens eller kontrol over fine-tuning. Selvhost under break-even bevidst, med åbne øjne for at du betaler for kontrollen. Bare fortæl ikke dig selv, at det er billigere, hvis det ikke er.
• Du er midt imellem. Kig på det hybridmønster, de fleste praktikere lander på i 2026: en lille selvhostet model til høj-volumen, simple opgaver, plus et frontier-API til den svære ræsonnering, din lokale model kommer 85–90% af vejen til (community-benchmarks, ikke laboratorieverificeret, og den sidste strækning er ofte, hvor du har mest brug for kvaliteten).

På "hvordan får jeg GPU'en"-spørgsmålet er svaret for en solo-builder næsten altid at leje, ikke at købe. At eje datacenter-grade hardware er en capex-væddemål, der kun giver mening ved en skala, du ikke har endnu. Serverless inferens kan reducere tomgangsspild ved at skalere til nul og kun fakturere for aktiv beregning, men det bytter ofte det for en højere per-GPU-time-sats og cold-start-latens. En lejet GPU VPS sidder i midten: ingen capex, en forudsigelig månedlig regning, root-adgang og evnen til at stoppe instansen, når den er i tomgang.

Hvis du har kørt formlen, klaret break-even og vil have en dedikeret, privat, root-adgangs-inferensserver uden at købe et kort, er det præcis, hvad en lejet GPU-maskine er til. Cloudzys GPU VPS-planer dækker intervallet fra en 8B-model på et enkelt kort op til en kvantiseret 70B, og et-kliks Ollama-appen i marketplace udruller på cirka et minut med et REST API, der er kompatibelt med OpenAI-klienter, så skiftet fra et betalt API til din egen server kan være tæt på en drop-in-ændring i din kode, uden per-token-omkostning efter det faste månedsgebyr. Tjek siden for aktuel prissætning; GPU-satser bevæger sig.

Den ene handling, der er værd at foretage, før du lejer noget: kør break-even-formlen på din egen regning. Det tager to minutter, og det vil fortælle dig, hvilken af de fire situationer ovenfor du er i.

Ofte stillede spørgsmål

Er det billigere at selvhoste en LLM eller bruge et API?

Det afhænger af hvilket API. At selvhoste en open-weight-model på en GPU VPS kan slå et frontier-API (GPT-5-klasse, Claude Sonnet 5 / Opus 4.8) ved høj, vedvarende volumen med god GPU-udnyttelse. Det slår sjældent et budget-open-weight-API (DeepSeek, DeepInfra, Together til nogenlunde $0.14–$0.50 per million tokens pr. July 2026) på omkostninger alene: den break-even løber op i milliarder af tokens om måneden, hvilket de fleste solo-buildere aldrig når.

Hvilken GPU har jeg brug for til at køre en 70B-model?

En 70B-model ved Q4_K_M-kvantisering kræver nogenlunde 40–46 GB VRAM bare til de kvantiserede vægte. En 80 GB A100 er den sikrere enkelt-GPU-mulighed, fordi den efterlader plads til KV cache, runtime-overhead og længere prompts. Et 48 GB RTX 6000 Ada kan fungere til strammere Q4-opsætninger, men kontekstlængde og samtidighed skal styres omhyggeligt.

Hvordan påvirker GPU-udnyttelse omkostningen per token?

En lejet GPU koster det samme, uanset om den er i tomgang eller fuldt belastet, så din effektive omkostning per token skalerer omvendt med udnyttelse. Ved 10% belastning koster hver token, du serverer, nogenlunde 10× af, hvad den ville ved fuld belastning, fordi du betaler for den ubrugte kapacitet. Den praktiske bund for, at selvhosting giver mening, er omkring 50–60% vedvarende udnyttelse.

Hvor mange tokens om måneden, før selvhosting er det værd?

Mod et frontier-API er nogenlunde 160–256 millioner tokens om måneden ved sund udnyttelse den retningsgivende tærskel (pr. July 2026). Mod et budget-open-weight-API er det milliarder om måneden, reelt uopnåeligt solo. Det eksakte tal afhænger af din GPU-omkostning og blandede API-sats, så kør formlen: break-even-tokens ≈ månedlig GPU VPS-omkostning ÷ din API-pris per token, og diskonter det så for vedvarende udnyttelse.

Kan jeg køre en open-weight LLM på en VPS?

Ja, på en GPU VPS dimensioneret til modellens VRAM. Et værktøj som Ollama kører open-weight-modeller (Llama, Qwen, Mistral og andre) med en et-kliks-udrulning og et OpenAI-compatible REST API, så din eksisterende API-kaldende kode kan pege på din egen server med minimale ændringer. Match GPU-niveauet til din model: en 8B passer komfortabelt på et 24 GB-kort, en kvantiseret 70B kræver 48–80 GB.