Comment chez Ultralytics, nous rendons les modèles YOLO plus rapides 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 des recettes mathématiques géantes. Ils sont composés d'opérations (que nous appelons couches) et d'une masse énorme de nombres que nous appelons poids.

Nos modèles Ultralytics YOLO traitent les images pour ce qu'elles sont vraiment : des tableaux de nombres ! Chaque pixel n'est en fait que des valeurs de couleur, la quantité de Rouge, Vert et Bleu (donc RGB) pour chaque point composant l'image. Nous appelons ces tableaux de nombres "tensors" car cela sonne beaucoup mieux que "matrices multidimensionnelles", ce qui sonne déjà mieux que "nombres empilés sur des nombres empilés sur des nombres".

Lorsque tu introduis une image dans notre modèle, elle entame un voyage épique à travers le réseau. Imagine ton tensor surfer d'une couche à l'autre, se faisant transformer, convoluer et manipuler mathématiquement de la plus belle des manières possible. Pense à cela comme à une soirée dansante où les nombres se mélangent et interagissent, extrayant l'essence de ce qui fait qu'un chat est un chat ou qu'une voiture est une voiture. Nous appelons ce processus extraction de caractéristiques.

Qu'est-ce qui sort à l'autre extrémité ? D'autres nombres ! Des nombres significatifs. Dans les tâches de détection, ils te disent 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 inférence.

Maintenant, avant que nos modèles puissent opérer leur magie, ils doivent aller à l'école ; ils doivent être entraînés. La partie entraînement est là où les choses deviennent intenses.

Pendant l'entraînement, chaque fois que nous présentons une image au réseau, nous n'obtenons pas simplement une réponse. Nous effectuons deux tâches très lourdes. Premièrement, nous calculons à quel point le réseau s'est trompé (ce que nous appelons la perte, soit la distance par rapport à la cible). Deuxièmement, et c'est la partie importante, nous mettons à jour chaque chiffre (ou poids) du réseau en fonction de cette perte. Imagine cela comme le réglage de milliers de minuscules boutons en même temps, où chaque ajustement est calculé pour rendre le réseau plus précis à chaque itération.

Nous entraînons essentiellement le réseau par la 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 similaire, il se rapproche de la bonne réponse. En somme, le réseau apprend en étant orienté dans la bonne direction, erreur après erreur, jusqu'à ce qu'il commence à réussir ses prédictions.

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

Pendant l'inférence, ce nombre de paramètres devient crucial. Faire tourner un réseau de 3 millions de paramètres, c'est comme faire un petit jogging autour du pâté de maisons. Faire tourner 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 le rendons-nous plus rapide ? Et que signifie même "optimiser le calcul" ?

Link to this sectionComment les puces font réellement les calculs#

Le calcul se fait avec des puces. Ces petits carrés de silicium sont essentiellement les châteaux de sable les plus organisés de l'univers. Chaque opération que ton ordinateur effectue, chaque addition, chaque comparaison, chaque "si ceci alors cela", est physiquement gravé dans le silicium. Il existe de vrais circuits physiques dans des zones spécifiques de la puce dédiées à l'addition de nombres, et d'autres pour les opérations logiques. C'est comme avoir 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 sur couche d'abstraction, comme une lasagne technologique devenue si haute qu'on ne peut même plus voir la plaque du fond. Nous avons tellement simplifié les choses que la plupart des programmeurs aujourd'hui n'ont aucune idée de la façon dont le calcul se produit réellement dans le silicium. Pas par leur faute, mais par conception !

Retirons ces couches. Prends ce code Python ultra simple :

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

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

Mais c'est là que ça devient intéressant. Entre ces trois lignes innocentes et les électrons se déplaçant réellement à travers le silicium, il y a AU MOINS quatre énormes couches de traduction qui se produisent (il y en a en fait plus, mais notre responsable du contenu numérique dit que mon nombre de mots lui donne déjà de l'anxiété). Laisse-moi te guider à travers ce voyage hallucinant :

Couche 1 : Python → Bytecode D'abord, Python lit ton code et le compile en quelque chose appelé bytecode, un langage intermédiaire plus facile à digérer pour les ordinateurs mais qui te ferait saigner les 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 que ton processeur comprend. C'est là que ton élégant "if x == 1" devient quelque chose comme "CHARGER registre, COMPARER registre, SAUTER si le drapeau zéro est défini."

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

Couche 4 : Microcode → Électronique Physique Enfin, nous arrivons au silicium. Ces micro-opérations déclenchent des signaux électriques réels qui circulent à travers les transistors. Des milliards de minuscules interrupteurs s'allument et s'éteignent, des électrons dansent sur des chemins soigneusement conçus et, d'une manière ou d'une autre, comme par magie, 1 + 1 devient 2.

Chaque couche existe pour cacher la complexité folle de la couche en dessous. C'est comme ces poupées russes, sauf que chaque poupée parle une langue complètement différente, et que la plus petite poupée est littéralement faite d'éclairs piégés dans du sable.

L'ironie ? Ces trois lignes de Python déclenchent probablement des MILLIONS d'interrupteurs à transistor. Mais grâce à ces abstractions, tu n'as pas besoin de penser à tout ça. Tu écris simplement "y = x + 1" et tu fais confiance au fait que, quelque part, au plus profond du silicium, la magie opère.

Link to this sectionL'architecture#

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

Nous avons des centaines de puces différentes sur le marché, chacune conçue pour des objectifs différents. Qu'est-ce qui change entre elles ? La topologie, comment les opérations sont positionnées et implémentées dans le domaine physique. C'est ce que nous appelons l'architecture, et mon Dieu, 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 - La bête d'IBM, toujours en service dans les consoles de jeux et les serveurs
• MIPS - Le favori des universitaires, simple et élégant
• SPARC - La contribution de Sun Microsystems (maintenant Oracle) au calcul haute performance
• Architectures GPU (cœurs CUDA de NVIDIA, RDNA d'AMD) - Des monstres de traitement parallèle

Chaque architecture arrange non seulement ses transistors différemment, mais parle aussi une langue différente. Les abstractions que nous utilisons pour envoyer des instructions à ces machines sont totalement différentes. C'est comme devoir écrire des instructions de voyage pour quelqu'un, mais selon sa voiture, tu pourrais devoir écrire en français, en mandarin ou en danse interprétative.

Link to this sectionLe battement de cœur du silicium#

Le carburant de nos puces, ce sont les électrons, de l'électricité qui circule dans la puce, fournissant l'énergie pour le calcul. Mais l'énergie seule ne suffit pas. Pour qu'une puce fonctionne vraiment, pour déplacer les données à travers sa topologie complexe, tout dépend d'un composant critique : l'horloge. C'est ce qui fait circuler les électrons le long de chemins spécifiques à des moments précis. Sans cela, tu aurais juste du silicium alimenté ne faisant rien.

Imagine essayer de coordonner une performance massive où des milliards de composants doivent bouger en parfaite synchronisation. Sans battement, ce serait le chaos. C'est exactement ce que fait l'horloge pour ton processeur. C'est un cristal qui vibre à une fréquence incroyablement constante, envoyant des impulsions électriques des milliards de fois par seconde.

Quand tu entends "processeur 3,5 GHz", ce GHz (gigahertz) est la vitesse d'horloge, soit 3,5 milliards de battements par seconde. Chaque battement est appelé un cycle d'horloge, et c'est l'unité de temps fondamentale en informatique.

RIEN ne se passe entre les cycles d'horloge. L'ordinateur entier se fige, en attendant le prochain battement. C'est comme le jeu le plus extrême de "1, 2, 3, soleil". À 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 prennent de nombreux cycles (une division ou récupérer des données de la RAM). C'est précisément chorégraphié, des milliards de composants effectuant leurs opérations spécifiques, tous synchronisés sur ce battement implacable.

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

À l'époque, ces opérations étaient implémentées avec des machines de la taille d'une pièce. Mais les composants qui effectuent tout ce calcul sont remarquablement simples : ce ne sont que des interrupteurs. Des interrupteurs marche/arrêt.

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

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

Les principes n'ont pas changé depuis les années 1940. Nous sommes simplement devenus incroyablement doués pour rendre les interrupteurs extrêmement petits. 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 trouvé comment fabriquer des interrupteurs à l'échelle atomique.

Lorsque nous exécutons des réseaux de neurones avec des millions de paramètres, nous actionnons ces minuscules interrupteurs des milliards de fois par seconde, tous parfaitement synchronisés avec ce battement de cœur de cristal. Chaque mise à jour de poids, chaque multiplication de matrice, chaque fonction d'activation, ils marchent tous au rythme de l'horloge.

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

Link to this sectionFaire rugir les réseaux de neurones#

D'accord, nous avons donc ces puces avec des milliards d'interrupteurs dansant au rythme d'un cristal, et nous voulons faire tourner des réseaux de neurones avec des millions de paramètres dessus. Ça devrait être facile, non ? Il suffit de jeter les nombres à la puce et de laisser faire !

Faire tourner rapidement des réseaux de neurones, c'est comme essayer de cuisiner un repas à cinq plats dans une cuisine où le réfrigérateur est à trois pâtés de maisons, où tu n'as qu'une seule poêle et où chaque ingrédient pèse 250 kilos. Le calcul en soi n'est pas le plus gros problème ; c'est tout le reste.

Link to this sectionL'inadéquation de l'architecture#

La plupart des puces ont été conçues pour faire tourner Microsoft Word, pas des réseaux de neurones. Ton CPU a été construit en pensant qu'il passerait sa vie à exécuter des instructions if, des boucles et à calculer occasionnellement tes impôts (le seul calcul que même les superordinateurs trouvent émotionnellement épuisant). Il est optimisé pour les opérations séquentielles : fais ceci, puis cela, puis l'autre chose.

Mais les réseaux de neurones 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'erreur de tes prédictions. Pendant l'inférence (utiliser réellement le modèle entraîné), tu pousses des 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, béni soit-il, veut les faire un par un, comme un comptable très rapide mais très méthodique.

C'est pourquoi les GPU sont devenus l'épine dorsale du calcul en IA. Les GPU ont été conçus pour les jeux vidéo, où tu dois calculer simultanément la couleur de millions de pixels. Il s'avère que calculer les couleurs des pixels et faire des calculs de réseaux de neurones sont étonnamment similaires : les deux impliquent d'effectuer la même opération sur des quantités massives de données en parallèle.

Mais même les GPU ne sont pas parfaits pour les réseaux de neurones. C'est pourquoi les entreprises construisent maintenant des puces IA spécialisées (TPU, NPU et tout autre acronyme finissant par PU). Ces puces sont conçues dès le départ avec une seule mission : faire aller les réseaux de neurones vite. Elles sont comme embaucher un chef qui ne sait cuisiner qu'un seul plat, mais qui le cuisine à une vitesse surhumaine. Alors que ton CPU lutte avec des opérations matricielles de manière séquentielle et que ton GPU les gère plutôt bien en parallèle, ces puces spécialisées mangent des matrices au petit-déjeuner, au déjeuner et au dîner.

Link to this sectionLe mur de la mémoire (Ou : Pourquoi déplacer des Bits est plus dur que les maths)#

Dans le calcul moderne des réseaux de neurones, nous passons plus de temps et d'énergie à DÉPLACER des données qu'à réellement CALCULER avec elles.

Pense à ta puce informatique comme à un mathématicien brillant qui travaille à la vitesse de l'éclair, mais dont tous les livres de référence sont stockés dans des bâtiments différents à travers la ville. Il peut résoudre n'importe quelle équation instantanément, mais d'abord, il doit obtenir les nombres, et ce voyage prend une éternité.

Ta puce peut multiplier deux nombres en un cycle d'horloge (souviens-toi, c'est l'un de ces milliards de battements par seconde). Rapide comme l'éclair ! Mais obtenir 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 avait besoin de cinq minutes pour aller à la bibliothèque et revenir.

La raison est la distance (et l'espace). L'électricité se déplace vite, mais pas infiniment vite. Plus les données doivent voyager loin sur la puce, plus cela prend de temps. Les concepteurs d'ordinateurs ont résolu cela en créant une hiérarchie de mémoire, comme avoir plusieurs lieux de stockage à différentes distances :

• Registres (intégrés directement dans les unités de calcul) : Le bureau de ton mathématicien. Accès instantané ! Mais c'est minuscule, tu ne peux garder qu'environ 32 nombres ici. C'est comme avoir des post-its juste devant toi.
• Cache L1 (à quelques micromètres) : La bibliothèque dans le bureau. Cela prend 3-4 cycles pour saisir quelque chose. Ici, tu peux faire tenir quelques milliers de nombres.
• Cache L2 (à quelques millimètres) : Le classeur dans le couloir. Prend 10-15 cycles et peut contenir quelques millions de nombres.
• Cache L3 (à travers la puce) : La salle de stockage en bas. Prend 30-50 cycles, contenant des dizaines de millions de nombres.
• RAM (sur une puce complètement différente) : L'entrepôt à l'autre bout de la ville. Cela prend 100-300 cycles. C'est là que vivent tes milliards de nombres.
• SSD/Disque dur (connecté par des câbles) : Une autre ville entièrement. Prend des millions de cycles. Stockage massif, vitesse glaciale.

Les structures exactes varient, la puce de ton téléphone pourrait sauter le cache L3, tandis qu'un CPU de serveur pourrait en avoir des quantités massives. Le principe, cependant, reste le même : une mémoire plus proche est plus rapide mais plus petite.

Maintenant, c'est là que ça devient douloureux pour les réseaux de neurones. Imagine que ton modèle Ultralytics YOLO a 50 millions de paramètres (ChatGPT en a des milliards, au passage). Ce sont 50 millions de nombres qui doivent voyager de la mémoire aux unités de calcul et inversement. Même si chaque nombre ne fait que 4 octets, ce sont 200 mégaoctets de données qui doivent circuler 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 de la RAM, tu passes 99 % de ton temps à attendre la livraison. C'est comme avoir une voiture de Formule 1 dans un embouteillage. Toute cette puissance de calcul, assise là, attendant que les données arrivent.

Voici l'idée cruciale : c'est LE goulot d'étranglement de l'informatique moderne. C'est ce qu'on appelle le goulot d'étranglement de von Neumann. Rendre les puces plus rapides en mathématiques est relativement facile. Rendre la mémoire plus rapide se heurte aux limites physiques. C'est pourquoi presque TOUTE l'optimisation des performances en IA se produit au niveau de la mémoire. Lorsque les ingénieurs accélèrent les réseaux de neurones, ils rendent rarement les mathématiques plus rapides ; ils trouvent des moyens ingénieux de déplacer moins de données, de mieux les mettre en cache ou d'y accéder plus intelligemment.

Les puces IA modernes ne se concentrent pas seulement sur la vitesse de calcul ; elles sont obsédées par la bande passante mémoire et les stratégies de déplacement de données. Elles pré-récupèrent les données, réutilisent les valeurs déjà en cache et organisent les calculs pour minimiser les trajets en mémoire. Les gagnants dans la course au matériel IA ne sont pas ceux avec les calculatrices les plus rapides ; ce sont ceux qui ont trouvé comment garder ces calculatrices alimentées en données. Tout le jeu consiste à optimiser les modèles d'accès à la mémoire.

Chaque fois que tu déplaces un bit de données, tu brûles de l'énergie. Pas grand-chose, on parle de picojoules, mais quand tu déplaces des téraoctets par seconde, ça s'additionne VITE. En fait, déplacer des données sur 1 mm à travers une puce utilise plus d'énergie que d'effectuer le calcul lui-même !

C'est pourquoi ton ordinateur portable ressemble à un moteur à réaction lorsqu'il entraîne des réseaux de neurones. 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 passe avant chauffe littéralement ta pièce.

Les accélérateurs IA modernes sont essentiellement des exercices de thermodynamique. Combien de calculs pouvons-nous entasser avant que la puce ne fonde ? À quelle vitesse pouvons-nous évacuer la chaleur ? C'est comme l'overclocking, mais l'horloge est toujours au maximum, et nous essayons juste de ne pas déclencher un incendie.

Link to this sectionLa solution ? Une conception consciente de l'architecture#

Les réseaux de neurones les plus rapides ne sont pas nécessairement les plus intelligents, ce sont ceux conçus avec les puces à l'esprit. Ils :

• Gardent les données locales autant que possible
• Réutilisent les calculs de manière obsessionnelle
• S'alignent parfaitement sur les capacités matérielles
• Minimisent les déplacements mémoire à tout prix

C'est comme la différence entre une recette qui dit "utilise des ingrédients de ton épicerie locale" versus une qui nécessite d'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 définitivement plus pratique.

Et c'est pourquoi rendre les réseaux de neurones rapides 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 la mémoire et danser parfaitement avec l'architecture.

Bienvenue dans le 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. Où le parallèle est rapide, mais la synchronisation est mortelle. Où ton plus grand ennemi n'est pas la complexité, c'est la distance.

Link to this sectionComment nous rendons YOLO plus rapide#

Lorsque tu entraînes un modèle YOLO, tu obtiens un réseau de neurones qui fonctionne magnifiquement sur ta configuration d'entraînement. Mais voilà : ton GPU de jeu, ton iPhone et cette petite puce dans une caméra de sécurité parlent tous des langues complètement différentes. Ils ont des forces différentes, des faiblesses différentes et des idées très différentes sur la façon de traiter les données.

Pense à cela de cette façon : un GPU a des milliers de cœurs qui peuvent tous fonctionner simultanément – il est conçu pour le traitement parallèle. Pendant ce temps, une puce mobile pourrait avoir des circuits spéciaux conçus spécifiquement pour les opérations IA, mais ne peut gérer que certains types de mathématiques. Et cet appareil edge dans ta caméra de sonnette ? Il essaie de faire tourner l'IA avec un budget énergétique plus petit qu'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.

Link to this sectionFusion d'opérations : Faire plus avec moins#

Dans le modèle YOLO original, de nombreuses opérations se produisent en séquence. Par exemple, nous pourrions faire 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 ingénieuse : nous pouvons combiner ces opérations en une seule étape. Lorsque nous exportons YOLO pour le déploiement, nous fusionnons ces opérations ensemble. Au lieu de :

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

Nous faisons :

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

Pour un modèle YOLO typique traitant une image 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 un décalage frustrant.

Link to this sectionUtiliser des nombres plus petits : La magie de la quantification#

YOLO n'a pas réellement besoin de nombres super précis 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 des ingrédients pour un sandwich. Pour un déploiement réel ? 8 bits fonctionnent très bien.

Cela s'appelle la quantification, et c'est l'une de nos techniques d'optimisation les plus puissantes. En utilisant des nombres plus petits :

• Le modèle rétrécit de 75 % (passant 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 te remercie)

Toutes les couches de YOLO ne sont pas aussi sensibles à cette réduction. Les premières couches qui détectent les bords et les formes basiques ? Elles sont robustes – nous pouvons utiliser des nombres 8-bit 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 minutieuse, Ultralytics YOLO conserve 99,5 % de sa précision d'origine tout en fonctionnant 3 fois plus vite sur les téléphones. C'est la différence entre un modèle de recherche et quelque chose que tu peux réellement utiliser dans le monde réel.

Link to this sectionChoisir le meilleur algorithme#

Il existe des dizaines de façons différentes d'effectuer la même opération mathématique. Une simple convolution (l'opération principale dans YOLO) peut être calculée en utilisant des algorithmes complètement différents, et le meilleur choix dépend de ton matériel spécifique et de la taille de tes données d'entrée.

Lorsque nous exportons YOLO, notre framework d'optimisation teste réellement différents algorithmes et choisit le plus rapide pour ton cas spécifique. C'est comme avoir plusieurs itinéraires pour atteindre la même destination et choisir en fonction des conditions de circulation actuelles. Sur un GPU, nous pourrions utiliser un algorithme qui traite de nombreux pixels simultanément. Sur un CPU, nous pourrions en utiliser un optimisé pour le traitement séquentiel. Les mathématiques sont les mêmes, mais la stratégie d'exécution est complètement différente.

Link to this sectionMémoire : Le goulot d'étranglement caché#

Tu te souviens quand nous avons parlé du fait que la mémoire est 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, 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 minimiser les déplacements de mémoire :

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

Tuilage : Au lieu de traiter une image entière à la fois, nous la divisons en plus petites tuiles qui tiennent dans le cache. Cela signifie que le processeur peut travailler avec une mémoire locale rapide au lieu de récupérer constamment des données dans la mémoire principale lente.

Réutilisation de tampon : Plutôt que de créer constamment une nouvelle mémoire pour les résultats intermédiaires, nous réutilisons les mêmes tampons mémoire. C'est incroyablement efficace – toute l'épine dorsale de YOLO peut fonctionner avec juste quelques tampons réutilisables.

Link to this sectionÉlagage : Moins, c'est mieux#

Voici un fait surprenant : les modèles YOLO sont souvent sur-conçus. Nous pouvons supprimer 30 % des canaux dans de nombreuses couches sans pratiquement aucun impact sur la précision. Cela ne rend pas seulement le modèle plus petit – cela le rend plus rapide, car il y a littéralement moins de calculs à effectuer.

Le processus est élégant : nous analysons quelles parties du réseau contribuent le moins aux résultats de détection finaux, 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 signifier des heures de temps de fonctionnement supplémentaire.

Link to this sectionAccélération matérielle : Jouer sur les forces de chaque puce#

Les différents processeurs sont bons dans des domaines différents, et les différences de performance sont stupéfiantes. 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 un processeur de téléphone haut de gamme
• 15 millisecondes sur un edge TPU Google Coral

Ce ne sont pas seulement des différences de vitesse dues aux cadences d'horloge – elles reflètent des différences architecturales fondamentales. Les GPU ont des milliers de cœurs qui fonctionnent en parallèle, parfaits pour les convolutions de YOLO. Les NPU mobiles ont des circuits spécialisés conçus spécifiquement pour les réseaux neuronaux. Les CPU sont polyvalents, flexibles mais pas spécialisés.

La clé de l'optimisation est de faire correspondre les opérations de YOLO à ce que chaque puce fait de mieux. Un GPU adore effectuer la même opération sur beaucoup de données simultanément. Un NPU mobile peut ne prendre en charge que certaines opérations, mais il les exécute incroyablement efficacement. Un edge TPU fonctionne uniquement avec des entiers 8-bit mais atteint une vitesse remarquable dans cette contrainte.

Link to this sectionLa magie de la compilation#

Lorsque tu exportes un modèle YOLO, quelque chose de remarquable se produit en coulisses. Nous ne convertissons pas seulement 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 Translate et un locuteur natif. Le processus de compilation :

1. Analyse ton modèle pour comprendre sa structure et ses exigences
2. Prend en compte les capacités de ton matériel – ce dans quoi il est bon, ce avec quoi il a des difficultés
3. Génère du code optimisé qui parle la langue native de ton matériel

Le compilateur pourrait réorganiser les opérations pour mieux utiliser le cache de ton processeur, sélectionner des instructions spécialisées que ta puce prend en charge, ou même 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 faire une différence de 10x en termes de performance. Le même modèle YOLO pourrait avancer péniblement avec du code générique mais voler avec des instructions correctement optimisées.

Link to this sectionDéploiement en périphérie dans le monde réel#

Parlons de ce qui se passe quand YOLO rencontre le monde réel – plus précisément, le monde exigeant des appareils de périphérie (edge). Imagine une caméra de sécurité qui doit exécuter YOLO 24h/24 et 7j/7 pour la détection d'objets. Elle fait face à des contraintes brutales :

• 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 : Pas de ventilateurs, juste une dissipation thermique passive
• Fiabilité : Doit fonctionner en continu sans planter

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

• Modèle d'origine : 15 watts, chauffe à 85°C, atteint 20 FPS
• Optimisé avec quantification et élagage : 3 watts, 45°C confortables, 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 vide les batteries et un appareil qui fonctionne de manière fiable pendant des années.

La clé est de choisir les bons compromis. Sur les appareils de périphérie, nous faisons souvent :

• Utiliser la quantification INT8 (moins de précision, beaucoup moins de puissance)
• 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 assez petits pour tenir entièrement dans la mémoire rapide

Link to this sectionLe 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 sont pas là où tu l'attendrais. Peut-être que 80 % du temps est passé dans seulement quelques couches, 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 plus gros goulots d'étranglement
2. Appliquer une optimisation à la fois
3. Mesurer à la fois l'amélioration de la vitesse et l'impact sur la précision
4. Conserver les optimisations qui offrent de bons compromis
5. Répéter jusqu'à ce que nous atteignions nos objectifs

Par exemple, avec le 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 d'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.

Link to this sectionLe futur : Calcul hétérogène#

Les appareils modernes deviennent plus intelligents dans l'utilisation conjointe de plusieurs processeurs. Ton téléphone n'a pas qu'un seul processeur – il en a plusieurs, chacun spécialisé pour des tâches différentes :

• Le capteur de la caméra a un ISP (Image Signal Processor) pour le prétraitement
• Le NPU (Neural Processing Unit) exécute l'inférence YOLO
• Le CPU gère la logique complexe et la coordination
• Le GPU rend les résultats à l'écran

Le futur de l'optimisation de YOLO consiste à diviser intelligemment le modèle entre ces processeurs. Peut-être que le NPU gère les convolutions principales, le CPU fait la logique de détection finale, et le GPU visualise les résultats. Chaque processeur fait ce qu'il fait de mieux, créant un pipeline plus efficace qu'aucun processeur unique ne pourrait atteindre.

Nous développons des algorithmes de partitionnement intelligents qui déterminent automatiquement la meilleure façon de diviser YOLO entre les processeurs disponibles, en considérant non seulement leurs capacités mais aussi le coût du déplacement des données entre eux.

Link to this sectionLe bilan#

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 comme la quantification (utiliser des nombres plus petits), l'élagage (supprimer les parties inutiles), la fusion d'opérations (combiner des étapes) et une gestion intelligente de la mémoire, nous obtenons des améliorations de performances de 10 à 100 fois tout en maintenant la précision.

La chose remarquable ? Il n'y a pas de « meilleure » optimisation universelle. Un serveur cloud avec une puissance illimitée nécessite des optimisations différentes de celles d'un drone alimenté par batterie. Un téléphone avec une puce IA dédiée nécessite un traitement différent de celui d'un Raspberry Pi. C'est pourquoi Ultralytics fournit autant d'options d'exportation – chacune est optimisée pour différents scénarios.

Chaque optimisation dont nous avons discuté sert un seul objectif : rendre la vision par ordinateur accessible partout. Que tu construises une sonnette intelligente, une application pour drone ou un service cloud massif, nous fournissons les outils pour faire fonctionner YOLO dans tes contraintes.

Lorsque tu exportes un modèle YOLO avec Ultralytics, tu ne sauvegardes pas simplement un fichier. Tu exploites des années de recherche pour 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 des contraintes réelles, en résolvant des problèmes réels.

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 le futur de l'IA ne consiste pas seulement à avoir les meilleurs modèles – il s'agit de rendre ces modèles utiles dans le monde réel.