Automatisierte Leistungsoptimierung & GPU-Kernel-Generierung

Geschwindigkeit aus Hotspot-Code (GPU-Kernel, numerische Routinen, Inferenzpfade) herauszuholen, ist langsame Expertenarbeit, die von der genauen Hardware abhängt. Eine evolutionäre oder agentische LLM-Schleife schlägt viele Codevarianten vor, kompiliert und vermisst jede auf dem realen Ziel, verwirft alles, was eine Korrektheitsprüfung nicht besteht, und gibt die besten Ergebnisse als Kontext für die nächste Runde zurück. Das Ergebnis sind gemessene Einsparungen bei Laufzeit und Energie, wobei ein Mensch die endgültige Änderung prüft.

Problem & Nutzen

• Heute: Eine kleine Gruppe von Performance-Ingenieuren optimiert Kernel von Hand (Tiling, Memory Coalescing, Fusion, Nutzung von Tensor-Cores, Vektorisierung) für jede Hardwaregeneration. Jede neue GPU, Framework-Version oder Modellarchitektur kann frühere Optimierungen entwerten. Die meisten Teams akzeptieren schlicht die Standardleistung der Bibliotheken und zahlen für die zusätzliche Rechenleistung.
• KI-Nutzen: LLMs kennen gängige Optimierungsmuster und können CUDA-, Triton- oder SIMD-Code schreiben; automatisches Benchmarking macht aus „plausiblem“ Code gemessene Verbesserungen. Die Suche über viele Varianten deckt mehr vom Entwurfsraum ab, als eine einzelne Person ausprobieren kann.
• Belege (vom Hersteller berichtet, nicht unabhängig): Google DeepMind berichtet, AlphaEvolve habe eine Scheduling-Heuristik für den Orchestrator seiner Rechenzentren gefunden, die dauerhaft etwa 0,7 % der weltweiten Rechenleistung von Google zurückgewinnt, einen Kernel in der Gemini-Architektur um 23 % beschleunigt (etwa 1 % kürzere Trainingszeit) und bei einem FlashAttention-Kernel bis zu 32,5 % gewonnen [1][2]. Verstehen Sie dies als Existenznachweise eines führenden Labors mit eigener Hardware, nicht als zu erwartende Ergebnisse für ein typisches Unternehmen. Benchmarks wie KernelBench zeigen, dass allgemeine LLMs PyTorch-Baselines oft nicht schlagen, wenn keine iterative, rückmeldungsgesteuerte Schleife genutzt wird [3].

Varianten

• GPU-Kernel-Generierung: CUDA-, Triton-, CUTLASS/CuTe-, HIP/ROCm-, Pallas-(TPU-)Kernel für Attention, GEMM, Normalisierung, quantisierte Operationen, MoE-Routing.
• Optimierung des Inferenz-Hotpaths: Operator-Fusion, Batching-/Scheduling-Heuristiken und Cache-Strategien in Serving-Stacks (vLLM, TensorRT-LLM) - ergänzt die Modellkompression.
• HPC und numerischer Code: CPU-Vektorisierung, MPI/OpenMP-Tuning, Kernel für dünn besetzte Matrizen und Stencils in Simulations- und Forschungscodes.
• Entdeckung von Algorithmen und Heuristiken: Weiterentwicklung von Bewertungsfunktionen, Schedulern, Compiler-Heuristiken oder mathematischen Konstruktionen (im Stil von AlphaEvolve), wo ein programmatischer Evaluator existiert [2].
• Profiling-Assistent auf Anwendungsebene: Ein LLM liest Flame Graphs und Profiler-Spuren und schlägt Korrekturen für Hotspots in gewöhnlichem Backend-Code vor (geringere Autonomie, breiter Nutzen).
• Private Nutzung: Optimierung von Kerneln für lokale Inferenz durch Hobbyisten und Studierende; geringer Wert, gleiche Werkzeuge.

