De GPU-breakevenlijn: wanneer een zelf gehost vLLM-cluster de LLM-API-rekening verslaat

Je API-rekening groeit in perfecte tred met je succes. Elke nieuwe klant voegt tokens toe, elke token voegt kosten toe, en het hele bedrag belandt elke maand in je cost of goods sold. Bij een bepaald volume kruist die verbruiksfactuur een grens: de GPU's zelf kopen en inferentie in eigen beheer draaien wordt goedkoper dan die van iemand anders huren. De vraag is waar die grens voor jou ligt — want het overschrijden ervan is niet alleen een technische beslissing. Het herschrijft je balans, je brutomarge en je belastingaangifte.

Deze gids loopt door de breakevenberekening, waarom de vLLM-servingstack de grens heeft verlegd, en wat er op je boeken verandert op de dag dat je stopt met het als kosten boeken van API-aanroepen en begint met het activeren van een GPU-cluster.

Twee manieren om voor inferentie te betalen​

Elke token die je product serveert, wordt op een van twee manieren betaald, en ze raken je financiën volledig anders.

Het API-pad is pure operationele kost. Je betaalt per miljoen tokens, de rekening schaalt met het gebruik, en het volledige bedrag is een periodekost — het meest natuurlijk geboekt als cost of goods sold, aangezien inferentie direct verbonden is met het leveren van je product aan klanten. Nul vooraf, nul activa, nul afschrijving. Je brutomarge krijgt elke maand een klap tegen een constant tarief, hoe groot je ook wordt.

Het zelf-gehoste pad is grotendeels kapitaaluitgave. Je koopt GPU-servers (of sluit een langlopende reservering), zet een vast actief op de balans, en schrijft het af over de gebruiksduur. Je maandelijkse resultatenrekening toont dan afschrijving plus operationele kosten — elektriciteit, colocatie of rackruimte, monitoring, en de engineeringuren om het cluster gezond te houden — in plaats van een rekening per token.

Dat structurele verschil is het hele spel. API-kosten schalen lineair met volume, voor altijd. Zelf-gehoste kosten zijn vooraf gefinancierd en grotendeels vast, dus de effectieve kosten per token dalen naarmate de bezettingsgraad stijgt. Ergens kruisen die twee curven elkaar. Alles hieronder gaat over het vinden van waar.

De breakevenberekening​

Een veel geciteerde analyse uit 2026 van meer dan 50 productie-implementaties zette de vuistregel op ongeveer $20.000 per maand aan API-uitgaven. Daaronder overtreft de engineering- en operationele kost van het runnen van je eigen cluster bijna altijd de besparingen. Boven $50.000 per maand wint zelf hosten van het grootste deel van het verkeer doorgaans met 50 tot 70 procent. Tussen die lijnen ligt een grijze zone waar de details — je modellen, de vorm van je verkeer, de GPU-ervaring van je team — de beslissing bepalen.

Dezelfde analyse schetste de investering achter die cijfers: $50.000 tot $500.000 vooraf voor GPU-hardware, afhankelijk van de modelgrootte, plus $3.000 tot $15.000 per maand aan doorlopende operationele kosten. Dat loopt van een enkele gebruikte A100-klasse machine die een model met 70 miljard parameters serveert tot een multi-node H100-cluster.

Het maakt enorm uit welke API je vervangt​

Het breakevenvolume verschuift met ongeveer een factor 100, afhankelijk van wat je vandaag per token betaalt:

Tegen een premium frontier-API die in de orde van $1.750 per 100 miljoen tokens rekent, ligt het omslagpunt rond een half miljard tot een miljard tokens per maand, en de terugverdientijd versnelt hard vanaf daar.

Maar vervang een budget-API die dichter bij $80 per 100 miljoen tokens rekent, en de berekening keert om: je zou 50 miljard-plus tokens per maand nodig hebben om break-even te draaien — een volume dat een serieus multi-GPU-cluster en een toegewijd infrastructuurteam vereist. Als een goedkope API aan je kwaliteitslat voldoet, is zelf hosten financieel zelden zinvol bij welk volume een klein bedrijf ook zal bereiken.

Bezettingsgraad is alles​

