Kubeflow Trainer: TrainJob, Runtimes und der Preis der Kubernetes-Native-Trainingsebene

Der Engpass liegt zwischen dem Trainingsskript und dem Cluster

Ein PyTorch-Skript, das auf einer Maschine mit acht GPUs läuft, wird nicht dadurch verteilt, dass man es auf einen Kubernetes-Pod legt. Es braucht eine feste Anzahl von Workern, eine Reihenfolge beim Start, eine gemeinsame Umgebung für Rank und World Size, einen Mechanismus für den Ausfall einzelner Prozesse und eine Stelle, an der der Job als Ganzes beschrieben wird. Kubeflow Trainer setzt genau hier an. Das Projekt beschreibt sich selbst als Kubernetes-native verteilte AI-Plattform für skalierbares LLM-Fine-Tuning und Training über Frameworks wie PyTorch, MLX, HuggingFace, DeepSpeed, Megatron-LM, JAX und XGBoost. Die Zielgruppe sind demnach nicht Data-Science-Einsteiger, sondern Plattformteams, die Trainingsjobs für andere bereitstellen, sowie Forschende, die bereits ein Cluster mit GPU-Knoten und einen Scheduler betreiben. Der Nutzen liegt weniger in einem neuen Trainingsalgorithmus als in der Vereinheitlichung: ein TrainJob-Objekt, das unabhängig vom Framework denselben Lebenszyklus hat, und Runtimes, die die framework-spezifische Konfiguration kapseln.

TrainJob, Runtime und der Weg durch JobSet und LeaderWorkerSet

Die beiden zentralen APIs heißen TrainJob und Runtime, wie das README im Zusammenhang mit dem Kubeflow Python SDK nennt. Ein TrainJob beschreibt den Lauf, eine Runtime beschreibt, wie dieser Lauf ausgeführt wird. Diese Trennung ist der eigentliche Mechanismus: Der Nutzer wählt eine Runtime, die Runtime kennt die Framework-Details, und der Controller übersetzt beides in Kubernetes-Objekte. Laut README verwendet Kubeflow Trainer dafür bestehende Bausteine aus dem Kubernetes-Umfeld, namentlich JobSet und LeaderWorkerSet, statt eine eigene Pod-Verwaltung zu bauen. Für MPI-Workloads kommt eine MPI-Runtime hinzu, die mehrknotige, multi-GPU-Jobs über High-Performance-Computing-Cluster orchestriert und auf schnelle Synchronisation zwischen GPU-Knoten zielt. Release v2.3.0 führt nach Angaben der Release Notes einen Runtime-Snapshot-Mechanismus ein, der den Runtime-Lebenszyklus entkoppelt, sowie erweiterten MPI-Support und Megatron-LM-Beispiele als Proposal. v2.2 brachte JAX- und XGBoost-Runtimes, Metrik-Propagation in den TrainJob-Status und eine Flux-Framework-Integration. Diese Aufzählung zeigt die Richtung: Die Runtime-Schicht wächst, und der TrainJob bleibt die stabile Schnittstelle darüber.

Installation und die Frage, was im Cluster wirklich landet

Das README verweist für Installation und Einstieg auf die offizielle Dokumentation unter trainer.kubeflow.org/en/latest/getting-started/index.html. Konkrete Befehle, Manifest-Pfade oder Helm-Werte nennt der Repository-Ausschnitt nicht. Wer den Artikel als Installationsanleitung liest, wird enttäuscht. Das ist eine Einschränkung des Materials, keine Aussage über das Projekt. Festhalten lässt sich, dass die Steuerungsebene in Go geschrieben ist und die APIs über Kubernetes-Custom-Resources bereitgestellt werden, was bedeutet, dass ein Controller im Cluster laufen muss und die CRDs installiert sein müssen, bevor ein TrainJob akzeptiert wird. Für Python-Nutzende gibt es das separate Kubeflow SDK, das laut README CustomTrainer, BuiltinTrainer und lokale PyTorch-Ausführung unterstützt. Der praktische Einstieg führt also über zwei Komponenten: den Controller im Cluster und das SDK auf der Entwicklungsmaschine. Wer nur einen einzelnen Job starten will, sollte prüfen, ob das SDK mit lokaler PyTorch-Ausführung nicht der kürzere Weg ist.

Alpha-Status und die zwei Versionslinien

Das README ist an dieser Stelle ungewöhnlich deutlich: Kubeflow Trainer befinde sich im Alpha-Status, und die APIs könnten sich ändern. Gleichzeitig existiert mit Training Operator V1 eine Vorgängergeneration, die von der Kubeflow-Community im Branch release-1.9 weiter gepflegt wird. Die Dokumentation für V1 liegt unter dem Pfad legacy-v1, und für den Umstieg gibt es ein eigenes Migrationsdokument. Das ist der wichtigste begrenzende Faktor des Projekts. Ein Team, das heute einen produktiven Trainingsbetrieb auf V1 aufgebaut hat, muss mit zwei Pfaden leben: dem gepflegten Altbestand und der neuen API, deren Stabilitätszusage fehlt. Die Release-Historie stützt diese Lesart. Innerhalb weniger Monate erschienen v2.0, v2.1, v2.2 und v2.3.0, parallel dazu ein Wartungsrelease v1.9.4. Solche Sprünge sind für frühe Adopter normal, für Teams mit langen Zertifizierungszyklen sind sie ein Planungsrisiko. Wer die Migration von V1 auf die neue API nicht ohnehin vorhat, hat wenig Grund, den Wechsel zu überstürzen.

