Ein Rechenzentrum aus Resten
Profi-Teams trainieren ihre Schach-KIs auf Server-Farmen. Bei uns stand am Anfang ein einzelner Desktop - erst lief er stundenweise, dann tageweise. Wärme, Geräuschkulisse und Stromverbrauch waren anfangs erträglich, im Dauerbetrieb aber nicht mehr - und die Leistung einer einzelnen Maschine stößt schnell an ihre Grenze.
So entstand die Idee, die ohnehin herumliegende, ungenutzte Hardware einzuspannen und den Pool Stück für Stück zu erweitern. Denn es zeigte sich schnell: Diese Geräte arbeiten nicht nur leiser, sondern liefern einzeln wie in der Summe ein echtes Ergebnis.
Daraus ist ein verteilter Datagen-Cluster geworden, der in zwei bis drei Tagen rund 60 Millionen Trainingsstellungen erzeugt. Wie das eingebunden, gegen Hitze und Stromausfall abgesichert und über drei Betriebssysteme verteilt ist - hier die Werkstattnotiz.
Die Hardware - und wie sie zusammenfindet
Der Mix ist bewusst heterogen: mehrere Android-Smartphones (über die Linux-Umgebung
Termux), Linux-Laptops (Debian, teils direkt vom USB-Stick), ein Windows-Control-Node
und ein Linux-VServer. Alle Geräte hängen per SSH zusammen; ein zentraler
Steuerknoten startet die Arbeit, überwacht sie und sammelt die Ergebnisse ein. So wird jedes
herumliegende Gerät in Minuten zum Rechenknoten.
Tage am Stück: Temperatur, Akku, Kerne
Ein Lauf dauert Tage - das verzeiht keine halbe Absicherung. Zwei Dinge entscheiden, ob ein Knoten durchhält: Wärme und Strom.
Temperatur. Ein „Governor"-Skript berechnet die Zahl der genutzten Kerne (Threads) live aus Akku-Stand und Chip-Temperatur und startet den Datagen-Prozess bei Bedarf neu. Wichtige Lektion: man muss alle Thermal-Zonen auslesen, nicht nur die Oberflächensensoren. Beispiel: ein Dimensity-9300+-Smartphone drosselt bei 7 Threads - 6 sind das stabile Optimum, und mit aktiver Kühlung läuft es tagelang durch.
Akku & Strom. Kritische Energiespar-Aktionen werden abgeschaltet (kein Auto-Shutdown bei niedrigem Akku), Deckel-Schalter und Ruhezustand auf den Laptops sind deaktiviert, die Geräte hängen am Netzteil. Trotzdem nötig: ein Akku-Watcher, der Geräte stoppt, die trotz Netzteil entladen - denn vier Kerne bei voller Last ziehen mehr Strom, als manches Ladegerät liefert.
Die Überraschung: Smartphones in der Laptop-Klasse
Der größte Aha-Moment: moderne Flaggschiff-Smartphones liefern einen Datagen-Durchsatz auf Augenhöhe mit älteren x86-Laptops. Spitzenreiter im Cluster ist der AVX-512-VServer - rund 2,2-mal so schnell wie ein Ultrabook. Und ein Laptop entpuppte sich als rein watt-limitiert, nicht thermisch: eine physikalische Wand, kein Defekt.
Aufgabenteilung über drei Betriebssysteme
Die Arbeit zerfällt in drei Rollen, die zu den Stärken der Geräte passen:
- Datagen - Selbstspiel-Partien erzeugen (viele Kerne pro Gerät; ideal für die Smartphones).
- Rescore - die erzeugten Stellungen mit einem stärkeren „Lehrer" (Stockfish) neu bewerten/labeln (Laptops + AVX-512-VServer).
- Training - das neuronale Netz (NNUE) auf der GPU lernen lassen (eigene Maschine; mehr dazu unten).
„Seti@home" fürs Schach
Damit nichts doppelt gerechnet wird, läuft das Rescoring wie ein klassisches verteiltes Rechenprojekt: Ein Master-Knoten hält eine Warteschlange von Work-Units. Jeder Worker holt sich atomar eine Einheit (Reservierung per atomarem Verschieben + Lease), rescored sie lokal, schiebt das Ergebnis zurück und bestätigt es atomar (von „in Arbeit" auf „fertig"). Fällt ein Gerät aus, wird seine Einheit einfach neu vergeben - doppelte Arbeit entsteht nie.
Das Trainingsdaten-Format hilft dabei: feste Recordgröße, einfach aneinanderhängbar. Man sammelt die Teildateien ein und hängt sie zusammen - fehlertolerant und ohne komplizierte Datenbank.
GPU-Training: vom Korpus zum Netz
Die verteilt gesammelten und vom Stockfish-Teacher nachbewerteten Stellungen - rund 200 Millionen pro Trainingskandidat - fließen in den Open-Source-Trainer bullet (GPU/CUDA). Heraus kommt ein neuronales Bewertungsnetz der Architektur kb4×768 (king-bucketed, 768er-Zwischenschicht); die Auswertung einer Stellung dauert auf der CPU unter einer Mikrosekunde.
Das Rezept in Zahlen: rund 120 Epochen (jede ein kompletter Durchlauf der ~200 Mio. Stellungen), ein gestufter Lernraten-Plan mit Warmup und finalem Drop, ein konstanter Win/Draw/Loss-Mischfaktor - in Summe etwa 24 Milliarden Trainings-Samples pro Netz.
Multi-Seed gegen Selbstbetrug. Gleicher Datensatz, mehrere zufällige Start-Seeds - so wird die natürliche Zufallsvarianz sichtbar. Ausgewählt wird nicht die schönste Trainingskurve, sondern die beste Spielstärke, bestätigt per 400-Partien-SPRT gegen die Live-Baseline. Ein „Lucky Seed", der zufällig gut aussieht, überlebt den SPRT nicht.
Warum die Trainingsmetrik lügen kann. Der Validation-Loss (Richtwert ~0,0077) prüft Overfitting und Reproduzierbarkeit - aber ein niedrigerer Wert heißt nicht „stärker". Auf einem nach Eröffnungs-Coverage verzerrten Prüfdatensatz kann das Signal sogar gegenläufig sein. Deshalb entscheidet am Ende nur der Elo-SPRT.
Zwei Geschichten dazu aus der Werkstatt:
- „Val-Loss lügt." Zwei Trainingsläufe zeigten einen besseren Validation-Loss als die Baseline - und verloren trotzdem deutlich im SPRT. Das Prüfset war nach Eröffnungen gewichtet, nicht nach der Suchfront; ein Netz, das dieses Set „auswendig lernt", verliert das taktische Mittelspiel. Erst das Brett entscheidet.
- „Reboot um 2:42." Ein nächtlicher Windows-Update-Neustart traf mitten in einen stundenlangen Bewertungslauf. Gerettet hat das Datenformat: feste Recordgröße und fortschritts-erhaltend - der Lauf machte exakt an der unterbrochenen Stelle weiter, null Datenverlust.
Stolpersteine über OS-Grenzen
Drei Betriebssysteme bedeuten drei Sorten Überraschungen. Die, die uns Zeit gekostet haben:
- Prozess-Erkennung auf Android/Termux liefert Fehltreffer - Lösung: exakter Abgleich des Programmnamens plus Prüfung über das Datei-Wachstum statt der Prozessliste.
- Android beendet Termux-Sitzungen nach rund zwei Stunden - ein Auto-Restart-Monitor von einem stabilen Knoten hält sie am Leben.
- Programmdateien nie auf flüchtigen RAM-Disks ablegen - nach einem Neustart sind sie weg, und es entsteht eine Absturz-Schleife.
- Zeichensätze: ein Windows-Skript las UTF-8 falsch und brach an einem Sonderzeichen still ab - seitdem strikte ASCII-Disziplin in den Steuerskripten.
Der schönste Fehler zum Schluss: Ein Smartphone-WLAN mit aktivierter „Client Isolation" machte die Geräte gegenseitig unsichtbar - sie liefen einwandfrei, waren aber nicht erreichbar. Lösung: ein eigenes, dediziertes Datagen-WLAN.
Was bleibt
Ernsthaftes maschinelles Lernen braucht nicht zwingend ein Rechenzentrum - sondern Disziplin bei Wärme, Strom und Fehlertoleranz. Der Rest ist Orchestrierung. Mehr zum Gesamtbild auf der Projekt-Seite; die Engine spielt live als @clrsrc_lc0, der Quellcode liegt auf GitHub.