Was Google bei Hot Chips 2025 über die nächste AI-Phase verriet – und was das für Hardware, Modelle und Rechenzentren bedeutet

Auf der Halbleiterkonferenz Hot Chips 2025 hat Google einen selten offenen Blick darauf gewährt, was große Sprachmodelle in den kommenden Jahren wirklich voranbringen wird. Die Keynote „Predictions for the Next Phase of AI“ hielt niemand Geringeres als Noam Shazeer – der Mitautor von „Attention Is All You Need“, Gründer von Character.AI und inzwischen Co-Lead von Google Gemini. Seine Botschaft war leidenschaftlich, aber glasklar: Sprachmodellierung ist „das beste Problem überhaupt“ – und die nächste Evolutionsstufe hängt an einer Kombination aus besserer Hardware, besserer Skalierung und besserer Datenökonomie. Entscheidende Treiber sind mehr FLOPS, mehr und schnellere Speicherhierarchien, mehr Netzwerkbandbreite sowie deterministische, präzisere Software-Stacks bei gleichzeitig sinkender numerischer Präzision, wo sie sinnvoll ist. Dass Google dafür den Herstellern von Supercomputern sinnbildlich „Danke“ sagt, ist kein Zufall: Ohne gewaltige, hochintegrierte Recheninfrastruktur wäre der aktuelle Sprung bei LLMs nicht denkbar.

Von 32 GPUs zu Hunderttausenden: Warum Skalierung der rote Faden bleibt

Shazeer stellte die Entwicklung der letzten Dekade pointiert dar: 2015 galt Training auf 32 GPUs als Meilenstein; 2025 sprechen wir über Hunderttausende Beschleuniger im Verbund. Den Wendepunkt markierte bei Google der Aufbau dedizierter AI-Rechenpods ab 2018: Statt Deep-Learning-Workloads opportunistisch zwischen CPU-Clustern und anderen Backends hin- und herzuschieben, erhielt das Training erstmals eine durchgängig spezialisierte „große Maschine“. Diese institutionalisierte Skalierung hat zwei Konsequenzen. Erstens: Architekturentscheidungen auf Modell- und Systemebene orientieren sich heute an Rechen- und Speicherverteilung über viele Racks hinweg – also an der Realität von verteilten Supercomputern, nicht an Einzelkarten. Zweitens: „Mehr FLOPS mehr besser“ ist nicht bloß ein Marketing-Slogan, sondern ergibt sich direkt aus den Lernkurven großer Modelle: mehr Parameter, mehr Tiefe, mehr nützliche Nichtlinearitäten – aber eben auch mehr Datenqualität und strenger kontrollierte Trainingsregimes, damit zusätzliche Compute auch tatsächlich in Fähigkeiten umgemünzt wird. Shazeers Kernthese: In Summe wächst der Nutzen, wenn Compute, Speicher und Datenpipeline im Gleichschritt skaliert werden.

Was LLMs wirklich wollen: Compute, Speicher, Bandbreite – und Determinismus

Die vielleicht wichtigste Folie der Keynote hieß sinngemäß „Was LLMs von Hardware wollen“. Die Antworten sind wenig überraschend, aber in der Zuspitzung entscheidend: mehr Rechenleistung, höhere Speicherkapazität, höhere Speicherbandbreite und mehr Netzwerkbandbreite – auf allen Ebenen der Hierarchie, von On-Chip-SRAM über HBM bis DDR5 und den Fabric-Links zwischen Racks. Hinzu kommen zwei Punkte, die oft unterschätzt werden. Erstens: niedrigere numerische Präzision dort, wo sie Lernverhalten und Inferenzqualität nicht verschlechtert, um mit gleicher Leistungsaufnahme mehr effektive Operationen zu realisieren. Zweitens: Determinismus in Trainings- und Inferenzpfaden, weil wiederholbare, verlässliche Ergebnisse Programmierung, Fehlersuche und Skalierung dramatisch vereinfachen. In Shazeers Lesart entsteht so ein klarer Pflichtenheft-Zirkel: Hardware muss mehr, schneller und verlässlicher liefern; Software muss das deterministisch, verteilungsrobust und effizient auszunutzen lernen; Datenprozesse müssen gute Daten in der richtigen Reihenfolge, im richtigen Format und mit der richtigen Priorisierung in die Rechenflüsse bringen.

