En 2026, les clusters Kubernetes tournent en moyenne à 5 % d'utilisation GPU alors que le matériel coûte plusieurs dollars l'heure. Voici une méthode de dimensionnement et un comparatif de coûts pour arbitrer entre provisionné et autoscaling.
La plupart des entreprises qui déploient des modèles en production sur Kubernetes découvrent le même chiffre une fois les factures cloud analysées. L'utilisation GPU moyenne atteint 5 % sur l'ensemble des clusters Kubernetes en production, selon le Cast AI 2026 State of Kubernetes Optimization Report. Même les déploiements les plus matures restent loin d'une utilisation satisfaisante : le cluster le plus performant de ce panel, un déploiement H200 de 136 nœuds, a atteint 49 %.
Ce taux d'utilisation s'explique en grande partie par la nature de l'inférence LLM. La consommation de calcul reste autour de 30-35 % car l'inférence est limitée par la bande passante mémoire (HBM), pas par la puissance de calcul brute. Concrètement, un modèle de taille modeste chargé en pleine mémoire GPU n'utilise qu'une fraction du silicium disponible, mais Kubernetes facture et réserve la carte entière. Lorsqu'un pod demande un GPU, Kubernetes assigne nativement la carte physique entière au conteneur, même si la charge n'en utilise que 15 %.
L'impact financier est direct. Un H100 inactif sur AWS p5 coûte environ 12,30 $ par GPU et par heure en on-demand ; 20 H100 actifs en permanence et inutilisés brûlent environ 177 000 $ par mois. Et la tendance ne va pas dans le bon sens : les prix des GPU sont également orientés à la hausse. AWS a relevé les prix des Capacity Blocks H200 de 15 % en janvier 2026.
Le dimensionnement commence par un mauvais réflexe fréquent : surdimensionner par prudence. Le sur-provisionnement est le comportement par défaut des déploiements GPU sous Kubernetes : les équipes demandent un H100 80 Go pour une charge qui utilise 9 Go, le GPU tourne à 8 % d'utilisation et est facturé à 100 %.
Pour éviter cet écueil, il faut partir de la taille réelle du modèle en mémoire, pas de la puissance de calcul théorique nécessaire. Quelques repères utiles pour le dimensionnement :
Côté coûts par type de carte, voici des ordres de grandeur observés sur GKE début 2026 : un T4 16 Go coûte environ 0,35 $/h en on-demand et 0,11 $/h en spot ; un L4 24 Go environ 0,70 $/h on-demand et 0,24 $/h en spot ; un A100 80 Go environ 3,67 $/h on-demand et 1,10 $/h en spot ; un H100 80 Go environ 11,29 $/h on-demand et 3,39 $/h en spot. Sur AWS, un nœud H100 coûte environ 3,90 $ par GPU-heure en on-demand, un écart de pricing qui justifie à lui seul un arbitrage multicloud pour les volumes importants.
Pour les charges d'inférence légères, la technologie NVIDIA MIG (Multi-Instance GPU) change radicalement l'équation économique. Un A100 doté de 40 Go de mémoire peut être partitionné en sept tranches 1g.5gb (chacune avec 1/7 du calcul et 5 Go de mémoire) ou deux tranches 3g.20gb.
L'effet sur la densité de service est net : pour des modèles plus petits (7B-13B après quantification), cela transforme un nœud GPU à 4 $/heure en sept points de terminaison d'inférence indépendants. Autrement dit, au lieu de payer sept GPU dédiés pour sept microservices, on en paie un seul partitionné. Le gain documenté est substantiel : le partitionnement GPU avec NVIDIA MIG peut réduire les coûts GPU par charge de travail jusqu'à 85 %.
Attention toutefois à la supervision : le GPU Feature Discovery de NVIDIA génère automatiquement des labels par nœud selon le matériel et la configuration MIG, ce qui permet au scheduler de différencier les profils de partition ; sans labels fiables, le scheduler ne peut pas distinguer un nœud offrant sept petites tranches d'un nœud offrant deux grandes partitions. Ce point technique est souvent négligé dans les déploiements rapides, avec des effets de bord en production.
Le dimensionnement ne se limite pas au GPU. Les agents, les API de préparation des données, les proxys et les services de monitoring tournent sur des nœuds CPU séparés, et doivent être isolés des nœuds GPU par des taints. Il faut tainter les nœuds GPU pour que les pods CPU classiques n'y soient pas planifiés par accident ; un nœud GPU sans taint acceptera volontiers des pods nginx, et facturera alors 3,67 $/heure pour servir des fichiers statiques.
Pour une architecture agentique typique associant agents CPU et inférence GPU, un ordre de grandeur budgétaire observé en production donne : pools système et agents autour de 200-400 $/mois, pool d'inférence (2 instances g5.xlarge Spot, 8h/jour) autour de 150-250 $/mois, pour un total d'environ 350-650 $/mois contre 1 500-2 000 $ si le GPU tournait 24h/24.
C'est la décision centrale du dimensionnement 2026. Un cluster provisionné statiquement garantit la latence mais paie l'inactivité ; un cluster autoscalé économise mais introduit un délai de démarrage à froid. Les données disponibles permettent de chiffrer l'arbitrage.
Sur le volet infrastructure, l'écart est documenté précisément : l'autoscaling natif Kubernetes réduit le temps d'inactivité GPU d'une moyenne de 35 % sur des clusters d'inférence à provisionnement fixe à 12 %, ce qui réduit le coût total d'inférence de 23 % pour un déploiement médian de 32 GPU.
Le choix de l'outil d'autoscaling au niveau nœud compte également. Cluster Autoscaler ajoute des nœuds à un groupe prédéfini quand des pods restent en attente, mais ne peut pas réduire la voilure sur la seule base de l'utilisation GPU : un nœud avec une utilisation GPU quasi nulle mais des pods en cours d'exécution reste actif, ce qui constitue une fuite de coût significative pour les charges d'inférence avec de longs intervalles d'inactivité. Karpenter, de son côté, réagit plus vite : il déclenche l'appel API cloud en moins de 60 secondes, et le nœud atteint l'état prêt pour GPU en 3 à 5 minutes avec une AMI GPU pré-configurée.
Le vrai scale-to-zero change la donne pour les usages peu sollicités : il signifie zéro pod et zéro nœud GPU en service quand la demande est absente, ce qui élimine entièrement le coût GPU inactif pour les points de terminaison à faible trafic ou de nuit ; la contrepartie est la latence de démarrage à froid, variable selon ce qui est déjà préchauffé. KEDA avec un minReplicaCount à 0 permet un véritable scale-to-zero pour les pods d'inférence GPU.
Le sur-provisionnement n'est pas toujours une erreur : c'est parfois un choix de fiabilité assumé. Le sur-provisionnement réduit la variance de latence P99 d'un facteur 3 à 5 ; un cluster tournant à 70 % d'utilisation GPU a une latence P99 supérieure de 15 % à la référence, tandis qu'un cluster à 85 % voit sa latence P99 augmenter de 60 % à cause de la mise en file d'attente des requêtes. La recommandation issue de ces observations converge vers une plage précise : faire tourner le cluster de base entre 60 et 65 % d'utilisation GPU avec des déclencheurs HPA à 70 %, ce qui maintient la latence P99 dans une marge de 20 % par rapport à la référence tout en gardant le coût d'inactivité GPU entre 35 et 40 %.
À titre d'illustration budgétaire sur un parc important : pour un cluster de 32 GPU B200 à 8,50 $/h par GPU, le coût d'inactivité se situe entre 13 056 et 14 928 $ par mois — un montant qui doit être lu comme le prix payé pour la fiabilité, pas comme une anomalie à corriger systématiquement.
Le choix entre instances spot et capacité réservée dépend du profil de trafic. Une synthèse des options observées mi-2026 donne les repères suivants pour du H200/B200 en région US East : spot à interruption modérée pour les charges batch ou multi-réplicas, sur-provisionnement pour les charges sensibles à la latence, scale-to-zero pour le développement et les environnements de test, et contrat réservé pour les trafics stables.
Les instances GPU spot offraient mi-2026 des remises de 50 à 80 % par rapport au prix on-demand, avec une alerte de terminaison de 2 minutes que la stack d'inférence doit gérer correctement. Pour les budgets conséquents, une stratégie hybride s'impose : pour les équipes dépassant 200 000 $/mois de coût GPU d'inférence, il est recommandé de négocier un contrat réservé d'un an couvrant 60 % de la capacité attendue et de couvrir les 40 % restants avec des instances spot.
Au-delà des moyennes sectorielles, plusieurs cas documentés donnent une idée des gains réalistes d'un dimensionnement maîtrisé. Une migration de SageMaker vers Kubernetes avec partage GPU et instances spot illustre l'effet cumulé des leviers : ALLEN Digital a migré 7 modèles d'inférence de SageMaker vers Kubernetes avec time-slicing GPU et instances Spot ; les économies résultent de trois facteurs cumulés — tarification spot, time-slicing GPU entre modèles, et bin-packing par consolidation de modèles — réduisant le coût total d'infrastructure GPU de plus de 70 % par rapport à la référence SageMaker, sans dégradation de latence.
Un autre cas d'optimisation d'autoscaling sur une charge fixe montre un résultat plus modeste mais tout aussi concret : la capacité planifiée est passée de 20 000 à 14 000 GPU-heures au tarif de 5 $ du client, faisant passer les charges de calcul GPU mensuelles de 100 000 $ à 70 000 $ pour la charge fixe, tout en préservant l'objectif de service pendant les pics et incidents.
Enfin, un repère de seuil utile avant même de se poser la question du dimensionnement fin : la plupart des startups IA atteignent le seuil de pertinence de Kubernetes autour de 5 000 à 10 000 $/mois de dépenses cloud GPU ; en dessous, un point de terminaison d'inférence managé ou une simple VM avec vLLM est plus simple et moins coûteux à exploiter. Ce seuil mérite d'être posé en amont de tout projet de clusterisation, pour éviter de complexifier une infrastructure qui n'en a pas encore besoin.
Ce travail de dimensionnement ne se fait pas une fois pour toutes : les prix des GPU, les modèles disponibles et les outils d'orchestration évoluent trop vite en 2026 pour qu'une configuration reste optimale plus de quelques mois. Nos équipes accompagnent les directions data sur l'audit et l'industrialisation de leurs infrastructures d'inférence, du choix des cartes jusqu'à la mise en place des politiques d'autoscaling adaptées à chaque secteur d'activité, détaillées sur notre page secteurs.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus