Regelmatig spreek ik met mensen die enthousiast zijn over cloud providers voor GenAI modellen. Ze hebben een abonnement op Claude, gebruiken via hun werk Copilot of hebben hun telefoon aangesloten op Gemini. Voor deze power users zijn LLMs allang veel meer dan een chatbot: met de juiste integraties kunnen deze modellen zelfstandig programmeren, emails beantwoorden en een blog bijhouden. Steeds vaker spelen deze early adopters een voortrekkersrol in innovatietrajecten binnen organisaties. Hun mening heeft daarom veel invloed op de manier waarop technologie uiteindelijk geïmplementeerd wordt.

Lokale modellen zijn voor mij niet goed genoeg om mijn werk te doen.
Dat omschrijft de reactie die ik krijg als ik vraag of ze weleens lokale modellen hebben gebruikt.

Tot voor kort was dat voor de meeste mensen ook zeker het geval. De infrastructuur was best lastig om te configureren, en hoewel er zeker woorden gegenereerd werden, was de betrouwbaarheid van de modellen niet altijd goed. Dat is snel aan het veranderen. In deze post introduceer ik een aantal redenen waarom je juist wel / niet lokale AI wil gebruiken.

Open versus closed

Vrijwel alle modellen die lokaal gedraaid kunnen worden, worden “open weight” genoemd. De populairste manier om ze te gebruiken, is door een GGUF bestand te downloaden (bijvoorbeeld vanaf https://huggingface.co/) en die met llama.cpp te draaien. Het GGUF bestand zelf bevat instructies over hoe het model gebruikt moet worden en bevat de “weights”. Omdat die publiek beschikbaar zijn, spreekt men van “open weights”. Open-weight betekent niet open-source. De meeste labs die open-weight modellen produceren, geven niet de infrastructuur en data vrij die nodig is om de modellen te trainen.

Open-weight modellen hoeven niet per se lokaal gedraaid te worden. Dat kan ook op een flinke VM van een cloud hoster. Lokaal versus cloud dekt dus sowieso niet helemaal de lading; de discussie gaat eerder over open versus closed.

Commerciële providers van GenAI modellen die hun eigen modellen ontwikkelen, delen lang niet altijd de modelbestanden. Deze modellen worden “closed weight” genoemd. Omdat de modelbestanden niet gedeeld worden, kunnen deze modellen dus niet lokaal gedraaid worden.

De meest geavanceerde modellen worden “frontier models” genoemd. In 2024 waren vrijwel al deze modellen closed-weight. Het is de vraag of dit nog zo is: op het moment van schrijven (oktober 2026) laten openbare benchmarks op bijv. Qwen3.8 Max zien dat dit open-weight model #2 is op de ranglijst voor het volgen van instructies. Bij de multimodal ranglijst, gebaseerd op het combineren van visuele informatie en tekst, staat het open-weight Kimi K3 model zelfs bovenaan. Hoewel geaggregeerde ranglijsten nog steeds aangevoerd worden door closed-weight modellen, komen open-weight modellen steeds meer in de buurt en werken ze zelfs beter als het op specifieke taken aankomt.

De ranglijsten laten zien dat recente open-weight modellen voor veel taken goed genoeg zijn. Als het om specifieke problemen gaat, kunnen ze zelfs beter zijn dan closed-weight modellen. Het is nu al interessant om meerdere modellen in te zetten zodat er maximaal gebruikt kan worden van hun sterke kanten. Een testopstelling maakt zo’n vergelijking mogelijk.

Kosten

Hoewel abonnementen van cloud providers vaak relatief kosteneffectief zijn, kan de prijs van tokens voor API-gebaseerde tools flink uit de klauwen lopen. Een groot probleem hierbij is dat de kostprijs van tokens lineair is: bij toegenomen verbruik is er altijd een toename in de prijs. Bij eigen hardware is dat niet het geval. Je hebt te maken met een initiële investering en kunt daarna de hardware gaan afschrijven. Op de lange termijn kan toegang tot eigen hardware de kosten voorspelbaarder maken. In theorie is er ook een break-even punt; als de hardware lang genoeg meegaat, worden de kosten per token lager dan ze zouden zijn geweest bij betaling op basis van gebruik.

In theorie – want dat punt is op dit moment erg lastig om te berekenen. De vraag naar GenAI heeft geleid tot een enorme behoefte aan RAM, opslagruimte en GPU’s. En dat heeft de prijzen flink opgedreven. Dat zorgt ervoor dat het sowieso langer duurt om een break-even punt te bereiken. Ook loopt de beschikbaarheid van hardware sterk achter op modelontwikkeling. Er zijn steeds betere en grotere open-weight modellen beschikbaar, maar de hardware om die modellen te draaien wordt alleen maar schaarser. Er is bovendien een risico dat de toekomstige noodzaak voor betere modellen zorgt voor een kortere effectieve levensduur van aangekochte hardware.

Een tweede complicatie heeft te maken met de flexibiliteit van AI. Daardoor is het erg lastig om de toegevoegde waarde van AI in processen accuraat te meten. Ook zijn integraties vaak nog niet uitontwikkeld. Dat zorgt ervoor dat het nog niet duidelijk is wat gegenereerde tokens uiteindelijk financieel gaan opleveren. Als die opbrengst laag is, is een investering in AI-integraties niet logisch – of dat nu een investering in lokale of cloud-gebaseerde integraties is.

Één van de grootste factoren die kosteneffectiviteit van eigen hardware beïnvloedt is het gebruik. Een server die standby staat, kost veel maar levert niets op. Dan maakt het niet uit hoe duur de tokens van een cloud provider zijn: voor ongebruikte tokens hoef je bij een contract op basis van gebruik niet te betalen. Voor een ongebruikte server moet wel betaald worden. Op dit moment moet daar zelfs zoveel voor betaald worden dat kosteneffectiviteit ook bij 100% gebruik niet gegarandeerd kan worden.

Zijn de processen die met GenAI ondersteund moeten worden al grotendeels uitontwikkeld? Is het mogelijk om de kosten van tokens naast de kosten van de benodigde hardware te leggen? In dat geval is het de moeite waard om een overzicht uit te werken. In alle andere gevallen kan het nog steeds interessant zijn om met open-weight modellen te werken, maar dat zal niet zijn vanwege mogelijke besparingen.

Stabiliteit

Bij cloud providers worden er keuzes gemaakt om het gebruiksgemak van hun AI-systemen te verhogen en de kosten te beperken. Zo kunnen providers er bijvoorbeeld voor kiezen om het aanbod van hun modellen te beperkent. Ook kunnen er integraties met cloud systemen opgezet worden waarbij het niet altijd helder is hoe er met toegangsbeheer omgegaan wordt. In de praktijk betekent dit dat er op een hoog tempo wijzigingen gemaakt kunnen worden die een grote invloed kunnen hebben op eindgebruikers. Een model wat uitstekend werkt in een ontworpen integratie kan na een update dan ander gedrag gaan vertonen.

Bij open-weight modellen valt dit onder de verantwoordelijkheid van de eindgebruiker. Modellen zullen nooit automatisch uitgefaseerd worden en integraties worden niet onzichtbaar toegevoegd. Dat heeft voor- en nadelen.

Wanneer processen relatief geoptimaliseerd zijn, is er vaak sprake van (informeel) change management en kwaliteitsmanagement. De processen zijn gedocumenteerd en er kan trainingsmateriaal beschikbaar zijn; uitkomsten van de processen zijn duidelijk gedefinieerd. Als deze processen veranderd moeten worden, kunnen betrokken personen accuraat inschatten wat de belangrijkste risico’s zijn. Wanneer er iets misgaat, is het onmiddelijk duidelijk wat de gevolgen daarvan zijn.

Hebben de geplande AI-integraties te maken met dit type processen? In dat geval is het logisch om dezelfde eisen te stellen aan risicomanagement. Als het proces een duidelijke en meetbare uitkomst heeft, moet er ook een manier zijn om vast te stellen dat de AI-integraties die uitkomsten niet in de weg staan. Wanneer wijzigingen aan het proces niet eenzijdig gemaakt mogen worden, moet dat waarschijnlijk ook gelden voor de AI-integratie. En als er gebruik wordt gemaakt van meerdere leveranciers om problemen te voorkomen wanneer één van de leveranciers niet beschikbaar is, is het logisch om de server achter de integratie ook uitwisselbaar te maken.

Zeker bij kleinere organisaties is er een risico dat IT-processen niet voldoende geautomatiseerd zijn. Dat kan grote problemen geven omdat het dan moeilijker is om veilig en efficiënt toegangsbeheer te implementeren. Net zoals personen in een organisatie niet zomaar toegang mogen hebben tot alle infrastructuur in de organisatie, mogen AI-integraties dat ook niet. Effectief systeembeheer betaalt zichzelf dan snel terug.

De keuze voor GenAI infrastructuur hangt dus sterk af van het type proces wat ondersteund moet worden en de beschikbare technische capaciteit. Wanneer er (nog) geen duidelijkheid is over de rol van GenAI in processen, kan het makkelijker zijn om flexibel om te gaan met integraties en wijzigingen van externe providers. Zijn er goede redenen om aan te nemen dat lokale dataverwerking een voorwaarde is, of dat de integratie duurzaam en betrouwbaar moet zijn? In dat geval is het de moeite waard om nader te onderzoeken wat de voor- en nadelen zijn van open-weight infrastructuur. Een kleine lokale testopstelling kan dan helpen om AI-integraties vorm te geven en te evalueren.

Expertise

Hoewel gebruiken van GenAI technologie een doel op zich kan zijn, wordt het meestal gezien als een middel om bestaande doelen te behalen. Vaak zijn er al processen aanwezig die te maken hebben met die doelen. Zulke processen ontstaan niet vanzelf: ze zijn afhankelijk van de expertise van de mensen die ze ontwerpen en uitvoeren.

Daadwerkelijk effectief integreren van GenAI technologie in zulke processen kan creatieve oplossingen vereisen. Misschien moet er daarvoor een aansluiting komen op een database. Of er moet effectief toegang verleend worden aan interne documentatie. Dienstverleners bieden regelmatig hun eigen oplossingen aan; soms is dit onderdeel van de bestaande dienstverlening, soms is het een aanvullend pakket. Vaak zijn ze ontworpen om te voldoen aan de behoeftes van de meerderheid van de eindgebruikers.

Bij processen die afhankelijk zijn van expertise is de kans groot dat gestandaardiseerde oplossingen niet goed werken. In dat geval kan het effectiever zijn om met de experts samen te werken om iets op maat te ontwikkelen. Zulke ontwikkelprocessen zijn kostbaar. Het is dan riskant om ze afhankelijk te maken van een externe dienstverlener die eenzijdig de ondersteuning kan wijzigen. Bovendien kan dit veiligheidsrisico’s geven die met infrastructuur in eigen beheer te vermijden valt.

Juist bij dit type processen zijn de grootste winsten te behalen. De expertise om de toegevoegde waarde en risico’s van de nieuwe oplossing in te schatten is namelijk voldoende aanwezig. Dat maakt het mogelijk om betrouwbaar effectiviteit te meten en randvoorwaarden voor succes te achterhalen. Zijn er bijvoorbeeld eisen qua productiviteit of veiligheid? Hoe wordt kwaliteit gedefinïeerd?

Het is mogelijk dat er oplossingen zijn van externe dienstverleners die wél goed aansluiten op de doelstellingen. Is dat wenselijk? Gebruik van zulke oplossingen kan leiden tot het uithollen van interne expertise en tot lock-in. Kennis die het mogelijk maakt om met technologie effectief processen te ondersteunen is niet makkelijk om te ontwikkelen; al helemaal niet als het gaat om processen die onderdeel zijn van een unieke niche. De infrastructuur bepaalt welke kennis behouden blijft.

TLDR;

De keuze voor open- versus closed-weight modellen is afhankelijk van:

• Het totale kostenplaatje
• Eisen aan risicomanagement
• De rol van interne expertise

Voor algemene toepassingen waarbij deze context niet duidelijk is, zijn cloudoplossingen vrijwel altijd kosteneffectiever.

Beter begrijpen wat de kansen en risico’s van GenAI zijn in uw organisatie, en welke infrastructuur daar bij past? Neem contact op voor een offerte.