YOLO- und Vision-Modelle produktiv bereitstellen: Triton, ONNX Runtime, TensorRT

Drei Ebenen eines Serving-Stacks

Um ein trainiertes Detektions- oder Klassifikationsmodell produktiv bereitzustellen, exportieren die meisten Teams es aus PyTorch nach ONNX, kompilieren es zu einer TensorRT-Engine für die GPU, auf der es laufen wird, und setzen den Triton Inference Server davor, der Anfragen vieler Kameras oder Anwendungen zu Batches bündelt. ONNX Runtime passt, wenn dieselbe Modelldatei auch auf CPUs laufen soll oder TensorRT nicht jede Schicht des Modells unterstützt. TorchServe, das Serving-Projekt von PyTorch, ist archiviert und erhält keine Sicherheitskorrekturen mehr.

Die drei Namen werden oft verglichen, als wären sie Alternativen. Sie liegen auf verschiedenen Ebenen. TensorRT ist NVIDIAs Compiler und Laufzeit: Es macht aus einem ONNX-Graphen eine Engine, optimiert für eine GPU und eine Genauigkeit. ONNX Runtime führt ONNX-Graphen über Execution Provider aus, darunter einen CUDA- und einen TensorRT-Provider. Triton ist ein Server: Er lädt Modelle aus einem Repository, bietet Endpunkte über HTTP/REST und gRPC, bündelt Anfragen zu Batches und liefert Metriken; zu seinen Backends gehören TensorRT, ONNX Runtime, PyTorch, OpenVINO und Python.

Dieser Beitrag behandelt Vision-Modelle, die keine Sprachmodelle sind: YOLO-Detektoren, Segmentierungsnetze, Klassifikatoren und Transformer wie RT-DETR. Das Serving von LLMs mit vLLM, SGLang und TensorRT-LLM vergleicht unser Beitrag zu vLLM, SGLang, TensorRT-LLM und Ollama, Kamera-Pipelines mit Hardware-Decodierung unser Leitfaden zum GPU-Server für Videoanalyse.

Unsere Zusammenfassung der Dokumentation von NVIDIA zu Triton und TensorRT, der ONNX-Runtime-Dokumentation und der TorchServe-Dokumentation, gelesen am 25. Oktober 2026.

TorchServe ist archiviert: was das für einen laufenden Dienst heißt

Die TorchServe-Dokumentation trägt den Hinweis „Limited Maintenance: This project is no longer actively maintained.“ Weiter heißt es: „While existing releases remain available, there are no planned updates, bug fixes, new features, or security patches. Users should be aware that vulnerabilities may not be addressed.“ Das GitHub-Repository wurde am 7. August 2025 vom Eigentümer archiviert und ist nur noch lesbar.

Ein Dienst, der heute läuft, funktioniert weiter. Das Risiko wächst mit der Zeit: Eine Schwachstelle im Server oder in einer seiner Abhängigkeiten bleibt offen, und neuere PyTorch- und CUDA-Versionen werden nicht mehr dagegen getestet. Für ein Modell im internen Netz ist das eine geplante Migration, für ein Modell, das aus Produktionsnetzen erreichbar ist, ein Sicherheitsthema. Das Modell selbst zieht meist ohne neues Training um: Der PyTorch-Checkpoint wird nach ONNX oder TorchScript exportiert und von Triton bereitgestellt, das für beide Formate Backends hat.

ONNX Runtime: eine Modelldatei, mehrere Execution Provider

ONNX Runtime lädt eine ONNX-Datei und weist jeden Teil des Graphen einem Execution Provider zu. Das ONNX-Runtime-Backend von Triton dokumentiert: „When GPU is enabled for ORT, CUDA execution provider is enabled“; ist TensorRT eingeschaltet, führt der CUDA-Provider die Knoten aus, die TensorRT nicht kann. Den TensorRT-Provider schaltet die Modellkonfiguration ein, mit Schlüsseln wie precision_mode auf FP16 und trt_engine_cache_enable; ohne sie gilt FP32 als Genauigkeit und 1 GB als Workspace.

