Wie man GPUs versteht
(jax-ml.github.io)- GPUs spielen im modernen Machine Learning eine zentrale Rolle und bestehen aus einer Struktur, die zahlreiche auf schnelle Matrixmultiplikation spezialisierte Streaming Multiprocessors (SMs) mit HBM (High Bandwidth Memory) kombiniert
- Die SMs einer GPU sind in Tensor Cores (Matrixmultiplikation) und CUDA Cores (Vektoroperationen) gegliedert und unterstützen massive Parallelverarbeitung sowie flexible Programmierung
- GPU und TPU unterscheiden sich in interner Struktur und Netzwerkaufbau; GPUs bieten eine hohe Allgemeinheit und Skalierbarkeit, erfordern aber mehr Überlegungen, um optimale Leistung zu erreichen
- Innerhalb eines Nodes ermöglichen NVLink und NVSwitch ultraschnelle Kommunikation zwischen GPUs, während zwischen Nodes Netzwerke wie InfiniBand große verteilte Trainingsläufe unterstützen
- Kollektivoperationen (Collectives) auf GPUs (z. B. AllReduce, AllGather) hängen leistungsmäßig stark von Hardwarestruktur und Netzwerkebene ab und liegen in der Praxis tendenziell unter der theoretischen Bandbreite
Was ist eine GPU?
- Moderne ML-(Machine-Learning-)GPUs (z. B. H100, B200) kombinieren Dutzende bis Hunderte auf Matrixmultiplikation spezialisierte Streaming Multiprocessors (SMs) mit schnellem HBM-Speicher
- Jeder SM enthält Tensor Cores (Matrixmultiplikation), Warp Scheduler (Vektoroperationen) und SMEM (On-Chip-Cache)
- Anders als bei einer TPU ermöglichen GPUs mit mehr als 100 SMs flexiblere und stärker parallelisierte Verarbeitung
Details zur SM-Struktur
- Ein SM ist in 4 Subpartitionen unterteilt; jede Subpartition enthält jeweils Tensor Cores, CUDA Cores (Vektoroperationen), Warp Scheduler, Register File usw.
- CUDA Cores sind für Vektor-Arithmetik (SIMD/SIMT) zuständig, Tensor Cores sind auf Matrixmultiplikation spezialisiert
- Die FLOPs der Tensor Cores sind überwältigend höher, und bei Berechnungen mit niedrigerer Präzision steigt der Durchsatz weiter
- Aktuelle GPUs (z. B. B200) verfügen zusätzlich über großes TMEM, um umfangreiche Eingaben für Tensor Cores zu unterstützen
Die Flexibilität der CUDA Cores
- Die CUDA Cores einer GPU verwenden das SIMT-Modell (Single Instruction Multiple Threads), bei dem ein Befehl parallel auf viele Threads ausgeführt wird
- Jeder Thread besitzt einen eigenen Befehlszeiger (Program Counter) und bietet damit Flexibilität etwa für bedingte Verzweigungen; viele Verzweigungen innerhalb eines Warps führen jedoch zu Leistungseinbußen
- Jeder CUDA Core kann seinen Zustand und Speicherzugriffe individuell handhaben (TPUs können nur zusammenhängenden Speicher verarbeiten)
Scheduling/Parallelität
- Ein SM plant viele Warps (bis zu 64) zur gleichzeitigen Ausführung ein, wobei jeder Warp Scheduler jeweils ein Programm gleichzeitig ausführt
- Diese Struktur ermöglicht GPUs eine hohe Parallelität bei gleichzeitig beträchtlicher Flexibilität
Speicherstruktur der GPU
- Bei GPUs ist HBM der größte Speicher; daneben gibt es eine Speicherhierarchie aus L2/L1 (SMEM)/TMEM/Registern
Zusammenfassung aktueller GPU-Spezifikationen
- Anzahl der SMs (Streaming Multiprocessors), Takt, Speicher, FLOPs und Bandbreite (BW) unterscheiden sich je nach Modell
- Speicherkapazität (HBM), Bandbreite und FLOPs (Floating Point/Ganzzahl/niedrige Präzision) steigen von Generation zu Generation
- Wichtige Merkmale aus der Tabelle (ausgelassen): Blackwell (B200) bietet HBM 192GB, HBM-BW 8.0TB/s, FP8-FLOPs 4.5e15 usw.
- Der Hardware-Fortschritt zeigt sich klar in jeder Generation, etwa bei Register- und On-Chip-Cache-(SMEM-)Kapazität sowie der Ergänzung von TMEM
GPU/TPU-Vergleich
- GPUs sind allgemein einsetzbar und in viele kleine SMs (parallele Einheiten) modularisiert; sie bieten viel Hardwarekontrolle, sind aber schwieriger zu verstehen und zu optimieren
- TPUs bestehen aus wenigen großen Tensor Cores und vielen Vektor-ALUs (VPUs); durch die Steuerung über einen einzelnen Thread kann die Hardware einfacher und kostengünstiger sein
- Daher ist bei TPUs Compiler-Optimierung unverzichtbar, während GPUs mehrere Kernel unabhängig ausführen können, was die Nutzung erleichtert
- Beim Verhältnis von Leistung zu Preis bietet die aktuelle H200-GPU etwa doppelt so viele FLOPs/s wie eine TPU v5p, 1,5-mal so viel HBM, kostet aber etwa 2,5-mal so viel
- TPUs verfügen über viel und schnelles VMEM (On-Chip-Cache), was etwa bei der Inferenz von LLMs große Vorteile bringen kann
Kernaussagen aus dem GPU-Hardware-Quiz Q&A
- Das H100 hat insgesamt 16.896 fp32-CUDA-Cores (132 SM x 4 x 32), das B200 18.944
- Die FLOPs für Vektoroperationen liegen beim H100 bei maximal rund 33,5TFLOPs/s und damit 30-mal unter den Matrixmultiplikations-FLOPs der Tensor Cores (990TFLOPs/s)
- Die kombinierte Kapazität von L1/SMEM und Registern im H100 beträgt 66MB, TPU-VMEM 120MB
- Das Verhältnis von Bandwidth (Bandbreite) zu FLOPs (theoretische Rechenintensität) liegt bei H100/B200 jeweils bei etwa 280–300 und ist damit ähnlich wie bei TPUs
GPU-Networking (Kommunikationsstruktur)
Node-/Cluster-Struktur
- GPU-Nodes sind meist in Gruppen von 8 GPUs aufgebaut und über NVLink (ultraschnell) sowie NVSwitch (Switch) mit voller Bandbreite direkt verbunden
- Zwischen Nodes ist Scale-out über InfiniBand (oder Ethernet usw.) möglich
- Aktuelle GPUs (Blackwell) unterstützen Architekturen, die sich auf bis zu 72 Nodes erweitern lassen
Merkmale nach Netzwerkebene
- Innerhalb eines Nodes (NVLink-Bereich): Egress pro GPU 450GB/s (H100), 900GB/s (B200), bis zu 1,6TB/s pro NVSwitch
- Oberhalb des Nodes (InfiniBand Leaf/Spine): Struktur mit Leaf Switches (8) bis Spine Switches (16), wobei theoretisch 400GB/s Full Bandwidth zwischen GPU und GPU erhalten bleiben
- In großen Architekturen wie SuperPod mit 1024 GPUs (128 Nodes) oder GB200 (72-GPU-Node) steigt die Bandbreite um das 9-Fache (3600GB/s)
Wichtige Punkte zur Netzwerkleistung
- Die theoretische Netzwerkstruktur (Full Fat Tree) ist so ausgelegt, dass auch zwischen Node und Node maximale Bandbreite bereitgestellt wird
- Wegen Hardware-Port-Beschränkungen wird bei einer Skalierung auf 1024–4096 GPUs eine mehrstufige Struktur mit zusätzlichen Spine-/Core-Switches verwendet
- Der Wechsel von Bandbreite innerhalb des Nodes (450GB/s) zu Bandbreite zwischen Nodes (400GB/s) führt zu Leistungsunterschieden bei Kollektivoperationen
Struktur von Kollektivoperationen (Collectives)
- Unterstützung für übergeordnete Kollektivoperationen wie AllGather, AllReduce (Summierung) und AllToAll (Verteilung)
- Innerhalb eines Nodes sind über NVLink direkte Verbindungen mit optimaler Leistung möglich (theoretische B/W), zwischen Nodes läuft die Kommunikation über InfiniBand
- Verwendet werden Bibliotheken wie NVIDIA NCCL und NVSHMEM
Leistungsanalyse von Kollektivoperationen
- AllGather/ReduceScatter: per Ring-Verfahren mit B/W (450GB/s beim H100) implementiert; bei kleinen Nachrichten ist auch ein Tree-Verfahren möglich
- AllToAll: Jede GPU sendet direkt an die jeweilige Ziel-GPU; da die Bandbreite durch N geteilt wird, ist es innerhalb eines Nodes theoretisch doppelt so schnell
- Tatsächliche Messungen zeigen bei AllReduce etwa 370GB/s und erreichen damit nicht das Hardware-Maximum
- Im Vergleich zu TPUs wird die Peak Bandwidth der Hardware erst bei großen Datenmengen (zig MB bis GB) annähernd erreicht
Zusammenfassung und Erkenntnisse
- GPUs punkten mit Allgemeinheit und Skalierbarkeit, aber je nach Hardware- und Netzwerkstruktur sind Leistungsoptimierung und Beobachtbarkeit anspruchsvoller als bei TPUs
- Networking (Intra-Node/NVLink/InfiniBand/Leaf/Spine usw.) ist entscheidend für die Leistung großer Trainingsläufe; auf die Differenz zwischen realer und theoretischer Bandbreite muss geachtet werden
- Das Verständnis von Kollektivoperationen und Netzwerkstrukturen ist ein wesentlicher Faktor für das Training/Serving extrem großer verteilter Modelle
- Um Engpässe und optimale Bedingungen zu identifizieren, ist ein Vorgehen erforderlich, das auf praktischen Benchmarks und einem Verständnis der Hardwaredetails basiert
1 Kommentare
Hacker-News-Kommentare
Ich fand diesen Artikel und mehrere andere Dokumente etwas unklar, besonders weil bei Erklärungen zu GPUs Begriffe oft uneindeutig verwendet werden. Zum Beispiel wird im ersten Bild der „Warp Scheduler“ als eine SIMD-Vektoreinheit ähnlich der VPU einer TPU beschrieben und es heißt, es gebe 32 „CUDA Cores“, aber was ein „CUDA Core“ hier genau ist, wird nicht klar erklärt, sodass der eigentliche Gegenstand der Erklärung nicht richtig vermittelt wird. Durch diese zusammengesetzten Fehler bleibt es für Anfänger oder Leser, die sich die Konzepte erst aneignen wollen, weiterhin schwer verständlich, während es für Leute, die die Konzepte schon einigermaßen kennen, nur Bekanntes wiederholt. Selbst wenn es ein Entwurf war, sollte man beim Veröffentlichen jeden einzelnen Begriff mit chirurgischer Präzision behandeln und Begriffe weder verwechseln noch vermischen. Analogien sollte man vorsichtig einsetzen. Und ich denke, Begriffe wie MXU (Matrix Multiply Unit) sollten durch zusätzliche Erklärungen oder Hyperlinks leicht auffindbar sein. Heutzutage kann man diese Rolle auch einer AI übertragen, was irgendwie traurig ist.
Ich antworte direkt als Autor: Ich stimme der Kritik größtenteils zu. Je mehr ich versuche, in der Erklärung Genauigkeit sicherzustellen, desto mehr ringe ich immer mit dem Gleichgewicht zur „moralischen Wahrheit“. Ich könnte zum Beispiel schreiben: „eine TPU-VPU-ähnliche Einheit, die aus 32 SIMD-(Single Instruction, Multiple Data)-Vektoreinheiten (ALUs) besteht, die NVIDIA CUDA Cores nennt“, aber dann wird der Satz lang und Definitionen für Begriffe wie Vektoreinheit fehlen womöglich trotzdem wieder. Ich bemühe mich, viele Fußnoten zu verwenden, aber man kann auch kaum erwarten, dass Leser alles anklicken, und Sidenotes sind in HTML schwer umzusetzen. Begriffe wie MXU hatte ich zwar schon in einem früheren Kapitel definiert, aber es ist wohl zu viel verlangt anzunehmen, dass Leser zwingend alle Kapitel lesen. Auch „Warp Scheduler“ ist tatsächlich ein mehrdeutiger Begriff, der mehrere Rollen meinen kann (Scheduler, Dispatch Unit, SIMD-ALU), aber das liegt daran, dass NVIDIA dieser zusammengesetzten Einheit keinen eigenen Namen gibt. Ich werde weiter daran arbeiten, das zu verbessern. Es ist eine fortlaufende Reihe schwieriger Kompromisse.
LLMs sind ein ziemlich gutes Werkzeug, um genau solche Hürden bei der Verknüpfung von Begriffen aufzulösen. Wenn man einen Begriff nachschlägt und dabei eine Kette weiterer unbekannter Begriffe auftaucht, können sie gut dabei helfen zu zeigen, wo man mit dem Lernen anfangen sollte.
Fast alles steht im Dokument zur Google-TPU-Systemarchitektur.
Ich möchte das ernsthaft fragen: Welches Maß an Vorwissen über Computerarchitektur ist hier angemessen? Das SIMD-Konzept selbst ist schon über 50 Jahre alt. In der Einleitung des Materials wird offenbar vorausgesetzt, dass man LLMs und die Transformer-Architektur versteht, gleichzeitig heißt es aber, dass man nicht verstehen müsse, wie Computer grundsätzlich funktionieren. Trotzdem denke ich, dass man die grundlegende Funktionsweise einer CPU nicht kennen sollte?
Dieser Inhalt ist ein Kapitel aus einem Buch, das sich an Menschen richtet, die im Bereich Machine Learning arbeiten.
Ich habe das Gefühl, dass es sehr schwer ist, die investierte Zeit zu rechtfertigen, wenn etwas nicht Open Source ist oder keine technologieübergreifend von mehreren Anbietern nutzbare Lösung darstellt. Gut darin zu sein, Nvidia-Chips auszunutzen, wirkt für mich ein bisschen wie früher SAP-ABAP-Berater zu sein. Natürlich verdient man in diesem Bereich viel Geld, aber historisch betrachtet war diese Art von Spezialisierung meiner Meinung nach nicht besonders vorteilhaft.
Ich habe vor 10 Jahren an der Uni auch so gedacht und einen CUDA-Kurs absichtlich ausgelassen.
CUDA besteht aus zwei Dingen: der Hardwarearchitektur und dem dazugehörigen Software-Stack. Der Software-Stack ist proprietär, daher muss man sich darum nicht unbedingt kümmern, solange man nicht selbst Low-Level-Optimierungen vornehmen will. Aber die Hardwarestruktur ist absolut lernenswert. Alle GPUs funktionieren im Grunde auf ähnliche Weise (die Grundphilosophie der CUDA-Architektur ist seit 2007 dieselbe), und diese Architektur beeinflusst stark, wie Shader-Sprachen und GPU-Abstraktionen gestaltet sind. Wenn man Details wie Thread-Scheduling, Warps oder die Struktur von privatem und gemeinsam genutztem Speicher versteht, kann man Algorithmen viel besser an das Ausführungsmodell der Hardware anpassen und so enorme Rechenleistung nutzen.
Ich möchte betonen, dass die Prinzipien des parallelen Rechnens und die Funktionsweise auf Hardware- und Treiberebene zu einem erheblichen Teil allgemeingültig sind. Ein Teil ist plattformspezifisch, aber vieles lässt sich breit anwenden. Wenn man zu sehr nur auf Allgemeingültigkeit setzt, kann das im Gegenteil sogar nachteilig sein. Ob etwas Open Source ist und ob es allgemein oder spezialisiert einsetzbar ist, kann man auch getrennt betrachten; insofern lohnt sich eine breitere Auseinandersetzung.
Der Wechsel ist nicht besonders schwer. Wer schon OpenMP- oder MPI-Code geschrieben hat, fand den Einstieg in CUDA an sich leicht. Wenn man lernt, wie man in CUDA Performance optimiert, werden auch parallele CPU-Programme schneller. Im Kern ist es also eine Weiterentwicklung bestehender Rechenmodelle.
Ich habe als Kind auf IBM PC/MS-DOS programmieren gelernt. Beides war nicht Open Source, und trotzdem hilft es mir bis heute enorm.
Ich denke, die Rechnung im Abschnitt „Quiz 2: GPU nodes“ ist ungenau. In der Praxis hat jede GPU oder jeder Switch nur begrenzt viele Ports, daher stehen die theoretisch möglichen 450 GB/s nicht verlässlich zur Verfügung. Deshalb bieten die großen Clouds oder Referenzsysteme 3,2 TB/s an. Wenn 3,6 TB/s möglich wären, gäbe es bei verteilten Ring-Workloads einen Flaschenhals. Übrigens suche ich gerade einen Job.
Diese ganze Serie war wirklich großartig. Sie erklärt die theoretischen Grenzen moderner AI-Workloads und macht technische Prinzipien wie Architektur und Parallelisierung leicht zugänglich. Zwar steht die TPU im Mittelpunkt, aber das meiste lässt sich auch auf andere Bereiche anwenden und ist deshalb sehr nützlich.
Die richtige Reihenfolge ist, numerisch intensive Programme in einer Sprache mit starker Typisierung so weit wie möglich zu optimieren und erst dann, wenn es immer noch schneller sein muss, die GPU-Option zu prüfen. Nach meiner Erfahrung wird es mit einer GPU ungefähr 8-mal schneller. Wenn man die Antwortzeit einer Webanwendung von 4 Sekunden auf 0,5 Sekunden senken kann, ist das ein enormer Unterschied. In der Praxis ist es aber oft einfacher, per WebSocket eine Verzögerungsanzeige (Spinner) zu zeigen oder einen Background-Cache zu verwenden. Und man sollte bedenken, dass GPUs in der Cloud teuer sind.
Ich finde es interessant, dass
nvshmemim ML-Bereich so viel Aufmerksamkeit bekommt. Dagegen war MPI mit ähnlicher Funktionalität in der Welt älterer wissenschaftlicher Simulationen nicht besonders zufriedenstellend. Zur Einordnung: Ich habe meist an schwierigen Aufgaben gearbeitet, etwa an Fernkraftberechnungen über mehrere Knoten hinweg.Ich frage mich, warum Nvidia nicht selbst eine TPU entwickelt hat.
Das müssen sie nicht. Sie haben bereits eine dominante Position im Markt für Hardware und Programmiermodelle, und eine TPU ist im Gegenteil schwerer zu programmieren.
Wie in diesem Artikel im Grunde erklärt wird, kommen 90 % der Nvidia-GPU-Leistung aus Matrix-Recheneinheiten, daher ist sie strukturell fast schon eine TPU. Man gibt etwas Performance auf, bekommt dafür aber ein deutlich flexibleres Compiler-Ökosystem.
Ich bin überrascht, dass Nvidia bis heute keine offiziellen Ressourcen auf diesem Niveau bereitgestellt hat. Am Ende sind es Drittanbieter, die die Hardware durch Reverse Engineering analysieren und zu tatsächlich brauchbaren Konzeptdiagrammen aufbereiten. Ich frage mich, was Nvidias wahres Motiv ist. Wenn es nur um Marketing geht, dann waren sie damit erfolgreich, aber bei der Engineering-Kultur bleiben bei mir Fragen offen.
Aus Sicht eines Echtzeit-Rendering-Ingenieurs war das schon immer so. NV hält die meisten Informationen sehr bewusst zurück, damit Konkurrenten Änderungen zwischen Generationen nicht nachvollziehen können. Andere Anbieter sind nicht viel anders. Im Spielebereich bekommt man unter NDA zwar detailliertere Architekturinformationen, aber außerhalb davon habe ich – außer bei Intel – keine vollständige Offenheit gesehen.
Nvidia hat im Vergleich zu anderen Anbietern tatsächlich sehr gute offizielle Dokumentation.
Mich würde interessieren, warum du das so empfindest. Tatsächlich scheint ein Großteil des Inhalts dieses Artikels fast direkt aus den offiziellen Nvidia-Dokumenten übernommen zu sein. Zum Beispiel wurde auch das H100-Diagramm in Wirklichkeit ohne Quellenangabe aus dem H100-Whitepaper kopiert. Auch Angaben zu Rechenleistung und Bandbreite werden in den offiziellen Whitepapers und in den Kapiteln 5, 6 und 7 des CUDA-C++-Leitfadens bereits vollständig behandelt. Dass Außenstehende das kompakter aufbereiten und mit zusätzlicher Interpretation versehen, ist wertvoll. Aber ohne die offiziellen Nvidia-Materialien wäre so ein Artikel überhaupt kaum möglich gewesen, daher sind solche unbelegten Vermutungen oder Verdächtigungen etwas überzogen.
Nvidia veröffentlicht nur Dokumentation auf mittlerem Niveau, sodass nur geschlossene Bibliotheken wie cuBLAS oder cuDNN wirklich schnell sind, was die Vendor-Lock-in-Struktur verstärkt. Dadurch wird es für andere Anbieter auch schwerer, durch Reverse Engineering aufzuschließen.
Wenn man verschiedene Anzeichen zusammennimmt, scheint Nvidia dazu zu neigen, maßgeschneiderte Materialien nur NDA-Unterzeichnern und VIPs bereitzustellen und die Veröffentlichung öffentlicher offizieller Handbücher bewusst zu vernachlässigen. Vermutlich ist das wirtschaftlich vorteilhaft für sie. Selbst wenn man bei der offiziellen API-Dokumentation Hürden errichtet und normale Entwickler dadurch schlechteren Zugang haben, konzentriert sich Nvidia auf den Verkauf des gesamten Ökosystems – AI, GPUs, Software und Materialien für VIPs – und kümmert sich daher schlicht weniger um gewöhnliche Entwickler.
Wenn wir Architekturdiagramme betrachten, sollten wir unbedingt im Hinterkopf behalten, dass sie die reale Hardware nicht perfekt widerspiegeln. Nvidia garantiert nicht, dass die Blöcke oder Komponenten in den Diagrammen tatsächlich so existieren; sie dienen vielmehr nur als mentales Modell, um über die Struktur von GPU und SM nachzudenken. Zum Beispiel weiß man offiziell nicht, wie viele Funktionseinheiten ein tatsächliches SM hat, ob ein „Tensor Core“ wirklich eigenständige Hardware ist oder eher das Ergebnis einer Kombination mehrerer Einheiten, oder wie genau die Details unterhalb der Warp-Ebene funktionieren.
Wirklich eine fantastische Ressource, ich habe dadurch viel Gutes mitgenommen.