9min Devices

LLM’s in chips ‘bakken’ gaat de grootste AI-bottleneck niet wegnemen

LLM’s in chips ‘bakken’ gaat de grootste AI-bottleneck niet wegnemen

Met de overname van Taalas heeft AMD een “pionier op het gebied van gespecialiseerde AI-inferencing-chips” in huis gehaald. Nog maar enkele weken geleden kwamen er details naar buiten over een interne “Frozen v2”-chip van Google waarin delen van de Gemini-modelarchitectuur zijn ingebouwd. Nu ook OpenAI en Anthropic zich opmaken om hun eigen processors te bouwen (die vermoedelijk eveneens “LLM-vormig” zullen zijn) rijst de vraag: wat zijn de voordelen van deze aanpak? En, nog belangrijker, welke andere beperkingen blijven er bestaan?

We zien al enige tijd een steeds grotere verfijning bij het draaien van Large Language Models. Overeenkomsten met zowel AWS als AMD hebben de mogelijkheden van de enorme chips van Cerebras benadrukt voor specifieke onderdelen van AI-inferencing, de workload die tokens als prompt ontvangt en deze vervolgens genereert voor een antwoord. Het eerste onderdeel, prefill, wordt sterk beperkt door rekenkracht, terwijl decode in het aantal output-tokens wordt beperkt door geheugenbandbreedte. Het is daarom logisch om AI-inferencing op te splitsen. Meer in het algemeen zijn de hierboven genoemde ontwikkelingen echter ambitieuzer. Ze zijn gericht op het optimaliseren van inferencing met wat The Register ‘MSIC’s’ noemt, oftewel Model-Specific Integrated Circuits. Dat is tegelijkertijd heel logisch en heel onlogisch.

Waarom het etsen van modellen nu zinvol is

Zoals gezegd kent inferencing bottlenecks op verschillende vlakken. Maar de onderliggende oorzaak van die bottlenecks is een mismatch tussen ontwerp en gebruik. GPU’s, TPU’s, Trainium, zelfs de zogenaamd op AI gerichte NPU’s in sommige pc’s: ze zijn allemaal in zekere mate geoptimaliseerd voor het rekenkundige werkpaard van AI, matrixvermenigvuldiging. Ze voeren die berekeningen parallel uit, met tienduizenden cores die kunnen bijspringen. Er zijn allerlei beperkingen aan de grootte van individuele processors, de snelheid van de koperen verbindingen ertussen en nog veel meer. Daar hoeven we hier niet te diep op in te gaan, maar het volstaat te zeggen dat je je hardware anders zou specificeren als je er alleen LLM’s op wilde draaien.

Dit is waar iets als de Taalas HC1 Technology Demonstrator om de hoek komt kijken. Gebouwd op TSMC’s wat oudere 6nm-procedé, met slechts een kwart van het aantal transistors van een Nvidia B200, draait deze chip Llama 3.1 8B op 16.960 tokens per seconde per gebruiker. Dat is ronduit een duizelingwekkend getal: 48 keer zo snel als de eerdergenoemde B200 van Nvidia met 353 t/s. Cerebras, dat zichzelf omschrijft als producent van “’s werelds snelste AI”, is met 1.981 t/s 8,5 keer langzamer. Het heeft 75 keer meer transistors nodig dan Taalas om die snelheid te halen, nota bene op een kleiner TSMC-procedé.

Maar dan is er nog dat ‘Technology Demonstrator’-gedeelte. Llama 3.1 met 8 miljard parameters was al een relatief zwak model ten opzichte van de AI-voorhoede… in 2024. Het punt is natuurlijk dat je elk klein model op deze manier in silicium kunt omzetten, met vergelijkbaar verbluffende snelheidswinst. Hier komt de overname door AMD, waarvan de voorwaarden niet bekendgemaakt zijn, in beeld. Hoewel AMD zijn MI400 Instinct-GPU’s meer op AI-inferencing dan op training richt, is er goede reden om ook op andere chipontwerpen in te zetten. Nvidia deed hetzelfde met de acqui-hire van Groq voor 20 miljard dollar enkele maanden geleden, en Googles eerdergenoemde Frozen v2 wijst op dezelfde diversificatie, weg van alleen TPU’s en door GCP gehoste GPU’s.

