Katib: Hyperparameter-Suche als Kubernetes-Ressource

Welches Problem Katib löst und für wen

Hyperparameter-Suche ist ein Schleifenproblem. Ein Trainingslauf startet, liefert eine Metrik, der nächste Lauf bekommt andere Werte, und irgendwo dazwischen muss jemand entscheiden, wann abgebrochen wird. Solange das auf einem Rechner im Notebook passiert, ist die Schleife harmlos. Sobald die Läufe auf einem Cluster verteilt sind, verteilen sich auch die Aufgaben: Jobs anlegen, Metriken einsammeln, schlechte Läufe stoppen, Ergebnisse zusammenführen. Genau diese Verwaltungsarbeit nimmt Katib ab.

Die Zielgruppe sind laut Repository Teams, die Trainingsjobs als Kubernetes-Custom-Resources ausführen. Das README beschreibt Katib als framework-agnostisch: getunt werden können Anwendungen in jeder Sprache, solange sie sich als Kubernetes-Job starten lassen und eine Metrik berichten. Nativ genannt werden TensorFlow, PyTorch und XGBoost, die Themenliste des Repositories führt zusätzlich scikit-learn und JAX. Wer seine Trainingsjobs dagegen lokal oder auf einem einzelnen GPU-Rechner startet, gewinnt durch Katib nichts und zahlt den Preis einer Control Plane.

Experiment, Suggestion und Trial: der Ablauf im Cluster

Katib führt die Suche nicht in einem eigenen Prozess, sondern als Zusammenspiel mehrerer Kubernetes-Objekte. Ein Experiment beschreibt den Suchraum, das Ziel und die Anzahl der Versuche. Der Katib-Controller erzeugt daraus Trials, also einzelne Läufe mit konkreten Hyperparameter-Werten. Welche Werte ein Trial bekommt, entscheidet die Suggestion-Komponente, die einen Suchalgorithmus ausführt.

Der Trainingsjob selbst läuft nicht im Katib-Controller, sondern in einem Trial-Template. Das Repository verlinkt dazu die Dokumentation unter dem Pfad trial-template und nennt Unterstützung für den Kubeflow Training Operator, Argo Workflows und Tekton Pipelines. Ein Trial ist damit ein Platzhalter: Katib füllt die vorgeschlagenen Werte in das Template ein, startet die darin definierte Ressource und liest anschließend die Metrik zurück. Diese Trennung ist der eigentliche Entwurf von Katib. Der Controller muss nichts über Frameworks wissen, nur über das Template und den Pfad zur Metrik.

Wie die Metrik zurückkommt, lässt sich aus dem Repository allein nicht vollständig rekonstruieren. Die Dokumentation verweist auf Metrik-Collector-Konfiguration und auf Standardausgabe als Quelle. Wer ein eigenes Template baut, sollte diesen Punkt zuerst klären, weil daran hängt, ob Katib einen Lauf überhaupt bewerten kann.

Suchalgorithmen und die vier Backend-Bibliotheken

Katib bringt mehrere Suchverfahren mit. Für Hyperparameter-Tuning listet das README Random Search, Grid Search, Bayesian Optimization, TPE, Multivariate TPE, CMA-ES, Sobol's Quasirandom Sequence, HyperBand und Population Based Training. Für Neural Architecture Search stehen ENAS und DARTS bereit, für Early Stopping die Median Stopping Rule. Das ist eine breite Auswahl, und sie ist nicht dekorativ: Grid Search und Bayesian Optimization verhalten sich bei hoher Dimension sehr unterschiedlich, und die Wahl bestimmt, wie viele Trials nötig sind.

Ausgeführt werden diese Verfahren nicht von Katib selbst, sondern von vier Bibliotheken: Goptuna, Hyperopt, Optuna und Scikit Optimize. Welcher Algorithmus auf welcher Bibliothek aufsetzt, geht aus dem README nicht hervor. Wer einen bestimmten Algorithmus braucht, muss das in der Kubeflow-Dokumentation nachschlagen, bevor er das Experiment schreibt. Ein eigenes Verfahren lässt sich ebenfalls einbinden; das README verlinkt dazu einen Abschnitt über Custom Algorithm in Katib.

Bemerkenswert ist die Kombination aus HyperBand und Population Based Training. Beide verändern laufende Trials, statt nur neue Werte vorzuschlagen. Das erklärt, warum Early Stopping in Katib eine eigene Kategorie ist und nicht nur ein Abbruchkriterium am Rand.

Installation: zwei Befehle und ein Versionsdetail

Die Control Plane kommt über Kustomize in den Cluster. Das README nennt für die stabile Version:

kubectl apply -k "github.com/kubeflow/katib.git/manifests/v1beta1/installs/katib-standalone?ref=v0.17.0"

und für den aktuellen Stand des master-Branches denselben Pfad mit ref=master. Auffällig: Der Beispielbefehl zeigt auf v0.17.0, während die letzten Releases v0.18.0 und v0.19.0 sind. Wer den Befehl unverändert übernimmt, installiert nicht die neueste Version, sondern eine ältere. Das ist kein Fehler im Projekt, aber ein Detail, das man beim Kopieren sehen sollte.

Für Data Scientists gibt es zusätzlich ein Python-SDK, installierbar mit:

pip install -U kubeflow-katib

Das SDK erzeugt die Experiment-Objekte, ersetzt aber nicht die Control Plane. Beides gehört zusammen: ohne installierte CRDs im Cluster läuft das SDK ins Leere. Vollständige Beispiele für Experimente liegen laut README unter examples/v1beta1. Die Voraussetzungen und die Detailanleitung verweisen auf die Kubeflow-Dokumentation, das README selbst wiederholt sie nicht.

Wo Katib die falsche Wahl ist

