Dr. Mohand SEDDAR
Article rédigé en avril 2026.
Nos voitures freinent face à un obstacle soudain. Nos montres détectent des anomalies cardiaques en continu. Des caméras industrielles repèrent en temps réel l’absence d’un équipement de protection. Dans chacun de ces cas, une décision d’intelligence artificielle est prise au plus près du capteur, en quelques millisecondes, sans dépendre d’un serveur distant.
Cette évolution n’est pas un simple déplacement du cloud vers l’objet : c’est un changement de paradigme. L’IA ne vit plus seulement dans les centres de données, elle s’insère dans les systèmes physiques, au contact du monde réel. Cette convergence entre systèmes embarqués et intelligence artificielle, souvent regroupée sous les termes d’Embedded AI ou d’Edge AI (IA embarquée, au plus près du capteur), oblige à repenser l’architecture des modèles, leur compression, leur exécution et leur interaction avec le matériel [1].
Pendant des années, l’IA a progressé dans un environnement de confort : calcul massif, mémoire abondante, contraintes énergétiques secondaires. Mais pour devenir omniprésente, elle doit désormais fonctionner là où la RAM se compte parfois en kilo-octets, où la puissance s’exprime en milliwatts, et où chaque milliseconde peut avoir une conséquence critique.
1. Quand le cloud atteint ses limites
Le modèle classique consiste à collecter les données, à les transmettre au cloud, à prendre une décision à distance, puis à renvoyer le résultat. Il reste utile pour l’entraînement et la supervision, mais répond difficilement à trois exigences : décider rapidement, fonctionner sans réseau et protéger les données. Quatre enjeux le résument : la latence, la connectivité, la confidentialité et le coût.
- Latence : un aller-retour réseau prend 50 à 200 ms hors congestion [2], sur un NPU (Neural Processing Unit), l’inférence locale descend sous 5 ms pour une classification, contre 30 ms incompressibles en cloud [3]. Pour un freinage d’urgence ou un robot collaboratif, l’écart est critique.
- Connectivité : un drone en zone blanche, un capteur isolé ou un dispositif médical portable ne peut pas supposer un réseau disponible. L’autonomie locale est une exigence fonctionnelle, pas un confort.
- Confidentialité : envoyer des flux vidéo, des signaux biométriques ou des données industrielles vers un serveur externe augmente mécaniquement les risques de fuite [4]. Traiter à la source permet une privacy by design de plus en plus imposée par la réglementation. Le federated learning pousse la logique plus loin avec un apprentissage collaboratif sans jamais centraliser les données brutes [5].
- Coût : transmettre en continu des flux HD ou vibratoires est coûteux en bande passante et en énergie. N’envoyer que des alertes ou des métadonnées réduit ce volume d’un facteur 10 à 100 [6] (un argument de poids à l’heure où l’empreinte carbone du numérique est scrutée).
L’enjeu n’est pas d’opposer cloud et embarqué, mais de construire une architecture distribuée cohérente : le cloud pour entraîner et orchestrer, l’edge pour inférer localement, l’embarqué pour les décisions critiques en temps réel (Figure 1).
2. Ce que signifie vraiment « embarqué »
Un système embarqué exécute une ou plusieurs fonctions précises dans un environnement contraint qui n’offre pas la polyvalence d’un PC, mais vise l’efficacité ciblée sur une tâche. Les formes sont variées : ECU (Electronic Control Unit) d’un véhicule, microcontrôleur d’une montre médicale, calculateur d’une caméra industrielle, pile de fonctions d’un drone, mais le point commun reste le même : fonctionner longtemps, souvent sans supervision, dans des limites strictes de mémoire, d’énergie et de calcul. En pratique, le choix se joue entre trois grandes familles de plateformes, chacune taillée pour un niveau d’exigence différent :
- Microcontrôleurs (MCU) : une unique puce intègre, CPU, Flash, SRAM et périphériques. Les familles ARM Cortex-M dominent, du M0+ aux récents M55/M85 (extensions SIMD et instructions DSP pour l’inférence TinyML directe). Acteurs clés : STM32, Nordic nRF, Texas Instruments.
- SoC et microprocesseurs applicatifs : plus puissants, ils font tourner un Linux embarqué et concentrent CPU multicœurs, GPU, DSP, NPU et ISP sur une seule puce (NVIDIA Jetson, NXP i.MX, Qualcomm Snapdragon). Ce sont eux qui portent les applications edge ambitieuses : vision avancée, multimodal, petits LLM, pipelines complexes.
- FPGA (Field-Programmable Gate Array) : à la différence d’un processeur qui exécute un programme, un FPGA est un circuit dont on câble la logique pour épouser exactement le calcul à effectuer. On obtient un chemin d’exécution sur mesure, une latence très prévisible et une bonne efficacité énergétique, au prix d’une conception nettement plus complexe [7]. D’où leur présence en aéronautique, défense et inspection industrielle critique, où la prévisibilité prime.
Au-delà du type de plateforme, le cœur de calcul repose sur un jeu d’instructions (le langage machine que comprend le processeur). ARM reste le standard dominant, avec des dizaines de milliards de cœurs déployés chaque année. RISC-V, un jeu d’instructions ouvert et libre de droits (par opposition aux architectures propriétaires sous licence), monte en puissance grâce à son extensibilité et à l’indépendance stratégique qu’il offre aux industriels soucieux d’éviter les licences propriétaires.
Figure 1 : Exemples d’architectures en embarqué.
3. Le mur des ressources
Les modèles modernes ont été conçus pour des environnements où la mémoire et la puissance sont abondantes (Figure 2), alors que l’embarqué impose les contraintes inverses [1]. Un serveur dispose de plusieurs gigaoctets, voire de plusieurs téraoctets de mémoire. Un microcontrôleur travaille avec quelques centaines de Ko de RAM et quelques Mo de mémoire Flash. Un modèle de deep learning standard dépasse souvent ces budgets d’un ou deux ordres de grandeur.
De plus, chaque multiplication matricielle a un coût physique. Sur batterie, l’optimisation algorithmique n’est plus une question de vitesse mais d’autonomie : chaque opération évitée est un gain réel.
Enfin, dans un système critique, être rapide en moyenne ne suffit pas : il faut garantir un temps d’exécution prévisible dans le pire des cas. La métrique de référence ne se limite donc plus à la précision ; elle repose sur un compromis entre précision, latence, mémoire et énergie. Ces contraintes paraissent rédhibitoires, mais elles ne le sont pas : les réseaux profonds offrent une marge de compression considérable, que les prochaines sections vont exploiter.
Figure 2 : Le goulot d’étranglement – le fossé Cloud / Edge.
Le Tableau 1 donne corps à ces contraintes. Il compare des architectures représentatives (des réseaux de vision classiques) en taille, complexité et latence sur différentes cibles matérielles. On y voit que les modèles conçus pour le TinyML privilégient une empreinte mémoire minimale et une très faible latence sur microcontrôleur.
| Modèle | Param. | FP32 | INT8 | FLOPs | Lat. Cortex-M4 @168 MHz | Lat. NPU |
| MobileNetV1 [8] | ~4,2 M | ~16 Mo | ~4,2 Mo | ~569 M | ~1 200 ms | ~80 ms |
| MobileNetV2 [9] | ~3,4 M | ~13 Mo | ~3,4 Mo | ~300 M | ~900 ms | ~60 ms |
| MobileNetV3-Small [10] | ~2,5 M | ~9,5 Mo | ~2,5 Mo | ~56 M | ~180 ms | ~15 ms |
| EfficientNet-Lite0 [11] | ~4,7 M | ~18 Mo | ~4,7 Mo | ~407 M | ~1 100 ms | ~75 ms |
| SqueezeNet 1.0 [12] | ~1,2 M | ~4,8 Mo | ~1,2 Mo | ~352 M | ~950 ms | ~55 ms |
| ResNet-18 [13] | ~11,7 M | ~44 Mo | ~11 Mo | ~1,8 G | trop lourd | ~350 ms |
| ResNet-50 [13] | ~25,6 M | ~98 Mo | ~25 Mo | ~4,1 G | / | ~800 ms |
| MCUNet (INT4) [14] | ~0,7 M | ~1,4 Mo | ~350 Ko | ~67 M | ~120 ms | / |
| TinyML CMSIS-NN [15] | ~50–200 K | ~0,2–0,8 Mo | < 256 Ko | ~5–20 M | < 50 ms | / |
Tableau 1 : modèles de vision sur MCU et NPU. Latences estimées pour une image 224×224 RGB, classification top-1 (TFLite Micro ou CMSIS-NN). FLOPs en MFLOPs/GFLOPs. Les valeurs varient selon l’implémentation et le compilateur.
4. Comment compresser les réseaux ?
La surparamétrisation est la mécanique centrale permettant la compression des réseaux d’apprentissage. Les réseaux profonds contiennent bien plus de paramètres que leur tâche n’en exige. Cette redondance n’est pas un défaut : elle facilite l’optimisation et rend la convergence plus robuste. Mais une fois l’entraînement terminé, une part importante des poids devient peu informative, voire inutile.
La Lottery Ticket Hypothesis (Frankle & Carbin, 2019 [27]) a formalisé cette intuition : au sein d’un grand réseau dense existent des sous-réseaux gagnants qui, réentraînés seuls avec leurs poids d’initialisation d’origine, atteignent des performances comparables au réseau complet. La performance ne dépend donc pas de la taille brute, mais de la qualité de la structure effective. Ces résultats ont été étendus aux Transformers [28], ouvrant la voie à la compression des LLM par élagage structuré (Figure 3).
En pratique, un réseau peut souvent perdre 50 à 80 % de ses paramètres sans dégradation notable, à condition de procéder méthodiquement.
Figure 3 : Exemples de compression de réseaux de neurones par élagage (pruning) et/ou quantification.
5. Les leviers de l’optimisation
Pour rendre les modèles exploitables sur des systèmes contraints, quatre familles de techniques réduisent la mémoire, le calcul et la consommation énergétique.
- Quantification : on réduit la précision numérique des poids et activations [29] (Float32 → Int8, Int4, voire binaire) : compression 4 à 8 fois, calcul entier 2 à 4 fois plus rapide et 4 à 16 fois moins énergivore sur MCU/NPU. La PTQ (post-training) est simple et rapide, la QAT (quantization-aware training) intègre la quantification dès l’entraînement pour mieux préserver la précision. Pour les LLM, GPTQ [30] permet une quantification INT4 agressive à dégradation minimale, rendant accessibles sur MPU des modèles jusqu’ici réservés au GPU serveur.
- Pruning (élagage) : on supprime les connexions ou structures redondantes selon des critères de magnitude, gradient ou information mutuelle [31]. L’élagage non structuré retire des poids individuels (fort taux de compression) mais produit des matrices creuses, difficiles à accélérer sur hardware classique. L’élagage structuré supprime des filtres, canaux ou têtes d’attention entiers et reste directement exploitable par tout compilateur embarqué. Empiriquement, ResNet-50 perd 50–70 % de ses connexions avec moins de 1 % de dégradation sur ImageNet après réentraînement [32].
- Distillation de connaissances : un grand modèle (professeur) transmet ses comportements à un modèle compact (élève) via la distribution de probabilité complète de ses sorties, bien plus informative que les seuls labels [33]. Les modèles distillés atteignent 95–98 % des performances du professeur avec 3 à 10 fois moins de paramètres [34].
- Conception légère by design : plutôt que compresser après coup, on conçoit un modèle efficient dès l’origine. Les architectures mobile-first (MobileNet [8], EfficientNet [11], SqueezeNet [12]) utilisent la depthwise separable convolution pour réduire le coût computationnel d’un ordre de grandeur. Le Neural Architecture Search (NAS) va plus loin en automatisant la recherche d’architecture sous contrainte de ressources. Des frameworks comme Once-for-All [35] et MCUNet [14] co-optimisent modèle et matériel pour maximiser la précision sous contrainte de latence et de mémoire sur une cible donnée.
6. Le runtime compte autant que le modèle
Un modèle optimisé ne suffit pas : sur cible embarquée, la chaîne d’exécution est décisive. Compilateur, runtime et kernels font une différence majeure sur la latence, la mémoire résidente et la consommation. TensorFlow Lite Micro [36] et CMSIS-NN [15] ciblent les MCU (fusion d’opérateurs, réordonnancement du graphe, kernels SIMD/DSP, allocation mémoire statique sans fragmentation). Apache TVM et ONNX Runtime poussent la portabilité et l’autotuning multi-cibles ; Edge Impulse et STM32Cube.AI offrent des pipelines complets, de l’acquisition au déploiement, avec profiling sur cible réelle.
Dans certains cas, un meilleur compilateur apporte plus qu’une compression supplémentaire. Un bon déploiement embarqué n’est pas qu’une affaire de réseau : c’est aussi une affaire de compilation, d’alignement mémoire et de pipeline d’inférence.
7. Quel matériel pour quel usage
Les familles de plateformes présentées plus haut (section 2) ne se choisissent pas dans l’absolu : chacune répond à un niveau de contrainte donné. Les CPU généralistes peuvent exécuter des inférences neuronales, mais leur architecture est moins efficace que celle d’unités dédiées pour paralléliser les milliers d’opérations MAC (Multiply-Accumulate : multiplier deux valeurs et cumuler le résultat) requises par certains modèles [7]. Le recours à des NPU, GPU, DSP ou FPGA permet alors d’améliorer le débit, la latence ou l’efficacité énergétique.
Le critère de choix est le couple contrainte/charge :
- Un microcontrôleur consommant quelques milliwatts suffit pour la détection d’événements ou le keyword spotting avec un modèle fortement quantifié [15].
- Un NPU apporte un parallélisme massif dédié aux convolutions, pour la vision temps réel sur système compact.
- Un MPU/SoC sous Linux fait tourner des modèles complexes (vision avancée, LLM compacts).
- Un FPGA offre un chemin de données sur mesure quand la latence doit être déterministe.
En résumé : « le meilleur modèle n’existe pas indépendamment de son matériel ». En IA embarquée, le modèle et la plateforme doivent être co-optimisés dès le départ : un excellent modèle mal aligné avec son matériel produira de mauvaises performances, et inversement.
8. Les cas d’usage qui comptent
On retrouve ici, en pleine lumière, les exemples évoqués en ouverture. Malgré la diversité des secteurs, les mêmes problématiques reviennent : perception locale, décision sous contrainte de latence, robustesse aux défaillances réseau, efficience énergétique. L’IA embarquée est devenue une technologie transversale.
- Automobile : les systèmes ADAS (détection d’obstacles, maintien de voie, reconnaissance de panneaux, surveillance du conducteur) s’exécutent localement, avec une latence de quelques dizaines de ms incompatible avec le cloud. La fusion multi-capteurs est centrale : caméras (sémantique), LiDAR (géométrie 3D), radar (météo/nuit), IMU (dynamique).
- Industrie 4.0 : la maintenance prédictive analyse vibrations, température, courant et signaux acoustiques directement sur MCU pour anticiper les défaillances. L’inspection visuelle embarque des modèles de détection de défauts qui décident acceptation/rejet en quelques dizaines de ms sur la ligne.
- Santé connectée : montres, patchs et moniteurs implantables analysent en continu ECG, PPG et accéléromètre pour détecter arythmies, apnées ou chutes. Le traitement local est ici un avantage structurel : les données sensibles restent sur l’appareil.
- Robotique et drones : perception, stabilisation, évitement d’obstacles et ajustement de mission en temps réel, sous fortes contraintes de batterie, de poids et de latence. Le SLAM (Simultaneous Localization and Mapping) reste l’un des défis computationnels les plus intenses du domaine.
9. La caméra devient un capteur de compréhension
Grâce aux dernières avancées technologiques, la vision embarquée a changé de nature : une caméra n’est plus un simple capteur d’images ; elle tend à devenir un capteur de compréhension du monde physique. Un seul flux vidéo peut désormais assurer simultanément la détection d’objets, la segmentation sémantique, l’estimation de profondeur, le suivi multi-objets et l’interprétation d’événements, autant de fonctions qui nécessitaient autrefois des capteurs dédiés.
Pour autant, la caméra ne remplace pas les autres capteurs. Dans les systèmes critiques, la fusion multi-capteurs reste la référence : radar pour la robustesse par faible visibilité, LiDAR pour la géométrie 3D, IMU pour la dynamique, caméra pour la richesse sémantique (Figure 4). La valeur vient de la complémentarité : une intelligence embarquée robuste orchestre une perception multimodale cohérente plutôt que d’optimiser un capteur unique.
Figure 4 : La caméra comme capteur de compréhension – vision et fusion multi-capteurs.
10. L’essor des petits modèles de langage
Percevoir le monde est une chose ; le mettre en mots et raisonner à son sujet en est une autre. Cette seconde capacité, longtemps l’apanage des grands modèles exécutés dans le cloud, commence également à être déployée dans l’embarqué. Après les LLM géants, une tendance complémentaire s’affirme : celle des Small Language Models (SLM). L’objectif n’est pas de reproduire les grands modèles, mais de concevoir des modèles compacts, ciblés et réellement déployables localement, en misant sur la qualité des données plutôt que sur la seule mise à l’échelle. Phi-3-mini (Microsoft, 2024) [16] et SmolLM (HuggingFace, 2024) [19] montrent que des capacités linguistiques utiles sont atteignables avec des modèles de 125 M à 3,8 B de paramètres. MobileLLM (Meta, 2024) [20] optimise l’architecture pour les contraintes de mémoire des appareils mobiles, grâce notamment au partage des embeddings et au regroupement de couches, sans sacrifier l’expressivité (Tableau 2).
Ces modèles ouvrent des cas d’usage entièrement hors ligne : assistant vocal en habitacle, interface conversationnelle en usine, aide à la décision sur tablette clinique, diagnostic embarqué à confidentialité renforcée. Une limite demeure : même « petits », ils restent hors de portée des MCU classiques et ciblent des MPU dotés de plusieurs centaines de Mo à quelques Go de RAM (Cortex-A, Jetson, i.MX). Faire descendre ces modèles vers le microcontrôleur est l’un des axes de recherche les plus actifs du domaine.
| Modèle | Param. | FP16 | INT4 / GGUF | RAM min. | Faisabilité |
| Phi-3-mini [16] | 3,8 B | ~7,6 Go | ~2,0 Go | ~3 Go | MPU Linux |
| Gemma 2B [17] | 2,0 B | ~4,0 Go | ~1,1 Go | ~2 Go | MPU Linux |
| TinyLlama 1.1B [18] | 1,1 B | ~2,2 Go | ~600 Mo | ~1 Go | MPU haut de gamme |
| SmolLM-360M [19] | 360 M | ~720 Mo | ~190 Mo | ~512 Mo | Cortex-A |
| SmolLM-135M [19] | 135 M | ~270 Mo | ~70 Mo | ~300 Mo | Cortex-A |
| MobileLLM-350M [20] | 350 M | ~700 Mo | ~180 Mo | ~512 Mo | Cortex-A |
| MobileLLM-125M [20] | 125 M | ~250 Mo | ~65 Mo | ~256 Mo | Cortex-A |
| LLM.int8() ~100M [21] | 50–125 M | ~100–250 Mo | ~25–65 Mo | ~64–128 Mo | MCU haut de gamme |
Tableau 2 : Small Language Models (SLM) – faisabilité embarquée. Tailles GGUF INT4 au format llama.cpp.
11. Vers des modèles multimodaux embarqués
La convergence entre encodeurs visuels compacts (SigLIP, CLIP) et petits modèles de langage produit une nouvelle génération de Vision-Language Models (VLM) embarquables. SmolVLM [25] et MoondreamV2 [24] montrent qu’il est possible de raisonner sur des images avec des modèles bien plus légers que les grandes architectures multimodales, grâce à des encodeurs hyper-compacts et à des stratégies de compression des tokens visuels (pixel shuffle, token merging) qui réduisent la charge d’un ordre de grandeur.
Concrètement, les configurations vont des modèles destinés aux serveurs, comme LLaVA-Phi-3-mini [22] (~3,8 B de paramètres, avec GPU), aux modèles exécutables sur un MPU sous Linux, comme PaliGemma-3B [23] (~1,5 Go en INT4), ou sur des plateformes haut de gamme, comme MoondreamV2 [24] (~1,86 B de paramètres). À l’extrémité la plus compacte, SmolVLM-256M et SmolVLM-500M [25], parmi les modèles multimodaux les plus légers déployés en production sur Cortex-A au début de 2026, atteignent environ 100 à 200 Mo en INT4 pour une consommation de RAM d’environ 300 à 512 Mo. Des prototypes comme NanoVLM [26] (~80 à 150 M de paramètres) visent déjà les microcontrôleurs haut de gamme. Les chiffres évoluent rapidement, mais la trajectoire est claire.
Le saut conceptuel est considérable. Un modèle classique (type YOLO) localise et classifie : « il y a un piéton ici ». Un VLM embarqué raisonne sur la signification contextuelle : « un enfant s’apprête à traverser devant une école en regardant son téléphone ». On passe d’une perception bas niveau à une compréhension situationnelle, sans doute l’évolution la plus structurante pour l’automobile autonome, la robotique collaborative et les environnements industriels intelligents.
12. Perspectives : les frontières actives de la recherche
Au-delà des techniques aujourd’hui maîtrisées, plusieurs directions encore en maturation dessinent l’IA embarquée de demain. Deux se détachent particulièrement dans les travaux récents.
Adapter le modèle à son terrain : L’adaptation on-device permet de faire évoluer un modèle directement sur l’appareil, sans rapatrier les données. La Low-Rank Adaptation (LoRA) [37] rend cette adaptation extrêmement légère (quelques paramètres entraînables supplémentaires), sans recalculer l’ensemble des poids. Utile lorsque l’environnement évolue (bruit acoustique, contexte industriel, capteurs, population d’utilisateurs), elle ouvre, combinée au continual learning sous contraintes mémoire, la voie à des systèmes qui s’améliorent au fil du déploiement. L’enjeu n’est plus seulement d’inférer correctement : c’est de progresser sans dériver.
Les pistes neuromorphiques : Les Spiking Neural Networks (SNN) et les architectures neuromorphiques explorent une autre manière de calculer, inspirée du cerveau : au lieu de traiter des vecteurs denses à chaque étape, un SNN ne déclenche un calcul que lorsqu’un signal dépasse un seuil local, supprimant ainsi des milliards d’opérations inutiles. Cette logique événementielle promet une très faible consommation pour les capteurs intelligents ; Intel Loihi et IBM TrueNorth en ont fourni des preuves de concept convaincantes. Les outils restent en maturation, mais l’idée est forte : repenser l’intelligence à partir du signal lui-même.
Conclusion
L’IA embarquée n’est pas une version dégradée de l’IA cloud : c’est une discipline à part entière, à l’intersection de l’optimisation algorithmique, de l’architecture embarquée et de l’efficacité matérielle. Ses contraintes (chaque octet, chaque cycle, chaque milliwatt) ne sont pas des obstacles mais des forces de conception : elles poussent à bâtir des systèmes plus sobres, plus robustes, plus déterministes. Comprimer un réseau sans en perdre l’intelligence, c’est comprendre ce que l’intelligence est vraiment.
C’est pourquoi ignorer ces contraintes n’est pas neutre. De nombreux travaux proposent des solutions dont la mise en œuvre finale sera exclusivement embarquée, pourtant, certains ne tiennent aucun compte des limites réelles du terrain, ce qui affecte la crédibilité de leurs résultats. Pire : des solutions prometteuses sur le papier perdent toute valeur dès qu’elles affrontent les conditions réelles d’un déploiement physique. Le futur de l’IA sera hybride, distribué et adaptatif, et dans cette architecture globale, l’IA embarquée jouera un rôle central : rapprocher l’intelligence des capteurs, des actionneurs et du monde réel.
Références
[1] Warden, P., & Situnayake, D. (2019). TinyML: Machine Learning with TensorFlow Lite on Arduino and Ultra-Low-Power Microcontrollers. O’Reilly Media.
[2] Shi, W., Cao, J., Zhang, Q., Li, Y., & Xu, L. (2016). Edge computing: Vision and challenges. IEEE Internet of Things Journal, 3(5), 637–646.
[3] Deng, S., Zhao, H., Fang, W., Yin, J., Dustdar, S., & Zomaya, A. Y. (2020). Edge intelligence: The confluence of edge computing and artificial intelligence. IEEE Internet of Things Journal, 7(8), 7457–7469.
[4] Regulation (EU) 2016/679 (GDPR). On the protection of natural persons with regard to the processing of personal data. European Parliament, 2016.
[5] McMahan, B., Moore, E., Ramage, D., Hampson, S., & y Arcas, B. A. (2017). Communication-efficient learning of deep networks from decentralized data. Proceedings of the 20th AISTATS, PMLR 54.
[6] Li, E., Zeng, L., Zhou, Z., & Chen, X. (2019). Edge AI: On-demand accelerating deep neural network inference via edge computing. IEEE Transactions on Wireless Communications, 19(1), 447–457.
[7] Reuther, A., Michaleas, P., Jones, M., Gadepally, V., Samsi, S., & Kepner, J. (2022). AI and ML accelerator survey and trends. IEEE HPEC 2022.
[8] Howard, A. G., Zhu, M., Chen, B., Kalenichenko, D., Wang, W., Weyand, T., … & Adam, H. (2017). MobileNets: Efficient convolutional neural networks for mobile vision applications. arXiv:1704.04861.
[9] Sandler, M., Howard, A., Zhu, M., Zhmoginov, A., & Chen, L. C. (2018). MobileNetV2: Inverted residuals and linear bottlenecks. CVPR 2018.
[10] Howard, A., Sandler, M., Chu, G., Chen, L. C., Chen, B., Tan, M., … & Adam, H. (2019). Searching for MobileNetV3. ICCV 2019.
[11] Tan, M., & Le, Q. (2019). EfficientNet: Rethinking model scaling for convolutional neural networks. ICML 2019.
[12] Iandola, F. N., Han, S., Moskewicz, M. W., Ashraf, K., Dally, W. J., & Keutzer, K. (2016). SqueezeNet: AlexNet-level accuracy with 50x fewer parameters and < 0.5 MB model size. arXiv:1602.07360.
[13] He, K., Zhang, X., Ren, S., & Sun, J. (2016). Deep residual learning for image recognition. CVPR 2016.
[14] Lin, J., Chen, W. M., Lin, Y., Cohn, J., Gan, C., & Han, S. (2020). MCUNet: Tiny deep learning on IoT devices. NeurIPS 2020.
[15] Lai, L., Suda, N., & Chandra, V. (2018). CMSIS-NN: Efficient neural network kernels for Arm Cortex-M CPUs. arXiv:1801.06601.
[16] Abdin, M., Aneja, J., Awadalla, H., et al. (2024). Phi-3 technical report: A highly capable language model locally on your phone. arXiv:2404.14219.
[17] Team, G., Mesnard, T., Hardin, C., et al. (2024). Gemma: Open models based on Gemini research and technology. arXiv:2403.08295.
[18] Zhang, P., Zeng, G., Wang, T., & Lu, W. (2024). TinyLlama: An open-source small language model. arXiv:2401.02385.
[19] Allal, L. B., Lozhkov, A., Penedo, G., Wolf, T., & Launay, J. (2024). SmolLM – Blazingly fast and remarkably powerful. HuggingFace Blog, August 2024.
[20] Liu, Z., Zhao, C., Iandola, F., Lai, C., Tian, Y., Bajaj, P., … & Wang, Z. (2024). MobileLLM: Optimizing sub-billion parameter language models for on-device use cases. ICML 2024.
[21] Dettmers, T., Lewis, M., Shleifer, S., & Zettlemoyer, L. (2022). LLM.int8(): 8-bit matrix multiplication for transformers at scale. NeurIPS 2022.
[22] Liu, H., Li, C., Wu, Q., & Lee, Y. J. (2023). Visual instruction tuning (LLaVA). NeurIPS 2023.
[23] Beyer, L., Steiner, A., Pinto, A. S., Kolesnikov, A., Wang, X., Salz, D., … & Zhai, X. (2024). PaliGemma: A versatile 3B VLM for transfer. arXiv:2407.07726.
[24] Vik, B. (2024). Moondream: A tiny vision language model. GitHub / HuggingFace, 2024.
[25] Marafioti, A., Allal, L. B., & Penedo, G. (2024). SmolVLM: Redefining small and efficient multimodal models. HuggingFace Blog, November 2024.
[26] Various authors (2024). NanoVLM: Experiments in ultra-compact vision-language models. Community research, GitHub.
[27] Frankle, J., & Carbin, M. (2019). The lottery ticket hypothesis: Finding sparse, trainable neural networks. ICLR 2019.
[28] Chen, T., Frankle, J., Chang, S., Liu, S., Zhang, Y., Wang, Z., & Carbin, M. (2020). The lottery ticket hypothesis for pre-trained BERT networks. NeurIPS 2020.
[29] Hubara, I., Courbariaux, M., Soudry, D., El-Yaniv, R., & Bengio, Y. (2017). Quantized neural networks: Training neural networks with low precision weights and activations. JMLR, 18(1), 6869–6898.
[30] Frantar, E., Ashkboos, S., Hoefler, T., & Alistarh, D. (2022). GPTQ: Accurate post-training quantization for generative pre-trained transformers. ICLR 2023.
[31] Han, S., Pool, J., Tran, J., & Dally, W. J. (2015). Learning both weights and connections for efficient neural networks. NeurIPS 2015.
[32] Frankle, J., Schwab, D. J., & Morcos, A. S. (2020). The early phase of neural network training. ICLR 2020.
[33] Hinton, G., Vinyals, O., & Dean, J. (2015). Distilling the knowledge in a neural network. NIPS Deep Learning Workshop 2014, arXiv:1503.02531.
[34] Gou, J., Yu, B., Maybank, S. J., & Tao, D. (2021). Knowledge distillation: A survey. International Journal of Computer Vision, 129(6), 1789–1819.
[35] Cai, H., Gan, C., Wang, T., Zhang, Z., & Han, S. (2020). Once-for-All: Train one network and specialize it for efficient deployment. ICLR 2020.
[36] David, R., Duke, J., Jain, A., Janapa Reddi, V., Jeffries, N., Li, J., … & Warden, P. (2021). TensorFlow Lite Micro: Embedded machine learning for TinyML systems. MLSys 2021, PMLR 143.
[37] Hu, E. J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., … & Chen, W. (2022). LoRA: Low-rank adaptation of large language models. ICLR 2022.