ONNX en TensorRT: AI-modellen optimaliseren voor tactische edge-inzet

Een model dat state-of-the-art nauwkeurigheid behaalt op een benchmarkgegevensset kwalificeert niet automatisch voor veldinzet. Onderzoeksmodellen worden getraind en geëvalueerd op GPU-clusters met ruime geheugen- en rekencapaciteit. Geïmplementeerde modellen moeten draaien op edge-hardware met strikte energiebudgetten, beperkt geheugen en realtime latentievereisten. De kloof tussen een PyTorch-trainingscontrolepunt en een productie-edge-inferentie-engine omspant meerdere optimalisatiestappen — en elke stap heeft implicaties voor nauwkeurigheid, latentie en onderhoudbaarheid.

ONNX (Open Neural Network Exchange) en TensorRT zijn de twee sleuteltechnologieën in de modeloptimalisatiepijplijn voor NVIDIA Jetson-inzet. ONNX biedt een frameworkneutrale tussenrepresentatie die de afhankelijkheid tussen trainingsframework en inzetomgeving doorbreekt. TensorRT compileert en optimaliseert ONNX-modellen naar apparaatspecifieke inferentie-engines die maximale prestaties halen uit NVIDIA GPU-hardware. Samen vormen ze een reproduceerbare, versiebeheerde optimalisatiepijplijn van onderzoeksmodel tot veld-geïmplementeerde inferentie.

De kloof tussen training en inferentie

Het typische onderzoeksmodel bestaat als een PyTorch state dict (`.pt`-bestand) of TensorFlow SavedModel — een verzameling geleerde gewichten en een berekeningsgrafikdefinitie die afhankelijk is van de runtime van het trainingsframework voor uitvoering. De runtime van het trainingsframework is ontworpen voor flexibiliteit (dynamische berekeningsgrafieken, autograd, gradientcontrolepunten) in plaats van prestaties. Een onderzoeksmodel in PyTorch uitvoeren op een NVIDIA Jetson Orin NX zonder optimalisatie levert inferentie op van ongeveer 8–15 fps voor een middelgroot detectiemodel — dramatisch onder het 30 fps-doel voor realtime videoanalyse.

Drie oorzaken van deze kloof: Geheugenoverhead. Trainingscontrolepunten bevatten optimizerstatus, gradientbuffers en per-laag batchnormalisatiestatistieken die niet nodig zijn voor inferentie. Een YOLOv8-medium trainingscontrolepunt is ongeveer 850 MB; de inferentie-alleen modelgewichten zijn ongeveer 50 MB. Rekenoverhead. Dynamisch geëvalueerde uitvoeringsgrafieken kunnen niet vooraf worden gecompileerd tot statische hardware-geoptimaliseerde uitvoeringsplannen. Precisiemismatch. Training gebruikt FP32 of FP16 voor numerieke precisie; edge-hardware bereikt maximale doorvoer met INT8, maar converteren naar INT8 vereist kalibratie om geschikte kwantisatieschalen te bepalen.

ONNX als universele uitwisselingsformaat: export vanuit PyTorch

ONNX definieert een standaard grafiekgebaseerde representatie van neurale netwerkarchitecturen, onafhankelijk van een bepaald trainingsframework. Het exporteren van een getraind PyTorch-model naar ONNX produceert een `.onnx`-bestand met de volledige inferentieberekeningsgrafiek — alle lagen, hun verbindingen en de geleerde gewichten — in een formaat dat elke ONNX-compatibele runtime kan uitvoeren.

De PyTorch ONNX-exportfunctie (`torch.onnx.export`) tracert de berekeningsgrafiek van het model door het uit te voeren met voorbeeldinvoertensors en de resulterende bewerkingen op te nemen. De primaire exportparameters zijn:

opset_version: De ONNX-operatorsetversie. Hogere versies ondersteunen meer operatortypes; TensorRT 8.x ondersteunt tot opset 17. Gebruik opset 16 of 17 voor maximale operatordekking met huidige TensorRT-versies.

dynamic_axes: Geeft aan welke tensordimensies als variabele lengte (dynamisch) moeten worden behandeld in plaats van vast. Voor een detectiemodel dat videoframes verwerkt, moet de batchdimensie dynamisch zijn om zowel realtime inferentie met één frame (batch=1) als batchverwerking met meerdere frames te ondersteunen. Het instellen van dynamische batchgrootte vergroot de algemeenheid van het ONNX-model maar kan sommige TensorRT-optimalisaties voorkomen die vaste vormen vereisen.

Veelvoorkomende exportvalkuilen. Niet alle PyTorch-bewerkingen hebben directe ONNX-equivalenten. Aangepaste autograd-functies, Python-besturingsstroom binnen modelforwardmethoden (if/else-takken die afhangen van tensorwaarden) en bewerkingen die in recente PyTorch-versies zijn toegevoegd maar nog niet in de ONNX-operatorset, kunnen exportfouten of onjuiste geëxporteerde grafieken veroorzaken. YOLOv8's detectiehoofd niet-maximum-onderdrukking is het meest voorkomende probleemgebied — Ultralytics biedt exportconfiguratievlaggen om ONNX-compatibele NMS-implementaties te gebruiken. Valideer het geëxporteerde ONNX-model altijd tegen het originele PyTorch-model op een representatieve testset voordat u doorgaat naar TensorRT-compilatie.

TensorRT-compilatie: INT8-kalibratie, laagfusie, kernelautomatisch afstemmen

