Waarom AI-inferentie, niet training, de volgende grote uitdaging voor ingenieurs is

Voor het afgelopen decennium heeft de aandacht in de kunstmatige intelligentie grotendeels in beslag genomen door training. De doorbraken kwamen grotendeels van massive compute-clusters, trillion-parametermodellen en de miljarden dollars die zijn besteed aan het leren van systemen om “te denken”. We hebben AI-ontwikkeling grotendeels behandeld als een bouwproject: het bouwen van de wolkenkrabber van intelligentie. Maar nu deze wolkenkrabber is gebouwd, is de echte uitdaging het faciliteren van de miljoenen die erin moeten wonen en opereren. Dit verschuift de focus van AI-onderzoekers en -ingenieurs van training (het creëren van intelligentie) naar inferentie (het gebruik ervan). Terwijl training een massive, eenmalige kapitaaluitgave (CapEx) is, is inferentie een doorlopende operationele uitgave (OpEx) die onbeperkt doorgaat. Als bedrijven agents implementeren die miljoenen gebruikers wereldwijd bedienen, ontdekken ze een harde realiteit: inferentie is niet alleen “training in omgekeerde volgorde”. Het is een fundamenteel andere, en misschien moeilijkere, ingenieursuitdaging.

Waarom inferentiekosten meer dan ooit belangrijk zijn

Om de ingenieursuitdaging te begrijpen, moet men eerst de onderliggende economische imperatief begrijpen. In de trainingsfase is inefficiëntie te tolereren. Als een trainingsrun vier weken in plaats van drie duurt, is het een irritatie. Bij inferentie kan inefficiëntie echter catastrofaal zijn voor bedrijven. Het trainen van een frontiermodel kan bijvoorbeeld 100 miljoen dollar kosten. Maar het implementeren van dat model om 10 miljoen queries per dag te beantwoorden, kan die kosten overtreffen in een kwestie van maanden als het niet wordt geoptimaliseerd. Dit is waarom we getuige zijn van een marktverschuiving, waarbij investeringen in inferentie worden verwacht om investeringen in training te overtreffen.

Voor ingenieurs verandert dit de doelstellingen. We zijn niet langer aan het optimaliseren voor doorvoer (hoe snel kan ik deze massive dataset verwerken?). We zijn aan het optimaliseren voor latentie (hoe snel kan ik één token teruggeven?) en concurrentie (hoeveel gebruikers kan ik bedienen op één GPU?). De “brute force”-aanpak die de trainingsfase domineerde door simpelweg meer computes toe te voegen, werkt hier niet. Je kunt niet meer H100’s toevoegen aan een latentieprobleem als de bottleneck de geheugengrootte is.

De geheugengrens: de echte bottleneck

De weinig bekende waarheid over Large Language Model (LLM)-inferentie is dat het zelden wordt beperkt door compute; het wordt beperkt door geheugen. Tijdens training verwerken we data in massive batches, waardoor de GPU’s compute-eenheden volledig worden benut. Bij inferentie, vooral voor real-time-toepassingen zoals chatbots of agents, komen verzoeken sequentieel binnen. Elk gegenereerd token vereist dat het model zijn miljarden parameters laadt uit high-bandwidth-geheugen (HBM) in de compute-kernen. Dit is de “geheugengrens“. Het is alsof je een Ferrari-motor (de GPU-kern) hebt die vastzit in een file (de beperkte geheugengrootte).

Deze uitdaging dwingt ingenieurs om de systeemarchitectuur opnieuw te bekijken, tot op het niveau van de silicium. Dit is waarom we de opkomst zien van Lineaire Verwerkingseenheden (LPUs) zoals die van Groq, en gespecialiseerde Neurale Verwerkingseenheden (NPUs). Deze chips zijn ontworpen om de HBM-bottleneck te omzeilen door gebruik te maken van massive hoeveelheden on-chip-SRAM, waardoor geheugen-toegang wordt behandeld als een continue gegevensstroom in plaats van een eenvoudige fetch-operatie. Voor de software-ingenieur betekent dit het einde van de “default to CUDA”-periode. We moeten nu code schrijven die hardware-georiënteerd is, waarbij we exact begrijpen hoe gegevens door de draad gaan.

De nieuwe frontier van AI-efficiëntie

Omdat we de hardware niet altijd kunnen veranderen, ligt de komende frontier van ingenieurswerk in software-optimalisatie. Hier gebeuren enkele van de meest innovatieve doorbraken op dit moment. We zien een renaissance van technieken die opnieuw definiëren hoe computers neurale netwerken implementeren en uitvoeren.

