Ce que « edge AI » veut dire vraiment
« Edge AI » ne veut pas dire « le cloud, en plus petit ». Cela veut dire faire de l’inférence 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 souvent l’absence de connexion fiable.
Le Jetson Orin de NVIDIA est l’un des rares modules à offrir un vrai GPU programmable dans cette enveloppe. C’est ce qui le rend intéressant — et ce qui fixe ses limites.
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, c’est la mémoire unifiée : CPU et GPU partagent la même RAM physique. De quoi éliminer les copies hôte↔device avec une mémoire épinglée ou managée — mais surtout une enveloppe mémoire commune que le modèle, le KV cache, le pipeline vision et le système d’exploitation doivent se partager.
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 débit, lui, reste loin d’un GPU datacenter.
Vingt à trente tokens par seconde, c’est confortable pour un assistant local interactif. Ce n’est pas un débit de service. La bonne question n’est 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 ».
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 ont une intensité arithmétique élevée et des modèles compacts, exactement ce que le GPU Orin avale bien. Beaucoup de déploiements réels utilisent Orin pour la vision et gardent un petit LLM pour le raisonnement sur les détections.
Les vraies limites : mémoire unifiée et thermique
Concevoir pour Orin, c’est budgéter la mémoire comme sur un système embarqué — chaque mégaoctet compte — et caractériser le comportement thermique sous charge prolongée, pas en pic.
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. Le cloud gagne quand il faut le plus gros modèle possible ou un débit agrégé élevé. Beaucoup d’architectures réelles sont hybrides : Orin filtre, résume et décide localement, et n’escalade vers le cloud que les cas difficiles.
Conclusion
Le Jetson Orin n’est pas un mini-datacenter : c’est un calculateur embarqué qui, bien dimensionné, fait tourner de la vision temps réel et des LLM quantifiés utiles. Le succès tient à la sobriété — choisir le plus petit modèle qui suffit — et au respect des deux plafonds réels : la mémoire unifiée et le thermique. Pour le choix de l’accélérateur lui-même, 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.