De algemene consensus is duidelijk verschoven richting het etsen van modellen in silicium, zij het op experimentele wijze, terwijl diversificatie weg van één monolithische, geparallelliseerde processor nu al concrete winst oplevert voor elke LLM. Claude Fable 5, de huidige state-of-the-art LLM die voor vrijwel elke betalende klant beschikbaar is, draait op verschillende soorten silicium (met name GPU’s, TPU’s en Trainium). De logische vervolgvraag: hoe zou de wereld eruitzien als niet Llama 3.1 8B, maar Fable 5, met hoeveel biljoen parameters dan ook, op ‘warp speed’ zou kunnen draaien?

Toegegeven: modelspecifieke chips kennen een inherente vertraging. LLM-generaties gaan ongeveer even lang mee als die van vuurvliegjes. Het ontwerpen, testen, produceren en opschalen van een chip kost nog altijd vele maanden, vaak jaren. We gaan ervan uit dat volwassen (en dus goedkopere en sneller te gebruiken) procedés, reproduceerbare ontwerpen en co-engineering die vertraging kunnen beperken, maar dit is een reëel probleem als modelspecifieke chips gemeengoed moeten worden. Toch laten we dit voor nu verder buiten beschouwing.

Snelheid is niet (alleen) het antwoord

Het wordt een erg interessante dag wanneer OpenAI eindelijk de beloofde 750 tokens/seconde-versie van GPT-5.6 Sol beschikbaar stelt. Die draait op de gigantische wafer-scale engine van Cerebras en is al beschikbaar voor geselecteerde preview- en prioriteitsklanten. Het aanbod zou “tot” tien keer sneller zijn dan andere instances, die meestal op Nvidia-GPU’s draaien. Onder bepaalde omstandigheden maakt zo’n capabel AI-model op deze hoge snelheden gloednieuwe toepassingen mogelijk. Denk aan de snelst mogelijke complexe analyses van financiële transacties, data-extractie op hoge snelheid en communicatie tussen AI’s onderling. Dat laatste vraagt om wat uitleg: op dit moment wordt AI-gebruik, zoals AI-expert Andrew Ng twee jaar geleden al aanstipte, voornamelijk door mensen aangestuurd. Op hogere snelheden, dichter bij computationele tijdschalen (denk microseconden en nanoseconden, niet 200 milliseconden), kan inferencing workloads slim bijsturen, netwerken intelligent routeren, compliance waarborgen, ruis wegfilteren, enzovoort – en dat allemaal tijdens runtime.

Op dit moment is dat zelfs met piepkleine AI-modellen onpraktisch. Deze kleinere modellen zijn simpelweg nog te traag om op te starten – ze moeten in het geheugen worden geladen, dat ze vervolgens bezet houden – en blijven wat onbetrouwbaar vergeleken met deterministische oplossingen en grotere, tragere modellen. De algoritmes die momenteel achter de schermen draaien in alledaagse toepassingen zijn grotendeels niet gebaseerd op generatieve AI en bestaan al helemaal niet uit miljarden parameters. Ze zijn al geoptimaliseerd om meedogenloos klein te zijn.

Er zijn echter nog veel, veel meer limieten dan alleen de inferencing-snelheid van LLM’s. De makkelijkst te bevatten is die van het licht: alles wat je niet rechtstreeks op je eigen machine draait, kent een natuurlijke snelheidslimiet, en dat wordt relevant voor cloud-workloads. Voor gebruikers die met LLM’s werken is dit doorgaans prima, aangezien tokengeneratie en redeneerwerk vele minuten in beslag kunnen nemen. Maar wanneer die tokengeneratietijden richting nul gaan, duiken er andere bottlenecks op. Die gaan verder dan de lichtsnelheid, zeker bij agentic workflows.

