6.6 AI-infrastructuur en -beheer

Overzicht en motivatie

AI-infrastructuur en -beheer is de discipline van het inrichten, plannen en draaien van de gespecialiseerde reken-, opslag- en servingsystemen die AI-werklasten vragen, kostenefficiënt, betrouwbaar en observeerbaar. Moderne AI is duur om te draaien. Grote modellen trainen en serveren vraagt schaarse versnellers (GPU’s en TPU’s), netwerken met hoge bandbreedte, grootschalige vectoropslag voor retrieval (data indexeren als numerieke vectoren zodat vergelijkbare items snel kunnen worden gevonden) en servinglagen afgestemd op latentie en doorvoer. Deze infrastructuur goed krijgen is het verschil tussen AI die duurzaam schaalt en AI die stilletjes een budget opslokt terwijl ze onderpresteert.

Voor grote teams zijn de kernproblemen schaal, schaarste en kosten. Versnellers zijn beperkt en prijzig, dus planning en benutting tellen enorm. Ongebruikte GPU’s zijn verbrand geld, en slecht gebundelde inferentie vermenigvuldigt de kosten per verzoek. Retrievalzware applicaties hebben vectordatabases nodig die snel blijven naarmate ze groeien. Generatieve AI-applicaties hebben promptversiebeheer, evaluatiepijplijnen en observeerbaarheid nodig (soms LLMOps genoemd) om veilig te draaien en in de tijd te verbeteren. Zonder gedeelde infrastructuur en operationele discipline voert elk team dezelfde gevechten en lopen de kosten op.

Overheids- en gereguleerde organisaties voegen eisen toe rond datasoevereiniteit, beveiliging en voorspelbare uitgaven. Ze kunnen on-premises of soevereine-clouddeployment nodig hebben zodat gevoelige data en modellen nooit gecontroleerde grenzen verlaten. Ze moeten infrastructuuruitgaven voorspellen en rechtvaardigen en aan beveiligings- en beschikbaarheidsstandaarden voldoen. AI-infrastructuurbeslissingen hebben in deze omgevingen meerjarige gevolgen, dus neem ze met aanbesteding, beveiliging en exit in gedachten.

Kernprincipes

Behandel versnellerrekenkracht als schaarse, dure bron om te plannen en te benutten, niet te hamsteren.
Optimaliseer kosten per nuttige werkeenheid, niet ruwe capaciteit.
Dimensioneer modellen en hardware op de taak. De grootste optie is zelden de meest kosteneffectieve.
Ontwerp serving voor latentie en doorvoer met bundelen en cachen als eersterangs technieken.
Maak AI-systemen observeerbaar: volg kosten, latentie, kwaliteit en fouten continu.
Versioneer en evalueer prompts en modellen met dezelfde rigueur als code.
Plan voor overdraagbaarheid en vermijd lock-in bij infrastructuur- en servingkeuzes.

Aanbevelingen

Plan en beheers versnellerrekenkracht

Voorspel de vraag naar training en inferentie afzonderlijk, aangezien ze verschillende vormen hebben. Training is stootsgewijs en planbaar. Inferentie is continu en latentiegevoelig. Gebruik planners en quota om schaarse GPU’s en TPU’s over teams te delen, werklasten te prioriteren en de benutting op te voeren. Meet benutting en behandel chronische inactiviteit als probleem om te repareren. Meng gereserveerde capaciteit voor basislast met on-demand- of spotcapaciteit voor pieken om kosten te beheersen. Overweeg of goedkopere of kleinere versnellers, of CPU-inferentie voor lichte modellen, zouden volstaan. Kies tussen cloud, on-premises en hybride op basis van kosten op jouw schaal, behoeften aan datasoevereiniteit en piekpatronen, en houd een exitpad.

Bouw retrievalinfrastructuur: embeddings en vectordatabases

