Google Transcript: Co-design van TPUs, gedistribueerde systemen en frontier AI-modellen
Google Dev Labs Fireside Chat met Jeff Dean en Bill Jia over het opschalen van AI-systemen, 20 september 2026
Inclusief introductie en de beginjaren van Google
Host: Wel allemaal hartelijk welkom. Ontzettend bedankt voor jullie aanwezigheid en enthousiasme. Dit is onze zevende editie van Dev Labs, en elke keer weer wordt het groter en beter. Dit is met voorsprong de beste tot nu toe. We kregen gigantisch veel belangstelling, waarvoor dank voor jullie feedback. We gaan het zo meteen hebben over een aantal vragen en de evolutie van TPUs. Dit is Jeff, die natuurlijk geen introductie behoeft. Hij was werknemer nummer 30 bij Google. Laten we daarmee beginnen, en we hebben Bill hier ook. Hij zal eveneens vragen stellen, maar we willen ook graag dat hij wat inzichten deelt over de uitvoering van de AI-infrastructuur, de visie en hoe dit momenteel en in de komende jaren wordt gerealiseerd, als dat goed is. Goed, laten we beginnen. Jeff, vertel ons eens wat meer. Je was werknemer nummer 30 bij Google.
Jeff Dean: Zeker.
Host: 1999. De meeste mensen hier waren toen nog niet eens geboren, of zaten wellicht nog in de luiers. Hoe was dat?
Jeff Dean: Nou, het was ontzettend leuk. Toen ik erbij kwam, zaten we met z'n allen in een piepklein kantoor in het centrum van Palo Alto, ingeklemd boven wat nu een T-Mobile-winkel is, zo ongeveer die schaal van een kantoor. We probeerden een zoekproduct van heel hoge kwaliteit te bouwen. Ik had daar in een eerdere baan al wat ervaring mee opgedaan op het gebied van information retrieval, met name op het web, waarbij ik de grafstructuur van het web gebruikte om de bestaande informatie op pagina's aan te vullen enzovoort. Google leek me daarom een logische plek om dat te proberen in een minder academische omgeving, waar mensen mijn werk direct gebruikten, wat superleuk was. De energie was enorm en ons verkeer groeide wekelijks met zo'n 7%. Als je 1,07 tot de macht 52 berekent, weet je dat je elk jaar uit je voegen barst en probeert om op dinsdag om twaalf uur 's middags niet om te vallen. Dat was dus erg leuk. En naarmate het bedrijf is blijven groeien, zijn we steeds meer dingen gaan doen, wat altijd spannend is om te zien.
Host: En wat gebeurde er in 2001, als we een sprong voorwaarts maken?
Jeff Dean: Om te voorkomen dat we uit onze voegen barsten, waren we voortdurend bezig om het volledige zoek-, indexerings- en query-servingsysteem te herschrijven zodat het efficiënter werd en gebruikmaakte van andere datastructuren en compactere representaties. In 2001 kwamen we op een punt waarop we beseften dat we de indexgrootte en de capaciteit voor het bedienen van de index opschaalden door steeds meer partities van de index te maken. We noemden die shards om een grotere index te krijgen. Van elk van die shards maakte je vervolgens steeds meer kopieën om capaciteit te leveren voor het gelijktijdig verwerken van meer queries. Uiteindelijk kwamen we op een punt waarop we, in plaats van 7 shards met elk 10 kopieën, zo'n 60 shards en 20 kopieën van elke shard in elk datacenter hadden. Uiteindelijk maakten we de berekening en beseften we dat we, in plaats van de index op schijf te zetten, de volledige webindex in het geheugen konden plaatsen op de 1.200 machines die anders dienst zouden doen als 20 kopieën van de 60 partities. Dat was echt fantastisch. We versnelden ons hele zoeksysteem in 3 dagen tijd met ongeveer een factor 4, wat erg leuk was, ja.
De gedaante van de TPU: Van spraakherkenning tot maatwerk ASICs
Host: En in 2013 maakte je wat berekeningen op een bierviltje.
Jeff Dean: Ja, klopt. Ik begon te werken aan infrastructuur voor deep learning-training en het trainen van deep learning-modellen, omdat dat de juiste abstractie leek. Ik had in 1990 tijdens mijn bachelor al kennisgemaakt met neurale netwerken en deed een bachelorscriptie over het parallel trainen daarvan, omdat ik vond dat dit de juiste weg was. We moesten gewoon 32 zwakke processoren inzetten in plaats van één, en dan zouden we geweldige modellen kunnen trainen. Het bleek dat we ongeveer een miljoen keer zoveel rekenkracht nodig hadden, in plaats van 32. Maar uiteindelijk, dankzij verbeteringen volgens de wet van Moore en dergelijke, begonnen we dat rond 2008 of 2009 te krijgen. In 2011 startten we vervolgens een project om serieus op te schalen en gedistribueerde training van modellen voor spraak, visie en taal uit te voeren op—in die tijd hadden we CPU's in onze datacenters, heel veel CPU's. We gebruikten dus ongeveer 16.000 CPU-cores om een groot visueel model te trainen, en we boekten fantastische verbeteringen. Dat deden we ook voor spraakmodellen, en de modellen lieten verbluffende kwaliteitsverbeteringen zien. We bereikten dus het equivalent van de laatste 20 jaar aan spraakonderzoek qua verbetering in word error rate in de twee maanden dat we probeerden een diep akoestisch spraakmodel te bouwen. Dat was een moment van: jeetje, dit wordt zo goed. Maar hoe gaan we dit serveren?
In die periode deed ik berekeningen waarin ik stelde: oké, stel dat 100 miljoen mensen een paar minuten per dag tegen hun telefoon gaan praten, hoe gaan we dat dan in vredesnaam faciliteren? Het bleek dat we het aantal computers van Google hadden moeten verdubbelen alleen maar om dat betere spraakherkenningsmodel uit te rollen in één heel klein, obscure onderdeel van Google. Dat leek me wat overdreven, om nog maar te zwijgen van onpraktisch. Daarom besloten we dat gespecialiseerde hardware de juiste weg was. Dat is zo ongeveer de oorsprong van de TPU-familie: we wilden gespecialiseerde versnellers bouwen die uiterst goed waren in lineaire algebra met lage precisie en verder helemaal niets. En zo kun je spraak- en visuele modellen enzovoort veel efficiënter bedienen. Het bleek dat de prestaties per watt 30 tot 80 keer zo goed waren als die van de hedendaagse CPU's en GPU's in 2015, toen de chip beschikbaar kwam. Dat was de eerste iteratie.
Bill Jia: Ja, de TPU v1, die echt gericht was op inference, toch? En de opvolgers waren daarna vooral gericht op zowel training als inference. En meer in het bijzonder zijn we onlangs zelfs begonnen om die lijnen weer uit elkaar te trekken, omdat training en inference toch enigszins van elkaar verschillen.
Host: En toen jullie de paper in 2017 publiceerden, werd deze geaccepteerd. Het is de meest geciteerde paper in de 50-jarige geschiedenis—
Jeff Dean: Ja, van ISCA, inderdaad. De paper over TPU v1 is een werk van vele auteurs; er staan denk ik zo'n 35 auteurs op. Maar dat is mooi, zeker gezien het feit dat het relatief recent is binnen de 50-jarige geschiedenis van computerarchitectuur.
Evolutie van TPU-architectuur, softwarestacks en optische switching
Bill Jia: Het is werkelijk fascinerend dat Google werd beschouwd als het ultieme softwarebedrijf, maar vervolgens begon door te duwen op de hardware-roadmap. Dat is echt geweldig. En hardware maken is één ding, want om de TPU fantastisch te maken is er heel wat boarddesign, chipsetdesign en het ontwerp van de TPU zelf voor nodig. Maar daarnaast moeten we ook zorgen dat de compiler en het framework uitstekend functioneren. In de beginfase heb je destijds aangedrongen op XLA, onze TPU-compiler, en ook op TensorFlow. Zou je kunnen toelichten hoe die vroege reis rond het pushen van deze softwarestack voor TPU eruitzag?
Jeff Dean: Zeker. Wat je als machine learning-ontwikkelaar of -onderzoeker wilt, is dat je je idee op hoog niveau kunt formuleren en dat het vervolgens als het ware op magische wijze draait op een grootschalig systeem, zonder dat je te hoeft na te denken over alle prestatiezaken die onder de motorkap nodig zijn om werkelijk goede prestaties te behalen. Dat betekent dat je een goede compiler nodig hebt, uitstekende interconnects en frameworks die de volgende abstractie uitdrukken: praat ik met 4 chips op mijn lokale machine, of praat ik met 10.000 chips in een grootschalige gedistribueerde opstelling? Je wilt daar liever niet te diep over na hoeven te denken, of voor beide situaties heel andere dingen hoeven te doen.
Host: Vertel eens over de iteraties van de verschillende TPUs, en waar zie je dit allemaal naartoe gaan?
Jeff Dean: Zeker. Na TPU v1, wat feitelijk niet meer was dan een PCIe-kaart die in een slot paste — en we kochten er destijds een hele boel zonder te weten hoe we ze zouden gebruiken; ik zette onze toenmalige CFO klem en zei: we moeten hier veel van kopen, want we gaan ze gebruiken; we weten nog niet precies waarvoor, maar mogen we er alsjeblieft heel veel kopen? Dat hebben we toen gedaan. En TPU v2 was zo'n beetje het eerste systeem dat we ontwierpen met het oog op training, niet met een enkele chip, maar met een heel supercomputerachtig systeem van vele chips die met elkaar verbonden waren via een 2D-torus. Door de generaties heen hebben we vloeistofkoeling geïntroduceerd, simmende vanaf TPU v3. Het blijft altijd spannend als er leidingen naar het oppervlak van de chips in je systeem lopen; lekkages zijn immers geen goed teken.
En dan TPU v4: naarmate je de pod-grootte opschaalde — TPU v2 en v3 hadden vaste bekabeling tussen 256 chips en later 1.024 chips — loop je bij steeds grotere systemen onvermijdelijk tegen storingen aan in individuele chips, boards of systemen. Je moet dus fouttolerantiger zijn, omdat je de volledige topologie van een veel grotere pod wilt kunnen blijven benutten, zelfs als er ergens iets stuk is. TPU v4 introduceerde daarom het concept van een optisch reconfigureerbaar netwerk tussen racks van machines.
Host: Zodat je als het ware Lego-blokjes overal vandaan op de datacenterfloer aan elkaar kunt klikken, toch?
Jeff Dean: Met van die gekke kleine switches met micro-verstelbare spiegeltjes, waardoor het lijkt alsof die acht racks direct naast elkaar staan, zelfs al zijn ze verspreid over vele gangpaden in het datacenter. Dat is ontzettend nuttig gebleken. TPU v5, v6 en v7 introduceren allemaal steeds lagere precisie-rekenformaten, wat buitengewoon nuttig is. Je behaalt daardoor veel betere prestaties, al is het altijd lastig om FLOPS met elkaar te vergelijken wanneer sommige FLOPS 16-bit zijn, andere 8-bit en weer andere 4-bit. Als je ze in je machine learning-algoritmen kunt benutten, vormen de varianten met een lagere precisie een geweldige manier om nog betere prestaties te behalen.
Pathways: Het orkestreren van onregelmatigheid en massieve gedistribueerde training
Host: De eerste TPU stamt dus uit 2015; in 2017 verscheen de paper. Inmiddels is dat legendarisch. En in 2018 volgde Pathways. Laten we het even hebben over Pathways en waarom dat zo belangrijk is.
Jeff Dean: Zeker. We zijn Pathways gaan bouwen om specifiek de training van veel onregelmatigere en lossere (sparser) modellen te ondersteunen, en tevens als onderliggende systeeminfrastructuur om te zorgen voor één enkel programmeermodel en één enkel proces dat een grootschalig gedistribueerd trainingssysteem aanstuurt. Als programmeur is het een stuk prettiger als je losse Python-proces er simpelweg uitziet alsof het is gekoppeld aan 8.000 apparaten, zodat je denkt: prachtig, ik wil gewoon een AllReduce uitvoeren over alle 8.000 apparaten, en het systeem voert dat uit zonder dat je daarvoor iets speciaals hoeft te doen.
De onderliggende software in zowel de XLA-compiler lost een deel daarvan op, en op een iets hoger niveau orkestreert Pathways de datamobiliteit tussen talloze verschillende chips. Je hebt chips binnen dezelfde TPU-pod, en als er gecommuniceerd moet worden, gebruikt het de ICI high-speed links die in de TPU-pod aanwezig zijn. Maar als je vervolgens iets nodig hebt dat meerdere pods omspant, of als je moet communiceren van deze chip in deze pod naar die chip in die andere pod, dan coördineert Pathways die overdracht via het datacenternetwerk, of zelfs een wide area network wanneer je een trainingstaak aaneenrijgt van pods in Oklahoma, Texas en Iowa of iets dergelijks. Dat levert je simpelweg een prettige abstractie op: ik beschik over een enorme hoeveelheid rekenkracht, en ik laat het systeem bepalen hoe dat optimaal kan worden ingezet.
Het co-designen van Gemini-modellen met hardware en infrastructuur
Bill Jia: Fantastisch. Jeff, in de beginfase was je nauw betrokken bij het netwerkontwerp voor de TPU, het TPU-ontwerp zelf, de compiler en het framework, en uiteraard Pathways, dat de complete datatransmissie, de herconfiguratie van het netwerkverkeer en alles daarbinnen aanstuurt. Dat is de complete AI-infrastructuurstack. Nu ben je heel nauw betrokken bij het ontwerpen van de Gemini-modellen, zowel de huidige als de toekomstige Gemini-modellen. Daardoor kunnen de Gemini-modellen echt worden gecodesigned in samenhang met de complete infrastructuurstack. Wat voor voordelen hebben we volgens jou al kunnen oogsten, en welke toekomstvisie heb je om de grenzen van modellen verder te verleggen?
Jeff Dean: Ik denk dat de hele reeks TPU-generaties enorm heeft geprofiteerd van het feit dat we zelf intensieve gebruikers zijn van de ML-rekenkracht en dat we veel mensen hebben die de grenzen van nieuwe onderzoeksideeën opzoeken. Die ideeën belasten de hardware soms op manieren die bestaande workloads niet doen. Doordat we alles onder één Alphabet-dak hebben, kunnen we veel interactie onderhouden tussen de ontwerpers van toekomstige TPU-generaties, de softwareontwikkelaars van de compilers en de infrastructuur, en de machine learning-onderzoekers. Die laatste groep kan aangeven: hé, dit soort aanpak lijkt op kleine schaal te werken, we denken dat dit over een jaar of twee cruciaal wordt voor grootschalige, toekomstige trainingsruns, en we willen zeker weten dat onze hardware daarin voorziet.
Als computerarchitect is het namelijk ontzettend lastig om dit in isolement te doen, puur gokkend waar het snel bewegende AI-veld zich over twee tot zes jaar bevindt — de periode waarin de specifieke chip die je nu ontwerpt relevant moet zijn. Hoe meer inzicht je kunt krijgen van "ja, we denken dat dit gaat werken" — en hoe meer iteraties je kunt doorlopen — des te beter. Het is vaak niet zo van "we denken dat we dit moeten doen", maar vaker dat de hardwaremensen zeggen: nou, dat is complex, maar we zouden dit kunnen bouwen, zou dat nuttig zijn? Dan krijg je een wisselwerking van: ja, daarmee kunnen we iets realiseren dat hier heel dicht bij komt, of misschien zelfs beter is. En dat is van onschatbare waarde voor effectief co-design.
Betrouwbaarheid op schaal: Goodput en fouttolerantie over 100.000 TPUs
Bill Jia: Gisteren stond ik op het podium voor de opening. Ik vertelde dat naarmate we de Gemini-modellen opschalen — en ik herinner me dat we maandelijks in dezelfde vergaderingen zaten om te praten over betrouwbaarheid; ik zit aan de infrastructuurkant en Jeff vertegenwoordigt Google DeepMind —, we zeiden: hé, weet je wat, de Gemini-modellen worden steeds groter, dus we gebruiken enorm veel TPU's om de modellen te trainen. Uiteindelijk gebruiken we 100.000 TPU's om de modellen te trainen. Dat is de ene metriek waar we gezamenlijk naar kijken, en die noemen we goodput.
In het begin was onze goodput niet best. Ik herinner me wat we tegen elkaar zeiden: badput overheerst goodput. Aanvankelijk lag het rond de 60%. Naarmate we meer en meer TPU's opschalen om dat model voor te trainen, wordt het enorm ingewikkeld. We hebben grotere schaal nodig, meer data, meer parallelle verwerking. De goodput lag in het begin op 50%, 60%, 70%, maar dat was simpelweg niet goed genoeg. Kort samengevat: inmiddels gebruiken we grootschalige trainingsinfrastructuur, trainen we veel complexere modellen en kan de goodput oplopen tot wel 95% of zelfs 98%.
Jeff Dean: Ja, en ik denk dat dat het resultaat is van een combinatie van factoren: betere operationele praktijken, betere kwaliteitscontroles en tests van de chips wanneer ze worden ingezet, en softwaresystemen die beter weten om te gaan met storingen en die vooruitgang blijven boeken, zelfs als een deel van het systeem uit de lucht is. Al deze elementen samen wegen zwaar en maken een enorm verschil.
Bill Jia: Dat is volgens mij nog een voordeel van het feit dat we het model in eigen beheer hebben, de data bezitten en tevens eigenaar zijn van de volledige hardware, het netwerk, de complete softwarestack en het operatieteam.
Jeff Dean: Je kunt stellen: het is van cruciaal belang. Want als je kijkt naar een losse tray met TPU's en je beschouwt dat niet als onderdeel van een groter systeem, denk je al snel: ach, prima, dat repareren we over een week wel een keer als we hier langskomen. Maar als dat onderdeel uitmaakt van een actieve pod met defecte trays erin, wil je dat direct verhelpen, omdat de impact (de zogenaamde blast radius) van wat je moet herstellen in werkelijkheid veel groter is dan het lijkt.
Host: Dus als je praat over 100.000 chips, is betrouwbaarheid eigenlijk geen kwestie meer van een softwarepatch toepassen? Zou je zeggen dat het eerder een kwestie is van systeemontwerp? Of heeft het meer te maken met fysica?
Jeff Dean: Volgens mij is betrouwbaarheid echt een eigenschap van een compleet systeem, en er zijn talloze aspecten die je robuust wilt inrichten. Een beproefde methode is om robuuste gehelen te bouwen uit onbetrouwbare onderdelen. Dat dateert eigenlijk al uit de beginjaren van Google. We kochten toen goedkope consumenten-pc's om ons zoekverkeer te bedienen, en we bouwden daar robuuste softwaresystemen bovenop die in staat waren om het uitvallen van individuele machines op te vangen, zodat de functionaliteit die het betreffende systeem hoorde te leveren toch overeind bleef. Denk aan een gedistribueerd bestandssysteem, waarbij je data repliceert over meerdere machines, zodat er altijd exemplaren beschikbaar zijn, zelfs als sommige replica's van een brok data offline zijn.
En volgens mij kun je exact hetzelfde doen bij grootschalige AI-trainingssystemen. Als je een standaardconfiguratie hebt van 20 pods, maar eentje daarvan ligt plat, dan kun je doorgaan met de overige 19 pods terwijl je die 20e pod repareert.
Operationele coördinatie en het tegengaan van stille datacorruptie
Host: Bill, je stipte dat gisteren tijdens je keynote al even aan met betrekking tot OCS en Jupiter. Wil je daar wat meer over vertellen en hoe dat bijdraagt aan de betrouwbaarheid?
Bill Jia: Zeker, er is sprake van een lange weg. Het begint ermee dat we voor elke 10.000 chips en elk onderdeel kijken naar het aantal interrupts per dag. Dat moeten we minimaliseren, want als het aantal interrupts te hoog oploopt naarmate we het trainingscluster opschalen, werkt dat contraproductief. Een van de dingen die we hebben gedaan, is de hardwarebetrouwbaarheid verbeteren. En daar blijft het niet bij: zoals ik gisteren al aangaf, scant de software voorafgaand aan de pre-training de volledige vloot, elk afzonderlijk component: wat is de hartslag? Als die hartslag problematisch oogt, lossen we dat op of sluiten we het onderdeel uit voordat de training überhaupt begint. Dat is stap één.
Stap twee: de training gaat van start. Maar zodra de training loopt, en zelfs als de hardware sterke vitale functies vertoont, duurt zo'n trainingsproces weken; dan kunnen er alsnog problemen optreden. Hoe identificeren we welke specifieke componenten en servers kuren vertonen, om ze vervolgens te herstellen, uit te sluiten, te vervangen en te repareren? Dat is het tweede aspect.
Daarnaast is er, zoals Jeff al opmerkte, sprake van intensieve operationele coördinatie. Als het datacenter onderhoud pleegt aan de stroomvoorziening van een hele datacenterrij en die specifieke rij is net bezig met de training, is dat uiteraard verre van ideaal. We coördineren daarom nauwgezet met datacenterteams, Site Reliability Engineers en alle ML-onderzoekers en -ingenieurs. Dat vergt een enorme coördinatie; we moeten strak op één lijn zitten.
En ik denk dat Jeff ook een leidende rol vervult op het vlak van Gemini-modelontwerp en softwarearchitectuur. Soms slaan dingen spaak, maar de training combineert dataparkallelisme en modelparallelisme met elkaar. Mocht er binnen één datareplica iets misgaan, dan draait de extra replica mogelijk gewoon door. Je middelt gewichten immers automatisch, waardoor je niet wordt gehinderd door het uitvallen van die ene replica. Het is dus een optelsom van zeer grondige verbeteringen. Nog iets toe te voegen hieraan?
Jeff Dean: Nee. Er kan van alles misgaan, en het is nagenoeg onmogelijk om elke denkbare faalwijze vooraf te voorspellen. Het bouwen van robuuste systemen die storingen kunnen detecteren — ook al weet je niet direct wat de precieze oorzaak is — is dan ook essentieel. Soms heb je te maken met chips die, zodra de temperatuur oploopt, betrouwbaarheidsproblemen vertonen; denk aan het optellen van 2 plus 2 en als uitkomst 5 krijgen.
Bill Jia: Dat is de meest akelige variant: een stille datacorruptiefout. Dat is werkelijk verschrikkelijk.
Jeff Dean: Zeker, en dat kan zich voordoen in de chip zelf, in een instabiele netwerkklink of op tal van andere plekken. We passen nu veel van dezelfde principes toe als in de begintijd van Google, toen we door die goedkope consumenten-pc's niet alleen geen ECC hadden, maar zelfs geen pariteitscontrole in het geheugen. Als je een massa computers inzet voor een taak en geen enkele daarvan heeft pariteit, dan krijg je te maken met willekeurige bit-flips in gegevens. Veel van de berekeningen die we uitvoerden moesten dus bestand zijn tegen bit-flips. Een manier om dat op te lossen was: prima, ik verwerk een miljard webpagina's, als ik er daar eentje van laat vallen, is dat waarschijnlijk geen ramp. Dat kon je simpelweg opvangen door in de softwarelaag boven de hardware een checksum toe te passen, zodat het geheel robuust bleef, zelfs als een specifieke machine of netwerkklink onbetrouwbaar bleek.
Open-sourcestrategie: JAX, StableHLO en PyTorch op TPU
Host: Google is een groot voorstander van open source, dus ik wil het onderwerp even verleggen naar open source. Ik weet dat we veel academici in de zaal hebben, evenals veel van onze partners. Laten we daarom stilstaan bij Google's AI-infrastructuurstrategie in relatie tot het waarborgen dat het geen afgeschermde resource wordt. Alles wat we hier bespreken, willen we immers delen met de wereld. Laten we het hebben over JAX, StableHLO, de bredere evolutie van open source en waarom dit vandaag de dag zo relevant is om te voorkomen dat dit een exclusief domein blijft.
Jeff Dean: Voor ons is de interactie met het bredere ecosysteem van buitengewoon groot belang. Het open-sourcen van technologieën zodat mensen de broncode kunnen inzien, aanpassen, ons kunnen helpen verbeteren en het een gezamenlijk project kan worden dat meerdere organisaties overstijgt in plaats van iets dat we voor ourselves houden, is cruciaal. Dat is de reden waarom we TensorFlow open-source hebben gemaakt, waarom we JAX open-source hebben gemaakt en waarom we de StableHLO-representatie voor de XLA-compiler open-source hebben gemaakt. En we zullen in de toekomst meer open-source beschikbaar stellen. We zijn al vele jaren grootgebruiker en -bijdrager aan open source, onder andere aan de Linux-kernel. Doorgaans behoren we tot de grotere organisaties die bijdragen aan collectieve open-source-initiatieven, simpelweg omdat we daarin geloven en we ervan overtuigd zijn dat het hele ecosysteem profiteert wanneer iedereen samenwerkt.
Host: Dat is een prachtig bruggetje voor jou om te praten over PyTorch en je ervaringen bij Meta.
Bill Jia: Zeker. Ik sprak Jeff vlak voor deze fireside chat nog. Jeff heeft een stempel gedrukt op de open-sourcestrategie voor de AI-infrastructuur van Google. Zoals hij al noemde, heeft Google in het verleden TensorFlow en JAX open-source gemaakt, en ook Kubernetes is destijds door Google gecreëerd en open-source gemaakt, net als Android en een heleboel andere geweldige zaken. Nu we de TPU breder in de community introduceren en TPU op Google Cloud benadrukken, verdubbelen we de inzet op deze open-sourcestrategie.
Sterker nog: we stellen niet alleen de kern van JAX open-source, we bouwen ook tal van hoger gelegen bibliotheken. Denk aan hoe we reinforcement learning aanpakken — we noemen dat TuneX, dat gebouwd is op de JAX-kern — en ook dat maken we open-source. Hoe je checkpointing regelt, hoe je inference inricht: we ontwikkelen diverse bovenliggende bibliotheken en frameworks bovenop JAX en stellen die open source, omdat we willen dat mensen deze gebruiken en via deze strategie direct van de TPU profiteren. Dat is één aspect.
Daarnaast willen we uiteraard aansluiten waar de klant zich bevindt. We omarmen daarom ook volwaardige producten die al bestaan binnen de open-sourcegemeenschap. PyTorch is uiterst volwassen en wordt ontzettend veel gebruikt in de community. We dachten: laten we PyTorch op TPU omarmen. We hebben momenteel een project lopen genaamd Torch-TPU. Dat bevindt zich in private preview. Volgend kwament — over enkele maanden — willen we naar een public preview toe, en in het vierde kwartaal willen we een openbaar aanbod op GitHub lanceren, zodat iedereen ermee aan de slag kan. Zoals ik gisteren al opmerkte, vergt het gebruik van Torch-TPU slechts een paar simpele regels codewijziging om de backend-device in te stellen op TPU, en vervolgens draaien hopelijk alle trainingen en inference op de TPU. We ondersteunen hierbij zowel de eager mode als de compiled mode. Dat is op frameworkniveau.
Daarnaast leggen we contacten — ik weet zeker dat er in de zaal veel gebruikers zitten van vLLM en SGLang. We voeren eveneens gesprekken met de makers van vLLM en SGLang om te zorgen dat dit soort geavanceerde, open-source inference-frameworks eveneens op TPU kunnen draaien. Er wordt dus momenteel volop gewerkt aan twee kanten: we stellen onze eigen technologie open source, en we omarmen volwassen open-sourceproducten uit de community.
Het automatiseren van hardwareontwerp met machine learning
Host: We hebben ook een hoop eerste- en jaars- en tweedejaars promovendi in de zaal zitten. Hoeveel van jullie zijn PhD-studenten? Wat zijn onderwerpen waar zij zich op zouden moeten richten? Sommigen van hen zijn trouwens ook bachelorstudenten, voor de goede orde.
Jeff Dean: Prachtig om in die fase van je carrière te verkeren, want ik denk dat je dan onderwerpen kunt vinden die je echt aanspreekt en belangrijk vindt, en kunt bepalen hoe je een bepaald vakgebied vooruithelpt om impact te maken in de wereld. Dat is gewoon een ontzettend leuke tijd.
Host: Is er één fysieke bottleneck waar je vanuit een infrastructuurperspectief momenteel over nadenkt?
Jeff Dean: Er zijn er zo veel. Ik ben erg optimistisch over steeds meer gespecialiseerde hardware, omdat ik geloof dat dat dé manier is om veel efficiëntere systemen te bouwen. We zien nu workloads waarbij een handvol toepassingen straks een groot deel van de wereldwijde rekenkracht zal opslokken. Als je daarover nadenkt, schreeuwt dat om specialisatie. Het nadeel van specialisatie is echter dat wanneer jouw doelstellingen in de toekomst veranderen, het hardwareproduct waaraan je twee jaar lang met liefde hebt gewerkt, wellicht niet meer optimaal relevant is.
Om specialisatie echt goed te laten functioneren, moet je naar mijn idee een veel groter deel van het hardwareontwerpproces automatiseren. Momenteel verloopt hardwareontwikkeling via een groot team van mensen. Sommigen pakken de hoogteniveau-specificatie en bouwen daar laagniveau RTL van. Omdat dit handmatig is vertaald, heb je vervolgens een ander team nodig dat verifieert of het eerste team wel goed werk heeft geleverd. En dan heb je nog een groep die de chip met de hand fysiek indeelt. Het lijkt erop dat als je veel meer geautomatiseerde lussen kunt inbouwen waarin gezocht kan worden via reinforcement learning of andere evolutionaire technieken — en je die lussen snel genoeg kunt laten draaien, iets waar hedendaagse EDA-tools doorgaans niet voor zijn ontworpen —, je de kans creëert om een veel sterker geautomatiseerde exploratieloop binnen het ontwerpproces te realiseren en de ontwerpcyclus drastisch in te korten.
Als je bijvoorbeeld een nieuwe chip zou kunnen ontwerpen met 10 mensen in 3 maanden in plaats van 150 mensen over 2 jaar, zie je veel meer gespecialiseerde hardware verschijnen. Bovendien hoef je dan veel minder te gokken op de toekomst: wat voor rekenkracht wil ik over 2 tot 6 jaar hebben, wordt dan een vraag die dichter bij 3 tot 6 maanden tot 4 jaar ligt, en dat is een stuk eenvoudiger te voorspellen.
Inference-workloads, agentsystemen en bottlenecks in tools
Bill Jia: Als we een jaar of twee teruggaan in de tijd, lag de nadruk binnen de industrie — inclusief Google en diverse andere frontier labs — primair op het fantastisch maken van het model. Er was enorm veel focus op het laten slagen van pre-training en post-training, waardoor veel hardware-strategieën waren toegespitst op de trainingskant. Maar nu grote modellen volwassen worden, vloeit een groot deel van het verkeer richting de agentenwereld en de inference-kant. Jeff, kun je vanuit een hardware-ontwerpoptiek je licht laten schijnen over hoe we hardware kunnen inrichten om specifiek inference-verkeer te ondersteunen?
Jeff Dean: Inference en training verschillen enigszins van elkaar. Bij inference beschik je in feite over een model en wil je simpelweg een grote hoeveelheid verzoeken daarvoor afhandelen. Je wilt dus zo min mogelijk informatie verplaatsen die onveranderd blijft. De componenten die niet veranderen zijn de modelgewichten, en de elementen die wel veranderen zijn de verzoeken, de KV-cache enzovoort. Je moet dus een systeem ontwerpen dat uiterst efficiënt is in het minimaliseren van die databewegingen.
En ik denk daarnaast dat naarmate je niet langer te maken hebt met enkel een prompt en een antwoord, maar met een veel onafhankelijker proces — een agent die wat handelingen verricht, besluit een tool aan te roepen, de tool laat draaien, de resultaten ontvangt, die samenvoegt in de context van het model en laat bepalen wat de volgende stap is — we zullen inzien dat al onze tools veel te traag zijn. Ze zijn immers ontworpen voor iteraties op menselijke snelheid. Als je code compileert als onderdeel van je tool, word je er diep ongelukkig van als je compiler traag is. Als je je inference-hardware supersnel maakt, kan die code genereren die mogelijk sneller is dan je kunt compileren, en sowieso sneller dan je kunt uitvoeren.
Een van de dingen waar we aan hebben gewerkt, is daarom het versnellen van onze interne tools om ze beter te maken. Het blijkt namelijk dat je heel effectief kunt vertalen van de ene programmeertaal naar de andere, omdat je beschikt over een volledige, nauwkeurig gespecificeerde omschrijving van wat je wilt bereiken. Je hebt het volledige programma geschreven in een geïnterpreteerde taal zoals Python, en je wilt exact hetzelfde programma in Go, Rust, C++ of een andere taal. Een agent kan dat uitstekend uitvoeren, wat heel anders is dan het type codeerinteractie dat we doorgaans met een agent hebben — zoals "maak een webserver voor me", waarbij de agent allerlei details moet invullen op basis van aannames die jij wellicht helemaal niet wilde. Maar met een volledig gespecificeerde tool levert dat fantastische resultaten op: de agent kan alle unit-tests draaien, alle unit-tests vertalen, die uitvoeren in het nieuwe systeem en het gedrag naast elkaar verifiëren om te garanderen dat het identiek presteert.
Bill Jia: We hebben hier intern bij Google een sprekend voorbeeld van dat we Project Tern noemen. Omdat veel modellen in TensorFlow waren gebouwd en we nu migreren naar JAX, vertalen we alle TensorFlow-modellen automatisch, migreren we naar JAX en voeren we alle unit-tests en codetests automatisch uit.
Host: Nu was er onlangs een paper ingediend bij NeurIPS die werd afgewezen en waarin werd gesteld dat distillatie bar weinig impact had.
Jeff Dean: O ja. Dat is een motiverend verhaal; het hoort als inspiratie te dienen. Het blijkt namelijk dat distillatie wel degelijk belangrijk is. Dit is een paper die mijn collega's Geoff Hinton, Oriol Vinyals en ik indienden over de vraag hoe je een groot model via distillatie kunt samenvatten in een kleiner 'student'-model.
Bill Jia: In welk jaar was dat?
Jeff Dean: Dat was in 2015 of 2016. Aanvankelijk dachten we hieraan in de context van het trainen van een groot ensemble van verschillende soorten gespecialiseerde modellen voor visie. Dat was een van de reeksen experimenten in de paper: je hebt 20.000 visuele klassen, maar je thet traint een speciaal model voor dieren, eentje voor auto's, weer een ander voor overige categorieën, en dat distilleer je vervolgens tot één enkel model dat al die dingen goed kan. De paper werd afgewezen, maar dat geeft niet; we hebben hem op arXiv gezet. Mensen hebben hem alsnog gelezen.
Host: Laat je dus niet ontmoedigen.
Jeff Dean: Precies.
Q&A: Commodity-hardware versus gespecialiseerde supercomputers
Host: Goed, we hebben nog een paar minuten over voor een paar vragen. Er lopen een paar mensen rond met microfoons. Daar hebben we er eentje. Misschien kunnen we hier beginnen. Als je even wilt opstaan, jezelf wilt voorstellen en in één zin je achtergrond wilt toelichten.
Publiekslid (Ying): Mijn naam is Ying. Ik heb tien jaar bij Google Brain gewerkt. Goed je weer te zien. Mijn vraag aan Bill en Jeff is: we spraken over commodity-software en commodity-rekenkracht uit de begintijd van Google; dat was hoe Google begin jaren 2000 opschaalde. Tegenwoordig worden AI-supercomputers steeds gespecialiseerder, meer vergelijkbaar met het oorspronkelijke supercomputerparadigma. Hoe kijken jullie aan tegen deze twee verschillende ontwerppatronen voor hardware en machine learning-systemen? Denken jullie dat we in de toekomst meer terugkeren naar commodity-hardware, of moeten we doorgaan met het bouwen van supercomputers? Dank je.
Jeff Dean: De reden dat we met commodity-hardware konden opschalen voor de zoekmachine, is dat zoeken een prachtig probleem is waarbij je — als je het opbreekt — nagenoeg geen communicatie tussen machines hebt, en je veel werk op één enkele machine verricht. Je hebt dus geen exotische interconnects nodig. We gebruikten destijds 100 megabit-ethernet op de machines en deelden een uplink van 1 gigabit per rack over 40 machines, wat neerkwam op een oversubscription van 4 op 1. Maar dat is geen probleem, omdat je termen als "restaurants in Palo Alto" naar elke machine stuurt en als antwoord een klein snippet terugkrijgt met tien resultaten. Training daarentegen verlegt de grenzen echt: daarvoor heb je massieve connectiviteit nodig.
Het liefst zou je trainen op een enkele chip — dat zou optimaal zijn —, maar dat duurt simpelweg te lang of past niet. Dus dwingt het je om het probleem op te splitsen over talloze chips. Hoe je dat ook indekt — modelparallelisme of dataparkallelisme —, je eindigt vrijwel altijd met een flinke hoeveelheid communicatie. En dat is precies de reden waarom je gebruikmaakt van dit soort exotische interconnects tussen machines. Je wilt de maximale prestaties per chip zodat je het niet over een al te groot aantal chips hoeft te verspreiden, maar je moet het alsnog over velen verdelen. Daarom passen we vloeistofkoeling toe om elke chip in die opstelling zo krachtig mogelijk te maken.
Ik denk dat inference meer de kant opgaat van: je kunt gespecialiseerde hardware inzetten, maar dat hoeft minder exotisch te zijn, met name voor kleinere modellen. Maar naarmate modellen groter worden, ontstaan er communicatiebehoeften die er in vergelijking met standaard Ethernet commodity-hardware en -netwerken behoorlijk exotisch uitzien, hoewel het onmiskenbaar meer mainstream en commodity is dan training. Is dat een helder antwoord?
Q&A: Open-sourcebijdragen, CUDA-pariteit en AI-agents voor ontwikkelaars
Host: Volgens mij hebben we hier nog een vraag.
Publiekslid (Andra): Jeff, mijn naam is Andra van Uber. Ik heb een vraag met betrekking tot het ecosysteem van JAX en OpenXLA, met name gezien de open-sourcegemeenschap die hieromheen is opgebouwd. Ik zie dit zo ongeveer als een tijdperk voor AI-infrastructuur dat vergelijkbaar is met Android en iOS. Wat zie jij als de manier waarop jonge ingenieurs kunnen bijdragen aan de bibliotheekfuncties van OpenXLA? De meeste gebruikers zijn immers doorgewinterde CUDA-gebruikers, of ze bouwen bibliotheken en functies op basis van CUDA-bibliotheken. Waar kunnen jonge ingenieurs volgens jou aan bijdragen binnen OpenXLA?
Bill Jia: Allereerst zijn OpenXLA en JAX, en de JAX-stack daarbovenop, volledig open-source gemaakt. Dat is één categorie werkzaamheden. Een andere categorie is Torch-TPU. Momenteel werken we hier intern nauw samen met Meta aan de ontwikkeling, maar uiteindelijk plaatsen we dit op GitHub zodat alle onderzoekers en ingenieurs uit de community kunnen bijdragen. Dat zijn onze twee parallelle inspanningen. Jonge ingenieurs in de community die willen bijdragen aan de open-source-repository zijn meer dan welkom om met Google samen te werken. We gaan graag in overleg over hoe we deze open-source-repository gezamenlijk kunnen doorontwikkelen.
Daarnaast denk ik dat veel gebruikers uiteindelijk ofwel de JAX-stack of de PyTorch-stack voor TPU of GPU zullen inzetten. Als mensen in de community op dit moment ergens tegenaan lopen, bellen velen van hen naar Google of Nvidia omdat die ervaren ingenieurs in huis hebben, of ze plaatsen vragen op community-discussieforums in de hoop dat iemand het probleem begrijpt en soortgelijke ervaringen heeft om een antwoord te formuleren. Maar naar mijn mening werkt dat allemaal erg traag. Waar de community kan bijdragen aan de open-sourcestrategie is: stel je voor dat we een JAX-agent en een PyTorch-agent hebben die draaien op GPU of TPU — dat maakt niet uit. Als iedereen in de community datarijken en bronnen bijdraagt om zo'n agent ijzersterk te trainen, stel je dan eens voor dat ik een TPU-collega-agent tot mijn beschikking heb. Wanneer ik een training, post-training of inference uitvoer, hoef ik niet langer Google te bellen of een discussieforum te raadplegen; ik gebruik direct deze agent om mij te helpen. Als die agent een groot deel van de vragen kan beantwoorden, is dat fantastisch. Maar dat vraagt om de inzet van de hele community, omdat we een grote schat aan datapunten en ervaringen nodig hebben.
Jeff Dean: Ik wil hier nog een meta-opmerking aan toevoegen over open-sourcebijdragen. Er zijn talloze manieren om bij te dragen. Het is heel verstandig om de dialoog aan te gaan met enkele beheerders van de verschillende repositories om te onderzoeken: ik overweeg dit te doen, is dat nuttig, of hebben jullie ideeën over zaken waar ik aan zou kunnen werken? Voordat je zomaar 5.000 regels code over de schutting gegooid bij iemand neerlegt met de mededeling "Hé, hier is het", is het echt aan te raden om eerst draagvlak of advies in te winnen over wat waardevol is. Mocht je erg gretig zijn om bij te dragen maar nog geen concreet idee hebben waaraan je wilt sleutelen, dan ligt er vaak een lange lijst klaar met zaken die nuttig zouden zijn.
Publiekslid (Andra): Dank je wel voor het antwoord. Een aarzeling die ik vaak tegenkom, is dat veel functies of module-kernels nog zwaar leunen op CUDA. Zie jij een trend waarin we iets vergelijkbaars implementeren met JAX, OpenXLA of Torch-TPU, zodat we een soort algemene compatibiliteit realiseren in vergelijking met CUDA-functies? Zou dat een goede richting zijn?
Bill Jia: Ja, ik denk zeker dat we die kant op gaan. Wanneer we intern bij Google kijken naar de JAX-stack en de PyTorch-stack op TPU, vergelijken we alle CUDA-functies met onze eigen functies. We zorgen ervoor dat we minimaal op gelijke hoogte zitten, zo niet beter. Dat is een absolute randvoorwaarde die we moeten invullen. En in die laag willen we ook het laagniveau TPU SDK-werk open-source maken.
Jeff Dean: Ik denk ook dat mensen op een veel hoger abstractieniveau willen denken. Je wilt redeneren in termen van JAX- of PyTorch-expressies, en niet noodzakelijkerwijs nadenken over: hoe kan ik dit parallel maken met wat kernelcode — of het nu een TPU-kerneltaal of GPU-kerneltaal betreft — om maximale prestaties te behalen? Idealiter zorgen de compiler en het onderliggende systeem daarvoor, en kun je je beperken tot prachtige abstracties zoals matrixvermenigvuldiging.
Q&A: Schalende netwerken, 3D-torussen en synchrone training
Host: Volgens mij hebben we nog tijd voor één laatste vraag. Slechts één laatste vraag, ga je gang.
Publiekslid (John): Hallo, John van NYU. Ik werk al vele jaren aan netwerken. Ik was erg onder de indruk van de presentatie van Bill Jia en zijn collega met betrekking tot de schaalbaarheid hier. Ik begreep dat deze TPU's zijn verbonden in een 3D-torus. In vergelijking met onder andere het Ultra Ethernet Consortium en andere partijen die kijken naar fat-tree-interconnects: kan deze 3D-torus vanuit een schaalbaarheidsperspectief — wanneer je TPU's of GPU's opschaalt tot tienduizenden of zelfs één miljoen — nog steeds alle-naar-alle-communicatie (all-to-all) aan op die enorme schaal?
Jeff Dean: Onze grootste pods voor TPU v5e of TPU v4 omvatten, geloof ik, 9.600 en een beetjes chips. Dat is de schaal waarop we 3D-torussen toepassen. Daarbovenop gebruiken we Pathways als softwareabstractie bovenop al die via 3D-torussen verbonden pods, en dat maakt gebruik van het datacenternetwerk — wat voor fabric je ook in je datacenter hebt staan — of zelfs een multi-metro trainingsopstelling waarbij je bijvoorbeeld 5 pods hebt staan in dit gebouw in Oklahoma en nog eens 8 in dit gebouw in Iowa, gekoppeld via een supersnelle WAN-link. Dat lijkt voor ons tot nu toe erg goed te werken qua opschaling.
Soms wil je de berekening die je uitvoert zo toewijzen dat je over zowel dataparkallelisme als modelparallelisme beschikt. Het is vaak handig om het modelparallelle aspect binnen een enkele pod of een deel van een pod te houden, en dataparkallelle replica's in te zetten over die pods of podsneden heen. Dat werkt voor ons erg prettig. Het voordeel van torus-gebaseerde netwerken is dat ze lokaal heel eenvoudig te bekabelen zijn, in tegenstelling tot de complexe bekabeling die je anders op de vloer van je datacenter nodig hebt.
Host: Afgezien van die gekke gespiegelde optische switches dan.
Jeff Dean: Nog iets toe te voegen, Bill?
Bill Jia: Ja, dat klopt helemaal. We hebben ICI binnen het rack, binnen de cube. Vervolgens gebruiken we de OCS om op te schalen tot 9.600. En daarboven hebben we onze datacenter-fabric, georkestreerd door de Pathways-software. Om voorbij de 100.000 chips te gaan, gebruiken we cloud-datacenternetwerken om alles met elkaar te verbinden. Die schaalbaarheid werkt uitstekend voor ons.
Jeff Dean: En ik durf te stellen dat we zelfs op die schaal in staat zijn om volledig synchrone training uit te voeren, wat erg prettig is vanuit het oogpunt van machine learning-reproduceerbaarheid en -interpretatie. Op enig moment zal asynchrone training vast weer terugkeren, maar tot dusver hebben we synchrone training ver kunnen doorvoeren, en we zullen zien wat de toekomst brengt.
Host: Een fantastische afsluiter. Onze tijd zit erop. Hartelijk dank, Jeff. En jij ook bedankt voor je tijd, Bill. Buiten bij de patio ligt er nog wat heel coole merchandise voor jullie klaar, waaronder pennen met bekende Jeff Dean-memes en een Dev Labs-t-shirt. Iedereen hartelijk dank!