Katib : l'AutoML qui vit dans le cluster Kubernetes, pas dans le notebook
Automated Machine Learning on Kubernetes
En bref
- De quoi s’agit-il ?
- Katib transforme la recherche d'hyperparamètres en ressources Kubernetes natives. Le projet est agnostique au framework, mais il déplace le problème : ce n'est plus le code d'entraînement qu'il faut écrire, c'est le manifeste YAML et le TrialTemplate.
- À qui s’adresse-t-il ?
- Katib convient aux équipes qui exécutent déjà leurs entraînements sur Kubernetes et veulent sortir la recherche d'hyperparamètres du poste de travail, avec un contrôle par manifestes et un historique conservé côté cluster. Il ne convient pas à un data scientist seul sur un notebook local, ni à qui veut une optimisation bayésienne fine sans écrire de YAML : le coût d'entrée est réel et le TrialTemplate est le point de friction principal.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 2 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : la recherche d'hyperparamètres coincée dans un notebook
Un entraînement sérieux génère des dizaines, parfois des centaines de configurations à essayer. Lancées à la main, ces tentatives saturent une machine, se perdent entre deux sessions, et personne ne sait plus quelle combinaison a produit quel score. Katib attaque ce point précis : il prend en charge la boucle d'essai-erreur et la délègue au cluster. Le projet se présente comme un composant Kubernetes natif pour l'AutoML, couvrant le réglage d'hyperparamètres, l'arrêt anticipé et la recherche d'architecture neuronale. Le public visé est celui qui a déjà Kubernetes sous la main et qui veut que chaque essai soit une ressource suivie, avec un budget de calcul borné et un résultat stocké. Un data scientist qui travaille seul sur un portable n'a rien à y gagner : il paierait le coût d'un orchestrateur sans en tirer le bénéfice.
Ce que Katib orchestre réellement entre le contrôleur et le TrialTemplate
Le mécanisme repose sur une indirection qui explique à peu près tout le reste. Katib ne sait pas entraîner un modèle. Il sait créer des essais, et chaque essai est décrit par un TrialTemplate : un modèle de ressource Kubernetes que Katib instancie avec les valeurs d'hyperparamètres tirées par l'algorithme. Le README indique que Katib peut exécuter des jobs d'entraînement via n'importe quel Custom Resource Kubernetes, avec un support prêt à l'emploi pour le Kubeflow Training Operator, Argo Workflows et Tekton Pipelines. C'est cette couche qui rend le projet agnostique au framework : TensorFlow, PyTorch, XGBoost ou un script maison écrit dans n'importe quel langage passent par le même chemin, puisque Katib ne voit qu'une ressource à créer et un score à récupérer. La contrepartie est immédiate : tout ce que Katib peut optimiser doit d'abord être exprimable comme une ressource Kubernetes. Un entraînement qui vit dans un notebook sans manifeste n'entre pas dans ce moule sans travail d'adaptation.
Les algorithmes disponibles et les bibliothèques qui les portent
Katib ne réimplémente pas les algorithmes d'optimisation. Il s'appuie sur des bibliothèques existantes : Goptuna, Hyperopt, Optuna et Scikit Optimize, d'après la liste du README. Côté réglage d'hyperparamètres, la documentation couvre la recherche aléatoire, la recherche sur grille, l'optimisation bayésienne, TPE, TPE multivarié, CMA-ES, la suite quasi-aléatoire de Sobol, HyperBand et Population Based Training. Pour la recherche d'architecture neuronale, deux méthodes sont listées : ENAS et DARTS. Pour l'arrêt anticipé, une seule : Median Stop. Ce déséquilibre est instructif. L'arrêt anticipé est souvent ce qui fait gagner le plus de temps en pratique, et Katib n'en documente qu'une règle. Le README renvoie aussi vers un guide pour implémenter un algorithme personnalisé, ce qui est la soupape prévue quand la liste ne suffit pas. Reste que la qualité de l'optimisation dépend des bibliothèques sous-jacentes, pas de Katib lui-même.
Installer le plan de contrôle et le SDK Python
L'installation du plan de contrôle se fait par kustomize, directement depuis le dépôt Git. Le README donne cette commande pour la dernière version stable : kubectl apply -k "github.com/kubeflow/katib.git/manifests/v1beta1/installs/katib-standalone?ref=v0.17.0". Pour suivre les changements en cours, la variante remplace le tag par ref=master. Un détail saute aux yeux : l'exemple du README épingle v0.17.0 alors que la version publiée la plus récente listée est v0.19.0. Il faut donc remplacer le tag soi-même, et éviter master en production. Côté code, Katib fournit un SDK Python publié sur PyPI, installable avec pip install -U kubeflow-katib, présenté comme un moyen de simplifier la création de jobs de réglage pour les data scientists. Les exemples complets d'Expériences se trouvent dans le répertoire examples/v1beta1 du dépôt. Le README renvoie à la documentation Kubeflow pour les prérequis et la procédure détaillée, ce qui signifie que les commandes ci-dessus ne suffisent pas à elles seules à valider un environnement.
La limite structurelle : tout passe par un manifeste
La conception de Katib a un coût assumé. Chaque campagne d'optimisation suppose d'écrire et de maintenir un TrialTemplate, c'est-à-dire un objet Kubernetes paramétré. Ce travail est découplé du code d'entraînement, et il faut le refaire dès que la ressource sous-jacente change. Pour un projet qui itère vite sur la définition même du job, ce détour ralentit. Autre point : Katib n'est pas un outil de suivi d'expériences. Il lance des essais et récupère une métrique objectif, mais la comparaison fine entre runs, les artefacts et la visualisation ne font pas partie de ce que le README décrit. Une équipe qui a besoin d'un registre d'expériences complet devra le coupler à autre chose. Enfin, le projet est explicitement lié à Kubernetes : sans cluster, il n'existe pas. C'est une contrainte d'infrastructure, pas un défaut de conception, mais elle élimine d'emblée une partie des utilisateurs potentiels.
Face à Optuna seul : orchestrateur contre bibliothèque
La comparaison la plus directe est celle avec Optuna utilisé directement dans un script Python. Optuna est une bibliothèque : on l'importe, on définit une fonction objectif, on appelle optimize, et la boucle tourne dans le processus courant. Katib, lui, est un orchestrateur : il crée des ressources Kubernetes, chaque essai devient un job séparé, et la parallélisation vient du cluster plutôt que d'un pool de threads. La différence de nature entraîne une différence d'usage. Avec Optuna seul, l'optimisation vit et meurt avec le script : pas de ressource persistante, pas de reprise après incident intégrée au cluster. Avec Katib, l'essai est un objet suivi par l'API Kubernetes, ce qui permet de le lister, de l'inspecter et de le supprimer avec kubectl. En contrepartie, Optuna ne demande aucune infrastructure et accepte n'importe quelle fonction Python, y compris celles qui ne se décriraient jamais comme un Custom Resource. Le choix se joue donc sur une question simple : l'entraînement est-il déjà une ressource Kubernetes, ou non ?
Maintenance, versionnage et licence
Le rythme de publication observé est régulier : v0.18.0 en mars 2025, v0.19.0 en octobre 2025, avec une release candidate intermédiaire. Le dépôt n'est pas archivé et la branche par défaut est master. Cette régularité implique une charge de mise à jour : les manifestes d'installation sont versionnés par tag, et une montée de version signifie relire les changements avant de remplacer le tag dans la commande kubectl apply -k. Le projet est distribué sous licence Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de copyright et du fichier de licence. Le README affiche aussi une référence OpenSSF Best Practices et un statut FOSSA. Ces éléments indiquent une attention portée à l'hygiène du projet, mais ils ne disent rien de la compatibilité entre deux versions de Katib et un TrialTemplate existant : ce point n'est pas documenté dans le matériel fourni et doit être vérifié au cas par cas.
Conclusion éditoriale
Katib convient aux équipes qui exécutent déjà leurs entraînements sur Kubernetes et veulent sortir la recherche d'hyperparamètres du poste de travail, avec un contrôle par manifestes et un historique conservé côté cluster. Il ne convient pas à un data scientist seul sur un notebook local, ni à qui veut une optimisation bayésienne fine sans écrire de YAML : le coût d'entrée est réel et le TrialTemplate est le point de friction principal. Avant d'adopter, vérifiez trois choses concrètes : la version épinglée dans votre commande kubectl apply -k (le README illustre avec ref=v0.17.0 alors que v0.19.0 est publiée), la compatibilité de votre TrialTemplate avec le Custom Resource que vous utilisez déjà, et la disponibilité de l'algorithme souhaité dans la liste documentée. Si votre entraînement ne se décrit pas comme une ressource Kubernetes, Katib n'est pas le bon outil.
Notes de la communauté