Zelf een Open-Weight LLM Hosten vs. een API: De Echte Kostenwiskunde

Je product gaat live, het roept een LLM-API aan, en de rekening kruipt elke maand omhoog. Dus je doet wat elke bouwer uiteindelijk doet: je opent een nieuw tabblad en vraagt je af of het huren van een GPU en zelf Llama draaien goedkoper zou zijn.

De vraag over de kosten van zelf een LLM hosten heeft een antwoord, maar het is niet het enkele getal dat de topzoekresultaten en AI Overviews blijven herhalen. Het hangt af van drie dingen die die artikelen platslaan: tegen welke API je vergelijkt, hoe druk je GPU het heeft, en de operationele kosten die niemand in de spreadsheet zet.

Hier is de korte versie vóór de details: voor de meeste solo-bouwers wint zelf hosten momenteel niet op kosten. Maar er is een specifieke grens waar het omslaat, en die kun je op je eigen rekening in ongeveer twee minuten berekenen. Hieronder staat de wiskunde van 2026 (huidige prijzen, VRAM-getallen per model, en een formule die je kunt uitvoeren).

De korte versie

• Het break-evenpunt is niet één getal. Het zijn er drie, afhankelijk van tegen welke API je vergelijkt. Tegen een frontier-API (GPT-5.x, Claude Sonnet 5 / Opus 4.8, Gemini Pro) bereikt zelf hosten het snelst break-even. Tegen een budget open-weight API (DeepSeek, DeepInfra, Together tegen grofweg $0.14–$0.50 per miljoen tokens) wint het bijna nooit op kosten alleen.
• Bezettingsgraad is de vermenigvuldiger die de solo-case om zeep helpt. Een gehuurde GPU kost hetzelfde inactief als bij volle belasting, dus een GPU die op 10% bezetting draait kost per token grofweg 10× wat het bij volle belasting kost. Onregelmatige solo-workloads zitten standaard op lage bezetting.
• Onder het break-evenpunt is de kostenwinst meestal het overstappen naar een budget open-weight API, niet zelf hosten. Zelf hosten verdient zichzelf terug wanneer aanhoudend volume tegen frontier-prijzen de grens overschrijdt bij 60%+ bezetting, of wanneer je een niet-kostenreden hebt (privacy, latency, controle over fine-tuning).
• Voer de formule uit op je eigen getallen voordat je iets huurt. Break-even tokens ≈ maandkosten GPU VPS ÷ je gemengde API-prijs per token.

Wat Dit Niet Behandelt

• GPU-clusters op multi-node- of datacenterschaal. Dit is een solo-kostenbeslissing, geen vloot.
• De economie van fine-tuning in enige diepte (een aparte berekening met eigen afwegingen).
• Een stapsgewijze Ollama-vs-vLLM-installatietutorial. De reikwijdte hier is de geldkwestie, niet de installatie.
• Eigen hardware als je primaire vehikel. De aanname doorheen is een gehuurde GPU, aangezien dat het realistische pad is voor een bouwer zonder een GPU die al op een bureau staat.

Wat de Kosten Bepaalt (en Waar de Populaire Getallen de Mist Ingaan)

Zoek op "self host LLM vs API cost" en je belandt op een keurig break-evencijfer: iets als 11 miljard tokens per maand, of rond de $4,200 aan maandelijkse API-uitgaven, aangehaald door de kostenanalyse van braincuber en bijna woordelijk herhaald in het AI Overview bovenaan de pagina. Het is een net getal. Het is op zichzelf ook bijna nutteloos, omdat het de twee variabelen verbergt die je antwoord bepalen.

