GPU pour l’IA : Pourquoi vos modèles attendent à côté de ressources inactives ?

C’est un paradoxe que de nombreuses équipes d’ingénierie connaissent bien. D’un côté, des tableaux de bord affichent un taux d’utilisation des GPU à un seul chiffre, semblant crier à l’inactivité.

De l’autre, une file d’attente de workloads d’intelligence artificielle qui s’allonge, attendant désespérément de la puissance de calcul. Comment est-ce possible ?

Le rapport 2026 de Cast AI sur l’optimisation Kubernetes a mis en lumière un chiffre stupéfiant : en moyenne, l’utilisation calculatoire des GPU en production est de seulement 5%. Si ce chiffre ne signifie pas que 95% de la capacité est immédiatement disponible, il révèle une profonde inefficacité structurelle.

Ce n’est presque jamais un manque de matériel. Le problème est bien plus subtil et se niche dans la manière dont nous allouons et gérons ces précieuses ressources. Cet article va démystifier ce phénomène, explorer les quatre causes principales de ce blocage et vous donner une méthode claire pour diagnostiquer et résoudre le problème une bonne fois pour toutes.

Utilisation vs. allocation : Le malentendu coûteux

La première étape pour résoudre cette problématique est de comprendre la distinction essentielle entre l’utilisation et l’allocation d’un GPU. Ce que la plupart des outils de monitoring affichent comme « utilisation » est en réalité l’utilisation calculatoire : le pourcentage des cœurs de calcul (les streaming multiprocessors) qui sont actifs à un instant T.

Cela ne vous dit absolument rien sur la disponibilité réelle de la carte.

Imaginez une salle de réunion réservée pour toute la journée. Même si personne ne parle à l’intérieur pendant des heures, la salle reste indisponible pour quiconque d’autre. C’est exactement ce qui se passe avec vos GPU.

Un modèle d’IA chargé en mémoire vidéo (VRAM) occupe cette mémoire en permanence. Même s’il ne traite qu’une requête par minute, maintenant l’activité de calcul à 5%, le GPU est considéré comme entièrement alloué par Kubernetes.

Pour l’orchestrateur, sa capacité est de zéro. Pour votre tableau de bord, il a l’air de se tourner les pouces.

Les 4 raisons cachées derrière la file d’attente de vos GPU

Une fois cette nuance saisie, nous pouvons commencer à creuser. Plusieurs facteurs peuvent créer cette situation frustrante où des workloads attendent à côté de GPU qui semblent libres. Voici les quatre principaux.

1. L’allocation exclusive par défaut

Par défaut, Kubernetes fonctionne sur un principe simple : un pod demande un GPU, il obtient un GPU entier, pour lui tout seul. Le plugin NVIDIA pour Kubernetes attribue un appareil physique de manière exclusive.

Qu’importe si le workload n’utilise que 10% de sa puissance de calcul ou 20% de sa mémoire. Tant que le pod est en cours d’exécution, ce GPU lui est verrouillé.

C’est la cause la plus fréquente, notamment pour les services d’inférence qui reçoivent des requêtes de manière sporadique. Chaque modèle sur son propre GPU dédié bloque l’ensemble du parc, même si l’activité globale est très faible. Le problème n’est pas matériel, il est au niveau de la planification (le scheduling).

2. La mémoire (VRAM) est pleine, pas le processeur

Une faible activité de calcul ne signifie pas que la mémoire est vide, loin de là. Un grand modèle de langage (LLM) de 70 milliards de paramètres peut nécessiter plus de 140 Go de VRAM juste pour être chargé, sans même compter le cache nécessaire au traitement des requêtes.

Même un modèle plus petit de 13 milliards de paramètres occupe environ 26 Go de VRAM en continu. L’activité de calcul peut être faible, mais la mémoire est saturée. Dans ce scénario, aucun autre workload ne peut être placé sur ce GPU, car il n’y a tout simplement plus de place en mémoire.

Avant d’envisager le partage de GPU, il faut donc vérifier l’occupation de la VRAM avec une commande comme `nvidia-smi`.

3. Les règles de placement qui bloquent tout

Parfois, des GPU sont techniquement disponibles et allouables, mais votre workload ne peut toujours pas y accéder. Pourquoi ? À cause des contraintes de placement que vous avez définies dans Kubernetes.

Un pod peut exiger un modèle de GPU spécifique (par exemple, un A100) et refusera de se lancer sur un nœud équipé de H100, même si ces derniers sont libres et plus puissants. Des règles d’affinité, des contraintes de topologie ou des taints sur les nœuds peuvent toutes empêcher un pod d’être planifié, donnant l’impression d’une pénurie de capacité. Une simple commande `kubectl describe pod` sur un pod en attente révèle souvent ces problèmes dans la section « Events ».

4. Le vrai coupable est ailleurs (CPU, réseau…)

