Kubeflow est la plate-forme MLOps open source de Google fonctionnant sur Kubernetes, couvrant l'ensemble du processus de préparation des données, de formation des modèles, de réglage et de déploiement d'inférence.

Kubeflow

Kubeflow’s core parameters and statistics

Kubeflow n'est pas une application unique, mais un ensemble de composants natifs Kubernetes : chaque sous-projet évolue indépendamment et est assemblé en une plate-forme complète via une distribution communautaire Kubeflow (KCD) unifiée. Cette architecture « de base » détermine que les limites de ses capacités dépendent des composants que vous assemblez, plutôt que d'un certain numéro de version qui indique tout.

Projets	Informations publiques
Positionnement officiel	AI platform tool base layer on Kubernetes
Core sub-projects (sorted by GitHub Stars)	Kubeflow Pipelines (4,2k ★), Spark Operator (3,1k ★), Kubeflow Trainer/Training Operator (2,2k ★), Katib AutoML (1,7k ★), Kubeflow Hub/Model Registry (176 ★), Notebooks (74 ★), Central Dashboard (16 ★)
Infrastructure dependencies	Kubernetes 1.25+ (required)
Licence Open Source	Apache2.0
CNCF Maturity	Incubating Projects (Incubating)
Lieu de résidence	États-Unis (US)
Cross-project GitHub Stars	33.1k+ (including all sub-projects)
Contributors across projects	3,000+
PyPI cumulative downloads	258 million+
Number of GitHub releases	94 times (main repository)
Utilisateurs cibles	Équipes Enterprise ML/Platform avec la fondation Kubernetes
Méthode de déploiement	Auto-hébergé (prend en charge les K8 nus, GKE, EKS, AKS, etc.)

Différence fondamentale : La différence de Kubeflow réside dans le « mappage des workflows ML dans les ressources natives Kubernetes » : chaque tâche de formation est une tâche K8s, chaque point de terminaison d'inférence est un service K8s, chaque paramètre expérimental est géré via ConfigMap/CRD, et la surveillance et les journaux réutilisent directement les outils écologiques K8 tels que Prometheus et Fluentd.

User and market recognition of Kubeflow

Kubeflow est le projet open source MLOps avec la couverture la plus large de l'écosystème Kubernetes. Sa reconnaissance sur le marché se reflète dans les trois dimensions que sont l'activité communautaire, l'adoption par les entreprises et l'intégration des fournisseurs de cloud.

Taille de la communauté : à la mi-2026, le nombre total d'étoiles multi-projets Kubeflow sur GitHub dépassait 33,1 000 et le nombre de contributeurs dépassait 3 000. Le référentiel principal compte 15,8 000 étoiles, 2,7 000 Forks et le sous-projet Pipelines compte 4,2 000 étoiles, ce qui indique que la communauté non seulement prête attention au concept de Kubeflow, mais approfondit également l'utilisation et la contribution de composants spécifiques. PyPI a été téléchargé 258 millions de fois au total, ce qui reflète la profondeur de la pénétration de son SDK dans l'écosystème Python.

Adoption par les entreprises : les clients de confiance affichés sur le site officiel de Kubeflow incluent les principaux fournisseurs de cloud tels qu'AWS, Oracle et Red Hat. Les entreprises adoptantes répertoriées dans le fichier GitHub ADOPTERS.md couvrent les secteurs de la finance, de la technologie, de la fabrication, des télécommunications et d'autres secteurs. La partie sous-jacente de Vertex AI de Google Cloud s'appuie sur le concept de conception de Kubeflow ; AWS fournit une solution de déploiement hybride SageMaker basée sur Kubeflow ; La fonctionnalité MLOps d'Azure est également profondément intégrée à Kubeflow Pipelines.

Position écologique du CNCF : En tant que projet de niveau incubation du CNCF, Kubeflow a passé avec succès l'évaluation de maturité du TOC mais n'est pas encore entré dans la phase d'obtention du diplôme. Cela signifie que la stabilité de son API et sa maturité en matière de gouvernance ont atteint les normes CNCF, mais la cadence de versions indépendantes de certains sous-projets peut conduire à une complexité globale de déploiement plus élevée.