TensorRT neemt een ONNX-model als invoer en produceert een TensorRT-engine-bestand (`.trt` of `.engine`) dat is geoptimaliseerd voor een specifieke doel-GPU-architectuur. Het compilatieproces heeft drie fasen:

Netwerkparsing en validatie. De ONNX-parser van TensorRT leest de ONNX-grafiek en valideert dat alle operatoren worden ondersteund. Niet-ondersteunde operatoren moeten worden geïmplementeerd als aangepaste TensorRT-plugins voordat compilatie kan beginnen. Voor standaard CNN-architecturen (YOLO-varianten, ResNet, MobileNet, EfficientDet) worden alle operatoren native ondersteund in TensorRT 8.x.

Optimalisatiepassen. TensorRT past een reeks optimalisaties op grafiekniveau toe: laagfusie (conv+BN+ReLU combineren tot één bewerking), tensorindelingsoptimalisatie (kiezen van NCHW vs NHWC geheugenindeling op basis van wat sneller is voor elke laag op de doel-GPU) en operatorvervanging (bepaalde bewerkingsreeksen vervangen door equivalente maar snellere alternatieven beschikbaar als voorgebouwde CUDA-kernels).

Precisiekalibratie en engine-compilatie. Voor INT8-compilatie voert TensorRT een kalibratieproces uit: het model wordt uitgevoerd op een representatieve kalibratiegegevensset (typisch 500–1.000 afbeeldingen), de dynamische reikwijdte van activeringen per laag wordt gemeten en optimale kwantisatieschaalfactoren worden bepaald. De kwaliteit van de kalibratigegevens bepaalt direct de INT8-nauwkeurigheid — gebruik domeinafgestemde beeldvorming die overeenkomt met uw inzetsensoorttype en doelklassen.

Na kalibratie evalueert TensorRT meerdere CUDA-kernelimplementaties voor elke laag op het doelapparaat en selecteert de snelste. Deze stap van automatisch afstemmen kan 30–90 minuten duren voor een groot model maar wordt slechts eenmaal uitgevoerd — het resulterende engine-bestand wordt geserialiseerd en kan direct worden geïnstalleerd op het doelapparaat zonder hercompilatie. Engine-bestanden zijn apparaatarchitectuurspecifiek: een engine gecompileerd op één Jetson SKU (bijv. Orin NX) werkt niet correct op een andere SKU (bijv. AGX Orin) vanwege verschillende GPU-kernaantallen.

Latentie vs doorvoer: batchgrootte 1 voor realtime inferentie

Het optimalisatiedoel van TensorRT kan worden geconfigureerd voor minimale latentie of maximale doorvoer. Voor realtime videoanalyse — waarbij elk frame moet worden verwerkt en resultaten moeten worden geleverd vóór het volgende frame arriveert — is minimale latentie bij batchgrootte 1 het juiste optimalisatiedoel. Voor offline batchverwerking van opgeslagen beeldvorming vermindert maximale doorvoer bij een grotere batchgrootte (8–32) de verwerkingstijd per frame ten koste van toegenomen latentie per batch.

Bij batchgrootte 1 draait YOLOv8-medium gecompileerd naar INT8 op Jetson AGX Orin op ongeveer 1,8 ms latentie (theoretisch maximum van 555 fps). Bij batchgrootte 8 neemt de latentie toe tot ongeveer 7 ms per batch (8 × 0,875 ms per frame) maar bereikt een ongeveer 15% hogere GPU-gebruiksefficiëntie. Voor een 30 fps invoerstroom biedt batchgrootte 1 met een verwerkingslatentie van 1,8 ms aanzienlijke marge voor multi-model pijplijnen. Voor een viercamerasysteem elk op 30 fps maakt batchgrootte 4 gelijktijdige verwerking van één frame van elke camerastream mogelijk in ongeveer 5 ms — een praktische architectuur voor multi-sensorplatforms.

Modelversionering en updatepijplijn voor veldapparaten

Een geïmplementeerd edge-AI-systeem vereist een onderhoudbare modelupdatepijplijn. Modellen verbeteren door aanvullende trainingsdata, architecturale verfijningen of aanpassing aan nieuwe operationele omgevingen (winter vs zomerterein, nieuwe doelklassen). Veld-geïmplementeerde apparaten moeten deze updates betrouwbaar ontvangen zonder fysiek herstel van de hardware te vereisen.

De updatepijplijn voor TensorRT-geïmplementeerde modellen verschilt van standaardsoftware-updates in één kritiek opzicht: TensorRT-compilatie moet worden uitgevoerd op het doelapparaat (of een identiek apparaat) omdat het apparaatspecifieke kernelautomatisch afstemmen omvat. Een modelupdateworkflow kan als volgt verlopen: nieuw model getraind bij centrale faciliteit → geëxporteerd naar ONNX → ONNX-model via beveiligd updatekanaal naar apparaat gestuurd → TensorRT-compilatie on-device uitgevoerd (tijdens een onderhoudsvenster wanneer de AI-pijplijn is gepauzeerd) → gecompileerde engine geactiveerd → oude engine gearchiveerd voor rollback.

Elke ONNX-modelrelease moet een semantische versie-ID, een SHA-256-inhoudshash en een cryptografische handtekening van de modelherkomstautoriteit bevatten. De apparaatside updatehandler valideert de handtekening vóór compilatie. Het compilatielogboek en de resulterende engine-hash moeten worden gerapporteerd aan het vlootbeheersysteem om succesvolle update op alle apparaten in de vloot te bevestigen.