TensorRT allein reicht nicht: Was wir bei der Jetson-Optimierung für den Feldeinsatz gelernt haben

Gradion EdgeAI ·

Wer ein KI-Modell auf einem NVIDIA Jetson zum Laufen bringen will, bekommt schnell einen scheinbar einfachen Rat: Exportiere dein Modell nach TensorRT, und die Performance kommt von selbst. In der Praxis ist das bestenfalls der Anfang.

Wir haben für das ARGOS Verkehrserfassungssystem eine komplette Inference Pipeline auf dem Jetson NX aufgebaut — und dabei gelernt, dass echte Optimierung weit über die reine Modellkonvertierung hinausgeht.

Die Realität hinter der Benchmark-Zahl

Wenn Sie ein YOLO-Modell mit TensorRT int8 quantisieren und auf einem Jetson NX laufen lassen, bekommen Sie beeindruckende Zahlen. In der Theorie.

Die Realität im Feldeinsatz sieht anders aus: Ein Modell, das auf dem Schreibtisch flüssig läuft, kann im Produktionsbetrieb an der Gesamtpipeline scheitern — an der Kameraanbindung, am Tracker, an der Datenweiterleitung, am Zusammenspiel aller Komponenten unter Last.

Bei ARGOS war die Ausgangslage klar: 11 Fahrzeugklassen in Echtzeit erkennen, verfolgen und zählen. An Kreuzungen, auf mehrspurigen Straßen, bei Nacht und bei Regen. Die Anforderung: 15 FPS bei unter 200 Millisekunden End-to-End-Latenz — vom Kamerabild bis zum verarbeiteten Ergebnis. Über Wochen im unbeaufsichtigten Betrieb, auf hunderten autonomen Sensoreinheiten im Feld.

Hier zählt nicht der beste Benchmark, sondern die zuverlässigste Gesamtlösung.

Die Pipeline, nicht nur das Modell

Die erste Entscheidung war die Wahl des Inference Frameworks. Wir haben drei Optionen evaluiert:

  • Python/OpenCV: Zu langsam für Echtzeit auf dem Jetson NX
  • Google Mediapipe: Starkes Framework, aber nicht für Jetson-Hardware optimiert — die GPU-Beschleunigung greift dort nicht wie bei NVIDIAs eigenem Stack
  • NVIDIA Deepstream: Nutzt die Hardware-Beschleunigung des Jetson direkt über GStreamer-Plugins und integriert sich nahtlos mit TensorRT

Deepstream war die richtige Wahl. Für die Objekterkennung setzen wir YOLOv4 ein — über den DeepStream-YOLO Plugin, der das Modell direkt in die Deepstream Pipeline einbindet. Der entscheidende Vorteil: Ein einzelner Inference-Durchlauf liefert Detection und Classification gleichzeitig. Kein zweistufiges Verfahren, kein zusätzlicher Overhead.

Warum int8 — und warum der Tracker wichtiger ist, als man denkt

Bei der TensorRT-Optimierung haben wir bewusst int8 Quantisierung gewählt, nicht FP16. Der Grund: Auf dem Jetson NX mit seinen begrenzten Ressourcen war int8 die richtige Balance zwischen Inference-Geschwindigkeit und Erkennungsgenauigkeit.

FP16 hätte mehr Headroom bei der Präzision gelassen, aber der Performance-Gewinn von int8 war entscheidend, um die 15-FPS-Anforderung zuverlässig zu halten.

Der Tracker als kritische Komponente

Was viele unterschätzen: Der Tracker ist in einer Produktionspipeline mindestens so kritisch wie das Erkennungsmodell selbst.

Wir verwenden einen Tracking-by-Detection-Ansatz — das Modell erkennt Objekte in jedem Frame, der Tracker korreliert diese Erkennungen über aufeinanderfolgende Frames zu Trajektorien. Dafür haben wir einen eigenen Luenberger Observer entwickelt, einen Kalman-basierten Tracker, der speziell auf die Anforderungen im Verkehrsmonitoring abgestimmt ist.

Warum kein Standard-Tracker? In der Praxis hatten wir Stabilitätsprobleme mit gängigen Tracking-Algorithmen, insbesondere bei Verdeckungen an Kreuzungen und bei wechselnden Lichtverhältnissen.

Die Entkopplung macht den Unterschied

Ein Detail, das in Benchmark-Diskussionen nie auftaucht: Was passiert, wenn die nachgelagerte Verarbeitung langsamer ist als die Inference?

Bei ARGOS läuft die Inference Pipeline in C++/GStreamer, die Datenverarbeitung in Python. Zwischen beiden sitzt eine Redis Queue. Das bedeutet: Wenn der Data Collector langsam wird, ein Netzwerkproblem hat oder kurzzeitig ausfällt, läuft die Inference Pipeline ungestört weiter.

Diese Entkopplung war keine theoretische Architekturentscheidung — sie war die Antwort auf reale Probleme im Feldtest. Ohne Redis-Puffer hätte ein kurzer Netzwerk-Timeout die gesamte Pipeline blockiert.

Was kommt als Nächstes

Die Pipeline läuft: 15 FPS, unter 200 Millisekunden Latenz, hunderte Einheiten im Feld.

Aber Stillstand gibt es nicht. Für die nächste Generation planen wir:

  • Wechsel von YOLOv4 zu RT-DETR (Transformer-basiert)
  • Wechsel vom Luenberger Observer zu ByteTrack
  • Migration auf den Jetson Orin NX als neue Hardwareplattform

Fazit

Model-Optimierung für den Jetson ist kein einzelner Schritt, sondern ein Pipeline-Problem. TensorRT int8 ist ein wichtiger Baustein, aber ohne das richtige Framework, den passenden Tracker und eine robuste Entkopplung zwischen Inference und Datenverarbeitung bleibt die Performance auf dem Papier.

Wer Edge AI in Produktion bringen will, muss die gesamte Kette optimieren.

Über Gradion EdgeAI: Wir bringen Edge-AI-Produkte vom Prototyp in die Produktion — mit tiefem NVIDIA Jetson Know-how, produktionsgehärteter Architektur und der Zuverlässigkeit eines 600-Ingenieure-Unternehmens. Sprechen Sie mit uns über Ihr Projekt.

Sie haben ein Edge AI Projekt?

Lassen Sie uns besprechen, wie wir Ihr Projekt vom Prototyp in die Produktion bringen.

Projekt besprechen