Enfin, il arrive que le GPU soit effectivement inactif parce qu’il attend. Il attend que le CPU termine une étape de prétraitement, que des données soient chargées depuis le disque, qu’un transfert via le bus PCIe se termine ou qu’une réponse réseau arrive.

Un serveur d’inférence qui attend une étape de tokenisation lente affichera une faible utilisation du GPU, mais il n’est pas pour autant disponible. Il est simplement bloqué par un autre composant de l’architecture. Augmenter le nombre de GPU ne résoudra rien.

La solution réside dans l’optimisation des ressources CPU, du stockage ou du pipeline de données.

Partage de GPU : La solution pour libérer votre capacité

Pour la problématique la plus courante, celle de l’allocation exclusive, la solution est le partage de GPU. Au lieu de donner un GPU entier à un seul pod, on permet à plusieurs pods de l’utiliser. Il existe plusieurs méthodes pour y parvenir, chacune avec ses compromis.

Le time-slicing : Simple, mais avec des risques

Le « time-slicing » (ou partage de temps) est une méthode logicielle où le GPU alterne très rapidement son attention entre plusieurs workloads. C’est compatible avec presque toutes les cartes NVIDIA. Cependant, cette méthode n’offre aucune isolation de la mémoire.

Si un workload consomme toute la VRAM ou provoque un crash, il impactera tous les autres workloads partageant le même GPU. C’est donc une solution à réserver à des modèles dont on est sûr que l’empreinte mémoire combinée ne dépassera pas la capacité de la carte.

MIG (Multi-Instance GPU) : La forteresse matérielle

Disponible sur les architectures récentes (Ampere et plus), MIG permet de partitionner un GPU physique en jusqu’à sept instances virtuelles indépendantes. Chaque instance dispose de ses propres chemins d’accès à la mémoire et de ses propres cœurs de calcul.

C’est la solution la plus robuste, garantissant une isolation parfaite des performances et de la mémoire. Idéal pour des environnements multi-locataires où la qualité de service est primordiale.

MPS (Multi-Process Service) : L’entre-deux concurrentiel

MPS est une alternative qui permet à plusieurs processus CUDA de s’exécuter simultanément sur les mêmes cœurs de calcul, réduisant la surcharge liée au changement de contexte par rapport au time-slicing. Bien qu’il n’offre pas l’isolation matérielle de MIG, des versions plus récentes permettent une meilleure gestion des ressources et une isolation des fautes, offrant un bon compromis pour certains cas d’usage.

Diagnostic en 5 étapes : Arrêtez de deviner, commencez à mesurer 📈

Avant de vous lancer dans une reconfiguration complexe ou, pire, d’acheter du nouveau matériel, suivez cette procédure de diagnostic dans l’ordre :

1. Vérifiez l’état d’allocation : Lancez `kubectl get nodes` pour voir combien de GPU sont allouables sur chaque nœud. Si tout est à zéro et que des pods attendent, vous avez bien un problème d’allocation.
2. Vérifiez l’occupation de la mémoire : Sur un nœud où les GPU sont alloués mais peu actifs, lancez `nvidia-smi`. Si la colonne de mémoire utilisée est proche du maximum, le goulot d’étranglement est la VRAM, pas le calcul.
3. Inspectez les événements des pods en attente : Utilisez `kubectl describe pod ` sur un pod qui ne démarre pas. Cherchez des messages d’erreur liés aux règles de placement (MatchNodeSelector, TaintToleration…).
4. Observez l’activité dans le temps : Utilisez `nvidia-smi dmon` pour suivre l’utilisation du GPU sur une période donnée. Des pics d’activité suivis de zéros pointent vers un goulot d’étranglement CPU ou I/O.
5. Vérifiez la compatibilité matérielle : Assurez-vous que la méthode de partage que vous envisagez (time-slicing, MIG) est compatible avec vos GPU et votre fournisseur cloud avant de modifier quoi que ce soit.

La prochaine fois que vous verrez des workloads en attente à côté de GPU semblant inactifs, ne sortez pas la carte de crédit. La réponse se trouve très probablement dans une mauvaise configuration de l’allocation, de la mémoire ou du scheduling, et non dans un manque de matériel.

En suivant une démarche de diagnostic méthodique, vous pouvez identifier la cause racine et appliquer la bonne solution, qu’il s’agisse de mettre en place du partage de GPU, d’ajuster vos règles de placement ou d’optimiser votre pipeline de données. C’est en transformant ces ressources « faussement inactives » en capacité réellement productive que vous libérerez le véritable potentiel de votre infrastructure d’IA.

Et vous, avez-vous déjà été confronté à ce paradoxe ? Partagez votre expérience dans les commentaires 👇

Simone

Simone, rédactrice principale du blog, est une passionnée de l’intelligence artificielle. Originaire de la Silicon Valley, elle est dévouée à partager sa passion pour l’IA à travers ses articles. Sa conviction en l’innovation et son optimisme sur l’impact positif de l’IA l’animent dans sa mission de sensibilisation.