Zet voor retrieval-augmented applicaties infrastructuur op om embeddings te genereren (numerieke vectorrepresentaties die vergelijkbare items dicht bij elkaar plaatsen) en ze op te slaan in een vectordatabase die snel benaderend dichtstbijzijnde-buurzoeken ondersteunt (de meest vergelijkbare vectoren vinden zonder elke vector uitputtend te vergelijken) op jouw schaal. Plan voor drie dingen: de kosten en latentie van embeddinggeneratie, indexversheid naarmate documenten veranderen en de operationele last van indexen consistent houden. Evalueer of een speciale vectordatabase, een vectorcapabele uitbreiding van een bestaande database of een beheerde dienst het best past bij je schaal en lock-intolerantie. Bewaak retrievallatentie en recall, want retrievalkwaliteit bepaalt direct de applicatiekwaliteit.

Optimaliseer modelserving: bundelen, cachen en latentie

Serving is waar inferentiekosten en gebruikerservaring worden bepaald. Gebruik bundelen (batching) om meerdere verzoeken samen te verwerken en de doorvoer van versnellers te verhogen, waarbij je batchgrootte tegen latentie afweegt. Gebruik cachen agressief: cache identieke of semantisch vergelijkbare verzoeken, cache embeddings en benut prompt- of prefixcaching waar het platform dat ondersteunt om herberekenen van gedeelde context te vermijden. Stel heldere latentiedoelen en meet staartlatentie, niet alleen gemiddelden. Stuur verzoeken naar modellen van passende grootte: een klein model voor makkelijke gevallen, een groter alleen wanneer nodig. Schaal serving automatisch mee met de vraag en test de belasting vóór lancering zodat je je capaciteit en kostencurve kent.

Oefen LLMOps: promptversiebeheer, evaluatiepijplijnen en observeerbaarheid

Behandel prompts als geversioneerde artefacten in bronbeheer, met review en het vermogen terug te draaien. Bouw evaluatiepijplijnen die automatisch offline testsuites draaien wanneer prompts of modellen veranderen, zodat je regressies vangt vóór release. Instrumenteer productie uitgebreid: log invoer, uitvoer, latentie, tokengebruik, kosten en fouten, met sampling en privacywaarborgen. Volg kwaliteitssignalen en gebruikersfeedback online. Deze observeerbaarheid laat je degradatie vangen, kosten beheersen, falen debuggen en systemen veilig verbeteren: de operationele ruggengraat van generatieve AI in productie.

Beheer kosten meedogenloos en observeerbaar

Wijs AI-uitgaven toe aan teams en gebruiksgevallen zodat kosten zichtbaar en bezeten zijn. Stel budgetten en alarmen in, bewaak kosten per verzoek en per uitkomst en beoordeel de grootste kostendrijvers regelmatig. Trek de hefbomen die je hebt: modellen op maat dimensioneren, cachen, bundelen, prompt- en contexttrimmen en de goedkoopste deployment kiezen die aan de eisen voldoet. AI-kosten kunnen op verrassende manieren met gebruik meeschalen, dus continue kostenobserveerbaarheid is essentieel om onaangename verrassingen te vermijden.

Afwegingen: voor- en nadelen

Beslissing	Optie A	Optie B	Afweging
Rekenlocatie	Cloud	On-premises	Elasticiteit en lage kosten vooraf tegenover controle, soevereiniteit en economie bij stabiel gebruik
Capaciteit	Gereserveerd	On-demand/spot	Voorspelbare kosten tegenover flexibiliteit en onderbrekingsrisico
Batchgrootte	Grote batches	Kleine batches	Doorvoer en kosten tegenover latentie
Modelgrootte	Groot model	Klein model	Kwaliteit tegenover kosten en snelheid
Vectoropslag	Speciale database	Uitbreiding van bestaande database	Prestaties op schaal tegenover eenvoud en minder systemen
Cachen	Agressief	Minimaal	Lagere kosten en latentie tegenover versheid en complexiteit

De dominante afweging is kosten tegenover latentie en kwaliteit. Bundelen, cachen en kleinere modellen verlagen kosten maar kunnen latentie toevoegen of kwaliteit verminderen. De juiste balans hangt af van de tolerantie van je applicatie. On-premises tegenover cloud ruilt controle en economie bij stabiel gebruik tegen elasticiteit en lage verbintenis, een beslissing sterk gevormd door behoeften aan datasoevereiniteit en schaal.

Vragen om met je team te bespreken

Wat zijn onze kosten per nuttige uitkomst vandaag, en welke hefboom zou ze het meest bewegen? Ruwe capaciteit en gemiddelden per verzoek verbergen het getal dat telt: wat het kost om één echte waardeeenheid te leveren, en hoe dat met gebruik meeschaalt. Voor een groot team is het gat tussen een geoptimaliseerde en een niet-geoptimaliseerde deployment vaak een veelvoud in uitgaven, dus deze vraag verandert een vage zorg over de rekening in een gerangschikte lijst reparaties. Neem de huidige kostentoewijzing per team en gebruiksgeval mee, trends per verzoek en per uitkomst en de grootste kostendrijvers. Bespreek de hefbomen in volgorde van opbrengst: modellen op maat dimensioneren, cachen (inclusief prefix- en semantisch cachen), bundelen en prompt- of contexttrimmen. Voeg bij de overheid de druk toe om meerjarige uitgaven te voorspellen en te rechtvaardigen. Het antwoord moet elke grootste kostendrijver een eigenaar en een hefboom geven, geen schouderophaal.
Als onze huidige inferentieaanbieder morgen zijn prijs verdubbelde of eruit lag, hoe snel konden we overstappen? Stille lock-in is makkelijk te bouwen en pijnlijk te ontsnappen, en servingstacks zijn waar hij zich het diepst verbergt. Voor ondernemingen en vooral de overheid is overdraagbaarheid een aanbestedings- en continuïteitseis, geen aardigheid. Neem je architectuur mee: of modellen achter een interne interface zitten, of prompts en evaluatiesuites overdraagbaar zijn en hoeveel aanbiederspecifiek servinggedrag je afhankelijk bent. Het signaal om op te letten is of iemand ooit je evaluatiesuite tegen een tweede aanbieder of tweede deploymentdoel heeft gedraaid. Als overstappen maanden zou duren en kernpaden herschrijven, behandel dat dan als ontwerpdefect om nu aan te pakken, aangezien soevereine en on-premisesopties met weinig waarschuwing verplicht kunnen worden.
Wat is onze benutting van versnellers nu, en hoeveel verbranden ongebruikte GPU’s en niet-gebundelde inferentie? Versnellers zijn schaars en duur, dus chronische inactiviteit en serving per verzoek tappen stilletjes budgetten af die meer vermogen konden financieren. Voor een grote organisatie die GPU’s over teams deelt legt deze vraag bloot of planning, quota en prioriteiten de benutting werkelijk hoog houden of dat gehamsterde, onderbenutte hardware de norm is. Neem echte benuttingsgetallen mee, je houding rond bundelen en cachen en je metingen van staartlatentie, niet alleen gemiddelden, want gebruikers voelen de trage staart. Bespreek of de vraag naar training en inferentie apart wordt voorspeld, gegeven hun verschillende vormen, en of een kleiner model of CPU-inferentie voor lichte gevallen zou volstaan. Het antwoord moet wijzen op specifieke ongebruikte capaciteit om terug te winnen en specifieke verzoeken om te bundelen of naar een model van passende grootte te sturen.
Wanneer een prompt- of modelwijziging wordt opgeleverd, wat belet een stille kwaliteits- of kostenregressie gebruikers te bereiken? Een servingstack kan gezond lijken op latentie en uptime terwijl de antwoorden die ze geeft stilletjes slechter worden of een nieuwe prompt het tokengebruik per verzoek verdubbelt. Voor een groot team waar veel groepen onafhankelijk prompts bewerken en modellen verwisselen is een niet-gepoorte wijziging een productie-incident dat wacht te gebeuren, en de schadezone groeit met elk team op het gedeelde platform. Neem je evaluatiedekking mee: welke prompts en modellen offline testsuites hebben, of die suites automatisch bij elke wijziging draaien, welke kwaliteits- en kostendrempels een release poorten en hoe snel je kunt terugdraaien. Bespreek of prompts met review in bronbeheer leven, of dat iemand nog steeds een live systeemprompt met de hand kan bewerken. Koppel in omgevingen van onderneming en overheid elke wijziging aan een auditspoor en een benoemde goedkeurder, want een toezichthouder die vraagt “wie heeft dit gewijzigd en wat heeft u getest” heeft een antwoord nodig dat is vastgelegd, niet onthouden.
Hoe beslissen we tussen cloud, on-premises en soevereine deployment, en hebben we de echte economie bij stabiel gebruik geprijsd in plaats van de pilot? De keuze van rekenlocatie bepaalt jarenlang je kostencurve, je datasoevereiniteitshouding en je exitopties, maar wordt vaak gemaakt op de cloudrekening van een pilot die er niets op lijkt als productie op schaal. Voor een grote organisatie is elastische cloudcapaciteit goedkoop om mee te beginnen en kan de grootste enkele post worden zodra inferentie continu draait, terwijl on-premises lage verbintenis ruilt tegen controle en economie bij stabiel gebruik. Neem voorspelde trainings- en inferentievolumes mee, het break-evenpunt waar gereserveerde of eigen hardware on-demand verslaat, je beperkingen voor dataresidentie en beveiliging en de piekpatronen die voor hybride pleiten. Weeg in overheids- en gereguleerde omgevingen eisen voor soevereine cloud of on-premises af die met weinig waarschuwing verplicht kunnen worden, en bevestig dat de architectuur modellen achter een interne interface houdt zodat een gedwongen verhuizing kernpaden niet herschrijft.
Bezitten we onze AI-uitgaven werkelijk, en kan elk team de kosten zien en verantwoorden die het drijft? AI-kosten schalen op verrassende manieren met gebruik, en zonder toewijzing landt de rekening als één ondoorzichtig getal waar geen team zich verantwoordelijk voor voelt het te verkleinen. In een grote organisatie zijn kosten die niemand bezit kosten die niemand optimaliseert, dus de vraag is of uitgaven aan teams en gebruiksgevallen zijn getagd met budgetten, alarmen en trends per uitkomst, of dat ze pas worden ontdekt wanneer financiën escaleert. Neem je kostentoewijzingsmodel mee, de grootste drijvers per team en de hefbomen die elke eigenaar beheerst: dimensioneren op maat, cachen, bundelen en contexttrimmen. Voeg voor budgetten van onderneming en overheid de discipline toe van meerjarige infrastructuuruitgaven voorspellen en rechtvaardigen, aangezien een publiek orgaan dat zijn rekenrekening niet regel voor regel kan uitleggen moeite zal hebben haar in een review te verdedigen.

Sectorperspectief

Startup. Bezit geen infrastructuur die je kunt vermijden. Roep een gehoste inferentie-API aan, stuur makkelijke verzoeken naar een klein goedkoop model en bewaar een groter voor moeilijke gevallen, en cache agressief zodat herhaalde prompts niets kosten. Gebruik een beheerde vectordatabase in plaats van er zelf een te beheren, houd prompts in git met een kort evaluatiescript vóór elke wijziging en log kosten per verzoek zodat een op hol geslagen rekening opduikt voordat ze pijn doet. Je schaarse middel is engineeringaandacht, dus koop beheerbaarheid en houd wisselen goedkoop.

Kleinbedrijf. Zonder platformteam behandel je serving, retrieval en observeerbaarheid als dingen die je koopt binnen tools die je al gebruikt, geen systemen die je bemant. Geef de voorkeur aan beheerde inferentie en beheerd vectorzoeken met transparante, voorspelbare prijzen, en stel vanaf dag één een hard uitgavenplafond en een factuuralarm in. Formuleer de beslissing eerlijk als kopen tegenover bouwen: GPU’s of een vectorindex beheren loont op jouw volume zelden, en een klein model achter een gehoste API voldoet meestal tegen een fractie van de inspanning.

Grote onderneming. Het probleem is een gedeeld platform op de gebaande weg over veel teams: gepoolde versnellers met planners, quota en prioriteiten om benutting omhoog te drijven, standaard bundelen en cachen, routers die op maat dimensioneren en kosten toegewezen aan elk team en gebruiksgeval. Poort prompt- en modelwijzigingen met geautomatiseerde evaluatiesuites, standaardiseer de interfacelaag zodat aanbieders en deploymentdoelen verwisselbaar blijven en beheer kosten per uitkomst als eersterangs statistiek in plaats van elke groep dure, onderbenutte infrastructuur opnieuw te laten uitvinden.