„Danke für die Supercomputer“: Warum Googles TPU-Infrastruktur der Subtext ist

Die Danksagung an die Supercomputer ist nicht nur rhetorische Farbe, sondern Programm. Google hat parallel zur Keynote im Hot-Chips-Umfeld technische Details zu „Ironwood“, der siebten TPU-Generation, offengelegt – und damit gezeigt, wie die „Wünsche“ der LLMs in Silizium, Interconnect und Rechenzentrumsinfrastruktur übersetzt werden. Ironwood ist die erste TPU, die primär für großskalige Inferenz statt Training ausgelegt ist, ohne die Trainingsfähigkeit aus den Augen zu verlieren. Pro Chip stehen zwei Rechen-Chiplets mit zusammen 4.614 TFLOPs (FP8) zur Verfügung, flankiert von acht HBM3e-Stacks mit 192 GB und 7,3 TB/s Bandbreite je Chip. Das eigentlich Spektakuläre ist aber die Systemskala: Bis zu 9.216 TPUs lassen sich zu einem Pod verschalten, der 42,5 ExaFLOPS FP8 erreicht und 1,77 Petabyte direkt adressierbares HBM als gemeinsamen Arbeitsspeicher bereitstellt – ermöglicht durch optische Circuit-Switches, die Racks logisch zu 3D-Topologien verbinden. In der Praxis bedeutet das: Aktivierungs- und Parameter-Sharding, MoE-Routings und Sequenz-Parallelismus können mit drastisch geringeren Kommunikationskosten orchestriert werden, als das klassisches elektrische Fabrics erlauben. Für den Rechenzentrumsbetrieb bringt Ironwood parallel robuste RAS-Funktionen (Root of Trust, Selbsttests, Schutz vor „Silent Data Corruption“, Logik-Repair) sowie die dritte Generation von Flüssigkühlung, die den thermischen Pfad bis in die Cold-Plate-Eingänge hinein kontrolliert.

Was das für Modellarchitekturen heißt: Den Speicherdruck dämpfen, die Rechenwege bestromen

Wenn Speicherbandbreite der limitierende Faktor vieler LLM-Operationen ist, müssen Architekturen nicht nur „mehr rechnen“, sondern vor allem „klüger bewegen“. Der Weg dahin ist zweigleisig. Erstens: Datenfluss-Ingenieurwesen – also Planen, Puffern, Prefetching und Rekonfiguration der Datenwege gemäß Topologie des Rechenpods. Ironwoods optische Umschaltung und das großflächige Shared-HBM senken die Latenz von Kollektivoperationen und vergrößern die „lokal schnellen“ Arbeitsmengen. Zweitens: Algorithmische Sparsamkeit – etwa über Mixture-of-Experts (MoE) mit sparsamer Aktivierung, strukturierte und unstrukturierte Sparsity, Low-Rank-Faktorisierungen und adaptive Präzision. Die Lehre aus Shazeers „Was LLMs wollen“ lässt sich so zusammenfassen: Rechenenergie sollte dorthin fließen, wo sie Informationsgewinn erzeugt. Die dafür nötige Deterministik – wiederholbare Pfade, reproduzierbare Scheduling-Entscheidungen, stabile Batch-Formate – ist nicht Beiwerk, sondern Bedingung, damit verteilte Systeme mit zehntausenden Chips verlässlich konvergieren und im Betrieb vorhersagbar bleiben.

Training vs. Inferenz: Ein Rollenwechsel mit Folgen