De reden dat dit glibberig is, is dat de twee kanten van de vergelijking verschillende kostenvormen hebben. Een API-rekening is een variabele kost: je betaalt per token, dus de rekening schaalt op en neer met hoeveel je hem gebruikt. Een gehuurde GPU is een vaste kost: je betaalt hetzelfde maandtarief of je er nu een miljard tokens doorheen duwt of hem inactief laat staan. Een variabele kost met één getal vergelijken met een vaste kost vereist dat je doet alsof je precies weet hoeveel tokens er zullen stromen, en op solo-schaal weet je dat meestal niet.

Dat laat drie hefbomen over die het break-evenpunt bewegen:

• Tegen welke API je vergelijkt. Een frontier-API en een budget open-weight API worden gescheiden door grofweg twee orden van grootte in prijs. Het break-evenpunt tegen elk is wild verschillend.
• Je GPU-bezetting. De vaste kost betaalt zich alleen terug als de GPU het druk heeft. Inactieve tijd is geld dat je voor niets uitgaf.
• De verborgen operationele kosten. Je uren, het verloop van modelupdates, en de VRAM-verrassingen die pas opduiken als je in productie zit.

Zet een prijs op elk daarvan en de mist trekt op. Dat is de rest van dit artikel.

Sectie-conclusie: het break-evenpunt is geen enkel getal. Het zijn drie getallen, één per API-tier, en het kiezen van de verkeerde tier om tegen te vergelijken is waar de meeste kostenschattingen de mist ingaan.

Het Drievoudige Break-Even: Frontier vs. Mid-Tier vs. Budget-API

Zelf een open-weight LLM hosten op een GPU VPS verslaat een frontier-API (GPT-5-klasse, Claude Sonnet 5 / Opus 4.8, Gemini Pro) bij grofweg een paar miljoen tokens per dag, mits je de GPU op een gezonde bezetting houdt (zeg 60% of hoger). Tegen een budget open-weight API rond $0.14–$0.50 per miljoen tokens wint het zelden op kosten. Dat verschil is het hele verhaal, en het is waarom één break-evengetal niet klopt.

Hier is de vorm ervan over de drie tiers. Behandel deze drempels als richtinggevende reeksen, niet als harde grenzen. Ze komen uit community-schattingen en 2026-prijzen, die beide snel bewegen.

Prijzen van de OpenAI, Anthropic, Google, DeepInfra, Together, en DeepSeek prijspagina's per July 2026. Elk van deze getallen heeft een houdbaarheid gemeten in maanden, dus controleer de huidige pagina's voordat je je vastlegt.

Nu het contraire punt, omdat het degene is die beslissingen verandert. Er gaat een luid en correct argument rond dat budget-API's het break-evenpunt van zelf hosten om zeep hebben geholpen. Open-weight API's zoals DeepInfra en Together serveren nu Llama- en Qwen-modellen tegen een fractie van de frontier-prijzen, en de frontier-prijzen zelf zijn sinds 2025 sterk gedaald. Tegen die budgettarieven loopt het break-evenpunt per token op tot in de miljarden tokens per maand. Een solo-ondernemer duwt geen miljarden tokens per maand. Dus als je enige doel een lagere rekening is, is de eerste zet meestal niet "een GPU huren", maar "overstappen naar een budget open-weight API en nul operationeel werk houden".

De kostenkant van zelf hosten overleeft op twee plekken: vergelijken tegen dure frontier-prijzen bij echt hoog, aanhoudend volume, en de niet-kostenredenen (privacy, latency, controle over fine-tuning) die verderop behandeld worden. Overal elders wint de budget-API het geldargument.

De Break-Even-Formule

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

Uitgewerkt voorbeeld, solo-ondernemersschaal: stel dat een enkele high-end GPU VPS ongeveer $1,000/maand kost (2026-catalogusbereik voor een top single-GPU-tier), en je zit op een frontier-API met een gemengd tarief rond $6 per miljoen tokens (grofweg $0.000006 per token). Dat is ~$1,000 ÷ $0.000006 ≈ 167 million tokens/maand voordat de GPU zichzelf op papier terugbetaalt. Doe het nu opnieuw tegen een budget open-weight API op $0.40 per miljoen ($0.0000004/token): ~$1,000 ÷ $0.0000004 = 2.5 miljard tokens/maand. Zelfde GPU, zelfde vaste kost, en het break-evenpunt verschuift met meer dan 10× puur afhankelijk van welke API je in de noemer zet. Dit is vóór bezetting, wat het getal nog erger maakt.