Référence d'évaluation de l'industrie : dans les comparaisons de plates-formes MLOps tierces, Kubeflow est généralement en avance sur MLflow (manque d'intégration native de K8) et SageMaker (verrouillage à source fermée) dans les dimensions de « l'open source » et de la « natif de K8 », mais est en retard sur les services gérés en termes de « convivialité prête à l'emploi ». Les rapports MLOps d'analystes tels que Gartner citent souvent Kubeflow comme implémentation de référence représentative du MLOps open source.

Avantage financier de Kubeflow

La structure de coûts de Kubeflow se compose de trois niveaux : « open source sans frais de licence + infrastructure à votre charge + investissement en main-d'œuvre d'exploitation et de maintenance », ce qui est essentiellement différent du modèle de coût d'une plate-forme SaaS MLOps hébergée.

Côté C/Utilisateurs individuels : Kubeflow n'a pas de version SaaS pour les data scientists indépendants. Les utilisateurs individuels doivent créer leur propre environnement Kubernetes (Minikube, Kind ou quota gratuit des fournisseurs de cloud) pour découvrir Kubeflow. En mode Minikube, un seul nœud peut exécuter certains composants, mais la fonctionnalité complète nécessite un cluster multi-nœuds. Pour les apprenants individuels, le coût en temps (2 à 8 heures pour la création du contexte) est beaucoup plus élevé que le modèle d'inscription et d'utilisation des outils SaaS.

Développeurs/utilisateurs d'API : Kubeflow fournit le SDK Python (kfp) pour la programmation de pipeline. Le SDK lui-même est gratuit, mais l'exécution de Pipeline nécessite un cluster backend K8s. Les développeurs peuvent utiliser Vertex AI Pipelines de Google Cloud (compatible avec le SDK Kubeflow Pipelines) pour exécuter des workflows sur une base de paiement à l'utilisation sans créer de cluster auto-construit. Il s'agit actuellement du portail de développement Kubeflow le plus économique. La facturation est basée sur le nombre d'exécutions et les ressources informatiques. Le coût d’une seule expérience varie de quelques yuans à plusieurs centaines de yuans.

Déploiements d'entreprise/privés : il s'agit du principal scénario de coûts pour Kubeflow. Les coûts se répartissent comme suit :

Élément de coût	Plage d'estimation	Descriptif
Licence de plateforme	0 yuan	Apache 2.0 open source, sans frais de licence
Cluster K8s (niveau production)	3 000 à 30 000 yuans/mois	3-10 nœuds, constructeur Evian et configuration flottante
Puissance de calcul GPU	5-50 yuans/carte/heure	Prix ​​à la demande A100/H100, les instances réservées peuvent être réduites de 30 à 50 %
Main d'œuvre d'exploitation et de maintenance	0,5-2 personnes/an	Le coût du personnel d'exploitation et de maintenance combiné avec les K8 + ML est supérieur à celui de l'exploitation et de la maintenance des K8 purs
Stockage et réseau	500 à 5 000 yuans/mois	Stockage PVC, stockage de produits modèles, trafic interrégional

Déduction de comparaison des coûts : en prenant comme exemple une équipe ML de 10 personnes avec une moyenne de 200 heures de formation GPU par mois, le coût total de possession annuel d'un Kubeflow auto-construit est d'environ 300 000 à 800 000 yuans (y compris le partage de la main d'œuvre d'exploitation et de maintenance), tandis que les frais annuels pour une plate-forme MLOps gérée de la même échelle sont d'environ 500 000 à 1,5 million de yuans. Les avantages de Kubeflow sont encore plus évidents à grande échelle : une fois que le nombre de nœuds dépasse 20, le coût marginal ne représente plus que 40 à 60 % de la solution d'hébergement. Cependant, le cycle de construction initial (2 à 4 semaines) ainsi que la complexité de l’exploitation et de la maintenance constituent des coûts cachés. L'équipe a besoin d'au moins un ingénieur familier avec les K8 et capable de résoudre les problèmes de compatibilité des composants Kubeflow.

Principales fonctions de Kubeflow

La fonctionnalité de Kubeflow consiste en un ensemble de sous-projets indépendants, chacun se concentrant sur une section du cycle de vie du ML. Voici les principaux composants fonctionnels et leurs relations de synergie :

• Kubeflow Pipelines (KFP) : moteur de workflow Visual DAG, pipeline de prétraitement des données série → formation → évaluation → déploiement. Vue d'expert : la vraie valeur de KFP n'est pas seulement de « dessiner un organigramme », mais il permet de définir le pipeline comme un Python DSL (Kfp SDK), et le compilateur génère un YAML IR (représentation intermédiaire) pour obtenir un découplage contextuel de la définition et de l'exécution du pipeline. Cela signifie que la même définition de pipeline peut être migrée de manière transparente entre les K8 locaux, GKE et EKS, résolvant ainsi le principal problème d'incohérence entre le développement et la production de ML.

• Recherche automatisée d'hyperparamètres Katib et NAS : Le moteur AutoML basé sur Kubernetes CRD prend en charge trois algorithmes de recherche : Recherche par grille, Recherche aléatoire et Optimisation bayésienne, ainsi que la stratégie d'arrêt anticipé. Lien caché : Katib peut appeler directement Kubeflow Pipelines comme moteur d'exécution d'expérience, et chaque combinaison d'hyperparamètres est exécutée en tant que Pipeline Run - cela signifie que les résultats de la recherche d'hyperparamètres portent automatiquement le lien expérimental complet (version des données, version du code, indicateur), sans association manuelle.

• Kubeflow Trainer (Training Operator) : opérateur de formation distribué, prend en charge nativement PyTorch, TensorFlow, MPI, XGBoost, MXNet et d'autres frameworks. Prise en charge étendue du réglage fin LLM pour HuggingFace, DeepSpeed, Megatron, MLX, JAX dans la version 1.9. Perspective d'ingénierie : les abstractions de base de Training Operator sont des CRD tels que PyTorchJob et TFJob, qui encapsulent la logique de déploiement de la topologie de formation distribuée (Worker/PS/Chief) dans les définitions de ressources K8. Les utilisateurs doivent uniquement spécifier le nombre de copies et de miroirs pour démarrer la formation distribuée, sans avoir besoin d'écrire manuellement des configurations complexes de StatefulSet et de service K8.

• KServe (Inference Service) : une plate-forme d'inférence de modèles hautes performances évoluée indépendamment qui prend en charge le déploiement automatique de TensorFlow, PyTorch, ONNX, Scikit-learn, XGBoost et d'autres formats. Fournit des fonctionnalités de niveau production telles que la mise à l'échelle élastique (basée sur Knative), les tests A/B, la version Canary et les journaux de requêtes. Valeur collaborative : une fois KServe lié à Kubeflow Pipelines, la fermeture CI/CD du « déclenchement automatique de la mise à jour du service d'inférence à la fin de la formation » peut être obtenue : la dernière étape du pipeline appelle l'API KServe pour mettre à jour le point de terminaison d'inférence afin d'obtenir une automatisation de bout en bout.

• Kubeflow Notebooks : un service d'hébergement qui exécute Jupyter Notebook dans un cluster K8s, prenant en charge l'accélération GPU isolée multi-tenant et la mise en miroir personnalisée. Chaque instance de Notebook est un pod K8 indépendant et les utilisateurs peuvent choisir différentes images (PyTorch, TensorFlow, langage R, etc.) et spécifications de ressources. Conseils de mise en œuvre : la liaison entre Notebooks, Katib et Pipelines est un chemin à haute fréquence : une fois que les utilisateurs ont terminé l'exploration des données et les expériences de prototypes dans Notebooks, ils peuvent exporter le code en tant que composant Pipeline en un seul clic, puis le soumettre en tant que tâche de formation planifiée.

• Kubeflow Hub (Model Registry) : centre de gestion des métadonnées du modèle, qui stocke la version du modèle, l'exécution du pipeline source, les indicateurs d'évaluation, l'état du déploiement et d'autres informations. Il comble le fossé de suivi entre les expériences (Pipelines + Katib) et la production (KServe), permettant aux équipes de plateforme de voir clairement « quelle version de modèle de quelle expérience est actuellement utilisée en production ».

• Central Dashboard : Console de gestion unifiée qui intègre l'interface Web de tous les sous-projets. Fournit la gestion des autorisations RBAC, l’isolation des espaces de noms multi-locataires et les portails de surveillance des ressources du cluster. Pour les administrateurs de plateforme, Dashboard constitue l’entrée principale pour l’exploitation et la maintenance quotidiennes.

Synergie entre les fonctions : Les composants de Kubeflow ne sont pas des fonctions isolées, mais forment un lien complet de "Expérience Notebook → Formation à l'orchestration de pipeline → Optimisation des hyperparamètres Katib → Enregistrement du modèle Hub → Déploiement d'inférence KServe → Retour de surveillance Prometheus". Un scénario fermé typique : le data scientist débogue le modèle dans Notebook et, une fois satisfait, encapsule le code dans un composant Pipeline, recherche les meilleurs hyperparamètres via Katib et le meilleur modèle est automatiquement enregistré dans le Hub. Le Hub déclenche KServe pour mettre à jour le point de terminaison d'inférence, et les indicateurs de latence et de débit du service d'inférence sont collectés par Prometheus et affichés dans le tableau de bord.

Modèle Kubeflow et évolution des versions

En tant qu'ensemble de projets, le système de numéro de version de Kubeflow a évolué de « version unifiée » à « version indépendante de sous-projet + version communautaire ». Le numéro de version actuel du référentiel principal (tel que 1.9) correspond à la version de Kubeflow Community Distribution (KCD), et non à la version d'un certain sous-projet.

Première étape : version unifiée (2018-2021)

• Kubeflow 0.1 (2018-03) : première version open source, les fonctionnalités de base sont limitées à l'exécution de tâches TensorFlow sur les K8. A cette époque, le projet se positionnait comme « TensorFlow sur Kubernetes ».
• Kubeflow 0.2 (2018-06) : introduction de la prise en charge de Jupyter Notebook, étendue au framework PyTorch.
• Kubeflow 1.0 (2020-03) : version marquante marquant l'engagement en matière de stabilité de l'API. Contient des versions préliminaires de Pipelines, Katib, Notebooks et KFServing. Le CNCF a été accepté comme projet d'incubation la même année.
• Kubeflow 1.1-1.3 (2020-2021) : focus sur le RBAC multi-tenant, l'intégration d'Istio et les améliorations fonctionnelles au niveau de l'entreprise.

Découplage des composants et évolution indépendante (2021-2024)

• Kubeflow 1.4-1.5 (2021-2022) : KFServing évolue vers un projet indépendant KServe pour accélérer le cycle de publication indépendant. Training Operator est séparé du référentiel principal. Pipelines v2 commence l'aperçu technologique.
• Kubeflow 1.6-1.7 (2022-2024) : Pipelines v2 GA, introduisant une représentation intermédiaire IR et une définition plus flexible des composants. Katib ajoute la prise en charge de Neural Architecture Search. La distribution communautaire (KCD) est officiellement devenue la méthode de déploiement recommandée.
• Kubeflow 1.8 (~2025-06, pas encore de date officielle précise) : amélioration de l'observabilité de Pipeline et de la stratégie de planification GPU. Trainer ajoute la prise en charge native de HuggingFace Accelerate.

Dernière phase : prise en charge du LLM et de GenAI (2025-présent)

• Kubeflow 1.9 (~ 2026-03, pas encore de date officielle précise) : Focus sur l'amélioration de la prise en charge de la charge de travail de formation LLM - Kubeflow Trainer ajoute la prise en charge de la formation distribuée pour DeepSpeed, Megatron, MLX et JAX ; Katib ajoute des modèles de recherche d'hyperparamètres LLM (recherche de classement LoRA, etc.) ; KServe améliore l'expérience de déploiement des frameworks d'inférence LLM tels que vLLM et TGI.

Statut de la version indépendante du sous-projet

Sous-projets	Versions autonomes	Étoiles GitHub	Descriptif
Pipelines Kubeflow	v2.x (autonome)	4,2k ★	KFP v2 est le pilote IR YAML principal actuel
KServe	v0.13+ (autonome)	3,9k ★ (dépôt autonome)	Séparé du référentiel principal Kubeflow
Katib	v0.16+ (indépendant)	1,7k ★	Itération continue, découplée de la version Kubeflow
Opérateur d'étincelles	v1.x (autonome)	3,1k ★	Pour Spark sur les charges de travail K8
Opérateur de formation	v1.7+ (autonome)	2,2k ★	Couvre le poste de formateur et MPI

Conseil de compatibilité des versions : La version du sous-projet intégrée par Kubeflow 1.9 KCD peut ne pas être la dernière version de chaque sous-projet. Lors du déploiement réel, il est recommandé de vérifier les notes de version de chaque sous-projet séparément pour confirmer la matrice de compatibilité des versions. Le document officiel fournit un tableau de compatibilité, mais il y a un décalage de mise à jour. Le lien complet doit être vérifié dans l’environnement de test avant le déploiement en production.

Avantages techniques de Kubeflow

Les avantages techniques de Kubeflow résident dans sa profonde adaptation au modèle de ressources natif de Kubernetes, plutôt que dans la construction d'une autre couche abstraite au-dessus des K8.

Conception architecturale basée sur Kubernetes CRD : chaque fonctionnalité principale de Kubeflow est définie par une définition de ressource personnalisée (CRD). En prenant l'opérateur de formation comme exemple, le CRD PyTorchJob définit l'état souhaité de la formation distribuée (nombre de Workers, PS, miroirs, quotas de ressources). Le contrôleur de Kubeflow surveille les modifications CRD et les rapproche de l'état réel. L'avantage de cette conception est que les processus « kubectl » et GitOps que les utilisateurs connaissent déjà peuvent être utilisés directement pour la gestion de la charge de travail ML sans avoir à apprendre une CLI de plate-forme supplémentaire. kubectl apply -f pytorchjob.yaml lancera la formation distribuée.

Assemblage au niveau des composants : Kubeflow ne force pas le déploiement complet. L'équipe de la plateforme peut choisir de déployer uniquement Pipelines + KServe, ou uniquement Katib + Trainer, ou même de développer des Kubeflow Notebooks de manière indépendante en tant qu'environnement de développement d'équipe. Cette flexibilité vient du fait que chaque sous-projet est une combinaison indépendante de Controller + CRD + Web UI, et que les composants communiquent via le service K8s standard et ConfigMap, sans aucune dépendance matérielle.

Pipeline IR (Intermediate Representation) : Le mécanisme IR introduit par KFP v2 est une innovation technologique clé. Il compile la définition du Pipeline dans une représentation intermédiaire YAML indépendante du contexte d'exécution spécifique, puis l'interprète et l'exécute sur le cluster cible par le moteur d'exécution (Dag Runner). Cela signifie que la même définition de pipeline peut être transplantée entre des clusters de test, des clusters de production et même des services K8 de différents fournisseurs de cloud, résolvant ainsi le problème classique du workflow ML « il peut s'exécuter lorsqu'il est développé mais ne peut pas s'exécuter lorsqu'il est produit ».

Intégration naturelle avec les outils écologiques K8s : Le modèle de ressource de Kubeflow étant une ressource K8s standard, l'ensemble de l'écosystème K8s peut être réutilisé à un coût nul : Prometheus collecte des indicateurs de suivi pour la formation et l'inférence ; EFK/Loki collecte les journaux du Pod ; Argo CD implémente la synchronisation GitOps définie par Pipeline ; Velero sauvegarde les données CRD et PVC. En revanche, les plates-formes MLOps non natives K8 doivent implémenter ou intégrer elles-mêmes ces capacités d’infrastructure.

Planification GPU et isolation des ressources : Kubeflow utilise la gestion des ressources des nœuds de Kubernetes et des planificateurs étendus tels que Volcano/Scheduler pour obtenir une allocation et une isolation fines des ressources GPU. Les expériences simultanées de Katib peuvent limiter la limite supérieure du GPU de chaque expérience via ResourceQuota de K8 pour empêcher un certain ensemble de recherches d'hyperparamètres d'épuiser la puissance de calcul du cluster. Dans un scénario multi-tenant, l'isolation des ressources et la gestion des quotas entre les équipes sont réalisées via K8s Namespace + RBAC.

Capacité d'adaptation de la formation LLM : En version 1.9, Kubeflow Trainer peut orchestrer des centaines de cartes de formation distribuée LLM sur K8 en intégrant les scripts de lancement de DeepSpeed ​​​​et Megatron. L'idée principale est d'encapsuler la commande de démarrage « deepspeed » de DeepSpeed ​​comme point d'entrée du travail K8 et d'utiliser le CRD de l'opérateur de formation pour gérer la topologie Worker-PS afin d'obtenir une planification élastique et une récupération des erreurs des tâches de formation.

Comment utiliser Kubeflow

Le chemin de déploiement de Kubeflow varie en fonction de la taille de l'équipe et des scénarios. De l’apprentissage autonome au déploiement multicluster au niveau de la production, voici les méthodes les plus couramment utilisées :

Méthode de déploiement	Scénarios applicables	Complexité	Typiquement fastidieux
Distribution communautaire Kubeflow (KCD)	Déploiement complet au niveau de la production	Moyen-Haut	1-3 jours
Fournisseur d'hébergement cloud Distribution (GKE/EKS/AKS)	Contexte d'intégration cloud profond	Moyen	2-8 heures
Déploiement local Kind/Minikube	Apprentissage personnel et vérification de prototypes	Faible	30 minutes-2 heures
Déploiement indépendant du sous-projet (par exemple, pipelines uniquement)	Exigences légères	Faible-moyen	1-4 heures

Déploiement rapide KCD (recommandé pour la production) :

Kubeflow Community Distribution est actuellement la méthode de déploiement de production officiellement recommandée. Les étapes générales sont les suivantes :

1. Préparez le cluster Kubernetes (1.25+) et assurez-vous qu'il dispose de suffisamment de ressources CPU/GPU et de classes de stockage.
2. Téléchargez le manifeste KCD pour votre version K8 cible à partir de la page officielle de Kubeflow GitHub Release.
3. Installez le manifeste KCD : kubectl apply -k https://github.com/kubeflow/kcd/... (pour les chemins spécifiques, veuillez vous référer à la documentation officielle).
4. Configurez Ingress/Gateway (KCD utilise Istio comme passerelle de trafic nord-sud par défaut).
5. Accédez à l'interface utilisateur Web via l'adresse NodePort ou LoadBalancer du tableau de bord central.
6. Créez une instance de Notebook ou soumettez le premier pipeline via le SDK kfp.

Exemple rapide de soumission de pipelines à l'aide du SDK kfp :

# Installer le SDK : pip install kfp
importerkfp
à partir de kfp importer DSL

@dsl.composant
def train_op (époques : int, lr : float) -> str :
    importer json
    # La logique de formation est exécutée ici
    métriques = {"précision": 0,95, "perte": 0,05}
    renvoyer json.dumps (métriques)

@dsl.pipeline(name="training-pipeline")
def training_pipeline (époques : int = 10, lr : float = 0,001) :
    train_task = train_op (époques = époques, lr = lr)

# Compiler et soumettre
kfp_client = kfp.Client(host="<YOUR_KUBEFLOW_HOST>")
run = kfp_client.create_run_from_pipeline_func(
    pipeline_de formation,
    arguments={"époques": 20, "lr": 0,0001},
    experience_name="mon-expérience"
)

Vérifier le déploiement : une fois le déploiement terminé, confirmez l'état de chaque composant via le tableau de bord. Utilisez kubectl get pods -n kubeflow pour vérifier si le pod principal est en cours d'exécution ; exécutez un exemple de pipeline via le menu « Pipeline » du tableau de bord pour vérifier le lien de bout en bout.

Points d'exploitation et de maintenance : les journaux des composants de Kubeflow sont vérifiés via les « journaux kubectl » ou collectés sur une plate-forme de journalisation centralisée ; si l'exécution du pipeline échoue, vérifiez d'abord l'événement Pod (kubectl décrire pod) et l'état Workflow CRD de KFP (kubectl get workflow).

Tarification des produits Kubeflow

Kubeflow lui-même est un logiciel d'infrastructure 100 % open source et gratuit, mais « gratuit » est limité au niveau de la licence logicielle. Le coût réel de mise en œuvre comprend les trois niveaux suivants :

Client C/utilisateurs individuels : Kubeflow n'a pas de version SaaS pour les particuliers. Pour un apprentissage personnel, vous pouvez créer un déploiement minimal via Minikube ou un quota gratuit auprès des fournisseurs de cloud. Le coût mensuel d'un déploiement Minikube typique à nœud unique est d'environ 0 à 30 USD (en fonction de la politique de quota gratuit du fournisseur de cloud), mais le maintien d'un environnement Kubeflow stable et disponible nécessite une certaine expérience d'exploitation de K8 - il s'agit d'un « coût en temps » implicite pour les développeurs indépendants.

Niveau d'appel développeur/API : le SDK kfp et la CLI kfctl sont entièrement gratuits. Mais chaque exécution de Pipeline consomme les ressources du cluster K8. Trois options économiques : (1) Local Minikube mène des expériences à petite échelle avec un coût nul mais une puissance de calcul limitée ; (2) Utilisez Google Cloud Vertex AI Pipelines (compatible avec le SDK KFP), facturé en fonction du nombre d'exécutions et de ressources. Le coût unique des expériences à petite échelle est d'environ 5 à 50 yuans ; (3) De petits clusters auto-construits (3 nœuds) exécutent des charges de travail de développement et le coût mensuel de l'infrastructure est d'environ 2 000 à 5 000 yuans.

Déploiements d'entreprise/privés : il n'y a aucun frais de licence logicielle, mais en fonction de la taille du cluster et de l'utilisation du GPU, le TCO annuel est estimé comme suit :

Taille de l'entreprise	Taille du cluster	Coût mensuel de l'infrastructure (estimé)	Effectif d'exploitation et de maintenance (années)	Fourchette annuelle du TCO (estimé)
Petite équipe (5-10 personnes)	3 à 5 nœuds, 1 à 4 cartes GPU	8 000 à 20 000 yuans	0,5 personne	150 000 à 400 000 yuans
Équipe de taille moyenne (20-50 personnes)	10 à 20 nœuds, 8 à 32 cartes GPU	30 000 à 100 000 yuans	1 personne	500 000 à 1,5 million de yuans
Grande organisation (100+ personnes)	Plus de 50 nœuds, plus de 100 cartes GPU	150 000 à 500 000 yuans	2+ personnes	2 à 8 millions de yuans

Conseil sur les coûts cachés : l'estimation ci-dessus n'inclut pas le coût GPU de la formation du modèle lui-même (généralement facturé en fonction de l'utilisation réelle pendant les tâches de formation et non inclus dans l'infrastructure de la plateforme). De plus, la mise à niveau des composants Kubeflow nécessite des temps d'arrêt ou une migration continue, et chaque mise à niveau de version majeure peut nécessiter 1 à 4 semaines de temps d'ingénierie pour les tests de compatibilité et la migration des données. Il est recommandé de réserver un tampon opérationnel de 20 % dans votre budget.

Scénarios d'application Kubeflow

Les capacités de Kubeflow couvrent l'intégralité du cycle de vie du ML, de la gestion expérimentale à l'inférence de production. Les quatre scénarios suivants ont été vérifiés à grande échelle :

• Plate-forme de pipeline ML de niveau entreprise : hébergez l'intégralité du processus de prétraitement des données, d'ingénierie des fonctionnalités, de formation des modèles, d'évaluation et de déploiement sur les K8. Convient aux équipes qui doivent éliminer la différence entre « le développement avec l'exécution de PyTorch et la production avec une reconfiguration manuelle ». Réduction des coûts et amélioration de l'efficacité : dans le modèle traditionnel, les ingénieurs ML doivent exécuter manuellement 8 à 12 étapes pour chaque itération du modèle (extraction de données, conversion de format, configuration des paramètres du script de formation, configuration du déploiement, etc.). Après le passage à Kubeflow Pipeline, il est réduit à « soumettre une exécution de pipeline » et le temps d'itération unique est réduit de 2 à 4 heures à 30 à 60 minutes (valeur de déduction, l'amélioration réelle varie en fonction de la complexité du processus d'équipe). Conseils de mise en œuvre : la conception de la granularité des composants de Pipeline affecte directement le taux de réutilisation : il est recommandé d'encapsuler les étapes courantes telles que la "vérification des données", le "calcul des fonctionnalités" et l'"évaluation du modèle" dans des composants standard et de les utiliser comme bibliothèque de composants commune pour l'équipe.

• Plate-forme de service de modèle multi-équipes : l'isolation multi-équipes est obtenue via K8s Namespace + RBAC. Les tâches de formation de chaque équipe s'exécutent dans un espace de noms indépendant et partagent la passerelle du service d'inférence. Convient aux moyennes et grandes organisations disposant de plusieurs équipes d’algorithmes. Limite de collaboration homme-machine (Règle D obligatoire) : les modifications de configuration des ressources pour la formation du modèle (telles que le nombre de GPU, l'extension du stockage) doivent être plafonnées via ResourceQuota de K8 au lieu d'une approbation manuelle ; cependant, un point de confirmation manuelle doit être défini lors de la dernière étape de la publication du modèle (passage du flux de la préparation à la production) pour éviter que les modèles insuffisamment vérifiés ne soient directement exposés au trafic en ligne.