Weil Ironwood explizit die Inferenz priorisiert, wird ein fundamentaler Trend sichtbar: Während die ganz großen Trainingsläufe weiterhin gigantische Ressourcen binden, verschiebt sich der Wertschöpfungsschwerpunkt in Richtung effizienter, latenzarmer Inferenz auf Milliarden-Nutzungen pro Tag. Für Architekten bedeutet das, dass Speicherkohärenz, Pipeline-Tiefe, Aktivierungs-Caching und KV-Cache-Layouts stärker in den Mittelpunkt rücken. Gleichzeitig steigt der Bedarf, Context-Fenster zu verlängern, Retrieval-Augmentation zu integrieren und modulare Reasoning-Ketten (z. B. MoE-Router, Tool-Aufrufe, Plan-&-Execute-Sequenzen) zu beschleunigen. Die gute Nachricht: Die gleichen Interconnect- und Speicher-Innovationen, die Training skalieren, helfen der Inferenz – solange Software-Stacks (Compiler, Runtime, Scheduler) die physische Topologie verstehen und ausnutzen.

Datenqualität, Tokenökonomie und das Ende der „Low-Hanging Fruits“

Mehr FLOPS alleine genügt nicht. Shazeer betont, wie stark gute Daten die Modellqualität mitbestimmen. In der Praxis heißt das: kuratierte, de-duplizierte, rechtssichere, diversifizierte Korpora mit hoher Aufgabenrelevanz – und immer öfter synthetische Daten mit Qualitätsgarantien. Zugleich warnt das Google-Top-Management seit geraumer Zeit davor, dass die schnelle Phase naheliegender Verbesserungen (größer, schneller, naiv mehr) abklingt. Die Zukunft liege in tieferen Durchbrüchen bei Reasoning, Werkzeuggebrauch, Sequenz-Ausführung und robusten Agenten-Verhalten. Das korrespondiert mit Shazeers Fokus auf deterministische, vernetzte, speichereffiziente Systeme: Die nächsten Sprünge kommen aus System- und Software-Innovation, die Hardware-Skalierung sinnvoll „veredelt“ – nicht aus blindem Parametertreiben.

Warum Determinismus unterschätzt wird – und doch der Schlüssel zur Planet-Skalierung ist

Im akademischen Kontext ist „Determinismus“ häufig ein Nischenthema; im Hyperscale-Betrieb entscheidet er über Wochen und Millionen. Wer Wiederholbarkeit garantiert, senkt die Varianz von Trainingsläufen, vereinfacht Rollbacks, beschleunigt Regessionsuche und minimiert die Kosten von Fehlexperimenten. Außerdem ist deterministisches Verhalten die Basis, um Fehlerquellen in massiven Fabrics einzugrenzen – von Bitfehlern über Clock-Skew bis zu sporadischen Link-Degradation. Google adressiert das in Ironwood mit Hardware-Features (z. B. SDC-Mitigation, On-Chip-Checks) und betont auf Software-Seite deterministische Builds, feste Saatwerte, reproduzierbare Operator-Pfadentscheidungen und präzise Compiler-Lowerings. Unterm Strich gilt: Determinismus macht aus einem großen System ein beherrschbares System.

Kühlung, Energie, RAS: Physik gewinnt immer

Ein 10-MW-Pod mit zehntausenden HBM-Stacks und kilometerweisen Glasfaserlinks ist zuerst ein thermisches und elektrisches Projekt. Google hebt denn auch die dritte Generation seiner Flüssigkühlung hervor – mit mehrstufigen Kühlkreisläufen, die die Einlassqualität des Kühlmediums sichern, um Cold-Plates nicht zu verschlammen. Parallel dazu wachsen die RAS-Anforderungen: Verfügbarkeit ist nur erreichbar, wenn die Infrastruktur Fehler nicht nur erkennt, sondern umkonfigurieren kann (Stichwort: optische Re-Mapping-Fähigkeiten, Checkpoint-Restore bei Knotenverlust). Dazu kommt „Grid-Awareness“: Eisenbahn-gleichmäßige Lastprofile sind dem Stromnetz lieber als Megawatt-Peaks durch Lastsprünge beim Vortraining. Die Konsequenz: Leistung pro Watt zählt doppelt – ökonomisch wie regulatorisch.