• Continue batching: Traditionele batching wacht tot een “bus” vol is voordat het vertrekt, waardoor vertragingen ontstaan. Continue batching (geïntroduceerd door frameworks zoals vLLM) werkt als een metrosysteem, waarbij nieuwe verzoeken kunnen aansluiten of afstappen bij elke iteratie. Het maximaliseert de doorvoer zonder latentie te offeren, waardoor een complexe planningsprobleem wordt opgelost dat diepe OS-niveau-expertise vereist.

• Speculatieve decoding: Deze techniek gebruikt een klein, snel en goedkoop model om een antwoord te schetsen, terwijl een groter, langzamer en krachtiger model het in parallel verifieert. Het vertrouwt op het feit dat tekst verifiëren veel minder computationeel duur is dan tekst genereren.
• KV-cachebeheer: In lange conversaties groeit de “geschiedenis” (de Key-Value-cache) snel, waardoor grote hoeveelheden GPU-geheugen worden verbruikt. Ingenieurs implementeren nu “PagedAttention“, een techniek geïnspireerd door virtuele geheugen-paging in besturingssystemen. Deze techniek breekt het geheugen op in fragmenten en beheert het niet-contigu.

De agente-complexiteit

Als standaard-inferentie al moeilijk is, maakt Agente-AI het exponentieel moeilijker. Een standaard chatbot is staatloos: de gebruiker vraagt, de AI antwoordt, het proces eindigt. Een AI-agent heeft echter een lus. Het plant, voert tools uit, observeert resultaten en herhaalt. Vanuit een ingenieursperspectief is dit een nachtmerrie. Deze architectuur-introductie introduceert enkele fundamentele uitdagingen:

1. Toestandsbeheer: De inferentie-engine moet de “toestand” van het denkproces van de agent over meerdere stappen behouden, vaak over een periode van minuten.
2. Oneindige lussen: In tegenstelling tot een voorspelbare forward-pass, kan een agent vast komen te zitten in een redeneerlus. Het ontwikkelen van robuuste “watchdogs” en “circuit breakers” voor probabilistische code is een geheel nieuw veld.
3. Veranderlijke compute: Één gebruikersverzoek kan één inferentie-aanroep triggeren, terwijl een ander er vijftig kan triggeren. Het beheren van de belasting en het autoscalen van de infrastructuur wanneer elk verzoek een extreme variatie in belasting met zich meebrengt, vereist een geheel nieuwe klasse van orkestratie-logica.

We bewegen ons in feite van “het serveren van modellen” naar “het orkestreren van cognitieve architectuur”.

AI naar alledaagse apparaten brengen

Tenslotte zullen de grenzen van energie en netwerklatentie uiteindelijk inferentie naar de rand dwingen. We kunnen niet verwachten dat elke slimme lichtbron, autonome voertuig of fabrieksrobot zijn verzoeken via een datacenter routeert. De ingenieursuitdaging hier is compressie. Hoe pas je een model aan dat is geleerd van het hele internet aan op een chip die kleiner is dan een vingernagel, die op een batterij draait?

Technieken zoals kwantificatie (het verminderen van precisie van 16-bit naar 4-bit of zelfs 1-bit) en model-distillatie (het leren van een klein studentenmodel om een groot leraar-model na te bootsen) worden standaardpraktijk. Maar de echte uitdaging is het implementeren van deze modellen op een gefragmenteerd ecosysteem van miljarden apparaten zoals Android, iOS, ingebedde Linux, aangepaste sensoren, elk met zijn eigen hardware-beperkingen. Het is de “fragmentatienachtmerrie” van mobiele ontwikkeling, vermenigvuldigd met de complexiteit van neurale netwerken.

De bodemlijn

We treden de “Dag 2”-periode van Generatieve AI binnen. Dag 1 was over het demonstreren dat AI gedichten kon schrijven. Dag 2 is over ingenieurswerk, het maken van die mogelijkheid betrouwbaarder, betaalbaarder en alomtegenwoordig. De ingenieurs die de komende decennia zullen definiëren, zijn niet noodzakelijk degene die nieuwe modelarchitecturen uitvinden. Ze zijn de systeemingenieurs, de kernel-hackers en de infrastructuur-architecten die kunnen uitvinden hoe ze een miljard tokens per seconde kunnen serveren zonder de stroomgrid te laten smelten of het bedrijf failliet te laten gaan. AI-inferentie is niet langer alleen een runtime-detail. Het is het product. En het optimaliseren ervan is de volgende grote ingenieursuitdaging.