Ein CUDA-Quellcode läuft auf Apple-GPUs.
Ein Rechenprogramm, das ursprünglich für Nvidias CUDA entwickelt wurde, läuft fast ohne Änderungen am Kernel-Code direkt auf einem Apple-Gerät mit M3 Pro-Chip.
Dies ist ein Fortschritt, den der X-Nutzer @Abhinav gestern veröffentlicht hat. Noch überraschender ist, dass es sich nicht um eine einfache Demonstration von „Vektoraddition, -subtraktion, -multiplikation und -division“ handelt, sondern bei der echten dreidimensionalen Strömungssimulation eine Geschwindigkeitssteigerung von etwa dem 10-fachen erreicht wurde.
Hinter dieser Sache steht ein besonderer Beteiligter – GPT-5.6 Sol.
Das Ganze fand auf der quelloffenen wissenschaftlichen Rechenplattform OpenFPM statt. Die Forscher haben lange an etwas gearbeitet, was viele für „unmöglich“ hielten: Hochleistungsrechenprogramme, die ursprünglich für CUDA/HIP-GPUs entwickelt wurden, über Plattformgrenzen hinweg auf Apples eigener Metal-GPU-Architektur auszuführen.
Warum ist das so schwierig? In den letzten zehn Jahren war der Bereich des GPU-Computings stark fragmentiert – Nvidia hat CUDA, AMD hat HIP, Apple hat Metal. Diese Ökosysteme sind wie verschiedene Sprachen und nicht miteinander kompatibel. Ein in CUDA geschriebenes Programm erfordert normalerweise eine umfangreiche Neuprogrammierung, um auf anderen Plattformen ausgeführt zu werden.
Aber dieses Mal haben die Entwickler nicht beschlossen, eine eigene Metal-Version neu zu erstellen, sondern eine Umleitung zu bauen: Das Programm wird zuerst von Clang/HIP verarbeitet, durchläuft dann Zwischenschichten wie SPIR-V, Vulkan und MoltenVK, sodass schließlich Apples Metal-GPU es verstehen und effizient ausführen kann.
Wichtiger noch: Sie haben überhaupt keine metalspezifischen Partikel-APIs hinzugefügt. Auf der Anwendungsebene bleibt der ursprüngliche CUDA/HIP-ähnliche Kernel-Aufruf erhalten, was echte Hardware-Transparenz erreicht.
In diesem Prozess hat GPT-5.6 Sol eine Schlüsselrolle gespielt. Es half beim Aufbau des geräteseitigen Speicherlayouts, entdeckte innerhalb von etwa 6 Stunden Kompatibilitätsprobleme in MoltenVK und SPIR-V und entwarf entsprechende Lösungswege.
Projektlink: https://github.com/mosaic-group/openfpm/pull/18
Was diese Arbeit wirklich auf die Probe stellt, ist ein komplexer Testfall – die dreidimensionale SPH-Dammbruch-Simulation. Diese Aufgabe erfordert die gleichzeitige Verarbeitung mehrerer komplexer Module wie Scannen, Sortieren und Umordnen, Aufbau von Zellen und Nachbarlisten, Austausch von Ghost-Partikeln, Reduktionsoperationen und Atomoperationen. Ein Fehler in jedem einzelnen Schritt führt zu Leistungseinbußen oder Abweichungen der physikalischen Ergebnisse.
Aber das Testergebnis übertraf die Erwartungen. Auf einem Apple-Gerät mit M3 Pro-Chip dauerte die Ausführung mit der Metal-GPU etwa 6 Sekunden; die sequenzielle Berechnung mit der CPU dauerte etwa 60 Sekunden. Das heißt, dass dasselbe Programm nur durch den Austausch der Rechenhardware eine Geschwindigkeitssteigerung von etwa dem 10-fachen erzielte, und die GPU-Auslastung lag nahe bei 100 % (was auf eine hohe Umwandlungseffizienz hinweist).
Wichtiger noch: Die Geschwindigkeitssteigerung wurde nicht auf Kosten der Genauigkeit erreicht. Die Entwickler haben die Simulationsergebnisse weiter überprüft und festgestellt, dass die physikalischen Ergebnisse der Apple-GPU-Version und der ursprünglichen Berechnungsversion übereinstimmen, einschließlich der entscheidenden Parameter und der Simulationsbahnen, die sehr nah beieinander liegen. Das bedeutet, dass die Apple-GPU nicht nur das Programm ausführen konnte, sondern auch die wissenschaftliche Rechenaufgabe tatsächlich korrekt erledigt hat.
Die Entwickler weisen ferner darauf hin, dass der Partikelspeicher linear mit der Partikelanzahl N wächst, während der Arbeitsaufwand für Nachbarsuchen ungefähr O(N·k) beträgt (wobei k die Anzahl der Nachbarn bei fester Dichte ist). Die derzeit gezeigte 10-fache Beschleunigung ist das Ergebnis eines Vergleichs von Backends auf einem einzelnen Gerät. In Zukunft kann mit der von Apples Thunderbolt unterstützten RDMA-Technologie ein dynamisches Lastausgleichsverfahren für mehrere Geräte realisiert werden, sodass die Simulation auf mehr Geräten skaliert werden kann.
Natürlich ist dieser Durchbruch noch weit davon entfernt, die gesamte GPU-Branche zu verändern. Eine der größten Einschränkungen von Apples Metal-GPU besteht derzeit in der unzureichenden Unterstützung für hochpräzise Gleitkommaoperationen, während viele Bereiche des professionellen wissenschaftlichen Rechnens auf Doppelgenauigkeitsoperationen angewiesen sind. Daher behalten Nvidias professionelle GPUs in Hochleistungsrechenszenarien wie Wettervorhersage und Luft- und Raumfahrtsimulation weiterhin einen Vorteil.
Trotzdem zweifeln einige die Bedeutung dieser Erkundung an. Ein Nutzer sagte: „Es gibt doch so viele geeignetere Systeme auf dem Markt – wozu soll es gut sein, solche kleinen Simulationen auf einem Mac auszuführen?“ Die Implikation ist, dass die GPU des MacBook, so schnell sie auch sein mag, nicht für wissenschaftliches Rechnen entwickelt wurde, und diese Sache klingt eher wie eine Demonstration von überflüssigen Fähigkeiten.
Die Antwort der Entwickler war sehr offen: „Der größte Nutzen ist, dass es Spaß macht und die Arbeit reibungslos funktioniert.“ Sie erklärten, dass die groß angelegten Simulationen des Teams bereits auf Clustern laufen, und dass die erfolgreiche Ausführung auf der Apple-Architektur genau bestätigt, dass das Design der Geräteabstraktionsschicht funktioniert. Der praktischere Grund liegt in der täglichen Entwicklung: Vor dem Ausführen großer Simulationen muss man immer zuerst mit kleinen Simulationen debuggen, aber das lokale Debuggen mit der CPU ist viel zu langsam; die Simulationsergebnisse sind oft mehrere GB groß, lassen sich nicht über SSH übertragen, und Remotedesktops sind schwerfällig und unpraktisch – es ist viel besser, sie direkt lokal auszuführen. Das Beste daran ist, dass der Code, der auf dem Notebook erfolgreich debuggt wurde, unverändert auf den GPU-Cluster übertragen werden kann, wo er automatisch skaliert.
Diese Erkundung beweist zudem: Derselbe Satz von Algorithmen im CUDA/HIP-Stil kann relativ transparent auf unterschiedlichen Hardware-Backends wie Apple Silicon ausgeführt werden. In Zukunft sind Softwareentwickler möglicherweise nicht mehr an ein einziges GPU-Ökosystem gebunden.
Darüber hinaus zeigt dies auch, dass KI (GPT-5.6 Sol) von der „Unterstützung beim Schreiben von Code“ zu einer neuen Phase übergeht, in der sie an der Gestaltung, Optimierung und plattformübergreifenden technischen Fehlerbehebung von zugrundeliegenden Systemen teilnimmt.
Dass Apples GPU nun die CUDA-Lücke überwunden hat, ist möglicherweise erst der Anfang.
Referenzlink: https://x.com/Abhinavsns/status/2079774018748694696