LLM sur NVIDIA Jetson Orin : l'IA embarquée qui tient dans la main

#Pourquoi un Jetson Orin pour un LLM

Un Jetson Orin n'est pas un microcontrôleur : c'est un module système-on-chip qui combine un CPU ARM Cortex, un GPU NVIDIA avec cœurs CUDA et Tensor, et de la mémoire unifiée partagée entre les deux. Concrètement, le GPU accède directement à la RAM système — pas de VRAM séparée. Un LLM chargé occupe donc la mémoire unifiée, exactement comme sur un Mac Apple Silicon, et le calcul profite de l'accélération CUDA.

C'est ce qui distingue radicalement le jetson orin llm d'une IA sur Raspberry Pi : là où le Pi peine en CPU pur, l'Orin délègue au GPU et tient des débits utilisables sur des modèles 3B à 8B. Le tout dans une enveloppe de 7 à 60 watts, alimentable sur batterie, sans ventilateur bruyant ni tour sous le bureau.

Autonomie réseau

Aucune dépendance au cloud : le modèle tourne à bord, y compris sur un robot mobile ou un site isolé sans connexion.

Latence prévisible

Pas d'aller-retour internet. La réponse dépend uniquement du GPU local, ce qui compte pour une boucle de contrôle temps réel.

Confidentialité

Les données capteurs, caméras ou micros ne quittent jamais l'appareil. Essentiel en domotique et en milieu médical.

Écosystème CUDA

Le même stack logiciel qu'un GPU desktop NVIDIA : Ollama, llama.cpp, PyTorch et TensorRT fonctionnent, à la compilation ARM près.

#Jetson Orin Nano ou AGX : choisir sa carte

La gamme Orin couvre un facteur 8 en mémoire et bien plus en puissance. Pour un LLM, le critère décisif est la RAM unifiée : elle plafonne la taille du modèle exactement comme la VRAM sur un GPU classique. Voici les paliers qui comptent.

Orin Nano 8 Go

Le point d'entrée (~40 TOPS). 8 Go de RAM unifiée partagée avec le système. Vise des modèles 3B en Q4, ou un 7B serré si vous libérez la mémoire. Idéal capteur intelligent, assistant vocal embarqué.

Orin NX 8 / 16 Go

Le milieu de gamme (~70-100 TOPS). Le 16 Go ouvre confortablement les 7B-8B en Q4_K_M. Bon compromis robotique mobile.

AGX Orin 32 Go

Station embarquée (~200 TOPS). Fait tourner un 14B en Q4 avec du contexte, ou plusieurs petits modèles en parallèle (vision + langage).

AGX Orin 64 Go

Le haut de gamme (~275 TOPS). Vise les 32B en Q4 (~19 Go) avec de la marge pour le contexte et d'autres charges. Le seul de la gamme à viser du 32B sérieux.

#Prérequis et rôle de JetPack

Tout l'écosystème Jetson repose sur JetPack, la distribution logicielle de NVIDIA. Elle embarque Ubuntu (L4T, Linux for Tegra), les pilotes CUDA, cuDNN, TensorRT et les bibliothèques GPU. Sans JetPack correctement flashé, aucune accélération : vous tomberiez en CPU pur, perdant tout l'intérêt de la carte.

Une carte Jetson Orin

Nano, NX ou AGX, avec son alimentation adaptée (le Nano tire jusqu'à 15 W, l'AGX jusqu'à 60 W).

Stockage rapide

Carte microSD (UHS-I) pour le Nano en test, mais un SSD NVMe est fortement recommandé : les modèles pèsent plusieurs Go et le chargement en pâtit sur SD.

Un PC hôte Linux (Ubuntu)

Nécessaire pour flasher via SDK Manager sur les AGX/NX. Le Nano Developer Kit s'installe directement depuis une image SD.

JetPack 6.x

La branche récente basée sur Ubuntu 22.04, avec CUDA 12. C'est la cible pour un stack LLM moderne (Ollama et llama.cpp compilés pour l'architecture ARM SBSA).

#1. Flasher JetPack et vérifier CUDA

1. 01
   Flasher l'image

   Pour un Orin Nano Developer Kit, écrivez l'image SD officielle sur une carte avec Balena Etcher, insérez-la, branchez et suivez l'assistant Ubuntu. Pour un AGX/NX, passez par NVIDIA SDK Manager sur le PC hôte, câble USB-C, carte en mode recovery.
2. 02
   Mettre à jour le système

   Au premier démarrage, mettez à jour les paquets. C'est aussi le moment d'installer les composants JetPack manquants si vous êtes passé par l'image SD.