Katib setzt voraus, dass jeder Trainingslauf ein Kubernetes-Objekt ist. Das ist eine harte Grenze. Ein Modell, das nur wenige Minuten trainiert, verliert durch Pod-Start, Image-Pull und Metrik-Rückweg mehr Zeit, als die Suche einspart. In solchen Fällen ist ein einfacher Python-Loop mit Optuna oder Hyperopt direkt im Prozess schneller, weil jede Trial-Iteration nur ein Funktionsaufruf ist.

Auch für interaktive Arbeit ist Katib schwerfällig. Die Suche läuft asynchron über den Controller. Wer während der Suche Parameter ändern, einen Lauf inspizieren und sofort neu starten will, arbeitet gegen das Modell von Experiment und Trial. Ein weiterer Punkt: Katib ist nicht das Werkzeug für verteiltes Training selbst. Es startet Jobs, es trainiert nicht. Wer Datenparallelität über mehrere GPUs braucht, muss das im Trial-Template lösen, etwa über den Kubeflow Training Operator.

Schließlich die Abhängigkeit von der Control Plane. Fällt der Katib-Controller aus, laufen Trials weiter, aber es werden keine neuen vorgeschlagen und keine Ergebnisse eingesammelt. Das ist ein zusätzlicher Dienst, der betrieben werden will.

Was Katib von einem lokalen Tuning-Skript unterscheidet

Der naheliegende Vergleich ist ein Skript, das Optuna direkt aufruft. Beide nutzen teilweise dieselben Bibliotheken, was den Unterschied umso deutlicher macht. Ein Optuna-Skript lebt in einem Prozess: Suchraum, Trainingsfunktion, Auswertung, alles im selben Speicher. Der Zustand liegt in einer lokalen Datenbank, der Abbruch ist ein Return-Statement.

Katib trennt genau diese Teile. Der Suchraum steht in einem Experiment, die Trainingsfunktion in einem Trial-Template, die Auswertung im Controller. Das kostet Latenz und verlangt mehr YAML. Es bringt zwei Dinge, die ein Skript nicht hat: Trials laufen unabhängig voneinander und überleben den Absturz des aufrufenden Rechners, und mehrere Personen können denselben Suchlauf beobachten, ohne dass ein Notebook geöffnet bleiben muss.

Wer diesen Unterschied nicht braucht, sollte beim Skript bleiben. Der Wechsel lohnt sich, wenn die Anzahl der Trials so groß wird, dass ein einzelner Rechner sie nicht mehr in vertretbarer Zeit abarbeitet, oder wenn die Läufe ohnehin schon als Cluster-Jobs existieren.

Wartung, Versionen und Lizenz

Die Release-Historie zeigt zwei bis drei Veröffentlichungen pro Jahr, mit v0.18.0 im März 2025 und v0.19.0 im Oktober 2025. Das ist ein ruhiger, aber nicht eingefrorener Rhythmus. Die letzte Push-Aktivität auf dem master-Branch datiert auf September 2026, das Repository ist nicht archiviert. Für ein Projekt, das als Teil von Kubeflow gepflegt wird, ist das ein normaler Zustand.

Für den Betrieb heißt das: Die Katib-CRDs sind clusterweit. Ein Upgrade der Control Plane muss mit der vorhandenen Kubeflow-Version abgestimmt werden, weil beide dieselben CRDs berühren können. Wer den master-Branch installiert, bekommt unveröffentlichte Änderungen; das README bietet diesen Pfad ausdrücklich an, empfiehlt ihn aber nicht als Standard.

Die Lizenz ist Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung und Modifikation und verlangt, dass Änderungen an den lizenzierten Dateien kenntlich gemacht werden. Wer Katib als Bestandteil eines eigenen Produkts ausliefert, sollte die Hinweispflichten prüfen. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Lizenzangabe im Repository zu den Pflichten führt, die man im eigenen Build-Prozess abbilden muss.

Für wen sich der Einstieg lohnt

Katib passt zu Plattform-Teams, die Kubernetes bereits für Trainingsjobs nutzen und die Suche als weiteren Ressourcentyp in dieser Umgebung betreiben wollen. Es passt zu Fällen, in denen Trials über Stunden laufen, die Anzahl der Versuche groß ist und mehrere Personen die Ergebnisse sehen sollen. Die Bandbreite an Algorithmen und die vier Backend-Bibliotheken decken die gängigen Suchverfahren ab, ohne dass man sie selbst implementieren muss.

Es passt nicht zu einzelnen Notebook-Läufen, zu kurzen Trainingszeiten und zu Teams ohne Kubernetes-Betriebserfahrung. Der Preis ist eine zusätzliche Control Plane mit eigenen CRDs, die aktualisiert und mit der restlichen Kubeflow-Installation synchron gehalten werden muss.

Vor dem ersten eigenen Experiment sind drei Dinge zu klären: ob das Trial-Template zum vorhandenen Trainingsjob passt, wie die Metrik aus dem Job zurückgelesen wird, und ob die installierte Katib-Version zu den CRDs im Cluster passt. Der Beispielbefehl im README zeigt auf v0.17.0, obwohl v0.19.0 verfügbar ist. Diese Abweichung ist der erste Punkt, der beim Kopieren auffällt.

Redaktionelles Fazit

Wer Trainingsjobs bereits als Kubernetes-Ressourcen betreibt, kann Katib ohne neue Infrastruktur einsetzen. Für einzelne Notebook-Läufe, die eine Person interaktiv steuert, ist der Umweg über Pods und Controller zu schwer. Vor dem Rollout im eigenen Cluster ist zu klären, ob das Trial-Template zum eigenen Trainingsjob passt und ob die Katib-CRDs mit der vorhandenen Kubeflow-Version zusammenpassen.

Offizielle Quellen

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