On-Premise vs Cloud LLM TCO Calculator

Door Ivo Donker — samengesteld met AI-ondersteuning · Laatst bijgewerkt: 7 augustus 2026

Kostenvergelijking Cloud-API's versus Eigen Infrastructuur voor LLM's

Bij het uitrollen van applicaties op basis van grote taalmodellen (Large Language Models of LLM's) staan technische teams en IT-beslissers voor de keuze tussen public cloud-API's en het beheren van eigen hardware on-premise of in een datacenter. Waar een startende uitrol vrijwel altijd begint met direct toegankelijke API-eindpunten van externe leveranciers, verandert deze afweging wanneer het tokenvolume groeit of wanneer strikte eisen aan datalocatie en vertrouwelijkheid gelden. Het vergelijken van beide scenario's vereist echter meer dan een eenvoudige vergelijking tussen het maandelijkse API-factuurbedrag en de aanschafprijs van een server.

Een voldragen vergelijking rust op het concept van de Total Cost of Ownership (TCO) over een bedrijfskritische horizon, typisch drie jaar. Hierin worden directe aanschafkosten, operationele ondersteuning, infrastructuurlasten en bezettingsrisico's samengebracht. Om de financiële impact van deze systeemarchitectuur te evalueren, helpt het de onderliggende financiële dynamically te ontleden. Voor een gedetailleerde weergave van de vereisten waaraan een eigen datacenter-omgeving moet voldoen, kan de lezer de gids over on-premise LLM-infrastructuureisen raadplegen om te bepalen of de benodigde fysieke faciliteiten aanwezig zijn.

In dit artikel worden de afzonderlijke kostencomponenten van zowel cloud- als on-premise scenario's ontleed. Vervolgens wordt ingegaan op de rekenmethodiek die wordt gebruikt in de interactieve client-side calculator op deze pagina, inclusief de randvoorwaarden om een eerlijke vergelijking te waarborgen. Tot slot biedt het artikel een gestructureerde checklist waarmee een organisatie de eigen TCO-matrix kan samenstellen zonder externe consultancy-inhuur.

De Kostenposten van Cloud-LLM-API's

Het financiële model van cloud-API's kenmerkt zich door een variabele kostenstructuur op basis van daadwerkelijk verbruik (OpEx). Hoewel dit model lage instaptarieven biedt en geen voorafgaande kapitaalinvesteringen vereist, brengt de opschaling specifieke kostenrisico's met zich mee die nauwgezet begroot moeten worden. Wie een financieel framework wil opzetten voor deze variabele uitgaven vindt verdere verdieping in het overzicht over budgetteren voor AI-applicaties.

De belangrijkste elementen binnen de cloud-TCO zijn:

• Input- en Output-tokenvolume: Leveranciers brengen gescheiden tarieven in rekening voor verwerkte invoertekst en gegenereerde uitvoertekst. Omdat generatie (output) meer rekenkracht vereist, ligt de prijs per duizend of miljoen tokens voor output significant hoger dan voor input. Het exacte verloop van deze kosten is afhankelijk van het type model dat wordt aangeroepen; lezers die de specifieke opbouw van deze tarieven willen analyseren kunnen terecht bij de uitleg over prijsmodellen per token.
• Groeiscenario's en Piekbelasting: Een statische berekening op basis van het huidige maandvolume geeft een vertekend beeld. Bij het opstellen van een driejarige TCO dient rekening te worden gehouden met een maandelijks of jaarlijks groeipercentage van het query-volume, evenals piekbelastingen waarin tijdelijk extra capaciteit nodig is.
• SLA's, Dedicated Endpoints en Provisioned Throughput: Bij grote volumes bieden standaard gedeelde API-eindpunten vaak onvoldoende garanties voor latency en beschikbaarheid. Leveranciers bieden voor die situaties 'provisioned throughput' of gereserveerde instanties aan. Hierbij vervalt het zuivere verbruiksmodel en betaalt de organisatie een vast bedrag per uur of per maand voor gegarandeerde verwerkingscapaciteit, ongeacht of deze volledig wordt benut.
• Netwerk, Datatransfer en Egress: Het verzenden van grote hoeveelheden data naar externe cloud-providers brengt netwerkkosten met zich mee. Hoewel ingress (inkomend verkeer naar de cloud) vaak kosteloos is, kunnen er bij intensief gebruik van embeddings of context-heavy responssystemen kosten ontstaan voor data-overdracht en netwerkbeveiliging (zoals private endpoints of VPN-verbindingen).
• Beheer en Integratie: Hoewel de infrastructuur door de provider wordt onderhouden, vraagt een cloud-architectuur om beheeruren voor sleutelbeheer, monitoring van rate limits, kostenbewaking (budget alerts), API-versiebeheer en de implementatie van fallback-mechanismen voor het opvangen van uitval.

De Kostenposten van On-Premise en Private Hardware

Het overstappen naar eigen hardware verschuift de kostenstructuur primair naar kapitaaluitgaven (CapEx), aangevuld met een terugkerende operationele component. Een veelgemaakte fout bij vergelijkingen is het enkel meenemen van de aanschafwaarde van de rekenkaarten (versnellers) en servers. Om een getrouw TCO-beeld te krijgen over een periode van 36 maanden, moeten alle fysieke en organisatorische randvoorwaarden worden gekwantificeerd.

Raadpleeg voor een uitgebreide technische specificatie van de benodigde rekenonderdelen de handleiding over hardware voor lokale LLM-systemen. Een volledige TCO-berekening omvat de volgende onderdelen:

1. Directe Hardware-investering (CapEx)

Dit betreft de aanschaf van rekennodes, gespecialiseerde versnellers met voldoende geheugenbandbreedte (VRAM), enterprise-processors, systeemgeheugen, snelle NVMe-opslag voor het inladen van weights, en redundant uitgevoerde voedingen. Ook de netwerk-interconnects (zoals 100GbE+ of specifieke fabric-switches) die nodig zijn om meerdere nodes aan elkaar te koppelen voor grotere modellen vallen onder deze post.

2. Huisvesting, Stroom en Koeling

Hardware voor AI-werklasten kent een hoge energiedichtheid per rack-unit. De operationele kosten voor energie zijn opgebouwd uit het continue stroomverbruik van de rekennodes onder belasting (en in ruststand) vermenigvuldigd met de Power Usage Effectiveness (PUE) van het datacenter. De PUE-factor verrekenent de energie die nodig is voor koeling en secundaire faciliteiten. Een analyse van de fysieke energielasten en warmte-afvoer is te vinden in het overzicht van het stroomverbruik bij lokale AI-systemen.

3. Afschrijving en Onderhoudscontracten

Hardware kent een beperkte economische en technische levensduur. Binnen de driejarige TCO wordt de aanschafwaarde lineair afgeschreven (meestal 33,3% per jaar). Daarnaast vereist enterprise-hardware uitgebreide garanties en supportcontracten (bijvoorbeeld 4-uurs on-site hardwarevervanging door de leverancier), wat op jaarbasis een vast percentage van de oorspronkelijke aanschafwaarde bedraagt.

4. Datacenter-ruimte en Rack-rent

Of de apparatuur nu in een eigen ruimte staat of in een colocation-datacenter wordt geplaatst, er zijn vaste kosten verbonden aan de fysieke footprint: het aantal rack-units (U) of hele racks, inclusief redundante feeds (A+B stroomvoorziening) en fysieke toegangsbeveiliging.

5. Beheer, Personeel en System Engineering

Een on-premise AI-stack vereist continue personele ondersteuning. Denk hierbij aan het inrichten en onderhouden van de fysieke nodes, de virtualization- of containerlaag (zoals Kubernetes met GPU-operators), drivers, orchestration-software, monitoring en beveiligingsupdates. Deze uren moeten tegen een realistisch intern of extern uurtarief worden meegenomen in de berekening.

6. Het Risico op Onbenutte Capaciteit (Capacity Underutilization)

In tegenstelling tot cloud-API's, waarbij alleen voor het daadwerkelijke verbruik wordt betaald (bij pay-as-you-go), kost een eigen server evenveel aan afschrijving en rack-huur ongeacht of de bezettingsgraad 10% of 90% is. Wanneer de capaciteit niet optimaal wordt benut, stijgen de effectieve kosten per verwerkt token drastisch.

Methodiek van een Eerlijke TCO-Vergelijking

Om een valide vergelijking tussen cloud en on-premise te maken, moeten beide scenario's aan exact dezelfde randvoorwaarden worden onderworpen. Een vergelijking gaat mank wanneer een krachtig cloudmodel wordt vergeleken met een lokaal model dat niet aan de minimale nauwkeurigheidseisen van de business-case voldoet, of wanneer uitvalrisico's in één van de twee scenario's worden genegeerd.

Voor een correcte vergelijkende analyse dienen de volgende drie principes gehanteerd te worden:

1. Gelijkwaardig Tokenvolume en Kwaliteit: Er moet uitgegaan worden van hetzelfde verwachte input- en outputvolume. Daarnaast moet het lokale model, qua parametergrootte en kwantisatie, in staat zijn de beoogde taak met vergelijkbare kwaliteit uit te voeren. Om de prestatie-kostenverhouding van verschillende taaktypen nauwkeurig te bepalen, kan men gebruikmaken van het benchmark-overzicht voor kosten per taak.
2. Capaciteitsbenutting en Piekopvang: Eigen hardware moet worden gedimensioneerd op de piekbelasting, of er moet een hybride model worden gehanteerd (base load lokaal, piekbelasting via de cloud). Als een server is gedimensioneerd op een piekmoment dat slechts twee uur per dag voorkomt, staat de hardware de overige 22 uur grotendeels onbenut te draaien, wat de TCO per token negatief beïnvloedt.
3. Expliciete Horizon van 36 Maanden: Alle kapitaaluitgaven moeten worden omgeregeld naar een maandelijkse afschrijvingscomponent over 36 maanden, opgeteld bij de maandelijkse operationele lasten (stroom, koeling, beheer, huur). Pas wanneer het totale maandbedrag over 36 maanden wordt vergeleken met de geprojecteerde maandelijkse API-factuur (inclusief volume-groei), ontstaat een reëel beeld van het omslagpunt.

Werking en Aannames van de Client-Side Rekenmodule

De op deze pagina geïntegreerde rekenmodule voegt bovenstaande variabelen samen in een dynamische berekening. Omdat de module volledig client-side werkt (in de browser van de gebruiker via JavaScript), worden ingevoerde volume- en kostengegevens niet naar een externe server verzonden. Dit waarborgt de vertrouwelijkheid van de strategische planning.

De rekenmodule hanteert de volgende wiskundige opbouw voor de twee scenario's:

Cloud TCO-Formule

De totale cloudkosten over $N$ maanden (waarbij $N=36$) worden berekend door de maandelijkse tokenvolumes te vermenigvuldigen met de respectievelijke tarieven, gecorrigeerd voor een maandelijks groeipercentage $g$:

$$\text{TCO}_{\text{cloud}} = \sum_{m=1}^{N} \left( \left( V_{\text{in}} \times (1+g)^m \times P_{\text{in}} \right) + \left( V_{\text{out}} \times (1+g)^m \times P_{\text{out}} \right) + K_{\text{infra}} \right)$$

Waarbij $V_{\text{in}}$ en $V_{\text{out}}$ de beginvolumes per maand zijn, $P_{\text{in}}$ en $P_{\text{out}}$ de prijzen per token, en $K_{\text{infra}}$ de vaste maandelijkse overige cloudkosten (zoals netwerk en monitoring).

On-Premise TCO-Formule

De totale on-premise kosten over dezelfde periode bestaan uit de initiële investering vermeerderd met de cumulatieve operationele lasten:

$$\text{TCO}_{\text{onprem}} = \text{CapEx}_{\text{hardware}} + \sum_{m=1}^{N} \left( K_{\text{stroom}}(m) + K_{\text{rack}} + K_{\text{onderhoud}} + K_{\text{beheer}} \right)$$

Waarbij $K_{\text{stroom}}$ rechtstreeks afhankelijk is van het opgenomen vermogen in kilowatt, de draaiuren per maand, de PUE-factor en de stroomprijs per kWh:

$$\text{Kstroom} = \left( \frac{\text{Watt}}{1000} \right) \times 730\text{ uur} \times \text{PUE} \times \text{Prijs per kWh}$$

Aannames in het Rekenmodel

De module gebruikt een aantal gestandaardiseerde uitgangspunten die als vuistregel dienen en in de invoervelden door de gebruiker kunnen worden aangepast:

• Onderhoudscontracten: Standaard ingesteld op een vuistregel van 10% tot 15% van de aanschafwaarde van de hardware per jaar.
• Beheerslast: Standaard gebaseerd op een geschat aantal uren per maand voor system engineering, vermenigvuldigd met het interne uurtarief.
• PUE (Power Usage Effectiveness): Standaard ingesteld op 1,25 (een representatieve waarde voor een modern efficiënt datacenter).
• Geen Restwaarde: Het model gaat uit van een restwaarde van 0 euro na 36 maanden, vanwege de snelle technologische veroudering van AI-hardware.

Wanneer Wint Welk Scenario?

Uit de kwantitatieve analyse van TCO-modellen komen duidelijke kantelpunten naar voren. Geen van beide opties is universeel superieur; de optimale keuze wordt gedreven door schaal, voorspelbaarheid en organisatorische randvoorwaarden.

Wanneer Cloud-API's Economisch En Technisch Winnen

• Lage of wisselende volumes: Bij opstartende projecten, experimentele fases of applicaties met een onregelmatig gebruikspatroon zorgen cloud-API's ervoor dat er enkel betaald wordt voor de effectief verwerkte tokens. Eigendomskosten van hardware wegen in dit stadium niet op tegen de lage variabele lasten.
• Behoefte aan de allergrootste grensverleggende modellen: De grootste, meest geavanceerde modellen vereisen een dusdanig omvangrijke clusters-infrastructuur dat het zelf draaien hiervan voor MKB- en middelgrote organisaties kapitaaltechnisch en operationeel niet haalbaar is.
• Beperkte interne beheercapaciteit: Wanneer een organisatie geen toegewezen infrastructure engineering- of DevOps-capaciteit heeft, zijn de verborgen personeelskosten voor het in de lucht houden van eigen hardware vaak vele malen hoger dan de marge die een cloudprovider rekent.

Wanneer On-Premise / Private Hardware Wint

• Hoge, voorspelbare en continue belasting (High Baseline Load): Wanneer de verwerkingscapaciteit 24/7 constant hoog is en de hardware een hoge bezettingsgraad kent (bijvoorbeeld >60-70%), dalen de effectieve kosten per token bij een eigen installatie ver onder het tarief van cloud-API's.
• Strikte datalocatie, privacy en compliance: In sectoren zoals de gezondheidszorg, de financiële sector of de overheid, waar data de organisatie- of landsgrenzen absoluut niet mag verlaten, is het vermijden van externe API's vaak een randvoorwaarde. Het TCO-model dient in dat geval om de meest efficiënte eigen infrastructuur te kiezen, eerder dan om de keuze tegen de cloud af te wegen.
• Lange-termijn vastlijning van specifieke open-source modellen: Wanneer de applicatie-architectuur is afgestemd op een specifiek open-source model dat door middel van fine-tuning optimaal presteert, vervalt de noodzaak om continu mee te bewegen met de nieuwste proprietary cloud-API's.

Artefact: TCO-Kostenposten Checklist en Datablad

Onderstaande matrix kan door IT-architecten en controllers worden gebruikt als inventarisatielijst om de benodigde gegevens te verzamelen voordat de definitieve TCO-berekening wordt gemaakt. Deze lijst voorkomt dat cruciale verborgen kostenposten over het hoofd worden gezien.

Vuistregel voor de uitvoering: Vul alle parameters in op basis van geautoriseerde offertes en interne tarieven. Vergelijk vervolgens het totaalbedrag onderaan de streep over een vaste periode van 36 maanden om tot een gewogen besluitvorming te komen.