Un modèle atteignant une précision state-of-the-art sur un jeu de données de référence ne se qualifie pas automatiquement pour le déploiement sur le terrain. Les modèles de recherche sont entraînés sur des clusters GPU avec mémoire et calcul abondants. Les modèles déployés doivent fonctionner sur du matériel Edge avec des budgets de puissance stricts, une mémoire limitée et des exigences de latence en temps réel. ONNX et TensorRT sont les deux technologies clés dans le pipeline d'optimisation pour le déploiement Jetson.
L'écart entre entraînement et inférence
Exécuter un modèle de recherche en PyTorch sur Jetson Orin NX sans optimisation produit une inférence à ~8–15 fps pour un modèle de détection moyen — bien en dessous des 30 fps cibles. Trois sources de cet écart : surcharge mémoire (état de l'optimiseur, tampons de gradient), surcharge de calcul (graphes dynamiques) et inadéquation de précision (FP32 vs INT8).
ONNX comme interchange universel : export depuis PyTorch
La fonction `torch.onnx.export` trace le graphe de calcul du modèle en l'exécutant avec des tenseurs d'entrée exemples. Paramètres clés : opset_version (opset 16 ou 17 pour une couverture maximale avec TensorRT) ; dynamic_axes (la dimension de lot doit être dynamique). Pièges courants : la tête NMS de détection YOLOv8 est la zone problématique la plus fréquente — toujours valider le modèle ONNX exporté avant la compilation TensorRT.
Compilation TensorRT : calibration INT8, fusion de couches, auto-tuning de noyau
TensorRT prend un modèle ONNX en entrée et produit un fichier de moteur optimisé pour une architecture GPU cible. La compilation comprend : parsing réseau ; passes d'optimisation (fusion de couches, optimisation de layout tensoriel) ; calibration de précision — pour INT8, TensorRT exécute une calibration sur 500–1 000 images représentatives. L'étape d'auto-tuning dure 30–90 minutes mais s'exécute une seule fois. Les fichiers de moteur sont spécifiques à l'architecture GPU.
Latence vs débit : taille de lot 1 pour l'inférence en temps réel
À la taille de lot 1, YOLOv8-medium INT8 sur Jetson AGX Orin tourne à ~1,8ms de latence. Pour un système à quatre caméras à 30 fps chacune, la taille de lot 4 permet le traitement simultané d'une trame de chaque flux caméra en ~5ms.
Insight clé : Les fichiers de moteur TensorRT ne sont pas portables entre architectures GPU. Compilez les moteurs sur la classe d'appareils cibles conformément aux exigences DGA/EMA pour le système d'armes spécifique — tenter d'exécuter un moteur compilé pour AGX Orin sur Orin NX produira des erreurs ou une dégradation silencieuse de la précision.
Versionning des modèles et pipeline de mise à jour pour les appareils de terrain
Flux de mise à jour : nouveau modèle entraîné centralement → export ONNX → ONNX transmis sur l'appareil via canal sécurisé → compilation TensorRT on-device → moteur compilé activé → ancien moteur archivé pour rollback. Chaque version du modèle ONNX doit porter un identifiant de version sémantique, un hash SHA-256 et une signature cryptographique.