Comment nous accélérons les modèles YOLO chez Ultralytics sur ta puce préférée

Chez Ultralytics, nous créons des modèles de vision par ordinateur ; en gros, nous apprenons aux ordinateurs à voir ! Considère ces modèles comme d'immenses recettes mathématiques. Ils sont constitués d'opérations (que nous appelons des couches) et d'une énorme quantité de nombres que nous appelons des poids.

Nos modèles Ultralytics YOLO traitent les images pour ce qu'elles sont réellement : des tableaux de nombres ! Chaque pixel n'est en fait qu'un ensemble de valeurs de couleur, la quantité de rouge, de vert et de bleu (RGB) pour chaque point qui compose l'image. Nous appelons ces tableaux de nombres des « tenseurs », parce que cela sonne bien plus cool que « matrices multidimensionnelles », qui sonne bien plus cool que « des nombres empilés sur des nombres empilés sur des nombres ».

Lorsque tu fournis une image à notre modèle, elle entreprend un voyage épique à travers le réseau. Imagine ton tenseur surfer à travers couche après couche, se transformant, se convoluant et se faisant malmener mathématiquement de la plus belle manière possible. Vois cela comme une fête dansante où les nombres se mélangent et se côtoient, extrayant l'essence de ce qui fait qu'un chat est un chat ou qu'une voiture est une voiture. Nous appelons ce processus l'extraction de caractéristiques.

Que ressort-il de l'autre côté ? Encore plus de nombres ! Des nombres porteurs de sens. Dans les tâches de détection, ils t'indiquent exactement où se trouvent les objets dans ton image et ce qu'ils sont probablement. « Hé, il y a 95 % de chances que ce soit un chien aux coordonnées (x, y) ! » Nous appelons ce processus magique l'inférence.

Mais avant que nos modèles puissent faire leur magie, ils doivent aller à l'école ; ils doivent être entraînés. C'est pendant l'entraînement que les choses deviennent intenses.