Overheid. Datasoevereiniteit, beveiliging en voorspelbare uitgaven geven elke keuze vorm. Geef de voorkeur aan on-premises of soevereine-clouddeployment zodat gevoelige data en modellen binnen gecontroleerde grenzen blijven, plan schaarse GPU’s over afdelingen met quota die je in aanbesteding kunt rechtvaardigen en voorspel capaciteit om meerjarige uitgaven regel voor regel te verdedigen. Versioneer en evalueer prompts en modellen met een vastgelegd auditspoor, houd uitgebreide observeerbaarheid over kosten en kwaliteit en houd modellen achter een interne interface zodat een gedwongen overstap naar een nieuwe aanbieder of een soeverein platform je niet laat stranden.

Voorbeelden

Startup. Een kleine startup met een AI-schrijffunctie hield haar rekening gezond zonder GPU’s te bezitten. Ze riep een gehoste inferentie-API aan, stuurde makkelijke verzoeken naar een goedkoper klein model en bewaarde het grotere voor moeilijke gevallen, en cachete antwoorden op herhaalde prompts. Ze bewaarde haar prompts in git met een kort evaluatiescript dat vóór elke wijziging draaide, gebruikte een beheerde vectordatabase voor retrieval zodat ze er geen hoefde te beheren en logde kosten per verzoek zodat de oprichters uitgaven zagen klimmen voordat het een verrassing werd.

Grote onderneming. Een mediabedrijf dat een LLM-functie met veel verkeer draaide verlaagde de inferentiekosten aanzienlijk. Het stuurde makkelijke verzoeken naar een klein model en bewaarde een groter model voor moeilijke. Het cachete antwoorden op herhaalde vragen en schakelde prefixcaching in voor zijn gedeelde systeemprompt. Het draaide GPU’s via een gedeelde planner om de benutting hoog te houden, versioneerde alle prompts in git met een geautomatiseerde evaluatiesuite die wijzigingen poort en instrumenteerde kosten per verzoek zodat elk productteam zijn uitgaven bezat.

Overheid. Een nationaal agentschap met strikte regels voor datasoevereiniteit deployde zijn AI-systemen on-premises zodat gevoelige data en modellen zijn gecontroleerde omgeving nooit verlieten. Het plande schaarse GPU’s over afdelingen met quota en prioriteiten, voorspelde capaciteit om meerjarige aanbesteding te rechtvaardigen en bouwde een vectorzoekplatform voor retrieval over officiële documenten. Prompts en modellen werden vóór release geversioneerd en geëvalueerd. Uitgebreide observeerbaarheid volgde kosten en kwaliteit, en de architectuur hield modellen achter een interne interface om een exitpad te behouden en lock-in te vermijden.

Zakelijke onderbouwing: motivatie, ROI en TCO

De motivatie voor gedisciplineerde AI-infrastructuur is eenvoudig. AI op schaal is kostbaar, en het gat tussen een geoptimaliseerde en een niet-geoptimaliseerde deployment is vaak een veelvoud in uitgaven. ROI komt uit hogere benutting van versnellers, lagere kosten per verzoek door bundelen en cachen, op maat gedimensioneerde modellen en over-provisioning vermijden. Observeerbaarheid en evaluatiepijplijnen betalen zich terug door dure incidenten te voorkomen en veilige iteratie mogelijk te maken.

De TCO omvat versnellerrekenkracht (de grootste post voor veel werklasten), vectoropslag, servinginfrastructuur, netwerken en het platform- en operatiepersoneel om het te beheren. Weeg dat af tegen de kosten van niet investeren: op hol geslagen inferentierekeningen, slechte latentie die adoptie ondermijnt en onvermogen om te schalen. Voeg bij de overheid de kosten toe van falen op eisen voor soevereiniteit of beveiliging. Maak de zaak voor het bestuur door trends in kosten per uitkomst te tonen en een platform op de gebaande weg dat veel teams AI efficiënt laat deployen, in plaats van dat elk dure, onderbenutte infrastructuur bouwt.

