Profilage Nsight Systems

NVIDIA Nsight Systems (nsys) est un outil d'analyse de performance au niveau système qui capture les chronologies d'activité CPU/GPU, les traces d'API et les événements au niveau du système d'exploitation. Contrairement à Nsight Compute (niveau kernel), nsys montre la vue d'ensemble — comment les kernels, les transferts mémoire, la communication et le travail CPU se chevauchent dans le temps.

Quand l'utiliser

Recourez à cette compétence quand vous rencontrez :

• Déclencheurs : L'utilisateur souhaite profiler un script d'entraînement de bout en bout, analyser l'utilisation du GPU, trouver les goulots d'étranglement du pipeline, vérifier le chevauchement communication/calcul, ou interpréter des rapports .nsys-rep
• Symptômes : L'entraînement plus lent que prévu, GPU inactif entre les itérations, besoin de comprendre où le temps est dépensé sur le CPU et le GPU, mauvaise scalabilité en entraînement distribué
• Mots-clés : « nsys », « nsight systems », « GPU timeline », « GPU utilization », « kernel launch overhead », « training profiling », « NCCL overlap », « nsys-rep », « cuda trace », « GPU idle », « pipeline stall », « data loading bottleneck »

N'utilisez PAS cette compétence pour :

• L'optimisation au niveau kernel (utilisez Nsight Compute / ncu à la place)
• Les métriques matérielles GPU comme le débit SM, les taux de cache hit (utilisez ncu)
• Le monitoring GPU sans profiling (utilisez nvidia-smi)
• L'utilisation non-CLI (workflows GUI, intégration IDE) — consultez la documentation officielle

Prérequis

Permissions : nsys peut nécessiter sudo ou CAP_SYS_ADMIN pour le traçage au niveau système et les métriques GPU. Dans les conteneurs, utilisez --privileged ou --cap-add=SYS_ADMIN.

Principes de rapport

Chaque nombre doit avoir une source faisant autorité. Quand vous présentez des données de timing, des comptages de kernels, des durées d'appels API, ou toute métrique quantitative, citez toujours la source : sortie de rapport nsys stats, sortie de règle nsys analyze, résultat de requête SQLite exportée, CSV de recette, ou sortie de commande brute. Montrez la commande réelle et sa sortie avant d'interpréter. Ne synthétisez jamais, n'estimez pas et n'extrapolez pas des nombres qui ne proviendraient pas d'une sortie d'outil.

Utilisez nsys stats pour l'analyse structurée, pas les données brutes de trace. Extrayez toujours les métriques via des commandes nsys stats -r <report> ciblées plutôt que de tenter de lire ou d'interpréter directement les fichiers .nsys-rep. Les rapports de stats produisent des résumés compacts et tabulaires ; les données brutes de trace peuvent être énormes (surtout avec des backtraces ou du traçage API verbose). Lancez le plus petit ensemble de rapports nécessaires pour la tâche, puis demandez des rapports supplémentaires seulement si les résultats initiaux soulèvent des questions.

Workflows

Workflow 1 : Profiler un script d'entraînement DL

Objectif : Capturer un profil propre et ciblé des itérations d'entraînement en régime permanent.

Étape 1 — Ajouter des marqueurs de profiler à votre script d'entraînement pour ignorer l'échauffement :

# Dans le script d'entraînement
for i, batch in enumerate(train_loader):
    if i == warmup_iters:
        torch.cuda.cudart().cudaProfilerStart()
    train_step(model, batch)
    if i == warmup_iters + profile_iters:
        torch.cuda.cudart().cudaProfilerStop()
        break

Étape 2 — Profiler avec la plage de capture cudaProfilerApi :

nsys profile -c cudaProfilerApi \
    -t cuda,nvtx,cudnn,cublas \
    --pytorch=autograd-nvtx \
    -o train_profile -- python train.py

Cela capture uniquement les itérations en régime permanent — pas d'échauffement, pas de bruit d'initialisation.

Note : -t cuda,nvtx,cudnn,cublas active le traçage spécifique à l'API. Par défaut, -t cuda ne trace que la couche runtime/driver CUDA — vous voyez les noms des kernels et les temps de lancement mais ne pouvez pas les attribuer aux bibliothèques de haut niveau. Ajouter cudnn et cublas trace les appels d'API au niveau bibliothèque, vous permettant de distinguer le temps de convolution (cuDNN) du temps GEMM (cuBLAS) et de mesurer le surcoût de la bibliothèque séparément de l'exécution brute du kernel.

Étape 3 — Résumé rapide :

nsys stats -r cuda_gpu_kern_sum,cuda_api_sum,cuda_gpu_mem_time_sum \
    train_profile.nsys-rep

Quand vous avez tracé les APIs de bibliothèque (cudnn, cublas dans -t), lancez aussi les rapports spécifiques à la bibliothèque pour voir le surcoût au niveau API (allocation d'espace de travail, sélection d'algorithme) séparé de l'exécution brute du kernel :

nsys stats -r cudnn_api_sum,cublas_api_sum train_profile.nsys-rep

Étape 4 — Détecter les anti-patterns :

nsys analyze -r all train_profile.nsys-rep

Étape 5 — Creuser plus profondément selon les résultats. Voir les références Tier 2.

Workflow 2 : Diagnostiquer l'inactivité du GPU

Objectif : Trouver pourquoi le GPU est inactif entre les itérations d'entraînement.

Étape 1 — Profiler avec traçage du runtime OS :

nsys profile -t cuda,nvtx,osrt \
    --pytorch=autograd-nvtx \
    -o idle_debug -- python train.py

Étape 2 — Vérifier les lacunes et l'utilisation GPU :

nsys analyze -r gpu_gaps,gpu_time_util idle_debug.nsys-rep

Étape 3 — Vérifier les phases de lancement de kernel :

nsys stats -r cuda_kern_exec_sum idle_debug.nsys-rep

Temps de queue élevé = GPU était occupé (ce n'est pas le problème). Temps de queue quasi-nul pour tous les kernels = GPU était affamé (l'hôte ne soumettait pas le travail assez vite).

Étape 4 — Causes courantes et corrections :

Workflow 3 : Profiler l'entraînement distribué

Objectif : Profiler l'entraînement multi-GPU/multi-nœud avec analyse de communication.

Étape 1 — Collecter les profils par rang :

nsys profile -t cuda,nvtx,mpi,ucx \
    --pytorch=autograd-nvtx \
    -o profile_%q{RANK} \
    -- torchrun --nproc_per_node=8 train.py

Étape 2 — Analyser le chevauchement communication/calcul NCCL :

nsys recipe nccl_gpu_overlap_trace -- profile_*.nsys-rep
nsys recipe nccl_gpu_time_util_map -- profile_*.nsys-rep

Étape 3 — Vérifier l'utilisation par rang :

nsys recipe cuda_gpu_time_util_map -- profile_*.nsys-rep

Étape 4 — Vérifier les retardataires :

Comparez cuda_gpu_kern_sum entre les rangs. Si un rang est plus lent, vérifiez ses modèles de réseau et de chargement de données.

Workflow 4 : Analyser la cohérence du temps d'itération

Objectif : Vérifier si les itérations d'entraînement sont stables ou ont des valeurs aberrantes.

# Profiler avec marqueurs d'itération NVTX
nsys profile --pytorch=autograd-nvtx -t cuda,nvtx \
    -o iter_check -- python train.py

# Vérifier la distribution du timing d'itération
nsys stats -r nvtx_pushpop_sum iter_check.nsys-rep

# Vérifier la projection GPU par plage NVTX
nsys stats -r nvtx_gpu_proj_sum iter_check.nsys-rep

# Analyse visuelle du rythme
nsys recipe nvtx_pace -- iter_check.nsys-rep

Un écart-type élevé dans la durée d'itération indique une incohérence — enquêtez sur les itérations aberrantes sur la chronologie.

Workflow 5 : Attribuer les kernels au code source via les backtraces

Objectif : Identifier quelle fonction Python ou quel chemin de code déclenche les kernels GPU coûteux.

Étape 1 — Profiler avec collecte de backtrace :

nsys profile -t cuda,nvtx \
    --backtrace=cuda \
    --python-backtrace=lbr \
    --pytorch=autograd-nvtx \
    -o stacktrace_profile -- python train.py

• --backtrace=cuda : Capture les stacks d'appels CUDA (frames C/C++) de sorte que chaque cudaLaunchKernel montre la chaîne d'appels côté hôte qui l'a déclenchée.
• --python-backtrace=lbr : Capture les stacks d'appels au niveau Python, corrélant le travail GPU avec des fonctions Python spécifiques (par ex., compute_attention vs compute_ffn).

Étape 2 — Obtenir le résumé du kernel et l'attribution NVTX :

Utilisez des rapports de stats ciblés pour identifier les kernels principaux et leur contexte NVTX :

# Kernels principaux par temps GPU total
nsys stats -r cuda_gpu_kern_sum stacktrace_profile.nsys-rep

# Kernels attribués aux plages NVTX (mappe les kernels aux régions de code annotées)
nsys stats -r nvtx_kern_sum stacktrace_profile.nsys-rep

Le rapport nvtx_kern_sum (nécessite --pytorch=autograd-nvtx ou des annotations NVTX manuelles) mappe chaque kernel à sa plage NVTX englobante, montrant directement quelle fonction Python ou opération autograd l'a lancée. C'est plus efficace que de croiser manuellement les données brutes de backtrace.

Étape 3 — Pour les modèles PyTorch, --pytorch=autograd-nvtx enveloppe automatiquement chaque opération autograd dans une plage NVTX. Combiné avec la backtrace, cela mappe : Kernel GPU → Appel d'API CUDA → Fonction Python → Opération autograd PyTorch.

Quand l'utiliser : Les charges de travail avec plusieurs chemins de code lançant des kernels similaires (par ex., attention vs FFN appellent tous les deux GEMM). Les stack traces désambiguïsent quel appelant est responsable du temps de kernel dominant.

Formats de sortie

Fichiers de rapport (.nsys-rep) : Format binaire, visualisable en GUI ou traitable avec nsys stats, nsys analyze, nsys export, nsys recipe.

Formats de sortie Stats : column (terminal), csv, json, table, tsv, hdoc, htable.

Formats d'export : sqlite (requêtes SQL), arrow/parquetdir (Pandas/Dask), hdf, jsonlines, text.

Sortie de recette : Répertoire avec données CSV/Parquet + visualisations HTML Plotly + .nsys-analysis (notebook Jupyter).

Colonnes clés du rapport stats :

Exemples

Exemple 1 : Profil DL rapide et résumé

# Profiler
nsys profile -t cuda,nvtx,cudnn,cublas \
    --pytorch=autograd-nvtx --stats=true \
    -o quick_profile -- python train.py

# Génère automatiquement les stats à la fin du profiling

Exemple 2 : Détecter la memcpy synchrone dans DataLoader

nsys profile -t cuda,nvtx -o dataloader_check -- python train.py
nsys analyze -r cuda_memcpy_sync,cuda_memcpy_async dataloader_check.nsys-rep

Si signalée, corrigez avec :

loader = DataLoader(dataset, pin_memory=True, num_workers=4)
tensor_gpu = tensor_cpu.to(device, non_blocking=True)

Exemple 3 : Analyse NCCL multi-nœud

# Collecter
nsys profile -t cuda,nvtx,mpi -o rank_%q{RANK} \
    -- torchrun --nproc_per_node=8 train.py

# Analyser le chevauchement
nsys recipe nccl_gpu_overlap_trace -- rank_*.nsys-rep

# Visualiser
nsys recipe nccl_gpu_time_util_map -- rank_*.nsys-rep

Exemple 4 : Décomposition au niveau API (cuDNN vs cuBLAS)

# Profiler avec traçage au niveau bibliothèque
nsys profile -t cuda,nvtx,cudnn,cublas \
    -o api_breakdown -- python model.py

# Résumé API cuDNN (appels de convolution)
nsys stats -r cudnn_api_sum api_breakdown.nsys-rep

# Résumé API cuBLAS (appels GEMM)
nsys stats -r cublas_api_sum api_breakdown.nsys-rep

# Comparer avec la vue au niveau kernel
nsys stats -r cuda_gpu_kern_sum api_breakdown.nsys-rep

Les rapports au niveau API (cudnn_api_sum, cublas_api_sum) montrent le temps passé dans les appels de bibliothèque incluant le surcoût (allocation d'espace de travail, sélection d'algorithme), tandis que cuda_gpu_kern_sum affiche uniquement l'exécution brute du kernel GPU. La différence révèle le surcoût côté bibliothèque.

Gestion des erreurs

Trouver plus d'informations

Tier 1 : Ce fichier (SKILL.md)

Vous le lisez maintenant. Les workflows et le tableau d'erreurs ci-dessus couvrent les tâches de profiling DL les plus courantes. Cherchez d'abord dans ce fichier.

Tier 2 : Répertoire references/

Utilisez grep pour les mots-clés dans references/ — les en-têtes sont compatibles grep :

• references/cli-profiling.md — Drapeaux complets nsys profile pour DL
• references/cli-post-collection.md — Commandes nsys stats, analyze, export, recipe
• references/app-preparation.md — Profiling ciblé, marqueurs NVTX, patterns PyTorch
• references/stats-reports.md — Colonnes et significations des rapports statistiques CUDA
• references/expert-systems.md — Règles du système expert, détection d'anti-patterns
• references/recipes-dl.md — Recettes avancées pertinentes pour DL avec exemples
• references/nvtx-analysis.md — Rapports statistiques NVTX pour code annoté

Comment chercher :

1. Grep pour votre mot-clé dans references/
2. Lisez uniquement le fichier vers lequel grep pointe

Tier 3 : Documentation officielle

Si les Tiers 1-2 ne répondent pas :

• User Guide — Référence complète CLI, toutes les options de traçage
• Analysis Guide — Rapports stats, systèmes experts, recettes

Utilisez WebFetch ou WebSearch pour ces URLs et consultez le contenu le plus récent. Envisagez de distiller les nouvelles découvertes dans references/.