So funktioniert es

1. Ausgangscode + Referenztests + Hardware-Spezifikation
2. LLM schlägt N Varianten vor (Mutationen / Umschreibungen, gestützt auf Profiler-Feedback und frühere Gewinner)
3. Kompilierung in der Sandbox (nvcc / Triton / clang)
4. Build-Fehler verwerfen
5. Korrektheits-Gate (Vergleich mit Referenzausgaben, Toleranz je Datentyp, mehrere Zufalls-Seeds, Randfall-Formen)
6. Benchmark auf der Zielhardware (Warm-up, wiederholte Läufe, Taktsperre, Varianz)
7. Profiling (Nsight Compute / rocprof)
8. Metriken an das LLM zurückspielen
9. Auswahl (evolutionäre Datenbank: beste + diverse Varianten behalten)
10. nächste Generation
11. menschliche Prüfung des Gewinners
12. Regressionssuite
13. Merge

• Vorschlagender Teil (Proposer): ein codefähiges Reasoning-LLM, oft ein Ensemble aus einem schnellen Modell für die Breite und einem stärkeren für die Tiefe (das AlphaEvolve-Muster) [2]. Reinforcement Learning mit Beschleunigung als Belohnung ist eine aufkommende Alternative zum reinen Prompting.
• Evaluator: der entscheidende Teil. Es ist ein deterministischer Rahmen, der Korrektheit und Zeitmessung liefert; er muss schwer auszutricksen sein. Öffentliche Berichte zeigen, dass schwache Rahmen ausgenutzt werden können (z. B. durch Wiederverwendung von Speicher früherer Läufe oder Auslassen von Arbeit), was die anfangs behaupteten Beschleunigungen beim „AI CUDA Engineer“ von Sakana aufblähte, bis der Fehler behoben wurde [4].
• Mensch-in-der-Schleife (Human-in-the-Loop): Ingenieure legen Ziel, Toleranz und Eingabeformen vorab fest, prüfen den Gewinner-Diff und führen vor der Freigabe die vollständige Test- und numerische Stabilitätssuite aus.

Datenaufbereitung

Die Eingaben sind der zu optimierende Code (Kernel, Hotpaths, Solver-Heuristiken), eine Korrektheitsreferenz und ein verlässlicher Benchmark auf der Zielhardware. In einem Unternehmen liegen diese in Git-Repositories, Performance-Testlaboren und CI-Runnern; in kleineren Teams oft auf dem Arbeitsplatzrechner einer einzelnen Person.

Typische Lücken: kein reproduzierbarer Benchmark, verrauschte Zeitmessungen auf geteilten Maschinen, fehlende Referenzimplementierung oder Unit-Tests für numerische Korrektheit, keine Profiling-Daten und unklare Leistungsziele.

Vorbereitungsschritte: 1. Zuerst profilieren (Nsight, perf, py-spy) und einen Hotspot mit messbarem Laufzeitanteil auswählen. 2. Einen deterministischen Benchmark mit festen Eingaben und Warm-up bauen, auf isolierter Hardware ausführen. 3. Ein Korrektheitsorakel schreiben: die Referenzimplementierung plus toleranzbasierte Tests mit unterschiedlichen Eingaben. 4. Die Build-Umgebung containerisieren, damit jeder Kandidat identisch kompiliert wird. 5. Die Ausführung generierten Codes in einer Sandbox durchführen.

Werkzeuge: pytest, Google Benchmark, Nsight Compute, Docker. Aufwandsanteil: gering bis mäßig, etwa 15 bis 25 Prozent, aber die Qualität des Orakels entscheidet, ob man den Ergebnissen trauen kann. GUIDE-003 und PREP-018 (Testsets mit Fachleuten aufbauen) helfen.

Umsetzungswege

Welcher Weg für wen

