Expliquer les attentes avant de chercher un GPU plus puissant.

Décrire le problème avec un résultat et une fenêtre

Remplacez « le GPU ne travaille pas » par une observation vérifiable : le premier résultat arrive tard, les étapes présentent des pauses ou le nombre de sorties acceptées diminue. Donnez le jeu d’entrées, la version de l’application, les réglages et la période observée. Un premier lancement peut inclure des phases différentes d’une exécution déjà préparée ; ne les mélangez pas sans le préciser.

Découpez le parcours en ouverture des fichiers, préparation CPU, transfert, calcul GPU, écriture puis validation. Ces phases peuvent se chevaucher : le dessin constitue une hypothèse à confronter aux traces. Notez les bornes avec le même fuseau horaire et une précision suffisante. Un graphique matériel pris après la pause ne permet pas d’expliquer la pause, même si sa valeur paraît inhabituelle.

Lire correctement les pourcentages et les mémoires

Dans NVIDIA SMI, l’utilisation GPU indique la part de l’intervalle d’échantillonnage pendant laquelle au moins un noyau s’exécutait. Ce n’est pas une note de rendement de tous les composants. L’utilisation de la mémoire décrit son activité de lecture ou d’écriture ; elle ne doit pas être confondue avec la quantité de mémoire occupée. La documentation précise aussi que certains champs peuvent être indisponibles selon l’environnement.

Conservez donc le nom exact de la métrique et son unité. Une quantité de mémoire élevée peut correspondre à des données conservées en attente ; une faible activité peut apparaître pendant une phase normale de préparation. À l’inverse, une activité élevée n’établit pas que le programme réalise un travail utile. Il faut regarder les sorties et la progression applicative en même temps que le matériel.

Recueillir un relevé corrélé et suffisamment court

Choisissez une séquence représentative et limitez la collecte à cette séquence. Relevez les heures, l’identifiant du GPU, l’activité, la mémoire occupée et les phases de l’application. En parallèle, utilisez les outils disponibles sur votre système pour observer le processus CPU, ses attentes, ses lectures et écritures. Une moyenne sur tous les cœurs peut masquer un seul fil saturé ; regardez aussi les processus concernés.

La commande de lecture ci-dessous est proposée pour une cible NVIDIA autorisée disposant déjà de NVIDIA SMI. Elle n’a pas été exécutée pour ce guide. Elle conserve les unités dans le CSV et affiche une observation par seconde jusqu’à son interruption. Vérifiez les champs pris en charge par votre version et arrêtez la collecte à la fin du scénario. Un champ N/A reste inconnu : ne le transformez pas en zéro.

Le journal minimum relie un identifiant de travail, une heure avec fuseau, la phase courante, une entrée ou un lot identifiable, la progression et l’erreur éventuelle. Il ne doit contenir ni secret ni contenu métier inutile au diagnostic. Si la télémétrie manque, vérifiez d’abord son dispositif de collecte et la progression applicative : une courbe vide ne prouve pas un processus arrêté. Marquez la période sans observation au lieu de la reconstituer de mémoire.

nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1

Faire la différence entre une piste et une conclusion

Si l’activité GPU baisse pendant que l’application attend ses entrées, examinez le chemin des fichiers. Si elle baisse pendant une préparation CPU longue, examinez cette phase et son parallélisme réel. Si les périphériques attendent les autres participants d’un travail distribué, vérifiez l’équilibre des charges et les communications. Plusieurs symptômes peuvent se produire ensemble ; leur corrélation n’est pas encore une preuve de causalité.

Écrivez une hypothèse courte et une modification qui permet de la départager. Par exemple, comparer les mêmes entrées déjà préparées à leur préparation habituelle peut isoler une étape, à condition que les résultats restent identiques. Ne changez pas simultanément la taille du lot, la précision, le nombre de processus et la localisation des fichiers : une amélioration deviendrait difficile à attribuer.

Exemple fictif : analyser une boucle de cent secondes

L’équipe fictive « Revue des maquettes » décrit une boucle sans recouvrement : soixante secondes de préparation CPU, vingt de calcul GPU, puis vingt d’export. Le total est 100 secondes et la fraction temporelle attribuée au calcul GPU vaut 20/100, soit 20 %. Ce calcul pédagogique ne prédit pas le pourcentage d’un outil d’échantillonnage et ne correspond à aucune mesure d’un GPU du catalogue.

Supposons que la préparation puisse être ramenée à trente secondes, sans changer le calcul ni les sorties. La boucle ferait alors 30 + 20 + 20 = 70 secondes : trente secondes de moins, avec une fraction GPU de 20/70, soit environ 28,6 %. À l’inverse, diviser hypothétiquement le seul calcul GPU par deux donnerait 60 + 10 + 20 = 90 secondes. Le scénario explique pourquoi traiter la plus longue attente peut peser davantage que changer de carte.

Approfondir une phase avec un profileur

Si l’observation générale localise une zone lente sans l’expliquer, utilisez le profileur adapté à l’application sur une fenêtre courte. PyTorch Profiler peut recueillir des événements CPU et CUDA et organiser des fenêtres de collecte. La documentation signale un surcoût lorsque l’enregistrement des formes ou des piles est activé. Une trace détaillée est donc un instrument de diagnostic ; son temps total ne doit pas être présenté sans réserve comme le temps normal du programme.

Gardez les noms de phases assez explicites pour relier une opération technique à votre travail : préparation d’un groupe de fichiers, transfert, étape applicative ou publication de sortie. Commencez avec le niveau de détail nécessaire à l’hypothèse. Après la modification, refaites une observation comparable puis une exécution sans instrumentation lourde. Ce second contrôle permet de vérifier que le bénéfice existe aussi dans les conditions usuelles.

Éviter les corrections qui masquent le problème

Augmenter la concurrence peut remplir le GPU tout en surchargeant le disque, la mémoire hôte ou les sorties. Accroître la taille des lots peut changer la latence et la mémoire nécessaire. Réduire la précision peut modifier le résultat. Ces décisions ne sont pas interdites, mais elles doivent être évaluées sur le même objectif métier, avec leurs effets secondaires, plutôt que retenues parce que le pourcentage affiché augmente.

Ne réinitialisez pas un périphérique et ne modifiez pas ses paramètres matériels pour diagnostiquer une simple baisse d’activité. Commencez par la lecture, puis faites examiner les erreurs explicites par le responsable autorisé. Évitez aussi de publier des traces brutes contenant chemins privés, paramètres confidentiels ou données d’entrée. Préparez un extrait utile au diagnostic et conservez la preuve complète dans le périmètre autorisé de l’équipe.

Clore le diagnostic avec une preuve utile à la décision

Le dossier final doit indiquer le symptôme, l’hypothèse retenue, le changement essayé, ses conditions et le résultat observé. Conservez au moins une comparaison avant/après sur le même jeu d’entrées, la même qualité et la même définition de fin. Si le résultat n’est pas concluant, écrivez ce qui a été éliminé et la prochaine observation nécessaire. Une piste rejetée documentée évite qu’une autre personne recommence au hasard.

Une faible activité normale ne demande pas toujours une correction. Si la tâche respecte son délai, sa qualité et son budget, réduire une complexité peut être préférable à une optimisation fragile. Si une nouvelle configuration est envisagée, transmettez les contraintes démontrées au dossier de réception. Aucun relevé isolé ne classe le catalogue et aucune valeur de cet exemple ne constitue une performance promise.