• Réglage et déploiement LLM : utilisez la prise en charge de Kubeflow Trainer pour DeepSpeed ​​​​et LoRA pour orchestrer des tâches de réglage fin distribuées pour les grands modèles de langage sur les K8. KServe fonctionne avec vLLM ou TGI pour implémenter le déploiement d'inférence à haut débit de LLM. Réduction des coûts et amélioration de l'efficacité : la tâche de réglage fin basée sur LoRA recherche automatiquement la meilleure combinaison de classement et de taux d'apprentissage via Katib, réduisant ainsi le temps de réglage manuel des paramètres de 1 à 2 jours à 2 à 4 heures (valeur de déduction). Dans le même temps, la configuration et les indicateurs de chaque expérience sont automatiquement enregistrés, évitant ainsi le problème d'ingénierie courant consistant à « oublier d'enregistrer les paramètres qui ont été modifiés ».

• AutoML et automatisation des hyperparamètres : Katib prend en charge l'exécution simultanée de dizaines d'ensembles d'expériences d'hyperparamètres, éliminant automatiquement les combinaisons inefficaces. Il convient aux scénarios qui nécessitent de nombreux essais et erreurs, tels que l'exploration de l'ingénierie des fonctionnalités, la sélection de l'architecture du modèle et l'optimisation de la stratégie de formation. Conseils de mise en œuvre : le nombre d'expériences simultanées dans Katib est limité par les ressources du cluster. Il est recommandé de définir la limite de quota de ressources pour le CPU/GPU afin d'éviter qu'un seul groupe d'expériences n'occupe trop de ressources et ne provoque la mort de faim d'autres expériences. La stratégie d'arrêt anticipé peut réduire considérablement les tentatives non valides. Il est recommandé d'activer d'abord la stratégie d'arrêt médian.

