Edge AI & Computer Vision
Engineering-AnsatzInferenz-Pipeline-Architektur auf einem eingeschränkten Edge-Gerät
INT8-Quantisierung · CUDA Graphs · DLA-Co-Execution · NVIDIA Jetson Orin NX
NVIDIA Jetson Orin NX 16GB · TensorRT 8.6 · JetPack 6
01Problem
Problem: Das Inferenzbudget auf einer SWaP-C-Plattform
Auf einem autonomen Luftsystem liefert die Standard-FP32-ONNX-Runtime nicht den Durchsatz, den Echtzeit-Detektion und -Tracking brauchen. Auf einer in Größe, Gewicht, Leistung und Kosten eingeschränkten Plattform ist Geschwindigkeit nicht das einzige Thema: Das Leistungsbudget begrenzt die Flugzeit unmittelbar. Die Zielmetrik ist deshalb nicht fps, sondern fps pro Watt.
- 01Zu geringer Inferenzdurchsatz führt bei schnell bewegten Objekten zu ausgelassenen Frames und Trackverlust
- 02FP32-Inferenz sättigt die GPU und lässt keinen Spielraum für gleichzeitige Bildvorverarbeitung
- 03Hohe Leistungsaufnahme drückt die Plattform unter die angestrebte Flugzeit
- 04Wird das Modell bei jedem Start aus ONNX neu übersetzt, verzögert das den Einsatz
- 05Bleiben CPU-GPU-Kopien und Kernel-Launch-Overhead ungemessen, ist der Engpass unbekannt
02Systemkontext
03Ursachenanalyse
- 01Das Modell lief in FP32, die INT8-Tensor-Cores und DLA-Kapazität des Orin NX lagen vollständig brach
- 02ONNX Runtime nutzte generische Ausführung; Layer-Fusion und Kernel-Auto-Tuning von TensorRT kamen nicht zum Einsatz
- 03Eine separate Kernel-Launch-Kette pro Frame erzeugte CPU-Overhead. GPU-Stalls waren im Profiling sichtbar
- 04Die Engine wurde bei jedem Start neu gebaut; Serialisierung wurde nicht genutzt
- 05Die gesamte Last lag auf der GPU, die DLA-Kerne blieben ungenutzt, Effizienzpotenzial wurde verschenkt
04Was wir geändert haben
INT8-Quantisierung mit repräsentativem Datensatz kalibriert anwenden
→ Tensor-Core- und DLA-Kapazität wird nutzbar; der Genauigkeitsverlust wird am Missionsdatensatz geprüft
TensorRT-Engine-Serialisierung aktivieren
→ Die Neuübersetzung beim Start entfällt, die Ladezeit wird vorhersagbar
Die Kernel-Launch-Kette pro Frame in einen einzigen CUDA-Graph zusammenfassen
→ Der CPU-Launch-Overhead sinkt, die GPU bleibt ausgelastet
DLA-Co-Execution: geeignete Schichten auf die DLA, der Rest auf die GPU
→ Dieselbe Arbeit läuft in einem kleineren Leistungsbudget, auf der GPU entsteht Spielraum
Vorverarbeitung auf die GPU verlagern (CUDA-Resize und -Normalisierung), CPU-GPU-Kopien reduzieren
→ Der Engpass wandert zum Modell selbst, der Ende-zu-Ende-Durchsatz wird haltbar
05Benchmark-Ergebnisse
06Warum es wichtig war
fps allein sagt nichts; auf einer SWaP-C-Plattform ist die sinnvolle Metrik fps pro Watt. Längere Missionsdauer und mehr gleichzeitige Wahrnehmungsaufgaben mit derselben Batterie folgen beide aus diesem Verhältnis.
- 01Echtzeit-Mehrobjekterkennung und -verfolgung wird auf einem einzigen Gerät möglich
- 02Geringere Leistungsaufnahme verlängert Batterielaufzeit und Missionsdauer unmittelbar
- 03Frei gewordene GPU-Kapazität steht für weitere Wahrnehmungsaufgaben wie Sensorfusion zur Verfügung
- 04Der INT8-Kalibrierungs- und Validierungsablauf entsteht als wiederverwendbare Pipeline; Modellupdates nehmen denselben Weg
Um Ihren Bedarf an Edge AI & Computer Vision auf Ihrer eigenen Plattform zu bewerten, planen Sie ein Embedded-Architektur-Audit oder bestimmen Sie Ihre Plattformklasse mit dem System-Anforderungsrechner.
Methodologiehinweis
- fps wird über die gesamte Pipeline (Aufnahme, Detektion, Ausgabe) berichtet, nicht als isolierter Modell-Benchmark
- Die Leistung wird mit externer Messtechnik unter Dauerlast nach thermischem Einschwingen erfasst
- Der INT8-Genauigkeitsverlust wird gegen die FP32-Referenz auf einem missionsrepräsentativen Validierungssatz gemessen
- Vergleiche erfolgen auf identischer Hardware, identischem Eingangsstrom und identischem Power-Modus
- Diese Seite beschreibt eine Methode. Wird eine Messung veröffentlicht, stehen Aufbau und Methode neben der Zahl
Verfehlt Ihre Edge-AI-Pipeline ihr fps- oder Leistungsbudget?
Kostenlose technische Bewertung, gemeinsam analysieren wir Latenz- und Determinismusprobleme in Ihrem System.
Diese Seite beschreibt eine Methode, keinen Messbericht. Spikedge veröffentlicht nur Messungen vom eigenen Prüfstand, deren Aufbau offengelegt werden kann; sobald eine veröffentlichungsfähige Messung zu diesem Thema vorliegt, wird sie hier ergänzt.