Frameworks für das Accelerated Computing im Vergleich CUDA, HIP/ROCm oder Unified DNA und oneAPI auf dem Schachbrett der KI-Vorherrschaft

Geht das? Massiv parallele KI/ML- und HPC-Arbeitslasten auf heterogenen Beschleunigern ausführen? Hardware-agnostische Programmierschnittstellen nutzen? Offene Standards für GPUs, Nvidias größten Albtraum, verwirklichen? Es könnte schnell gehen.

Im Kampf um die Gnade der Software-Entwickler:innen und lukrative Marktanteile möchte AMD in einem Katzensprung zu Nvidia aufschließen. Intel war es schon lange zu bunt geworden; dank offener Standards und APIs wollte man, zumindest mit Pat Gelsinger an der Spitze, mit einer einheitlichen Codebasis nach Möglichkeit auf allen Chip-Architekturen rechnen. Ist also Schluss mit der Geheimniskrämerei?

AMD Unified DNA

AMD führt seine GPU-Architekturen CDNA (kurz für Compute DNA, die Architektur der „Instinct“-Reihe von Rechenzentrums-GPUs) und RDNA („Radeon DNA“ für GPUs der Verbraucherklasse) zu einer einheitlichen Mikro-Architektur zusammen, verkündete laut Jack Huynh, Senior Vice President und General Manager der Computing and Graphics Business Group von AMD, zum hundertjährigen Geburtstag der IFA Anfang September 2024 in Berlin.

Die neue Architektur trägt die Bezeichnung „UDNA“ – kurz für Unified DNA – und soll AMDs Position im Wettbewerb gegen „Nvidia CUDA“ stärken. Denn gerade beim Software-Stack zeigt das AMD-Ökosystem die größten Defizite.

Seit der Abkehr von der „GCN-Mikro“-Architektur im Jahr 2019 fährt AMD mit RDNA und CDNA zweigleisig. Der Ansatz habe zwar gewisse Optimierungen ermöglicht, sei aber unterm Strich hinderlich gewesen. Er soll optimierte Designs für unterschiedliche Anwendungsbereiche ermöglicht haben, führte jedoch zu einer Fragmentierung, die für die Entwicklergemeinde unnötig viele Herausforderungen mit sich brachte (Siehe hierzu den Bericht: „Einer Ingenieurin ist nix zu schwör! Was macht AMD richtig?“).

„Wir haben auf der RDNA-Seite Fehler gemacht“, gestand Huynh ganz offen. „Wann immer wir die Speicherhierarchie oder Subsysteme geändert haben, mussten wir die Optimierungen von Grund auf neu durchführen“, erklärte er weiter. Das möchte AMD in Zukunft vermeiden.

Daher denke man bei AMD jetzt nicht nur an RDNA 5, RDNA 6 oder RDNA 7, sondern an UDNA 6 und UDNA 7, so Huynh: „Wir planen bereits für die nächsten drei Generationen“, um sicherzustellen, dass die Speicherhierarchie stabil und die Optimierungen erhalten blieben. „Viele Entwickler/innen wünschen sich, wir hätten das früher getan.“

In Unified DNA, wie auch schon zuvor, setzt AMD auf Offenheit. Die Herausforderung bestehe jetzt darin, die vollständige Vorwärts- und Rückwärtskompatibilität von UDNA sicherzustellen und ein ähnliches Maß an Einheitlichkeit und Entwicklerfreundlichkeit zu schaffen, wie es Nvidia mit CUDA vorgemacht hat.

Das GPU-Programmiermodell CUDA des Branchenprimus sucht in Sachen Leistung seines Gleichen. Das Unternehmen kann beeindruckende vier Millionen CUDA-Entwickler:innen vorweisen. Doch im Zeitalter heterogener Rechenarchitekturen ist der proprietäre Ansatz eine Achillesferse des Ökosystems.

Der Nvidia-KI-Stack

