De relevante keuze is geen ideologisch kamp
Wie veel AI wil gebruiken, vraagt al snel: moeten we open source draaien of een gesloten model via API gebruiken? Het bruikbare antwoord begint een stap eerder. U kiest tegelijk een modelcapaciteit, licentie, dataweg, servinglaag, prijsmodel, veiligheidsgrens, supportmodel en teamverantwoordelijkheid. Een model met publiek beschikbare gewichten kan bijvoorbeeld nog steeds gebruiksvoorwaarden hebben; een managed endpoint kan juist de meest verstandige manier zijn om een product veilig en snel te valideren.
De Open Source Initiative maakt dit onderscheid scherp. Volgens haar definitie gaat open-source-AI over de vrijheden om een systeem te gebruiken, te bestuderen, aan te passen en te delen, met de informatie die daarvoor nodig is. ‘Open weights’ is dus een nuttige technische eigenschap, maar niet automatisch hetzelfde als een volledig open systeem. Lees de concrete licentie, modelkaart, distributievoorwaarden en toegestane inzet altijd zelf. [1]
Voor een productteam is de vraag daarom: welk deel van onze AI-waardeketen moeten wij beheersen om betere betrouwbaarheid, privacy, kosten of productdifferentiatie te leveren—en welk deel kopen we verstandiger in? Dat maakt de beslissing toetsbaar in plaats van symbolisch.
Bronnen [1]
Waarom een gesloten API vaak de rationele eerste stap is
In de beginfase weet je meestal nog niet hoeveel verkeer een use-case werkelijk krijgt, welke prompts waarde opleveren, hoe lang contexten worden, hoeveel menselijke review nodig blijft en welke kwaliteit klanten verwachten. Een API verlaagt dan de vaste operationele last: geen modelimage, GPU-scheduling, capacity planning, quantisatiekeuze, drivercompatibiliteit of 24/7 on-call voordat het productbewijs er is.
Dat is meer dan gemak. Een provider-API maakt het mogelijk om dezelfde taak tegen meerdere modellen te evalueren, de productinterface te testen en de echte tokenverdeling te meten zonder vooraf een capaciteitshypothese in hardware te vertalen. De Stanford AI Index laat zien dat inferentiekosten en modelprestaties snel blijven bewegen; een starre infrastructuurkeuze aan het begin kan daardoor sneller verouderen dan de use-case. [2]
API-first betekent niet dat je afhankelijkheid moet negeren. Leg een modelrouter achter uw product-API, log taakklasse en kosten zorgvuldig, abstraheer prompts en outputcontracten, en ontwerp fallbacks. Dan blijft een wijziging van model of leverancier een gecontroleerde productbeslissing in plaats van een herschrijving.
Bronnen [2]
De omslag naar eigen GPU-capaciteit begint bij een workload-profiel
Self-hosting of gehuurde GPU-capaciteit wordt interessant wanneer de vraag niet alleen groot, maar ook voorspelbaar en technisch passend is. Denk aan veel vergelijkbare classificaties, extractie, transformaties, samenvattingen of agentstappen met een bekende contextlengte en een stabiele latency-eis. Dan kunnen een vaste modelkeuze, batching en caching de capaciteit beter vullen dan losse API-calls.
Reken niet met ‘aantal gebruikers’, maar met een vraagprofiel: input- en outputtokens per taak, gelijktijdigheid, piekbelasting, gewenste responstijd, contextvenster, modelgeheugen, herhaalratio, regio, beschikbaarheidsdoel en foutmarge. Vergelijk vervolgens de volledige kosten per geslaagde taak: API-verbruik tegenover GPU-uren plus opslag, netwerk, modeloperatie, observability, beveiliging, engineers, idle-tijd en reserve- of fallbackcapaciteit.
GPU-prijzen veranderen per regio, machine, contract en moment. Google Cloud publiceert bijvoorbeeld aparte on-demand- en commitmentprijzen voor GPU's; Spot-capaciteit kan fors goedkoper zijn, maar kan ook worden onderbroken. Spot is daarom bruikbaar voor herstelbare batchjobs of training met checkpoints, niet als enige laag onder een strakke interactieve servicebelofte. [3, 4]
Bezettingsgraad maakt het economische verschil
Een gehuurde GPU wordt per tijdseenheid betaald, ook wanneer zij wacht. Daardoor is de beslissende variabele vaak niet de theoretische tokens-per-seconde van een model, maar de gerealiseerde bezettingsgraad onder uw eigen verkeer. Een stille GPU maakt self-hosting duur; een constante stroom vergelijkbare taken kan dezelfde GPU juist heel efficiënt benutten.
Moderne servingengines zijn gebouwd rond dat probleem. vLLM documenteert onder meer continuous batching, chunked prefill en prefix caching: technieken die inkomende requests slimmer samen plannen en herhaalde context minder vaak verwerken. Ze verbeteren de doorvoer niet automatisch voor elke workload; lange generaties, lage concurrency, grote contexten en strikte latencygrenzen blijven fysiek en economisch bepalend. [5]
Meet daarom eerst. Neem een representatieve set productrequests, verdeel die in taakklassen en benchmark kwaliteit, p50/p95-latency, tokens, GPU-geheugen, foutpercentage en kosten per geaccepteerd resultaat. Pas daarna kun je eerlijk vergelijken of een self-hosted endpoint werkelijk goedkoper of beter beheersbaar is dan een API.
Bronnen [5]
Wanneer open modellen inhoudelijk winnen
Open-weight of open-source modellen zijn vooral sterk wanneer modelgedrag onderdeel van het product wordt. U kunt een specifieke versie vastzetten, de servinglaag zelf instrumenteren, een domeinspecifieke fine-tune of adapter evalueren, een deployment in een gekozen omgeving uitvoeren en de routing rond uw eigen data- en latencygrenzen ontwerpen. Dat kan belangrijk zijn voor continue hoge volumes, dataresidency, offline of private omgevingen en een product waarvoor voorspelbaarheid meer waard is dan elke week het nieuwste frontiermodel.
Maar controle koopt ook werk. U wordt eigenaar van kwetsbaarheden in de model- en containerketen, toegangsbeheer, modellicenties, prompt- en outputbeveiliging, capaciteitsplanning, patches, evaluaties, incidentrespons en de beslissing wanneer een modelversie wordt vervangen. Self-hosting verlaagt nooit automatisch het privacy- of compliance-risico; het verplaatst verantwoordelijkheid naar uw organisatie.
Gebruik een open model dus niet omdat het woord open aantrekkelijk klinkt. Gebruik het wanneer de controle die het mogelijk maakt aantoonbaar bijdraagt aan een beter product of een beter kostenprofiel onder echte belasting.
Een hybride architectuur is vaak de volwassen uitkomst
De keuze hoeft niet exclusief te zijn. Een volwassen platform routeert taken op grond van kwaliteit, gevoeligheid, kosten, latency en beschikbaarheid. Een self-hosted model kan de hoge-volume, goed-begrepen stroom afhandelen; een gesloten frontiermodel behandelt moeilijke redenering, uitzonderlijk lange context of multimodale taken; een eenvoudige deterministische stap voorkomt dat beide modellen werk doen dat code beter kan doen.
Dat vraagt om een gedeeld evaluatiecontract. Normaliseer invoer en output, versies prompts en modellen, meet per route hetzelfde kwaliteitsresultaat en zet een veilige fallback klaar. Routeer geen gevoelige data naar een externe provider zonder expliciete grondslag en contractuele toetsing; stuur ook geen ongeteste open modeloutput direct naar een klant of bedrijfssysteem zonder passende review en validatie.
- Begin met één taakklasse die voldoende volume én een meetbare definitie van goed heeft.
- Meet piek, gemiddelde en daluren apart; gemiddelde belasting verbergt dure idle-capaciteit en wachtrijen.
- Houd een fallbackmodel en een duidelijke degradatiestand voor capaciteits- of kwaliteitsproblemen.
- Behandel model- en licentiewijzigingen als een release met evaluaties, niet als een configuratiewijziging.
- Kies Spot alleen wanneer een onderbreking technisch en commercieel herstelbaar is.
De praktische volgorde: bewijs, meet, committeer pas daarna
Start met een API of een klein managed experiment om taakfit en vraag te bewijzen. Verzamel daarna echte distributies van tokens, context, latency, correcties en gebruiksmomenten. Bouw een benchmark die zowel de minimale kwaliteitsgrens als de kosten per afgerond resultaat vastlegt. Pas wanneer een workload stabiel genoeg is, verdient een pilot met gehuurde GPU's en een gekozen open model de moeite.
De beste infrastructuurkeuze is daarmee geen permanent geloofsartikel. Herzie haar wanneer volume, modelkwaliteit, contractvoorwaarden, hardware, regelgeving of uw eigen product veranderen. Dat houdt de organisatie flexibel genoeg om schaalvoordeel te pakken zonder te vroeg een datacenterbedrijf te worden.