Andere kostenanalyses plaatsen het breakevenpunt veel lager — één gedetailleerd build-vs-rent-model zet het op ongeveer $4.200 per maand aan API-uitgaven — en de kloof tussen de schattingen is zelf de les: er bestaat geen universeel breakevenpunt. De hele berekening hangt af van de bezettingsgraad. Een GPU die continu stabiel verkeer serveert, spreidt de vaste kost over miljarden tokens. Dezelfde GPU die piekerig dagverkeer serveert, staat de hele nacht stil, schrijft af zonder iets op te leveren, en de stille uren verdubbelen of verdrievoudigen geruisloos je werkelijke kost per token.

Voordat je iemands breakevencijfer vertrouwt, inclusief dat van dit artikel, meet je eigen verkeersvorm: aanhoudende tokens per seconde, piek-tot-gemiddelde-verhouding, en groeisnelheid. Vlak, voorspelbaar, groeiend volume pleit voor zelf hosten. Piekerig of laag volume pleit voor de nul stilkosten van de API.

Waarom vLLM de grens heeft verlegd​

De servingstack die je kiest is een financiële variabele, niet alleen een technische. Doorvoer per GPU bepaalt hoeveel GPU's je moet kopen, en de spreiding tussen een naïeve servingloop en een moderne inferentie-engine is enorm.

vLLM is de standaard productiekeuze geworden door twee technieken die out of the box ingeschakeld zijn:

• Continuous batching houdt elke GPU-slot gevuld door nieuwe en lopende verzoeken te mengen in plaats van te wachten tot een hele batch klaar is, wat de doorvoer met ruwweg een factor 2 tot 3 verhoogt ten opzichte van statische batching.
• PagedAttention beheert de key-value-cache in blokken in plaats van aaneengesloten geheugen vooraf toe te wijzen, wat fragmentatieverspilling vermindert en 2 tot 4 keer meer gelijktijdige verzoeken op dezelfde kaart ondersteunt.

Gecombineerd met tensor-parallelisme over GPU's en ondersteuning voor gekwantiseerde gewichten levert vLLM in de orde van 24 keer de doorvoer van een naïeve transformers-servingloop — wat betekent dat je ruwweg 24 keer minder GPU's hoeft te kopen voor hetzelfde verkeer. Een cluster dat zonder deze technieken is gedimensioneerd is niet alleen langzamer; het is een kapitaaluitgavefout.

Twee eigenschappen doen er nog toe voor de businesscase. Ten eerste: vLLM biedt OpenAI-compatibele endpoints, dus het migreren van bulkverkeer weg van een API is grotendeels een URL- en sleutelwijziging in plaats van een herschrijving — de overstapkost blijft laag. Ten tweede de beperking: je kunt alleen open-weight-modellen zoals Llama, Qwen, DeepSeek en Mistral zelf hosten. Frontier-modellen van de grote labs blijven API-only, wat verklaart waarom de gangbare eindtoestand een hybride is: host zelf een open model voor de 80 procent van het verkeer dat routinematig is, en blijf de 20 procent die frontier-redenering nodig heeft via een API routeren.

Wat er op je boeken verandert wanneer je zelf host​

Op de dag dat de GPU-servers aankomen, verandert je boekhouding op vijf plekken. Doe deze goed en de breakevenberekening die je hebt gemaakt, komt daadwerkelijk tot uiting in je financiën.

1. De hardware wordt een vast actief​

Gekochte GPU-servers zijn kapitaalgoederen, geen verbruiksartikelen. Je boekt de aankoopprijs plus de directe kosten om het cluster in dienst te stellen — vracht, rackinstallatie, initiële configuratie-arbeid — als een vast actief op de balans, en schrijft het vervolgens af. Computers en gerelateerde apparatuur zijn doorgaans 5-jaars MACRS-eigendom, en afschrijving begint wanneer het actief in dienst wordt gesteld (klaar en beschikbaar voor het beoogde gebruik), niet wanneer je de factuur betaalt.

De de-minimis-safe-harbor van $2.500 waarmee je kleine aankopen als kosten kunt boeken, dekt geen GPU-server. Laat een cluster van $60.000 niet via kantoorbenodigdheden lopen.

2. Je krijgt in 2026 een echte fiscale timingkeuze​

Voor federale belastingen geeft de huidige wet je drie snelheden voor dezelfde hardware:

