Argumentet är lockande. Modeller med öppen källkod är konkurrenskraftiga. GPU:er finns att tillgå. Inferensservrar som vLLM, TGI och SGLang är mogna. Varför betala ett påslag på 5–10 gånger till OpenAI eller Anthropic när motsvarigheten kan köras i egen drift?
Verkligheten är mer komplex. Egen drift vinner faktiskt vid vissa volymer. Vid andra överstiger driftskostnaden besparingen för inferens med bred marginal. Nollpunkten varierar med arbetslast, modellstorlek, latenskrav och teamets förmåga.
Den här artikeln går på djupet i kalkylen, den operativa verkligheten och mönstren som skiljer team som bör driva själva från dem som inte bör göra det. Vi utgår från att du överväger detta på allvar och vill ha uppriktiga siffror.
När egen drift är motiverad
Egenskaper som talar för egen drift:
Skala. Hög inferensvolym. En månatlig API-kostnad över 5 000–10 000 euro motiverar vanligtvis att egen drift övervägs.
Förutsägbar arbetslast. Jämn och förutsägbar användning. Egen drift kräver kapacitetsplanering; toppig belastning slösar kapacitet vid underutnyttjande eller fallerar vid överbelastning.
Integritets- eller efterlevnadskrav. Data som inte får skickas till molnleverantörer, exempelvis i reglerade branscher, vissa myndighetsavtal eller strikt interna data.
Anpassade modeller. Finjusteringar, anpassade arkitekturer eller specialiserade varianter som hanterade leverantörer inte erbjuder.
Latenskontroll. För vissa tillämpningar kräver en latens till första token under 100 ms att modellerna körs på infrastruktur du styr.
Kostnad per anrop under nollpunkten. När kalkylen faktiskt visar att egen drift vinner.
När merparten stämmer bör egen drift övervägas seriöst.
När egen drift inte är motiverad
Den andra sidan. Egenskaper som talar för hanterade API:er:
Låg eller varierande skala. Inferensutgifter under 5 000 euro/månad. Besparingen motiverar inte driftskostnaden.
Toppiga arbetslaster. Användning som varierar tiofaldigt mellan toppar och lugna perioder. Egen drift slösar kapacitet i dalarna.
Behov av frontlinjefunktioner. GPT-5.5, Claude Opus 4.8 och de senaste resonemangsnivåerna är slutna och endast tillgängliga via API. Om arbetslasten verkligen kräver frontlinjekvalitet måste du betala för API:er.
Litet team. Egen inferensdrift kräver operativ expertis. Utan avsatt kapacitet går saker sönder.
Snabb iteration. Många modeller, konfigurationer och leverantörer provas. Med API:er är det enkelt; vid egen drift blir varje ändring en driftsättning.
Flera regioner eller globala användare. Egen drift kräver verksamhet i varje region. Hanterade API:er sköter det.
I dessa fall är hanterade API:er rätt även om kostnaden är betydande.
Kostnadskalkylen, noggrant utförd
Vi räknar på ett representativt fall. Antaganden:
- Arbetslast: 100 miljoner indatatoken och 30 miljoner utdatatoken per månad.
- Kvalitetsmål: jämförbart med Claude Sonnet 5 eller aktuell GPT-5.x-nivå.
- Tillgänglig öppen modell: Llama 3.3 70B. Kvaliteten ligger nära de ledande slutna modellerna för många uppgifter. Observera att ”Llama 4 70B” inte finns; Llama 4 levereras som MoE-modellerna Scout/Maverick.
Alternativ A: API till en sluten modell.
- Ledande slutet API (listpris för Claude Sonnet 5, kontrollerat 2026-07-07): 3 dollar/miljon indatatoken × 100 miljoner = 300 dollar. 15 dollar/miljon utdatatoken × 30 miljoner = 450 dollar. Totalt cirka 750 dollar/månad.
Denna kostnadsnivå motiverar inte egen drift.
Vi tiodubblar arbetslasten:
- 1 miljard indatatoken och 300 miljoner utdatatoken.
- Slutet API: 7 500 dollar/månad.
Nu blir egen drift intressant.
Alternativ B: API till en öppen modell hos en hanterad leverantör.
- Llama 3.3 70B hos Together AI: 0,88 dollar/miljon token för både in- och utdata (listpris, kontrollerat 2026-07-07).
- 1 miljard indatatoken × 0,88 dollar/miljon = 880 dollar. 300 miljoner utdatatoken × 0,88 dollar/miljon = 264 dollar. Totalt cirka 1 144 dollar/månad.
En besparing på cirka 85 % jämfört med den slutna modellen. Betydande.
Alternativ C: egen drift på hyrda GPU:er.
- En kvantiserad 70B-modell (INT8/FP8) ryms på en H100 med 80 GB. Planera för cirka två H100 för FP16-vikter eller marginal för batchgenomströmning; dimensioneringen nedan utgår från två för genomströmning.
- Hyrda H100: 2–3 dollar/timme per enhet.
- 2 H100 × 2,50 dollar/timme × 730 timmar/månad = 3 650 dollar/månad enbart för beräkning.
- Därtill kommer lagring, nätverk och drifttid.
För arbetslasten slår en öppen modell hos en hanterad leverantör egen drift i ren kostnad. Egen drift vinner endast om du också behöver kontroll för integritet eller en anpassad modell, eller om genomströmningen är mycket högre.
Alternativ D: egen drift på ägda eller långsiktigt reserverade GPU:er.
- 2 H100, köpta eller långsiktigt reserverade: effektivt 1–2 dollar/timme.
- 2 H100 × 1,50 dollar/timme × 730 timmar = 2 190 dollar/månad.
- Högre utnyttjande kan fördela kostnaden; om GPU:erna hanterar flera arbetslaster blir kostnaden per arbetslast lägre.
Nu är kostnaden konkurrenskraftig mot hanterade leverantörer av öppna modeller. Den operativa omkostnaden är dock verklig.
Den centrala insikten: vid denna skala, cirka 1,3 miljarder token/månad, är besparingen med egen drift jämfört med en hanterad leverantör av öppna modeller marginell. Besparingen mot slutna API:er är dramatisk, men den hanterade öppna leverantören fångar merparten av den.
Vid tio gånger större arbetslast, cirka 13 miljarder token/månad, börjar egen drift vinna tydligt. Vid en tiondel är värdtjänsten svaret.
Driftskostnaden
Utöver den rena inferenskostnaden tillkommer följande vid egen drift.
Inledande etablering:
- Välja rätt inferensserver (vLLM, TGI eller SGLang).
- Konfigurera den för modellen och maskinvaran.
- Etablera GPU-infrastruktur i molnet eller egen miljö.
- Nätverk, säkerhet och observerbarhet.
- Kvantisering och optimering.
Typiskt: 1–4 ingenjörsveckor för första driftsättningen.
Löpande drift:
- Övervakning av latens, genomströmning, fel och GPU-utnyttjande.
- Kapacitetsplanering.
- Uppgraderingar av modeller och inferensservrar samt säkerhetsuppdateringar.
- Incidenthantering för GPU-fel, OOM-krascher och programvarufel.
- Skalning med fler GPU:er när belastningen växer.
Typiskt: 0,25–1 ingenjörsheltidstjänst löpande beroende på skala.
Dolda kostnader:
- Volatila GPU-priser.
- Kostnad för utgående molntrafik i hybridlösningar.
- Specialkompetens inom CUDA, kvantisering och optimering.
- Ersättnings- och felkostnader för ägd maskinvara.
Med en full kostnad på 100 000–200 000 euro per ingenjör och år är även ingenjörstid på deltid betydande. En inferensbesparing på 5 000 euro/månad försvinner under en ingenjörskostnad på 15 000 euro/månad.
Här underskattar team kostnaden för egen drift. Inferenskalkylen ser utmärkt ut isolerat; den totala ägandekostnaden är mycket högre.
Inferensservrarna
Om du ska köra egen drift är de viktigaste alternativen:
vLLM. Öppen källkod och sannolikt populärast för servering av öppna LLM:er. PagedAttention, kontinuerlig batchning och brett modellstöd. Standardvalet.
TGI (Text Generation Inference). Hugging Faces server. Mogen, brett modellstöd och god prestanda. Funktionsutvecklingen har på senare tid gått långsammare än för vLLM.
SGLang. Nyare och mycket högpresterande. Stark för strukturerad generering. Aktiv utveckling.
LMDeploy. Från InternLM-teamet. Stark kvantisering och snabb.
llama.cpp/Ollama. För mindre modeller och lägre genomströmning. CPU-vänliga. Produktionsmässiga för vissa användningsfall.
Hugging Face TGI Inference Endpoints. Hanterad egen drift. Betalning per instanstimme; HF driver dem. Ett mellanting mellan full egen drift och hanterat.
Modal, RunPod, Replicate. Funktion som tjänst för inferens. Mindre åtagande än full egen drift och högre kostnad än att göra allt själv.
För de flesta team: vLLM eller SGLang för egen drift i produktion. Båda är mogna, snabba och väldokumenterade.
Val av maskinvara
GPU-alternativen:
NVIDIA H100. Aktuell toppnivå för inferens. Cirka 2–3 dollar/timme att hyra. Ger 80 GB VRAM och snabb inferens. 70B-modeller fungerar väl på en H100 med kvantisering eller två utan.
NVIDIA H200. Efterföljaren till H100, med mer VRAM (141 GB). För mycket stora modeller.
NVIDIA L40S. Mer tillgänglig, cirka 1–2 dollar/timme. Bra för medelstora modeller, upp till cirka 30B med kvantisering.
NVIDIA A100. Föregående generation, fortfarande allmänt tillgänglig. Cirka 1–2 dollar/timme. Arbetshäst i många produktionsmiljöer.
AMD MI300X. Konkurrerar med H100 för vissa arbetslaster. Allt mer tillgänglig. Viss omognad i programvaran jämfört med NVIDIA-stacken.
Apple M-serien. För mycket små modeller under 8B fungerar Mac Studio eller Mac Pro med enhetligt minne. Ett nischfall.
För de flesta produktionsmiljöer i egen drift 2026: H100 eller H200 för stora modeller; L40S eller A100 för medelstora.
Uthyrare: AWS, GCP och Azure (etablerade), Lambda Labs, Runpod, Together och Vast.ai (specialiserade). Priserna varierar. Spot-/avbrytbara instanser kan spara 50–70 % om avbrotten kan tolereras.
Kvantisering
De flesta produktionsmiljöer i egen drift använder kvantiserade modeller:
FP16 (16 bitar). Standardprecision. Full kvalitet. Högst minnesbehov.
INT8/FP8 (8 bitar). Halverar minnet med liten kvalitetsförlust. Vanligt produktionsval.
INT4 (4 bitar). En fjärdedel av minnet, med tydligare men ofta acceptabel kvalitetsförlust. Aggressivt val.
AWQ, GPTQ, GGUF. Olika kvantiseringsformat med skilda avvägningar.
För en 70B-modell:
- FP16: 140 GB VRAM.
- INT8: 70 GB VRAM.
- INT4: 35 GB VRAM.
H100 har 80 GB VRAM. INT8 ryms väl; FP16 kräver två GPU:er.
Kvalitetspåverkan:
- INT8: vanligtvis mindre än 1 % försämring i riktmärken.
- INT4: 1–5 % försämring, beroende på uppgift.
Testa på den egna arbetslasten före driftsättning. Vissa uppgifter, särskilt strukturerade uppgifter och kod, är känsligare för kvantisering än andra.
Genomströmning och kapacitetsplanering
En central fråga är hur många token per sekund som behövs.
Genomströmning för enskild begäran.
- 70B-modell på H100 med INT8: cirka 50–80 token/sekund för en användare.
Batchad genomströmning.
- Flera samtidiga begäranden: totalt 1 000–3 000 token/sekund över alla begäranden med vLLM och bra batchning.
Latens.
- Latens till första token: vanligtvis 100–500 ms.
- Latens per token: 10–30 ms.
För kapacitetsplanering:
- Uppskatta högsta antal samtidiga begäranden.
- Uppskatta genomsnittlig längd.
- Beräkna totalt behov av token/sekund.
- Lägg till 50 % marginal.
Ett team som hanterar 1 miljon token/timme och som mest 50 samtidiga användare behöver vanligtvis 2–4 H100 med gott utnyttjande.
Tillförlitlighet och reservlösning
Egen drift innebär eget ansvar för tillförlitligheten.
Hälsokontroller. Kontinuerlig övervakning och omstart av ohälsosamma instanser.
Kontrollerad degradering. När kapaciteten är mättad är långsamma svar bättre än fel.
Reserv till API:er. Många team kör primär trafik själva och använder hanterade API:er vid överbelastning. Det bästa av två världar, men med verklig komplexitet.
Reservmaskinvara. GPU:er går sönder. Ha reservkapacitet redo.
Flera regioner. Replikera för globala användare eller använd hanterade API:er i avlägsna regioner.
Uppdateringsstrategi. Nya modellversioner och serveruppgraderingar. Blågröna driftsättningar undviker avbrott.
Allt detta är ingenjörsarbete som hanterade API:er sköter åt dig.
Exempel: ett teams beslut om egen drift
Ett verkligt exempel: ett SaaS-team med AI-funktioner och 18 000 euro i månatlig inferenskostnad hos hanterade API:er.
Kalkylen:
- 80 % av inferensen är klassificering och extraktion som kan köras på en mindre öppen modell.
- 20 % är komplex generering som kräver en sluten frontlinjemodell.
Planen:
- Llama 3.3 70B i egen drift för 80 %.
- Claude/GPT-API för resterande 20 %.
- 3 reserverade H100 hos Lambda Labs: cirka 4 500 euro/månad.
- Etablering: 4 veckor och en engångskostnad på 25 000 euro.
- Löpande drift: 0,25 ingenjörstjänst, cirka 30 000 euro/år.
Resultat efter sex månader:
- Inferenskostnaden sjönk från 18 000 till 6 000 euro/månad: 4 500 euro för egen drift + 1 500 euro till slutna API:er för svåra uppgifter.
- Bruttobesparing: 12 000 euro/månad = 144 000 euro/år.
- Ingenjörsinvestering: 25 000 + 30 000 = 55 000 euro/år.
- Finansiell nettovinst: cirka 89 000 euro/år.
Dolda komplikationer:
- Ett avbrott när en konfigurationsbugg infördes; två timmars partiell degradering.
- Flera veckors fortlöpande justering för optimal genomströmning.
- Ingenjören som skötte egen drift önskade att tiden lagts på annat.
Resultat: finansiellt positivt men operativt tyngre än väntat. Teamet fortsätter; om volymen sjönk 50 % skulle de återgå till hanterat.
Så ser ett verkligt lyckat beslut om egen drift ut. Ingen magi – ingenjörsarbete med mätbar avkastning.
Exempel: ett teams beslut att återgå till API:er
Ett annat team med liknande utgångspunkt.
Ursprunglig lösning: Llama 3 70B i egen drift på hyrda GPU:er. Inferenskostnad: 3 000 euro/månad plus cirka 20 000 euro/år i löpande ingenjörsarbete.
Förändringen:
- Priset hos hanterade leverantörer av öppna modeller sjönk 50 % på 18 månader.
- Teamet växte men anställde ingen särskild MLOps-kompetens.
- Lösningen behövde omfattande arbete för att följa med nya modeller.
Beslutet:
- Avsluta egen drift.
- Flytta öppna modeller till Together AI.
- Kostnad: 2 500 euro/månad för hanterade öppna modeller. Något billigare och mindre komplext.
- Frigöra ingenjören.
Resultat:
- Måttlig ekonomisk besparing.
- Ingenjörstid frigjord för produktarbete.
- Mindre operativ stress.
Slutsats: rätt beslut för dem. Egen drift vinner för vissa team, inte andra.
När beslutet bör omprövas
Beslutet är inte permanent. Ompröva regelbundet:
Volymförändringar. Betydande ökning gör egen drift attraktivare, betydande minskning mindre attraktiv.
Prisförändringar. Slutna API:er, hanterade öppna modeller och maskinvara blir billigare eller dyrare.
Modellförbättringar. Nya öppna modeller når sluten kvalitet eller nya slutna modeller drar ifrån.
Operativ kapacitet. Teamets ML-/driftskompetens växer eller minskar.
Integritets- och efterlevnadskrav. Nya krav föreskriver egen drift.
En kvartalsvis kontroll är rimlig. Inte ständig omprövning, men inte heller ett engångsbeslut.
Vanliga misstag
Mönster vi ser i beslut om egen drift:
Misstag 1: kalkyl utan driftskostnad. ”Egen drift sparar 10 000 euro/månad” men 15 000 euro/månad i ingenjörstid ignoreras. Negativ avkastning.
Misstag 2: egen drift för tidigt. Ingenjörsarbete läggs på en liten arbetslast. Förtida optimering.
Misstag 3: frontlinjekvalitet från små öppna modeller. En mindre modell sparar pengar men kvaliteten sjunker och användarna klagar. Resultatet blir återgång till API:er.
Misstag 4: ingen reservlösning. Infrastrukturen går ned utan kontrollerad degradering. Ett avbrott som API-kunder inte hade fått.
Misstag 5: underinvestering i optimering. En 70B-modell körs på en GPU med 5 token/sekund när korrekt konfiguration ger 50. Merparten av värdet kastas bort.
Misstag 6: ignorerad kvalitetsdrift. Den egna modellen har halkat efter aktuella slutna modeller. Kunderna märker det, teamet gör det inte.
Misstag 7: ingen omprövning. Ett beslut som var rätt för två år sedan kan vara fel nu.
Misstag 8: spot-/avbrytbara instanser utan robust hantering. 60 % sparas på beräkning, men instanserna återtas och orsakar avbrott med några timmars mellanrum.
Beslutschecklista
För att fatta beslutet medvetet:
- Är API-utgiften för inferens minst 5 000–10 000 euro/månad?
- Är arbetslasten jämn och förutsägbar?
- Har teamet, eller kan det anställa, MLOps-/inferenskompetens?
- Finns en öppen modell med tillräcklig kvalitet?
- Är latenskraven förenliga med egen drift?
- Har en detaljerad kalkyl inklusive driftskostnader gjorts?
- Finns en reservplan?
- Föreskriver efterlevnads- eller integritetskrav inte en viss väg?
- Kommer beslutet att omprövas kvartalsvis?
Om merparten är ja är egen drift värd att överväga seriöst.
Hybridmönster
Det är inte allt eller inget. Många team kör hybrid:
Egen drift för volymen, API:er för svåra fall. Klassificering och enkel generering i egen drift; komplext resonemang via slutna API:er.
Egen drift för grundlast, API:er för toppar. Egen drift hanterar grundlasten och API:er absorberar topparna.
Egen drift för känsligt, API:er för allmänt. Känsliga data går internt och allmänna frågor via API:er.
Egen drift för finjusteringar, API:er för basmodeller. Anpassade modeller drivs internt och standardmodeller hämtas via API.
Hybrid tillför komplexitet men fångar ofta det bästa av båda. För team i skala är hybrid ofta rätt.
Slutsats
LLM-inferens i egen drift är fullt genomförbart 2026. Öppna modeller är konkurrenskraftiga, inferensservrarna mogna och maskinvaran tillgänglig.
Driftskostnaden är dock verklig och lätt att underskatta. Nollpunkten mot hanterade API:er ligger runt 5 000–10 000 euro i månatlig inferensutgift; under den nivån betalar sig inte ingenjörsinvesteringen.
Team som lyckas med egen drift:
- Har räknat ärligt, inklusive driftskostnad.
- Har eller kan bygga MLOps-kapacitet.
- Har tillräcklig skala.
- Har jämna arbetslaster.
- Behöver inte funktioner som enbart finns i slutna frontlinjemodeller.
- Planerar för tillförlitlighet, övervakning och uppdateringar.
Team som bör stanna på API:er:
- Har lägre skala.
- Har toppiga arbetslaster.
- Behöver snabb iteration.
- Är små och saknar driftkapacitet.
- Behöver slutna frontlinjefunktioner.
Rätt svar beror på situationen. Räkna noggrant och bedöm den operativa kapaciteten ärligt. Välj API:er som standard om inte egen drift vinner tydligt.
När egen drift vinner gör den det stort, både ekonomiskt och arkitekturellt. När den inte gör det är den ett dyrt sätt att upptäcka att hanterade API:er hela tiden var rätt val.
