Principe de fonctionnement

L’outil Agentic CUDA Optimizer transforme une description de charge de travail en implémentation GPU via un cycle itératif d'édition de code, de vérification de correction et de mesure de performance. Le processus démarre avec une signature de kernel, des cas d'entrée et, le cas échéant, un kernel de référence. Chaque itération compile le candidat avec NVRTC, exécute les cas d'entrée via l'API CUDA Driver, compare les sorties à l'aide de NumPy et mesure la latence avec des événements CUDA. Le modèle de langage, par défaut gpt-5-mini avec effort de raisonnement moyen, propose des modifications de code ou de configuration de lancement, puis reçoit le feedback des mesures pour guider la prochaine tentative.

Architecture du workflow

Le cœur du système repose sur LangGraph, qui orchestre les agents responsables du code, de la validation et du profiling. Un harness C++ autonome compile les kernels à la volée (NVRTC) et les lance via le driver CUDA, tandis qu'un script Python gère la comparaison des résultats et la sélection du meilleur candidat. Les métriques de performance sont agrégées par la moyenne géométrique des latences sur les cas de performance, les cas de validation n'influant pas au score. Le profilage optionnel utilise Nsight Compute pour récupérer les compteurs GPU et les exposer au modèle, ce qui permet d'orienter les changements de configuration (taille de bloc, nombre de threads, etc.). Tous les artefacts – sources, requêtes, historiques, heatmaps – sont stockés dans un répertoire results/run-XXX/ pour chaque session.

python -m venv .venv
.venv\Scripts\python -m pip install -r optimizer_agent/requirements.txt
cmake -S cuda_test_harness -B cuda_test_harness/build -DCMAKE_BUILD_TYPE=Release
cmake --build cuda_test_harness/build --parallel
.venv\Scripts\python optimizer_agent/optimizer_agent.py \
    --description "Single-precision GEMM with rectangular matrices." \
    --max-iterations 7

Analyse des performances et limites

Les tests présentés utilisent un RTX 3060 Laptop GPU sous Windows, avec 10 lancements d'échauffement et 100 mesures de latence par cas. Le temps de compilation et les relances de profilage sont explicitement exclus du classement, ce qui isole la latence pure du kernel. Le système a démontré la capacité à améliorer un kernel de GEMM initial en quelques itérations, mais la validité reste limitée aux cas fournis : la réussite sur les entrées d'exemple ne garantit pas une généralisation à d'autres dimensions ou types de données. De plus, la dépendance à l'API OpenAI introduit un coût variable et une latence externe, et aucune garantie n'est donnée quant à la reproductibilité des résultats si le modèle sous‑jacent évolue. Enfin, l'absence d'oracle de correction indépendant signifie que les erreurs de logique non détectées par les comparaisons NumPy peuvent persister, limitant l'utilité de l'optimiseur pour des kernels critiques où la précision numérique est stricte.