3. 03
   Vérifier le GPU et CUDA

   Contrôlez que CUDA est bien présent et que le module est reconnu. jtop (installé via le paquet jetson-stats) donne une vue temps réel du GPU, de la RAM et de la consommation — l'équivalent de nvidia-smi côté Jetson.

# Mettre à jour le système
sudo apt update && sudo apt upgrade -y

# Vérifier la version de CUDA fournie par JetPack
nvcc --version

# Installer jtop (moniteur GPU/RAM/conso pour Jetson)
sudo pip3 install -U jetson-stats
sudo systemctl restart jtop.service

# Lancer le moniteur temps réel
jtop

#2. Installer Ollama sous JetPack

Ollama est la voie la plus rapide vers un premier modèle. Le script d'installation officiel détecte l'architecture ARM64 et le GPU Jetson, et configure le service systemd. Une fois lancé, le daemon écoute par défaut sur http://localhost:11434, exactement comme sur un PC de bureau.

# Script d'installation officiel (détecte ARM64 + GPU Jetson)
curl -fsSL https://ollama.com/install.sh | sh

# Le service démarre automatiquement (systemd)
systemctl status ollama

# Tirer et lancer un modèle 3B adapté au Nano
ollama run llama3.2:3b

# Vérifier que le GPU est bien utilisé (pas CPU)
ollama ps

Pour une interface façon ChatGPT, ajoutez Open WebUI en conteneur pointant sur le même endpoint. Sur un Nano 8 Go, restez sobre : chaque service consomme de la mémoire unifiée déjà comptée pour le modèle.

#3. Compiler llama.cpp avec CUDA

Ollama suffit pour la plupart des usages, mais compiler llama.cpp à la main donne un contrôle fin : choix de la quantization GGUF exacte, réglage du nombre de couches déchargées sur le GPU, et souvent quelques tokens/sec de plus. C'est aussi la voie si vous voulez intégrer le moteur dans votre propre binaire embarqué.

# Dépendances de build
sudo apt install -y build-essential cmake git libcurl4-openssl-dev

# Récupérer les sources
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

# Compiler avec CUDA activé (GGML_CUDA=ON)
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j$(nproc)

# Lancer l'inférence en déchargeant les couches sur le GPU (-ngl 99)
./build/bin/llama-cli -m modele-q4_k_m.gguf -ngl 99 -p "Bonjour"

#Quels modèles tournent selon la mémoire

La règle est la même que sur GPU desktop : en quantization Q4_K_M (le meilleur compromis qualité/mémoire), comptez ~2 Go pour un 3B, ~5 Go pour un 7B, ~9 Go pour un 14B et ~19 Go pour un 32B. Sur Jetson, retranchez la mémoire système de la RAM totale pour connaître votre budget réel.

Orin Nano 8 Go

Llama 3.2 3B, Qwen 3 4B, Gemma 3 4B en Q4. Un 7B (Mistral, Llama 3.1 8B) passe en Q4 si vous fermez tout le reste, mais le contexte reste serré.

Orin NX 16 Go

Confortable sur les 7B-8B en Q4_K_M avec du contexte. Un 14B (Phi-4) tient en Q4 en laissant peu de marge.

AGX Orin 32 Go

Un 14B en Q5, ou un 32B en quantization très agressive. Assez de place pour combiner un modèle de langage et une pile vision.

AGX Orin 64 Go

Un 32B en Q4_K_M (~19 Go) avec un grand contexte, ou plusieurs modèles chargés simultanément. Le seul palier qui vise sérieusement le 32B.

#Consommation et modes d'alimentation

L'atout maître du Jetson, c'est le rapport performance/watt. Chaque carte propose des modes d'alimentation (power modes) qui plafonnent la consommation en activant plus ou moins de cœurs CPU et en bridant la fréquence GPU. On les pilote avec nvpmodel, et jetson_clocks force les fréquences au maximum autorisé par le mode.

# Lister les modes d'alimentation disponibles
sudo nvpmodel -q

# Basculer sur le mode le plus performant (index variable selon la carte)
sudo nvpmodel -m 0

# Verrouiller les fréquences au max du mode courant
sudo jetson_clocks

# Suivre conso, GPU et température en direct
jtop

Mode basse conso

Sur Orin Nano, un mode 7 W limite fortement le débit mais permet une alimentation sur batterie ou USB-C modeste. Adapté à un capteur qui interroge le modèle par intermittence.

Mode pleine puissance