• Section 179-aftrek: trek tot $2.560.000 aan in aanmerking komend apparatuur dat in 2026 in dienst is gesteld af, waarbij het voordeel dollar-voor-dollar afbouwt zodra de totale in aanmerking komende aankopen $4.090.000 overschrijden. De aftrek mag je belastbare bedrijfswinst niet overschrijden, maar ongebruikte bedragen worden overgedragen.
• 100 procent bonusafschrijving: permanent hersteld voor in aanmerking komend eigendom verworven na 19 januari 2025. Anders dan Section 179 kan het een verlies creëren en er is geen dollargrens.
• Reguliere MACRS: spreid de aftrek over 5 jaar.

Een winstgevend klein bedrijf dat zijn eerste cluster koopt, boekt vaak het hele bedrag in jaar één als kosten af. Een startup vóór winstgevendheid verkiest mogelijk MACRS, om aftrekken te bewaren voor jaren waarin er inkomen is om te verrekenen. Hoe dan ook: houd boek- en fiscale afschrijving apart — je financiële overzichten moeten de economische werkelijkheid over de gebruiksduur van het actief weerspiegelen, zelfs wanneer de belastingaangifte het allemaal in één keer neemt.

3. Gehuurde GPU's blijven operationele kost​

Niets van het bovenstaande geldt als je cloud-GPU's per uur huurt. Uurverhuur, reserved instances en GPU-cloudabonnementen zijn operationele periodekosten — dichter bij het API-pad dan bij eigendom. Dat is een legitiem tussenpad (geen voorafgaand kapitaal, nog steeds verbruiksgemeten), maar verwacht geen balansactief of afschrijvingsaftrek van een huurrekening. De CapEx-vs-OpEx-beslissing en de build-vs-buy-beslissing zijn twee afzonderlijke assen.

4. Doorlopende clusterkosten splitsen tussen COGS en OpEx​

Classificeer kosten zodra ze lopen op basis van wat ze ondersteunen:

• Naar COGS (ze schalen met het serveren van klanten): elektriciteit voor productie-nodes, colocatie en bandbreedte voor het servingcluster, monitoring en logging voor productie, en de afschrijving op productie-GPU's.
• Naar operationele kosten: de prototype-machine waarop je engineers experimenteren, staging-omgevingen, en algemene R&D-infrastructuur.

Dezelfde splitsing geldt voor arbeid. Engineeringtijd besteed aan het in de lucht houden van productie-inferentie ondersteunt de levering en kan in COGS zitten; tijd besteed aan het evalueren van het model van volgend kwartaal is R&D. SaaS-brutomarges worden doorgaans gebenchmarkt op 70 tot 85 procent, en verkeerde classificatie in beide richtingen maakt je marge onvergelijkbaar — stop API- en hostinguitgaven in overhead en je marge ziet er kunstmatig prachtig uit terwijl je OpEx opgeblazen lijkt.

5. Je brutomarge zou moeten uitzetten voorbij breakeven​

Let maandelijks op deze identiteit na de migratie: de API-regel in COGS zou naar nul moeten dalen (of naar de 20 procent frontier-rest in een hybride opzet), vervangen door een kleinere gecombineerde afschrijvings-plus-hostingpost. Als de brutomarge niet binnen een kwartaal of twee na steady-state werking verbetert, is óf de bezettingsgraad lager dan gemodelleerd óf verborgen operationele kosten hebben de besparingen opgegeten — wat je signaal is om de beslissing te herzien in plaats van te verdedigen.

In een plain-text-grootboek is de aankoop zelf één gebalanceerde boeking — een activaruil van cash naar apparatuur, met afschrijvingsboekingen die de kost maand na maand erkennen. Als je nooit vaste activa op deze manier hebt gemodelleerd, loopt de Beancount-documentatie stap voor stap door rekeningen, afschrijvingsboekingen en rapporten.

Fouten die de besparingen wissen​

De meeste mislukte self-hosting-migraties falen niet op GPU-benchmarks. Ze falen op kosten die de spreadsheet wegliet:

Dimensioneren voor de piek, betalen voor het gemiddelde. Een cluster ingericht voor je drukste uur draait de rest van de dag half leeg. Elk stil uur is afschrijving zonder tokens. Autoscaling helpt bij gehuurde GPU's; bij eigen hardware is het enige verweer genoeg basisvolume.