Pendant l'entraînement, chaque fois que nous présentons une image au réseau, nous ne faisons pas que recueillir une réponse. Nous faisons deux choses particulièrement exigeantes. Premièrement, nous calculons à quel point le réseau s'est trompé (nous appelons cela la perte, c'est-à-dire essentiellement la distance par rapport au centre de la cible). Deuxièmement, et c'est le plus important, nous mettons à jour chaque nombre (ou poids) du réseau en fonction de cette perte. Imagine cela comme le réglage simultané de milliers de petits boutons, chaque ajustement étant calculé pour rendre le réseau plus précis à chaque fois.

Nous entraînons essentiellement le réseau par correction : chaque erreur lui apprend ce qu'il NE faut PAS faire, et nous ajustons tous ces poids afin que, lorsqu'il reverra une image similaire, il se rapproche de la bonne réponse. En substance, le réseau apprend en étant poussé dans la bonne direction, erreur après erreur, jusqu'à commencer à viser juste dans ses prédictions.

De combien de nombres parle-t-on ? Eh bien, notre petit YOLO11n possède quelques millions de paramètres. Mais YOLO11x ? Ce gros bébé embarque plus de 50 millions de paramètres ! Plus de paramètres signifie que tu peux encoder davantage de détails, comme la différence entre dessiner avec des crayons de couleur et disposer d'une palette complète d'artiste.

Pendant l'inférence, ce nombre de paramètres devient crucial. Exécuter un réseau de 3 millions de paramètres, c'est comme faire un petit jogging autour du pâté de maisons. Exécuter un réseau de 50 millions de paramètres ? C'est plutôt comme courir un marathon en jonglant avec des torches enflammées.

Alors, qu'est-ce que le calcul EXACTEMENT ? Comment tout ce traitement de nombres se produit-il réellement ? Comment pouvons-nous l'accélérer ? Et que signifie même « optimiser le calcul » ?

Comment les puces effectuent réellement les calculs#

Le calcul s'effectue au moyen de puces. Ces petits carrés de silicium sont essentiellement les châteaux de sable les mieux organisés de l'univers. Chaque opération effectuée par ton ordinateur, chaque addition, chaque comparaison, chaque « si ceci alors cela », est physiquement gravée dans le silicium. De véritables circuits physiques, situés dans des zones précises de la puce, sont dédiés à l'addition des nombres, tandis que d'autres s'occupent des opérations logiques. C'est comme une petite ville où différents quartiers se spécialisent dans différents types de mathématiques.

Cela semble probablement bizarre, même si tu es informaticien. C'est parce que nous avons passé les 40 dernières années à construire couche après couche d'abstraction, comme une lasagne technologique devenue si haute que nous ne pouvons même plus voir l'assiette du dessous. Nous avons tellement simplifié les choses que la plupart des programmeurs actuels n'ont aucune idée de la manière dont le calcul se produit réellement dans le silicium. Ce n'est pas leur faute, mais une conséquence de la conception !

Retirons ces couches une à une. Prenons ce code Python tout simple :

x = 1
if x == 1:
    y = x + 1

Nous créons une variable x, lui attribuons la valeur 1 et, si x est égal à 1 (divulgâchis : c'est le cas), nous créons y avec la valeur de x plus 1. Trois lignes. Facile.

Mais c'est ici que les choses deviennent intéressantes. Entre ces trois lignes innocentes et le déplacement réel d'électrons dans le silicium, il y a AU MOINS quatre énormes couches de traduction (il y en a en réalité davantage, mais notre responsable du contenu numérique affirme que mon nombre de mots lui cause déjà de l'anxiété). Laisse-moi te guider à travers ce voyage qui fait tourner la tête :

Couche 1 : Python → Bytecode Tout d'abord, Python lit ton code et le compile en quelque chose appelé bytecode, un langage intermédiaire plus facile à assimiler pour les ordinateurs, mais qui te ferait saigner des yeux si tu essayais de le lire.

Couche 2 : Bytecode → Code machine L'interpréteur Python (comme CPython) prend ce bytecode et le traduit en code machine, les instructions réelles comprises par ton processeur. C'est ici que ton élégant « if x == 1 » devient quelque chose comme « LOAD register, COMPARE register, JUMP if zero flag set ».

Couche 3 : Code machine → Microcode Rebondissement ! Les processeurs modernes n'exécutent même pas directement le code machine. Ils le décomposent davantage en microcode, des opérations encore plus petites que les composants internes de la puce peuvent gérer. Ta simple instruction « ADD » peut devenir plusieurs micro-opérations.

Couche 4 : Microcode → Électronique physique Enfin, nous atteignons le silicium. Ces micro-opérations déclenchent de véritables signaux électriques qui circulent à travers les transistors. Des milliards de minuscules interrupteurs s'allument et s'éteignent, les électrons dansent à travers des chemins soigneusement conçus et, comme par magie, 1 + 1 devient 2.

Chaque couche existe pour dissimuler la complexité insensée de la couche située en dessous. C'est comme ces poupées russes gigognes, sauf que chaque poupée parle une langue complètement différente et que la plus petite est littéralement constituée d'éclairs emprisonnés dans du sable.

L'ironie ? Ces trois lignes de Python déclenchent probablement des MILLIONS d'interrupteurs de transistors. Mais grâce à ces abstractions, tu n'as pas besoin de penser à tout cela. Tu écris simplement « y = x + 1 » et tu fais confiance à la magie qui opère quelque part, au cœur du silicium.

L’architecture#

Chaque opération est implémentée physiquement dans le silicium, et l'ENDROIT où elle se produit sur la puce dépend entièrement de la topologie de celle-ci. C'est comme l'urbanisme, mais pour les électrons. L'additionneur vit ici, le multiplicateur là-bas, et tous doivent communiquer efficacement.

Il existe des centaines de puces différentes sur le marché, chacune conçue pour des usages différents. Qu'est-ce qui change entre elles ? La topologie, c'est-à-dire la manière dont les opérations sont positionnées et implémentées dans le domaine physique. C'est ce que nous appelons l'architecture, et crois-moi, nous en avons beaucoup :

• x86 (Intel et AMD) - Le grand-père de l'informatique de bureau, complexe mais puissant
• ARM - Alimente ton téléphone et de plus en plus ton ordinateur portable, conçu pour l'efficacité
• RISC-V - Le rebelle open source, qui gagne du terrain partout
• PowerPC - Le monstre d'IBM, qui équipe encore les consoles de jeu et les serveurs
• MIPS - Le favori des universitaires, simple et élégant
• SPARC - La contribution de Sun Microsystems (désormais Oracle) au calcul haute performance
• Architectures GPU (cœurs CUDA de NVIDIA, RDNA d'AMD) - Des monstres du traitement parallèle

Chaque architecture ne se contente pas d'agencer ses transistors différemment, elle parle aussi une langue différente. Les abstractions que nous utilisons pour envoyer des instructions à ces machines sont complètement différentes. C'est comme devoir rédiger un itinéraire pour quelqu'un, mais selon sa voiture, tu devras peut-être l'écrire en français, en mandarin ou en danse interprétative.

Le battement de cœur du silicium#

Le carburant de nos puces, ce sont les électrons, c'est-à-dire l'électricité qui circule dans la puce et fournit l'énergie nécessaire au calcul. Mais l'énergie seule ne suffit pas. Pour qu'une puce fonctionne réellement et déplace des données à travers son réseau complexe, tout dépend d'un composant essentiel : l'horloge. C'est elle qui fait circuler les électrons sur des chemins précis à des moments précis. Sans elle, tu aurais simplement du silicium alimenté qui ne fait rien.

Imagine que tu essaies de coordonner un spectacle gigantesque où des milliards de composants doivent se déplacer en parfaite synchronisation. Sans rythme, ce serait le chaos. C'est exactement ce que fait l'horloge pour ton processeur. Il s'agit d'un cristal qui vibre à une fréquence incroyablement constante et émet des impulsions électriques des milliards de fois par seconde.

Quand tu entends parler d'un « processeur à 3,5 GHz », le GHz correspond à la vitesse d'horloge, soit 3,5 milliards de battements par seconde. Chaque battement est appelé un cycle d'horloge, l'unité de temps fondamentale en informatique.

RIEN ne se passe entre deux cycles d'horloge. L'ordinateur entier se fige en attendant le battement suivant. C'est comme le jeu « 1, 2, 3, soleil » le plus extrême de l'univers. À chaque « feu vert » (impulsion d'horloge) :

• Les données se déplacent entre les composants
• Les calculs s'exécutent
• Les décisions logiques sont prises
• La mémoire est lue ou écrite

Certaines opérations prennent un cycle (une simple addition), tandis que d'autres en prennent plusieurs (une division ou la récupération de données depuis la RAM). Tout est chorégraphié avec précision : des milliards de composants exécutent leurs opérations spécifiques, tous synchronisés sur ce rythme implacable.

Tu peux overclocker ton processeur en faisant vibrer le cristal plus rapidement ; tout se produit plus vite, mais cela génère aussi davantage de chaleur et rend le système moins stable. Pousse trop loin, et ton ordinateur plante parce que les électrons ne peuvent littéralement plus suivre le rythme.

À l'époque, ces opérations étaient réalisées par des machines de la taille d'une pièce. Mais les composants qui effectuent tous ces calculs sont remarquablement simples : ce sont juste des interrupteurs. Des interrupteurs allumés ou éteints.

Relie suffisamment de ces interrupteurs selon le bon schéma, et tu obtiens un calculateur. Toute la révolution numérique se résume à un agencement sophistiqué d'interrupteurs.

Cette simplicité signifie que si tu as des interrupteurs, quels qu'ils soient, tu peux construire un ordinateur. Des personnes ont construit des ordinateurs fonctionnels avec des conduites d'eau et des vannes, des dominos, des briques LEGO, des billes et même de la redstone dans Minecraft.

Les principes n'ont pas changé depuis les années 1940. Nous sommes simplement devenus incroyablement efficaces pour fabriquer des interrupteurs extrêmement petits. Ton téléphone possède davantage de puissance de calcul que tous les ordinateurs qui ont envoyé des humains sur la Lune, et il tient dans ta poche parce que nous avons appris à fabriquer des interrupteurs à l'échelle atomique.

Lorsque nous exécutons des réseaux neuronaux comportant des millions de paramètres, nous activons et désactivons ces minuscules interrupteurs des milliards de fois par seconde, le tout parfaitement synchronisé avec le battement de ce cristal. Chaque mise à jour de poids, chaque multiplication matricielle, chaque fonction d'activation : tout suit le rythme de l'horloge.

Pas étonnant que l'entraînement des modèles donne à ton ordinateur l'impression d'essayer de décoller !

Faire tourner les réseaux neuronaux à toute allure#

Bon, nous avons donc ces puces avec des milliards d'interrupteurs qui dansent au rythme d'un cristal, et nous voulons y exécuter des réseaux neuronaux comportant des millions de paramètres. Cela devrait être facile, non ? Il suffit de lancer les nombres sur la puce et de laisser faire !

Faire tourner rapidement des réseaux neuronaux, c'est comme essayer de préparer un repas de cinq plats dans une cuisine dont le réfrigérateur se trouve à trois pâtés de maisons, où tu n'as qu'une seule poêle et où chaque ingrédient pèse 225 kg. Les mathématiques elles-mêmes ne sont pas le principal problème ; c'est tout le reste.

Le décalage entre les architectures#

La plupart des puces ont été conçues pour exécuter Microsoft Word, pas des réseaux neuronaux. Ton CPU a été conçu en partant du principe qu'il passerait sa vie à exécuter des conditions, des boucles et, de temps en temps, à calculer tes impôts (le seul calcul qui épuise émotionnellement même les superordinateurs). Il est optimisé pour les opérations séquentielles : faire ceci, puis cela, puis autre chose.

Mais les réseaux neuronaux sont complètement différents. Ils veulent tout faire EN MÊME TEMPS. Pendant l'entraînement, tu mets à jour des millions de poids en fonction de l'écart entre tes prédictions et la réalité. Pendant l'inférence (l'utilisation réelle du modèle entraîné), tu fais passer les données à travers des millions de calculs simultanément. Imagine que tu doives multiplier un million de nombres par un autre million de nombres. Ton CPU, aussi méritant soit-il, veut les traiter un par un, comme un comptable très rapide mais extrêmement méthodique.

C'est pourquoi les GPU sont devenus la colonne vertébrale du calcul pour l'IA. Les GPU ont été conçus pour les jeux vidéo, où il faut calculer simultanément la couleur de millions de pixels. Il s'avère que calculer les couleurs des pixels et effectuer des calculs de réseaux neuronaux sont étonnamment similaires : dans les deux cas, il s'agit d'appliquer la même opération à d'énormes quantités de données en parallèle.

Mais même les GPU ne sont pas parfaits pour les réseaux neuronaux. C'est pourquoi les entreprises construisent aujourd'hui des puces d'IA spécialisées (TPU, NPU et tous les autres acronymes se terminant par PU). Ces puces sont conçues de zéro avec un seul objectif : accélérer les réseaux neuronaux. C'est comme engager un chef qui ne sait préparer qu'un seul plat, mais qui le cuisine à une vitesse surhumaine. Tandis que ton CPU peine à effectuer les opérations matricielles séquentiellement et que ton GPU les traite assez bien en parallèle, ces puces spécialisées dévorent les matrices au petit-déjeuner, au déjeuner et au dîner.

Le mur de la mémoire (ou : pourquoi déplacer des bits est plus difficile que faire des calculs)#

Dans les calculs modernes de réseaux neuronaux, nous passons plus de temps et dépensons plus d'énergie à DÉPLACER les données qu'à les CALCULER réellement.

Imagine la puce de ton ordinateur comme un mathématicien brillant qui travaille à la vitesse de l'éclair, mais dont tous les ouvrages de référence sont stockés dans différents bâtiments à l'autre bout de la ville. Il peut résoudre n'importe quelle équation instantanément, mais il doit d'abord obtenir les nombres, et ce trajet prend une éternité.

Ta puce peut multiplier deux nombres en un cycle d'horloge (rappelle-toi qu'il s'agit de l'un de ces milliards de battements par seconde). À la vitesse de l'éclair ! Mais récupérer ces nombres de la mémoire pour les amener jusqu'à la puce ? Cela peut prendre des CENTAINES de cycles. C'est comme si ton mathématicien pouvait résoudre un problème en une seconde, mais avait besoin de cinq minutes pour aller à la bibliothèque et en revenir.

La raison tient à la distance (et à l'espace). L'électricité se déplace rapidement, mais pas à une vitesse infinie. Plus les données doivent parcourir une longue distance sur la puce, plus cela prend du temps. Les concepteurs d'ordinateurs ont résolu ce problème en créant une hiérarchie de mémoire, comme si plusieurs espaces de stockage se trouvaient à différentes distances :

• Registres (intégrés directement aux unités de calcul) : le bureau de ton mathématicien. Accès instantané ! Mais l'espace est minuscule : tu ne peux y conserver qu'environ 32 nombres. C'est comme avoir des pense-bêtes juste devant toi.
• Cache L1 (à quelques micromètres) : la bibliothèque dans le bureau. Il faut 3 à 4 cycles pour récupérer quelque chose. Tu peux y stocker quelques milliers de nombres.
• Cache L2 (à quelques millimètres) : le classeur au bout du couloir. Il faut 10 à 15 cycles et il peut contenir quelques millions de nombres.
• Cache L3 (à travers la puce) : la réserve à l'étage inférieur. Il faut 30 à 50 cycles ; elle peut contenir des dizaines de millions de nombres.
• RAM (sur une puce complètement différente) : l'entrepôt à l'autre bout de la ville. Il faut 100 à 300 cycles. C'est là que résident tes milliards de nombres.
• SSD/Disque dur (connecté par des câbles) : une autre ville tout entière. Il faut des millions de cycles. Capacité massive, vitesse glaciaire.

Les structures exactes varient : la puce de ton téléphone peut ne pas avoir de cache L3, tandis qu'un CPU de serveur peut en avoir une quantité gigantesque. Le principe reste toutefois le même : une mémoire plus proche est plus rapide, mais plus petite.

C'est ici que les choses deviennent douloureuses pour les réseaux neuronaux. Imagine que ton modèle Ultralytics YOLO comporte 50 millions de paramètres (ChatGPT en a des milliards, soit dit en passant). Ce sont 50 millions de nombres qui doivent voyager de la mémoire vers les unités de calcul, puis revenir. Même si chaque nombre ne fait que 4 octets, cela représente 200 mégaoctets de données à déplacer dans ton système.

La puce peut traiter chaque nombre en un seul cycle, mais s'il faut 100 cycles pour récupérer ce nombre depuis la RAM, tu passes 99 % de ton temps à attendre la livraison. C'est comme avoir une voiture de course de Formule 1 dans un embouteillage. Toute cette puissance de calcul reste là, à attendre l'arrivée des données.

Voici l'idée essentielle : c'est LE goulot d'étranglement de l'informatique moderne. On l'appelle le goulot d'étranglement de von Neumann. Accélérer les calculs mathématiques des puces est relativement facile. Accélérer la mémoire se heurte à des limites physiques. C'est pourquoi la quasi-totalité des optimisations de performances en IA se font au niveau de la mémoire. Lorsque les ingénieurs accélèrent les réseaux neuronaux, ils rendent rarement les calculs plus rapides ; ils trouvent plutôt des moyens astucieux de moins déplacer les données, de mieux les mettre en cache ou d'y accéder plus intelligemment.

Les puces d'IA modernes ne se concentrent pas uniquement sur la vitesse de calcul ; elles se focalisent sur la bande passante mémoire et les stratégies de déplacement des données. Elles préchargent les données, réutilisent les valeurs déjà présentes dans le cache et organisent les calculs pour réduire au minimum les accès à la mémoire. Les gagnants de la course au matériel d'IA ne sont pas ceux qui possèdent les calculateurs les plus rapides ; ce sont ceux qui ont trouvé comment les alimenter en données. Tout le jeu consiste à optimiser les schémas d'accès à la mémoire.

Chaque fois que tu déplaces un bit de données, tu dépenses de l'énergie. Pas beaucoup, on parle de picojoules, mais lorsque tu déplaces des téraoctets par seconde, cela s'accumule RAPIDEMENT. En fait, déplacer des données de 1 mm sur une puce consomme plus d'énergie que d'effectuer le calcul lui-même !

C'est pourquoi ton ordinateur portable ressemble à un réacteur lorsque tu entraînes des réseaux neuronaux. Ce ne sont pas les mathématiques qui génèrent de la chaleur ; c'est le déplacement des données. Chaque mise à jour de paramètre, chaque calcul de gradient, chaque propagation avant réchauffe littéralement ta pièce.

Les accélérateurs d'IA modernes sont essentiellement des exercices de thermodynamique. Quelle quantité de calcul pouvons-nous concentrer avant que la puce ne fonde ? À quelle vitesse pouvons-nous évacuer la chaleur ? C'est comme l'overclocking, sauf que l'horloge est toujours à 11 et que nous essayons simplement de ne pas déclencher un incendie.

La solution ? Une conception consciente de l'architecture#

Les réseaux neuronaux les plus rapides ne sont pas nécessairement les plus intelligents ; ce sont ceux qui sont conçus en tenant compte des puces. Ils :

• Conservent les données en local autant que possible
• Réutilisent les calculs de manière obsessionnelle
• S'alignent parfaitement sur les capacités du matériel
• Réduisent au minimum les déplacements de mémoire, quel qu'en soit le coût

C'est comme la différence entre une recette qui dit « utilise les ingrédients de ton épicerie locale » et une autre qui t'oblige à importer des épices du Tibet, du fromage de France et de l'eau de l'Antarctique. Les deux peuvent être bonnes, mais l'une est clairement plus pratique.

Et c'est pourquoi accélérer les réseaux neuronaux est une forme d'art. Il ne suffit pas d'avoir de bonnes mathématiques ; tu dois comprendre le matériel, respecter la hiérarchie de mémoire et danser parfaitement avec l'architecture.

Bienvenue dans un monde où l'informatique rencontre la physique, l'ingénierie et la pure sorcellerie. Où déplacer un nombre coûte plus cher que de calculer avec lui. Où le parallélisme est rapide, mais où la synchronisation est mortelle. Où ton plus grand ennemi n'est pas la complexité, mais la distance.

Comment nous accélérons YOLO#

Lorsque tu entraînes un modèle YOLO, tu obtiens un réseau neuronal qui fonctionne à merveille sur ton environnement d'entraînement. Mais voilà le problème : ton GPU de jeu, ton iPhone et la minuscule puce d'une caméra de sécurité parlent tous des langues complètement différentes. Ils ont des points forts différents, des faiblesses différentes et des conceptions très différentes de la manière de traiter les données.

Vois les choses ainsi : un GPU possède des milliers de cœurs qui peuvent tous travailler simultanément : il est conçu pour le traitement parallèle. En revanche, une puce mobile peut disposer de circuits spéciaux conçus spécifiquement pour les opérations d'IA, mais ne gérer que certains types de calculs. Et le dispositif edge de ta sonnette vidéo ? Il essaie d'exécuter de l'IA avec un budget énergétique inférieur à celui d'une ampoule LED.

Chez Ultralytics, nous prenons en charge plus d'une douzaine de formats d'exportation différents, car chacun est optimisé pour un matériel différent. Il ne s'agit pas d'avoir trop d'options. Il s'agit d'avoir la bonne option pour TES besoins spécifiques.

Fusionner les opérations : faire plus avec moins#

Dans le modèle YOLO d'origine, de nombreuses opérations se produisent en séquence. Par exemple, nous pouvons effectuer une convolution, puis normaliser les résultats, puis appliquer une fonction d'activation. Ce sont trois étapes distinctes, chacune nécessitant ses propres lectures et écritures en mémoire.

Mais voici l'astuce : nous pouvons combiner ces opérations en une seule étape. Lorsque nous exportons YOLO pour le déploiement, nous fusionnons ces opérations. Au lieu de :

1. Calculer la convolution → Enregistrer en mémoire
2. Charger depuis la mémoire → Normaliser → Enregistrer en mémoire
3. Charger depuis la mémoire → Appliquer l'activation → Enregistrer en mémoire

Nous faisons :

1. Calculer la convolution + la normalisation + l'activation → Enregistrer en mémoire

Pour un modèle YOLO classique traitant une image de 640×640, cette simple astuce élimine des gigaoctets de transferts mémoire inutiles. Sur un téléphone mobile, c'est la différence entre une détection fluide en temps réel et une latence frustrante.

Utiliser de plus petits nombres : la magie de la quantification#

YOLO n’a pas réellement besoin de valeurs ultra-précises pour détecter les objets avec précision. Pendant l’entraînement, nous utilisons 32 bits pour représenter chaque poids — c’est comme utiliser une calculatrice scientifique pour mesurer les ingrédients d’un sandwich. Pour le déploiement réel ? 8 bits suffisent amplement.

C’est ce qu’on appelle la quantification, et c’est l’une de nos techniques d’optimisation les plus puissantes. En utilisant des valeurs plus petites :

• Le modèle est réduit de 75 % (de 200 Mo à 50 Mo pour Ultralytics YOLO11x)
• Il s’exécute 2 à 4 fois plus rapidement sur la plupart des appareils
• Il consomme beaucoup moins d’énergie (la batterie de ton téléphone t’en remercie)

Toutes les couches de YOLO ne sont pas aussi sensibles à cette réduction. Les premières couches, qui détectent les contours et les formes de base ? Elles sont robustes : nous pouvons utiliser des valeurs sur 8 bits sans aucun problème. Les dernières couches de détection, qui déterminent « est-ce un chat ou un chien ? », ont besoin d’un peu plus de précision. Nous ajustons donc la précision couche par couche, en utilisant juste assez de bits pour maintenir la précision tout en maximisant la vitesse.

Nous avons constaté qu’avec une quantification soigneusement réglée, Ultralytics YOLO conserve 99,5 % de sa précision d’origine tout en s’exécutant 3 fois plus rapidement sur les téléphones. C’est ce qui distingue un modèle de recherche d’un modèle réellement utilisable dans le monde réel.

Choisir le meilleur algorithme#

Il existe des dizaines de façons différentes d’effectuer une même opération mathématique. Une convolution simple (l’opération centrale de YOLO) peut être calculée à l’aide d’algorithmes complètement différents, et le meilleur choix dépend de ton matériel et de la taille de tes entrées.

Lorsque nous exportons YOLO, notre framework d’optimisation teste différents algorithmes et sélectionne effectivement le plus rapide pour ton cas précis. C’est comme disposer de plusieurs itinéraires vers la même destination et choisir en fonction des conditions de circulation actuelles. Sur un GPU, nous pouvons utiliser un algorithme qui traite de nombreux pixels simultanément. Sur un CPU, nous pouvons en utiliser un qui est optimisé pour le traitement séquentiel. Les mathématiques restent les mêmes, mais la stratégie d’exécution est complètement différente.

Mémoire : le goulot d’étranglement caché#

Tu te souviens quand nous avons expliqué que la mémoire constituait le véritable goulot d’étranglement de l’informatique moderne ? C’est particulièrement vrai pour YOLO. Le modèle peut comporter 50 millions de paramètres et, pendant l’inférence, il crée des gigaoctets de résultats intermédiaires. Déplacer toutes ces données est souvent plus lent que le calcul lui-même.

Nous utilisons plusieurs astuces pour réduire au minimum les déplacements de données :

Planification intelligente : nous organisons les opérations de sorte que les données soient utilisées immédiatement, tant qu’elles se trouvent encore dans la mémoire cache rapide. Pour le réseau pyramidal de caractéristiques de YOLO, cela réduit le trafic mémoire de 40 %.

Découpage en tuiles : au lieu de traiter une image entière en une seule fois, nous la divisons en petites tuiles qui tiennent dans le cache. Le processeur peut ainsi travailler avec une mémoire locale rapide au lieu de récupérer constamment les données depuis la mémoire principale, plus lente.

Réutilisation des tampons : plutôt que de créer constamment de nouvelles zones mémoire pour les résultats intermédiaires, nous réutilisons les mêmes tampons mémoire. C’est incroyablement efficace : l’intégralité du backbone de YOLO peut fonctionner avec un simple ensemble de tampons réutilisables.

Élagage : moins, c’est plus#

Voici un fait surprenant : les modèles YOLO sont souvent surdimensionnés. Nous pouvons supprimer 30 % des canaux dans de nombreuses couches avec un impact pratiquement nul sur la précision. Il ne s’agit pas seulement de réduire la taille du modèle : il devient aussi plus rapide, car il y a littéralement moins de calculs à effectuer.

Le processus est élégant : nous analysons les parties du réseau qui contribuent le moins aux résultats finaux de détection, nous les supprimons, puis nous affinons le modèle pour compenser. Un modèle YOLO11m élagué peut être 30 % plus rapide tout en conservant 99 % de sa précision d’origine. Sur les appareils alimentés par batterie, ce gain d’efficacité peut représenter plusieurs heures d’autonomie supplémentaires.

Accélération matérielle : tirer parti des atouts de chaque puce#

Les différents processeurs excellent dans des tâches différentes, et les écarts de performances sont considérables. Le même modèle YOLO11n prend :

• 45 millisecondes par image sur un CPU Intel moderne
• 4 millisecondes sur un GPU NVIDIA RTX
• 22 millisecondes sur le processeur haut de gamme d’un téléphone
• 15 millisecondes sur une TPU Google Coral destinée à l’edge

Il ne s’agit pas simplement de différences de vitesse dues aux fréquences d’horloge : elles reflètent des différences architecturales fondamentales. Les GPU disposent de milliers de cœurs qui fonctionnent en parallèle, ce qui convient parfaitement aux convolutions de YOLO. Les NPU mobiles possèdent des circuits spécialisés conçus spécifiquement pour les réseaux neuronaux. Les CPU sont polyvalents, flexibles, mais non spécialisés.

La clé de l’optimisation consiste à adapter les opérations de YOLO à ce que chaque puce exécute le mieux. Un GPU aime effectuer simultanément la même opération sur de nombreuses données. Un NPU mobile ne prend parfois en charge que certaines opérations, mais les exécute avec une efficacité remarquable. Une TPU destinée à l’edge ne fonctionne qu’avec des entiers sur 8 bits, mais atteint une vitesse impressionnante dans cette contrainte.

La magie de la compilation#

Lorsque tu exportes un modèle YOLO, quelque chose de remarquable se produit en arrière-plan. Nous ne convertissons pas simplement le format du fichier : nous compilons réellement le modèle spécifiquement pour ton matériel cible. C’est comme la différence entre Google Traduction et un locuteur natif. Le processus de compilation :

1. Analyse ton modèle pour comprendre sa structure et ses besoins
2. Prend en compte les capacités de ton matériel — ses points forts et ses difficultés
3. Génère du code optimisé qui parle le langage natif de ton matériel

Le compilateur peut réorganiser les opérations pour mieux utiliser le cache de ton processeur, sélectionner des instructions spécialisées prises en charge par ta puce, voire utiliser l’apprentissage automatique pour trouver la meilleure stratégie d’optimisation. Oui, nous utilisons l’IA pour optimiser l’IA : le futur est là !

Cette étape de compilation peut multiplier les performances par 10. Le même modèle YOLO peut avancer péniblement avec du code générique, mais filer avec des instructions correctement optimisées.

Déploiement réel sur des appareils edge#

Voyons ce qui se passe lorsque YOLO rencontre le monde réel — plus précisément, le contexte exigeant des appareils edge. Imagine une caméra de sécurité qui doit exécuter YOLO 24 h/24 et 7 j/7 pour détecter des objets. Elle doit composer avec des contraintes particulièrement sévères :

• Mémoire : peut-être seulement 512 Mo à 2 Go de RAM au total
• Énergie : souvent seulement 2 à 5 watts (moins qu’un chargeur de téléphone)
• Refroidissement : aucun ventilateur, uniquement une dissipation thermique passive
• Fiabilité : doit fonctionner en continu sans tomber en panne

Voici ce que l’optimisation permet d’obtenir en pratique. Une caméra de sécurité exécutant YOLO11s :

• Modèle d’origine : 15 watts, chauffe jusqu’à 85 °C, atteint 20 FPS
• Optimisé avec quantification et élagage : 3 watts, température confortable de 45 °C, atteint 25 FPS

Nous avons réduit la consommation d’énergie de 80 % tout en améliorant réellement les performances ! C’est la différence entre un appareil qui surchauffe et épuise les batteries et un appareil qui fonctionne de manière fiable pendant des années.

La clé consiste à choisir les bons compromis. Sur les appareils edge, nous faisons souvent les choix suivants :

• Utiliser la quantification INT8 (moins de précision, beaucoup moins d’énergie)
• Traiter moins d’images lorsque l’activité est faible
• Répartir le travail entre différents processeurs pour gérer la chaleur
• Garder les modèles suffisamment petits pour tenir entièrement dans la mémoire rapide

Le processus d’optimisation#

Chez Ultralytics, nous suivons une approche systématique de l’optimisation. Nous commençons par profiler le modèle afin de comprendre où le temps est réellement consacré. Souvent, les goulots d’étranglement ne se trouvent pas là où on les attend. Peut-être que 80 % du temps est consacré à quelques couches seulement, ou que les transferts mémoire dominent le temps de calcul.

Ensuite, nous appliquons les optimisations de manière itérative :

1. Commencer par les goulots d’étranglement les plus importants
2. Appliquer une seule optimisation à la fois
3. Mesurer à la fois le gain de vitesse et l’impact sur la précision
4. Conserver les optimisations qui offrent de bons compromis
5. Répéter jusqu’à atteindre nos objectifs

Par exemple, lors du déploiement de YOLO11m sur un téléphone :

• Référence : 200 ms par image, modèle de 200 Mo
• Après quantification : 80 ms par image, modèle de 50 Mo
• Après élagage : 60 ms par image, modèle de 35 Mo
• Après fusion des opérations : 45 ms par image, modèle de 35 Mo

Chaque étape améliore les performances tout en conservant plus de 99 % de la précision d’origine. Le résultat ? Une détection d’objets en temps réel sur un appareil qui tient dans ta poche.

L’avenir : l’informatique hétérogène#

Les appareils modernes deviennent plus efficaces pour utiliser plusieurs processeurs ensemble. Ton téléphone ne possède pas un seul processeur : il en possède plusieurs, chacun étant spécialisé dans des tâches différentes :

• Le capteur de la caméra dispose d’un ISP (processeur de signal d’image) pour le prétraitement
• Le NPU (unité de traitement neuronal) exécute l’inférence de YOLO
• Le CPU gère la logique complexe et la coordination
• Le GPU affiche les résultats à l’écran

L’avenir de l’optimisation de YOLO consiste à répartir intelligemment le modèle entre ces processeurs. Le NPU pourrait gérer les convolutions principales, le CPU la logique finale de détection et le GPU la visualisation des résultats. Chaque processeur fait ce qu’il sait le mieux faire, créant ainsi un pipeline plus efficace que ce qu’un seul processeur pourrait accomplir.

Nous développons des algorithmes de partitionnement intelligent qui déterminent automatiquement la meilleure façon de répartir YOLO entre les processeurs disponibles, en tenant compte non seulement de leurs capacités, mais aussi du coût du déplacement des données entre eux.

En résumé#

Optimiser les modèles YOLO ne consiste pas seulement à convertir des formats de fichiers ; il s’agit de transformer une IA de pointe en quelque chose qui fonctionne réellement dans le monde réel. Grâce à des techniques telles que la quantification (utiliser des valeurs plus petites), l’élagage (supprimer les parties inutiles), la fusion des opérations (combiner des étapes) et la gestion intelligente de la mémoire, nous obtenons des gains de performances de 10 à 100 fois tout en maintenant la précision.

Ce qui est remarquable ? Il n’existe pas d’optimisation « idéale » universelle. Un serveur cloud disposant d’une puissance illimitée nécessite des optimisations différentes de celles d’un drone alimenté par batterie. Un téléphone doté d’une puce d’IA dédiée doit être traité différemment d’un Raspberry Pi. C’est pourquoi Ultralytics propose autant d’options d’exportation : chacune est optimisée pour des scénarios différents.

Chaque optimisation dont nous avons parlé poursuit un seul objectif : rendre la vision par ordinateur accessible partout. Que tu construises une sonnette connectée, une application pour drone ou un service cloud de grande envergure, nous fournissons les outils nécessaires pour faire fonctionner YOLO dans le respect de tes contraintes.

Lorsque tu exportes un modèle YOLO avec Ultralytics, tu ne fais pas que sauvegarder un fichier. Tu tires parti de plusieurs années de recherche consacrées à rendre les réseaux neuronaux pratiques. Tu transformes un modèle d’IA de pointe en quelque chose qui peut fonctionner sur du matériel réel, avec de vraies contraintes, pour résoudre de vrais problèmes.

C’est ce que nous faisons chez Ultralytics. Nous comblons le fossé entre la recherche en IA et le déploiement pratique. Nous faisons fonctionner la vision par ordinateur partout, car l’avenir de l’IA ne consiste pas seulement à disposer des meilleurs modèles, mais à rendre ces modèles utiles dans le monde réel.