Waarom Steeds Meer Development Teams Kiezen voor Eigen AI-Infrastructuur

Er komt een moment waarop je ontwikkelteam zich afvraagt: waarom laten we eigenlijk zoveel van onze infrastructuur over aan externe partijen?

Dit is geen retorische vraag of een pleidooi om AI-services links te laten liggen. Het is een praktische overweging die steeds meer teams bezighoudt nu AI-codeertools een vast onderdeel worden van het dagelijks werk.

Ik stuitte onlangs op een interessant experiment. Een klein team bij Parity ging aan de slag met wat zij een "20%-tijd experiment" noemden: een paar engineers kregen de vrijheid om te onderzoeken of zelf-gehoste AI-modellen konden werken voor echte ontwikkelwerkzaamheden. Wat begon als een middagje proberen, liep uit op weken experimenteren. Vijfentwintig engineers verwerkten samen bijna 13 miljard tokens via een zelf beheerde inference-opzet.

De cijfers zijn opvallend. In de eerste drie dagen verwerkten ze meer dan 3 miljard tokens tegen ongeveer $0,10 per miljoen tokens aan GPU-rekenkosten. Over de volledige maand kwamen de kosten uit op zo'n $1.200. Dat is niet niks, maar ook niet het onbetaalbare avontuur dat veel teams verwachten wanneer ze "self-hosted AI" horen.

De Echte Kosten Zijn Niet Wat Je Denkt

Wat mij het meest frappeerde: de GPU-kosten waren weliswaar reëel, maar vormden de kleinere uitgave. De grotere investering zat in engineering-tijd. Het opzetten van de infrastructuur, het benchmarken van prestaties, en het leren hoe je het systeem betrouwbaar kunt runnen.

Dit patroon zie ik keer op keer terugkomen bij infrastructuurkeuzes. De directe kosten zijn zichtbaar en makkelijk te budgetteren. De verborgen kosten zijn de tijd en aandacht die je team besteedt aan het opbouwen van operationele kennis over nieuwe systemen. De gok van het Parity-team is dat deze kennis rente op rente oplevert. Door nu infrastructuur, benchmarks en operationele playbooken op te bouwen, investeer je in capaciteiten die zich uitbetalen over toekomstige workloads.

Dit klinkt vast bekend voor iedereen die ooit heeft nagedacht over cloud hosting, container-orchestratie of managed databases. Je weegt operationele complexiteit af tegen de controle, kostenbesparingen en strategische flexibiliteit die je wint. Soms wint de managed oplossing. Soms is het bezitten van de stack logischer.

Hoe Een "Simpele" Architectuur Er Uitziet

Wat ik waardeerde aan de beschrijving van Parity was hoe open ze waren over hun architectuur. Ze draaiden geen op maat gebouwde inference-cluster. Hun stack was verrassend eenvoudig:

Een common interface layer (zij gebruikten LiteLLM) staat tussen ontwikkelaarstools en de modellen die requests afhandelen. Daarachter zorgt vLLM voor model serving. De GPU-capaciteit draait op gehuurde infrastructuur van een cloud provider. De hele opzet is bewust zo ontworpen dat engineers kunnen blijven werken met hun vertrouwde codeeromgevingen en clients, terwijl het team flexibiliteit behoudt over welke modellen en providers achter de common endpoint zitten.

Dit is de crux die veel teams missen wanneer ze zelf-hosted opties afwijzen: je hoeft niet te kiezen tussen controle en gemak. Een goed ontworpen abstractielaag betekent dat ontwikkelaars met dezelfde tools werken als altijd. Het verschil is dat jij bepaalt welk model reageert, welke data wordt gelogd, en hoe kosten worden toegerekend.

Denk aan DNS-beheer. Ontwikkelaars hoeven de ins en outs van DNS-propagatie niet te begrijpen om domeinnamen effectief te gebruiken. Ze werken met een cleane interface. Maar achter die interface heeft iemand bewuste keuzes gemaakt over nameservers, TTLs en redundantie. Hetzelfde principe geldt hier.

Wat De Cijfers Ons Vertellen

De operationele data van Parity's experiment is waar het echt interessant wordt voor teams die vergelijkbare opzetten overwegen. Ze trackten context-lengtes, request-parallellisme, throughput en queue-tijden over echte ontwikkelworkflows.

Een paar cijfers die opvielen:

