🤖 machine learning

SOLAR: AI-Powered Speed-of-Light Performance Analysis

SOLAR est un cadre automatisé qui traduit le code source PyTorch et JAX en limites de performance de type « vitesse de la lumière » validées, grâce à un pipeline hybride génératif-déterministe, permettant aux développeurs de quantifier les limites d'exécution théoriques, d'identifier les opportunités d'optimisation et de guider le provisionnement matériel à travers diverses charges de travail de deep learning.

Auteurs originaux : Qijing Huang, Sana Damani, Zhifan Ye, Athinagoras Skiadopoulos, Siva Kumar Sastry Hari, Jason Clemons, Sahil Modi, Jingquan Wang, Aditya Kane, Edward C Lin, Humphrey Shi, Christos Kozyrakis

Publié 2026-06-26

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Qijing Huang, Sana Damani, Zhifan Ye, Athinagoras Skiadopoulos, Siva Kumar Sastry Hari, Jason Clemons, Sahil Modi, Jingquan Wang, Aditya Kane, Edward C Lin, Humphrey Shi, Christos Kozyrakis

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un pilote de course automobile. Vous avez une voiture de haute performance flambant neuve (votre modèle d'IA) et un circuit spécifique (votre puce informatique). Vous voulez savoir : Quel est le temps de tour le plus rapide que cette voiture pourrait absolument réaliser sur ce circuit ?

Actuellement, la plupart des outils ne peuvent que dire à quelle vitesse la voiture est réellement allée lors d'un essai, ou peuvent compter la puissance du moteur (combien de problèmes mathématiques elle résout). Mais ils ne peuvent pas vous dire la vitesse théorique limite de cette voiture spécifique sur ce circuit spécifique. Votre voiture roule-t-elle à 50 % de son potentiel ? 90 % ? Ou est-elle coincée dans les bouchons à cause d'une mauvaise conception de la route ?

Ce document présente SOLAR, un nouvel outil qui calcule automatiquement cette limite de « Vitesse de la Lumière » (SOL - Speed of Light).

Voici comment fonctionne SOLAR, décomposé en analogies simples :

1. Le Problème : Deviner vs Savoir

Actuellement, si vous voulez connaître la vitesse limite d'un modèle d'IA complexe, vous devez le faire à la main. C'est comme essayer de calculer le temps de tour le plus rapide en mesurant manuellement chaque virage et chaque ligne droite avec une règle. C'est lent, sujet aux erreurs et souvent faux.

Les anciens outils se contentent soit de compter les mathématiques (en ignorant les embouteillages), soit de mesurer à quelle vitesse un pilote spécifique roule en ce moment (en ignorant le potentiel de la voiture).
La pure supposition par l'IA tente de prédire le temps, mais se trompe souvent dans les calculs, surtout pour les itinéraires complexes.

2. La Solution : Le « Traducteur » et l'« Ingénieur »

SOLAR résout cela grâce à une équipe ingénieuse en deux parties : un Traducteur et un Ingénieur.

Étape 1 : Le Traducteur (L'Agent d'IA)
Imaginez que vous avez une recette manuscrite désordonnée (votre code IA écrit en PyTorch ou JAX). Un chef humain (le Modèle de Langage Étendu/LLM) lit cette recette désordonnée et la réécrit sous la forme d'un plan strict et standardisé appelé Affine Loop IR.
- Le contrôle de sécurité : Avant que le plan ne soit accepté, SOLAR exécute à la fois la recette désordonnée originale et le nouveau plan pour s'assurer qu'ils produisent exactement le même plat. Si les plats ont des goûts différents, l'IA recommence. Cela garantit que la traduction est 100 % précise.
Étape 2 : L'Ingénieur (Le Calculateur Déterministe)
Une fois le plan vérifié, un ingénieur strict et respectueux des règles prend le relais. Cet ingénieur examine le plan et se demande : « Si nous construisons cela exactement comme dessiné, quel est le temps minimum absolu nécessaire ? »
- Il ne devine pas. Il calcule les mathématiques basées sur la structure du plan.
- Il crée une carte de dépendances (un « Graphe d'Einsum »), montrant exactement comment les données circulent d'une étape à la suivante.

3. Le Calcul de la « Vitesse de la Lumière »

Une fois que l'ingénieur possède la carte, il calcule la vitesse limite en utilisant deux facteurs principaux :

Calcul (Compute) : La vitesse à laquelle le moteur peut faire des mathématiques.
Mémoire (Trafic) : La vitesse à laquelle les données entrent et sortent du moteur.

SOLAR regarde la carte et dit :

« Vitesse Naïve » : Si vous vous arrêtez à chaque intersection pour recharger vos courses (données), combien de temps cela prend-il ?
« Vitesse Fusionnée » : Si vous combinez deux arrêts en un seul (fusion d'opérations), vous gagnez du temps.
« Vitesse Réaliste » : Si vous considérez que votre coffre (cache) est petit et que vous ne pouvez pas tout transporter à la fois, combien de temps cela prend-il ?

4. Ce que SOLAR vous dit (la « Marge de Progression »)

La partie la plus excitante est ce que révèle SOLAR : L'Écart.

Si votre modèle d'IA actuel met 10 secondes pour s'exécuter, et que SOLAR dit que la limite théorique est de 1 seconde, vous avez une marge de progression (headroom) de 10x.

L'analogie de la Marge de Progression : Imaginez que vous roulez à 60 mph dans une zone de 100 mph. SOLAR vous dit : « Vous roulez à 60, mais la voiture et la route peuvent supporter 100. Voici exactement où vous ralentissez : Est-ce parce que vous vous arrêtez trop souvent ? Est-ce parce que votre coffre est trop petit ? Est-ce parce que vous prenez un mauvais itinéraire ? »

5. Exemples concrets du document

Les auteurs ont testé SOLAR sur trois types de scénarios :

Benchmarks Standards : Ils ont découvert que pour des tâches complexes, les logiciels actuels sont souvent 50 fois plus lents que la limite théorique. Cela signifie qu'il y a une marge de progression massive simplement en réorganisant la façon dont le code s'exécute.
Robotique : Ils ont étudié des robots qui doivent réagir instantanément (500 fois par seconde). SOLAR leur a dit : « Vos puces informatiques actuelles sont trop lentes car elles ne peuvent pas déplacer les données assez vite. Vous avez besoin d'une puce avec 20 fois plus de bande passante pour faire fonctionner ce robot en temps réel. »
Matériel Différent : Ils ont montré que vous pouvez prédire comment un modèle fonctionnera sur une nouvelle puce non encore commercialisée, simplement en faisant les calculs, sans avoir besoin d'acheter la puce au préalable.

Résumé

SOLAR est comme un GPS pour la performance de l'IA. Au lieu de simplement vous dire combien de temps votre trajet a duré, il calcule le temps de trajet le plus rapide possible pour votre voiture et votre route spécifiques. Il vous indique ensuite précisément où vous perdez du temps — que ce soit à cause d'un mauvais plan d'itinéraire (algorithmes), de trop nombreux arrêts (trafic mémoire) ou d'un coffre trop petit (cache) — afin que vous sachiez exactement comment le corriger pour atteindre la « Vitesse de la Lumière ».

Résumé Technique : SOLAR – Analyse de la Performance « Speed-of-Light » pilotée par l'IA

1. Énoncé du Problème

Les accélérateurs d'apprentissage profond modernes atteignent des débits de pointe de l'ordre du petaFLOPS, pourtant, les charges de travail réelles n'approchent que rarement ces limites théoriques. Un fossé critique existe entre la vitesse à laquelle un modèle pourrait s'exécuter sur un matériel cible et la vitesse à laquelle il s'exécute réellement. Les outils actuels ne parviennent pas à traiter cette question de manière exhaustive :

Les compteurs de FLOPs (ex: fvcore, ptflops) souffrent d'une couverture d'opérateurs étroite (75–84 % sur KernelBench), ignorent le trafic d'E/S et ne peuvent pas dériver les temps d'exécution minimaux théoriques (limites de la vitesse de la lumière ou « Speed-of-Light » - SOL).
Les profilers matériels (ex: NCU, NSys) mesurent la performance réalisée de certaines implémentations plutôt que les limites théoriques, rapportant potentiellement une « marge de progression » (headroom) physiquement inatteignable en raison de contraintes algorithmiques.
L'estimation par pur LLM est sujette aux erreurs, particulièrement sur les charges de travail composites, et manque des capacités de recherche systématique requises pour l'analyse sensible au cache.
Les cadres de modélisation de performance existants (ex: Timeloop, AccelForge) nécessitent une spécification manuelle de la charge de travail, ce qui est sujet aux erreurs et déconnecté du développement rapide de modèles.

Il n'existe aucun outil capable de dériver automatiquement des limites SOL validées directement à partir du code source de haut niveau (PyTorch/JAX) avec une large couverture d'opérateurs.

2. Méthodologie

SOLA (Speed-of-Light Analysis for Runtime) est un cadre de type « source-vers-SOL » qui comble ce fossé grâce à un pipeline en trois étapes séparant la traduction générative de l'analyse déterministe.

Étape 1 : Frontend Agentique Validé

La première étape traduit des programmes sources arbitraires en un IR de Boucle Affine exécutable.

L'Agent LLM comme Parseur : Un agent LLM traduit le code source en l'IR de Boucle Affine, une représentation intermédiaire indépendante du langage.
Structure de l'IR : L'IR divise les programmes en :
- Noyaux de boucles affines restreintes : Boucles parfaitement imbriquées sur des tenseurs de dimensions nommées avec des bornes statiques et des expressions d'indexation affines, conçues pour un levage mécanique vers des einsums.
- Couche de composition non restreinte : Gère le contrôle de flux, les mouvements de données (reshape, slice) et les opérations creuses (sparse).
Boucle de Validation : Pour garantir la correction, le système exécute le programme original pour capturer les sorties « golden », génère l'IR via le LLM, exécute l'IR (en utilisant Numba) et compare les sorties. En cas de divergence, un retour de diagnostic guide le LLM pour corriger la traduction. Cette boucle « générer-puis-vérifier » garantit que le pipeline en aval ne reçoit que des traductions numériquement validées.

Étape 2 : Génération Déterministe d'Einsum

Une fois l'IR validé, le compilateur déterministe le lève vers un Graphe d'Einsum.

Construction du Graphe : Le backend trace l'IR pour construire un graphe orienté acyclique (DAG) où les nœuds sont des einsums étendus (supportant des réductions comme max) et les arêtes représentent les dépendances de données de tenseurs.
Dérivation Mécanique : À partir de la structure des sous-indices des einsums, le système dérive mécaniquement les comptes exacts de MAC et les formules de trafic mémoire.
Analyse de Fusions (Fusibility) : La structure du graphe identifie les opérateurs adjacents pouvant partager des tampons sur puce (on-chip buffers), permettant au système de calculer le coût des opérations fusionnées par rapport à une exécution indépendante.

Étape 3 : Analyse SOL

Le backend analytique calcule les temps d'exécution minimaux théoriques ( $T_{SOL}$ ) par rapport aux spécifications du matériel cible (débit de pointe $\Pi$ et bande passante DRAM $\beta$ ).

Modèle de Roofline : $T_{SOL} = \max(\frac{\text{FLOPs}}{\Pi}, \frac{\text{Traffic}}{\beta})$ .
Modes Multi-fidélité :
1. Non-fusionné (Unfused) : Suppose une exécution indépendante avec des allers-retours complets vers la DRAM pour les intermédiaires.
2. Fusionné (Fused) : Élimine le trafic DRAM intermédiaire en supposant une capacité de tampon sur puce infinie pour les opérateurs fusionnés.
3. Fusionné Sensible au Cache (OROJENESIS) : Modélise la capacité finie du tampon sur puce. Il utilise la programmation linéaire en nombres entiers pour optimiser les stratégies de titrage (tiling), tenant compte des relectures depuis la DRAM lorsque l'ensemble de travail dépasse les limites du cache.
Roofline Inverse : Étant donné une latence cible, le système dérive les spécifications matérielles minimales requises ( $\Pi_{min}$ et $\beta_{min}$ ).

3. Contributions Clés

Premier Cadre Source-vers-SOL : SOLAR est le premier outil capable de dériver des limites SOL validées directement à partir du code source PyTorch et JAX, atteignant une couverture d'analyse de 100 % sur KernelBench.
Pipeline Hybride Génératif-Déterministe : Il combine de manière unique un LLM pour la traduction indépendante du langage (avec validation numérique) et un compilateur déterministe pour une analyse de performance reproductible. Cela évite les erreurs d'une estimation purement basée sur le LLM tout en contournant l'effort manuel de la modélisation traditionnelle.
Évaluation Complète : Le cadre fournit des preuves à travers des cas d'utilisation de noyaux (kernels), d'algorithmes et d'architectures, démontrant des capacités d'analyse de marge de progression, d'identification d'optimisation, d'exploration multi-plateforme et de provisionnement matériel.

4. Résultats

L'évaluation a été menée sur KernelBench (270 problèmes), des modèles JAX/Flax, et des charges de travail robotiques sur Jetson Thor.

Analyse de la Marge de Progression (Headroom) : SOLAR révèle des écarts d'optimisation significatifs. Sur KernelBench, l'écart entre le temps d'exécution mesuré et le SOL fusionné varie de 4,3× (L1) à 54,6× (L3) pour l'exécution PyTorch eager. Même torch.compile laisse une marge substantielle (ex: 47,7× sur L3), indiquant que la fusion au niveau du graphe est critique pour les charges de travail composites.
Aperçus Multi-fidélité :
- Fusion : L'analyse fusionnée révèle jusqu'à 7,8× de marge supplémentaire par rapport à l'analyse par opérateur sur KernelBench.
- Mise en Cache : Les limites sensibles au cache resserrent le SOL jusqu'à 2,25× par rapport aux limites fusionnées naïves, identifiant le titrage comme un goulot d'étranglement dans certains scénarios.
- Optimisation Algorithmique : Le réordonnancement des chaînes d'einsum (ex: dans DeepSeek MLA) a permis une réduction de 2,04× des FLOPs par rapport à l'ordonnancement naïf.
Projection Multi-plateforme : SOLAR projette les performances sur quatre cibles matérielles (B200, H100, A6000, Jetson Thor) sans accès physique. Les bénéfices de la fusion varient considérablement selon la plateforme (1,8× sur B200 contre 14,5× sur Jetson Thor), soulignant l'interaction entre la bande passante et la fusion.
Provisionnement Matériel (Roofline Inverse) : Pour les modèles de robotique ciblant des boucles de contrôle de 500 Hz, SOLAR a identifié que la bande passante est la contrainte principale. Par exemple, le modèle DreamZero WAM nécessite une amélioration de 19,7× de la bande passante actuelle pour atteindre les cibles de latence, suggérant que les mises à niveau de silicium seules sont insuffisantes sans compression de modèle ou changements algorithmiques.

5. Signification et Revendications

L'article affirme que SOLAR change fondamentalement la manière dont l'optimisation des performances est abordée en rendant les limites théoriques accessibles et exploitables sans modélisation manuelle.

Combler le Fossé : Il réduit le décalage entre le développement rapide de modèles et l'analyse de performance matérielle, fournissant un plafond d'optimisation « validé ».
Aperçus Actionnables : En offrant une analyse multi-fidélité, il aide les ingénieurs à distinguer les goulots d'étranglement causés par un manque de fusion, un mauvais titrage ou des inefficacités algorithmiques fondamentales.
Conception Indépendante du Matériel : Il permet aux architectes et aux concepteurs d'algorithmes d'explorer les espaces de conception et de provisionner les exigences matérielles avant même l'existence du silicium, évitant ainsi le gaspillage de calcul et de jetons (tokens) sur des travaux ayant peu de marge de progression restante.

Les auteurs soulignent que bien que l'analyse soit basée sur les formes de tenseurs (et non sur les valeurs) et suppose un comportement matériel idéal (ignorant le bridage thermique), elle fournit la première vue automatisée, validée et complète de la vitesse de la lumière théorique pour les charges de travail d'apprentissage profond.