dyl-joseph/DiT-Autoresearch

Compétence DiT AutoResearch A5500

Utilisez cette compétence lors de l'optimisation de l'inférence des Transformers de Diffusion sur du matériel RTX A5500/Ampere.

Règles non-négociables

• Lisez program.md avant d'agir.
• Considérez knowledge/handbook/00_foundations/04_target_hardware_and_quality_contract.md comme la référence du projet remplaçant les conseils génériques sur le matériel/la précision.
• La qualité est une contrainte stricte, pas un objectif pondéré.
• La quantification ne peut être testée que si la suite de benchmarks fixe ne montre aucune régression de qualité/précision requise. Ne conservez jamais un candidat quantifié avec un score de benchmark requis inférieur.
• Ne modifiez pas le corpus de benchmarks, l'évaluateur de qualité, le harnais de performance ou les autres fixed_paths pendant une session.
• Modifiez uniquement les chemins listés dans mutable_paths.
• Établissez d'abord la référence non modifiée.
• Comparez la qualité du candidat avec la référence originale, pas avec le candidat précédent.
• Comparez les performances avec le meilleur candidat actuel dans la branche d'objectif.
• Une hypothèse causale par commit.
• Privilégiez les optimisations d'implémentation exactes avant les approximations numériques ou algorithmiques.
• Mesurez sur A5500. N'importez pas les nombres d'accélération H100/B200 comme résultats attendus sur A5500.
• FlashAttention-2/SDPA sont des chemins d'attention Ampere pertinents ; les fonctionnalités spécifiques à FA3/FA4 et Hopper/Blackwell sont des références de recherche, pas des chemins natifs pour la cible.

Démarrage obligatoire

1. Lisez program.md complètement.
2. Lisez les fichiers du guide suivants :
   • knowledge/handbook/00_foundations/04_target_hardware_and_quality_contract.md
   • knowledge/handbook/00_foundations/02_benchmarking_and_quality_gates.md
   • knowledge/handbook/03_single_gpu/08_a5500_optimization_ladder.md
   • knowledge/handbook/02_bottlenecks/05_nsight_a5500_profiling_workflow.md
   • knowledge/handbook/09_reference/09_a5500_benchmark_runbook.md
   • knowledge/handbook/09_reference/10_reproducibility_and_claims_standard.md
3. Exécutez dit-ar --config config/autoresearch.json doctor.
4. Assurez-vous que la branche de recherche est autoresearch/<tag> et que l'arbre de travail est propre.
5. Exécutez dit-ar ... init s'il s'agit d'une nouvelle session.
6. Exécutez dit-ar ... baseline avant de modifier le code optimisé.

Récupération de connaissances

Avant une expérience non triviale, parcourez le guide :

dit-ar --config config/autoresearch.json search "<mécanisme + goulot + termes modèle/matériel>"

Lisez les fichiers Markdown les plus pertinents. Utilisez le guide comme mémoire de recherche locale principale. Lorsqu'il ne soutient pas une hypothèse, étiquetez l'idée comme une hypothèse de recherche externe/nouvelle au lieu de prétendre que le guide la recommande.

Classification des expériences

Utilisez l'une des suivantes :

• exact : modifications d'implémentation/disposition/ordonnancement/mémoire destinées à préserver l'algorithme ;
• numerical : changements de mode arithmétique tels que le comportement FP16↔BF16 ou TF32 ;
• approximate : calcul du modèle modifié/sauté tel que moins d'étapes, caches approximatifs, coupure de guidage, approximation creuse ;
• quantization : tout chemin de poids/activation/attention/stockage en bits faibles.

La quantification reçoit automatiquement une passerelle de qualité stricte sans régression.

Boucle de conservation/rejet

Pour chaque hypothèse :

1. Inspectez les meilleures métriques actuelles et les échecs récents.
2. Recherchez/lisez le matériel pertinent du guide.
3. Énoncez l'hypothèse et le changement de goulot attendu.
4. Modifiez uniquement les chemins mutables.
5. Exécutez une vérification syntaxique/rapide si utile.
6. Validez le candidat.
7. Exécutez :

dit-ar --config config/autoresearch.json experiment \
  --classification <classe> \
  --description "<courte hypothèse causale>"

8. Si CONSERVER, restez sur le commit et continuez.
9. Si REJETER, conservez les journaux .autoresearch/, puis git reset --hard HEAD^ pour revenir au précédent meilleur.
10. Si PLANTAGE, corrigez uniquement si l'implémentation est trivialement erronée ; sinon, rejetez et passez à autre chose.
11. Continuez jusqu'à arrêt manuel.

Priorités de recherche sur A5500

Favorisez, approximativement dans cet ordre :

• profilage de bout en bout et attribution de phases ;
• sélection du backend d'attention pour les formes exactes ;
• compilation/compilation régionale et suppression des ruptures de graphe ;
• fusion des opérations de normalisation/modulation/ponctuelles ;
• Graphes CUDA pour les compartiments de forme stables ;
• réglage de l'algorithme/disposition GEMM ;
• élimination des transferts et ordonnancement du cycle de vie des composants ;
• ingénierie de la mémoire VRAM de 24 Go avec déchargement/expulsion/quadrillage ;
• stratégies à deux A5500 sensibles à la topologie si disponibles ;
• Triton/CUDA/CUTLASS personnalisés uniquement après preuve du profileur ;
• approximations et quantification uniquement derrière le pare-feu de qualité complet.

N'optimisez jamais une métrique dont le produit cible ne se soucie pas simplement parce qu'elle est facile à améliorer.