Mesurer la charge avant d'agrandir le pool de GPU
27 octobre 2026 · 4 min de lecture
Des équipes exécutant des charges de travail d'intelligence artificielle sur Kubernetes font face à un pool de GPU entièrement alloué et à une file d'attente de jobs en croissance. Cette situation peut inciter à agrandir le pool sans examen préalable. Avant d'ajouter des ressources, il faut déterminer ce qui constitue un succès, la date limite d'achevement et le coût associé à la réalisation de cet objectif.
« Un GPU alloué, un GPU occupé et une charge de travail produisant des résultats utiles ne sont pas la même chose. »
Il est essentiel de distinguer ces concepts afin d'optimiser l'utilisation de la capacité existante avant de provisionner de nouvelles unités.
Commencez par définir l'objectif et la date limite
Analysez les charges de travail et les cas d'utilisation qu'elles supportent. Un chatbot de service client nécessite une capacité d'inférence continue, alors qu'un job d'évaluation de modèle peut être requis uniquement avant la prochaine synchronisation interne. Classer les charges de travail en catégories telles que « inférence » ou « formation » ne détermine pas leur urgence. Certaines tâches d'inférence peuvent être différées, tandis que d'autres ont une date limite stricte.
Utilisez la flexibilité de planification avant d'agrandir le pool
Imaginons que quatre GPU compatibles soient disponibles pour le traitement par lots entre midi et 17 heures. Quatre jobs d'évaluation indépendants sont prêts à midi. Chaque job nécessite deux GPU pendant une heure, et tous les résultats doivent être livrés avant 17 heures.
Lancer les quatre jobs simultanément demanderait huit GPU. En revanche, exécuter deux jobs à midi et les deux restants à 13 heures permet de terminer l'ensemble des travaux avant 14 heures, en utilisant uniquement les quatre GPU déjà disponibles. Le nombre total d'heures GPU consommées reste de huit, hors frais de démarrage.
« La planification par lots réduit la demande maximale. Les jobs terminent à temps sans agrandir le pool. »
Examinez les politiques d'admission
Des outils comme Kueue offrent un point de contrôle d'admission en appliquant des quotas et des politiques configurées. Les équipes doivent toutefois définir comment représenter et appliquer les délais et les exigences de charge.
Mesurez la production utile durable
La flexibilité de planification peut atténuer les contraintes de capacité, mais les équipes d'inférence doivent vérifier que le modèle et la configuration de service correspondent aux exigences du travail.
Une activité élevée du GPU ne prouve pas la capacité supplémentaire disponible. La documentation Nvidia indique que l'activité des multiprocesseurs peut inclure des warps en attente de mémoire. Les métriques de service telles que les requêtes en cours, les requêtes en attente et l'occupation du cache apportent du contexte, tout comme les comptes de préemptions.
Pour évaluer la capacité durable, effectuez des tests de charge représentatifs en maintenant le modèle, le matériel, les paramètres de service et le mix de requêtes constants. Augmentez progressivement le taux d'arrivée et observez le débit, la qualité et la latence. Le taux maximal soutenable qui respecte les exigences, y compris les limites d'erreur et les percentiles de latence choisis, constitue une estimation fiable.
Comparez le trafic de production avec la capacité testée. Une faible occupation du cache peut justifier une investigation, mais affirmer une augmentation de dix fois le débit nécessite des preuves de test.
Liez les données OpenCost aux résultats vérifiés
La communauté FinOps relie l'efficacité de l'IA aux coûts et aux résultats concrets. Pour rendre le coût pertinent, il doit être associé aux résultats que l'infrastructure permet de délivrer.
Utilisez l'API d'allocation d'OpenCost pour obtenir les coûts des charges de travail à intervalles définis, puis combinez ces données avec les métriques de service et les enregistrements de résultats en utilisant les identités des charges de travail et les horodatages. OpenCost propose également un suivi des coûts d'inférence par million de tokens.
Calculez le coût par résultat vérifié en divisant le coût total imputable par le nombre de résultats répondant aux exigences de qualité et livrés dans les délais. Incluez les coûts de GPU, CPU, mémoire et autres infrastructures, ainsi que les frais de démarrage et les périodes d'inactivité.
« Connecter les données de coût à des résultats vérifiés permet d'évaluer l'efficacité réelle des ressources. »
Cette approche évite les hypothèses non fondées et assure que chaque dépense est justifiée par un résultat mesurable.