Sectie-conclusie: De API waar je tegen vergelijkt kan je break-evenpunt met 10× of meer bewegen, dus "de getallen doorrekenen" betekent ze doorrekenen tegen de specifieke API die je daadwerkelijk zou vervangen.

Wat Bezetting Doet met de Kosten per Token

Neem dat frontier-break-evenpunt van ~167 million tokens en voeg de variabele toe die de formule stilzwijgend wegneemt: je GPU heeft het de hele tijd druk. Dat is niet zo. Een gehuurde GPU rekent hetzelfde of hij nu verzadigd of inactief is, dus je effectieve GPU VPS LLM-kosten per token schalen omgekeerd evenredig met de bezetting. Draai op 10% belasting en elke token die je serveert draagt grofweg 10× de kosten die hij bij volle belasting zou dragen, omdat je betaalt voor de 90% capaciteit die je niet gebruikte. Community-schattingen en verslagen van praktijkmensen leggen de praktische ondergrens op rond 50–60% aanhoudende bezetting voordat de getallen ophouden je te beschamen (richtinggevende cijfers, geen labconstanten).

Voor een onregelmatige solo-workload (verkeer dat overdag piekt en 's nachts vlak ligt) is een aanhoudende 60% bezetting moeilijk te halen. Dat is de valkuil. Hier is wat het doet met de kosten per miljoen tokens over een paar concrete punten, met gebruik van 2026-catalogus-GPU-prijzen gedeeld door ruwe maandelijkse doorvoer bij elk bezettingsniveau:

De absolute centen-per-token hangen af van je model, kwantisering, en hoeveel gelijktijdige verzoeken je op de kaart kunt proppen, dus behandel de kolommen als tonend de vorm van de straf in plaats van een offerte. Het punt is de vermenigvuldiger: zak van volle belasting naar een kwart belasting en je kosten per token verviervoudigen ongeveer. Dat is meestal wat de solo-zelfhostingcase om zeep helpt, niet de stickerprijs van de GPU.

Er is één structurele ontsnappingsroute, en het is de reden waarom huren kopen kan verslaan bij grillige vraag: je kunt een gehuurde instance stoppen wanneer hij inactief is. Bezit de hardware en die schrijft af en trekt stroom of je hem gebruikt of niet. Bij rentals per uur of on-demand kun je de instance stoppen of afbreken wanneer de taak klaar is en betalen voor inactieve uren vermijden. Bij vaste maandplannen is de rekening nog steeds vast voor de facturatieperiode, dus bezetting blijft het belangrijkste kostenprobleem. Het lost geen workload op die de hele dag echt laag bezet is, maar voor vraag die druk is in pieken en dood ertussenin, is het vermogen om de meter uit te zetten de ene hefboom die rent-vs-own naar huren doet kantelen.

Sectie-conclusie: bezetting, niet de maandprijs van de GPU, is meestal wat beslist of zelf hosten uitkomt, en het is de variabele die de populaire break-evengetallen volledig weglaten.

Welk Model Past Bij Welke GPU: de VRAM-Realiteit

Het plan dat als eerste breekt is "ik draai gewoon een 70B op een 4090." Dat kan niet. Een 70B-model op Q4_K_M-kwantisering heeft grofweg 40–46 GB VRAM nodig, en een 24 GB RTX 4090 of een 32 GB RTX 5090 heeft simpelweg niet de ruimte. Forceer het op een 24 GB-kaart en je zakt naar Q2_K-kwantisering (rond 21 GB) met zichtbaar kwaliteitsverlies, of het model loopt over naar systeem-RAM en de generatiesnelheid stort in. VRAM is de harde muur die beslist welke modellen überhaupt op tafel liggen voor een gegeven GPU.

Hier is wat waar past. VRAM-cijfers zijn bij benadering: ze zijn afgeleid van de standaard bytes-per-parameter-rekenkunde (FP16 ≈ params × 2 met ~15% overhead; Q4_K_M ≈ params × ~0.55 met overhead), dus behandel ze als afmetingsrichtlijn, geen garantie.

VRAM-cijfers zijn gekruistcontroleerd tegen NVIDIA's officiële GPU-specificatiepagina's voor elke kaart. De A100 geeft een gekwantiseerde 70B comfortabelere speelruimte; RTX 6000 Ada kan werken voor krappere Q4-opstellingen, terwijl 24 GB- en 32 GB-consumentenkaarten niet genoeg VRAM hebben voor een normale 70B Q4-deployment. Als je de volledige uitleg wilt van hoe GGUF-, GPTQ-, AWQ- en EXL2-formaten geheugen verbruiken, dat is een konijnenhol dat een eigen leesbeurt waard is: GGUF, GPTQ, AWQ, EXL2: hoe LLM-kwantiseringsformaten geheugen echt gebruiken.

Het community-favoriet voor een enkele 24 GB-kaart is een 24B-tot-32B-model (Mistral Small 3.1 of Qwen 3 32B op Q4). Dat is de omvang die een solo-bouwer een bruikbaar model geeft op de goedkoopste GPU-tier zonder de hele weg met VRAM te vechten. Als je afweegt welke kaart je überhaupt zou huren, vergelijkt onze H100 vs RTX 4090-benchmark voor AI-workloads de tiers op doorvoer.

De Verborgen Kosten Die de Naïeve Besparingen Wegvagen

De spreadsheet die zegt dat zelf hosten goedkoper is heeft bijna altijd één regel: de maandprijs van de GPU. De rekening die je betaalt heeft meer regels. Er is je tijd (elk uur dat je besteedt aan patchen, het herstarten van een vastgelopen inference-server, of het najagen van een out-of-memory-crash is een uur dat je niet aan het product besteedde). Er is het verloop van modelupdates: het open-weight-model dat je uitrolde wordt vervangen, en her-benchmarken en her-uitrollen is terugkerend werk, geen eenmalige inrichting. Er is de VRAM- en KV-cache-verrassing uit de vorige sectie. En er is inactieve verspilling, de uren dat de GPU zit te factureren terwijl er niets draait.

Praktijkmensen die deze getallen hebben opgeteld leggen de werkelijke kosten op grofweg 1.3–2× de kale GPU-prijs zodra operationele tijd is meegeteld, en sommigen gaan hoger, naar 3–5×, op rommeligere opstellingen. Dat zijn richtinggevende vermenigvuldigers uit community-verslagen, geen gecontroleerde cijfers, maar de richting is het punt. Zoals één veelgeciteerde formulering het zegt: een inactieve GPU is geen bezit, het is een verplichting die per uur wordt gefactureerd. Voor een solo-bouwer is de juiste manier om dit te prijzen geen MLOps-salarisregel, het zijn je eigen uren, die het schaarste zijn dat je hebt. Als zelf hosten je op papier $200 per maand bespaart maar je zes uur operationeel werk kost dat je anders aan uitleveren zou besteden, is dat niet duidelijk een winst.

Wanneer Zelf Hosten Toch Wint: Privacy, Latency en Fine-Tuning

Kosten zijn niet de enige reden om je eigen model te draaien, en voor sommige bouwers zelfs niet de belangrijkste. Onder het kosten-break-evenpunt, waar het geld zegt "blijf op de API", zijn er drie redenen om toch zelf te hosten. Datasoevereiniteit: de prompts en data van je gebruikers buiten de pipeline van een externe AI-provider houden, wat voor sommige producten uitmaakt ongeacht wat de getallen zeggen. Voorspelbare latency: geen wachtrij met gedeelde tenants, geen rate limits die je niet zelf hebt ingesteld, geen onverwachte vertragingen tijdens de verkeerspiek van iemand anders. En volledige controle: de vrijheid om te fine-tunen, kwantiseren, modellen te wisselen en versies vast te pinnen zonder op een leverancier te wachten.

Er is een kanttekening bij het privacypunt, en het overslaan zou oneerlijk zijn. Een gehuurde GPU VPS draait nog steeds op andermans hardware in andermans datacenter. Dat is betekenisvolle soevereiniteit ten opzichte van de trainings- en logging-pipeline van de AI-provider (je prompts stromen niet door de systemen van een modelleverancier), maar het is niet hetzelfde als on-premises apparatuur die je fysiek beheert. Als je vereiste echte on-prem-isolatie is, brengt een gehuurde VPS je daar niet. Als je vereiste is "houd onze data uit handen van een externe modelleverancier", dan wel. Weet welke van de twee je nodig hebt.

Voor workloads die draaien in beperkende netwerkomgevingen kan een zelfgehost model op infrastructuur die je beheert ook afhankelijkheden van externe endpoints omzeilen die mogelijk onbereikbaar zijn, een mogelijkheid die er onafhankelijk toe doet van waar je het uitrolt.

Dus Zou Je Zelf Moeten Hosten? Een Rechtstreeks Antwoord per Situatie

Alles hierboven sorteert zich in een korte beslissing. Je hebt een rekening, een ruw gevoel van je maandelijkse token-volume, en nu de drie break-eventiers, de bezettingsstraf en de verborgen-kostenvermenigvuldiger. Koppel je situatie aan een van deze:

• Je zit onder het frontier-break-evenpunt en kosten zijn je enige zorg. Blijf op een API, en prijs serieus een budget open-weight API (DeepSeek, DeepInfra, Together) voordat je iets anders doet. Dat is meestal de kostenwinst, niet zelf hosten. API's wisselen is een configuratiewijziging; zelf hosten is een tweede baan.
• Je hebt aanhoudend, hoog volume tegen frontier-prijzen en kunt een GPU op 60%+ bezetting houden. Dit is waar zelf hosten zich terugbetaalt. Voer de formule uit tegen je frontier-tarief, bevestig dat je de drempel overschrijdt met aanhoudende bezetting (niet piek), en een gehuurde GPU VPS begint te winnen.
• Je hebt een niet-kostendrijver: privacy, latency of controle over fine-tuning. Host bewust zelf onder het break-evenpunt, met open ogen dat je betaalt voor de controle. Vertel jezelf alleen niet dat het goedkoper is als dat niet zo is.
• Je zit ertussenin. Kijk naar het hybride patroon waar de meeste praktijkmensen in 2026 op uitkomen: een klein zelfgehost model voor hoogvolume, simpele taken, plus een frontier-API voor het harde redeneren waar je lokale model 85–90% van de weg naartoe komt (community-benchmarks, niet lab-geverifieerd, en het laatste stuk is vaak waar je de kwaliteit het meest nodig hebt).

Op de vraag "hoe kom ik aan de GPU" is het antwoord voor een solo-bouwer bijna altijd huren, niet kopen. Datacentergrade-hardware bezitten is een capex-gok die alleen zin heeft op een schaal die je nog niet hebt. Serverless inference kan inactieve verspilling verminderen door naar nul te schalen en alleen te factureren voor actieve compute, maar het ruilt dat vaak in voor een hoger tarief per GPU-uur en cold-start-latency. Een gehuurde GPU VPS zit in het midden: geen capex, een voorspelbare maandrekening, root-toegang, en het vermogen om de instance te stoppen wanneer hij inactief is.

Als je de formule hebt uitgevoerd, het break-evenpunt hebt overschreden, en een dedicated, private inference-server met root-toegang wilt zonder een kaart te kopen, dan is dat precies waar een gehuurde GPU-box voor is. Cloudzy's GPU VPS-plannen dekken het bereik van een 8B-model op een enkele kaart tot een gekwantiseerde 70B, en de één-klik Ollama-app in de marketplace rolt in ongeveer een minuut uit met een REST API die compatibel is met OpenAI-clients, dus de overstap van een betaalde API naar je eigen server kan bijna een drop-in-verandering in je code zijn, zonder kosten per token na de vaste maandelijkse vergoeding. Controleer de pagina voor actuele prijzen; GPU-tarieven bewegen.

De ene actie die het waard is om te ondernemen voordat je iets huurt: voer de break-evenformule uit op je eigen rekening. Het kost twee minuten en het vertelt je in welke van de vier situaties hierboven je zit.

Veelgestelde vragen

Is Het Goedkoper om een LLM Zelf te Hosten of een API te Gebruiken?

Het hangt af van welke API. Zelf een open-weight-model hosten op een GPU VPS kan een frontier-API (GPT-5-klasse, Claude Sonnet 5 / Opus 4.8) verslaan bij hoog, aanhoudend volume met goede GPU-bezetting. Het verslaat zelden een budget open-weight API (DeepSeek, DeepInfra, Together tegen grofweg $0.14–$0.50 per miljoen tokens per July 2026) op kosten alleen: dat break-evenpunt loopt op tot in de miljarden tokens per maand, wat de meeste solo-bouwers nooit bereiken.

Welke GPU Heb Ik Nodig om een 70B-Model te Draaien?

Een 70B-model op Q4_K_M-kwantisering heeft grofweg 40–46 GB VRAM nodig alleen al voor de gekwantiseerde gewichten. Een 80 GB A100 is de veiligere single-GPU-optie omdat die ruimte laat voor KV cache, runtime-overhead en langere prompts. Een 48 GB RTX 6000 Ada kan werken voor krappere Q4-opstellingen, maar contextlengte en concurrency moeten zorgvuldig beheerd worden.

Hoe Beïnvloedt GPU-Bezetting de Kosten per Token?

Een gehuurde GPU kost hetzelfde of hij nu inactief of volledig belast is, dus je effectieve kosten per token schalen omgekeerd evenredig met de bezetting. Bij 10% belasting kost elke token die je serveert grofweg 10× wat hij bij volle belasting zou kosten, omdat je betaalt voor de ongebruikte capaciteit. De praktische ondergrens waarbij zelf hosten zin heeft is rond 50–60% aanhoudende bezetting.

Hoeveel Tokens per Maand Voordat Zelf Hosten de Moeite Waard Is?

Tegen een frontier-API is grofweg 160–256 miljoen tokens per maand bij gezonde bezetting de richtinggevende drempel (per July 2026). Tegen een budget open-weight API is het miljarden per maand, in de praktijk onbereikbaar solo. Het exacte getal hangt af van je GPU-kosten en gemengde API-tarief, dus voer de formule uit: break-even tokens ≈ maandkosten GPU VPS ÷ je API-prijs per token, en verdisconteer dat dan voor aanhoudende bezetting.

Kan Ik een Open-Weight LLM op een VPS Draaien?

Ja, op een GPU VPS afgestemd op de VRAM van het model. Een tool zoals Ollama draait open-weight-modellen (Llama, Qwen, Mistral en andere) met een één-klik-deploy en een OpenAI-compatible REST API, dus je bestaande API-aanroepende code kan met minimale wijzigingen naar je eigen server wijzen. Stem de GPU-tier af op je model: een 8B past comfortabel op een 24 GB-kaart, een gekwantiseerde 70B heeft 48–80 GB nodig.