AutoKernel : système de recherche automatique de kernels GPU

• Application de l’Autoresearch de Karpathy à l’optimisation de kernels GPU
• Outil de recherche automatique de kernels GPU qui optimise automatiquement des kernels Triton ou CUDA C++ à partir d’un modèle PyTorch en entrée
• Fournit un pipeline entièrement automatisé pour profiler, extraire, optimiser et valider les kernels goulots d’étranglement du modèle
• Ajuste les priorités via une orchestration fondée sur la loi d’Amdahl ; chaque expérience prend environ 90 secondes, ce qui permet des centaines d’itérations pendant la nuit
• Intégré à KernelBench, avec 50 à 300 itérations d’expérimentation sur plus de 250 problèmes, pour une exploration systématique au-delà de la génération ponctuelle
• Prend en charge un double backend Triton et CUDA C++, une validation priorisant la correction et une structure de modification sur fichier unique, pour une optimisation de kernels efficace et reproductible

---

Principe de fonctionnement

• AutoKernel prend un modèle PyTorch en entrée et exécute les étapes suivantes
  • Profilage pour identifier les kernels GPU qui constituent les goulots d’étranglement
  • Extraction pour les isoler en kernels Triton ou CUDA C++ indépendants
  • Boucle d’optimisation automatique qui répète modification, benchmark, conservation ou annulation
  • Validation de la correction puis rapport du gain global de vitesse
• En s’appuyant sur les instructions de program.md, il modifie kernel.py et effectue, via bench.py, une vérification de correction en 5 étapes ainsi qu’une analyse roofline
• Chaque expérience prend environ 90 secondes, soit environ 40 essais par heure et environ 320 essais sur une nuit

Exécution et composants

• Environnement requis : GPU NVIDIA (H100/A100/RTX 4090), Python 3.10+, paquet uv
• Composition des scripts principaux
  • profile.py : classement des kernels selon le temps GPU
  • extract.py : extraction des principaux kernels goulots d’étranglement
  • bench.py : benchmark de correction et de performance en 5 étapes
  • orchestrate.py : planification multi-kernel fondée sur la loi d’Amdahl
  • verify.py : validation du modèle complet et rapport de gain de vitesse
• program.md inclut une stratégie d’optimisation en 6 étapes, la gestion des conflits et un cadre de prise de décision permettant une exécution automatique sur de longues durées

Kernels pris en charge et modèles d’exemple

• Prise en charge de 9 types de kernels : matmul, softmax, layernorm, rmsnorm, flash_attention, fused_mlp, cross_entropy, rotary_embedding, reduce
• Chaque kernel inclut une implémentation de référence PyTorch (reference.py) et des versions initiales Triton/CUDA (kernels/, kernels/cuda/)
• Modèles d’exemple : GPT-2, LLaMA (y compris 7B), BERT-base, modèles personnalisés
• Les modèles HuggingFace peuvent aussi être intégrés avec uv sync --extra models

Intégration à KernelBench

• Intégré à KernelBench (Stanford Scaling Intelligence Lab) pour exécuter le benchmark standard des kernels GPU générés par IA
• AutoKernel explore systématiquement l’espace d’optimisation avec 50 à 300 itérations d’expérimentation par problème
• Outils principaux
  • bridge.py : chargement des problèmes et génération du kernel initial
  • bench_kb.py : évaluation de la correction et des performances
  • scorer.py : calcul du score global par niveau
  • program_kb.md : instructions d’agent dédiées à KernelBench

Export vers HuggingFace Hub

• Les kernels optimisés peuvent être exportés vers HuggingFace Hub et chargés simplement avec get_kernel()
• export_hf.py permet l’export et l’envoi de kernels CUDA

Principes de conception

• Double backend Triton + CUDA C++ : Triton pour itérer rapidement, CUDA pour les performances maximales
• Priorité à la correction : si le résultat ne correspond pas à celui de PyTorch, retour immédiat en arrière
• Orchestration fondée sur la loi d’Amdahl pour définir les priorités selon la contribution aux performances globales
• Structure de modification sur fichier unique (kernel.py) facilitant le suivi des changements et la restauration
• Journal TSV (results.tsv) pour enregistrer les résultats d’expérience de manière simple et lisible