• enterprise (B): Optimierungsschleifen brauchen eigene Benchmarks und Zielhardware, daher liefert ein eigener Rahmen, der Cloud-Modell-APIs aufruft, die besten Ergebnisse, ohne dass etwas trainiert werden muss.
• developer (B): Frontier-Modell-APIs erzeugen heute die besten Kernel-Kandidaten; der Evaluierungsrahmen läuft lokal auf der eigenen GPU.

Weg A — Kaufen (Standardsoftware)

Es gibt nur wenige schlüsselfertige Produkte. Optionen sind (1) von Herstellern bereitgestellte optimierte Bibliotheken und Compiler mit eingebautem Autotuning (NVIDIA cuDNN/CUTLASS, TensorRT-LLM, PyTorch torch.compile mit Inductor, OpenAI Triton Autotuner), (2) Cloud-Dienste wie das Early-Access-Angebot AlphaEvolve von Google Cloud für ausgewählte Kunden und (3) KI-gestützte Profiler in allgemeinen Coding-Agenten (CODE-001/002). Aus der EU: wenige spezialisierte Anbieter; fragen Sie Ihre GPU-/HPC-Beratungen. Wählen Sie A, wenn der Engpass in einem Standardoperator liegt, den Hersteller bereits optimieren.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlener Einstieg)

• Modelle: führende Reasoning-/Codemodelle (Claude, Gemini, GPT) oder die Codemodelle von Mistral (EU-Anbieter) über API in EU-Regionen, wo verfügbar; Code und Benchmarks enthalten selten personenbezogene Daten.
• Schleife: Die Open-Source-Frameworks OpenEvolve (von AlphaEvolve inspiriert) oder ShinkaEvolve liefern die evolutionäre Datenbank, das Prompt-Sampling und Evaluator-Anbindungen [5]; kombinieren Sie sie mit einem generischen Agenten- Framework für profilergesteuerte Iterationen.
• Hardware: Die Benchmark-GPUs sind der Kostenblock - mieten Sie Zielhardware (EU-Cloud oder On-Premises) und führen Sie den Evaluator in isolierten Containern aus; LLM-Tokens fallen meist kaum ins Gewicht.
• B wählen, wenn: Sie ein bis zwei heiße Kernel oder Dienste und eigene GPUs für den Evaluator haben.

Weg C — Selbst betreiben (Open Source)

• Modelle: Open-Weight-Code-/Reasoning-Modelle wie Qwen3-Coder, DeepSeek-V3/R1-Klasse, gpt-oss oder Mistral Devstral/Codestral, betrieben mit vLLM; auf Kernel spezialisierte Feintunings (z. B. aus der KernelBench-Community) entstehen gerade.
• Stack: OpenEvolve, Triton, CUDA Toolkit, Rahmen im Stil von KernelBench, Nsight/rocprof.
• Hardware: HW3 für den Proposer (Modell mit 30-120B) plus die Ziel-GPUs für den Evaluator; kleine Teams können mit einer Workstation-GPU (HW2) und einem ~30B-Modell beginnen.
• C wählen, wenn: der Quellcode hochvertraulich ist oder die Suche wochenlang läuft.

Weg D — Eigenes Training

RL-Feintuning eines Codemodells mit Beschleunigung als Belohnung, wobei echter Compiler und echte Hardware in der Belohnungsschleife stecken, ist die Forschungsfront [3][4]. Es braucht eine Flotte von Benchmark-GPUs und einen robusten, manipulationsresistenten Verifizierer; außerhalb von KI-Laboren, Chipherstellern und großen Inferenz-Betreibern selten gerechtfertigt.

Stand der Technik (2026)