Ne convient pas aux scénarios : Kubeflow ne convient pas aux scénarios suivants : des data scientists indépendants qui n'ont pas besoin de l'infrastructure K8 (un ordinateur portable suffit pour exécuter des expériences) ; les entreprises d'inférence légères qui nécessitent un délai de bout en bout inférieur à 10 minutes entre la soumission du code et la modélisation en ligne ; des projets qui lient profondément les services natifs de fournisseurs de cloud spécifiques (dans ce cas, les services gérés tels que Vertex AI et SageMaker sont davantage recommandés pour une meilleure expérience d'intégration).

Groupes applicables de Kubeflow

Kubeflow s'adresse aux équipes et aux organisations, et non aux développeurs individuels. Les quatre types de rôles suivants constituent les groupes d'utilisateurs principaux :

• ML Engineer/Algorithm Engineer : encapsulez le code de formation dans les composants du pipeline, utilisez Katib pour automatiser la recherche d'hyperparamètres et déployez les points de terminaison d'inférence de modèle via KServe. Prérequis : des compétences de base en conteneurisation Docker (empaquetage de scripts de formation en images) et des compétences en programmation Python sont requises. Le SDK kfp est conçu pour être convivial pour PyTorch/TensorFlow, mais il y a généralement une courbe d'apprentissage de 1 à 2 jours la première fois que vous convertissez un script de formation local en composant Pipeline.