Antipatronen en valkuilen

Ongebruikte versnellers. Schaarse GPU’s wijden aan teams die ze onderbenut laten.
Geen bundelen of cachen. Elk verzoek afzonderlijk serveren en gedeelde context herberekenen.
Standaard het grootste model. Een duur model gebruiken waar een klein volstaat.
Kostenblindheid. Geen toewijzing, budgetten of zicht op kosten per verzoek tot de rekening aankomt.
Ongeversioneerde prompts. Prompts in productie wijzigen zonder versiebeheer of evaluatiepoort.
Staartlatentie verwaarlozen. Gemiddelde latentie optimaliseren terwijl gebruikers onder trage staarten lijden.
Stille lock-in. Diep bouwen op de servingstack van één aanbieder zonder overdraagbaarheid.

Volwassenheidsmodel

Initiëren. Ad hoc GPU-toewijzing die reageert op wie het hardst roept, geen bundelen of cachen, geen kostenzicht tot de rekening aankomt, prompts live bewerkt en ongeversioneerd, minimale bewaking.
Ontwikkelen. Sommige teams nemen gedeelde planning, cachen en prompts in versiebeheer over, maar de praktijk is inconsistent over de organisatie: de ene groep bundelt en evalueert terwijl een andere nog elk verzoek afzonderlijk serveert en prompts met de hand wijzigt.
Standaardiseren. Een gedocumenteerd platform op de gebaande weg wordt organisatiebreed afgedwongen: gedeelde planning met quota en prioriteiten, standaard bundelen, cachen en dimensioneren op maat, vectorinfrastructuur voor retrieval, geautomatiseerde evaluatiepijplijnen die elke prompt- of modelwijziging poorten en kostentoewijzing aan teams en gebruiksgevallen.
Beheersen. Het platform wordt gemeten en beheerst aan de hand van uitgangswaarden: benutting van versnellers, kosten per nuttige uitkomst, staartlatentie, retrievalrecall en kwaliteitsregressies per wijziging worden gevolgd met alarmen en drempels, kosten worden door elk team bezeten en go/no-go op een wijziging wordt beslist op bewijs in plaats van intuïtie.
Orkestreren. Infrastructuur verbetert continu en past zich aan: routering, bundelen en schalen stemmen zichzelf af op live kosten- en kwaliteitssignalen, capaciteit wordt herbalanceerd tussen teams en tussen cloud-, on-premises- en soevereine doelen naarmate vraag en beperkingen verschuiven, overdraagbaarheid wordt gerepeteerd en infrastructuurplanning is geïntegreerd met product, beveiliging en aanbesteding.

Ideeën voor discussie

Hoe drijf je de benutting van versnellers omhoog zonder prioritaire werklasten uit te hongeren?
Waar ligt de juiste balans tussen bundelen en cachen voor je latentie-eisen?
Wanneer rechtvaardigt on-premises of soevereine deployment haar kosten boven cloud?
Hoe wijs je AI-uitgaven toe en beheers je ze over veel teams?
Wat zou een prompt- of modelwijziging moeten poorten voordat ze productie bereikt?
Hoe houd je servinginfrastructuur overdraagbaar genoeg om van aanbieder te kunnen wisselen?

Belangrijkste inzichten

Versnellers zijn schaars en duur. Plan, deel en benut ze bewust.
Bundelen, cachen en modellen op maat dimensioneren zijn de belangrijkste hefbomen voor kosten en latentie.
Retrievalapplicaties hebben goed beheerde embedding- en vectorzoekinfrastructuur nodig.
LLMOps (promptversiebeheer, evaluatiepijplijnen en observeerbaarheid) is de operationele ruggengraat van generatieve AI.
Beheer kosten observeerbaar en behoud overdraagbaarheid om lock-in te vermijden.

Referenties en verder lezen

Chip Huyen, Designing Machine Learning Systems.
Google, Site Reliability Engineering (Beyer, Jones, Petoff, Murphy, editors).
Jared Kaplan et al., Scaling Laws for Neural Language Models.
Reza Yazdani Aminabadi et al., DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale.
Woosuk Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM).
Andriy Burkov, Machine Learning Engineering.