Ce que « edge AI » veut dire vraiment
« Edge AI » ne veut pas dire « le cloud, en plus petit ». L’expression désigne l’inférence exécutée là où la donnée naît : une caméra, un robot, un véhicule, sous trois contraintes que le datacenter ignore : une enveloppe énergétique de quelques dizaines de watts, un refroidissement passif ou modeste, et l’absence fréquente de connexion fiable. Ces contraintes ne sont pas accessoires : elles excluent d’emblée toute architecture qui suppose un accès permanent à plusieurs centaines de watts ou à un lien réseau stable.
Le Jetson Orin de NVIDIA est l’un des rares modules à offrir un vrai GPU programmable dans cette enveloppe : un GPU Ampere complet, avec CUDA, TensorRT, et l’écosystème logiciel qui va avec. C’est ce qui le rend intéressant face à un NPU Neural Processing Unit. Circuit dédié à l'inférence des réseaux de neurones : tableau de multiplieurs-accumulateurs câblés en dur pour quelques opérateurs (convolution, matmul, activations). Très efficace en énergie sur ce qu'il sait faire, incapable du reste. Approfondir dans le glossaire rigide ou à un Raspberry Pi sans accélération sérieuse. C’est aussi ce qui fixe ses limites, parce que ce GPU vit dans la même enveloppe thermique et mémoire que tout le reste du système.
Jetson Orin : l’architecture en bref
| Profil | Mémoire unifiée | Enveloppe | Cible |
|---|---|---|---|
| Orin Nano | 4–8 Go | 7–25 W | Vision légère, capteurs |
| Orin NX | 8–16 Go | 10–40 W | Vision multi-flux, petit LLM |
| AGX Orin | 32–64 Go | 15–60 W | LLM quantifié, robotique |
Le point structurant n’est pas le nombre de TOPS Tera Operations Per Second. Mille milliards d'opérations par seconde : métrique brute de débit d'un accélérateur, généralement annoncée en INT8 ou INT4. Elle ne dit rien du débit réel d'un modèle, qui dépend du compilateur et du repli éventuel sur CPU. Approfondir dans le glossaire , c’est la mémoire unifiée : CPU et GPU partagent la même RAM physique. Sur un serveur classique, copier un tenseur du CPU vers le GPU traverse PCIe, une opération qu’on cherche à minimiser parce qu’elle bouffe quelques microsecondes et de la bande passante. Sur Orin, cette frontière n’existe pas : le GPU adresse directement la RAM système via une mémoire épinglée ou managée, sans copie. Bénéfice immédiat sur la latence d’un pipeline vision qui passe des frames à un modèle.
Le revers est qu’il n’y a qu’une seule réserve physique pour tout. Le modèle, son KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire quand c’est un LLM, les buffers d’image, le pipeline d’encodage vidéo, le système d’exploitation : tout se sert dans la même enveloppe. Sur un AGX Orin 64 Go on a de la marge ; sur un Orin Nano 8 Go, chaque mégaoctet alloué quelque part en retire ailleurs.
Faire tourner un LLM quantifié sur Orin
Avec llama.cpp et une quantification GGUF, un AGX Orin fait tourner des modèles 7 B confortablement et des 13 B sous contrainte. Le mécanisme qui rend ce déploiement viable est la quantification : descendre les poids de 16 bits à 4 bits divise par quatre l’empreinte mémoire (un Llama 3 8 B passe de ~16 Go à ~4,5 Go en Q4_K_M) et réduit d’autant la bande passante que chaque token doit traverser. Le débit, lui, reste loin d’un GPU datacenter parce que l’enveloppe énergétique d’Orin plafonne à 60 W contre 700 W pour un H100 : à technologie comparable, on n’arrache pas les mêmes tokens par seconde.
Vingt à trente tokens par seconde, c’est confortable pour un assistant local interactif : l’utilisateur lit à peu près à cette vitesse, donc la latence perçue est nulle. Ce n’est pas un débit de service : à dix requêtes concurrentes, chacune tombe à 2-3 tokens/s et l’interaction devient pénible. La bonne question n’est donc pas « quel est le plus gros modèle qui démarre » mais « quel est le plus petit modèle qui résout ma tâche » : un Llama 3 8 B qui pousse 27 tokens/s vaut mieux qu’un 13 B à 13 tokens/s si la qualité de réponse est équivalente sur votre domaine.
Vision : le terrain naturel d’Orin
Là où Orin est imbattable dans son enveloppe, c’est la vision. Détection d’objets, segmentation, suivi sur plusieurs flux caméra simultanés : ces charges combinent deux propriétés que le GPU Orin avale bien. D’abord, les modèles compacts (un YOLOv8 fait quelques dizaines de mégaoctets, contre plusieurs gigaoctets pour un LLM), donc l’empreinte mémoire reste modeste. Ensuite, une intensité arithmétique élevée : chaque pixel d’image déclenche beaucoup de calculs par octet de poids lu, ce qui sature les unités de calcul plutôt que la bande passante mémoire. C’est exactement le régime où un GPU est efficient.
Beaucoup de déploiements réels combinent les deux usages : Orin traite les flux caméra en continu, et garde un petit LLM en mémoire pour raisonner sur les détections, par exemple décider qu’une succession d’événements visuels vaut une alerte. Les deux charges coexistent sur la même mémoire unifiée, ce qui ramène à la contrainte centrale.
Les vraies limites : mémoire unifiée et thermique
La mémoire unifiée se sature en silence. Voici concrètement ce qui se passe. Au démarrage, le pipeline vision réserve ses buffers, disons 1,5 Go pour quatre flux HD plus les tenseurs intermédiaires du modèle de détection. Le LLM quantifié de 4,5 Go est chargé en mmap Appel système qui « mappe » un fichier dans l'espace d'adressage d'un processus. Le fichier n'est pas chargé en RAM d'un coup : l'OS charge les pages à la demande, au premier accès. C'est ce qui permet à llama.cpp de démarrer un modèle de 40 Go en une fraction de seconde. (un appel système qui projette un fichier dans l’espace d’adressage du processus, chargé page par page à la demande). Le système d’exploitation et les services courants occupent 2 Go. Sur un Orin Nano 8 Go, il reste déjà à peine un demi-gigaoctet de marge.
À la première requête LLM, le KV cache commence à se remplir : ~128 Ko par token pour un 8 B en FP16 (en GQA, 8 têtes KV, ramené à ~32 Ko en Q4 quand le runtime le supporte), et une conversation de 2 000 tokens occupe ~250 Mo en FP16, ~64 Mo en Q4 ; un contexte de 32 k tokens fait grimper ce poste à plusieurs gigaoctets. Le noyau Linux n’envoie pas d’alerte : il évince les pages les moins utilisées du modèle mmap, qui seront rechargées depuis la flash à la prochaine inférence, une lecture eMMC à 200 Mo/s pendant qu’on espérait calculer à 200 GB/s.
Le débit s’effondre d’un facteur 10 à 100 sur les tokens concernés, et l’utilisateur voit son assistant figer aléatoirement. Le piège est qu’il n’y a pas de swap explicite à surveiller : juste un fichier mmap qui pagine silencieusement depuis le stockage de boot, sans alerte côté système.
Le throttling thermique est le second piège, et il décale la mesure. Une enveloppe « 60 W » sur fiche technique n’est pas une enveloppe garantie : c’est un plafond qu’Orin tient tant que la température de jonction reste sous son seuil. Sous charge LLM continue dans un boîtier fermé avec un dissipateur médiocre, la jonction monte en 60 à 120 secondes, et le firmware abaisse la fréquence GPU pour rester dans son budget thermique. Le débit chute de 30 % à 50 % par rapport au burst initial. Voilà pourquoi un benchmark de 30 secondes est trompeur : il mesure le régime froid, jamais celui où votre service vit.
Concevoir pour Orin, c’est donc budgéter la mémoire comme sur un système embarqué (chaque mégaoctet compte, chaque conversation a un coût prévisible qu’il faut plafonner par configuration) et caractériser le comportement thermique sous charge prolongée, pas en pic. Une heure de test continu dans le boîtier final, dans l’ambiance thermique de déploiement, vaut tous les benchmarks de fiche technique.
Edge vs cloud : la bonne frontière
La frontière utile n’est pas technique, elle est décisionnelle. L’edge gagne quand la latence, la confidentialité ou la résilience hors-ligne priment : une boucle de contrôle robotique à 50 ms ne tolère aucun aller-retour réseau, un dossier médical ne sort pas du bâtiment, et un véhicule en zone blanche doit continuer à décider. Le cloud gagne quand il faut le plus gros modèle possible (un 70 B ou un 405 B ne rentrent dans aucune enveloppe edge raisonnable) ou un débit agrégé élevé, là où on amortit la carte sur des milliers de requêtes par seconde.
La plupart des architectures déployées sont hybrides : Orin filtre, résume et décide localement sur les cas faciles, qui font la majorité du trafic, et n’escalade vers le cloud que les cas difficiles, ceux où la confiance du petit modèle est basse. On préserve la latence et la confidentialité sur l’essentiel du flux, on paie le cloud uniquement quand il apporte une vraie valeur. C’est la même logique que les CDN au-dessus d’un origin server : le calcul proche absorbe ce qu’il peut, le calcul gros reste centralisé.
Conclusion
Orin tient bien son rôle de calculateur embarqué pour la vision temps réel et les LLM jusqu’à 13 B en quantifié, pour qui accepte de raisonner mémoire et thermique comme un système temps réel, pas comme un mini-datacenter. La vraie question pour quiconque démarre un projet edge en 2026 n’est donc pas « Orin tient-il ma charge », c’est quelle tranche d’Orin tient votre charge, et où est le palier au-dessus quand votre modèle aura grossi de 30 %. Le Jetson AGX Thor à 128 Go ouvre justement ce palier supérieur ; pour le débat de fond entre GPU programmable et puce dédiée à plus basse consommation, voir NPU vs GPU à l’edge.
Sources et méthode
Spécifications des modules (faits vérifiés, fiches NVIDIA consultées le 14 mai 2026) :
- Jetson Orin, page et modules : capacités mémoire, GPU Ampere, enveloppes par module
- Mode « Super » de JetPack 6.2 (janvier 2025) : révision des enveloppes : Orin Nano jusqu’à 25 W, Orin NX jusqu’à 40 W
- Architecture mémoire unifiée : documentation CUDA for Tegra (mémoire managée / zero-copy)
Débits LLM : estimation crédible, pas fait vérifié. Ordres de grandeur pour llama.cpp en Q4_K_M sur AGX Orin 64 Go ; NVIDIA ne publie pas de table llama.cpp officielle, et les résultats communautaires varient fortement selon la version de llama.cpp et de CUDA. Toute reprise doit préciser la version logicielle exacte et être recaractérisée en régime thermique établi.