• Evolutionäre LLM-Suche (AlphaEvolve, OpenEvolve und Nachfolger) ist das vorherrschende Muster zum Auffinden schnelleren Codes und besserer Heuristiken, sofern ein schneller automatischer Evaluator existiert [2][5].
• KernelBench (Stanford) ist der Referenz-Benchmark: 250 PyTorch-Workloads auf drei Stufen, bewertet mit der Kennzahl „fast_p“ (korrekt und um den Faktor p schneller als die Baseline). Frühe Ergebnisse zeigten, dass führende Modelle nur bei einer Minderheit der Aufgaben korrekte, schnellere Kernel erzeugten; iterative Rückmeldung durch Compiler-Fehler und Profiler verbessert die Ergebnisse erheblich [3].
• Triton senkt die Einstiegshürde gegenüber reinem CUDA, daher zielen viele Systeme zuerst darauf [6].
• Grenzen und Fehlerbilder: Reward Hacking am Benchmark; Kernel, die nur für getestete Eingabeformen oder ein GPU-Modell schnell sind; subtile numerische Abweichungen (fp16/bf16/fp8-Akkumulation); Race Conditions, die Tests nur zeitweise bestehen; Gewinne, die gegen eine gut optimierte Herstellerbibliothek verschwinden; Wartungslast durch unlesbaren generierten Code; nicht portable Ergebnisse über GPU-Generationen hinweg.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack: llm-code + agent-framework wie CODE-002; Test- und Sandbox-Infrastruktur aus CODE-004; Hardware-Verifikationsschleifen ähnlich CODE-019 (RTL, Testbenches).
• Vor-/nachgelagert: CODE-021 (Refactoring im großen Maßstab) zum Ausrollen akzeptierter Änderungen; CODE-009 für CI/CD-Benchmark-Runner; CODE-018 für das Tracing des Optimierungsagenten.
• Verwandt, aber verschieden: OPT-015 (FinOps) optimiert Ressourcenzuteilung und Cloud-Ausgaben, nicht Code.
• Gemeinsame Hardware: Der Pool der Benchmark-GPUs kann in Leerlaufzeiten als Inferenz-/Trainingskapazität dienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage; Gewinne begrenzt auf das, was Hersteller ausliefern.
• Weg B: 2-4 Monate, um einen vertrauenswürdigen Evaluator und die CI-Integration aufzubauen; Kostentreiber sind GPU-Stunden für Benchmarks und Arbeitszeit für den Rahmenentwurf, nicht Tokens.
• Weg C: 3-6 Monate; zusätzlicher Betrieb für das Modell-Serving.
• Weg D: 6+ Monate mit einem spezialisierten Team.
• Kennzahlen: Beschleunigung gegenüber der stärksten Baseline (nicht der naiven), p50-/p99-Latenz, Durchsatz pro GPU, Energie pro Inferenz oder pro Job, Quote akzeptierter Varianten, durchgerutschte Korrektheitsregressionen, GPU-Stunden je akzeptierter Verbesserung, Prüfzeit der Ingenieure.

Menschen & Veränderung

Einbinden: Die Geschäftsleitung muss nur Budget und GPU-Zeit freigeben; die Abteilungsleitung Entwicklung bzw. HPC wählt das Ziel und die Erfolgsschwelle. Endnutzer sind die Performance-Ingenieure, die jede Gewinnervariante validieren. Die IT stellt Hardware und isolierte Runner bereit, die IT-Sicherheit prüft die Sandbox, da die Schleife generierten Code ausführt (GUIDE-013).

Betriebsrat: nein. Das System optimiert Code und vermisst Programme, nicht Menschen; §87(1) Nr. 6 BetrVG wird daher nicht ausgelöst. Das sollte so bleiben: Hängen Sie keine Produktivitätskennzahlen je Ingenieur an. Informieren Sie den Betriebsrat dennoch nach §90(1) Nr. 3 BetrVG, wenn sich der Arbeitsprozess des Performance-Teams spürbar ändert. Eine(n) Datenschutzbeauftragte(n) oder eine DSFA braucht es nicht, da keine personenbezogenen Daten verarbeitet werden.