Mit CUDA (Compute Unified Device Architecture) hat Nvidia eine proprietäre Rechenplattform für massive Parallelisierung geschaffen, die den Vorstoß des GPU-Pioniers ins Rechenzentrum ermöglicht hatte und seine technologische Führerschaft zementierte ( Siehe hierzu: „UALink, CXL & Co. - eine Revolte gegen NVLink von Nvidia“. Das Rechen-Framework umfasst eine Reihe von Bibliotheken und Erweiterungen für die Programmiersprache C/C++ zur Ausführung auf Nvidia-GPUs. Es hat die Aufgabe, die Beschleuniger für komplexe Workloads wie KI, Deep Learning, Simulationen und wissenschaftliches Rechnen nutzbar zu machen.

CUDA durchdringt alle Ebenen des Technologie-Stacks von Nvidia, von der Hardwareschicht über spezialisierte Bibliotheken („cuDNN“, „NCCL“, „CUDA Math Libraries“ ....), Entwicklungs-Frameworks bis hin zu den Anwendungen und Workloads. CUDA übernimmt die Datenvorverarbeitung, parallelisiert das Modelltraining und optimiert die Inferenz – aber nur auf den Nvidia-eigenen GPUs.

CUDA spielt eine tragende Rolle bei der Leistung, Skalierbarkeit und Flexibilität einer 'AI Factory' im Zusammenspiel mit Frameworks wie „Tensorflow“, „Pytorch“und „Mxnet“, die direkt auf CUDA-kompatiblen GPUs laufen. CUDA ist die proprietäre Geheimsauce von Nvidia – und ein Dorn im Auge seiner Mitbewerber.

Ein zentrales Merkmal der „Blackwell“-Architektur ist die Unterstützung der CUDA Compute Capability 10.0. Diese brachte mit sich eine Reihe von beachtlichen Verbesserungen. In der Blackwell-Architektur konnte der Hersteller die Anzahl von CUDA-Kernen pro Streaming-Multiprozessor (SM) erhöhen und eine höhere Parallelität realisieren, was zu einer signifikanten Leistungssteigerung führte.

SMs umfassen neben CUDA-Kernen für massive Parallelität auch Tensor-Kerne zur Beschleunigung von Matrixoperationen, Transformer-Engines zur optimierten Berechnung von Transformer-Modellen in reduzierter oder gemischter Genauigkeit und andere spezialisierte Recheneinheiten. AMD stehen viele dieser Innovationen ja noch bevor.

Die fünfte Generation der (erweiterten) Tensor Cores in Blackwell führt mit FP4 und FP6 neue Datentypen ein. Diese niedrigpräzisen Datentypen erfordern weniger Rechenleistung und Energie, eignen sich jedoch hervorragend für spezifische KI-Workloads wie Inferenz, ohne signifikante Einbußen bei der Genauigkeit zu verursachen.

Die Transformer-Engines in Blackwell arbeiten eng mit den Tensor-Kernen zusammen, um gemischte Präzision (Mixed Precision) zu ermöglichen. Diese Berechnungen werden vollständig innerhalb der SMs ausgeführt, ohne dass Daten zwischen verschiedenen GPU-Komponenten verschoben werden müssen. Die CUDA-Kerne innerhalb der SMs führen unterstützende Berechnungen aus, die nicht direkt auf Tensor-Kernen ausgeführt werden können, zum Beispiel kleinere Punktoperationen oder logische Operationen.

Flexibilität in der Parallelverarbeitung und den Speichern

CUDA beherrscht in Blackwell eine verbesserte Steuerung der Thread-Zuweisung für eine höhere Flexibilität in der Parallelverarbeitung. Erweiterte Instruktionssätze erlauben optimierte Operationen für Matrixberechnungen, Sparse-Linear-Algebra und KI-Inferenz in Echtzeit. Die Transformer-Engines optimieren die Nutzung der CUDA- und Tensor-Kerne innerhalb eines SMs, indem sie Workloads für Transformer-Modelle auf Threads zur Maximierung der Parallelität verteilen.

CUDA optimiert die Datenübertragung zwischen globalem Speicher, gemeinsamen Speicher (Shared Memory) und den CUDA-Kernen sowie das Caching in den erweiterten L1- und L2-Caches, um die Abhängigkeit vom globalen Speicher (und damit von der Kompression) zu reduzieren. Und die Technik verwaltet die Speicherzugriffe auf HBM3e. Das CUDA-Programmiermodell in Blackwell erlaubt eine erweiterte Nutzung von gemeinsam genutztem Arbeitsspeicher durch die CUDA-Kerne eines Streaming-Multiprozessors (SM). Transformer Engines nutzen die Shared-Memory eines SMs, um Zwischenergebnisse zwischen CUDA- und Tensor-Kernen auszutauschen.

Die Speicherkompression in Nvidia-GPUs ist hardwareseitig implementiert. CUDA selbst bietet Entwickler:innen lediglich die Möglichkeit, auf die zugrunde liegenden Hardware-Funktionen zuzugreifen.

CUDA-basierte Frameworks wie Tensorflow und Pytorch genauso wie vortrainierte Modelle und Pipelines von Hugging Face und Co. können Blackwell-spezifische Verbesserungen direkt nutzen. Mit CUDA-Tools wie „Nsight“ können Entwickler:innen die Speicherzugriffe und die Speicherkompression analysieren, um CUDA auf niedriger Ebene noch zusätzliche Leistung zu entlocken.

Die Connections

Blackwell setzt auf eine verbesserte Version von „NVLink“ für die Kommunikation zwischen den GPUs. NVLink wird hardwareseitig durch Nvidia-Komponenten wie „NVSwitch“ gesteuert. CUDA nutzt die NVLink-Verbindungen, um die Datenübertragung zwischen GPUs zu koordinieren, ist jedoch nicht direkt für die Steuerung der NVLink-Hardware verantwortlich.

Die verbesserte Implementierung von CUDA-Streams in Blackwell ermöglicht eine fein abgestimmte Synchronisation und Parallelisierung von Aufgaben über mehrere GPUs hinweg. Die Echtzeit-Inferenz in CUDA ist mit Blick auf Edge-Anwendungen konzipiert.

Jeder CUDA-Kern lässt sich in seiner Taktrate dynamisch an die betreffende Arbeitslast anpassen. Dies reduziert den Energieverbrauch in Leerlaufphasen oder bei weniger intensiven Berechnungen. Nicht aktive Bereiche eines Streaming-Multiprozessors (SM) lassen sich zeitweise abschalten, um Energie zu sparen (Stichwort: Fine-Grain Power Gating). Einzelne SMs können unabhängig voneinander in den Stromsparmodus wechseln.

Der Energiebedarf

CUDA nutzt Sensoren in der GPU, um Echtzeitdaten zum Energieverbrauch zu erfassen. Diese Daten fließen in das Power-Management ein und ermöglichen es, Lastspitzen auszugleichen. Trotzdem berichten einige Anwenderorganisationen von Problemen mit der Überhitzung von Blackwell-Hardware.

„Dem Ingeniör ist nix zu schwör!“

Das macht Nvidia richtig (und falsch)

Blackwell-Hardware kann CUDA-Anwendungen während der Ausführung vor unerlaubten Zugriffen isolieren, ohne dass Änderungen am Code erforderlich sind. Die Blackwell-Architektur implementiert Confidential Computing des GPU-Giganten in Hardware, um sensible Daten und KI-Modelle vor unbefugtem Zugriff zu schützen. Dies macht Blackwell zur ersten GPU in der Branche, die Trusted Execution Environment Input/Output (TEE-I/O)-Funktionen bereitstellen kann (siehe auch den Bericht: „Confidential Computing mit Enclaive.io; Vertrauenswürdige Datenverarbeitung in der hybriden Multicloud“).

AMD HIP/ROCm

Doch nun zur Konkurrenz: AMD hat zwar in den letzten Jahren erhebliche Fortschritte gemacht. Dennoch besteht ein gewisser Nachholbedarf zum Marktführer – vor allem im Hinblick auf den Software-Stack.

Das AMD-Gegenstück zu CUDA nennt sich ROCm (Radeon Open Compute). Es ist eine offene Softwareplattform für die Ausführung von AI-Workloads auf AMD-GPUs mit geeigneten Bibliotheken und einer umfassenden Toolchain für Hochleistungsrechnen.

Ein wesentlicher Bestandteil von ROCm ist eine offene Schnittstelle namens HIP (kurz für Heterogeneous-compute Interface for Portability). Der pfiffige Name soll die Hauptaufgabe dieser Technologie zum Ausdruck bringen: die Ausführung von CUDA-Code auf AMD-GPUs (siehe dazu auch: „Wie im Krimi: Die Taktiken im GPU-Lager; Unlauterer Wettbewerb? Nvidia unter Beobachtung des U.S.-Justizministeriums“). HIP stellt hierzu eine Übersetzungsschicht bereit.

Im Rahmen des ROCm-Ökosystems nutzt AMD unter anderem „OpenCL“ als eine plattformübergreifende, offene Alternative zu CUDA. OpenCL (Open Computing Language) ermöglicht es Entwickler:innen, Code zu schreiben, der sich auf verschiedenen Hardwareplattformen – , einschließlich CPUs, GPUs und anderen Prozessoren – ausführen lässt. Dies macht OpenCL zu einer flexiblen Option für Hochleistungsrechnen und parallele Verarbeitung.

AMD-Alternativen

Nach der Übernahme von Xilinx im Jahr 2022 hatte AMD dessen damaligen CEO, Victor Peng, beauftragt, ein einheitliches ROCm-Team aufzubauen, um das Projekt unter eine straffere Führung zu stellen. Trotz gewisser Fortschritte bleibt der Handlungsbedarf bisher aber immer noch recht offensichtlich.

Parallel zur Weiterentwicklung von ROCm sieht sich AMD auch mit der wachsenden Bedeutung der Unified Acceleration Foundation konfrontiert. Diese Initiative hat sich offenen Standards für Beschleuniger verschrieben und hat bereits die Unterstützung namhafter Player wie Qualcomm, Samsung, ARM und Intel gewonnen. Projekte wie „ZLUDA“ und „Intel oneAPI“ zielen darauf ab, CUDA-Code auf Beschleunigern anderer Hersteller nutzbar zu machen.

oneAPI für anbieteragnostische Parallelität

Intel hat mit oneAPI eine Programmierplattform für HPC (High Performance Computing) entwickelt, die auf Offenheit und Interoperabilität setzt. Das Ziel besteht darin, eine einheitliche plattformübergreifende Umgebung zu schaffen, die verschiedene Hardwaretypen wie CPUs, GPUs und FPGAs anbieteragnostisch unterstützt. oneAPI soll die Wiederverwendbarkeit von Code ermöglichen und den Aufwand der Optimierung für verschiedene Architekturen senken.

oneAPI ermöglicht die Portierung von Anwendungen über verschiedene Hardware-Architekturen hinweg – ein Ansatz, der insbesondere in heterogenen Rechenzentren an Relevanz zunimmt. Das Herzstück des „oneAPI Base Toolkits“ bildet „DPC++“ (Data Parallel C++), eine Implementierung der offenen SYCL-Sprache, die auf den industriellen Standard OpenCL aufbaut.

SYCL ist eine lizenzfreie, plattformübergreifende Abstraktionsschicht und Programmiersprache, die ISO C++ erweitert. SYCL-Code kann parallel – anbieteragnostisch – auf verschiedenen Hardwareplattformen laufen und lässt sich dennoch an spezifische Beschleuniger anpassen.

Es geht auch offen

Entwickler/innen schreiben ihren SYCL-Code unter Verwendung standardisierter Konzepte wie Speicherzuweisungen, Warteschlangenübermittlungen und Kerneln für leistungskritische Teile des Codes. Eine SYCL-Implementierung wie DPC++ fügt alle Teile zu einer Anwendung zusammen.

Diese lässt sich dann auf mehreren Systemen mit einem einzigen Compiler-Aufruf ausführen. All dies erfolgt nur mit standardmäßigem C++-Code und ohne proprietäre Syntax. SYCL basiert auf einem offenen Standard, der kollaborativ von branchenübergreifenden Arbeitsgruppen gepflegt wird.

Intel zählt neben Codeplay und ARM zu den Hauptakteuren hinter der Entwicklung von SYCL und dem DPC++-Compiler. Die AMD-Tochter Xilinx unterstützt SYCL für die eigenen FPGAs. AMD selbst unterstützt SYCL mit dem HIP-Backend.

Intels Tochter Codeplay hat eine Reihe von Plug-Ins veröffentlicht, die die Ausführung von SYCL-Code mit oneAPI auf GPUs von AMD und NVIDIA ermöglichen. Codeplay ist als Anbieter von Tools für heterogenes Computing bekannt, bei dem verschiedene Prozessortypen wie CPUs, GPUs und FPGAs zusammenarbeiten. Mit der Übernahme von Codeplay in 2022 verlor Intel das Interesse an der Unterstützung von ZLUDA; der Hauptentwickler wechselte daraufhin zu AMD bis ihm dieses Unternehmen sein Backing entzog (wie das Ganze hinter den Kulissen ablief und was daraus wurde, beleuchtet der Bericht „Mafia-Taktiken im GPU-Lager“).

Das Codeplay-Plugin für Nvidia-GPUs nutzt die CUDA-Architektur, um die Ausführung von SYCL-Code auf Nvidia-GPUs zu ermöglichen. Die Edition des Plug-Ins für AMD-GPUs fügt dem DPC++-Compiler ein HIP-Backend hinzu, um die Ausführung von SYCL-Code auf AMD-GPUs zu ermöglichen. Die Leistung von SYCL-Code auf Nvidia- und AMD-GPUs gleicht beinahe nativer Leistung.

Im Juli 2024 hat Codeplay seine oneAPI-Plugins für AMD- und NVIDIA-GPUs mit zahlreichen Optimierungen angereichert (rund einen Monat später hat AMD den Hauptentwickler des quelloffenen ZLUDA die Genehmigung für die Veröffentlichung des Code entzogen.

Wie im Krimi: Die Taktiken im GPU-Lager

Unlauterer Wettbewerb? Nvidia unter Beobachtung des U.S.-Justizministeriums

Eine bemerkenswerte Neuerung ist die experimentelle Version von SYCL Graph für AMD-GPUs. Damit können Entwickler ihre Offload-Kernel in Graph-Befehle bündeln, was die CPU-Last reduziert und die Leistung steigert. Die Edition des Plug-Ins für Nvidia-GPUs brachte unter anderem die Unterstützung von „C++-Atomics“ mit sequenzieller Konsistenz, die Entwicklern eine feinere Kontrolle über die Ausführung ihres Codes ermöglicht.

Das Update brachte außerdem kommerzielle Unterstützung für die Edition des Plug-Ins für AMD-GPUs. Kommerzielle Unterstützung bietet Unternehmen die Sicherheit, dass sie bei Problemen oder Fragen auf professionelle Hilfe zurückgreifen können, was besonders in produktiven Umgebungen eine große Rolle spielt.

Codeplay ist bekannt für seine Expertise in der Entwicklung von Compilern, Laufzeitumgebungen, Debuggern und anderen spezialisierten Tools für beschleunigtes Computing. Mit oneAPI zielt Intel auf Anwenderorganisationen ab, die mehr Flexibilität und Zukunftssicherheit suchen.

(ID:50325786)