Jetson LLM Serve

Encode le tutoriel GenAI Jetson AI Lab : sur Orin JetPack 7.2 / L4T r39+, utilise vLLM 0.20+ en amont (vllm/vllm-openai:latest) ; sur les anciennes versions d'Orin, choisis le conteneur vLLM précompilé NVIDIA-AI-IOT ; sur Thor, utilise vLLM 0.20+ en amont ou vLLM 0.20+ natif validé, et utilise NVIDIA SGLang 26.01 (nvcr.io/nvidia/sglang:26.01-py3, SGLang 0.5.5.post2) quand SGLang est demandé. Définis MAXN, mets les identifiants Hugging Face et le cache à disposition, et lance un serveur compatible OpenAI. Fonctionne pour les LLMs et VLMs.

Objectif

Fournir une recette de serveur appropriée à Jetson pour un LLM ou VLM utilisant vLLM ou SGLang, incluant le chemin d'exécution, la commande de lancement, l'endpoint, et l'étape de vérification.

Quand l'utiliser

• « Exécute / sers / héberge ce modèle sur un Jetson. »
• « Démarre un serveur vLLM que je peux interroger depuis Open WebUI / mon appli. »
• Après que jetson-inference-mem-tune a produit des flags de lancement et que l'utilisateur veut réellement démarrer le serveur.

Pour les questions concernant une recette seule, réponds à partir de ce document sans démarrer les conteneurs. Effectue les vérifications préalables en direct uniquement si l'utilisateur te demande de vérifier ce périphérique ou d'exécuter le déploiement.

Prérequis

• Exécute sur l'hôte Jetson ou un shell avec accès Docker au runtime GPU Jetson.
• Connais la génération Jetson cible (thor ou orin) et l'identifiant du modèle ou le chemin du checkpoint local.
• Utilise HF_TOKEN uniquement quand le modèle est privé/protégé ; les modèles publics doivent omettre la variable d'environnement token.
• Utilise jetson-inference-mem-tune d'abord quand l'espace mémoire disponible ou les flags de lancement sont incertains.

Instructions

Pour les questions de recette, fournis une recette de lancement complète au lieu de tenter d'appeler jetson-llm-serve comme outil. Une réponse complète inclut :

• Le chemin d'exécution approprié à Jetson : vLLM 0.20+ en amont (vllm/vllm-openai:latest) ou NVIDIA SGLang 26.01 (nvcr.io/nvidia/sglang:26.01-py3, SGLang 0.5.5.post2) sur Thor, conteneur vLLM NVIDIA-AI-IOT sur anciennes versions d'Orin, ou vLLM 0.20+ en amont sur Orin JetPack 7.2 / L4T r39+.
• Le checkpoint du modèle / repo Hugging Face nommé par l'utilisateur.
• Un schéma de commande docker run + serveur avec --host 0.0.0.0 --port 8000.
• L'endpoint compatible OpenAI : http://<jetson-ip>:8000/v1.
• Une étape de vérification telle que curl http://localhost:8000/v1/models.

Pour les questions de VLM, énonce explicitement que le VLM utilise le même flux de serveur vLLM qu'un LLM avec un checkpoint différent vision-langage. N'omets pas vLLM ou le conteneur Jetson en répondant aux demandes VLM.

Étape 1 — Choisis le chemin d'exécution (par famille Jetson)

Utilise vLLM 0.20+ en amont sur Thor (vllm/vllm-openai:latest, ou une installation vLLM 0.20+ native validée). Sur Orin JetPack 7.2 / L4T r39+, utilise vLLM 0.20+ en amont (vllm/vllm-openai:latest). Sur les anciennes versions d'Orin, utilise l'image vLLM précompilée NVIDIA-AI-IOT (packages) car elle inclut le bon ensemble CUDA / cuDNN / TensorRT pour ce JetPack. Utilise NVIDIA SGLang 26.01 (nvcr.io/nvidia/sglang:26.01-py3, SGLang 0.5.5.post2) sur Thor quand l'utilisateur demande SGLang, RAG, tool-use, ou un serveur programmable ; ne recommande pas SGLang natif en amont sur Orin sauf si une version adaptée au JetPack le supporte explicitement.

Pour détecter l'ère du silicium pour les tags d'image :

1. Source le détecteur pour que les exports survivent dans ton shell :

   . skills/jetson-diagnostic/scripts/detect_jetson.sh

