Faktenblatt: Gaudi – Management-Versagen vs. technische Sackgasse
Die Aussage des anderen Diskutanten ist
teilweise richtig, aber zu kurz gegriffen. Ja, Gaudis Potenzial wurde durch Management-Entscheidungen und Ressourcenentzug erstickt. Aber die technischen und strukturellen Hürden machten einen schnellen CUDA-Klon („einfach HIP reinwerfen“) unmöglich. Aus Investorensicht war die Beerdigung daher
nicht alternativlos, aber
rational begründbar – die Alternativen waren teuer und risikoarm nicht verfügbar.
---
### 1. Management-Realität: Ressourcenentzug war real
Die „stiefmütterliche Behandlung“ ist belegt, nicht nur ein Gefühl.
- Personalschwund und Verzögerungen: Die Open-Source-Treiber für Gaudi 3 wurden erst Ende 2025 veröffentlicht – über ein Jahr nach Marktstart – und durchliefen mehrere Runden von Maintainer-Wechseln aufgrund von Layoffs und Abgängen.
- Einstellung der Wartung: Im Februar 2025 archivierte Intel das Open-Source-Projekt SynapseAI Core und stellte die aktive Wartung offiziell ein. Das README trägt seither den Hinweis: „PROJECT NOT UNDER ACTIVE MANAGEMENT“ – Intel leistet keine Bugfixes, Updates oder Patch-Annahmen mehr.
- Marktzahlen: Intel verfehlte sein 500-Mio.-USD-Umsatzziel für Gaudi im Jahr 2024 deutlich, nachdem ursprünglich 1–2 Mrd. USD angepeilt waren.
Fazit: Das Management hat Gaudi nicht aktiv „beerdigt“, aber es hat ihm die Ressourcen entzogen, die für ein konkurrenzfähiges Software-Ökosystem nötig gewesen wären. Das ist ein realer, belegbarer Faktor.
---
### 2. Technische Realität: Warum „einfach HIP reinwerfen“ nicht ging
Die Hardware war programmierbar – aber anders als eine GPU.
- Gaudi war kein starrer ASIC ohne Programmierbarkeit. Die Tensor Processing Cores (TPCs) sind voll programmierbare VLIW-SIMD-Prozessoren (256 Bit breit), die mit TPC-C – einem C99-Derivat – programmiert werden können. Die Matrix Multiplication Engines (MMEs) hingegen sind „configurable, not programmable“. Gaudi hätte also theoretisch eine CUDA-ähnliche Schnittstelle bekommen können.
- Der Unterschied lag im Programmiermodell und der Kontrolle. Statt offener Low-Level-Kontrolle setzte Intel auf den SynapseAI-Graph-Compiler, der die Optimierung übernimmt und dem Entwickler die explizite Kontrolle über Graph-Optimierungen entzieht. Bei nicht unterstützten Operatoren fällt die Ausführung auf die CPU zurück – der Datentransfer zwischen HPU und CPU zerstört die Performance.
- HIP ist keine Ein-Klick-Lösung. AMD selbst dokumentiert: Inline-PTX in CUDA-Kernels kann hipify nicht übersetzen – NVIDIA-spezifische Assembler-Semantik bleibt unübersetzt oder erzeugt ungültigen Code für AMD. Auch die Performance-Portierung (Wavefront-Breite, Shared-Memory-Tiling, Registerdruck) erfordert manuelle Neuoptimierung. HIP bietet Quellcode-Kompatibilität, keine Performance-Kompatibilität.
Fazit: Ein CUDA-Äquivalent für Gaudi hätte nicht „reingeknallt“ werden können. Es wäre ein
mehrjähriges, personalintensives Software-Projekt gewesen – genau die Art von Investition, die Intel unter Kostendruck nicht mehr tätigen wollte.
---
### 3. Investoren-Perspektive: War die Beerdigung unausweichlich?
Nicht unausweichlich, aber rational begründbar.
| Faktor | Bewertung aus Investorensicht |
| :--- | :--- |
|
Software-Ökosystem | Der CUDA-Moat war
nicht mit einem Einzelprojekt zu brechen. AMD baute ROCm/HIP über
Jahre mit
einer einheitlichen GPU-Architektur auf. Intel hatte für Gaudi einen
Sonderweg (SynapseAI) und parallel
oneAPI für Xe – die Kräfte waren zersplittert. |
|
Marktfenster | Intel-CEO Lip-Bu Tan sagte intern:
„On training I think it is too late for us“ – Nvidias Marktposition sei zu stark, um sie noch einzuholen. |
|
Kosten der Alternative | Einen konkurrenzfähigen CUDA-Klon für Gaudi zu bauen, hätte
Milliarden verschlungen und
Jahre gedauert – ohne Erfolgsgarantie gegen ein etabliertes Ökosystem. |
|
Fokus | Die Ressourcen flossen stattdessen in
Foundry (18A) und
Xe-GPUs (Crescent Island, Jaguar Shores) – Bereiche, in denen Intel einen
strukturellen Vorteil aufbauen kann, statt gegen CUDAs Software-Moat frontal anzurennen. |
Kurz gesagt: Die Beerdigung von Gaudi war
keine geniale Entscheidung, aber unter den gegebenen Zwängen (Kapitaldruck, CUDA-Dominanz, zersplitterte Software-Ressourcen) eine
nachvollziehbare Portfolio-Entscheidung. Der andere Diskutant hat recht, dass das Management Gaudis Potenzial erstickt hat. Er greift aber zu kurz, weil er die
technische und strukturelle Dimension ausblendet: Selbst mit mehr Ressourcen wäre ein CUDA-Klon für Gaudi ein
langwieriges, riskantes Unterfangen gewesen – kein schnell umsetzbarer Fix.