Google-Transkript: Co-Design von TPUs, verteilten Systemen und Frontier-KI-Modellen
Google Dev Labs Fireside Chat mit Jeff Dean und Bill Jia zur Skalierung von KI-Systemen, 20. September 2026
Einführung und die Anfänge von Google
Host: Also, herzlich willkommen an alle. Vielen Dank, dass Sie so zahlreich und mit so viel Begeisterung erschienen sind. Dies ist unser siebtes Dev Labs, und jedes Mal wird es größer und besser. Und das ist mit Abstand das bisher beste. Wir hatten so viel Interesse – vielen Dank für Ihr Feedback. Das Ganze läuft so ab, dass wir über ein paar Fragen sprechen werden, insbesondere über die Entwicklung der TPUs. Das ist Jeff, der absolut keiner Einführung bedarf. Er war Mitarbeiter Nummer 30 bei Google. Fangen wir also mit dieser Geschichte an. Wir haben auch Bill hier, der ebenfalls Fragen stellen wird, uns aber auch ein paar Einblicke in die Umsetzung der KI-Infrastruktur geben soll – in die Vision und wie diese derzeit sowie in den nächsten Jahren umgesetzt wird, wenn das in Ordnung ist. Alles klar, fangen wir an. Jeff, erzähl uns ein bisschen mehr. Du warst Mitarbeiter Nummer 30 bei Google.
Jeff Dean: Japp. Japp.
Host: 1999. Die meisten hier waren damals noch gar nicht geboren, oder vielleicht gerade so, oder noch in den Windeln. Wie war das damals?
Jeff Dean: Nein, das hat unglaublich viel Spaß gemacht. Als ich anfing, saßen wir alle in diesem winzigen Büro in der Innenstadt von Palo Alto, eingeklemmt über dem, was heute ein T-Mobile-Shop ist – so in etwa war die Größenordnung des Büros. Und wir versuchten, ein qualitativ hochwertiges Suchprodukt zu entwickeln. Ich hatte in einem früheren Job bereits etwas Erfahrung mit Information Retrieval gesammelt, insbesondere im Bereich Web, wo man die Graphenstruktur des Webs nutzt, um bestehende Informationen auf Seiten anzureichern und so weiter. Google schien mir daher ein natürlicher Ort zu sein, um das in einer weniger forschungslastigen Umgebung auszuprobieren, wo die Leute meine Arbeit direkt nutzen würden, was super viel Spaß gemacht hat. Die Energie war enorm und unser Traffic wuchs jede Woche um etwa 7 %. Und wenn man 1,07 hoch 52 rechnet, weiß man, dass man jedes Jahr fast durchschmilzt und versucht, dienstags um 12 Uhr mittags nicht umzufallen. Das hat also großen Spaß gemacht. Und während das Unternehmen weiter gewachsen ist, haben wir immer mehr Dinge getan, was natürlich jedes Mal aufs Neue spannend ist.
Host: Und was ist dann im Jahr 2001 passiert, wenn wir ein Stück vorspulen?
Jeff Dean: Um das Durchschmelzen zu verhindern, haben wir damals unter anderem die gesamte Such-, Indexierungs- und Abfrageserver-Architektur kontinuierlich neu geschrieben, um sie effizienter zu machen und andere Datenstrukturen sowie kompaktere Repräsentationen zu verwenden. 2001 kamen wir an den Punkt, an dem wir merkten: Um die Indexgröße und gleichzeitig die Kapazität für die Bereitstellung des Index zu skalieren, erstellten wir immer mehr Partitionen des Index. Wir nannten sie Shards, um einen größeren Index zu erhalten. Und von jedem dieser Shards erstellten wir wiederum immer mehr Kopien, um die Kapazität für die gleichzeitige Beantwortung von mehr Abfragen bereitzustellen. Schließlich kamen wir an den Punkt, an dem wir statt 7 Shards mit je 10 Kopien etwa 60 Shards und je 20 Kopien in jedem Rechenzentrum hatten. Und als wir das schließlich durchrechneten, wurde uns klar: Anstatt den Index auf der Festplatte zu speichern, könnten wir den gesamten Web-Index im Arbeitsspeicher auf jenen 1.200 Maschinen unterbringen, die andernfalls als 20 Kopien der 60 Partitionen gedient hätten. Das war wirklich genial. Wir haben unser gesamtes Suchsystem innerhalb von 3 Tagen um den Faktor 4 beschleunigt, was ziemlich großartig war, ja.
Die Entstehung der TPU: Von der Spracherkennung zu maßgeschneiderten ASICs
Host: Und 2013 hast du ein paar überschlägige Berechnungen angestellt.
Jeff Dean: Ja. Genau. Ich hatte begonnen, an Infrastruktur für das Training von Deep Learning und dem Training von Deep-Learning-Modellen zu arbeiten, weil mir das als die richtige Abstraktion erschien. Ich war tatsächlich bereits 1990 als Student mit neuronalen Netzen in Berührung gekommen und hatte eine Bachelorarbeit über das parallele Training neuronaler Netze geschrieben, weil ich einfach das Gefühl hatte: Das ist der richtige Weg, wir müssen nur 32 schwache Prozessoren statt einem einsetzen, und dann werden wir in der Lage sein, fantastische Modelle zu trainieren. Es stellte sich heraus, dass wir etwa eine Million Mal mehr Rechenleistung brauchten, nicht 32. Aber schließlich, durch die Verbesserungen nach dem Mooreschen Gesetz und so weiter, fingen wir an, diese Rechenleistung ab etwa 2008 oder 2009 zur Verfügung zu haben. Und 2011 starteten wir ein Projekt, um das verteilte Training von Modellen für Sprache, Bildverarbeitung und Sprache wirklich zu skalieren – zu dieser Zeit hatten wir CPUs in unseren Rechenzentren, jede Menge CPUs. Also nutzten wir etwa 16.000 CPU-Kerne, um ein großes Bildverarbeitungsmodell zu trainieren, und wir erzielten diese fantastischen Verbesserungen. Wir machten das auch für Sprachmodelle, und die Modelle brachten erstaunliche Qualitätsverbesserungen. Wir erzielten also das Äquivalent von 20 Jahren Sprachforschung in Bezug auf Verbesserungen der Wortfehlerrate in den rund zwei Monaten, in denen wir versuchten, ein akustisches Deep-Learning-Sprachmodell aufzubauen. Und da dachten wir: Oh mein Gott, das wird so gut werden. Aber wie zum Teufel liefern wir das aus?
Zu diesem Zeitpunkt stellte ich einige Berechnungen an und sagte mir: Okay, angenommen, 100 Millionen Menschen fangen an, jeden Tag ein paar Minuten lang mit ihrem Telefon zu sprechen – wie werden wir das bedienen? Es stellte sich heraus, dass wir die Anzahl der Computer, die Google besaß, hätten verdoppeln müssen, nur um das bessere Spracherkennungsmodell in einem einzigen, winzigen, unbedeutenden Bereich von Google einzuführen. Das schien mir etwas übertrieben, ganz zu schweigen von der Undurchführbarkeit. Also beschlossen wir, dass spezialisierte Hardware der richtige Weg ist. Und das ist quasi die Geburtsstunde der TPU-Familie: Wir wollten spezialisierte Beschleuniger entwickeln, die im Grunde extrem gut in linearer Algebra mit niedriger Präzision und sonst nichts sind. Auf diese Weise kann man Sprachmodelle, Bildverarbeitungsmodelle und so weiter viel effizienter betreiben. Es stellte sich heraus, dass die Leistung pro Watt 2015, als der Chip verfügbar war, um das 30- bis 80-Fache höher war als bei zeitgenössischen CPUs und GPUs. Und das war die erste Iteration.
Bill Jia: Ja, die TPU v1, die wirklich auf Inferenz ausgerichtet war, nicht wahr? Und die nachfolgenden Generationen zielten dann meist sowohl auf Training als auch auf Inferenz ab. Und in jüngerer Zeit haben wir sogar begonnen, diese Linien wieder voneinander zu trennen, weil Training und Inferenz doch etwas unterschiedlich sind.
Host: Und als ihr das Paper 2017 veröffentlicht habt, wurde es angenommen. Es ist das am häufigsten zitierte Paper in der 50-jährigen Geschichte –
Jeff Dean: Ja, der ISCA, genau. Das Paper über die TPU v1 hat viele Autoren; es gibt wahrscheinlich so 35 Autoren oder so. Aber das ist erfreulich, wenn man bedenkt, dass es in der 50-jährigen Geschichte der Computerarchitektur relativ neu ist.
Evolution der TPU-Architektur, Software-Stacks und optischen Vermittlung
Bill Jia: Es ist einfach faszinierend, dass Google als das Softwareunternehmen schlechthin galt, dann aber begann, die Hardware-Roadmap voranzutreiben. Das ist wirklich erstaunlich. Und Hardware zu entwickeln ist das eine – denn um eine TPU fantastisch zu machen, braucht man viel Platinen-, Chipsatz- und TPU-Design. Aber man muss eben auch den Compiler und das Framework tadellos zum Laufen bringen. Schon früh habt ihr XLA, unseren TPU-Compiler, und auch TensorFlow vorangetrieben. Kannst du kurz beschreiben, wie die Anfänge bei der Entwicklung dieses Software-Stacks für die TPU aussahen?
Jeff Dean: Ja. Ich denke, was man als Entwickler oder Forscher im Bereich Machine Learning will, ist im Grunde nur, seine hochgradige Idee auszudrücken und sie dann wie von Zauberhand auf einem groß angelegten System laufen zu lassen, ohne groß darüber nachdenken zu müssen, welche Performance-Tricks man unter der Haube anwenden muss, um tatsächlich eine gute Leistung zu erzielen. Das bedeutet: einen guten Compiler zu haben, hervorragende Interconnects bereitzustellen und Frameworks zu nutzen, die die Abstraktion ermöglichen: Spreche ich gerade mit 4 Chips auf meinem lokalen Rechner oder mit 10.000 Chips in einem großen verteilten Setup? Man möchte darüber idealerweise nicht allzu viel nachdenken oder für diese beiden Szenarien völlig unterschiedliche Dinge tun müssen.
Host: Sprich über die verschiedenen TPU-Generationen und wohin sich das deiner Meinung nach entwickelt.
Jeff Dean: Ja. Nach der TPU v1, die im Grunde nur eine PCIe-Karte war, die in einen Steckplatz passte – und wir hatten damals tatsächlich eine ganze Reihe davon gekauft, ohne zu wissen, wie wir sie nutzen würden; ich habe unseren damaligen CFO in die Enge getrieben und gesagt: Wir müssen viele davon kaufen, weil wir sie nutzen werden, wir wissen zwar noch nicht wofür, aber können wir bitte viele kaufen? Also haben wir das getan. Und die TPU v2 war dann quasi das erste System, das wir mit Blick auf das Training entworfen haben, und zwar nicht nur als einzelner Chip, sondern als ein supercomputerähnliches System aus vielen Chips, die über einen 2D-Torus miteinander verbunden sind. Über die Generationen hinweg haben wir ab der TPU v3 Flüssigkühlung eingeführt. Es ist immer aufregend, wenn man Rohre hat, die direkt an die Oberfläche der Chips im System heranführen – Undichtigkeiten sind dabei allerdings keine gute Sache.
Und dann die TPU v4: Wenn man die Pod-Größe skaliert – TPU v2 und v3 hatten eine feste Verdrahtung zwischen 256 und später 1.024 Chips –, stößt man bei immer größeren Systemen unweigerlich auf Ausfälle einzelner Chips, Platinen oder Systeme. Man muss fehlertoleranter werden, weil man die gesamte Topologie eines viel größeren Pods auch dann noch nutzen können möchte, wenn etwas defekt ist. Deshalb wurde mit der TPU v4 das Konzept eines optisch rekonfigurierbaren Netzwerks zwischen Maschinen-Racks eingeführt.
Host: Man kann sich das also wie Legosteine aus dem gesamten Rechenzentrum zusammenbauen, richtig?
Jeff Dean: Mit drolligen kleinen Switches, die micro-verstellbare Spiegel enthalten, so dass es wirkt, als stünden diese acht Racks direkt nebeneinander, obwohl sie über viele Gänge im Rechenzentrum verstreut sind. Das hat sich als extrem nützlich erwiesen. TPU v5, v6 und v7 haben allesamt Rechenformate mit immer geringerer Präzision eingeführt, was enorm hilfreich war. Man erzielt dadurch eine viel höhere Leistung, auch wenn es sich immer etwas seltsam anfühlt, FLOPS zu vergleichen, wenn einige davon 16-Bit-, andere 8-Bit- und wieder andere 4-Bit-Werte sind. Wenn man diese in seinen Machine-Learning-Algorithmen nutzen kann, sind die Varianten mit niedrigerer Präzision ein hervorragender Weg, um noch mehr Performance herauszuholen.
Pathways: Orchestrierung von Irregularitäten und massives verteiltes Training
Host: Die erste TPU kam also 2015, 2017 erschien das Paper – das inzwischen absoluten Legendenstatus hat. Und 2018 folgte Pathways. Lass uns ein wenig über Pathways sprechen und darüber, warum das so wichtig ist.
Jeff Dean: Ja. Wir haben Pathways im Grunde entwickelt, um das Training deutlich unregelmäßigerer und spärlicherer Modelle zu bewältigen, und auch als zugrundeliegende Systeminfrastruktur, die uns ein einziges Programmiermodell und einen einzigen Prozess ermöglicht, der ein großes verteiltes Trainingssystem steuert. Als Programmierer ist es viel angenehmer, wenn dein einzelner Python-Prozess einfach so aussieht, als hätte er 8.000 angeschlossene Geräte, und du dir denkst: Großartig, ich möchte jetzt einfach ein AllReduce über alle 8.000 Geräte ausführen, und das System erledigt das, ohne dass du irgendetwas Spezielles tun musst.
Ein Teil davon wird von der zugrundeliegenden Software im XLA-Compiler übernommen, und auf einer etwas höheren Ebene orchestriert Pathways dann die Datenverschiebung zwischen all den verschiedenen Chips. Man hat also Chips innerhalb desselben TPU-Pods, und wenn dort kommuniziert werden muss, werden die in den TPU-Pods integrierten Hochgeschwindigkeits-ICI-Verbindungen genutzt. Wenn man jedoch etwas umsetzen muss, das sich über mehrere Pods erstreckt, oder wenn man von diesem Chip in diesem Pod mit jenem Chip in jenem Pod sprechen muss, dann orchestriert Pathways diese Übertragung über das Rechenzentrumsnetzwerk oder sogar über ein Weitverkehrsnetzwerk (WAN), wenn man einen Trainingsjob aus Pods in Oklahoma, Texas und Iowa oder ähnlichen Standorten zusammenschustert. Das liefert im Grunde einfach diese schöne Abstraktion: Ich habe einen riesigen Haufen Rechenleistung, und ich überlasse es dem System herauszufinden, wie es diesen am besten nutzt.
Co-Design von Gemini-Modellen mit Hardware und Infrastruktur
Bill Jia: Ja, das ist faszinierend. Jeff, du warst schon sehr früh stark in das Netzwerkdesign für die TPU, das TPU-Design an sich, den Compiler, das Framework und natürlich Pathways involviert, das den gesamten Datentransfer, die Rekonfiguration des Netzwerkverkehrs und alles andere orchestriert. Das ist also der gesamte Stack der KI-Infrastruktur. Jetzt bist du sehr tief in das Design der Gemini-Modelle involviert – sowohl der aktuellen als auch zukünftiger Gemini-Modelle. Die Gemini-Modelle können somit im Co-Design perfekt auf den gesamten Infrastruktur-Stack abgestimmt werden. Welche Vorteile konnten wir deiner Ansicht nach bereits realisieren, und welche Zukunftsvisionen hast du, um die Grenzen der Modelle weiter auszureizen?
Jeff Dean: Ich denke, die gesamte Palette der TPU-Generationen hat immens davon profitiert, dass wir selbst große Nutzer von ML-Rechenleistung sind und viele Leute haben, die versuchen, die Grenzen neuer Forschungsideen zu verschieben. Das stellt die Hardware oft vor Herausforderungen, die mit bestehenden Workloads so nicht abgedeckt werden. Dadurch, dass sich alles unter einem Alphabet-Dach befindet, können wir einen intensiven Austausch pflegen: zwischen den Designern künftiger TPU-Generationen, den Softwareentwicklern für Compiler und Infrastruktur sowie den Machine-Learning-Forschern. Letztere können sagen: „Hey, dieser Ansatz scheint im kleinen Maßstab zu funktionieren; wir glauben, dass das für großskalige, zukünftige Trainingsläufe in ein oder zwei Jahren enorm wichtig sein wird, und wir wollen sicherstellen, dass unsere Hardware das unterstützt.“
Denn als Computerarchitekt, der isoliert arbeitet und versucht zu erraten, wohin sich das schnelllebige KI-Feld in dem Zwei- bis Sechsjahreszeitraum entwickelt, für den der aktuell entworfene Chip relevant sein muss, ist das verdammt schwierig. Je mehr Einblicke man darüber erhält, was tatsächlich funktionieren wird – und je mehr Iterationen stattfinden –, desto besser. Es ist ja nicht so, dass wir uns einfach überlegen, was wir tun müssen; oft ist es so, dass die Hardware-Leute sagen: „Nun, das ist schwierig, aber wir könnten stattdessen Folgendes tun – wäre das nützlich?“ Und so entsteht ein Hin und Her: „Ja, das würde uns erlauben, etwas umzusetzen, das sehr nahe daran ist, oder vielleicht sogar noch besser.“ Das ist für ein effektives Co-Design von entscheidender Bedeutung.
Zuverlässigkeit im großen Maßstab: Goodput und Fehlertoleranz über 100.000 TPUs hinweg
Bill Jia: Gestern stand ich auf der Bühne, um die Eröffnungsrede zu halten. Ich sprach darüber, dass wir – während wir die Skalierung der Gemini-Modelle vorantreiben (und ich erinnere mich, dass wir jeden Monat in denselben Meetings saßen, um über Zuverlässigkeit zu sprechen; ich komme von der Infrastrukturseite, und Jeff vertritt Google DeepMind) – feststellten: Hey, wissen Sie was, die Gemini-Modelle werden immer größer, und wir setzen Unmengen von TPUs ein, um sie zu trainieren. Schließlich nutzen wir 100.000 TPUs für das Training. Das ist die eine Kennzahl, die wir gemeinsam betrachten: das sogenannte Goodput (nutzbare Rechenleistung).
Anfangs war unser Goodput nicht besonders gut. Ich erinnere mich daran, was wir gemeinsam gesagt haben: Das Badput dominiert das Goodput. Zu Beginn lag es bei etwa 60 %. Wenn man immer mehr TPUs zusammenschaltet, um dieses Modell vorzutrainieren, wird es extrem komplex. Wir brauchen einen größeren Maßstab, mehr Daten, mehr Parallelismus. Das Goodput lag anfangs bei 50 %, 60 %, 70 %, aber das war einfach nicht gut genug, richtig? Um eine lange Geschichte kurz zu machen: Mittlerweile nutzen wir eine massive Trainingsinfrastruktur, trainieren viel komplexere Modelle, und das Goodput kann auf bis zu 95 %, ja sogar 98 % steigen.
Jeff Dean: Ja, und ich denke, das ist tatsächlich eine Kombination aus einer Vielzahl von Faktoren: besseren operativen Abläufen, gründlicheren QA-Tests der Chips bei der Bereitstellung sowie Software-Mechanismen, die besser mit Ausfällen umgehen und kontinuierlich Fortschritte erzielen können, selbst wenn ein Teil des Systems ausfällt. All diese Dinge zusammen sind von enormer Bedeutung und machen einen großen Unterschied.
Bill Jia: Ja, ich denke, das ist ein weiterer Vorteil, wenn wir das Modell besitzen, die Daten besitzen und zudem die gesamte Hardware, die Netzwerke, den gesamten Software-Stack und das Betriebsteam unter einem Dach haben.
Jeff Dean: Man kann sagen: Das ist von entscheidender Bedeutung. Denn wenn man an ein einzelnes TPU-Tray denkt und glaubt, das sei kein Teil eines größeren Systems, sagt man sich: „Okay, gut, das können wir in einer Woche reparieren, wenn wir hier ohnehin routinemäßig vorbeischauen.“ Aber wenn es Teil eines aktiven Pods ist und sich darin defekte Trays befinden, muss man das sofort beheben, weil der Radius der Auswirkungen, die man reparieren muss, tatsächlich viel größer ist, als es zunächst erscheinen mag.
Host: Wenn man also von 100.000 Chips spricht, ist Zuverlässigkeit im Grunde kein Problem mehr, das man einfach mit einem Software-Patch lösen kann. Würdest du sagen, das ist eher eine Frage des Systemdesigns? Hat das mehr mit Physik zu tun?
Jeff Dean: Zuverlässigkeit ist meines Erachtens wirklich eine Eigenschaft des Gesamtsystems, und es gibt viele verschiedene Aspekte, die man robust gestalten muss. Eine Möglichkeit besteht darin, robuste Einheiten aus unzuverlässigen Teilen zu bauen. Das war im Grunde schon von den allerersten Tagen von Google an so. Wir haben billige Consumer-PCs gekauft, um unseren Suchverkehr zu bewältigen, und darauf robuste Softwaresysteme aufgebaut, die es uns erlaubten, den Ausfall einzelner Maschinen abzufangen und dennoch die Funktionalität bereitzustellen, die das jeweilige System liefern sollte. Das kann zum Beispiel ein verteiltes Dateisystem sein, bei dem Daten über mehrere Maschinen hinweg repliziert werden, sodass immer einige Instanzen verfügbar sind, selbst wenn einige Repliken eines Datenblocks offline sind.
Und ich denke, genau dasselbe kann man bei großflächigen KI-Trainingssystemen tun. Wenn man eine Standardkonfiguration mit 20 Pods hat und einer davon ausfällt, kann man den Fortschritt mit den verbleibenden 19 Pods aufrechterhalten, während der 20. Pod repariert wird.
Operative Koordination und Eindämmung stiller Datenkorruption (Silent Data Corruption)
Host: Bill, du hast das gestern in deiner Keynote über OCS und Jupiter bereits leicht angeschnitten. Möchtest du dazu noch etwas sagen und erklären, wie das in puncto Zuverlässigkeit zusammenspielt?
Bill Jia: Ja, ich denke, das war ein langer Weg. Das Erste, worauf wir schauen, sind die Interrupts – wie viele Interrupts pro Tag wir bei jeweils 10.000 Chips und jeder einzelnen Komponente verzeichnen. Das müssen wir minimieren. Denn wenn es zu viele Interrupts gibt und wir gleichzeitig den Trainingscluster hochskalieren, führt das zu Problemen, was natürlich ungünstig ist, richtig? Einer der Schritte, die wir unternommen haben, war die Verbesserung der Hardware-Zuverlässigkeit. Darüber hinaus erwähnte ich gestern, dass die Software bereits vor Beginn des Vortrainings die gesamte Flotte und jede einzelne Komponente scannt: Wie sehen die Vitalzeichen aus? Wenn diese Vitalzeichen problematisch erscheinen, beheben wir das Problem oder schließen die Komponente aus, noch bevor das Training überhaupt beginnt. Das ist der erste Punkt.
Der zweite Punkt: Das Training läuft an. Aber selbst wenn die Hardware zu Beginn sehr starke Vitalzeichen zeigt, erstreckt sich das Training über Wochen, und es können dennoch Probleme auftreten. Wie können wir identifizieren, welche konkreten Komponenten und Server fehlerhaft sind, um sie zu reparieren, auszuschließen oder zu ersetzen? Das ist der zweite Punkt.
Wie Jeff bereits erwähnte, ist zudem eine Menge operativer Koordination erforderlich. Wenn das Rechenzentrum gerade die Stromversorgung für eine komplette Rechenzentrumsreihe wartet und genau diese Reihe das Training durchführt, ist das natürlich suboptimal. Daher stimmen wir uns extrem eng mit den Rechenzentrumsteams, den Site Reliability Engineers (SREs) und allen ML-Forschern und -Ingenieuren ab. Das erfordert massive Koordination; wir müssen absolut synchronisiert sein.
Jeff hat zudem maßgeblich die Entwicklung der Gemini-Modelle und des Software-Designs vorangetrieben. Manchmal fallen Dinge aus, aber das Training kombiniert ohnehin Datenparallelismus und Modellparallelismus. Wenn der Ausfall innerhalb einer Datenreplika auftritt, läuft die zusätzliche Replika möglicherweise einfach weiter, richtig? Die Gewichtungen werden automatisch gemittelt, sodass man sich nicht weiter um den Ausfall dieser einen Replika kümmern muss. Es handelt sich also um eine Fülle umfassender Verbesserungen. Gibt es dazu noch etwas zu ergänzen?
Jeff Dean: Nein. Es kann einfach alles Mögliche passieren, und es ist extrem schwierig, jeden denkbaren Ausfallgrund im Voraus vorherzusagen. Deshalb ist es entscheidend, robuste Mechanismen zu entwickeln, die Fehler erkennen können – selbst wenn man nicht zwingend sofort weiß, was den Fehler ausgelöst hat, man kann ihn aber identifizieren. Gelegentlich hat man Chips, die bei steigenden Temperaturen plötzliche Unzuverlässigkeiten zeigen – etwa, dass sie 2 plus 2 rechnen und 5 herausbekommen.
Bill Jia: Das ist das absolut Fieseste: ein Fehler durch stille Datenkorruption (Silent Data Corruption). Das ist grauenhaft, einfach grauenhaft.
Jeff Dean: Ja, und das kann im Chip selbst passieren, in einer instabilen Netzwerkverbindung oder an vielen anderen Stellen. Wir nutzen hierbei viele derselben Prinzipien wie in der Frühzeit von Google: Da wir diese billigen Consumer-PCs kauften, hatten sie nicht nur keinen ECC-Speicher, sondern oft nicht einmal Paritätsschutz im Arbeitsspeicher. Wenn man also eine enorme Menge an Computern für eine Aufgabe einsetzt und keine davon Parität besitzt, muss man mit zufälligen Bitkipps (Bit Flips) rechnen. Viele der Berechnungen, die wir durchgeführt haben, mussten gegenüber Bitkipps robust sein. Eine Möglichkeit, das zu erreichen, war: Gut, ich verarbeite eine Milliarde Webseiten; wenn mir eine davon verloren geht, ist das vermutlich nicht das Ende der Welt. Man konnte das also ignorieren, indem man über der Hardware-Schicht in der Software Prüfsummen (Checksums) einsetzte, um die Dinge robust zu halten – selbst dann, wenn eine bestimmte Maschine oder eine Netzwerkverbindung unzuverlässig war.
Open-Source-Strategie: JAX, StableHLO und PyTorch auf TPU
Host: Google ist ein starker Befürworter von Open Source, daher möchte ich das Thema nun wechseln und über Open Source sprechen. Ich weiß, dass wir viele Akademiker im Publikum haben und auch viele unserer Partner. Lassen Sie uns also kurz über Googles KI-Infrastrukturstrategie sprechen, insbesondere im Hinblick darauf, sicherzustellen, dass dies keine abgeschottete Ressource bleibt. All diese Dinge, über die wir sprechen, wollen wir mit der Welt teilen. Sprechen wir über JAX und StableHLO sowie die Evolution von Open Source im Allgemeinen und darüber, warum das heute so relevant ist, um zu verhindern, dass dies zu einer exklusiven Ressource wird.
Jeff Dean: Ja, für uns ist es von allergrößter Bedeutung, dass wir mit dem breiteren Ökosystem interagieren. Open Source bereitzustellen, damit Menschen den Quellcode einsehen, ihn modifizieren, uns bei der Verbesserung helfen und ein kollaboratives Projekt daraus machen können, das sich über viele Organisationen erstreckt anstatt nur etwas zu sein, das wir für uns behalten – das ist extrem wichtig. Aus diesem Grund haben wir TensorFlow als Open Source veröffentlicht, ebenso JAX und die StableHLO-Repräsentation für den XLA-Compiler. Und wir werden in Zukunft noch mehr Dinge als Open Source freigeben. Wir sind seit vielen Jahren große Mitwirkende an Open-Source-Projekten im Allgemeinen, wie etwa dem Linux-Kernel und anderen. Normalerweise gehören wir zu den größeren Organisationen, die zu kollektiven Open-Source-Initiativen beitragen, weil wir daran glauben und überzeugt sind, dass das gesamte Ökosystem profitiert, wenn alle zusammenarbeiten.
Host: Das ist die perfekte Überleitung, um über PyTorch und deine Erfahrungen bei Meta zu sprechen.
Bill Jia: Ja, ich habe mich kurz vor diesem Fireside Chat mit Jeff unterhalten. Jeff hat maßgeblich die Open-Source-Strategie für die KI-Infrastruktur angeführt. Wie Jeff erwähnte, hat Google in der Vergangenheit TensorFlow und JAX als Open Source bereitgestellt; auch Kubernetes wurde von Google entwickelt und als Open Source veröffentlicht, ebenso Android und viele weitere fantastische Dinge. Jetzt, da wir die TPU in die Community tragen und TPU auf Google Cloud betonen, verdoppeln wir unsere Anstrengungen bei dieser Open-Source-Strategie.
Tatsächlich haben wir nicht nur den JAX-Kern als Open Source veröffentlicht, sondern auch viele Bibliotheken höherer Ebene aufgebaut – etwa für Reinforcement Learning, was wir TuneX nennen und das auf dem JAX-Kern aufbaut. Auch das haben wir als Open Source freigegeben. Wie man Checkpointing macht, wie Inferenz funktioniert: Wir entwickeln zahlreiche übergeordnete Bibliotheken und Frameworks auf Basis von JAX und machen sie als Open Source zugänglich, weil wir möchten, dass die Leute sie nutzen und diese Open-Source-Strategie anwenden, um direkt auf der TPU zu arbeiten. Das ist das eine.
Und natürlich wollen wir dort sein, wo der Kunde ist, richtig? Deshalb wollen wir auch alle ausgereiften Produkte annehmen, die in der Open-Source-Community bereits existieren. PyTorch ist hochgradig ausgereift und in der Community extrem weit verbreitet. Wissen Sie was? Lasst uns PyTorch auf TPU unterstützen. Wir haben ein Projekt namens Torch-TPU. Momentan befindet es sich in einer privaten Preview. Wir wollen im nächsten Quartal – also in nur wenigen Monaten – eine öffentliche Vorschau starten, und im vierten Quartal wollen wir ein öffentliches Release auf GitHub bereitstellen, sodass es jeder nutzen kann. Und wie ich gestern erwähnt habe: Wenn man Torch-TPU verwendet, sind dafür nur ein paar einfache Zeilen Code nötig, um das Backend-Gerät auf TPU umzustellen, und hoffentlich laufen dann das gesamte Training und die Inferenz auf der TPU. Wir unterstützen dabei sowohl den Eager-Modus als auch den kompilierten Modus. Das ist die Framework-Ebene.
Wir engagieren uns außerdem – ich bin sicher, wir haben viele Nutzer von vLLM und SGLang im Publikum. Wir stehen im Austausch mit den Entwicklern von vLLM und SGLang, um sicherzustellen, dass auch diese übergeordneten Open-Source-Inferenz-Frameworks auf der TPU eingesetzt werden können. Es gibt also aktuell eine Menge Arbeit: Wir geben unsere eigenen Entwicklungen als Open Source frei und integrieren gleichzeitig ausgereifte Open-Source-Produkte der Community.
Automatisierung des Hardware-Designs durch Machine Learning
Host: Wir haben hier im Publikum auch zahlreiche Doktoranden im ersten und zweiten Jahr. Wie viele von Ihnen sind PhD-Studierende? Worauf sollten sie sich konzentrieren? Einige von ihnen sind übrigens auch Bachelorstudenten.
Jeff Dean: Okay. Es ist immer eine spannende Phase in der Karriere, weil man in dieser Zeit Dinge finden kann, die einem wirklich Spaß machen und die man für wichtig hält, und man einen Weg findet, ein bestimmtes Gebiet voranzubringen und weltweit Wirkung zu erzielen. Das ist einfach eine großartige Zeit.
Host: Gibt es einen physischen Engpass, über den du aus Infrastruktursicht nachdenkst?
Jeff Dean: Da gibt es so viele. Ich bin ein großer Verfechter von immer spezialisierterer Hardware, weil das aus meiner Sicht der Weg zu deutlich effizienteren Systemen ist. Und wir haben mittlerweile Workloads, bei denen eine Handvoll von Anwendungen den Großteil der weltweiten Rechenleistung ausmachen wird, richtig? Wenn man sich das vor Augen führt, schreit das geradezu nach Spezialisierung. Das Problem bei der Spezialisierung ist jedoch: Wenn sich die Anforderungen in der Zukunft ändern, ist das mit viel Liebe in Hardware gegossene System vielleicht schon nach zwei Jahren nicht mehr optimal relevant.
Um Spezialisierung wirklich erfolgreich zu machen, muss man daher einen viel größeren Teil des Hardware-Designprozesses automatisieren. Aktuell läuft das Hardwaredesign so ab, dass man ein großes Team von Leuten hat. Einige von ihnen nehmen die High-Level-Spezifikation und erstellen daraus Low-Level-RTL (Register Transfer Level). Weil das manuell übersetzt wurde, benötigt man ein weiteres Team, das überprüft, ob das erste Team gute Arbeit geleistet hat. Und dann gibt es noch ein weiteres Team, das den Chip auf dem Silizium anordnet (Layout). Das wirkt so, als gäbe es hier Raum für mehr Automatisierung: Wenn man wesentlich mehr automatisierte Schleifen schaffen kann, die durch Reinforcement Learning oder andere evolutionäre Techniken durchsucht werden können, und wenn man diese Schleifen schnell genug laufen lassen kann – wozu aktuelle EDA-Tools typischerweise nicht ausgelegt sind –, dann eröffnet sich die Chance auf eine viel automatisiertere Erforschung des Designprozesses und möglicherweise auf eine drastische Verkürzung des Designzyklus.
Wenn man beispielsweise einen neuen Chip mit 10 Leuten in 3 Monaten entwerfen könnte anstatt mit 150 Leuten in 2 Jahren, würde es weltweit viel mehr spezialisierte Hardware geben. Und man müsste viel weniger Wetten auf die ferne Zukunft abschließen: Die Frage, welche Rechenleistung man in zwei bis sechs Jahren benötigt, verschiebt sich dann zu einem Horizont von drei Monaten bis vier Jahren, und das ist eine Wettsituation, auf die man sich viel leichter einlassen kann.
Inferenz-Workloads, Agenten-Systeme und Tool-Engpässe
Bill Jia: Wenn wir ein oder zwei Jahre zurückblicken: Damals lag der Hauptfokus der Branche – einschließlich Google und vieler anderer Frontier Labs – darauf, dieses eine Modell absolut fantastisch zu machen. Der Schwerpunkt lag stark darauf, Pre-Training und Post-Training zum Laufen zu bringen, weshalb ein Großteil der Hardware-Strategie auf der Trainingsseite lag. Doch nun, da große Modelle ausreifen, fließt ein Großteil des Traffics in die Welt der Agenten und auf die Inferenzseite. Jeff, wenn du irgendwelche Überlegungen aus Sicht des Hardware-Designs teilen kannst: Wie können wir Hardware so gestalten, dass sie sich auf den Inferenz-Traffic konzentriert und diesen optimal unterstützt?
Jeff Dean: Inferenz und Training unterscheiden sich ein Stück weit. Bei der Inferenz hat man im Grunde ein fertiges Modell und möchte einfach eine Fülle von Anfragen dafür beantworten. Man möchte also so wenig Informationen wie möglich bewegen, die sich nicht verändern. Die Dinge, die sich nicht verändern, sind die Modellgewichtungen; die Dinge, die sich verändern, sind die Anfragen, der KV-Cache und so weiter. Man muss also ein System entwerfen, das bei der Minimierung dieser Datenbewegungen extrem effizient ist.
Und ich denke zudem: Wenn man nicht mehr nur einen Prompt und eine direkte Antwort sieht, sondern viel unabhängigere Abläufe – ein Agent unternimmt etwas, beschließt ein Tool aufzurufen, das Tool läuft, die Ergebnisse kommen zurück, man fügt das in den Kontext des Modells ein und lässt es entscheiden, was als Nächstes zu tun ist –, werden wir feststellen, dass all unsere Tools viel zu langsam sind, weil sie für Iterationen im menschlichen Tempo konzipiert wurden. Wenn man im Rahmen seines Tools Code kompiliert, ist man zutiefst betrübt, wenn der Compiler langsam ist. Wenn man die Inferenz-Hardware super schnell macht, kann sie Code möglicherweise schneller generieren, als man ihn überhaupt kompilieren kann, und ganz sicher schneller, als man ihn ausführen kann.
Einer der Ansätze, die wir verfolgt haben, besteht daher darin, einige unserer internen Tools zu beschleunigen, um sie leistungsfähiger zu machen. Es zeigt sich, dass man Code recht effektiv von einer Programmiersprache in eine andere übersetzen kann, weil man im Grunde bereits eine vollständige, präzise Spezifikation dessen hat, was man will. Man hat das gesamte Programm in einer interpretierten Sprache wie Python geschrieben und möchte schlicht das exakt äquivalente Programm in Go, Rust, C++ oder einer anderen Sprache. Ein Agent kann das tatsächlich ziemlich gut erledigen – ganz anders als die übliche Coding-Interaktion mit einem Agenten, bei der man sagt: „Erstelle mir bitte einen Webserver“, woraufhin er alle möglichen Details mit Annahmen füllen muss, die vielleicht gar nicht den eigenen Wünschen entsprechen. Mit einem vollständig spezifizierten Tool leistet er jedoch hervorragende Arbeit: Er kann alle Unit-Tests ausführen, alle Unit-Tests übersetzen, diese im neuen System laufen lassen und das Verhalten Seite an Seite verifizieren, um sicherzustellen, dass es sich identisch verhält.
Bill Jia: Wir haben intern bei Google tatsächlich ein Live-Beispiel dafür, das wir Projekt Tern nennen. Da viele Modelle auf TensorFlow basierten, wir aber zu JAX migrieren, übersetzen wir alle TensorFlow-Modelle automatisch, migrieren sie nach JAX und führen sämtliche Unit- und Code-Tests automatisch durch.
Host: Nun gab es ein bestimmtes Paper bei NeurIPS, das von euch eingereicht und abgelehnt wurde und bei dem es hieß, es habe nur sehr geringe Auswirkungen. Es ging um ein Distillations-Paper.
Jeff Dean: Oh ja. Das ist so eine Motivationsgeschichte; das soll eine Inspiration sein. Es stellt sich heraus, dass Distillation wichtig ist. Das ist ein Paper, das meine Kollegen Geoff Hinton, Oriol Vinyals und ich eingereicht hatten – es drehte sich darum, wie man ein großes Formmodell nimmt und es mithilfe von Distillation in ein kompakteres Schüler-Modell (Student Model) destilliert.
Bill Jia: Aus welchem Jahr war das?
Jeff Dean: Das war 2015 oder 2016. Ursprünglich dachten wir dabei an den Kontext des Trainings eines großen Ensembles verschiedener spezialisierter Modelle für die Bildverarbeitung. Das war einer der experimentellen Ansätze in dem Paper: Man hat 20.000 Bildverarbeitungsklassen, trainiert aber ein spezielles Modell für Tiere, ein anderes für Autos, wieder ein anderes für etwas anderes, und destilliert das Ganze dann in ein einziges Modell, das in all diesen Bereichen gut ist. Es wurde zwar abgelehnt, aber macht nichts; wir haben es auf arXiv veröffentlicht. Die Leute haben es ohnehin gelesen.
Host: Nur nicht entmutigen lassen.
Jeff Dean: Ganz genau.
Fragen und Antworten (Q&A): Standard-Hardware vs. spezialisierte Supercomputer
Host: Gut, wir haben noch ein paar Minuten Zeit. Wir nehmen noch ein paar Fragen entgegen. Es laufen ein paar Leute mit Mikrofonen herum. Da haben wir jemanden. Vielleicht können wir hier vorne anfangen. Wenn Sie aufstehen und sich kurz vorstellen sowie ein paar Sätze zu Ihrem Hintergrund sagen könnten.
Publikumsteilnehmer (Ying): Mein ich heiße Ying. Ich war ein Jahrzehnt lang bei Google Brain. Schön, Sie wiederzusehen. Meine Frage an Bill und Jeff: Wir haben über Standard-Software und Standard-Rechenleistung aus den Anfängen von Google gesprochen – das war die Art und Weise, wie Google Anfang der 2000er Jahre skaliert ist. Heutzutage werden die KI-Supercomputer immer spezialisierter und ähneln eher den ursprünglichen Supercomputing-Frameworks. Wie bewerten Sie diese beiden unterschiedlichen Designmuster für Hardware- und Machine-Learning-Systeme? Glauben Sie, dass wir uns in Zukunft eher wieder in Richtung Standard-Hardware bewegen sollten oder sollten wir weiterhin dedizierte Supercomputing-Maschinen bauen? Vielen Dank.
Jeff Dean: Der Grund, warum wir bei der Suche mit Standard-Hardware skalieren konnten, liegt darin, dass die Suche ein sehr dankbares Problem ist: Wenn man sie aufteilt, gibt es nahezu keine Kommunikation zwischen den Maschinen, und man hat die meiste Arbeit auf einer einzelnen Maschine zu erledigen. Man benötigt daher nichts Exotisches in Bezug auf die Verbindungen. Wir hatten damals tatsächlich 100-Megabit-Ethernet an den Maschinen und teilten uns eine 1-Gigabit-Uplink-Leitung pro Rack auf 40 Maschinen auf, sodass faktisch eine Überbuchung von 4 zu 1 vorlag. Das funktionierte jedoch problemlos, weil man Anfragen wie „Palo Alto restaurants“ an jede Maschine schickte und als Ergebnis ein kleines Snippet mit zehn Ergebnissen zurückerhielt. Das Training hingegen treibt die Anforderungen wirklich an die Grenzen: Man benötigt eine enorme Konnektivität.
Am liebsten würde man auf einem einzigen Chip trainieren – das wäre das Beste –, aber das dauert schlicht zu lange oder passt größenmäßig nicht hinein. Also muss man das Problem auf viele Chips aufteilen. Unabhängig davon, wie man es aufteilt – ob Modellparallelismus oder Datenparallelismus –, am Ende entsteht in der Regel ein erhebliches Kommunikationsvolumen. Genau deshalb setzt man auf diese exotischeren Interconnects zwischen den Maschinen. Man strebt die maximale Leistung pro Chip an, um das Problem nicht auf allzu viele Chips verteilen zu müssen, aber man muss es eben dennoch auf eine große Menge verteilen. Aus diesem Grund nutzen wir Flüssigkühlung, um jeden Chip in diesem Szenario so leistungsfähig wie möglich zu machen.
Bei der Inferenz wird es meiner Ansicht nach eher so sein: Man kann zwar spezialisierte Hardware einsetzen, aber diese ist – insbesondere für kleinere Modelle – nicht ganz so exotisch. Wenn die Modelle jedoch größer werden, entstehen Kommunikationsanforderungen, die im Vergleich zu Standard-Ethernet-Hardware und gewöhnlichen Netzwerken recht exotisch anmuten, wenngleich sie im Vergleich zum Training zweifelsohne deutlich konventioneller und mainstream-tauglicher sind. Macht das Sinn?
Fragen und Antworten (Q&A): Open-Source-Beiträge, CUDA-Parität und KI-Agenten für Entwickler
Host: Ich glaube, wir haben hier noch eine Frage.
Publikumsteilnehmer (Andra): Jeff, mein Name ist Andra von Uber. Ich habe eine Frage zum Ökosystem von JAX und OpenXLA, insbesondere angesichts dieser von der Open-Source-Community aufgebauten Infrastruktur. Ich habe das Gefühl, dass wir uns hier in einer Ära der KI-Infrastruktur befinden, die Android und iOS ähnelt. Wie sehen Sie die Möglichkeiten für junge Ingenieure, zu den Bibliotheksfunktionen von OpenXLA beizutragen? Denn die meisten Nutzer sind starke CUDA-Nutzer oder bauen ihre Bibliotheken beziehungsweise Funktionen auf CUDA-Bibliotheken auf. Worzu können junge Ingenieure im Kontext von OpenXLA Ihrer Meinung nach beitragen?
Bill Jia: Erstens sind OpenXLA und JAX sowie der gesamte JAX-Stack vollständig als Open Source verfügbar. Das ist der eine Arbeitsbereich. Ein weiterer Arbeitsbereich ist Torch-TPU. Aktuell arbeiten wir intern eng mit Meta zusammen und entwickeln das Projekt weiter, aber letztlich werden wir es auf GitHub veröffentlichen, damit alle Forscher und Ingenieure in der Community dazu beitragen können. Das sind unsere beiden parallelen Bestrebungen. Jeder junge Ingenieur in der Community, der zum Open-Source-Repository beitragen möchte, ist herzlich eingeladen, mit Google zusammenzuarbeiten. Wir können gerne besprechen, wie wir dieses Open-Source-Repository gemeinsam weiterentwickeln können.
Zudem werden meiner Ansicht nach früher oder später viele Anwender entweder den JAX-Stack oder den PyTorch-Stack für TPUs oder GPUs nutzen. Wenn heute jemand in der Community Probleme bei der Nutzung hat, wendet sich derjenige häufig an Google oder Nvidia, weil dort erfahrene Ingenieure sitzen, oder sie posten ihre Fragen in Community-Diskussionsforen in der Hoffnung, dass jemand das Problem versteht und über ähnliche Erfahrungen verfügt, um es zu beantworten. Meiner Meinung nach ist das jedoch alles viel zu langsam. Wo die Community im Rahmen der Open-Source-Strategie einen wertvollen Beitrag leisten kann, ist folgender: Stellen Sie sich vor, wir hätten einen JAX-Agenten und einen PyTorch-Agenten, die auf GPU oder TPU laufen – ganz egal worauf. Wenn alle in der Community Datenquellen beisteuern, um diesen Agenten wirklich leistungsfähig zu trainieren, dann stellen Sie sich vor, ich hätte einen TPU-Kollegen als KI-Agenten. Wenn ich ein Training, Post-Training oder eine Inferenz durchführe, muss ich nicht bei Google anrufen oder mich durch Foren wühlen; ich kann diesen Agenten direkt um Unterstützung bitten. Wenn der Agent einen großen Teil der Fragen beantworten kann, ist das fantastisch. Das erfordert jedoch die Mitwirkung der gesamten Community, da wir eine Fülle von Datenpunkten und Praxiserfahrungen benötigen.
Jeff Dean: Vielleicht noch ein allgemeiner Punkt zu Open-Source-Beiträgen: Es gibt zahlreiche Möglichkeiten, wie Menschen beitragen können. Es ist äußerst ratsam, sich mit einigen der Maintainer verschiedener Repositories auszutauschen, um herauszufinden: „Ich plane Folgendes – wäre das nützlich?“ oder „Habt ihr Ideen, woran ich arbeiten sollte?“ Bevor man einfach jemandem 5.000 Zeilen Code vor die Füße wirft und sagt: „Hier ist es“, ist es eine sehr gute Idee, sich etwas Rückhalt oder Orientierung darüber zu holen, was tatsächlich gebraucht wird. Wer unbedingt beitragen möchte, aber noch kein konkretes eigenes Projekt im Kopf hat, findet meist eine lange Liste von Dingen, die Entwickler bereits auf dem Schirm haben und die von Nutzen wären.
Publikumsteilnehmer (Andra): Danke für die Antwort. Ein Punkt, der bei mir zu Zögern geführt hat, ist, dass viele Funktionen oder Modul-Kernels nach wie vor stark von CUDA abhängen. Sehen Sie den Trend, Äquivalente unter Verwendung von JAX, OpenXLA oder Torch-TPU zu implementieren, um eine Art allgemeine Kompatibilität im Vergleich zu CUDA-Funktionen zu erreichen? Wäre das eine gute Richtung?
Bill Jia: Ja, ich denke, das wird unweigerlich so kommen. Wenn wir uns intern bei Google den JAX-Stack und den PyTorch-Stack auf TPU ansehen, gleichen wir sämtliche CUDA-Funktionen mit unseren eigenen ab. Wir stellen sicher, dass wir mindestens gleichziehen, wenn nicht sogar besser abschneiden. Das ist unseres Erachtens eine absolute Notwendigkeit, die wir umsetzen müssen. Und auf dieser Ebene wollen wir auch die Low-Level-TPU-SDK-Arbeit als Open Source veröffentlichen.
Jeff Dean: Ich denke zudem, dass Anwender auf einer viel höheren Abstraktionsebene denken wollen. Man möchte in JAX- oder PyTorch-Ausdrücken denken und nicht notwendigerweise darüber nachgrübeln: Wie kann ich das mit speziellem Kernel-Code parallelisieren – sei es in einer TPU-Kernelsprache oder einer GPU-Kernelsprache –, um die maximale Leistung herauszuholen? Idealerweise sollten der Compiler und das zugrundeliegende System das für einen erledigen, sodass man sich ganz auf schöne Abstraktionen wie Matrixmultiplikationen konzentrieren kann.
Fragen und Antworten (Q&A): Skalierung von Netzwerken, 3D-Tori und synchrones Training
Host: Ich glaube, wir haben noch Zeit für eine letzte Frage. Nur noch eine letzte Frage, legen Sie los.
Publikumsteilnehmer (John): Hallo, John von der NYU. Ich arbeite seit vielen Jahren im Bereich Netzwerke. Ich war sehr beeindruckt von den Ausführungen von Bill Jia und dem anderen Kollegen bezüglich der Skalierbarkeit hier. Ich weiß, dass diese TPUs in einem 3D-Torus verbunden sind. Im Vergleich zum Ultra Ethernet Consortium und anderen, die sich mit Fat-Tree-Interconnects befassen: Ist dieser 3D-Torus aus Skalierbarkeits Sicht bei der Hochskalierung von TPUs oder GPUs auf Zehntausende oder sogar eine Million Chips nach wie vor in der Lage, All-to-All-Kommunikation in diesem massiven Maßstab zu bewältigen?
Jeff Dean: Unsere größten Pods für die TPU v5e oder TPU v4 umfassen meines Wissens 9.600 und ein paar Chips. Das ist der Maßstab, in dem wir 3D-Tori einsetzen. Darüber hinaus nutzen wir Pathways als Software-Abstraktion über viele dieser über 3D-Tori vernetzten Pods hinweg; dies greift auf das Rechenzentrumsnetzwerk zurück – je nachdem, welches Fabric im Rechenzentrum vorhanden ist – oder sogar auf ein standortübergreifendes Multi-Metro-Trainings-Setup, bei dem sich beispielsweise 5 Pods in diesem Gebäude in Oklahoma und 8 weitere in diesem Gebäude in Iowa befinden, verbunden über eine High-Speed-WAN-Verbindung. Das hat für uns bei der Skalierung bislang recht gut funktioniert.
Manchmal möchte man die ausgeführten Berechnungen so abbilden, dass man Daten- und modellparallele Dimensionen erhält. Typischerweise möchte man den modellparallelen Aspekt innerhalb eines einzelnen Pods oder eines Pod-Slices halten und datenparallele Repliken über diese Pods oder Pod-Slices hinweg verteilen. Das scheint für uns sehr gut zu funktionieren. Das Schöne an torusbasierten Netzwerken ist, dass sie sich lokal extrem einfach verbinden lassen, anstatt dass man eine hochkomplexe Verkabelung auf dem Rechenzentrumsboden benötigt.
Host: Abgesehen von den drolligen, verspiegelten optischen Switches.
Jeff Dean: Gibt es von deiner Seite noch etwas hinzuzufügen, Bill?
Bill Jia: Ja, das trifft voll und ganz zu. Wir haben ICI innerhalb des Racks, innerhalb des Cubes. Dann nutzen wir OCS, um das Ganze auf 9.600 Chips hochzuskalieren. Darüber hinaus verfügen wir über unser Rechenzentrums-Fabric, das durch die Pathways-Software orchestriert wird. Um über 100.000 Chips hinauszugehen, nutzen wir Cloud-Rechenzentrumsnetzwerke, um alles miteinander zu verbinden. Diese Art der Skalierbarkeit funktioniert für uns äußerst gut.
Jeff Dean: Und ich möchte hinzufügen: Selbst in diesem Maßstab sind wir in der Lage, ein vollständig synchrones Training durchzuführen, was unter dem Aspekt der Reproduzierbarkeit und Interpretierbarkeit im Machine Learning von großem Vorteil ist. Irgendwann wird das asynchrone Training sicherlich wieder eine Rolle spielen, aber bislang konnten wir das synchrone Training sehr weit vorantreiben, und wir werden sehen, was die Zukunft bringt.
Host: Das ist ein wunderbarer Schlusspunkt. Unsere Zeit ist leider um. Vielen Dank, Jeff. Vielen Dank, Bill, für eure Zeit. Draußen auf der Terrasse gibt es noch ein paar richtig coole Giveaways für Sie, darunter Stifte mit berühmten Jeff-Dean-Memes und ein Dev Labs T-Shirt. Vielen herzlichen Dank an alle.