Der strategische Kontext: Google spannt die Brücke von Forschung zu Produkt

Die Rückkehr von Noam Shazeer zu Google und seine Rolle in Gemini unterstreichen, dass der Konzern Forschung, Infrastruktur und Produktskalierung enger verzahnt. Die Ironwood-Initiative wurde im Frühjahr auf Cloud-Next erstmals vorgestellt und nun bei Hot Chips mit Architekturdetails unterfüttert. Analysten sehen darin nicht nur technische, sondern potenziell auch geschäftliche Hebel – bis hin zu Gedankenspielen über eigenständig bewertete TPU-/DeepMind-Assets. Ob es dazu kommt, ist offen; unstrittig ist aber: Mit Trillium (TPU v6) und Ironwood (TPU v7) zeigt Google eine klare Roadmap, die von Speicher- und Interconnect-Dominanz geprägt ist. Für Entwickler bedeutet das: Wer in den kommenden Jahren performante LLM- und Multimodal-Workloads bauen will, sollte sein Denken von der Single-GPU lösen und „Pod-native“ Software entwerfen – von der Batchbildung über KV-Cache-Layouts bis zu kollektiven Reduktionsmustern, die die optische Switching-Topologie ausspielen.

Praxis-Takeaways für Architekten und Teams

Erstens: Planen Sie Modelle und Pipelines explizit für hierarchische Speicher – KV-Cache-Sharding, Aktivierungs-Recycling, Offloading-Strategien und präzise Prefetch-Pläne sind Pflicht. Zweitens: Nutzen Sie Präzisionsmix und Sparsity systematisch (Training wie Inferenz), um Bandbreite-Hotspots zu entschärfen. Drittens: Investieren Sie in deterministische Builds und reproduzierbare Trainings-/Inferenzpfade; die Resultate zahlen sich überproportional aus, je größer das System. Viertens: Denken Sie Energie- und Kühlpfade mit – Energieglättung, Lastmanagement und Telemetrie sind nicht „SRE-Luxus“, sondern Leistungsmerkmale. Fünftens: Verankern Sie Datenqualität als Erstbürger – ohne kuratierte, rechtssichere und aufgabennahe Korpora verbrennen selbst 42,5 ExaFLOPS nur Strom.

Fazit: Größer, schneller, verlässlicher – aber vor allem systemischer

Shazeers Keynote war mehr als ein Loblied auf Rechenleistung. Sie war ein Plädoyer für Systemdenken: Rechenwerke, Speicherpfade, Netze, Compiler, Trainingsregeln und Datenqualität müssen zusammenwachsen. Google demonstriert mit Ironwood, wie stark eine vertikal integrierte Pipeline wirken kann, wenn Hardware, Rechenzentrumsbau und Modell-Engineering aufeinander abgestimmt sind. Der Satz „Danke für die Supercomputer“ ist deshalb auch ein Versprechen: Die nächste AI-Phase wird nicht durch ein einzelnes, magisches Modell kommen, sondern durch die Summe aus skalierbarer Infrastruktur, deterministischer Software und disziplinierter Datenarbeit. Wer diese Trias meistert, baut die Modelle, die nicht nur größer sind – sondern spürbar klüger.

AOMEI Backupper Professional mit Lebenslangen…

AOMEI Partition Assistant Professional Lifetime (2…

Angebot

WD_BLACK SN850P 8 TB NVMe SSD Offiziell Lizenziert…

Letzte Aktualisierung am 1.09.2025 / Affiliate Links / Bilder von der Amazon Product Advertising API. Alle hier angezeigten Preise und Verfügbarkeiten gelten zum angegebenen Zeitpunkt der Einbindung und können sich jederzeit ändern. Der Preis und die Verfügbarkeit, die zum Kaufzeitpunkt auf Amazon.de angezeigt werden, sind maßgeblich. Als Amazon-Partner verdienen wir an qualifizierten Verkäufen.