Denk aan elke keer dat je merkbare vertraging op een computer hebt ervaren. Dat gebeurt vaak, en is vaak acceptabel. Wie weleens een langlopende agentic workflow heeft gevolgd, weet dat deze beperkingen (een pagina die laadt, een API- of MCP-aanroep) geregeld niet de grootste bottleneck vormen. Maar bij LLM’s die duizenden tokens per seconde of meer verwerken, is elke wachttijd van 500 milliseconden ronduit gigantisch. Zou je de tokengeneratie van deze langlopende workloads vol tool-aanroepen in een grafiek uitzetten, dan zie je nu een consistente piek, een tijdelijke pauze en daarna een terugkeer naar bijna volledige benutting. Met MSIC’s zouden ze snel op gang komen, gevolgd door een naar verhouding gigantisch dal en daarna weer een zeer korte piek. Dat zal niet altijd zo zijn, maar AI-systemen zullen voortdurend tegen verouderde snelheidsbarrières aanlopen.

De wereld etsen?

Niet elke toekomstige bottleneck laat zich wegetsen in silicium. Afgezien van de lichtsnelheid – die momenteel niet eens de beperkende factor is voor de koperen bedrading in en rond AI-versnellers – blijft de omgang van AI met de huidige IT-infrastructuur een hardnekkig probleem. We zagen CPU’s hun AI-prestaties opvoeren, geheugenpools meegroeien met stijgende parameteraantallen, bandbreedtelimieten sneuvelen door nieuwe netwerkstandaarden, en tal van vooruitgang in en rond LLM’s zelf. Maar een willekeurig AI-model in silicium omzetten, zelfs het meest geavanceerde, werpt op zichzelf weer een flinke horde op.

Er gaan ook geluiden op dat AI-bedrijven naar deze geëtste oplossingen grijpen vanwege een vermeend gebrek aan interne overtuiging. Immers: als insiders ervan uitgaan dat LLM’s hun technische maximum naderen, is het eerste wat ze zouden doen het draaien ervan optimaliseren om de operationele kosten te drukken. Toch zijn wetgeving en een opkomende wens in de AI-industrie om modelontwikkeling af te remmen extra argumenten om langer vast te houden aan de huidige stand van de techniek in AI. We zullen betere LLM’s blijven zien die taken consistenter uitvoeren, en ook steeds meer use cases voor die modellen.

Conclusie

Een verschuiving naar snellere modellen en naar verhouding tragere infrastructuur brengt andere afwegingen met zich mee. Hoe revolutionair tool-calling het afgelopen jaar ook is geweest voor de bruikbaarheid van AI, het wordt verstandiger om de LLM zoveel mogelijk werk te laten doen zonder API-/MCP-aanroepen of tools. Wellicht brengt dat iemand op het lumineuze idee om de tools zelf verder te optimaliseren, of ze zelfs óók in silicium te bakken…

Er valt hier een groter punt te maken. Hoezeer de adoptie van AI ook achterblijft bij de marketingcampagnes en software-integraties, we hebben zelfs het volledige potentieel van de AI-modellen van gisteren nog niet benut, laat staan dat van vandaag. Bedenk eens welke nuttige toepassingen de IT-industrie had verzonnen als ze te horen had gekregen dat er alleen maar, pak ‘m beet, GPT-4 of o1 of Claude Fable zou komen. Geef deze LLM’s de tijd en je kunt om hun beperkingen heen werken, de wereld eromheen optimaliseren en het silicium bouwen om ze zo snel te laten draaien als de natuur toestaat.

Op dit moment lijken we daar een glimp van op te vangen. Verwacht dat LLM’s langzamer vooruitgang boeken, maar dat de infrastructuur waarop ze draaien naar verhouding een sprong voorwaarts maakt. Dat geeft de tijd om de AI-uitbouw netjes af te stemmen op de vraag, en om chipontwerpen te optimaliseren voor een bekende workload. Het silicium wordt meer een verbruiksartikel naarmate de architecturen sneller verouderen dan huidige GPU-generaties doen. De wens om de hardware maximaal te benutten zal echter vooruitgang op andere vlakken aanjagen en de aandacht vestigen op andere bottlenecks. Kort gezegd is dat knelpunt de verouderde infrastructuur: zowel de software als de hardware die nog altijd in gebruik is, terwijl cloud-workloads, tools en databronnen erdoorheen stromen. Het oplossen van die niet-AI-snelheidslimieten is de uitdaging op lange termijn, willen LLM’s niet slechts lopen, maar rennen.