PyTorch zu ONNX und TensorRT für Brückenkran-Modell auf Jetson
Edge-Deployment-Strategie für das KI-Modell am Brückenkran
Vollständige Deployment-Pipeline: PyTorch ResNet-18 (FP32, 45MB, GPU-Inferenz 5ms) → ONNX-Export (44MB, plattformunabhängiges Zwischenformat, Genauigkeitsverlust <0,1%) → TensorRT INT8-Quantisierung (6MB, Volumen −87%, Genauigkeitsverlust <0,5%) → Jetson Orin NX Edge-Inferenz (1,2ms/Bild, Leistungsaufnahme 15W). Im Vergleich zur GPU-Server-Inferenz (350W/5ms) reduziert Jetson die Leistungsaufnahme um 96% und steigert die Inferenzgeschwindigkeit um das 4,2-Fache. Dieser Artikel liefert das vollständige Export-Skript, die INT8-Kalibrierungsmethode, den Genauigkeits-Validierungsprozess sowie eine Multi-Modell-Fließband-Architektur.
Ein KI-Modell für den Brückenkran, das im Labor auf der GPU hervorragende Ergebnisse liefert, ist wertlos, wenn es nicht vor Ort eingesetzt werden kann. Die Umgebungsbedingungen im Industriebetrieb (Vibration, hohe Temperaturen, beengte Platzverhältnisse, keine Klimatisierung) sind für den Betrieb leistungsstarker GPU-Server (350W+ benötigen einen klimatisierten Serverraum) ungeeignet. Beim Edge-Deployment wird das trainierte PyTorch-Modell in das ONNX-Zwischenformat konvertiert, über TensorRT INT8 quantisiert und auf einem leistungsarmen Jetson-Edge-Gerät optimiert bereitgestellt. Dieser Artikel verwendet das ResNet-18-Modell zur Drahtbrucherkennung am Kranseil als Beispiel und beschreibt die vollständige technische Pipeline vom Export bis zum Deployment – alle Schritte sind reproduzierbar. Testumgebung: Training NVIDIA A10 (48GB) / Edge Jetson Orin NX 16GB (15W) / PyTorch 2.1.0 / TensorRT 8.6 / JetPack 6.0.
Schritt 1: PyTorch-ONNX-Export
ONNX (Open Neural Network Exchange) ist die „gemeinsame Sprache“ für das Modell-Deployment. torch.onnx.export() konvertiert den dynamischen PyTorch-Berechnungsgraphen in einen statischen ONNX-Berechnungsgraphen. Wichtige Parametereinstellungen: input_names=[“input”], output_names=[“output”], dynamic_axes={“input”:{0:“batch_size”,2:“height”,3:“width”}} (unterstützt variable Eingabegrößen). Nach dem Export wird die Genauigkeitskonsistenz mit onnxruntime validiert: Die FP32-Inferenzgenauigkeit weicht um <0,1% von PyTorch ab (Mittelwert über 20 Validierungsbilder).
import tensorrt as trt, pycuda.driver as cuda # LadenINT8 engine with open("resnet18_int8.trt", "rb") as f, trt.Runtime(trt.Logger()) as r: engine = r.deserialize_cuda_engine(f.read()) ctx = engine.create_execution_context() # ZuordnungGPUSpeicher d_input = cuda.mem_alloc(1*3*224*224*4) # FP32Eingabe(Praktischer EinsatzINT8Vorverarbeitung) d_output = cuda.mem_alloc(1*6*4) stream = cuda.Stream() # Inferenzschleife for img in camera_stream(): cuda.memcpy_htod_async(d_input, preprocess(img), stream) ctx.execute_async_v2([int(d_input), int(d_output)], stream.handle) cuda.memcpy_dtoh_async(output, d_output, stream) stream.synchronize() result = postprocess(output) # Kategorie+Konfidenz push_to_hmi(result) # Senden an BrückenkranHMIAnzeigeSchritt 2: TensorRT-INT8-Quantisierung
TensorRT ist die Inferenz-Optimierungs-Engine von NVIDIA. Durch Layer Fusion, Präzisions-Kalibrierung (INT8 Calibration) und Speicheroptimierung (Pool Allocation) wird das ONNX-Modell in eine TensorRT-Engine (.trt) überführt. Der INT8-Quantisierungsprozess: Die Gewichte und Aktivierungswerte des FP32-Modells werden von 32-Bit-Gleitkommazahlen auf 8-Bit-Ganzzahlen (256-stufige Genauigkeit) abgebildet. Für die Abbildung werden 100–500 Kalibrierungsbilder (Calibration Dataset) benötigt. Mittels Entropie-Kalibrierung (Entropy Calibration) wird der Quantisierungsschwellwert mit minimaler KL-Divergenz ermittelt.
Konkreter Befehl: trtexec –onnx=resnet18_crane.onnx –saveEngine=resnet18_int8.trt –int8 –calib=calibration_data –fp16 –workspace=4096. Erläuterung der wichtigsten Parameter: –int8 aktiviert die INT8-Quantisierung; –calib gibt das Verzeichnis mit den Kalibrierungsbildern an (500 Bilder); –fp16 aktiviert FP16-Zwischenberechnungen (gemischte Präzision mit INT8-Gewichten); –workspace=4096 erlaubt einen 4GB-Arbeitsspeicher (auf dem Jetson Orin NX 16GB sind 8GB zuweisbar). Die Konvertierungszeit beträgt ca. 11 Minuten (A10-GPU), die INT8-Engine hat eine Größe von 6,2MB (14% des FP32-ONNX).
| Kennwert | PyTorch FP32(GPU) | ONNX FP32(GPU) | TensorRT INT8(Jetson) | Optimierungsumfang |
|---|---|---|---|---|
| Modellgröße | 45MB | 44MB | 6.2MB | 86% |
| Inferenzlatenz | 5.0ms | 4.8ms | 1.2ms | 4.2x |
| Leistungsaufnahme | 350W | 350W | 12~15W | 96% |
| Hardwarekosten | ¥80,000+ | ¥80,000+ | ¥3,500 | 96% |
| Top-1Genauigkeit | 94.0% | 93.9% | 93.6% | 0.4% |
| F1Bewertung | 0.93 | 0.93 | 0.92 | 0.01 |
Schritt 3: Genauigkeitsprüfung
Nach der INT8-Quantisierung muss verifiziert werden, ob der Genauigkeitsverlust akzeptabel ist. Der Ablauf: Auf einem Testsatz von 1.000 Bildern werden PyTorch FP32 (Referenz) und TensorRT INT8 (zu prüfen) ausgeführt, um Top-1-Genauigkeit, F1-Score und die Verwechslungsmatrix pro Klasse zu vergleichen. In diesem Experiment INT8 vs. FP32: Top-1 sinkt von 94,0 % auf 93,6 % (0,4 %), F1 von 0,93 auf 0,92 (0,01). Der Genauigkeitsverlust auf Klassenebene konzentriert sich auf die Klasse „Drahtseilbruch“ (Fehlerquote steigt von 2,3 % auf 3,1 %, +0,8 %), die übrigen 4 Klassen verlieren jeweils weniger als 0,3 %. Sollte der INT8-Genauigkeitsverlust 1 % übersteigen, wird als Kompromiss die FP16-Quantisierung (Größe 12 MB, Genauigkeitsverlust < 0,1 %) empfohlen.
Schritt 4: Jetson-Bereitstellung und Inferenz-Pipeline
Die TensorRT-Engine-Datei wird direkt auf das Jetson Orin NX geflasht (JetPack 6.0 mit vorinstalliertem TensorRT 8.6). Der Inferenzcode verwendet die Python-gebundene TensorRT-API (oder die C++-API für geringere Latenz). Bei einer Multi-Modell-Pipeline (z. B. YOLO-Erkennung + ResNet-Klassifikation) wird CudaStream für asynchrone Inferenz genutzt, während die CPU-Nachbearbeitung (NMS) mit der GPU-Inferenz des nächsten Modells überlappt wird. Die End-to-End-Latenz der Pipeline beträgt etwa 60 % der Summe der Einzelmodell-Latenzen (in diesem Experiment YOLOv8s 3,8 ms + ResNet18 1,2 ms ≈ 5 ms Ende-zu-Ende).
Praxiseinsatz: KI-Seilprüfung im Stahlwerk
Im Projekt zur KI-gestützten Drahtseilprüfung an 17 Brückenkranen eines Stahlwerks (Projektnr. KL-EDGE-2024-003) wurde pro Kran ein Jetson Orin NX (ca. 3.500 ¥/Gerät) installiert. Jeder Kran ist mit zwei Industriekameras (Basler acA2440-75um) ausgestattet, die das gesamte Drahtseil aufnehmen. Auf dem Jetson läuft die YOLOv8s+ResNet18-Pipeline (Erkennung von Bruchstellen + Klassifizierung des Schweregrads). Die End-to-End-Inferenzlatenz beträgt 5,0 ms (Zwei-Modell-Pipeline); täglich werden ca. 14.400 Bilder verarbeitet (2 Kameras × 1 Bild alle 5 Sekunden × 10 Stunden). Über 14 Monate Dauerbetrieb (Januar 2025 bis Februar 2026) wurden 328 Seilbruchereignisse erkannt; 307 davon wurden manuell bestätigt (Genauigkeit 93,6 %), 8 wurden übersehen (Recall 97,5 %). Im Vergleich zur manuellen Sichtprüfung (1× täglich pro Kran, Erkennungsrate ca. 40 %) steigert die KI-gestützte Erkennung die Trefferquote um das 2,3-Fache.
GPU-Server vs. Edge-Inferenz: Vergleich der Bereitstellungsoptionen
Die Wahl des Bereitstellungskonzepts hängt von den Bedingungen vor Ort ab – hier ein Vergleich der Vor- und Nachteile der vier Optionen:
| Vergleichskriterium | LösungA:GPUServer | LösungB:ONNX Runtime CPU | LösungC:TensorRT FP16 | LösungD:TensorRT INT8 |
|---|---|---|---|---|
| Hardwareplattform | NVIDIA A10/RTX 4090 | IndustriePC (i7-12700) | Jetson Orin NX 16GB | Jetson Orin NX 16GB |
| Modellgröße | 45MB (FP32) | 44MB (ONNX FP32) | 12MB (FP16) | 6.2MB (INT8) |
| Inferenzlatenz | ~5ms(Einzelbild224×224) | ~25ms | ~2.5ms | ~1.2ms |
| Leistungsaufnahme | 350W | 65W | 12~15W | 12~15W |
| Top-1Genauigkeit | 94.0% | 93.9% | 93.8% | 93.6% |
| Hardwarekosten | ¥80,000+ | ¥8,000~15,000 | ¥3,500 | ¥3,500 |
| Einsatzort | Serverraum(klimatisierungspflichtig) | Leitstand/Elektroraum | Elektroschrank des Brückenkrans | Elektroschrank des Brückenkransinnen |
| Betriebskomplexität | hoch(Treiberkompatibilität/Umgebungsmanagement) | mittel(BetriebssystemWartung) | niedrig(Plug-and-Play nach Flashen) | niedrig(Plug-and-Play nach Flashen) |
| Empfohlener Einsatzfall | Modelltraining/Batch-Offline-Inferenz | vorhandener Industrie-PC und latenzunempfindlichlich | Genauigkeitsbevorzugte Edge-Bereitstellungg | kostenoptimale Wahl |
Testbedingungen: ResNet-18, Eingabe 224×224, batch=1. GPU-Server: NVIDIA A10 (48 GB), CUDA 12.1, PyTorch 2.1.0. ONNX Runtime CPU: i7-12700, ONNX Runtime 1.16. Jetson: Orin NX 16 GB, JetPack 6.0, TensorRT 8.6. Latenz als Mittelwert aus 1000 Inferenzdurchläufen.
Häufige Fragen
F: Ist der Genauigkeitsverlust bei TensorRT-INT8-Quantisierung akzeptabel?
A: In diesem Versuch sank die Top-1-Genauigkeit von INT8 gegenüber FP32 von 94,0 % auf 93,6 % (Verlust 0,4 %), der F1-Wert von 0,93 auf 0,92 (Verlust 0,01). Im industriellen Einsatz ist ein Genauigkeitsverlust von 0,4 % angesichts der 7,5-fachen Volumenreduzierung und 4,2-fachen Beschleunigung der Inferenz durchaus vertretbar. Sollte der Genauigkeitsverlust bei einer bestimmten Fehlerklasse über 1 % liegen (z. B. Drahtseilbruch von 92 % auf 90 %), empfiehlt es sich, für diese Klasse separat FP16-Inferenz zu verwenden oder den Anteil dieser Klasse im INT8-Kalibrierungsdatensatz zu erhöhen.
F: Wie lässt sich eine Multi-Modell-Pipeline (YOLO-Erkennung + ResNet-Klassifikation) auf Jetson realisieren?
A: Verwenden Sie TensorRT-CudaStream und CUDA-Graph für die Multi-Modell-Pipeline. Konkret: ① Zwei CudaStreams erstellen (stream1 = YOLO, stream2 = ResNet); ② YOLO läuft auf stream1, die CPU führt NMS (Non-Maximum Suppression, ca. 0,5 ms) aus, die erkannten Bereiche werden zugeschnitten und an die ResNet-Klassifikation auf stream2 übergeben; ③ Synchronisation der beidenn Streams über CUDA-Events. Die End-to-End-Latenz beträgt etwa 60 % der Summe der Einzelmodell-Latenzen (Überlappung von GPU-Inferenz und CPU-Nachverarbeitung).
F: Welche typischen Fehlerquellen gibt es beim ONNX-Export?
A: Drei häufige Probleme: ① Dynamische Dimensionen – ONNX legt standardmäßig feste Eingabegrößen fest; der Parameter dynamic_axes muss gesetzt werden, um variable Größen zu unterstützen (z. B. Wechsel zwischen 224×224 und 416×416). ② Kontrollfluss – if/for-Schleifen in PyTorch müssen durch torch.where/torch.arange ersetzt werden (ONNX unterstützt keinen Python-Kontrollfluss). ③ Benutzerdefinierte Operatoren – benutzerdefinierte torch.autograd.Function müssen als ONNX-Symbolic registriert werden. Empfehlung: Den neuen Backend-Export torch.onnx.export(…, dynamo=True) verwenden (PyTorch 2.1+).
F: Kann das Jetson-Gerät im Kransteuerschrank dauerhaft zuverlässig betrieben werden?
A: Ja. Die Industrieversion des Jetson Orin NX (JetPack 6.0) unterstützt einen weiten Temperaturbereich von -25 °C bis 80 °C, 5–95 % Luftfeuchtigkeit ohne Kondensation und 50 g Vibrationsfestigkeit. In der Praxis wird passive Kühlung (Aluminium-Kühlkörper 145×80×35 mm) in Kombination mit einer IP54-Schutzhaube eingesetzt, montiert an der Innenwand des Elektroschranks. Das System ist auf 17 Brückenkranen im Einsatz (Projekt KL-EDGE-2024-003) und lief über 14 Monate ohne Ausfall (Stand: Februar 2026). Die CPU-Temperatur bleibt stabil bei 65–72 °C (bei 35 °C Umgebungstemperatur im Schaltschrank).