Zwei Punkte aus der ONNX-Runtime-Dokumentation sind im Betrieb wichtig. „The first run (warmup) can be very long because building engine involves exhaustive profiling“: Ein Container, der ohne zwischengespeicherte Engine startet, antwortet also spät. Dieselbe Seite schreibt, dass ONNX Runtime mit TensorRT „delivers better inferencing performance on the same hardware compared to generic GPU acceleration“. Und zwischengespeicherte Engines „are not portable and optimized for specific Nvidia hardware“: Die Dokumentation verlangt, alte Engine- und Profildateien zu löschen, wenn sich Hardware, Modell, ONNX-Runtime-Version oder TensorRT-Version ändern. Legen Sie den Engine-Cache je GPU-Typ auf lokalen Speicher.

Die Versionen ändern sich schnell. Triton-Release 26.09 enthält ONNX Runtime 1.28.0, und die Release-Seite des Projekts nannte am 25. Oktober 2026 Version 1.29.0 als neueste, mit NVFP4-Arbeiten für Compute Capability 12.0 (SM120) in den Hinweisen. Die Anforderungstabelle auf der Seite des TensorRT-Providers nennt CUDA- und TensorRT-Versionen je ONNX-Runtime-Release; prüfen Sie sie für den Build, den Sie einsetzen.

TensorRT-Engines gelten für eine GPU und eine Version

NVIDIAs TensorRT-Dokumentation sagt es deutlich: „By default, TensorRT engines are compatible only with the version of TensorRT used to build them“ und „only compatible with the type of device where they were built“. TensorRT speichert die Compute Capability im Plan, und „If they do not match, the plan will fail to deserialize.“ Der Leitfaden zum Model Repository von Triton ergänzt, dass ein TensorRT-Plan an die CUDA Compute Capability einer GPU gebunden ist, und bietet die Eigenschaft cc_model_filenames, um je Capability einen eigenen Plan im selben Modellverzeichnis zu halten.

NVIDIA-Seite CUDA GPUs (Compute Capability; die H200 NVL ist nicht getrennt von der H200 aufgeführt) und NVIDIA-Produktseiten, gelesen am 25. Oktober 2026.

Eine Flotte, die L4-Karten in Edge-Servern mit RTX PRO 4500 Server Edition im Rechenzentrum mischt, braucht also zwei Engines je Modell. TensorRT bietet zwei Wege, das zu lockern. Eine hardwarekompatible Engine mit der Stufe AMPERE_PLUS läuft auf Ampere und neueren GPUs, SAME_COMPUTE_CAPABILITY auf GPUs derselben Capability; NVIDIA warnt, eine solche Engine „can have lower throughput and/or higher latency“, und die Stufe für dieselbe Capability sei in der Regel schneller als AMPERE_PLUS. Eine versionskompatible Engine läuft auf späteren TensorRT-Releases, packt eine Kopie der Laufzeit in jeden Plan und „can be slower“; NVIDIA rät: „you should only deserialize trusted plans this way“. Mit TensorRT 11 gebaute Engines laufen nicht auf einer Laufzeit von TensorRT 10.

Ultralytics, dessen YOLO-Modelle der übliche Ausgangspunkt sind, schreibt dasselbe zum Export mit format="engine": „TensorRT engines are hardware- and runtime-specific“, und eine .engine-Datei sei kein portables Modellformat. Für INT8 nennt Ultralytics es entscheidend, dass der Export auf dem Gerät läuft, das die Engine nutzen wird, mit einem Kalibrierdatensatz. In der Praxis ist die ONNX-Datei das versionierte Artefakt, Engines entstehen in der Deployment-Pipeline, auf der Zielkarte und mit der TensorRT-Version des Serving-Containers. Wir liefern die L4 und die RTX PRO Server Editions für solche gemischten Flotten; schreiben Sie uns, welche Karten an Ihren Standorten laufen, und wir antworten mit den Kartentypen und der Zahl der Engines, die Ihre Modelle brauchen.

Triton mit Dynamic Batching für Vision-Modelle: Repository, Batches, Instanzen

Triton lädt Modelle aus einem Repository mit einem Verzeichnis je Modell, einer config.pbtxt und mindestens einem nummerierten Versionsverzeichnis. Ein TensorRT-Plan heißt standardmäßig model.plan, eine ONNX-Datei model.onnx, eine TorchScript-Datei model.pt und ein Python-Modell model.py. Für die meisten TensorRT- und ONNX-Modelle leitet Triton die Konfiguration selbst ab, solange es nicht mit --disable-auto-complete-config startet. Der Triton-Leitfaden von Ultralytics baut ein solches Repository aus einem YOLO-Modell, das mit dynamic=True nach ONNX exportiert wurde, startet das Container-Image nvcr.io/nvidia/tritonserver:26.02-py3 und ruft es aus Python mit YOLO("http://127.0.0.1:8000/yolo", task="detect") auf.

