Nous mettons en place Kubernetes pour partager vos GPU entre équipes.

La production, la data science et l'entraînement travaillent sur le même cluster, sur vos serveurs, et les charges qui ne doivent pas se gêner sont séparées au niveau matériel.

Avec un GPU par équipe, certains tournent à fond et d'autres restent à l'arrêt.

Celui de la production ne suit pas, celui des data scientists passe l'après-midi avec un notebook ouvert sans rien calculer et l'entraînement qui arrive le jeudi n'a nulle part où aller.

Acheter une autre carte supprime la file d'attente pour un temps, mais celles que vous avez déjà restent à moitié inutilisées et l'achat suivant arrive plus tôt que prévu.

Façons de partager un GPU

Un même cluster les combine souvent. Le bon choix dépend de la capacité des charges à se gêner entre elles et de la mémoire dont chacune a besoin.

GPU · 96 Go

Par tranches de temps

Plusieurs processus utilisent la carte entière et calculent à tour de rôle. Cela fonctionne sur presque tous les GPU NVIDIA, mais la mémoire est commune et il n'y a pas d'isolation : si un processus l'accapare ou si la carte tombe en panne, tout s'arrête. C'est adapté aux notebooks et aux tests, qui passent beaucoup de temps sans calculer.

GPU · 96 Go
24 Go24 Go24 Go24 Go

Découpé avec MIG

La carte est divisée au niveau matériel en GPU plus petits, chacun avec sa mémoire et ses cœurs, si bien qu'une panne dans l'un n'affecte pas les autres. C'est le bon choix pour servir plusieurs petits modèles en production.

Serveur · 4 GPU
entraînement · en attente

Entiers, en file d'attente

Chaque tâche reçoit des GPU complets et attend son tour dans la file de son équipe. C'est là que trouvent leur place les entraînements et les ajustements de modèles, qui peuvent tourner la nuit sans prendre de place à la production.

  • Production
  • Données
  • Tests et entraînement

Exemple : un serveur avec quatre GPU

Trois équipes se partagent les quatre cartes au fil d'une journée.

  1. Le modèle de production, servi avec vLLM, dispose du GPU 1 entier dès le démarrage.

    entier
  2. Trois petits modèles (embeddings, un classifieur et la transcription vocale) se partagent le GPU 2, découpé avec MIG.

    MIG
  3. Cinq notebooks de data science utilisent le GPU 3 à tour de rôle.

    à tour de rôle
  4. Un ajustement de modèle demande deux GPU. Un seul est libre, il attend donc dans la file de son équipe.

    en attente
  5. Les notebooks se ferment et l'ajustement emprunte le GPU 3 en plus du 4.

    emprunté
  6. L'ajustement se termine et le GPU 3 revient à l'équipe données avant que quiconque n'arrive.

    rendu

Comment nous le mettons en place

Pilotes avec le GPU Operator Il installe et maintient les pilotes NVIDIA sur chaque nœud, configure les partitions MIG et le partage par tranches de temps, et rend les cartes visibles pour Kubernetes. En dessous tourne Ubuntu ou Rocky Linux, avec le support de Canonical ou de CIQ.

Demander des GPU avec DRA Avec DRA, intégré à Kubernetes depuis la version 1.34, et le pilote DRA de NVIDIA, une charge demande « un GPU d'au moins 40 Go » et le cluster en trouve un qui convient.

Une file par équipe avec Kueue Chaque équipe a son quota. Ce qu'une équipe n'utilise pas, une autre peut l'emprunter, et la production est prioritaire pour récupérer ses cartes dès qu'elle en a besoin.

Mesurer l'utilisation Avec l'exportateur DCGM de NVIDIA, Prometheus et Grafana, on voit combien utilise chaque équipe : c'est la donnée qui permet d'ajuster les quotas ou de décider s'il faut une autre carte.

Serveurs et formation

Si vous n'avez pas encore les cartes, nous configurons des serveurs Lenovo pour l'IA et des serveurs Supermicro pour l'IA avec les GPU adaptés à la répartition. Et pour que votre équipe puisse gérer le cluster, il y a les formations Kubernetes avec MicroK8s et vLLM et llm-d sur Kubernetes (3 jours), qui couvre le partage de GPU entre équipes.

Questions fréquentes

Quels GPU prennent en charge MIG ?

L'A100, l'A30, le H100, le H200, le B200 et le B300, ainsi que la RTX PRO 6000 Blackwell. Le L4 et le L40S ne le prennent pas en charge : sur ces cartes, on partage par tranches de temps ou par GPU entiers.

Faut-il Kubernetes pour cela ?

Pour une équipe et un modèle, non : vLLM sur un serveur suffit. Kubernetes devient intéressant quand plusieurs équipes ou plusieurs modèles partagent les mêmes machines et qu'il faut décider qui utilise quoi et quand. L'inférence d'IA sur vos serveurs

Nous avons déjà les GPU. Par où commencer ?

À partir des données d'utilisation des cartes que vous avez déjà, nous proposons une répartition, et nous ne parlons d'en ajouter que si cela ne suffit pas pour tout le monde.

Contact

Combien de GPU avez-vous et qui les utilise ?

Dites-nous quelles cartes vous avez ou comptez acheter et quelles équipes vont les utiliser. Nous vous proposerons une répartition et ce qu'il faut mettre en place.

Parlez-nous de vos GPU

SIXE