De $20 miljard zet van NVIDIA voor de groq lpu heeft zijn AI-inferentie roadmap hervormd, van GPU-architectuurkeuzes tot hoe Vera Rubin real-time workloads op schaal zal bedienen.
Summary
Binnenin NVIDIA’s $20 miljard gok op Groq
Op eerste kerstdag 2025 was de overname van NVIDIA van Groq nog slechts een telefoontje en een handdruk. Oprichter Jonathan Ross — de maker van zowel de LPU als Google’s originele TPU — was thuis toen de gesprekken begonnen. Echter, drie weken later waren er $20 miljard van eigenaar gewisseld en was Ross NVIDIA’s Chief Software Architect geworden.
Het proces begon toen Groq COO Sunny Madra contact opnam met Jensen Huang nadat NVIDIA NVLink had opengesteld voor ecosysteempartners, met de vraag of Groq ermee kon verbinden. Jensen antwoordde: “Natuurlijk, waarom niet?” Ze testten GPU–LPU workload-splitsing via Ethernet — nog geen NVLink, slechts een proof of concept. Het werkte betrouwbaar genoeg dat, binnen enkele dagen na de demo, formele overnamegesprekken begonnen.
De snelheid van de deal weerspiegelde een dringend strategisch probleem. NVIDIA kocht een gerichte oplossing voor de decodeerknelpunt waar elk GPU-datacenter mee te maken heeft in LLM-inferentie. Bovendien sloot het aan bij NVIDIA’s bredere GPU-architectuur evolutie van H100 naar Blackwell B200 en vervolgens naar het Vera Rubin platform.
Waarom GPU’s moeite hebben met LLM-token generatie
Elke LLM-inferentieaanvraag heeft twee verschillende fasen. Prefill is wanneer het model de volledige invoer — prompt, context of document — parallel verwerkt. Duizenden tokens, alle aandachtshoofden tegelijk actief. GPU’s excelleren in deze sterk parallelle workload.
Decode daarentegen is fundamenteel anders. Het model genereert output één token tegelijk, sequentieel. Elk nieuw token is afhankelijk van alle voorgaande tokens, dus het proces kan niet parallel over de sequentie worden uitgevoerd. Dat gezegd hebbende, deze sequentiële aard onthult de architectonische mismatch tussen GPU’s en token-voor-token generatie.
Tijdens elke decodeerstap haalt de GPU de volledige gewichts matrix uit HBM geheugen, voert een relatief kleine matrixvermenigvuldiging uit en geeft een enkel token uit. De gewichten veranderen niet tussen de stappen, dus dezelfde data wordt herhaaldelijk geladen. Zelfs bij 22 TB/s HBM4 bandbreedte op een Vera Rubin GPU, wordt geheugenbeweging de bottleneck omdat de berekening per stap zo licht is.
GPU’s zijn geoptimaliseerd voor massale paralleliteit, niet voor fijnmazige sequentiële uitvoering. Bijgevolg laat elke token-generatiestap een groot deel van de GPU-berekening onderbenut. Dit is precies het probleem dat de Groq 3 LPU was ontworpen om op te lossen, door het deel van de inferentie over te nemen dat gebonden is aan geheugentoegang en latentie, niet aan ruwe FLOPS.
Groq 3 LP30 ontwerp en SRAM-eerst architectuur
De LP30 chip, het hart van Groq 3, is architectonisch heel anders dan een GPU. In plaats van high-bandwidth HBM naast de chip, integreert het 500 MB on-die SRAM die 150 TB/s bandbreedte levert. Een Vera Rubin GPU daarentegen biedt 288 GB HBM4 bij 22 TB/s. De LPU heeft veel minder capaciteit, maar de geheugentoegang is bijna 7x sneller.
Dit ontwerp is doelbewust. Er is geen cache-hiërarchie, geen dynamische hardwareplanning en geen speculatieve uitvoering. In plaats daarvan stelt de LP30 vlakke SRAM bloot met fysieke bankadressering. Bovendien vervangt het het runtime-gestuurde uitvoeringsmodel van de GPU door compiler-gestuurde statische instructieplanning, waarbij de timing van elke instructie bij compileertijd is vastgelegd.
Die deterministische benadering elimineert variatie in tokenleveringstiming, wat cruciaal is voor real-time spraakagenten en latentiegevoelige toepassingen. Een GPU die tokens sequentieel genereert, ervaart onvoorspelbare vertragingen op microsecondenniveau tussen tokens, veroorzaakt door geheugendruk en planningsstatus. De LPU vermijdt deze haperingen volledig door constructie.
De LP30 omvat vier verschillende uitvoeringseenheidstypen: Matrix (MXM) voor dichte FFN matrixvermenigvuldigingen, Vector (VXM) voor puntbewerkingen en activeringen, Switch (SXM) voor datapermutatie en transpositie, en Memory (MEM) voor directe SRAM-adressering onder compilercontrole. Deze mix is geoptimaliseerd voor transformer FFN-uitvoering.
Elke LP30 chip levert 1.2 PFLOPS aan FP8-berekeningen. Het verbindt met naburige chips via 96 chip-to-chip links bij 112 Gbps elk, voor een totaal van 2.5 TB/s C2C bandbreedte per chip. Gebouwd op Samsung’s LP4X proces, verdubbelt het de SRAM-capaciteit ten opzichte van Groq’s eerste generatie chip, die 230 MB had.
Cruciaal is dat de LPU niet bedoeld is om GPU’s te vervangen. Het is ontworpen om naast Vera Rubin GPU’s te zitten in een gesplitst-uitvoeringsmodel, waarbij elk processortype het deel van de workload afhandelt dat bij zijn architectuur past. Het efficiënt maken van die splitsing vereiste echter een nieuw systeemontwerp.
Attention-FFN Disaggregatie en systeemniveau splitsing
NVIDIA noemt de architectuur Attention-FFN Disaggregatie (AFD). Het kerninzicht is dat een decoderlaag van een transformer twee zeer verschillende soorten werk bevat, en verschillende hardware wint bij elk: aandacht versus feed-forward netwerken.
Aandacht is contextafhankelijk. Het leest de KV cache — de buffer die tussentijdse aandachtberekeningen opslaat die lineair groeit met de sequentielengte — berekent aandachtsscores over alle voorgaande tokens en produceert tussentijdse activeringen. De berekening schaalt met de contextlengte, dus het heeft hardware nodig met grote HBM-capaciteit om de KV cache vast te houden. Die rol valt toe aan de Rubin GPU.
Het FFN pad daarentegen is contextonafhankelijk. Dezelfde gewichts matrices worden gebruikt ongeacht de specifieke prompt; alleen de binnenkomende activeringen verschillen per token. Moderne MoE-modellen worden gedomineerd door FFN-parameters: DeepSeek R1 heeft 669 miljard FFN-parameters van de in totaal 685 miljard, of 97,7%. Kimi K2 bereikt 98,9%. Deze gewichten kunnen op rack-schaal in SRAM passen, en het laden ervan bij 150 TB/s is aanzienlijk sneller dan 22 TB/s van HBM4.
In de praktijk werkt de splitsing als volgt: een Vera Rubin NVL72 complex behandelt prefill, KV cache constructie en decodeer aandacht. Het Groq 3 LPX systeem neemt decodeer FFN en MoE-routing op zich. Voor een model met 40 decoderlagen betekent dat 40 rondreizen per token, waarbij activeringen van GPU naar LPU en terug stromen voor elk gegenereerd token.
Dit alles wordt gecoördineerd door NVIDIA Dynamo, een softwarelaag die binnenkomende verzoeken classificeert, prefill naar GPU-werkers routeert, de per-token AFD-lus beheert en KV-bewuste planning uitvoert zodat nieuwe tokens landen op werkers die de relevante cache al bevatten. Bovendien coördineert het netwerken zodat cross-rack verkeer wordt geminimaliseerd.
Zoals Jonathan Ross uitlegde tijdens zijn GTC 2026 sessie: “Als je alles op de LPU draait, zou je het onderbenutten op aandacht. Als je alles op de GPU draait, onderbenut je het op de FFN-lagen. Door ze samen te voegen, gaat de benutting voor beide omhoog.” Die opmerking vat de logica achter de nvidia groq overname netjes samen.
Kortom, Rubin GPU’s behandelen wat grote HBM vereist — aandacht over lange contexten en KV cache opslag. Groq’s LPU behandelt wat extreme geheugendoorvoer en deterministische timing nodig heeft — FFN gewichten geleverd bij 150 TB/s voor elk token.
Groq 3 LPX rackontwerp en prestatieomvang
Het AFD-model werkt alleen als de Groq 3 LPX voldoende schaalt om de FFN-workload te dekken. Bij 256 LP30 chips bereikt het die schaal. Het LPX-rack integreert 256 chips over 32 vloeistofgekoelde rekken, met 8 chips per rek in een all-to-all topologie om intra-rack latentie laag te houden.
Rack-niveau specificaties zijn aanzienlijk. Totale SRAM over de 256 chips is 128 GB. Totale rack-schaal bandbreedte bereikt 640 TB/s. FP8-berekeningen pieken op 315 PFLOPS. Inter-rack connectiviteit biedt ongeveer 448 GB/s per richting per rek, met behulp van een Dragonfly topologie met een maximale drie-hop diameter.
Wanneer gecombineerd met Vera Rubin NVL72, levert dit platform dramatische efficiëntiewinsten. Volgens NVIDIA bereikt het gecombineerde Vera Rubin NVL72 + LPX-systeem 35x hogere inferentie doorvoer per megawatt dan een Grace Blackwell NVL72-systeem alleen. Belangrijk is dat de vergelijking is tegen Blackwell NVL72, niet oudere H100-configuraties.
Tijdens de GTC-keynote toonde Jensen Huang interactieve doelen van 800–1.000 tokens per seconde voor real-time workloads met dit gecombineerde systeem. Echter, een cruciale verduidelijking van hetzelfde evenement is dat het LPX-rack geen goedkopere alternatief is voor NVL72.
Toen een lid van het publiek suggereerde dat LPX minder kostbaar zou kunnen zijn, reageerde Ross: “Ik ben het daar eigenlijk niet mee eens dat het minder kostbaar is. Er zit veel silicium in dat rek.” Het LPX wordt gepresenteerd als een premium uitbreiding van het Vera Rubin platform voor klanten die ultra-lage latentie inferentie op schaal nodig hebben, niet als een budget inferentiekaart.
Er is ook een harde limiet op de modelgrootte. Met 128 GB SRAM kan een LPX-rack modellen hosten tot ongeveer 53 GB in FP8. Grotere modellen zoals DeepSeek R1, met 623 GB aan FFN-gewichten in FP8, vereisen het koppelen van meerdere LPX-racks via frontpaneel C2C-poorten en het distribueren van FFN-gewichten over racks. Dat gezegd hebbende, zijn Dynamo en NVIDIA’s netwerkstack ontworpen om veel van deze complexiteit voor eindgebruikers te verbergen.
Rubin CPX annulering en Vera Rubin integratie
De overname van Groq loste ook een productplanningsconflict op. Aanvankelijk omvatte de Vera Rubin roadmap een tweede GPU-variant genaamd Rubin CPX, een GDDR7-gebaseerde chip geoptimaliseerd voor lange context en KV cache workloads. Tijdens GTC 2026 vroeg een deelnemer Ross direct of Rubin CPX was geannuleerd.
Ross ontweek met “één vraag per persoon” en gaf geen direct ja of nee. Echter, in een aparte Ian Buck pers Q&A, bevestigde NVIDIA dat CPX is geschrapt en dat LPU-gebaseerde decodeer dit jaar in plaats daarvan zal worden verzonden. De LPU lost hetzelfde contextonafhankelijke, geheugencapaciteit inferentieprobleem op met behulp van toegewijde SRAM in plaats van een GPU-variant.
Als gevolg daarvan standaardiseert Vera Rubin integratie nu op Rubin GPU’s voor aandacht en KV cache taken, terwijl LPX-racks de verantwoordelijkheid op zich nemen voor FFN-uitvoering en MoE-dispatch. Bovendien vereenvoudigt dit de productstack: in plaats van het prolifereren van GPU SKU’s, leunt NVIDIA op een duidelijke GPU–LPU arbeidsverdeling.
Veelgestelde vragen over LPU en Rubin
Waarom niet gewoon meer Rubin GPU’s inzetten?
Het toevoegen van meer Vera Rubin GPU’s verhoogt de totale batchdoorvoer — meer parallelle verzoeken kunnen tegelijkertijd worden bediend. Het verbetert echter niet de decodeerlatentie voor een enkel verzoek, omdat token generatie inherent sequentieel blijft ongeacht het aantal GPU’s. De LPU is ontworpen om de latentie per verzoek te verminderen, niet alleen de systeemwijde doorvoer, waardoor de twee benaderingen complementair zijn.
Hoe wordt de 35x doorvoerverbetering gemeten?
Het 35x cijfer is een systeemniveau metriek. Het vergelijkt een volledige Vera Rubin NVL72 plus Groq 3 LPX implementatie tegen een Grace Blackwell NVL72-alleen systeem, gemeten in tokens per seconde per megawatt. Het is geen verbetering per GPU, en de basislijn sluit expliciet kleinere configuraties zoals B200x8 of H100x8 uit.
Waar is de GPU-naar-LPU bottleneck?
Rack-naar-rack latentie is een reële overweging. Een Microsoft-ingenieur bracht dit punt direct naar voren tijdens de GTC-sessie. Ross erkende de zorg en zei dat netwerkverbeteringen in uitvoering zijn. Ondertussen behandelt Dynamo KV-bewuste routing om onnodige overdrachten te minimaliseren, en NVIDIA’s Mellanox netwerkstack beheert inter-rack verbindingen om de latentie zo laag mogelijk te houden.
Kan de LPU modellen trainen?
Nee. De LPU is strikt alleen decodeer. Zijn compiler-gestuurde statische planning, die FFN-uitvoering zo snel en deterministisch maakt, is slecht geschikt voor de dynamische en iteratieve aard van backpropagation. Trainingsworkloads blijven daarom op Rubin GPU’s, die zijn ontworpen voor flexibele, hoge doorvoer berekeningen.
Wanneer zal Groq 3 LPX beschikbaar zijn?
Ross bevestigde tijdens GTC dat Groq 3 LPX al in productie is. Jensen Huang kondigde Q3 2026 aan als de tijdlijn voor klantbeschikbaarheid, in lijn met de bredere Vera Rubin platformuitrol. Ross beschreef de reis van kerstmisdagbesprekingen naar het GTC-podium als “waarschijnlijk een van de snelste halfgeleideropvoeringen in de geschiedenis,” die ongeveer drie maanden besloeg.
Strategische implicaties voor AI-inferentie
De groq lpu architectuur vult een gat dat geen enkele GPU-variant kon dichten, niet omdat GPU’s transistors of geheugen missen, maar omdat sequentiële, latentiegevoelige FFN-decode niet overeenkomt met hun parallelle ontwerp. Naarmate gebruikersvolumes groeien, raken meer gelijktijdige verzoeken elk datacenter, en elke milliseconde van per-token latentie stapelt zich op over duizenden sessies.
De overname signaleerde NVIDIA’s erkenning dat GPU’s alleen niet voldoende zijn voor de decodeerkant van LLM-inferentie. Bovendien bevestigde het een bredere verschuiving in de industrie: gespecialiseerde versnellers komen op om algemene GPU’s aan te vullen, niet om ze volledig te vervangen.
Compiler-gestuurde SRAM bij 150 TB/s is het juiste gereedschap voor FFN-uitvoering. HBM4 bij 22 TB/s is het juiste gereedschap voor aandacht over lange contexten en KV-zware workloads. De $20 miljard gok is dat het gebruik van beide samen — gecoördineerd door Dynamo en verbonden via NVLink en high-speed C2C links — een systeem creëert dat geen van beide alleen zou kunnen evenaren.
Op basis van NVIDIA’s GTC 2026 aankondigingen en officiële documentatie, richt Groq 3 LPX zich op beschikbaarheid in Q3 2026. Als de opvoering op schema blijft, zou de gecombineerde Rubin–LPU stack de referentiearchitectuur kunnen definiëren voor grootschalige AI inferentie in de tweede helft van het decennium.