De operationele staart vergeten. Eén gedetailleerde uiteenzetting zet verborgen maandelijkse kosten op $4.700 tot $7.900 bovenop de hardware voor een bescheiden 4-GPU-opstelling: 8 tot 20 engineeringuren per maand ($2.500 tot $5.000 bij belaste salarissen), elektriciteit ($400 tot $600), netwerk en opslag, monitoring, en een redundantie-reserve. Niets daarvan verschijnt in een GPU-prijsvergelijking.

De uptimekloof negeren. API-providers garanderen doorgaans 99,9 procent SLA-uptime. Een zelfgedraaid cluster zonder serieuze redundantie-investering komt realistisch op 95 tot 99 procent — defecte kaarten, out-of-memory-crashes, een CUDA-driverupdate die om 2 uur 's nachts de implementatie breekt. Op $100.000 per maand aan AI-gedreven omzet kost één extra punt downtime $1.000 per maand, nog voordat je de incidentrespons meetelt.

API-uitgaven als overhead boeken. Als inferentiekosten in algemene kosten zitten in plaats van COGS, is je brutomarge fictie in beide richtingen: te hoog vóór migratie, en de verbetering na migratie onzichtbaar. Repareer de classificatie voordat je vergelijkt.

Optimisme over de gebruiksduur. Sommige hyperscalers schrijven GPU's af over 5 tot 6 jaar, terwijl analisten betogen dat de economische levensduur dichter bij 2 tot 3 jaar ligt, gezien hoe snel elke generatie de vorige achterhaald maakt. Als de restwaarde van je cluster instort wanneer de volgende architectuur uitkomt, boek dan een impairment in plaats van een fantasieactief te dragen.

Prototype-uitgaven vermengen met productie. De GPU die je kocht om fine-tuning te evalueren is R&D. Het cluster dat klantverkeer serveert is productie. Ze in één rekening mengen corrumpeert zowel je brutomarge als je onderbouwing voor de R&D-credit.

Een beslis-checklist voordat je koopt​

Loop deze zes vragen door met echte cijfers, niet met onderbuikgevoel:

1. Volume: Ligt de aanhoudende maandelijkse API-uitgave boven ruwweg $20.000, of gaat die daar geloofwaardig binnen twee kwartalen naartoe?
2. Welke API vervang je? Premium frontier-prijzen breken zelfs rond een miljard tokens per maand; budget-API-prijzen breken mogelijk nooit zelfs.
3. Verkeersvorm: Is de belasting vlak genoeg dat GPU's bezet blijven, of zullen piekprovisioneringen capaciteit strand laten liggen?
4. Expertise: Spreekt iemand in het team al CUDA, kwantisatie en vLLM-tuning — of begroot je een aanwerving in de terugverdienberekening?
5. Cash en belastingen: Kun je het voorafgaande kapitaal financieren, en heb je het inkomen om een Section 179- of bonusaftrek te gebruiken — of zou MACRS je beter dienen?
6. Niet-financiële drijfveren: Dwingen privacy-, compliance- of sub-100ms-latentie-eisen je om zelf te hosten, ongeacht de kosten?

Drie of meer zwakke antwoorden betekent voorlopig op de API (of de hybride splitsing) blijven. De lijn zal er nog zijn wanneer je volume erin groeit — en tegen die tijd zal de volgende GPU-generatie hem in jouw voordeel hebben verlegd.

Houd je inferentie-uitgaven leesbaar​

Of je nu per token of per afschrijvingsschema betaalt, inferentie is nu een van je grootste kostenposten, en die verdient beter dan één mysterieus totaal op de resultatenrekening. API-uitgaven scheiden van hosting, productie-GPU's van prototype-machines, en boekafschrijving van fiscale afschrijving is wat de breakevenlijn verandert van een eenmalige berekening in een cijfer dat je elke maand kunt volgen.

Beancount.io biedt plain-text boekhouding die je volledige transparantie en controle over je financiële gegevens geeft — geen black boxes, geen vendor lock-in. Volg het cluster als vast actief, boek afschrijving volgens schema, en zie het door je rapporten stromen in Fava. Begin gratis en houd je AI-infrastructuuruitgaven even leesbaar als je infrastructuurcode.