Dynamic Batching ist der Hauptgrund, Triton vor ein Vision-Modell zu setzen. Der Dynamic Batcher „allows inference requests to be combined by the server, so that a batch is created dynamically“, und dynamic_batching { } in der Konfiguration schaltet ihn mit Standardwerten ein, die „will create batches as large as possible up to the maximum batch size“. Mit max_queue_delay_microseconds wartet der Server kurz auf weitere Anfragen. NVIDIAs Vorgehen: maximale Batchgröße festlegen, den Batcher mit Standardwerten einschalten, Latenz und Durchsatz mit dem Perf Analyzer messen und dann Batchgröße oder Wartezeit erhöhen, bis das Latenzbudget erreicht ist; bevorzugte Batchgrößen „should not be used for most models“.

Instanzen legen fest, wie viele Kopien eines Modells je Karte laufen. „By default, a single execution instance of the model is created for each GPU available in the system“, und instance_group mit count: 2 setzt zwei auf jede GPU. Ensembles verketten Modelle im Server: „An ensemble model represents a pipeline of one or more models“, etwa eine Bildvorverarbeitung, danach ein Detektor und ein Klassifikator, und jedes Mitgliedsmodell skaliert für sich. Die Triton-Dokumentation nennt Business Logic Scripting (BLS) als zweiten Weg zu Pipelines, mit der Logik in einem Python-Modell. Ist ein Model Warmup konfiguriert, meldet Triton ein Modell erst nach dem Warmup als bereit, was zu Load Balancern mit Readiness-Prüfung passt.

NVIDIA Triton Inference Server Release Notes, Release 26.09, Seite zuletzt aktualisiert am 1. Oktober 2026, gelesen am 25. Oktober 2026. Das Release unterstützt Compute Capability 7.5 und höher (Turing bis Blackwell).

Die TensorRT-Dokumentation stand am selben Tag bei 11.4.0, ein Minor-Release vor dem Container. Eine mit einem eigenständigen TensorRT 11.4 gebaute Engine lädt Triton 26.09 deshalb nicht; bauen Sie sie im selben Container-Image oder mit der TensorRT-Version, die der Container nennt.

Veröffentlichte Durchsätze auf den Karten, die wir liefern

Veröffentlichte Zahlen für Vision-Modelle auf Serverkarten sind selten, und nur wenige nutzen dasselbe Modell auf mehreren Karten. NVIDIAs Performance-Seite zu DeepStream 9.2 misst ganze Video-Pipelines, „end-to-end performance of the entire video analytic application“, mit abgeschaltetem Rendering der Ausgabe, und führt die Modelle über TensorRT aus. Die RT-DETR-Zeilen kommen einem reinen Detektor-Dienst am nächsten; unser Leitfaden zur Videoanalyse rechnet dieselbe Tabelle in Kamerazahlen um, hier dient sie dem Vergleich der Karten.

NVIDIA DeepStream 9.2, Dokumentation, Performance, dGPU pretrained models, Bilder pro Sekunde je GPU, Eingabe 640 × 640, FP16, TensorRT, gelesen am 25. Oktober 2026. SE = Server Edition. Die Seite nennt keine Zahlen für die L4.

Für die L4 ist die Messung aus DeepStream 7.1 in unserem Leitfaden zur Videoanalyse die veröffentlichte Referenz: 68 H.264-Streams mit 1080p und 30 Bildern pro Sekunde mit einem leichten ResNet18-Detektor, einem Tracker und zwei Klassifikatoren auf einer Karte. Ultralytics veröffentlicht Latenzen seiner eigenen Modelle auf einer T4, der Vorgängerin der L4, mit TensorRT 10 bei 640 Pixeln: 1,7 ms je Bild für YOLO26n, 4,7 ms für YOLO26m und 11,8 ms für YOLO26x. Bei Batch 1 und einer Anfrage nach der anderen sind das nach unserer Rechnung rund 590, 210 und 85 Bilder pro Sekunde; Batching über Triton erhöht den Durchsatz, und den Gewinn messen Sie mit Ihrem eigenen Modell.

