GPU inactifs et files d’attente : allocation, mémoire, placement

Des pods peuvent patienter alors que les graphiques montrent un GPU presque au repos. La raison n’est pas forcément une pénurie matérielle, mais souvent l’allocation exclusive, la VRAM occupée, des contraintes de placement ou un pipeline qui bloque ailleurs. Cast AI rapporte une moyenne d’utilisation de 5% sur des clusters analysés en 2025-2026, mais cela ne signifie pas que 95% de la capacité sont récupérables sans diagnostic fin.

Quand le GPU n’est pas le goulet : CPU, I/O et placement bloquent

Une faible activité de calcul sur un GPU ne signifie pas toujours qu'il est disponible pour d'autres charges de travail. Le processeur, les transferts PCIe, le chargement de données ou le réseau peuvent laisser le GPU inoccupé alors que la charge de travail attend ailleurs. Par exemple, un serveur d’inférence LLM en attente d’une étape de tokenisation lente ou d’un fetch de cache KV distant affichera un faible pourcentage de multiprocesseurs de streaming actifs, sans pour autant libérer l’appareil pour d’autres pods. Ces situations sont difficiles à diagnostiquer à partir des seules métriques GPU. Une activité de calcul durablement basse sur une charge active indique généralement un goulet d’étranglement hors GPU ; ajouter des cartes n’apporte alors pas de solution. Les correctifs portent sur les ressources CPU, le réglage du batching, la latence de stockage ou la refonte du pipeline de données. Des outils comme nvidia-smi dmon ou les métriques DCGM permettent d’observer l’utilisation du calcul dans le temps : des alternances entre 0% et de courtes rafales évoquent une limite CPU, tandis qu’une faiblesse constante sous charge oriente vers l’I/O ou le réseau. Ces profils se distinguent d’une pénurie d’allocation et nécessitent des remèdes différents. Par ailleurs, l’échec de planification peut venir du placement. Des affinités de nœud ciblant un modèle de GPU, des contraintes de répartition de topologie ou des taints non tolérés peuvent exclure du matériel pourtant disponible. Une demande nvidia.com/gpu: 1 assortie d’un sélecteur exigeant un A100 ne se posera pas sur des H100, même inactifs. Demander plus de répliques en time-slicing qu’un nœud ne peut en fournir, sans répartition, peut aussi faire échouer le déploiement malgré la capacité totale. La commande kubectl describe pod <pending-pod> et ses événements (MatchNodeSelector, InsufficientResource, TaintToleration) permettent d’identifier ces cas, qui se résolvent par la configuration du planificateur, pas par l’ajout de matériel.

Allocation exclusive par défaut : le premier verrou à lever

Le planificateur Kubernetes considère les GPU comme des dispositifs entiers exposés via nvidia.com/gpu, sans tenir compte du pourcentage de silicium actif. Par défaut, il attribue des GPU entiers aux pods : un pod demandant nvidia.com/gpu: 1 obtient l’exclusivité du dispositif pendant toute sa durée de vie, empêchant tout autre pod d’y accéder, quelle que soit l’utilisation effective. Ce comportement explique la plupart des files d’attente à côté de GPU peu actifs dans les clusters d’inférence : des modèles servis à faible fréquence monopolisent chacun une carte, et une charge entrante constate nvidia.com/gpu: 0 disponible, même si l’activité agrégée du nœud reste inférieure à 10%. Le plugin de dispositif se concentre sur l’allocation et l’auto-scaler peut ajouter des nœuds, mais la récupération de capacité sur un nœud existant n’a pas lieu. Le problème est de planification : il faut changer la manière de présenter les GPU au planificateur, ce que permettent les mécanismes de partage.

VRAM saturée : modèles lourds, KV cache et quantification

Une faible utilisation de calcul ne signifie pas que la mémoire GPU est disponible. Un modèle de 70 milliards de paramètres en FP16 occupe environ 140 Go de VRAM pour ses poids, auxquels le cache KV ajoute 15 à 20% à 4K de contexte et peut dépasser les poids à 128K. Il faut alors deux A100 80 Go ou plus pour le charger. Un modèle 13B FP16 tient sur un A100 80 Go avec environ 26 Go mais occupe la VRAM en continu ; l’activité peut n’indiquer que 8% et l’appareil reste indisponible pour d’autres charges. Avant de configurer un partage, il faut évaluer la quantification : un 7B en INT4 peut descendre à environ 4 Go contre environ 14 Go en FP16 ; l’INT8 réduit souvent d’environ moitié les besoins par rapport au FP16 avec une qualité acceptable pour l’inférence. Le choix de la méthode de partage dépend de la mémoire. Le time-slicing multiplexe le calcul mais ne partitionne pas la VRAM : toutes les répliques partagent le même espace d’adressage, et deux charges qui dépassent ensemble la mémoire ne peuvent pas coexister en sécurité. Diagnostiquer d’abord la contrainte mémoire évite les déploiements instables. Un contrôle préalable avec nvidia-smi s’impose : si la mémoire libre approche de zéro, la limite est la VRAM plutôt que la planification. MIG apporte des partitions mémoires isolées matériellement, au prix d’un matériel compatible et d’une planification adaptée.

Ce que disent vraiment les métriques d’utilisation GPU

Les indicateurs regroupés sous « utilisation GPU » recouvrent au moins quatre mesures distinctes. La plupart des tableaux de bord affichent l’activité de calcul, c’est-à-dire la part de multiprocesseurs de streaming actifs sur une fenêtre donnée ; elle renseigne sur l’occupation du silicium, pas sur l’état d’allocation. Un modèle chargé en VRAM occupe cette mémoire en continu, et Kubernetes ne reprogrammera rien d’autre sur un appareil alloué, même si l’activité de calcul reste, par exemple, à 5% avec un service répondant rarement. D’autres métriques complètent le tableau : l’occupation mémoire VRAM indique combien de mémoire est consommée sans préciser l’activité de calcul ni l’aptitude des charges en attente à tenir ; le temps d’attente de programmation mesure la durée d’attente sans préciser l’origine du blocage ; débit et latence reflètent les performances perçues (jusqu’au premier jeton ou de bout en bout) sans informer sur l’utilisation des ressources ni l’efficacité d’allocation. Confondre ces échelles mène à des diagnostics erronés.

Chiffrer sans surinterpréter et diagnostiquer dans l’ordre

Cast AI indique, dans un rapport couvrant des dizaines de milliers de clusters entre janvier 2025 et avril 2026, une utilisation moyenne des GPU de 5% avant optimisation. Un cluster y a maintenu 49% sur 136 H200, un écart attribué surtout à la technique plutôt qu’au matériel. Ces éléments décrivent un surprovisionnement et une sous-utilisation réels à l’échelle d’une flotte, sans signifier que 95% de la capacité est mobilisable d’emblée. Chaque cluster et chaque GPU exigent un diagnostic propre. Côté remèdes, plusieurs méthodes de partage coexistent avec des compromis différents en isolation mémoire, exigences matérielles, observabilité et support cloud ; aucune n’est universelle. Certaines plateformes, comme Cast AI, déclarent prendre en charge time-slicing, MIG et MPS avec un bin-packing automatique ne requérant pas de modifier les manifestes. Quel que soit l’outillage, la démarche de diagnostic doit suivre une séquence précise : vérifier l’état d’allocation, puis l’occupation mémoire, ensuite le placement, enfin les goulets d’étranglement applicatifs. C’est dans cet ordre que les causes se démêlent et que les correctifs techniques portent leurs effets.