Wo Kubernetes an die falsche Stelle gerät

Kubeflow Trainer ist kein Werkzeug für jede Trainingsaufgabe. Ein einzelner Trainingslauf auf einer Maschine mit einer GPU gewinnt nichts durch einen Controller, einen Scheduler und eine Runtime-Abstraktion. Der Overhead beginnt bei der Installation der CRDs und endet bei der Fehlersuche, die sich über mehrere Schichten zieht: TrainJob, Runtime, JobSet oder LeaderWorkerSet, Pods, Container. Wenn ein Job nicht startet, muss man wissen, welche dieser Schichten die Ursache meldet. Ein weiterer Grenzfall sind Teams ohne Kubernetes-Betrieb. Das Projekt setzt vorhandene Cluster-Werkzeuge voraus und nennt Integrationen mit Kueue für Topology-aware Scheduling und Multi-Cluster-Dispatching, mit Slurm Bridge für hybride Kubernetes-und-Slurm-Cluster und mit KAI Scheduler für GPU-aware Scheduling. Wer keine dieser Komponenten betreibt, muss sie nicht zwingend einführen, sollte aber bedenken, dass die dokumentierten Pfade für Scheduling und Datenverteilung auf genau diese Nachbarschaft verweisen. Ohne diese Werkzeuge bleibt die Scheduling-Frage offen.

Der Unterschied zu einem einfachen Job-Controller

Die naheliegende Alternative ist ein selbstgebauter Kubernetes-Job plus ein Startskript, das Rank und Master-Adresse über Umgebungsvariablen verteilt. Der Unterschied liegt nicht in der Ausführungsmechanik, sondern in der Zustandsverwaltung. Ein einfacher Job kennt nur Erfolg oder Fehler. Kubeflow Trainer führt mit dem TrainJob-Status ein Objekt, das den Lauf beschreibt, und mit v2.2 kam laut Release Notes die Propagation von Metriken in genau diesen Status. Das verändert, wer einen Lauf beobachten kann: nicht nur die Person, die den Job gestartet hat, sondern jede Rolle mit Lesezugriff auf die Ressource. Der zweite Unterschied ist die Runtime. Ein selbstgebautes Skript verteilt Framework-Wissen über YAML-Dateien und Container-Images. Eine Runtime bündelt dieses Wissen an einer Stelle, die mehrere TrainJobs teilen können. Der Preis dafür ist Bindung: Wer eine Runtime einmal etabliert hat, ändert sie nicht ohne Nebenwirkungen für alle, die sie verwenden. Der dritte Unterschied ist der Distributed Data Cache, der laut README große Datenmengen mit Zero-Copy-Transfer direkt auf GPU-Knoten streamen soll. Ob das im eigenen Cluster trägt, hängt an Speicher- und Netzwerktopologie und lässt sich aus dem Repository-Ausschnitt nicht beurteilen.

Pflegeaufwand, Lizenz und was vor dem Einsatz zu klären ist

Der Pflegeaufwand verteilt sich auf zwei Ebenen. Auf der Cluster-Ebene stehen Controller-Upgrades, CRD-Aktualisierungen und die Kompatibilität mit JobSet, LeaderWorkerSet und dem gewählten Scheduler. Auf der Runtime-Ebene steht die Pflege der eigenen Runtime-Definitionen, sobald diese von den mitgelieferten abweichen. Der Runtime-Snapshot-Mechanismus aus v2.3.0 zielt laut Release Notes darauf, den Runtime-Lebenszyklus zu entkoppeln, was den Upgrade-Pfad für Runtimes vereinfachen soll. Ob das in der Praxis trägt, lässt sich aus dem Material nicht belegen. Die Lizenz ist Apache-2.0. Das erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, verlangt aber die Beibehaltung der Lizenzhinweise und enthält eine ausdrückliche Patentgewährung. Wer modifizierte Versionen weitergibt, muss die Änderungen kennzeichnen. Das ist eine Einordnung, keine Rechtsberatung. Für den Einsatz zuerst zu verifizieren sind drei Dinge: die im eigenen Cluster installierte Runtime-Version, die Kompatibilität des Schedulers mit den verwendeten JobSet- und LeaderWorkerSet-Versionen und der Stand der release-1.9-Branch, falls noch V1-Jobs laufen. Der letzte Punkt ist der wichtigste, weil er bestimmt, ob es zwei Systeme parallel zu betreiben gilt.

Redaktionelles Fazit

Wer bereits Kubernetes betreibt und verteiltes Training über MPI, JobSet oder LeaderWorkerSet steuern will, findet in Kubeflow Trainer eine API, die sich in vorhandene Cluster-Werkzeuge einfügt. Wer kurzfristig ein stabiles Fine-Tuning-Setup braucht, sollte wegen des im README benannten Alpha-Status und der möglichen API-Änderungen die Migration von Training Operator V1 prüfen, bevor der Wechsel geplant wird. Zuerst zu verifizieren sind die Runtime-Version, die im eigenen Cluster tatsächlich installiert ist, und der Stand der release-1.9-Branch für bestehende V1-Jobs.

Offizielle Quellen

1. kubeflow/trainer on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases