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 ! Imagine ces modèles comme de gigantesques recettes mathématiques. Ils sont composé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 telles qu’elles sont réellement : des tableaux de nombres ! Chaque pixel correspond simplement à des valeurs de couleur : la quantité de rouge, de vert et de bleu (donc RGB) pour chacun des points qui composent l’image. Nous appelons ces tableaux de nombres des « tenseurs », parce que ça sonne bien mieux que « matrices multidimensionnelles », qui sonne bien mieux que « des nombres empilés sur des nombres, eux-mêmes empilés sur des nombres ».

Quand tu fournis une image à notre modèle, elle entame un voyage épique à travers le réseau. Imagine ton tenseur surfer de couche en couche, se transformant, étant convolué et trituré mathématiquement de la plus belle façon qui soit. Vois cela comme une soirée dansante où les nombres se mélangent et se côtoient pour extraire 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.

Qu’est-ce qui ressort de l’autre côté ? Encore des nombres ! Des nombres qui ont du sens. Pour les tâches de détection, ils indiquent précisément où se trouvent les éléments 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.

Maintenant, avant que nos modèles puissent opérer leur magie, ils doivent aller à l’école : ils doivent être entraînés. C’est pendant l’entraînement que les choses deviennent sérieuses.

Pendant l’entraînement, chaque fois que nous présentons une image au réseau, nous ne nous contentons pas d’obtenir 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 ; en gros, la distance par rapport au centre de la cible). Deuxièmement, et c’est le point important, nous mettons à jour chacun des nombres (ou poids) du réseau en fonction de cette perte. Imagine que tu ajustes des milliers de minuscules boutons à la fois, chaque réglage étant calculé pour rendre le réseau plus précis.

En somme, nous entraînons 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 voit à nouveau une image semblable, il se rapproche de la bonne réponse. En somme, le réseau apprend en étant poussé dans la bonne direction, erreur après erreur, jusqu’à réussir ses prédictions.

De combien de nombres parle-t-on ? Eh bien, notre petit YOLO11n tout mignon a quelques millions de paramètres. Mais YOLO11x ? Ce monstre embarque plus de 50 millions de paramètres ! Plus de paramètres, c’est plus de détails à encoder, comme la différence entre dessiner avec des crayons de couleur et disposer de toute la palette d’un artiste.

Lors de l’inférence, le 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 tout en jonglant avec des torches enflammées.

Alors, qu’est-ce que le calcul, EXACTEMENT ? Comment tous ces calculs sont-ils réellement effectués ? Comment les accélérer ? Et que signifie au juste « optimiser le calcul » ?

Comment les puces effectuent réellement les calculs#

Les calculs sont effectués par des puces. Ces petits carrés de silicium sont en quelque sorte 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. Des circuits physiques situés à des endroits précis de la puce sont dédiés à l’addition des nombres, et d’autres aux opérations logiques. C’est comme une petite ville où différents quartiers se spécialisent dans différents types de calculs.

Cela peut sembler étrange, 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 si haute qu’on n’en voit même plus la couche du dessous. Nous avons tellement simplifié les choses que la plupart des programmeurs d’aujourd’hui n’ont aucune idée de la façon dont le calcul s’effectue réellement dans le silicium. Ce n’est pas de leur faute, c’est voulu !

Soulevons le voile sur ces couches. Prenons ce code Python tout simple :

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

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

Mais c’est là que les choses deviennent intéressantes. Entre ces trois lignes apparemment inoffensives et les électrons qui circulent réellement dans le silicium, il se produit AU MOINS quatre couches massives de traduction (il y en a en fait davantage, mais quatre suffisent à illustrer le propos). Suis-moi dans ce parcours fascinant :

Couche 1 : Python → bytecode D’abord, Python lit ton code et le compile en 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 là que ton élégant « if x == 1 » devient quelque chose comme « CHARGER registre, COMPARER registre, SAUTER si indicateur zéro activé ».

Couche 3 : Code machine → microcode Retournement de situation ! Les processeurs modernes n’exécutent même pas directement le code machine. Ils le décomposent encore en microcode, des opérations encore plus petites que les composants internes de la puce peuvent traiter. Ton unique instruction « ADD » peut ainsi devenir plusieurs micro-opérations.

Couche 4 : Microcode → électronique physique Enfin, nous arrivons au silicium. Ces micro-opérations déclenchent de véritables signaux électriques qui circulent dans les transistors. Des milliards de minuscules interrupteurs s’ouvrent et se ferment, des électrons dansent sur des chemins soigneusement conçus et, d’une manière ou d’une autre, par magie, 1 + 1 devient 2.

Chaque couche existe pour masquer l’incroyable complexité de la couche inférieure. C’est comme ces poupées russes, sauf que chaque poupée parle une langue totalement différente et que la plus petite est littéralement faite d’éclairs emprisonnés dans du sable.

L’ironie ? Ces trois lignes de Python déclenchent probablement des MILLIONS de commutations de transistors. Mais grâce à ces abstractions, tu n’as pas besoin d’y penser. Il te suffit d’écrire « y = x + 1 » et de faire confiance à la magie qui opère quelque part, au cœur du silicium.

L’architecture#

Chaque opération est physiquement implémentée dans le silicium, et l’endroit où elle s’effectue sur la puce dépend entièrement de la topologie de celle-ci. C’est comme l’urbanisme, mais pour les électrons. L’additionneur est ici, le multiplicateur est là, et ils doivent tous 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 les distingue ? Leur topologie, c’est-à-dire la disposition et l’implémentation physique des opérations. C’est ce que nous appelons l’architecture, et il en existe énormément :

• x86 (Intel et AMD) - Le grand ancêtre de l’informatique de bureau, complexe mais puissant
• ARM - Fait fonctionner ton téléphone et de plus en plus d’ordinateurs portables ; conçu pour l’efficacité énergétique
• RISC-V - Le rebelle open source qui gagne du terrain partout
• PowerPC - Le monstre d’IBM, autrefois utilisé dans les consoles de jeux et encore courant dans les systèmes embarqués
• MIPS - Le favori des universitaires, simple et élégant
• SPARC - La contribution de Sun Microsystems (aujourd’hui 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 utilisées pour envoyer des instructions à ces machines sont totalement différentes. C’est comme si tu devais écrire un itinéraire pour quelqu’un, mais que tu devais l’écrire en français, en mandarin ou en danse expressive selon sa voiture.

Le cœur battant du silicium#

Le carburant de nos puces, ce sont les électrons : l’électricité qui entre 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 fasse circuler les données dans son réseau complexe, tout dépend d’un composant essentiel : l’horloge. C’est elle qui fait circuler les électrons dans des chemins précis à des moments précis. Sans elle, tu aurais du silicium alimenté qui ne ferait rien.

Imagine que tu doives coordonner un spectacle gigantesque où des milliards de composants doivent bouger parfaitement à l’unisson. Sans rythme, ce serait le chaos. C’est exactement ce que fait l’horloge pour ton processeur. C’est un cristal qui vibre à une cadence incroyablement régulière et émet des impulsions électriques des milliards de fois par seconde.

Quand tu entends « processeur à 3,5 GHz », ces GHz (gigahertz) correspondent à la fréquence d’horloge : 3,5 milliards de battements par seconde. Chaque battement s’appelle un cycle d’horloge, et c’est 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 une partie extrême de feu rouge, feu vert. À chaque « feu vert » (impulsion d’horloge) :

• Les données circulent 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 beaucoup (une division ou la récupération de données depuis la RAM). Tout est minutieusement orchestré : des milliards de composants effectuent leurs opérations spécifiques, tous synchronisés au rythme incessant de l’horloge.

Tu peux overclocker ton processeur en augmentant sa fréquence d’horloge : tout fonctionne plus vite, mais produit aussi plus de chaleur et devient moins stable. Si tu pousses trop loin, ton ordinateur plante, car les électrons n’arrivent littéralement plus à suivre la cadence.

Autrefois, ces opérations étaient effectuées par des machines de la taille de pièces entières. Pourtant, les composants qui réalisent tous ces calculs sont remarquablement simples : ce ne sont que des interrupteurs. Des interrupteurs qui s’ouvrent ou se ferment.

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

Cette simplicité signifie qu’avec des interrupteurs — quels qu’ils soient —, tu peux construire un ordinateur. Des gens ont fabriqué des ordinateurs fonctionnels avec des conduites d’eau et des valves, 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 doués pour fabriquer des interrupteurs minuscules. Ton téléphone a plus 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 dotés de millions de paramètres, nous activons et désactivons ces minuscules interrupteurs des milliards de fois par seconde, parfaitement synchronisés au rythme 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 fasse sonner ton ordinateur comme s’il tentait de décoller !

Faisons ronronner les réseaux neuronaux#

Bon, nous avons des puces avec des milliards d’interrupteurs qui dansent au rythme d’un cristal, et nous voulons y exécuter des réseaux neuronaux dotés de millions de paramètres. Ça devrait être facile, non ? Il suffit d’envoyer les nombres à la puce et de la laisser tout faire !

Exécuter rapidement des réseaux neuronaux, c’est comme essayer de préparer un repas de cinq plats dans une cuisine où 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 250 kilos. Les calculs eux-mêmes ne sont pas le problème principal ; c’est tout le reste.

L’inadéquation des architectures#

La plupart des puces ont été conçues pour faire tourner 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 instructions if, des boucles et à calculer parfois tes impôts (le seul calcul qui épuise même émotionnellement les supercalculateurs). Il est optimisé pour les opérations séquentielles : faire ceci, puis cela, puis autre chose.

Mais les réseaux neuronaux fonctionnent de façon totalement différente. Ils veulent tout faire EN MÊME TEMPS. Pendant l’entraînement, tu mets à jour des millions de poids en fonction des erreurs de tes prédictions. Pendant l’inférence (l’utilisation effective du modèle entraîné), tu fais passer des données dans des millions de calculs simultanés. Imagine que tu doives multiplier un million de nombres par un autre million de nombres. Ton CPU, aussi vaillant soit-il, veut les traiter un par un, comme un comptable très rapide mais très méthodique.

C’est pourquoi les GPU sont devenus le pilier 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 se trouve que le calcul de couleurs de pixels et les calculs des réseaux neuronaux sont étonnamment similaires : dans les deux cas, la même opération est appliquée en parallèle à d’énormes quantités de données.

Mais même les GPU ne sont pas parfaits pour les réseaux neuronaux. C’est pourquoi les entreprises construisent désormais des puces spécialisées pour l’IA (TPU, NPU et tous les autres acronymes qui se terminent par PU). Ces puces sont conçues de A à Z avec un seul objectif : accélérer les réseaux neuronaux. C’est comme engager un chef qui ne sait cuisiner qu’un seul plat, mais le prépare à une vitesse surhumaine. Alors que ton CPU peine à effectuer des opérations matricielles séquentielles et que ton GPU les traite assez bien en parallèle, ces puces spécialisées dévorent des 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 les calculs)#

Dans les calculs modernes des réseaux neuronaux, nous passons plus de temps et dépensons plus d’énergie à DÉPLACER les données qu’à EFFECTUER des calculs avec elles.

Imagine que ta puce soit un mathématicien brillant et rapide comme l’éclair, mais dont tous les ouvrages de référence se trouvent dans différents bâtiments à l’autre bout de la ville. Il peut résoudre instantanément n’importe quelle équation, mais il doit d’abord récupérer les nombres, et ce trajet prend une éternité.

Ta puce peut multiplier deux nombres en un cycle d’horloge (souviens-toi : l’un de ces milliards de battements par seconde). À la vitesse de l’éclair ! Mais transférer ces nombres de la mémoire à 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 devait marcher cinq minutes jusqu’à la bibliothèque et en revenir.

La raison tient à la distance (et à l’espace). L’électricité se déplace vite, mais pas à une vitesse infinie. Plus les données doivent parcourir de 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 plusieurs lieux de stockage situés à différentes distances :

• Registres (directement intégrés 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 du bureau. Il faut 3 à 4 cycles pour y prendre 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 pour y accéder et il peut contenir quelques millions de nombres.
• Cache L3 (à l’autre bout de la puce) : le local de stockage en bas. Il faut 30 à 50 cycles pour y accéder ; il peut contenir des dizaines de millions de nombres.
• RAM (sur une puce totalement différente) : l’entrepôt à l’autre bout de la ville. Il faut 100 à 300 cycles pour y accéder. C’est là que se trouvent tes milliards de nombres.
• SSD/disque dur (connecté par des câbles) : une autre ville, carrément. Il faut des millions de cycles pour y accéder. Énorme capacité de stockage, 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 énorme quantité. Le principe reste toutefois le même : une mémoire plus proche est plus rapide, mais plus petite.

Voici maintenant ce qui complique les choses pour les réseaux neuronaux. Imagine que ton modèle Ultralytics YOLO ait 50 millions de paramètres (ChatGPT en a des milliards, au passage). Cela représente 50 millions de nombres qui doivent circuler entre la mémoire et 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 dans la RAM, tu passes 99 % de ton temps à attendre la livraison. C’est comme avoir une voiture de Formule 1 coincée dans les embouteillages. Toute cette puissance de calcul reste là, à attendre que les données arrivent.

Voici le point essentiel : 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 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 fait 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 cherchent plutôt des moyens ingénieux de réduire les déplacements de données, d’améliorer leur mise 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 accordent une importance capitale à la bande passante mémoire et aux 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 afin de 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 ont les calculatrices les plus rapides, mais ceux qui ont trouvé comment les alimenter continuellement en données. Tout se joue sur l’optimisation des schémas d’accès à la mémoire.

Chaque fois que tu déplaces un peu de données, tu consommes de l’énergie. Pas beaucoup, on parle de picojoules, mais quand tu déplaces des téraoctets par seconde, ça finit par compter TRÈS vite. En fait, déplacer des données de 1 mm sur une puce consomme plus d’énergie que le calcul lui-même !

C’est pourquoi ton ordinateur portable fait un bruit de réacteur quand tu entraînes des réseaux neuronaux. Ce n’est pas le calcul qui génère de la chaleur, mais le déplacement des données. Chaque mise à jour de paramètres, chaque calcul de gradient, chaque passe avant chauffe littéralement ta pièce.

Les accélérateurs d’IA modernes sont essentiellement des exercices de thermodynamique. Quelle quantité de calcul peut-on intégrer avant que la puce ne fonde ? À quelle vitesse peut-on évacuer la chaleur ? C’est comme l’overclocking, sauf que la fréquence est toujours à fond, et qu’on essaie juste de ne pas déclencher un incendie.

La solution ? Une conception tenant compte de l’architecture#

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

• Gardent les données en local autant que possible
• Réutilisent les calculs sans relâche
• S’alignent parfaitement sur les capacités du matériel
• Réduisent au minimum les déplacements de mémoire, à tout prix

C’est comme la différence entre une recette qui dit « utilise des 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 relève de l’art. Il ne suffit pas d’avoir de bonnes équations : il faut comprendre le matériel, respecter la hiérarchie mémoire et danser en parfaite harmonie avec l’architecture.

Bienvenue dans un monde où l’informatique rencontre la physique, l’ingénierie et la pure magie. Où déplacer un nombre coûte plus cher que de le calculer. Où le parallélisme accélère les choses, mais où la synchronisation est fatale. Où ton pire ennemi n’est pas la complexité, mais la distance.

Comment nous accélérons YOLO#

Quand tu entraînes un modèle YOLO, tu obtiens un réseau neuronal qui fonctionne à merveille dans ton environnement d’entraînement. Mais voilà : ton GPU de jeu, ton iPhone et la minuscule puce d’une caméra de sécurité parlent tous des langages complètement différents. Ils ont des points forts et des faiblesses qui leur sont propres, et des façons très différentes 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. À l’inverse, une puce mobile peut avoir des circuits spéciaux conçus pour les opérations d’IA, mais ne prendre en charge que certains types de calculs. Et l’appareil en périphérie dans ta sonnette vidéo ? Il essaie de faire tourner 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, car chacun est optimisé pour du matériel différent. Il ne s’agit pas d’avoir trop d’options, mais de choisir celle qui convient à TES besoins spécifiques.

Fusion des opérations : faire plus avec moins#

Dans le modèle YOLO d’origine, de nombreuses opérations s’exécutent en séquence. Par exemple, on peut effectuer une convolution, puis normaliser les résultats et enfin appliquer une fonction d’activation. Cela fait 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. Lors de l’exportation de 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 ce qui fait la différence entre une détection fluide en temps réel et des ralentissements frustrants.

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

YOLO n’a pas réellement besoin de nombres extrêmement précis pour détecter les objets avec exactitude. 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 ? 8 bits suffisent largement.

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

• Le modèle est réduit de 75 % (de 200 Mo à 50 Mo pour Ultralytics YOLO11x)
• Il s’exécute 2 à 4 fois plus vite sur la plupart des appareils
• Il consomme beaucoup moins d’énergie (la batterie de ton téléphone te 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 nombres 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.

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 fondamentale 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 des entrées.

Lors de l’exportation de YOLO, notre framework d’optimisation teste différents algorithmes et choisit le plus rapide pour ton cas précis. C’est comme avoir plusieurs itinéraires vers une même destination et choisir en fonction de la circulation. Sur un GPU, nous pouvons utiliser un algorithme qui traite de nombreux pixels simultanément. Sur un CPU, nous pouvons en choisir un optimisé pour le traitement séquentiel. Les calculs sont les mêmes, mais la stratégie d’exécution est complètement différente.

La mémoire : le goulot d’étranglement caché#

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

Nous utilisons plusieurs astuces pour réduire les déplacements de mémoire :

Planification intelligente : nous organisons les opérations afin 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 à la fois, nous la divisons en petites tuiles qui tiennent dans le cache. Le processeur peut ainsi travailler avec une mémoire locale rapide plutôt que de récupérer constamment des données dans la mémoire principale, plus lente.

Réutilisation des tampons : au lieu de créer sans cesse 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’ensemble du backbone de YOLO peut fonctionner avec quelques tampons réutilisables.

Élagage : moins, c’est mieux#

Voici un fait surprenant : les modèles YOLO sont souvent surdimensionnés. On peut souvent supprimer des canaux dans de nombreuses couches sans presque aucun effet 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 de détection finaux, nous les supprimons, puis nous affinons le modèle pour compenser. 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 points forts de chaque puce#

Chaque processeur excelle dans des domaines différents, et les écarts de performances ne se résument pas à des différences de fréquence d’horloge : ils reflètent des différences fondamentales d’architecture. Les GPU disposent de milliers de cœurs fonctionnant en parallèle, idéaux pour les 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 sait faire le mieux. Un GPU aime effectuer la même opération sur de nombreuses données simultanément. Un NPU mobile ne prend en charge que certaines opérations, mais les exécute avec une efficacité incroyable. Un TPU de périphérie ne fonctionne qu’avec des entiers sur 8 bits, mais offre une vitesse remarquable dans ces limites.

La magie de la compilation#

Quand tu exportes un modèle YOLO, il se passe quelque chose de remarquable en arrière-plan. Nous ne faisons pas que convertir le format de 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 en comprendre la structure et les exigences
2. Tient compte des 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 exploiter 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 s’envoler avec des instructions correctement optimisées.

Déploiement en périphérie dans le monde réel#

Voyons ce qui se passe lorsque YOLO rencontre le monde réel, et plus précisément l’univers exigeant des appareils périphériques. 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 de fortes contraintes :

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

L’essentiel est de choisir les bons compromis. Sur les appareils en périphérie, nous :

• Utilisons la quantification INT8 (moins de précision, beaucoup moins d’énergie)
• Traitons moins d’images quand l’activité est faible
• Répartissons le travail entre différents processeurs pour maîtriser la chaleur
• Gardons les modèles assez 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. D’abord, nous profilons le modèle pour comprendre où le temps est réellement passé. 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 principaux goulots d’étranglement
2. Appliquer une 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

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

Les appareils modernes deviennent plus intelligents dans leur façon d’utiliser plusieurs processeurs ensemble. Ton téléphone n’a pas un seul processeur : il en a plusieurs, chacun 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 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 s’occuper des convolutions principales, le CPU de la logique finale de détection et le GPU de la visualisation des résultats. Chaque processeur fait ce qu’il sait faire le mieux, créant un pipeline plus efficace que ce qu’un seul processeur pourrait réaliser.

Nous développons des algorithmes de partitionnement intelligents 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 des transferts de 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 une solution qui fonctionne concrètement dans le monde réel. Grâce à des techniques comme la quantification (utilisation de nombres plus petits), l’élagage (suppression des parties inutiles), la fusion d’opérations (combinaison d’étapes) et la gestion intelligente de la mémoire, nous améliorons considérablement les performances tout en préservant la précision.

Ce qui est remarquable ? Il n’existe pas d’optimisation « meilleure » universelle. Un serveur cloud à la 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 nécessite un traitement différent de celui 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é sert un seul objectif : rendre la vision par ordinateur accessible partout. Que tu développes une sonnette connectée, une application pour drone ou un vaste service cloud, nous fournissons les outils nécessaires pour faire fonctionner YOLO dans les limites de ton environnement.

Lorsque tu exportes un modèle YOLO avec Ultralytics, tu ne fais pas que sauvegarder un fichier. Tu mets à profit des années de recherche visant à rendre les réseaux neuronaux pratiques. Tu transformes un modèle d’IA de pointe en un outil capable de 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 faisons le lien 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 à avoir les meilleurs modèles, mais aussi à les rendre utiles dans le monde réel.