Optimiser les Performances de NVSHMEM

Objectif

Guider l'utilisateur vers le plus petit workflow de performance NVSHMEM applicable. Proposer une collecte de baseline optionnelle et trois services d'optimisation ciblés tout en préservant les entrées de chaque spécialiste, sa limite d'exécution et ses règles de sécurité.

Ne reproduis pas les conseils techniques des spécialistes dans ce routeur. Invoque :

Exigences

• Rendre les quatre spécialistes listés ci-dessus disponibles ; ce routeur délègue tous les travaux techniques à ces derniers.
• Ne nécessite aucune clé API, accès cluster, installation NVSHMEM, ou outils de benchmark pour sélectionner une route. Le spécialiste sélectionné établit tout prérequis spécifique à l'environnement avant d'agir.

Entrées

Obligatoires

• Obtenir l'objectif de performance NVSHMEM ou le service sélectionné par l'utilisateur. Quand la demande est insuffisamment spécifiée, exige une sélection explicite parmi les alternatives de workflow de la Section 2 avant d'invoquer un spécialiste.

Optionnels

• Réutilise tout rapport de performance fourni, logs bruts, version exacte et préfixe d'installation NVSHMEM, chemin source ou kernel, fabric et provider, échelle de job, binding PE-to-GPU, topologie GPU/NIC, transport sélectionné, contraintes de tuning et objectif d'optimisation.
• Réutilise les résultats pertinents et conditions non résolues d'un spécialiste antérieur dans le même workflow.
• Demande uniquement les informations nécessaires pour résoudre la cible de routage. Laisse le spécialiste sélectionné inspecter l'environnement ou demander ses propres entrées requises.

Privilégie la demande utilisateur explicite actuelle, puis les arguments d'invocation explicites, puis le contexte sans conflit et la sortie du spécialiste antérieur. Signale les valeurs conflictuelles plutôt que de choisir silencieusement.

Instructions

1. Résoudre la Cible de Routage

Respecte un spécialiste ou workflow nommé explicitement. Sinon, classifie l'objectif concret :

• Achemine les demandes de baseline de performance, courbes de benchmark, tests de latence ou bandwidth, vérifications de performance, ou preuves système packagées vers la collecte de données de performance.
• Achemine les demandes concernant NVSHMEM_REMOTE_TRANSPORT, IBRC, IBDevX, IBGDA, GPUNetIO, UCX, libfabric, compatibilité réseau distant, ou sélection d'une voie de données inter-nœud vers la sélection de transport distant.
• Achemine les demandes concernant la sélection d'HCA, ports NIC, affinité GPU-to-NIC, utilisation multi-NIC, NVSHMEM_HCA_*, ou assignation PE-to-NIC vers le mappage NIC-to-PE.
• Achemine les demandes concernant TMA, NVSHMEM_TMA_POLICY, enregistrement de mémoire partagée CTA, transferts de mémoire partagée directs, ou préparation d'un kernel CUDA pour TMA vers l'activation de TMA.

Invoque un spécialiste pour une demande concrète unique. Indique quel spécialiste est invoqué et pourquoi.

2. Résoudre une Demande de Performance Insuffisamment Spécifiée

Quand la demande énonce seulement une intention générale d'améliorer ou tuner les performances NVSHMEM, ne sélectionne pas de spécialiste et n'exécute rien. Présente ces alternatives de workflow et exige une sélection explicite :

1. Workflow de caractérisation de baseline : collecter les preuves initiales de performance et système avant de sélectionner un domaine d'optimisation.
2. Workflow d'optimisation ciblée : procéder sans collecte préliminaire et sélectionner l'une des alternatives :
   • sélection de transport distant inter-nœud ;
   • mappage NIC-to-PE conscient de la topologie ;
   • évaluation ou activation de la pertinence de TMA pour les chemins kernel GPU peer/NVLink éligibles.

Permets la collecte de données de performance comme portée terminale. Distingue brièvement les trois domaines d'optimisation sans en recommander un en l'absence de preuves.

3. Séquencer les Workflows Explicites Multi-Étapes

1. Invoque la collecte de données de performance en premier seulement quand l'utilisateur la demande, sélectionne le workflow de caractérisation de baseline, ou spécifie explicitement une séquence collection-first. Laisse cette skill obtenir sa sélection de benchmark requise avant toute exécution.
2. Invoque la sélection de transport distant avant le mappage NIC-to-PE quand les deux sont demandés. Passe le transport sélectionné, version, provider, preuves de topologie et conditions non résolues dans le workflow de mappage.
3. Invoque TMA séparément. Ne traite pas TMA comme une optimisation de transport distant et ne déduise pas que des preuves de benchmark inter-nœud établissent l'éligibilité TMA.
4. Invoque aucun spécialiste non demandé. Laisse le spécialiste actif résoudre ses propres prérequis au lieu de les remplir.

Après la fin de la collecte de données, invoque un spécialiste d'optimisation déjà sélectionné par l'utilisateur. Si aucun domaine d'optimisation n'a été sélectionné, présente les trois alternatives d'optimisation ciblée à nouveau et exige une sélection explicite.

4. Préserver la Passation

• Passe la demande originale, contraintes explicites, chemins exacts, commandes, logs, valeurs de configuration, portée source, artefacts bruts, faits résolus et sortie pertinente du spécialiste antérieur.
• Préserve les paramètres de transport et contraintes de tuning de l'utilisateur pendant la collecte et la comparaison ultérieure.
• Retourne le résultat du spécialiste sans remplacer sa confiance, ses inconnues, son statut de validation ou ses suivis demandés.
• Maintiens l'exécution de benchmark, l'inspection système, les éditions de source et les changements de configuration à l'intérieur de l'autorisation et des garde-fous du spécialiste sélectionné.

5. Gérer un Spécialiste Indisponible

Si une skill requise est indisponible, nomme-la, explique quel service demandé ne peut pas procéder et demande à l'utilisateur de la rendre disponible ou de choisir un autre service. N'imite ou reconstruis pas la skill manquante.

Limitations

• N'exécute pas directement de benchmarks, collecteurs, lanceurs ou applications cibles de ce routeur.
• N'édite pas CUDA source, ne génère pas d'exports de transport ou ne synthétise pas de mappages NIC directement de ce routeur.
• Ne rends pas la collecte de données un prérequis implicite simplement parce qu'une optimisation pourrait bénéficier d'une mesure ultérieure.
• Ne promets pas une amélioration de performance ou ne déclare pas une régression sans les preuves requises par le spécialiste sélectionné.
• Ne traite pas TMA comme utile pour le trafic réseau distant ; achemine-le uniquement comme un workflow d'optimisation distinct peer GPU/NVLink.
• N'achemine pas les questions NCCL non liées, CUDA-only, système d'exploitation ou performance d'application générale vers ces skills NVSHMEM.

Exemples

Achemine une demande de collecte de preuves avant de choisir une optimisation :

User: Collect a baseline for our two-node NVSHMEM all-to-all before tuning it.
Action: Invoke $nvshmem-collect-performance-data and preserve the two-node and all-to-all constraints.

Achemine une demande explicite de configuration réseau directement :

User: Which NVSHMEM remote transport should we use with this InfiniBand cluster?
Action: Invoke $nvshmem-select-remote-transport because the request concerns an inter-node data path.

Dépannage