Optimisation mémoire Jetson Inference

Recommande un runtime d'inférence et les flags spécifiques liés à la mémoire à lui passer, en fonction du SKU/variant Jetson et de la charge de travail de l'utilisateur. N'inclut pas la sélection de la recette de quantification — celle-ci se trouve dans la skill model-benchmarking — mais pointe le plancher de précision que chaque runtime peut servir efficacement.

Objectif

Convertir un snapshot jetson-memory-audit en direct en recommandations de runtime et de flags de lancement pour la diffusion LLM/VLM sur Jetson. À utiliser quand l'utilisateur doit ajuster un modèle, réduire le risque d'OOM, ou passer à une pile de diffusion moins gourmande en mémoire.

Quand utiliser

• "Quelle pile de diffusion dois-je utiliser sur Orin Nano 8 GB pour exécuter un modèle 7B ?"
• "vLLM fait des OOM — qu'est-ce que --gpu-memory-utilization et --max-model-len doivent être ?"
• "Même modèle, moins de mémoire — puis-je passer de vLLM à llama.cpp ?"
• Après que jetson-memory-audit montre qu'un serveur de modèle est le plus gros consommateur de NvMap / PSS.

Prérequis

• Commencez par un snapshot JSON courant de jetson-memory-audit/scripts/audit.sh depuis la cible Jetson.
• Connaître la charge de travail prévue : llm-server, vlm-server, embedding, ou rag.
• Si l'utilisateur donne une cible de mémoire libre souhaitée, la passer en --target-mb ; sinon laisser le script utiliser les défauts du SKU.

Scripts disponibles

Si votre runtime agent supporte run_script, invoquez run_script("scripts/recommend.py", ["--audit", "/tmp/audit.json", "--runtime", "auto", "--workload", "llm-server"]) et résumez le JSON retourné. Sinon exécutez-le avec python3 depuis la racine du dépôt.

Instructions

1. Exécutez jetson-memory-audit/scripts/audit.sh pour capturer la ligne de base du device.
2. Exécutez scripts/recommend.py --audit /tmp/audit.json --runtime auto --workload llm-server --target-mb 6000 pour obtenir un JSON des recommandations de runtime + flags.
3. L'agent présente le runtime suggéré et les flags CLI exacts. L'utilisateur (ou un agent orchestrateur externe) lance/redémarre le serveur avec ces flags.
4. Réexécutez l'audit pour vérifier.

Flux de travail attendu

Utilisez scripts/recommend.py pour la prompt et la réponse spécifiques du JSON qu'il émet. Si l'exécution directe est bloquée, exécutez-la en tant que python3 {baseDir}/scripts/recommend.py ....

• Pour les prompts vLLM OOM, exécutez avec --runtime vllm --workload llm-server et incluez les valeurs concrètes --gpu-memory-utilization=<0.x> et --max-model-len=<number> de launch_flags.
• Pour les prompts "mémoire minimale" ou Orin Nano 8 GB, exécutez avec --runtime auto --workload llm-server ; préférez le runtime du JSON et mentionnez explicitement le compromis GGUF / 4-bit quand il sélectionne llama-cpp.
• Pour les prompts SGLang, exécutez avec --runtime sglang et citez --mem-fraction-static, --max-running-requests, et toute note sur le contexte/KV-cache.
• Pour les prompts "passer de vLLM à llama.cpp", exécutez avec --runtime llama-cpp et citez -ngl, -c, et --no-mmap.

Limitations

• Les recommandations sont aussi à jour que le JSON d'audit. Réexécutez jetson-memory-audit après l'arrêt des services, le changement de mode d'alimentation, ou le redémarrage des serveurs de modèle.
• Le script estime la pression mémoire à partir des défauts du SKU et des totaux d'audit ; le KV-cache spécifique au modèle, la quantification, et le comportement du tokenizer peuvent néanmoins nécessiter des benchmarks.
• Cette skill émet uniquement des flags. Elle ne démarre, n'arrête, ni ne redémarre les serveurs de modèle.

Gestion des erreurs

• Sortie 2 : le JSON d'audit n'a pas pu être lu, analysé, ou ne contenait pas de champs mémoire numériques valides. Demandez à l'utilisateur de réexécuter jetson-memory-audit/scripts/audit.sh.
• Sortie 3 : runtime ou charge de travail demandée non prise en charge. Réexécutez avec l'une des valeurs --runtime et --workload listées dans scripts/recommend.py --help.
• launch_flags vide ou manquant : n'inventez pas de flags de secours. Signalez l'échec du script et demandez un audit récent ou un runtime pris en charge.

Contrat de sortie pour recommend.py

{
  "sku": "orin-nx",
  "variant": "orin-nx-16gb",
  "mem_total_gb": 16,
  "runtime": "vllm",
  "rationale": "Débit maximal avec ce budget mémoire étant donné le traitement par batch continu + paged attention.",
  "launch_flags": [
    "--gpu-memory-utilization=0.55",
    "--max-model-len=4096",
    "--max-num-seqs=8",
    "--enable-prefix-caching"
  ],
  "alternatives": [
    { "runtime": "llama-cpp", "rationale": "Plancher mémoire plus bas avec GGUF Q4_K_M.", "launch_flags": ["-ngl 28", "-c 4096", "--no-mmap"] }
  ],
  "notes": ["Abaissez davantage --gpu-memory-utilization si vous exécutez aussi un petit VLM en parallèle."]
}

Runtimes couverts

Pour Orin JetPack 7.2 / L4T r39+, vLLM upstream 0.20+ est pris en charge. Pour les anciennes versions d'Orin, préférez les images vLLM préconstruites NVIDIA-AI-IOT où disponibles car elles expédient la stack CUDA/cuDNN/TensorRT correspondant à JetPack. Pour Thor, préférez vLLM upstream 0.20+ (vllm/vllm-openai) ou une installation native vLLM 0.20+ validée ; pour SGLang utilisez NVIDIA SGLang 26.01 (nvcr.io/nvidia/sglang:26.01-py3, SGLang 0.5.5.post2) ou les notes de sortie NVIDIA SGLang plus récentes qui listent explicitement le support Jetson Thor. Ne forcez pas un chemin conteneur Jetson spécifique à Orin sur Thor, et ne supposez pas le support SGLang upstream natif sur Orin.

Recommandations de quantification

Utilisez les noms de quantification spécifiques au runtime. vLLM et SGLang consomment généralement les checkpoints Hugging Face comme W4A16, AWQ, GPTQ, FP16, ou NVFP4. llama.cpp et Ollama consomment les modèles GGUF, recommandez plutôt GGUF INT4/Q4_K_M.

Ne décrivez pas GGUF Q4_K_M comme W4A16/AWQ/GPTQ. Ne comparez pas les résultats NVFP4 de Thor avec les résultats W4A16 d'Orin sauf si la sortie inclut un champ quant.

Orientation des commandes de runtime

Utilisez recommend.py comme source de vérité pour les knobs mémoire, puis placez ses launch_flags dans la commande de diffusion correspondante. Conservez l'orientation des commandes dans cette skill plutôt que dans de petits fichiers de référence séparés afin que les agents assimilent un ensemble d'instructions complet et unique.

Pour vLLM sur Orin avec JetPack 7.2 / L4T r39+, utilisez vLLM upstream 0.20+ (vllm/vllm-openai:latest). Sur les anciennes versions d'Orin, utilisez l'image 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-model-id-or-local-path> \
    --host 0.0.0.0 \
    --port 8000 \
    --gpu-memory-utilization 0.60 \
    --max-model-len 4096 \
    --max-num-seqs 8 \
    --enable-prefix-caching

Pour vLLM sur Thor, utilisez vLLM upstream 0.20+ (vllm/vllm-openai:latest) sauf si vLLM natif 0.20+ est déjà installé sur l'hôte et validé :

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-model-id-or-local-path> \
    --host 0.0.0.0 \
    --port 8000 \
    --gpu-memory-utilization 0.75 \
    --max-model-len 8192 \
    --max-num-seqs 32 \
    --enable-prefix-caching

Note vLLM Thor : ne jugez pas le support Thor à partir des résultats vLLM antérieurs à 0.20 ; le support vLLM upstream commence à vLLM 0.20+.

Pour SGLang sur Thor, utilisez NVIDIA SGLang 26.01 (nvcr.io/nvidia/sglang:26.01-py3). NVIDIA SGLang 26.01 contient SGLang 0.5.5.post2 et liste explicitement le support Jetson Thor. Évitez de juger le support Thor à partir des résultats SGLang préalables plus anciens. Évitez de recommander les chemins gpt-oss ou FP8 sur Thor sauf si les notes de sortie NVIDIA SGLang plus récentes disent que ces problèmes connus sont résolus.

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-model-id-or-local-path> \
    --host 0.0.0.0 \
    --port 8000 \
    --mem-fraction-static 0.60 \
    --max-running-requests 8

Pour llama.cpp, utilisez l'image NVIDIA-AI-IOT llama.cpp quand disponible, ou le binaire llama-server à partir d'une build JetPack-adaptée. Commencez par GGUF INT4 / Q4_K_M sur Orin et Thor ; choisissez un modèle GGUF INT4 plus petit si l'audit montre une mémoire serrée.

docker run --rm -it --runtime nvidia --network host --name llama-cpp \
  -v "$PWD/models:/models:ro" \
  ghcr.io/nvidia-ai-iot/llama_cpp:latest-jetson-<orin-or-thor> \
  llama-server \
    -m /models/<model>.gguf \
    --host 0.0.0.0 \
    --port 8000 \
    -ngl 28 \
    -c 4096 \
    --no-mmap \
    --flash-attn

Procédure (le script l'encode)

1. Choisissez le runtime le plus léger qui satisfait les fonctionnalités requises par l'utilisateur (traitement par batch continu ? génération structurée ? déchargement CPU ?).
2. Choisissez la précision la plus basse qui satisfait la barre de précision de l'utilisateur (skill model-benchmarking).
3. Parcourez les knobs mémoire du runtime (commencez par gpu-memory-utilization pour vLLM, n-gpu-layers et ctx-size pour llama.cpp) pour trouver l'empreinte minimale qui soutient le débit cible.
4. Re-mesurez avec jetson-memory-audit.

Sécurité

Lecture seule. La skill ne démarre, n'arrête, ni ne redémarre jamais un serveur de modèle. Elle émet des flags ; l'utilisateur (ou un agent d'orchestration externe) est responsable d'invoquer le runtime.