Ferme Kubernetes GPU : multi-tenant, GPU Operator et scheduling

Slurm reste la référence pour le training synchrone de grande taille. Mais la réalité de la plupart des entreprises est mixte : plusieurs équipes, des services d’inférence, des notebooks, du fine-tuning en batch, des jobs de CI. Kubernetes gagne sur ce terrain parce qu’il parle la langue que votre équipe plateforme opère déjà : namespaces, RBAC, GitOps, observabilité. Le GPU Operator gère drivers, device plugin, métriques DCGM et node feature discovery de façon déclarative : un nœud GPU rejoint le cluster en minutes au lieu d’un après-midi de réglages manuels.

Le piège est de traiter les GPU comme des CPU. Une GPU n’est pas fractionnable par défaut, les jobs sont souvent gang-schedulés, et l’allocation inactive brûle de l’argent à un rythme qui rend le gaspillage CPU anecdotique.

Le training distribué exige un placement tout-ou-rien : lancer 7 workers sur 8 bloque le fabric et gaspille chaque GPU allouée. Kueue apporte une sémantique de file à Kubernetes : ClusterQueues avec quotas par équipe, cohortes pour emprunter la capacité inactive, et admission d’un job seulement quand le gang complet a sa place. Combiné aux priority classes et à la préemption, une équipe recherche peut emprunter les nuits creuses de l’équipe inférence sans qu’un ticket soit ouvert.

Pour partager une même carte, choisissez délibérément : MIG partitionne une H100 ou A100 en tranches isolées matériellement, aux performances prévisibles, idéales pour les tiers d’inférence. Le time-slicing est plus souple, bien pour notebooks et dev, mauvais pour du serving sensible à la latence. Documentez le profil exposé par chaque file et faites-le respecter par la plateforme, pas par la tradition orale.

Les clusters GPU multi-tenant échouent par les fuites, pas par le scheduling. Isolez les équipes avec namespaces, NetworkPolicies et storage classes séparées ; exposez des charts Helm de référence ou un template interne pour les jobs de training et de serving, pour que personne ne réinvente des specs de pod en mode privilégié. La refacturation compte même en interne : publiez des tableaux de bord GPU-heure par équipe depuis les données DCGM, car le coût visible est la seule incitation durable contre le squat.

Faites passer l’ensemble par GitOps. Définitions de files, quotas, profils MIG et versions de drivers appartiennent à un dépôt avec revue : les changements de politique de capacité deviennent des décisions auditables plutôt que des surprises kubectl.