• ML Platform Engineer/DevOps Engineer : Responsable du déploiement, de la mise à niveau, de la surveillance et du dépannage des clusters Kubeflow. Vous devez maîtriser à la fois l'exploitation et la maintenance du K8 et les caractéristiques de la charge de travail ML - telles que comprendre les stratégies de planification partagée GPU, être familier avec les indicateurs de formation de surveillance Prometheus et être capable de dépanner les échecs de communication de formation distribuée de PyTorchJob, etc. Ce type de rôle est un investissement humain clé pour la mise en œuvre de Kubeflow. Au moins une personne dans l’équipe est requise pour assurer la stabilité de l’environnement de production.

• Data Scientist/Chercheur : exécutez des scénarios de développement interactifs dans le cluster avec Kubeflow Notebooks, en exploitant les ressources GPU du cluster pour accélérer les expériences. Ne convient pas aux limites : les data scientists qui ont des attentes élevées en matière de "prêt à l'emploi" peuvent être frustrés lors de la phase de configuration limitée - Kubeflow ne fournit pas d'images préinstallées avec toutes les dépendances, et les utilisateurs doivent créer leurs propres images ou choisir des images communautaires. Il est recommandé aux ingénieurs de la plateforme de préparer à l'avance des images standardisées.

• AI Technical Manager/Platform Decision Maker : Évaluer l'adéquation de Kubeflow en tant qu'infrastructure ML de l'équipe. Trois conditions préalables doivent être concentrées sur : (1) L'équipe a déjà ou envisage de construire une infrastructure K8 ; (2) Il y a au moins un ingénieur d'exploitation et de maintenance du K8 à soutenir ; (3) La taille et la complexité de la charge de travail de l'équipe ML ont atteint un niveau où « la gestion manuelle est déjà difficile » (généralement une équipe d'algorithmes de plus de 5 personnes ou un temps de formation mensuel de plus de 500 heures GPU). Ne convient pas à la limite : pour les équipes d'algorithmes de moins de 3 personnes ou les organisations disposant déjà de solutions d'hébergement MLOps stables, il n'est pas recommandé de migrer vers Kubeflow - le rapport entrées-sorties n'est pas économique.

Résumé et Outlook

Kubeflow est la plate-forme MLOps open source la plus complète de l'écosystème Kubernetes : elle lie profondément les flux de travail ML à l'orchestration des conteneurs et convient aux équipes d'entreprise qui disposent déjà d'une infrastructure K8 et nécessitent des fonctionnalités MLOps de bout en bout.

Principaux avantages : l'architecture composée de composants de Kubeflow vous permet d'obtenir « ce que vous utilisez » sans introduire de complexité inutile en installant tous les composants ; l'intégration gratuite avec l'écosystème K8s (Prometheus, Istio, Argo CD, etc.) permet à l'équipe de la plateforme de tirer parti des piles technologiques existantes ; l'échelle communautaire de plus de 3 000 contributeurs et de plus de 33 000 étoiles garantit une vitalité écologique à long terme. La prise en charge étendue de la version 1.9 pour les charges de travail de formation LLM la maintient pertinente à l’ère GenAI.

Principales limitations actuelles : (1) Complexité élevée d'installation, d'exploitation et de maintenance - le déploiement complet de KCD implique plus de 10 contrôleurs, CRD et interfaces utilisateur Web, et la gestion de la compatibilité des versions entre les composants nécessite une maintenance dédiée ; (2) Courbe d'apprentissage abrupte : les utilisateurs doivent maîtriser à la fois le cadre ML (PyTorch/TensorFlow) et les compétences opérationnelles K8, les talents de fertilisation croisée des deux compétences sont rares sur le marché ; (3) la documentation chinoise et les ressources communautaires sont relativement limitées, et les blogs technologiques nationaux et le partage de cas sont toujours dominés par les plateformes MLOps hébergées ; (4) Il existe un écart de génération entre l'expérience de l'interface utilisateur et les produits MLOps commerciaux (tels que Vertex AI, SageMaker), et certaines opérations doivent encore revenir à la ligne de commande.

Points d'observation de suivi : (1) La situation concurrentielle entre l'écologie de Kubeflow et Ray - Ray pénètre rapidement sur la voie « plus légère » de la formation et du raisonnement de l'IA. Kubeflow peut-il réduire le seuil d'exploitation et de maintenance tout en conservant les avantages natifs des K8 ; (2) les progrès de l'obtention du diplôme du CNCF - de l'incubation à l'obtention du diplôme doivent prouver la maturité de la gouvernance et l'ampleur de l'adoption du projet ; (3) Profondeur de prise en charge de la charge de travail LLM - si elle peut être utilisée dans DeepSpeed/Megatron. Sur la base de l'intégration, elle fournit en outre des fonctionnalités de haut niveau telles que le flux de travail RLHF du modèle de réglage fin LoRA ; (4) Rythme de sortie de la version KCD - si le décalage horaire entre la sortie du sous-projet et l'intégration de KCD peut être raccourci.

Évaluation des risques d'achat et d'adoption : (1) Pour les entreprises disposant d'équipes K8 existantes et de charges de travail ML croissantes, Kubeflow est une option open source qui mérite d'être évaluée - il est recommandé de piloter les processus non critiques (formation hors ligne, évaluation de modèle) pendant 1 à 2 mois pour confirmer que l'équipe peut résoudre de manière indépendante les défauts quotidiens avant de passer aux scénarios d'inférence de production. (2) Les mises à niveau des versions majeures de Kubeflow peuvent impliquer une migration CRD et des modifications de l'API. Avant de mettre à niveau l'environnement de production, des tests de régression de lien complet doivent être effectués dans l'environnement de version préliminaire et le plan de restauration doit être écrit dans la SOP de mise à niveau. (3) Pour les secteurs où la conformité est forte, les fonctions RBAC et de journal d'audit de Kubeflow répondent aux exigences de base, mais le suivi précis du traçage des données et l'audit des versions de modèle doivent encore être étendus de manière indépendante. (4) Pour les petites et moyennes équipes ou organisations sans base K8, il est recommandé d'évaluer d'abord les services MLOps gérés (Vertex AI, SageMaker) ou des alternatives légères (MLflow + Ray), puis d'envisager de migrer vers Kubeflow une fois l'infrastructure mature.

Outils associés : Visage câlin, replicate

Informations de version

• Kubeflow 1.9 ：Il n’y a pas encore de date officielle précise. Prise en charge améliorée des charges de travail de formation LLM et de la stabilité de la plateforme. （~2026-03）
• Kubeflow 1.8 ：Il n’y a pas encore de date officielle précise. Présentation d’une expérience Pipeline améliorée et d’optimisations pour la planification GPU. （~2025-06）