Le mode MAXN débloque tout le GPU. Sur AGX Orin, la conso peut atteindre 60 W : prévoyez le refroidissement (dissipateur actif) et une alimentation dimensionnée.

Le compromis embarqué

Beaucoup de projets tournent bien en mode 15-25 W : bon débit sur un 3B-7B, dissipation gérable, autonomie batterie raisonnable.

#Cas d'usage : robotique et domotique

Le Jetson brille là où un LLM doit vivre au plus près du monde physique, sans latence cloud ni fuite de données. Deux domaines dominent l'embarqué.

Robotique (ROS 2)

Le LLM sert d'interface langage naturel : traduire une consigne parlée en séquence d'actions, décrire une scène perçue par la caméra, raisonner sur une tâche. Le Jetson héberge à la fois la perception (vision) et le langage, sur le même GPU.

Domotique locale

Un assistant vocal maison qui commande Home Assistant sans jamais passer par un cloud. Le modèle interprète les demandes en langage naturel et déclenche les automatisations — micro et données restent à la maison.

Capteur intelligent autonome

Sur site isolé (agricole, industriel), l'Orin analyse localement des données et génère des synthèses en langage naturel, transmises seulement quand une connexion est disponible.

Assistant terrain hors-ligne

Documentation technique interrogeable en RAG, embarquée dans un véhicule ou un équipement, fonctionnant sans réseau.

#Face au Raspberry Pi : le vrai écart

La question revient toujours : pourquoi payer un Jetson quand un Raspberry Pi 5 fait aussi tourner Ollama ? La réponse tient en un mot : le GPU. Le Pi n'a pas d'accélérateur exploitable pour l'inférence LLM ; tout se fait en CPU ARM. Le Jetson, lui, décharge le calcul sur des cœurs CUDA.

Accélération

Pi 5 : CPU pur, quelques tokens/sec péniblement sur un 3B. Jetson Orin : GPU CUDA, débit plusieurs fois supérieur sur le même modèle, et des 7B-14B réellement utilisables.

Mémoire

Pi 5 plafonne à 8/16 Go de RAM CPU. Jetson va jusqu'à 64 Go de mémoire unifiée exploitable par le GPU, ouvrant des modèles hors de portée du Pi.

Prix

Le Pi coûte une fraction du Jetson. L'écart de tarif est réel : le Jetson se justifie quand vous avez besoin de débit ou de gros modèles, pas pour un simple bot 1B.

Écosystème

Le Pi est généraliste et communautaire ; le Jetson vise l'IA embarquée avec CUDA, TensorRT et le support robotique NVIDIA (Isaac).

#Dépannage

Ollama reste en CPU

Le GPU n'est pas exploité si JetPack/CUDA n'est pas correctement installé, ou si vous avez flashé une image ARM générique sans support Tegra. Vérifiez nvcc --version et l'activité GPU dans jtop.

Out of memory au chargement

Le modèle dépasse la mémoire unifiée disponible une fois le système déduit. Descendez d'une taille (7B → 3B), passez en Q4 plus agressif, ou fermez les autres services.

Débit qui s'effondre

Throttling thermique. Contrôlez la température dans jtop, améliorez le refroidissement, ou basculez sur un mode nvpmodel moins gourmand mais stable.

Chargement de modèle très lent

Modèles stockés sur microSD. Déplacez ~/.ollama (ou vos GGUF) sur un SSD NVMe pour des chargements en secondes plutôt qu'en minute.

llama.cpp ignore le GPU

Option -ngl absente ou build sans CUDA. Recompilez avec -DGGML_CUDA=ON et lancez avec -ngl 99.

# Le GPU est-il vu et actif ?
jtop

# CUDA est-il bien présent ?
nvcc --version

# Ollama utilise-t-il le GPU pour le modèle chargé ?
ollama ps

# Mode d'alimentation courant
sudo nvpmodel -q

#Pour aller plus loin

Le Jetson partage le même stack logiciel qu'un PC NVIDIA. Ces guides prolongent naturellement votre setup embarqué :

LLM sur Raspberry Pi 5 : IA locale embarquée

Le comparatif direct côté CPU pur, utile pour trancher entre Pi et Jetson selon votre projet et votre budget.

Compiler llama.cpp avec CUDA

Pour approfondir le build from source et les réglages GPU, transposables à l'architecture ARM du Jetson.

Choisir sa quantification (Q4, Q5, Q8, FP16)

Pour caler la bonne empreinte mémoire selon la RAM unifiée de votre carte Orin.