De verborgen kosten van de cloud

Hoofdstuk 5 — De verborgen kosten van de cloud

De dominante verhaallijn van de afgelopen vijf jaar is dat de cloud kosteneffectief, schaalbaar en eenvoudig is. Voor veel workloads is dit volkomen waar. Voor enterprise RAG, steeds vaker, is dit niet het geval. En het moment waarop je dit merkt, is meestal aan het einde van het eerste kwartaal, wanneer de factuur arriveert.

Laten we het meest onderschatte onderdeel van de rekening nemen: de API's van vision-modellen. Wanneer een bedrijf zijn fotoarchief in een moderne RAG verwerkt, moet elke foto worden "beschreven" door een multimodaal model dat de inhoud, objecten, context, eventuele overgelegde teksten, stemming en compositie extraheert. Een grote Europese modelprovider – nog naamloos – bood in 2025 een uitstekend model uit de Qwen-familie met 32 miljard parameters aan, tegen een interessante prijs per afbeelding. Het probleem, pas op het veld en na maanden van productie ontdekt: onder belasting hakte de provider de antwoorden af. Niet altijd, niet voorspelbaar, niet wanneer het testteam erbij was: willekeurig. Eén op de tien foto's, soms één op de vijf, kwam terug met een JSON die halverwege was afgekapt, slecht geparst, met gedeeltelijke of null-metadata. De tijden schoten omhoog van tien seconden naar tweehonderd seconden per afbeelding, zonder patroon. De kosten van de retry – want retries worden betaald, elke oproep, zelfs die welke de server afbreekt – waren hoger dan verwacht. De database was inconsistent: sommige foto's rijk aan metadata, andere afgekapt. En het team kon het probleem niet reproduceren in testomgevingen, omdat de belasting in tests laag was en alles werkte.

De oplossing kwam in drie delen: een compactere prompt (kortere antwoorden worden minder snel afgekapt), een slimme retry-logica (als het antwoord langer dan vijftig seconden duurt en leeg terugkomt, probeer het dan onmiddellijk opnieuw) en — wanneer het volume het rechtvaardigt — de mogelijkheid om de cloud helemaal over te slaan en het vision-model op een lokale GPU te draaien, langzamer maar deterministisch. De juiste architectuur, zo bleek uit deze ervaring, is niet "altijd cloud" en ook niet "altijd lokaal". Het is "kies voor elke oproep, op basis van wat er op dat moment nodig is".

Dan is er nog het hoofdstuk van de query's. Elke gebruikerszoekopdracht activeert in een klassieke cloud-native RAG een cascade van betaalde API-aanroepen. Eén voor het inbedden van de vraag. Eén voor de intentieclassificatie (welk type vraag is dit?). Eén voor het opnieuw rangschikken van de documenten. Eén voor het genereren van het uiteindelijke antwoord. Elk kost een fractie van een cent. Voor een interne dienst met vijftig gebruikers en tienduizend query's per dag — wat niet weinig is, maar ook geen enorm aantal voor een gemiddeld bedrijf — loopt de maandelijkse rekening op tot bedragen die zelfs een toegeeflijke CFO zou doen fronzen. En de groei is lineair: verdubbel je het aantal gebruikers, verdubbel je de rekening. Er zijn geen schaalvoordelen in de verbruikte tokens, niet voor jou.

Er is ook een probleem dat in 2025 onderhuids sluimerde en in 2026 centraal is komen te staan: elke afzonderlijke query stuurt delen van bedrijfsdocumenten – soms vertrouwelijk, soms onderhevig aan een geheimhoudingsverplichting (NDA), soms onderworpen aan sectorregelgeving – naar de servers van een externe leverancier, in rechtsgebieden die niet altijd overeenkomen met de jouwe, met logboekbewaringsbeleid dat niet altijd helder is. Meer dan één Europees bedrijf heeft de afgelopen achttien maanden pas tijdens een audit – meestal geïnitieerd door een bezorgde klant of een ISO-controle – ontdekt dat hun contracten, prijslijsten en technische specificaties waren verwerkt (en potentieel gelogd voor doeleinden van "serviceverbetering") door infrastructuur buiten de EU. De verrassing kostte meestal meer dan de besparing op lokale hardware die men wilde vermijden.

Het alternatief is niet het tegenovergestelde dogma. "Geen cloud, wel lokaal" is net zo fout als "altijd cloud". Het alternatief is een architectuur die je in staat stelt om voor elk afzonderlijk onderdeel van de pipeline — embedding, classificatie, reranking, visie, uiteindelijke generatie — te kiezen of je een cloudmodel of een lokaal model wilt gebruiken, en om van gedachten te veranderen in één dag, niet in een kwartaal. Dit vereist een ontwerp waarin leveranciers onderling uitwisselbaar zijn, waarin geen enkel onderdeel vastzit aan de naam van een specifiek bedrijf, waarin de overstap van Regolo naar Ollama (of vice versa) een configuratieregel is, niet een herschrijving. En dat was, tot voor kort, zeldzaam. Populaire frameworks, ondanks de façade van "provider-agnostisch", waren in werkelijkheid sterk verbonden met iemand.