2. Vérifie JETSON_GENERATION (thor ou orin) et choisis le chemin d'exécution correspondant dans le tableau ci-dessus.
3. Utilise JETSON_PRODUCT_LINE pour un groupe plus fin tel que thor-agx ou orin-nano ; JETSON_SKU reste l'identifiant historique.

N'utilise pas bash skills/jetson-diagnostic/scripts/detect_jetson.sh quand tu as besoin de variables exportées dans l'appelant ; exécuter avec bash utilise un sous-shell.

Étape 2 — Définis le mode d'alimentation MAXN

sudo nvpmodel -m 0 && sudo jetson_clocks

Ignore cette étape seulement si l'utilisateur demande explicitement une exécution avec consommation électrique réduite ; sinon les nombres de benchmark et de serveur seront incohérents.

Étape 3 — Lance le serveur

Sur Thor avec vLLM, utilise vLLM 0.20+ en amont (vllm/vllm-openai:latest) ou une installation vLLM 0.20+ native validée :

docker run --rm -it --runtime nvidia --network host --ipc host --name vllm \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  -e HF_TOKEN="$HF_TOKEN" \
  vllm/vllm-openai:latest \
  vllm serve <hf-repo-id> \
    --host 0.0.0.0 --port 8000 \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.75 \
    --tensor-parallel-size 1

Sur Orin JetPack 7.2 / L4T r39+, utilise vLLM 0.20+ en amont (vllm/vllm-openai:latest). Sur les anciennes versions d'Orin, utilise le conteneur NVIDIA-AI-IOT :

docker run --rm -it --runtime nvidia --network host --name vllm \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  -e HF_TOKEN="$HF_TOKEN" \
  ghcr.io/nvidia-ai-iot/vllm:latest-jetson-orin \
  vllm serve <hf-repo-id> \
    --host 0.0.0.0 --port 8000 \
    --max-model-len 4096 \
    --gpu-memory-utilization 0.85 \
    --tensor-parallel-size 1

HF_TOKEN est obligatoire seulement pour les modèles Hugging Face privés/protégés ; omets la ligne -e HF_TOKEN="$HF_TOKEN" pour les modèles publics qui ne nécessitent pas d'authentification Hub. Passer HF_TOKEN comme variable d'environnement peut l'exposer via la sortie docker inspect, les métadonnées de processus, ou les logs sur les systèmes partagés. Préfère le token avec la plus petite portée possible, révoque-le/change-le après une utilisation de conteneur partagé, et utilise un fichier d'identifiants monté ou un secret Docker quand l'environnement de déploiement le supporte.

Attends Application startup complete. Le serveur est sur http://0.0.0.0:8000/v1.

Pour SGLang sur Thor, utilise NVIDIA SGLang 26.01 (nvcr.io/nvidia/sglang:26.01-py3), qui contient SGLang 0.5.5.post2 et énumère le support Jetson Thor. Ne juge pas le support SGLang Thor à partir des anciens résultats SGLang en pré-version :

docker run --rm -it --runtime nvidia --network host --ipc host --name sglang \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  -e HF_TOKEN="$HF_TOKEN" \
  nvcr.io/nvidia/sglang:26.01-py3 \
  python3 -m sglang.launch_server \
    --model-path <hf-repo-id> \
    --host 0.0.0.0 \
    --port 8000 \
    --mem-fraction-static 0.60 \
    --max-running-requests 8

Utilise SGLang quand l'utilisateur a besoin de workflows RAG/tool-use, de génération structurée, ou d'ordonnancement spécifique à SGLang. Pour un simple serveur à haut débit compatible OpenAI, préfère vLLM sauf si l'utilisateur demande SGLang.

Paramètres par défaut appropriés à la SKU

Si le serveur OOM au démarrage, baisse --gpu-memory-utilization de 0,05 et relance (ou exécute jetson-inference-mem-tune pour une recommandation consciente de la charge).

Préférences de quantification (importe plus que le runtime)

Pour vLLM et SGLang, choisis les formats de checkpoint par famille Jetson :

Pour llama.cpp et Ollama, utilise plutôt les noms de quantification GGUF : recommande INT4 / Q4_K_M GGUF sur Orin et Thor, et choisis un modèle GGUF INT4 plus petit si la mémoire est serrée. N'appelle pas un GGUF Q4_K_M un modèle W4A16/AWQ/GPTQ. NVFP4 est préféré et ajusté sur Thor pour les runtimes qui le supportent.

Mode VLM

Les VLMs utilisent le même flux que les LLMs : même conteneur, même invocation vllm serve, checkpoint vision-langage différent. Le conteneur gère le prétraitement des images. Pour une UI navigateur spécifique au VLM, utilise le conteneur live-vlm-webui ; pour une UI chat générique pour l'un ou l'autre, utilise Open WebUI pointant vers http://<jetson-ip>:8000/v1.

Ne fabrique pas de capacité de périphérique

N'invente pas de totaux RAM, valeurs de mémoire libre, tailles de modèle, versions JetPack, ou noms SKU/variante en donnant une recette de serveur. Si la capacité importe, soit exécute les vérifications préalables en direct (quand l'exécution est autorisée), soit confie à jetson-inference-mem-tune / jetson-memory-audit. Si les données en direct ne sont pas disponibles, dis que la valeur est inconnue et fournis des valeurs par défaut conservatrices au lieu de citer un nombre inventé.

Liste de vérification préalable (l'agent doit vérifier avant d'exécuter l'étape 3)

• [ ] Sur un Jetson (/proc/device-tree/model contient NVIDIA Jetson).
• [ ] nvpmodel -q rapporte un mode de performance maximale reconnu : MAXN ou MAXN_* tel que MAXN_SUPER. Les modes nommés par wattage doivent être signalés comme avertissements sauf si l'utilisateur confirme explicitement que c'est le mode de benchmark prévu pour ce périphérique.
• [ ] Sur Thor, vérifie si MIG est activé avant le lancement (nvidia-smi -L et nvidia-smi mig -lgi). Si MIG est activé, avertis que vLLM/SGLang ne voit peut-être qu'une tranche MIG ou aucun périphérique CUDA.
• [ ] Sur Thor avec MIG ou conflit d'affichage/caméra, inspecte les utilisateurs GPU avec sudo lsof /dev/nvidia*. Les gestionnaires d'affichage, Xorg/GNOME, ou nvargus-daemon peuvent détenir les fichiers de périphérique GPU ; ne stoppe pas les services ou change le mode MIG sauf si l'utilisateur approuve explicitement.
• [ ] Aucun conteneur nommé vllm ne s'exécute déjà (docker ps --format '{{.Names}}') ; sinon docker rm -f vllm d'abord.
• [ ] Docker expose le runtime NVIDIA (docker info | grep -i 'runtimes.*nvidia'), ou un conteneur activé pour GPU peut exécuter nvidia-smi.
• [ ] ~/.cache/huggingface existe ; HF_TOKEN est défini si le modèle est protégé.

Limitations

• Cette compétence fournit les commandes de serveur et les vérifications préalables ; elle ne benchmark pas le serveur déployé.
• Les tags de conteneur tels que latest sont mutables. Pour les déploiements en production ou de conformité, épingle un digest et enregistre-le avec les notes de déploiement.
• Les limites de mémoire vLLM et SGLang dépendent toujours de l'architecture du modèle, de la quantification, de la longueur de contexte, et du nombre de requêtes concurrentes. Utilise jetson-inference-mem-tune quand une commande OOM ou que l'espace mémoire importe.
• vLLM Thor requiert vLLM 0.20+ en amont ou plus récent. Les anciennes images vLLM en amont peuvent ne pas supporter Thor / SM 11.0 correctement.
• SGLang Thor doit utiliser NVIDIA SGLang 26.01 ou des notes de version plus récentes qui énumèrent explicitement le support Jetson Thor. NVIDIA SGLang 26.01 contient SGLang 0.5.5.post2.
• Sur Thor, MIG, l'affichage de bureau, ou les services caméra peuvent cacher le GPU complet aux conteneurs. Cette compétence doit seulement détecter et avertir ; désactiver MIG ou arrêter les services tels que gdm3 ou nvargus-daemon requiert l'approbation explicite de l'utilisateur.
• vLLM/SGLang natif sur l'hôte Thor ne doit être utilisé que quand cette installation est déjà validée sur le JetPack cible.

Transfert vers

• jetson-llm-benchmark pour mesurer réellement le serveur déployé.
• jetson-speculative-decoding pour ajouter une spéculation EAGLE-3 / draft-model en ajoutant --speculative-config '{...}' à la commande vllm serve ci-dessus.
• jetson-inference-mem-tune si le serveur OOM ou est limité par la mémoire.

Source

Jetson AI Lab — Introduction to GenAI on Jetson: How to Run LLMs and VLMs et packages NVIDIA-AI-IOT GHCR.