Format d’enregistrement des résultats

• results.tsv enregistre pour chaque expérience le numéro, le type de kernel, le débit (TFLOPS), la latence, le ratio par rapport au pic GPU, l’accélération par rapport à PyTorch, la correction, l’utilisation de VRAM et la description

Contexte du projet

• Inspiré par le concept d’autoresearch d’Andrej Karpathy, qui applique une architecture d’agent IA autonome destinée à la recherche sur les LLM à l’optimisation de kernels GPU
• L’intégration de KernelBench s’appuie sur les travaux du Stanford Scaling Intelligence Lab, et AutoKernel réalise une optimisation itérative plutôt qu’une génération ponctuelle
• Le projet est développé par l’équipe Forge de RightNow AI et publié sous licence MIT

[GN⁺]

Commentaires sur Hacker News

• Projet vraiment impressionnant
  J’étais moi aussi en train de construire quelque chose de similaire ces dernières semaines, mais dans une version bien plus généraliste et surconçue
  Cette approche, centrée uniquement sur Triton et sur des kernels spécifiques, est simple et efficace
  En revanche, le graphique de progression est déroutant. On dirait un benchmark de matmul fp16 en 4096x4096x4096, mais tout en annonçant un gain de 1,31x par rapport à cuBLAS, il ne montre que 187 TFLOPS, soit 18,9 % d’utilisation du pic
  cuBLAS obtient des performances bien plus proches du pic, donc il y a probablement un surcoût CPU ou un autre goulot d’étranglement
  Les benchmarks sont vraiment difficiles, mais je pense que ce domaine est extrêmement prometteur pour les 6 prochains mois

• Si cela pouvait fonctionner dans quelque chose comme llama.cpp, le gain serait probablement bien plus important
  Il existe de nombreux kernels de quantification et configurations matérielles, et comme il y a aussi beaucoup d’utilisateurs individuels, l’ampleur des gains d’efficacité pourrait être élevée
  J’aimerais que ce projet y contribue

  • C’est une bonne analyse
    llama.cpp possède plusieurs kernels CUDA réglés manuellement comme Q4_K_M, Q5_K_S et Q8_0, chacun visant des profils matériels différents
    Si une optimisation automatique par GPU devenait possible, ce serait un changement énorme
    Aujourd’hui, même avec le même format de quantification, les écarts de performances entre une RTX 3090 et une 5070 Ti sont importants
    Un environnement comme llama.cpp, où la diversité matérielle est grande, est précisément l’endroit où la recherche automatique de kernels peut donner le meilleur d’elle-même

• Super !
  Je suis en train d’ajouter la même capacité pour Apple Silicon
  Dans mon projet autoresearch-everywhere, je travaille à faire de l’autoresearch un véritable outil sérieux

• Il y a quelque chose d’étrange
  Si on prend comme référence le GEMM fp16 4kx4kx4k, cutlass est environ 3 fois plus rapide

• Je me demande s’il y a eu des benchmarks comparatifs avec l’auto-scheduling de TVM, comme Ansor

• Ce n’est que le début
  Pour référence, Google faisait déjà quelque chose de similaire avec des modèles d’il y a deux générations
  Dans le billet de blog de mai 2025, AlphaEvolve, ils ont annoncé avoir accéléré de 23 % un kernel clé de l’architecture Gemini en divisant les grandes multiplications de matrices en sous-problèmes plus petits, réduisant ainsi le temps d’entraînement de 1 %
  Nous sommes désormais à une époque où ce type de technologie devient possible « à la maison »
  En particulier, avec la montée récente de l’entraînement basé sur le RL, les gains en vitesse d’inférence se traduiront directement par des gains en vitesse d’entraînement

• Je me demande quand ce genre d’optimisation arrivera aussi dans des runtimes de langages open source comme Swift ou Rust, afin d’en extraire jusqu’à la dernière goutte de performance