EXO-Cluster gebaut, und jetzt produktionsreif machen

EXO (das Open-Source-Projekt, das Inferenz-Workloads über heterogene Hardware verteilt) ist beeindruckend. Wir haben zu Hause selbst lange damit gearbeitet (M2 Ultra + RTX 4090 Box + Linux-Workstation, alles mit derselben Modell-Last). Für Bastelfreude und Lernen ist EXO eine bessere Adresse als jeder zertifizierte Hardware-Stack.

Was uns über Monate aufgefallen ist: Der Sprung vom Pet-Projekt zur produktiven Arbeitslast verläuft nicht graduell. Es gibt drei harte Klippen.

Klippe 1: Stabilität der heterogenen Hardware

Solange ein Cluster aus drei Knoten 3 Stunden am Tag läuft, sind Treiber-Updates, USB-Diskrepanzen und das gelegentliche Auf-und-Ab-Verhalten der Mac-MPS-Pipeline egal. Sobald derselbe Cluster jeden Tag laufen muss, fällt das Maintenance-Hochrechnen brutal aus: Pro Knoten ein paar Stunden im Monat, multipliziert mit allen Update-Zyklen, ergibt einen halben Tag pro Woche IT-Bastelarbeit. Das skaliert nicht.

Klippe 2: Performance-Ceiling

EXO macht aus heterogener Hardware einen logischen Inferenz-Pool, aber die langsamste Komponente diktiert die Latenz. Auf Frontier-Modellen (235B, 397B, 480B) liefert ein Cluster aus M2 + 4090 + Workstation typischerweise 6–14 t/s. Das reicht für Spielerei, nicht für 30 parallele User-Sessions, die Sub-2-Sekunden-Erstantwortzeit erwarten.

Klippe 3: Wartbarkeit ohne Single-Vendor

Wenn etwas nicht läuft, fragt EXO nicht nach: NVIDIA-Treiber, macOS-Update, Python-Versions-Drift, Modell-Hash-Mismatch zwischen Knoten: der Bug liegt überall und nirgendwo. Es gibt keinen Hersteller, dessen Support-Hotline man anruft. Im Privat-Setup macht das Spaß; in einer Kanzlei, in der morgens die Vertragsanalyse warten muss, ist es ein Problem.

Wann EXO trotzdem die richtige Wahl ist

Forschung und Lehre: Lernen ist das Ziel, nicht der konstante Output. EXO ist ein hervorragendes Werkzeug, um die Innenwelt verteilter Inferenz zu verstehen.
Kapitalknappes Pet-Projekt: Wer schon Mac-Studio und RTX-Box hat, kommt ohne neue Hardware-Investition zu produktiver Inferenz.
Pre-Sales-Demo: "Wie würde lokal-KI aussehen?" lässt sich auf EXO im Showroom günstig beantworten.

Was wir konkret gemacht haben

Unsere produktiven Workloads sind auf eine homogene Spark-Basis umgezogen. Was bei EXO ständig nervte (variable Latenzen, Treiber-Driften, Modell-Sync), ist auf vier identischen Knoten mit denselben Treibern vom Tisch. Wir betreiben EXO heute noch auf einer Test-Maschine, um neue Modelle vor der Produkt-Aufnahme grob zu evaluieren: als Discovery-Werkzeug, nicht als Produktionsstack.

Wer EXO-Erfahrung hat und eine produktive Box sucht, hat den steilen Lerneffekt schon hinter sich: KI:KUBE ist dann nicht "etwas Neues", sondern "die produktive Variante derselben Idee".