KI-Kompetenz: Fördern Sie die Fähigkeiten der Ingenieure (Art. 4 KI-Verordnung) mit einem Workshop zu Benchmark-Gültigkeit, Reward Hacking (eine Variante, die den Benchmark austrickst) und Prüfungen der numerischen Korrektheit (GUIDE-006).

Pilot und Kommunikation: Beginnen Sie mit einem einzelnen Kernel oder Hotpath mit klarem Beschleunigungsziel und einem Zeitrahmen von vier bis sechs Wochen; legen Sie vorab eine Go/No-go-Schwelle fest (GUIDE-009). Typische Sorge: „Generierter Code ist nicht wartbar oder subtil falsch.“ Antwort: Jede akzeptierte Variante besteht das Orakel, durchläuft das normale Code-Review und wird dokumentiert, sodass die Verantwortung bei Menschen bleibt.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko; das System optimiert Software und verarbeitet keine Personen. Die Pflicht zur KI- Kompetenz nach Art. 4 gilt. Läuft der optimierte Code in einem Hochrisiko-KI-System oder einer Sicherheitskomponente, muss die Änderung durch Konformitäts- und Änderungsmanagement dieses Systems [7].
• DSGVO: in der Regel nicht anwendbar (Code und Benchmarks); halten Sie Produktionsdaten aus den Test- eingaben heraus und verwenden Sie synthetische oder anonymisierte Eingaben.
• Sicherheit und Qualität (Safety): Bei medizinischer, automobiler oder industrieller Software (siehe CODE-020) brauchen generierte Optimierungen qualifizierte Werkzeug- und Verifikationsprozesse; numerische Änderungen können validierte Ergebnisse verändern.
• Geistiges Eigentum und Lizenzen: Lizenzen generierten Codes prüfen, der Open-Source-Kerneln ähneln kann; proprietärer Code, der an externe APIs gesendet wird, braucht vertraglichen Schutz.
• Sicherheit (Security): nicht vertrauenswürdigen generierten Code nur in Sandboxes ausführen (kein Netzwerk, Ressourcenlimits); von LLMs geschriebener nativer Code kann Speicher beschädigen.
• Nachhaltigkeit: Die Suche selbst verbraucht Energie; rechnen Sie sie gegen die Einsparungen auf.

Erste Schritte

1. Zuerst profilieren: einen Hotspot wählen, der einen großen Anteil an Laufzeit oder GPU-Ausgaben ausmacht.
2. Den Evaluator schreiben: Referenzausgaben, Toleranzen je Datentyp, repräsentative Eingabeformen, gesperrte Taktraten, wiederholte Zeitmessung; Prüfungen gegen Reward Hacking einschließen.
3. Mit starken Baselines vergleichen (cuBLAS/cuDNN, torch.compile, vorhandene Triton-Kernel).
4. OpenEvolve oder eine einfache Agentenschleife mit Budgetobergrenze ausführen; jede Variante und ihre Kennzahlen protokollieren.
5. Den Gewinner von Hand prüfen, die vollständige Regressions- und numerische Suite ausführen, dann mit einem Rollback-Plan ausrollen und bei jeder neuen GPU oder jedem neuen Treiber fortlaufend benchmarken.

Quellen

1. Google DeepMind - AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms - https://deepmind.google/discover/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/
2. Novikov et al. - AlphaEvolve white paper (arXiv 2506.13131) - https://arxiv.org/abs/2506.13131
3. Ouyang et al. - KernelBench: Can LLMs Write Efficient GPU Kernels? (arXiv 2502.10517) - https://arxiv.org/abs/2502.10517
4. Sakana AI - The AI CUDA Engineer (including the later correction notice) - https://sakana.ai/ai-cuda-engineer/
5. OpenEvolve - open-source AlphaEvolve implementation - https://github.com/codelion/openevolve
6. Triton language and compiler - https://github.com/triton-lang/triton
7. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj