Edge Computing

L’informatique en périphérie consiste à exécuter des calculs et à stocker des données à proximité de l’endroit où elles sont produites ou utilisées, sur des appareils, des serveurs et des passerelles sur site, ou dans de petits centres de données en bordure des réseaux télécoms, plutôt que de tout envoyer vers une région cloud éloignée. Le traitement à proximité de la source réduit le temps de réponse, diminue la bande passante nécessaire au transfert des données brutes, conserve les données sensibles sur place et permet aux systèmes de continuer à fonctionner en cas de coupure réseau. Cette idée vient des réseaux de diffusion de contenu, qui mettaient en cache des pages Web près des utilisateurs à la fin des années 1990. En 2009, des chercheurs dirigés par Mahadev Satyanarayanan ont proposé des « cloudlets » à proximité pour les appareils mobiles ; Cisco a introduit le terme fog computing en 2012 ; et l’organisme européen de normalisation ETSI a commencé à normaliser le Multi-access Edge Computing pour les réseaux mobiles en 2014. L’exécution de modèles d’apprentissage automatique sur cette infrastructure s’appelle l’IA en périphérie.

Niveaux de périphérie#

Le terme « périphérie » englobe plusieurs couches entre un capteur et le cloud :

• Périphérie de l’appareil : Caméras, téléphones, drones, robots et véhicules qui traitent les données sur leurs propres processeurs, souvent dotés d’accélérateurs intégrés.
• Périphérie sur site : Passerelles et serveurs compacts installés dans une usine, un magasin, un hôpital ou une ferme, qui agrègent les données de nombreux appareils, par exemple un seul boîtier GPU qui analyse les flux de dizaines de caméras.
• Périphérie réseau : Serveurs installés dans des stations de base télécoms ou des points de présence régionaux, à quelques millisecondes des utilisateurs mobiles, qui exécutent les charges de travail des appareils trop limités pour les traiter localement.
• Cloud : Régions centrales qui entraînent les modèles, stockent les données à long terme et gèrent le parc d’appareils en périphérie.

Pourquoi traiter les données en périphérie#

La latence est la première raison. La lumière se propage dans la fibre optique à environ 200 kilomètres par milliseconde ; un centre de données situé à 1 000 km ajoute donc au moins 10 ms d’aller-retour, avant même le routage, la mise en file d’attente ou le traitement. Les véhicules autonomes et les robots, qui doivent réagir en quelques millisecondes, exécutent donc l’inférence en temps réel à bord. La bande passante est le deuxième facteur : un seul flux vidéo H.264 en 1080p nécessite quelques mégabits par seconde. Un site équipé de 100 caméras enverrait donc continuellement des centaines de mégabits, alors qu’un événement de détection transmis en JSON ne prend que quelques kilo-octets. Le traitement sur site conserve aussi les images brutes de personnes en local : seuls les décomptes, les alertes ou les résultats anonymisés quittent le bâtiment, ce qui simplifie le respect des obligations de protection des données. Enfin, les systèmes continuent de fonctionner en cas de panne réseau dans les fermes, les navires, les mines et les infrastructures éloignées.

En pratique, la périphérie et le cloud fonctionnent en boucle. Les appareils traitent chaque image localement et n’envoient que les événements et certains échantillons vers le cloud, qui utilise ces échantillons pour réentraîner les modèles et y déployer leurs versions améliorées :

Cette approche permet le contrôle qualité sur les lignes de production, où une pièce défectueuse doit être rejetée avant l’arrivée de la suivante, la surveillance des cultures et du bétail dans des champs mal desservis par le réseau, et la gestion du trafic grâce à des systèmes qui adaptent les feux à partir des caméras aux intersections.

Informatique en périphérie et notions connexes#

L’informatique en nuage centralise une capacité élastique dans de grands centres de données, et l’informatique en périphérie étend les traitements à partir de cette infrastructure ; la plupart des systèmes combinent donc les deux. L’IA en périphérie est la partie de l’informatique en périphérie qui exécute des modèles d’IA. Le fog computing, terme de Cisco, désigne la couche de passerelles et de serveurs locaux située entre les appareils et le cloud ; il est largement synonyme des niveaux sur site et réseau. L’Internet des objets (IoT) est le réseau de capteurs et d’appareils connectés, et l’informatique en périphérie traite une grande partie des données qu’ils produisent.

Déploiement de modèles sur des appareils en périphérie#

Le matériel périphérique dispose d’une fraction de la mémoire, de la puissance de calcul et du budget énergétique d’un GPU de centre de données, des microcontrôleurs consommant quelques milliwatts aux modules NVIDIA Jetson et aux cartes Raspberry Pi. Les modèles sont réduits et accélérés par la quantification de modèles en entiers de 8 bits, l’élagage et la distillation des connaissances, puis compilés pour l’environnement d’exécution et l’accélérateur cibles, comme TensorRT sur les GPU NVIDIA, OpenVINO sur les CPU et les NPU Intel, LiteRT sur Android ou Core ML sur les appareils Apple. Le mode d’exportation d’Ultralytics YOLO génère ces formats à partir d’un seul modèle entraîné. Cet exemple exporte YOLO26 vers NCNN, le framework d’inférence de Tencent pour les appareils mobiles et les CPU ARM, puis exécute le modèle exporté :

from ultralytics import YOLO

# Export YOLO26n to NCNN, a lightweight runtime for ARM CPUs and mobile devices
model = YOLO("yolo26n.pt")
ncnn_path = model.export(format="ncnn")  # writes the yolo26n_ncnn_model folder

# Load the exported model and run it on this machine's CPU
ncnn_model = YOLO(ncnn_path)
results = ncnn_model("https://ultralytics.com/images/bus.jpg")
print(f"Inference: {results[0].speed['inference']:.1f} ms")

L’exportation crée un dossier yolo26n_ncnn_model contenant model.ncnn.param pour la structure du réseau, model.ncnn.bin pour les poids et metadata.yaml pour les noms de classes et la taille d’entrée. Le temps affiché est la latence d’inférence par image sur la machine qui exécute le modèle ; c’est la valeur qui détermine si le modèle respecte le budget d’images par seconde d’une application en périphérie.