Als wir Gaudi-Beschleuniger in die EC2 DL1-Instanzen von Amazon einführten, standen wir vor einer Herausforderung, die die gesamte Bereitstellung gefährdete. Die Leistungszahlen waren nicht nur enttäuschend; sie waren katastrophal. Bei Modellen, die ein effektives Coaching erforderten, kam es bei der Skalierung über mehrere Knoten zu einem Leistungsabfall von bis zu 50 %. Das Drawback? Eine Netzwerktopologie, die alle Datenbytes durch den Hostspeicher leitete, was zu einem Engpass führte, der alles zunichte machte, wofür Gaudi entwickelt wurde.
Ich leitete die technischen Bemühungen zur Lösung dieses Issues, die letztendlich zur Entwicklung dessen führten, was wir heute Peer Direct nennen. Es handelt sich um eine Funktion, die die Artwork und Weise, wie Gaudi-Beschleuniger in Cloud-Umgebungen kommunizieren, verändert hat, und ihre Geschichte bietet einige nützliche Lehren für verteiltes KI-Coaching im großen Maßstab.
Das Drawback mit Host-NICs
Gaudi wurde so konzipiert, dass die NIC (Community Interface Card) direkt in das Silizium eingebettet ist. Jeder Chip verfügt über zehn Netzwerkschnittstellen, die 100 Gbit/s verarbeiten können und RDMA mit RoCE v2 unterstützen, sodass Geräte direkt auf den Speicher des anderen zugreifen können, ohne dass die CPU benötigt wird. Diese Architektur ist äußerst effizient für KI-Trainings-Workloads, bei denen kollektive Vorgänge wie AllReduce Farbverläufe von Dutzenden oder Hunderten von Geräten professional Trainingsiteration akkumulieren müssen.
Aber Cloud-Bereitstellungen entsprechen nicht immer perfekten Architekturen. Als Amazon Gaudi für DL1-Instanzen testete, mussten sie normale Host-NICs anstelle von Gaudis integriertem Netzwerk verwenden. Die Gründe waren pragmatischer Natur: Kosteneinsparungen und die logistische Umgehung der vorhandenen Rechenzentrumsinfrastruktur zur Anpassung an eine neue Netzwerktopologie. Aus geschäftlicher Sicht warfare die Nutzung einer etablierten Netzwerkinfrastruktur absolut sinnvoll.
Aus leistungstechnischer Sicht warfare es eine Katastrophe. Anstelle von Peer-to-Peer-RDMA-Übertragungen zwischen Gaudi-Karten verlief die gesamte Kommunikation umgekehrt. Daten mussten aus Gaudís Speicher mit hoher Bandbreite in den Host-DRAM dupliziert, von der Host-CPU verarbeitet, über TCP/IP an die Host-NIC gesendet, vom entfernten Host empfangen und zurück in den Speicher des entfernten Gaudí dupliziert werden. Alle zusätzlichen Sprünge verursachten Latenz, stahlen CPU-Zyklen und führten zu zusätzlichen Bandbreitenbeschränkungen, die die Skalierbarkeit des verteilten Trainings völlig zunichte machten.
Der Leistungsmangel warfare so groß, dass man sich fragte, ob sich der Einsatz überhaupt jemals lohnen würde. Hierbei handelte es sich nicht um eine triviale Optimierung; es warfare eine existenzielle Bedrohung für die gesamte Vereinbarung mit AWS.
Warum Leistung so wichtig ist
Es lohnt sich zu wissen, warum ein Leistungsverlust von 50 % für die Lebensdauer von Trainingsmodellen und insbesondere von großen Modellen wie GPT-5 so katastrophal ist. Heutzutage dauert es Wochen oder Monate, selbst auf riesigen Clustern riesige Sprachmodelle zu trainieren. Wenn Sie mit Modellen herumspielen, die Milliarden oder Billionen Parameter haben, schlägt sich jeder Prozentpunkt der Leistung direkt in Zeit und Geld um.
Betrachten Sie die Ökonomie. Wenn die Schulung eines Modells 30 statt 15 Tage dauert, warten Sie nicht nur länger; Sie zahlen für die doppelte Rechenzeit. Im Cloud-Maßstab mit Hunderten oder Tausenden von Beschleunigern im Dauereinsatz summiert sich dies auf Millionen von Greenback. Schlimmer noch, es halbiert Ihre Iterationsgeschwindigkeit. In einer wettbewerbsintensiven KI-Welt, in der Unternehmen um die Entwicklung verbesserter Modelle konkurrieren, kann die Verdoppelung der Anzahl von Exams innerhalb desselben Zeitraums den Unterschied zwischen Vorsprung und Rückstand ausmachen.
Auch die Umweltkosten sind von entscheidender Bedeutung. Große Modelle benötigen zum Anlernen viel Strom. Bessere Leistung bedeutet weniger Rechenzeit, was den Energieverbrauch und die CO2-Emissionen halbiert. Da der Druck auf die KI-Branche, ihren CO2-Fußabdruck zu verringern, zunimmt, sind Effizienzsteigerungen kein Luxus mehr, sondern eine Notwendigkeit.
Die von uns entwickelte Lösung, Peer Direct, lieferte eine RDMA-ähnliche Leistung, als das physische Netzwerklayout nicht für normales RDMA geeignet warfare. Wir benötigten direkten Speicherzugriff zwischen Gaudi-Geräten auf verschiedenen Systemen, ohne den Host-Speicher zu durchlaufen, allerdings auf Host-NICs, die überhaupt nicht dafür ausgelegt waren.
Der Wegbereiter warfare der AWS Elastic Cloth Adapter, eine leistungsstarke Netzwerkschnittstelle für HPC- und KI-Workloads auf EC2. EFA bietet Betriebssystem-Bypass-Kommunikation mit geringer Latenz, typischerweise einer Latenz von weniger als 10 Mikrosekunden. EFA bietet RDMA-ähnliche Semantik mithilfe von libfabric, einer In-Person-House-Kommunikationsbibliothek, die eine gemeinsame Schnittstelle für mehrere Netzwerktechnologien bietet.
Die Aufgabe bestand darin, libfabric mit der Collective Communication Library (HCCL) von Habana zu kombinieren, die alle verteilten Trainingsarbeitslasten abwickelt. HCCL wurde auf der Grundlage von nativem RDMA unter Verwendung von Gaudis On-Chip-NICs erstellt. Wir mussten eine Brücke schaffen, die es HCCL ermöglicht, libfabric clear für die Kommunikation zu nutzen, ohne seine Leistungsgarantien und Kommunikationssemantik zu beeinträchtigen.
Die Lösung erforderte mehrere technische Fortschritte. Zuerst haben wir ein Speicherregistrierungssystem eingeführt, das es libfabric ermöglichte, direkt auf Gaudis Speicher mit hoher Bandbreite zuzugreifen. Wir haben das DMA-BUF-Framework des Linux-Kernels verwendet, das einen gemeinsamen Mechanismus zum Teilen von Gerätetreiberpuffern bietet. Wenn HCCL Daten übertragen muss, stellt der Gaudi-Treiber einen DMA-BUF-Dateideskriptor für die Speicherregion bereit, den libfabric verwenden kann, um RDMA-Übertragungen direkt aus dem Gerätespeicher zu erstellen.
Zweitens haben wir einen LRU-Cache für Speicherregistrierungen integriert. Die Speicherregistrierung ist teuer; Dabei handelt es sich um Kernel-Aufrufe und Setup-Vorgänge, die einen erheblichen Overhead verursachen können. Durch das Zwischenspeichern der Zuordnung von Speicheradressen zu ihren libfabric-Handles konnten wir Registrierungen in Scorching-Entry-Regionen wiederverwenden und so den größten Registrierungsaufwand für das eigentliche Coaching eliminieren.
Das Ergebnis warfare eine Kommunikationspipeline, die etwa so aussah: HCCL ruft den OFI-Wrapper auf, der das zwischengespeicherte libfabric-Deal with aufruft, um eine RDMA-Übertragung direkt vom Gaudi-Quellspeicher zum Gaudi-Zielspeicher durchzuführen, ohne dass jemals eine CPU aufgerufen wird. Der OFI-Wrapper wurde eingeführt, um die Codebasis sauber zu halten und direkte Header-Einbindungen zu vermeiden – es handelt sich um eine schlanke Bibliothek, die dynamisch mit HCCL verknüpft ist und die Verwendung von libfabric ermöglicht, ohne dass eine direkte Integration erforderlich ist
Nachdem die Übertragung abgeschlossen ist, berichtet libfabric über eine Abschlusswarteschlange und HCCL setzt die Berechnung mit den kürzlich empfangenen Daten fort.
Die Entwicklungserfahrung
Der Aufbau von Peer Direct erforderte den Vorstoß in Neuland unter engen Zeitplänen. Libfabric warfare im Bereich der KI-Beschleuniger noch nicht Mainstream. Es gab nicht viele öffentliche Unterlagen und die Diskussion warfare dürftig. Der Schwerpunkt lag mehr auf dem Eintauchen in den libfabric-Quellcode und dem auf Experimenten basierenden Reverse Engineering.
Die Kommunikation mit den AWS-Ingenieuren warfare von größter Bedeutung, aber aufgrund der Zeitzone eingeschränkt. Die Zusammenarbeit mit einem Crew zwölf Stunden im Voraus bedeutete, dass Debug-Iterationen innerhalb von 24 Stunden bearbeitet werden konnten. Jedes Drawback erforderte eine sorgfältige Dokumentation und eine ordnungsgemäße Kommunikation, da eine Zusammenarbeit in Echtzeit nicht möglich warfare.
Es stand viel auf dem Spiel, da die gesamte DL1-Bereitstellung auf dieser funktionierenden Funktionalität beruhte. Verzögerungen hätten eine große Produkteinführung vereitelt. Niemand in unserem Crew verfügte über umfassende Hintergrundkenntnisse über die Interna von libfabric, daher lernten wir eine komplexe Codebasis und entwarfen gleichzeitig eine wichtige Integration.
Die Ergebnisse
Als wir Peer Direct tatsächlich einsetzten, waren die Geschwindigkeitsverbesserungen der Aufwand wert. Bei kollektiven Vorgängen mit einer Nachrichtengröße von 32 MB konnten wir einen 1,5- bis 2-fachen Durchsatzanstieg feststellen. Bei größeren Nachrichten warfare die Leistung sogar noch erstaunlicher, mit einem bis zu 1,76-fach höheren Durchsatz bei einer Nachrichtengröße von 256 MB. Durch den CPU-Overhead entstand ein Engpass, der vollständig verschwand.
Am wichtigsten ist, dass sich diese Mikrobenchmark-Verbesserungen direkt in der tatsächlichen Trainingsleistung des Modells niederschlugen. Durch das Coaching des DeepSpeed BERT-Modells von Habana mit 5 Milliarden Parametern auf 128 Gaudi-Geräten konnten wir einen erheblichen Durchsatzgewinn feststellen. Modelle, die aggressivere Speicheroptimierungsmethoden verwenden, wie ZeRO-2, die stärker vom kollektiven Betrieb abhängig sind, profitierten überproportional von Peer Direct.
PeerDirect warfare einer der Hauptfaktoren für die Leistung von Gaudi auf AWS DL1-Instanzen und ermöglichte die mühelose Durchführung groß angelegter verteilter Schulungen am Starttag. Über diese anfängliche Wirkung hinaus legte die Initiative den Grundstein für zukünftige leistungsstarke Kommunikationsfunktionen und bewies, dass Cloud-native KI-Beschleuniger trotz der Einschränkungen der Cloud-Infrastruktur wettbewerbsfähig bleiben können.
Die Erfahrung erinnerte mich an eine wichtige Lektion in der Systemtechnik: Oft resultieren die wichtigsten Leistungsverbesserungen nicht aus der Optimierung des Quick Path, sondern aus der vollständigen Umgehung ungerechtfertigter Umwege. Beim verteilten KI-Coaching ist es wichtig, dass die Daten ohne unnötige Kopien und ohne CPU-Eingriff direkt über die Beschleuniger übertragen werden, was ein funktionierendes System im Vergleich zu einem skalierbaren System auszeichnet.
Wichtige Erkenntnisse? Eine wichtige „Erkenntnis“ aus diesem Projekt ist, dass Annahmen über die Netzwerktopologie zum frühestmöglichen Zeitpunkt im verteilten Trainingsprozess getestet werden sollten. Da viele der Beschleunigerstacks auf der Grundlage einer idealisierten Umgebung erstellt wurden, berücksichtigen sie nicht die zusätzlichen Hops, Übersetzungsebenen und/oder kostenbedingten Faktoren, die in den Cloud-Umgebungen vorhanden sind. Daher sollten Ingenieure, bevor sie sich auf die Optimierung auf Modellebene oder Kernelebene konzentrieren, ein einfaches kollektives Mikrobenchmarking für die gewünschte Topologie durchführen. Wenn die Skalierungseffizienz mit zunehmender Knotenanzahl oder Nachrichtengröße dramatisch abnimmt, liegt der wahrscheinliche Grund am Datenpfad und nicht am Kernel. Durch die frühzeitige Erkennung der Umleitung zwischen Host und Speicher können Ingenieure ihre Bemühungen dort konzentrieren, wo sie die größte Wirkung erzielen.
Eine weitere wichtige Lektion warfare die Notwendigkeit, sowohl die Speicherregistrierung als auch die Datenübertragung als erstklassige Leistungsaspekte zu behandeln. Der Aufwand für die Speicherregistrierung kann den Zeitaufwand für die Kommunikation erheblich übersteigen, wenn für jede Datenübertragung eine neue Registrierung erforderlich ist. Der LRU-Cache für registrierte Erinnerungen warfare eine nicht glamouröse Ergänzung zu HCCL; Es beseitigte jedoch effektiv eine systemische Latenzquelle und machte den RDMA-Pfad für reale Arbeitslasten nutzbar. Bei der Entwicklung verteilter Systeme sollten Ingenieure nicht nur ein Profil der verfügbaren Netzwerkbandbreite erstellen, sondern auch die Lebenszykluskosten, die mit der Zuweisung von Puffern, deren Registrierung und dem Abbau dieser Registrierungen verbunden sind. Kleine Änderungen an diesen Kontrollpfaden können zu großen Steigerungen des Finish-to-Finish-Durchsatzes führen.
Schließlich liefert die in diesem Projekt verwendete Integrationsmethode ein Muster für die Integration. Anstatt HCCL so umzuschreiben, dass libfabric direkt verwendet wird, haben wir eine dünne Abstraktionsschicht erstellt, die die vorhandene Semantik beibehält und gleichzeitig die zugrunde liegende Transportschicht ersetzt. Dies brachte mehrere Vorteile mit sich, darunter die Minimierung des Risikos, die Reduzierung der Code-Abwanderung und die Möglichkeit inkrementeller Exams. Groups, die vor einer ähnlichen Herausforderung stehen (z. B. die Anpassung von Beschleuniger-nativen Kommunikationsbibliotheken an Cloud-native Materials), sollten versuchen, die Transportschicht zu isolieren, die kollektive Semantik beizubehalten und kleine, testbare Schnittstellen zwischen beiden zu schaffen. Dies ermöglicht nicht nur eine schnellere Entwicklung, sondern auch eine einfachere Unterstützung zukünftiger Transport-Backends.
Offenlegung: Ich arbeite als AI Runtime Crew Supervisor bei Intel. Die in diesem Artikel geteilten Perspektiven sind meine eigenen.