Negenennegentig procent van de requests gebruikte minder dan 500k tokens aan context. Meer dan de helft van de tijd verwerkte het systeem precies één concurrent request. Op piekmomenten zagen ze prefill processing van 168k tokens per seconde, met een gemiddelde time-to-first-token van ongeveer 3,34 seconden.

De verdeling van request-vormen vertelt een belangrijk verhaal. Meestal draait je inference-infrastructuur relatief bescheiden, single-threaded requests van developers. De parallelle request-scenario's die je systeem op de proef stellen zijn de uitzondering, niet de regel.

Dit heeft praktische implicaties voor capaciteitsplanning. Je hoeft niet per se te provisioneren voor de piek-parallelle belasting de hele tijd. Een goed ontworpen systeem kan dynamisch schalen terwijl baseline-kosten redelijk blijven.

De Strategische Vraag: Controle vs. Gemak

Hier ligt volgens mij de echte waarde van experimenten zoals dit: ze leren de industrie wat "AI-infrastructuur-onafhankelijkheid" in de praktijk betekent.

We zitten in een interessante overgangsperiode. AI-codeertools worden essentieel voor hoe teams software bouwen, maar de industrie is nog uitvogend wat het betekent om deze workloads verantwoord te draaien. Vragen over data retention, kostenvoorspelbaarheid, model-beschikbaarheid en vendor lock-in zijn allemaal reële zorgen die development teams steeds serieuzer nemen.

Het Parity-experiment suggereert dat zelf-gehoste inference toegankelijker is dan velen denken. Je hebt geen enorme engineering-organisatie of custom hardware nodig om te starten. Je hebt heldere requirements nodig, een verstandige architectuur, en de bereidheid om te investeren in operationele kennis.

Of die afweging voor jouw team werkt, hangt volledig af van je context. Maar het feit dat het een haalbare optie is, is het waard om te begrijpen — vooral nu AI-tools steeds diepgaander worden geïntegreerd in hoe we software verschepen.

Hoe Dit Past in het Cloud Hosting Landschap

Vanuit een cloud-infrastructuurperspectief heeft deze trend interessante implicaties. De mogelijkheid om GPU-capaciteit te huren in plaats van te kopen verlaagt de instapdrempel aanzienlijk. Je krijgt de operationele flexibiliteit van zelf-gehoste infrastructuur zonder de kapitaaluitgaven van fysieke hardware aanschaffen.

Dit is dezelfde evolutie die we hebben gezien in andere gebieden van cloud computing. Managed services abstraheren complexiteit weg, maar abstraheren ook controle weg. Zelf-hosted opties op cloud-infrastructuur geven je meer controle zonder dat je fysieke hardware hoeft te bouwen en te onderhouden.

Voor teams die bouwen op platforms zoals Vibe Hosting wordt de vraag: hoe wil je AI-capaciteiten consumeren? Prefereer je de eenvoud van volledig managed AI-services? Of waardeer je de mogelijkheid om modellen te wisselen, kosten te controleren, en precies te begrijpen wat er achter de schermen gebeurt?

Het eerlijke antwoord voor de meeste teams vandaag de dag is waarschijnlijk een hybride aanpak — managed services voor bepaalde workloads, terwijl je zelf-hosted capaciteiten opbouwt voor andere. De sleutel is begrijpen wat je in elke richting opgeeft.

De Conclusie

Zelf-gehoste AI voor software engineering is geen theoretische oefening meer, en ook geen aanpak die alleen weggelegd is voor grote ondernemingen met dedicated ML-infrastructuurteams. De tools zijn volwassen geworden, de kosten zijn gedaald, en de operationele patronen worden helderder.

Of je nu besluit om je eigen inference-infrastructuur te draaien of bij hosted providers te blijven, het begrijpen van de trade-offs wordt essentiële kennis voor engineering-leiders. Teams die nu de tijd nemen om deze lessen te leren, zijn beter gepositioneerd om infrastructuurkeuzes te maken naarmate AI-tools zich blijven ontwikkelen.

De toekomst van AI in ontwikkeling draait niet alleen om welke modellen je gebruikt — het draait om wie de stack controleert waar die modellen op draaien. En die vraag verdient serieuze overweging van elk team dat zijn ontwikkelinfrastructuur serieus neemt.

Welke aanpak hanteert jouw team voor AI-infrastructuur? Ben je volledig overgestapt op hosted services, experimenteer je met self-hosted opties, of vind je een balans tussen beide? Het gesprek over AI-infrastructuur-onafhankelijkheid is nog maar net begonnen.