🤖 machine learning

SOLAR: AI-Powered Speed-of-Light Performance Analysis

SOLAR ist ein automatisiertes Framework, das PyTorch- und JAX-Quellcode mittels einer hybriden generativ-deterministischen Pipeline in validierte Speed-of-Light-Leistungsobergrenzen übersetzt und es Entwicklern ermöglicht, theoretische Ausführungslimits zu quantifizieren, Optimierungspotenziale zu identifizieren und die Hardware-Bereitstellung über diverse Deep-Learning-Workloads hinweg zu steuern.

Ursprüngliche Autoren: Qijing Huang, Sana Damani, Zhifan Ye, Athinagoras Skiadopoulos, Siva Kumar Sastry Hari, Jason Clemons, Sahil Modi, Jingquan Wang, Aditya Kane, Edward C Lin, Humphrey Shi, Christos Kozyrakis

Veröffentlicht 2026-06-26

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Qijing Huang, Sana Damani, Zhifan Ye, Athinagoras Skiadopoulos, Siva Kumar Sastry Hari, Jason Clemons, Sahil Modi, Jingquan Wang, Aditya Kane, Edward C Lin, Humphrey Shi, Christos Kozyrakis

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Rennfahrer. Sie haben ein brandneues, hochleistungsfähiges Auto (Ihr KI-Modell) und eine spezifische Rennstrecke (Ihren Computerchip). Sie möchten wissen: Was ist die absolut schnellste Zeit, die dieses Auto für eine Runde auf dieser Strecke benötigt?

Im Moment können die meisten Tools nur sagen, wie schnell das Auto in einem Testlauf tatsächlich war, oder sie können die Pferdestärken des Motors zählen (wie viele mathematische Probleme es löst). Aber sie können nicht die theoretische Höchstgeschwindigkeit dieses spezifischen Autos auf dieser spezifischen Strecke ermitteln. Fährt Ihr Auto mit 50 % seines Potenzials? 90 %? Oder steckt es im Stau aufgrund eines schlechten Straßendesigns fest?

Dieses Paper stellt SOLAR vor, ein neues Tool, das diese theoretische „Speed of Light“ (SOL)-Grenze automatisch berechnet.

So funktioniert SOLAR, unterteilt in einfache Analogien:

1. Das Problem: Raten vs. Wissen

Derzeit müssen Sie, wenn Sie die Geschwindigkeitsbegrenzung eines komplexen KI-Modells wissen wollen, dies manuell tun. Es ist, als würde man versuchen, die schnellstmögliche Rundenzeit zu berechnen, indem man jede Kurve und jede Gerade manuell mit einem Lineal misst. Das ist langsam, fehleranfällig und oft falsch.

Alte Tools zählen entweder nur die Mathematik (und ignorieren Staus) oder messen, wie schnell ein bestimmter Fahrer gerade fährt (und ignorieren das Potenzial des Autos).
Reines KI-Raten versucht, die Zeit vorherzusagen, vertut sich aber oft bei der Mathematik, insbesondere bei komplexen Routen.

2. Die Lösung: Der „Übersetzer“ und der „Ingenieur“

SOLAR löst dies mit einem cleveren zweiteiligen Team: einem Übersetzer und einem Ingenieur.

Schritt 1: Der Übersetzer (Der KI-Agent)
Stellen Sie sich vor, Sie haben ein unordentliches, handgeschriebenes Rezept (Ihren KI-Code in PyTorch oder JAX). Ein menschlicher Koch (das KI Large Language Model) liest dieses unordentliche Rezept und schreibt es in einen strengen, standardisierten Bauplan namens Affine Loop IR um.
- Die Sicherheitsprüfung: Bevor der Bauplan akzeptiert wird, führt SOLAR sowohl das ursprüngliche unordentliche Rezept als sie den neuen Bauplan aus, um sicherzustellen, dass beide exakt dasselbe Gericht produzieren. Wenn die Gerichte anders schmecken, versucht die KI es erneut. Dies stellt sicher, dass die Übersetzung zu 100 % genau ist.
Schritt 2: Der Ingenieur (Der deterministische Rechner)
Sobald der Bauplan verifiziert ist, übernimmt ein strenger, regelbefolgender Ingenieur das Kommando. Dieser Ingenieur betrachtet den Bauplan und fragt: „Wenn wir dies exakt so bauen, wie gezeichnet, was ist die absolute minimale Zeit, die es dauert?“
- Er rät nicht. Er berechnet die Mathematik bas * Er erstellt eine Abhängigkeitskarte (einen „Einsum Graph“), die genau zeigt, wie die Daten von einem Schritt zum nächsten fließen.

3. Die „Speed of Light“-Berechnung

Sobald der Ingenieur die Karte hat, berechnet er das Tempolimit unter Verwendung zweier Hauptfaktoren:

Rechenleistung (Compute): Wie schnell der Motor Mathematik betreiben kann.
Speicher (Verkehr): Wie schnell Daten in den Motor hinein- und aus ihm herausbewegt werden können.

SOLAR betrachtet die Karte und sagt:

„Naïve Geschwindigkeit“: Wenn Sie an jeder einzelnen Kreuzung anhalten, um Ihre Lebensmittel einzuladen (Daten), wie lange dauert es?
„Fused Geschwindigkeit“: Wenn Sie zwei Stopps zu einem kombinieren (Operationen fusionieren), sparen Sie Zeit.
„Realistische Geschwindigkeit“: Wenn Sie berücksichtigen, dass Ihr Kofferraum (Cache) klein ist und Sie nicht alles auf einmal transportieren können, wie lange dauert es?

4. Was SOLAR Ihnen sagt (Der „Spielraum“)

Der aufregendste Teil ist, was SOLAR enthüllt: Die Lücke.

Wenn Ihr aktuelles KI-Modell 10 Sekunden benötigt, um zu laufen, und SOLAR sagt, dass das theoretische Limit 1 Sekunde beträgt, haben Sie einen 10-fachen „Spielraum“ (Headroom).

Die „Spielraum“-Analogie: Stellen Sie sich vor, Sie fahren mit 60 mph in einer 100 mph Zone. SOLAR sagt Ihnen: „Sie fahren mit 60, aber das Auto und die Straße können 100 bewältigen. Hier ist genau der Punkt, an dem Sie langsamer werden: Liegt es daran, dass Sie zu oft anhalten? Liegt es daran, dass Ihr Kofferraum zu klein ist? Liegt es daran, dass Sie eine schlechte Route nehmen?“

5. Reale Beispiele aus dem Paper

Die Autoren haben SOLAR in drei Arten von Szenarien getestet:

Standard-Benchmarks: Sie fanden heraus, dass aktuelle Software bei komplexen Aufgaben oft 50-mal langsamer ist als das theoretische Limit. Das bedeutet, dass es massiven Raum für Verbesserungen gibt, allein durch die Umgestaltung der Art und Weise, wie der Code ausgeführt wird.
Robotik: Sie untersuchten Roboter, die sofort reagieren müssen (500 Mal pro Sekunde). SOLAR sagte ihnen: „Ihre aktuellen Computerchips sind zu langsam, weil sie Daten nicht schnell genug bewegen können. Sie benötigen einen Chip mit 20-mal mehr Bandbreite, um diesen Roboter in Echtzeit arbeiten zu lassen.“
Unterschiedliche Hardware: Sie zeigten, dass man vorhersagen kann, wie ein Modell auf einem neuen, noch nicht veröffentlichten Chip laufen wird, indem man einfach die Mathematik durchführt, ohne den Chip vorher kaufen zu müssen.

Zusammenfassung

SOLAR ist wie ein GPS für die KI-Leistung. Anstatt Ihnen nur zu sagen, wie lange Ihre Reise gedauert hat, berechnet es die absolut schnellstmögliche Reisezeit für Ihr spezifisches Auto und Ihre spezifische Straße. Es zeigt Ihnen dann genau auf, wo Sie Zeit verlieren – ob durch eine schlechte Routenplanung (Algorithmen), zu viele Stopps (Speicherverkehr) oder einen zu kleinen Kofferraum (Cache) – damit Sie genau wissen, wie Sie es anpassen müssen, um die „Speed of Light“ zu erreichen.

Technisches Resümee: SOLAR – KI-gestützte Analyse der Speed-of-Light-Performance

1. Problemstellung

Moderne Deep-Learning-Beschleuniger erreichen Spitzenleistungen im PetaFLOPS-Bereich, doch reale Workloads nähern sich diesen theoretischen Limits selten an. Es besteht eine kritische Lücke im Verständnis darüber, wie schnell ein Modell auf der Zielhardware laufen könnte im Vergleich dazu, wie schnell es tatsächlich läuft. Bestehende Tools adressieren dies nicht umfassend:

FLOP-Counter (z. B. fvcore, ptflops) leiden unter einer engen Operator-Abdeckung (75–84 % auf KernelBench), ignorieren den I/O-Verkehr und können keine theoretischen minimalen Ausführungszeiten (Speed-of-Light oder SOL-Grenzwerte) ableiten.
Hardware-Profiler (z. B. NCU, NSys) messen die erreichte Performance spezifischer Implementierungen statt theoretischer Limits und melden potenziell einen „Headroom“, der aufgrund algorithmischer Einschränkungen physisch unerreichbar ist.
Reine LLM-Schätzungen sind fehleranfällig, insbesondere bei zusammengesetzten Workloads, und es fehlt ihnen an den systematischen Suchkapazitäten, die für eine Cache-bewusste Analyse erforderlich sind.
Bestehende Performance-Modellierungs-Frameworks (z. B. Timeloop, AccelForge) erfordern eine manuelle Spezifikation der Workloads, was fehleranfällig ist und von der schnellen Modellentwicklung entkoppelt ist.

Es existiert kein bestehendes Tool, das automatisch validierte SOL-Grenzwerte direkt aus hochgradigem Quellcode (PyTorch/JAX) mit breiter Operator-Abdeckung ableitet.

2. Methodik

SOLA (Speed-of-Light Analysis for Runtime) ist ein Source-to-SOL-Framework, das diese Lücke durch eine dreistufige Pipeline schließt, welche die generative Translation von der deterministischen Analyse trennt.

Stufe 1: Validierter Agentic Frontend

Die erste Stufe übersetzt beliebige Quellprogramme in eine ausführbare Affine Loop IR.

LLM als Parser: Ein LLM-Agent übersetzt den Quellcode in die Affine Loop IR, eine sprachunabhängige Zwischenrepräsentation.
IR-Struktur: Die IR unterteilt Programme in:
- Restriktive Affine Loop Kernels: Perfekt verschachtelte Schleifen über benannten, dimensionalen Tensoren mit statischen Grenzen und affinen Index-Ausdrücken, die für das mechanische Lifting zu Einsums konzipiert sind.
- Unrestriktive Kompositionsebene: Behandelt Kontrollfluss, Datentransport (Reshape, Slice) und dünnbesetzte Operationen (Sparse Operations).
Validierungsschleife: Um die Korrektheit zu gewährleisten, führt das System das Originalprogramm aus, um „Golden“-Outputs zu erfassen, generiert die IR via LLM, führt die IR (unter Verwendung von Numba) aus und vergleicht die Outputs. Tritt eine Diskrepanz auf, leitet ein diagnostisches Feedback das LLM zur Korrektur der Translation an. Diese „Generate-then-Verify“-Schleife stellt sicher, dass die nachgelagerte Pipeline nur numerisch validierte Übersetzungen erhält.

Stufe 2: Deterministische Einsum-Generierung

Sobald die IR validiert ist, hebt ein deterministischer Compiler sie in einen Einsum-Graphen an.

Graphkonstruktion: Das Backend verfolgt die IR, um einen gerichteten azyklischen Graphen (DAG) aufzubauen, bei dem Knoten erweiterte Einsums (unterstützen Reduktionen wie Max) darstellen und Kanten die Tensor-Datenabhängigkeiten repräsentieren.
Mechanische Ableitung: Aus der Subskript-Struktur der Einsums leitet das System mechanisch exakte MAC-Zahlen und Speicherverkehrsformeln ab.
Fusibilitätsanalyse: Die Graphstruktur identifiziert benachbarte Operatoren, die On-Chip-Buffer teilen können, wodurch das System die Kosten für gefusste Operationen gegenüber einer unabhängigen Ausführung berechnen kann.

Stufe 3: SOL-Analyse

Das analytische Backend berechnet die theoretisch minimalen Ausführungszeiten ( $T_{SOL}$ ) gegenüber den Zielhardware-Spezifikationen (Spitzenleistung $\Pi$ und DRAM-Bandbreite $\beta$ ).

Roofline-Modell: $T_{SOL} = \max(\frac{\text{FLOPs}}{\Pi}, \frac{\text{Traffic}}{\beta})$ .
Multi-Fidelity-Modi:
1. Unfused: Nimmt eine unabhängige Ausführung mit vollen DRAM-Round-Trips für Zwischenergebnisse an.
2. Fused: Eliminiert den zwischenzeitlichen DRAM-Verkehr durch die Annahme einer unendlichen On-Chip-Buffer-Kapazität für gefusste Operatoren.
3. Cache-Aware Fused (OROJENESIS): Modelliert die endliche On-Chip-Buffer-Kapazität. Es nutzt ganzzahlige lineare Programmierung, um Tiling-Strategien zu optimieren, wobei Re-Reads aus dem DRAM berücksichtigt werden, wenn der Arbeitsdatensatz die Cache-Limits überschreitet.
Inverse Roofline: Gegeben eine Ziel-Latenz leitet das System die erforderlichen minimalen Hardware-Spezifikationen ( $\Pi_{min}$ und $\beta_{min}$ ) ab.

3. Kernbeiträge

Erstes Source-to-SOL Framework: SOLAR ist das erste Tool, das validierte SOL-Grenzwerte direkt aus PyTorch- und JAX-Quellcode ableitet und dabei eine 100%ige Analyse-Abdeckung auf KernelBench erreicht.
Hybrider generativ-deterministischer Pipeline: Es komb Kombinationiert ein LLM für die sprachunabhängige Translation (mit numerischer Validierung) und einen deterministischen Compiler für reproduzierbare Performance-Analyse. Dies vermeidet die Fehler reiner LLM-Schätzungen und umgeht gleichzeitig den manuellen Aufwand traditioneller Modellierung.
Umfassende Evaluierung: Das Framework liefert Evidenz über Kernel-, Algorithmus- und Architektur-Use-Cases hinweg und demonstriert Fähigkeiten in den Bereichen Headroom-Analyse, Optimierungsidentifikation, plattformübergreifende Exploration und Hardware-Bereitstellung.

4. Ergebnisse

Die Evaluierung wurde auf KernelBench (270 Probleme), JAX/Flax-Modellen und Robotik-Workloads auf Jetson Thor durchgeführt.

Headroom-Analyse: SOLAR offenbart signifikante Optimierungslücken. Auf KernelBench liegt die Lücke zwischen gemessener Laufzeit und gefusster SOL zwischen dem 4,3-fachen (L1) und dem 54,6-fachen (L3) für PyTorch Eager Execution. Selbst torch.compile lässt erheblichen Headroom (z. B. 47,7× auf L3), was zeigt, dass die Graph-Level-Fusion für zusammengesetzte Workloads entscheidend ist.
Multi-Fidelity-Erkenntnisse:
- Fusion: Die gefusste Analyse zeigt bis zu einen 7,8× höheren Headroom im Vergleich zur pro-Operator-Analyse auf KernelBench.
- Caching: Cache-bewusste Grenzen ziehen die SOL um bis zu 2,25× gegenüber naiven gefussten Grenzen enger, was Tiling als Engpass in spezifischen Szenarien identifiziert.
- Algorithmische Optimierung: Die Neuordnung von Einsum-Ketten (z. B. in DeepSeek MLA) erreichte eine 2,04× Reduktion der FLOPs gegenüber der naiven Ordnung.
Plattformübergreifende Projektion: SOLAR projiziert die Performance auf vier Hardware-Targets (B200, H100, A6000, Jetson Thor) ohne physischen Zugriff. Die Fusions-Vorteile variieren stark je nach Plattform (1,8× auf B200 vs. 14,5× auf Jetson Thor), was die Wechselwirkung zwischen Bandbreite und Fusion verdeutlicht.
Hardware-Bereitstellung (Inverse Roofline): Für Robotik-Modelle, die 500 Hz Regelkreise anstreben, identifizierte SOLAR die Bandbreite als primären Engpass. Beispielsweise benötigt das DreamZero WAM Modell eine 19,7× Verbesserung der aktuellen Bandbreite, um die Latenzziele zu erreichen, was darauf hindeutet, dass Silicon-Upgrades allein ohne Modellkompression oder algorithmische Änderungen unzureichend sind.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass SOLAR die Herangehensweise an die Performance-Optimierung grundlegend verändert, indem es theoretische Limits zugänglich und handhabbar macht, ohne dass eine manuelle Modellierung erforderlich ist.

Schließung der Lücke: Es schließt die Diskrepanz zwischen schneller Modellentwicklung und Hardware-Performance-Analyse und bietet eine „validierte“ Obergrenze für die Optimierung.
Handlungsorientierte Erkenntnisse: Durch die Bereitstellung von Multi-Fidelity-Analysen hilft es Ingenieuren, zwischen Engpässen durch mangelnde Fusion, schlechtes Tiling oder fundamentale algorithmische Ineffizienzen zu unterscheiden.
Hardware-agnostisches Design: Es ermöglicht Architekten und Algorithmen-Designern, Designräume zu explorieren und Hardware-Anforderungen bereitzustellen, bevor die Silizium-Entwicklung abgeschlossen ist, um die Verschwendung von Rechenleistung und Tokens für Arbeit mit wenig verbleibendem Headroom zu verhindern.

Die Autoren betonen, dass die Analyse zwar auf Tensor-Shapes (nicht auf Werten) basiert und ein ideales Hardwareverhalten annimmt (unter Ignorierung von Thermal Throttling), aber die erste automatisierte, validierte und umfassende Sicht auf die theoretische Speed-of-Light für Deep-Learning-Workloads bietet.