Deutliche Verbesserungen erzielt

In den letzten zwei Jahrzehnten wurden Rechenzentren immer weiter optimiert. Standardisierung und Automatisierung sorgen für mehr Effizienz in Bezug auf die reine Datenverarbeitung bzw. Rechenleistung und auf den Stromverbrauch. Technologien wie Virtualisierung und Containerisierung ermöglichen Nutzern und Entwicklern eine effizientere Ressourcenauslastung bis hin zu einer Self-Service-Bereitstellung.

Die universellen x86-Architekturen, wie sie in modernen Rechenzentren zum Einsatz kommen, sind jedoch für die Ausführung von KI-Workloads nicht geeignet. Die meisten Unternehmen adressieren dieses Problem, indem sie GPUs (Grafikprozessoren) für KI-Workloads zur Verfügung stellen. Dies hat in den letzten zehn Jahren die Weiterentwicklung des Maschinellen Lernens (ML) enorm vorangetrieben.

Für Unternehmen, die KI-Workloads ausführen möchten, stellt dies jedoch auch ein Problem dar. In der Regel bedeutete der Ansatz „CPU-Host plus Beschleuniger“ den Kauf eines einzigen Systems, das GPUs und x86-basierte Host-Rechenleistung umfasst. Die Infrastrukturteams in den Unternehmen sind dabei gefordert. Obwohl solche Systeme theoretisch Plug-and-Play-fähig sind, können sie viel Platz im Rack beanspruchen und andere Anforderungen an Stromverbrauch und Kühlung als reguläre Server stellen. Sie können auch unflexibel sein, da das Verhältnis von Rechenleistung zu GPU-Beschleuniger fix ist, was die Flexibilität bei der Handhabung mehrerer KI-Workloads mit unterschiedlichen Host-Rechenanforderungen einschränkt.

Da KI-Anwender mit immer größeren Modellen und Datensätzen arbeiten – wir sind heute im Bereich von Billionen und mehr Parametern – wird der Kauf eines weiteren neuen Systems zu einer Frage der Skalierung der KI-Leistung, um mit der Entwicklung Schritt zu halten. Dann folgt ein weiteres System und wiederum ein weiteres System usw. Dies trägt jedoch wenig dazu bei, das Ungleichgewicht zwischen Host-Computing und KI-Beschleunigung zu beheben.

Was geschieht im Rest eines solchen hochgradig optimierten Rechenzentrums? Nun, man kann es nicht wirklich nutzen, wenn alle KI-Workloads in einem Silo stattfinden. Dies macht erfahrene CIOs, CTOs und Infrastrukturmanager verständlicherweise nervös.

KI im Einsatz

Während KI neben traditionellen Rechen-, Netzwerk- und Speichersystemen zur vierten Säule des Rechenzentrums wird, sollte dies nicht in Form von Black-Box-Systemen erfolgen. KI-Leistung muss vielmehr von der Host-Rechenleistung getrennt und in eine Form gepackt werden, die sich problemlos in moderne Rechenzentren einfügt und diese auch voll ausnutzt.

Die IPU-POD Lösungen von Graphcore sind eine Familie von Systemkonfigurationen, die auf der IPU-M2000 basieren, einem 1HE-Blade, das 1 PetaFLOP KI-Rechenleistung bereitstellt. Jede Einheit enthält vier GC200 Mk2 Colossus Intelligence Processing Units (IPU) mit jeweils 1.472 unabhängigen Cores oder Tiles, von denen jeder sechs gleichzeitige Threads ausführen kann. Sie teilen sich 900 MB prozessorinternen Speicher auf dem gleichen Chip.

Der Ausgangspunkt für einen CIO oder CTO, der sein Rechenzentrum mit KI-Rechenressourcen ausstatten möchte, die besser zum Betrieb seines Rechenzentrums passen, sind der IPU-POD16 und IPU-POD64 des Anbieters. Der IPU-POD64 besteht aus 16 IPU-M2000, Daten- und Management-Switches und einer Auswahl von einem oder vier Hostservern, die disaggregiert sind. Er liefert 16 PetaFLOPS FP16.16-KI-Rechenleistung und belegt je nach Serverzuordnung rund 20 RU Rackfläche, verteilt auf ein oder mehrere Racks.