Die Rechengenauigkeit verändert die Zahlen so stark wie die Karte. Die TensorRT-Seite von Ultralytics nennt für yolov8n.engine auf einer A100 je Bild 0,52 ms in FP32, 0,33 ms in FP16 und 0,29 ms in INT8, bei Batch 1 auf der COCO-Validierung. NVIDIAs DeepStream-Zahlen oben und das Triton-Beispiel von Ultralytics laufen beide in FP16; INT8 braucht eine Kalibrierung und eine Prüfung der Genauigkeit auf Ihrem Validierungsdatensatz, bevor es in der Produktion eingesetzt wird.

Welche Karte für einen Vision-Serving-Server

Die Last sind Bilder pro Sekunde: Kameras oder Clients mal die Bilder, die jeder zur Analyse schickt. Ein Detektor mit 640 Pixeln ist klein; YOLO26x hat laut Ultralytics 55,7 Millionen Parameter, der GPU-Speicher geht also an Batches, mehrere Modellkopien und in Video-Pipelines an decodierte Bilder. Dimensionieren Sie nach der gemessenen Rate Ihres Modells auf der Zielkarte, halten Sie Reserve für Spitzen, und lesen Sie die veröffentlichten Zahlen oben als Größenordnung.

Die L4 passt in Edge- und Filialserver und in Allzweck-Hosts: 72 W, passiv, Low Profile und einfach breit, 24 GB, Strom aus dem PCIe-Steckplatz, mit vier Video-Decodern. Unser Leitfaden zum Nachrüsten einer GPU im vorhandenen Rack-Server beschreibt den Einbau in einen Host, den Sie bereits betreiben. Die RTX PRO 4500 Server Edition ist eine einfach breite, passive Blackwell-Karte mit 165 W und 32 GB, und acht davon bedienen acht unabhängige Modelle; unser Vergleich L4 oder RTX PRO 4500 Server Edition wägt beide ab. Die RTX PRO 6000 Server Edition passt in zentrale Server mit schwereren Modellen wie RT-DETR oder Open-Vocabulary-Detektoren, vielen Kameras je Karte oder MIG-Instanzen für getrennte Teams.

Wir liefern die L4, die L40S und die RTX PRO Server Editions als Karten für Ihre Server oder in Servern nach Maß; nennen Sie uns Ihre Modelle, Bildgrößen und Bilder pro Sekunde, und unser Team antwortet mit einem Vorschlag für Karte und Server.

Hinweise zum Betrieb des Serving-Servers

Die Support-Matrix von TensorRT nennt R580 als minimalen Treiberzweig für die Pakete mit CUDA 13.x, und die Triton-Release-Notes verweisen für den Treiber eines Containers auf NVIDIAs Seite zur CUDA-Kompatibilität. Unsere Übersicht der NVIDIA-Treiberzweige und CUDA-Versionen listet die Zweige. Auf Blackwell-Karten läuft Software nicht, die ohne Kernel für Compute Capability 12.0 gebaut wurde; unser Beitrag zur Software-Unterstützung für Blackwell sm_120 zeigt, welche Releases sie enthalten.

Betreiben Sie Triton als Container mit dem NVIDIA Container Toolkit und binden Sie jeden Container an seine Karten; unser Leitfaden zur GPU-Zuweisung in Docker ohne Kubernetes zeigt das Vorgehen, GPU-Sharing in Kubernetes mit MIG, Time-Slicing und MPS behandelt Cluster. Bauen Sie TensorRT-Engines neu, sobald sich die TensorRT-Version des Containers ändert, und legen Sie die Engines neben dem Image-Tag ab, mit dem sie gebaut wurden. Zur Lizenz von YOLO-Gewichten und -Code hinter dem Dienst lesen Sie unseren Leitfaden zur Ultralytics-YOLO-Lizenz, zum Training der Modelle unseren Leitfaden zum Trainingsserver für Vision-Modelle.

Was wir liefern

Wir liefern die NVIDIA L4, L40S, RTX PRO 4500 Server Edition und RTX PRO 6000 Server Edition für Server, die Sie bereits betreiben, und bauen damit KI-Server nach Maß, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer Rechnung und Herstellergarantie auf jede Komponente. Auf Wunsch kommt der Server mit installiertem Betriebssystem, NVIDIA-Treiber, CUDA und Container-Laufzeit. Mengen und Lieferzeit bestätigen wir schriftlich mit dem Angebot.

FAQ