perf-analysis

Par nvidia · skills

Workflow de coordination pour l'analyse des performances. Oriente la délégation du profiling, la classification des goulots d'étranglement (calcul/mémoire/lancement/communication/synchronisation) et la génération de rapports structurés. À utiliser lorsque l'utilisateur demande d'analyser les performances, de profiler une charge de travail, de vérifier le MFU/SOL ou de diagnostiquer des goulots d'étranglement.

npx skills add https://github.com/nvidia/skills --skill perf-analysis

Analyse de Performance

Principes

  1. Déléguer le profilage, maîtriser l'analyse. Tu coordonnes le flux de travail d'analyse mais n'exécutes pas directement les outils de profilage. Délègue toutes les tâches de profilage et de mesure à perf-profiling-specialist ou à d'autres spécialistes du domaine.
  2. Métriques issues des outils, jamais inventées. Tous les nombres de performance doivent provenir de la sortie des outils de profilage. Ne jamais fabriquer de métriques.
  3. Classifier avant de recommander. Identifie le type de goulot avant de suggérer des optimisations. Une mauvaise classification conduit à des efforts gaspillés.
  4. Rapports structurés. Chaque analyse produit un rapport avec Résumé, Métriques, Findings et Recommandations.

Métriques Clés de Performance

  • Throughput: samples/sec, tokens/sec, iterations/sec
  • Latency: temps bout en bout, temps noyau, temps de communication
  • MFU (Model FLOPs Utilization): FLOPs réels / FLOPs théoriques de crête
  • % of SOL (Speed of Light): perf actuelle / perf de crête du matériel
  • GPU Utilization: occupancy SM, utilisation tensor core
  • Memory Bandwidth: utilisation bande passante DRAM vs crête

Flux de Travail d'Analyse

  1. Comprendre: Clarifier quelles métriques l'utilisateur a besoin (MFU, SOL, latency, etc.)
  2. Planifier: Planifier tes étapes de profilage et d'analyse avant de commencer
  3. Profiler: Déléguer à perf-profiling-specialist pour les mesures réelles
  4. Mesurer: Extraire les métriques demandées des résultats de profilage
  5. Classifier: Si tu diagnostiques des problèmes, détermine le type de goulot primaire
  6. Rapporter: Générer un rapport d'analyse de performance avec findings

Classification des Goulots

Quand tu diagnostiques des problèmes de performance, classe le goulot primaire :

Type Indicateur Description
Compute-bound Utilisation GPU élevée, utilisation bande passante mémoire faible Limité par la capacité de calcul (FLOPs)
Memory-bound Bande passante mémoire élevée, utilisation calcul faible Limité par le débit DRAM
Launch-overhead Nombreux petits kernels, temps CPU élevé CPU devient goulot à cause du surcoût de lancement de kernels
Communication-bound Temps significatif dans les opérations collectives Limité par la communication inter-GPU ou inter-nœud
Sync-bound Points de synchronisation CPU-GPU excessifs Ralentissements dus à des synchronisations inutiles

Directives de Délégation

Quand tu délègues à des spécialistes, décris le résultat souhaité -- pas la méthodologie de l'outil.

À INCLURE:

  • La charge de travail: chemin de fichier, extrait de code, ou commande à profiler
  • Contexte du problème: dimensions, dtypes, calculs FLOPs, batch sizes
  • Métriques souhaitées: SOL%, MFU, throughput, occupancy, classification des goulots
  • Contraintes éventuelles: kernel spécifique à cibler, marqueurs de région de profilage

À NE PAS INCLURE:

  • Drapeaux spécifiques de l'outil ou patterns de commandes (ex. --set=full, --section SpeedOfLight)
  • Instructions étape par étape d'utilisation de l'outil
  • Stratégies de secours en cas d'échec de l'outil
  • Commandes d'exemple
  • Chemins de fichiers de sortie ou emplacements d'artefacts (les spécialistes créent leurs propres artefacts d'espace de travail)

Les spécialistes ont leurs propres skills qui codifient les bonnes pratiques pour l'utilisation d'outils et leurs propres artefacts d'espace de travail pour la sortie. Prescrire des commandes dans la délégation surcharge leurs skills et peut mener à des stratégies de profilage non optimales (ex. collecter 8000+ métriques avec --set=full quand une analyse de section ciblée serait plus rapide et plus précise).

Bon Exemple

Profiler le kernel GEMM en batch dans bmm_workload.py avec NCU.
La charge de travail utilise des marqueurs cudaProfilerStart/Stop pour isoler la région d'intérêt.
Collecter les métriques au niveau kernel: SOL%, throughput calcul/mémoire, bande passante DRAM,
utilisation tensor core, occupancy, raisons des stalls de warp, et classification roofline.
Le GEMM en batch effectue 68,72 GFLOP par appel (B=32, M=512, N=1024, K=2048, FP16).
Calculer le MFU par rapport aux TFLOP/s de crête FP16 tensor core du GPU.

Mauvais Exemple

Exécuter NCU avec --set=full --profile-from-start off --target-processes all.
Si --set=full échoue, essayer --set=detailed. Parser la sortie CSV pour
sm__throughput.avg.pct_of_peak_sustained_elapsed.
Sauvegarder la sortie NCU brute dans /workspace/.../ncu_output.txt.

Profilage Distant

Quand tu profiles sur un cluster SLURM distant, inclus le bloc Remote Execution Context dans la délégation avec le wrapper SSH+srun pour le cluster cible. Le perf-profiling-specialist préfixera ses commandes (nsys, ncu, nvidia-smi) avec ce wrapper.

Le perf-profiling-specialist n'a pas besoin du skill remote-slurm — le bloc de contexte fournit tout ce dont il a besoin pour exécuter à distance.

Spécialistes Disponibles

Délègue le profilage et l'analyse spécifique au domaine à ces spécialistes :

  • perf-profiling-specialist: Exécute nvidia-smi, nsys, ncu, torch.profiler. À utiliser pour TOUTES les tâches de profilage.
  • perf-torch-cuda-graph-specialist: Analyse la compatibilité CUDA Graph et applique les flux de capture

Format du Rapport

Structure chaque rapport d'analyse avec ces quatre sections :

  1. Résumé: État de performance de haut niveau ou classification du goulot
  2. Métriques: Nombres de performance clés issus du profilage
  3. Findings: Observations détaillées avec preuves
  4. Recommandations: Liste priorisée des optimisations (si applicable)

Exemple de Rapport

## Résumé
Entraînement à 42% MFU, limité par la mémoire en raison de grands tenseurs d'attention.

## Métriques
- Throughput: 1 247 samples/sec
- MFU: 42% (vs 65% théorique pour ce modèle)
- % of SOL: 58% (espace pour une amélioration de 1,7x)
- GPU Utilization: 45%
- Memory Bandwidth: 850 GB/s (89% de la crête)
- Kernel Count: 1 247 par itération

## Findings
1. L'auto-attention consomme 60% de la bande passante mémoire
2. L'étape optimizer a 3 synchronisations inutiles
3. La batch size pourrait être augmentée de 2x

## Recommandations
1. Activer FlashAttention (résultat attendu: +15% MFU)
2. Supprimer les synchronisations dans l'optimizer (résultat attendu: +5% throughput)
3. Augmenter la batch size pour améliorer l'utilisation GPU

Skills similaires