Der IPU-POD16 ist eine Einstiegslösung für jene, die die Technik erforschen und Neuerungen damit umsetzen wollen. Der IPU-POD16 ist in zwei Varianten erhältlich: Direct Attach mit vorkonfiguriertem Plug-and-Play-System, und als Alternative, die Switches verwendet. Beide Varianten arbeiten mit einem einzigen Hostserver und liefern 4 PetaFLOPS FP16.16-KI-Rechenleistung.

Skalierbarkeit findet sich in jeder IPU-M2000 mit dem vom Anbieter selbst entwickelten Gateway-Chip. Dieser unterstützt die Kommunikation mit 100 GBit/s in jeder Richtung zu benachbarten IPU-POD-Racks. Als Teil der IPU-Fabric-Interconnect können diese Verbindungen direkt oder über Switches erfolgen, um zusätzliche Flexibilität und Ausfallsicherheit zu gewährleisten. Die Basis für die Skalierung ist die IPU-Fabric mit einer Gesamtbandbreite von 2,8 TBit/s. 16 M2000 werden innerhalb eines Racks zu einem IPU-POD64 hochskaliert. Für die Kommunikation zwischen den Racks kann die IPU-Fabric in einer geswitchten 3D-Torus-Topologie konfiguriert werden, um Tausende von IPUs und bis zu 1024 IPU-M2000 zu unterstützen. Dadurch entsteht ein massiv paralleles System, das 16 ExaFLOPS KI-Rechenleistung bereitstellt.

Dieser disaggregierte Ansatz kommt dem Wunsch von Hyperscalern und Unternehmen entgegen, die Anzahl der zu unterstützenden Server-SKUs zu minimieren. Die Anbietersysteme sind effektiv an das Netzwerk angeschlossen. Kunden installieren einfach die Poplar-Software – die branchenübliche ML-Frameworks wie TensorFlow oder PyTorch unterstützt – auf ihren bevorzugten Servern, um Host-Computing für das IPU-basierte System bereitzustellen. Entscheidend ist, dass die Serverkapazität je nach KI-Workload schrittweise hoch- oder heruntergefahren werden kann. Während NLP-Workloads ein geringeres Verhältnis von Host-Rechenleistung und Schnittstellen erfordern, belasten Bildverarbeitungs-Workloads den Host stärker.

Die Disaggregation hat auch Vorteile in Bezug auf die Ausfallsicherheit. Im Falle eines Ausfalls (Server fallen nun einmal auch aus) lassen sich die Vorteile von Standard-Failover-Protokollen nutzen, die über einen Netzwerk-Stack bereitgestellt werden. Wenn also ein Server oder eine virtuelle Maschine ausfällt, lässt sich dieser/diese auf einen anderen Standby-Server oder eine virtuelle Standby-Maschine migrieren.

Die IPU-Fabric ist so konzipiert, dass sie kompilierte Kommunikation und massive Skalierung unterstützt. Wenn KI-Anwender ihren Code mit Poplar kompilieren, wird ihr Modell im IPU-POD-System als zusammenhängende IPU-Ressource abgebildet – so, als wäre es eine riesige IPU, bis hin zu den einzelnen Cores der Prozessoren. Damit wird das optimale Kommunikationsmuster zur Unterstützung des jeweiligen ML-Modells geschaffen, unabhängig davon, ob es sich um eine IPU oder eine Skalierung auf 1000 handelt. Das Ergebnis ist eine deterministische und jitterfreie Kommunikation, auch wenn das System massiv skaliert wird.

Aber der KI-Anwender kümmert sich nicht so sehr um Hardware oder Systeme – er will im Grunde eine sehr skalierbare Plattform, auf der er seinen Code ausführen kann. Wie schnell dieser Code ausgeführt wird, zeigen die neuesten Benchmarks des Anbieters: die Trainingszeit für BERT-Large mit einem IPU-POD-System im Vergleich zu einem DGX-A100-GPU-basierten System wird mehr als halbiert, mit einem mehr als dreimal höheren Durchsatz für Inferenz-Berechnungen bei niedrigster Latenz. Bei einer Markov-Chain-Monte-Carlo-Workload führte die IPU-M2000 Training-Berechnungen in weniger als drei Stunden durch, verglichen mit 48 Stunden für die A100-GPU.

Bei den neuesten KI-Modellen sind die Verbesserungen noch deutlicher. Die IPU-M2000 steigerte den Lerndurchsatz bei EfficientNet-B4 um das 10-fache und bei einer IPU-optimierten Konfiguration sogar um das 18-fache. Im Vergleich zu einem GPU-System lieferte die IPU-M2000 eine 60-fache Steigerung des Durchsatzes und eine 16-fach geringere Latenz.

IPU-POD-Systeme werden umfassend von einer Management-Software-Suite unterstützt, die Systemverwaltung und Beobachtbarkeit ermöglicht. Sie bestehen aus branchenüblichen Open-Source-Tools wie OpenBMC, RedFish DTMF, Prometheus und Grafana und werden mit gut dokumentierten, offenen APIs für die Integration von Managementsystemen bereitgestellt. Angenommen, ein Netzteil fällt bald aus, dann möchte man frühzeitig darüber informiert werden. So kann man dann einen Support-Mitarbeiter losschicken, um es zu ersetzen. Gleiches gilt für ein DIMM, das bald ausfällt.

Infrastruktur-Teams sind sehr darauf bedacht, dass sie das Beste aus der Investition in ihre KI-Hardware herausholen, d.h. dass so viele Workloads, Jobs und Teams wie möglich unterstützt werden.

KI für alle?

Obwohl die IPU-POD-Architektur auf Zehntausende von IPUs skaliert werden kann – was für KI-Anwender äußerst verlockend klingt, um darauf ihre KI-Modelle ausführen können – wird es in der Realität nur wenige Fälle geben, in denen ein einzelner Anwender die gesamte KI-Rechenkapazität in Anspruch nimmt. In der Regel gibt es mehrere Nutzer, die das System verwenden. Daher ist ein robustes Ressourcenmanagement erforderlich. Der Software-Stack des Anbieters ermöglicht es, „virtuelle IPUs“ zu erstellen und ermöglicht diesen, den POD in mehrere virtuelle PODs aufzuteilen, die vollständig isoliert sind. Eine IPU oder ein System in einem virtuellen Pod kann dann nicht mit einer anderen IPU in einem benachbarten Pod kommunizieren.

Hinzu kommt die Unterstützung seitens branchenüblicher Orchestrierungstools wie SLURM und Kubernetes, sodass auf dem Host laufende virtuelle Maschinen oder Container mit VPODs im IPU-System verknüpft werden können. Unabhängig davon, ob es sich um ein Hyperscale-System oder ein einzelnes Rack handelt: Während sich der KI-Anwender darauf konzentriert, so viel Leistung wie möglich für die Ausführung eines Modells zu erhalten, möchte sein Vorgesetzter oder sein Unternehmen die Gewissheit haben, dass diese Ressource einzig und allein dem Unternehmen oder der Organisation gehört.

Dies kommt der Erwartung entgegen, dass viele Unternehmen ihre ersten Erfahrungen mit IPUs über Hyperscaler oder den Bare-Metal-Cloud-Dienst Graphcloud des Anbieters gemacht haben. Viele werden letztlich eigene KI-Hardware On-Premise einsetzen wollen – gerade aus Gründen des Datenschutzes, der Geheimhaltung und der Latenz. Dabei werden traditionelle Gleichungen zu den Gesamtbetriebskosten durchgespielt. Eine Frage dazu lautet: Wie viel Strom wird tatsächlich verbraucht, um z.B. eine BERT-Berechnung auszuführen – für ein Jahr? Betrachtet man sowohl die Box- als auch die Systemebene, ist die Lösung sehr attraktiv.

Aus Investitionssicht ist die Gleichung noch einfacher. Die einzige neue Komponente, die wirklich hinzugefügt werden muss, ist das IPU-M2000-basierte IPU-POD-System. Der Rest – Network und Storage – ist ja schon vorhanden. Und das ist wohl das Unproblematischste, was man unternehmen kann, um sein Rechenzentrum für KI-Workloads fit zu machen.

Bildquelle: Graphcore/tpapkalla