Wichtigste Erkenntnisse
- Kostenlos und Apache-2.0-lizenziert, veröffentlicht von NVIDIA auf GitHub
- Baut auf NVIDIAs TensorRT-SDK für Deep-Learning-Inferenz auf, erweitert um LLM-spezifische Optimierungen
- Kompiliert ein Modell vorab in eine optimierte Engine für eine bestimmte GPU — ein Schritt, den vLLM und llama.cpp nicht benötigen
- Nutzt In-Flight- (kontinuierliches) Batching und einen paginierten KV-Cache, um die GPU-Auslastung bei gleichzeitigem Traffic hochzuhalten
- Unterstützt Quantisierung inklusive FP8, INT8, INT4, AWQ und GPTQ; die neuesten Formate benötigen aktuelle NVIDIA-GPUs
- Läuft nur auf NVIDIA-GPUs — keine Unterstützung für CPU, AMD, Apple Silicon oder andere Hersteller
- Wird häufig über den NVIDIA Triton Inference Server oder verpackt in NVIDIA-NIM-Microservices bereitgestellt
- Für Rechenzentrums- und Enterprise-Produktionsbetrieb gebaut, nicht für Single-User-Desktop-Chat
📍 In einem Satz
TensorRT-LLM ist NVIDIAs kostenlose, Apache-2.0-lizenzierte Bibliothek, die LLMs mittels In-Flight-Batching, paginiertem KV-Cache und Quantisierung in GPU-spezifische, optimierte Inference-Engines kompiliert, mit dem Ziel maximaler Durchsatz auf NVIDIA-GPUs.
💬 In einfachen Worten
Statt ein Modell einfach zu laden und auszuführen, hat TensorRT-LLM einen zusätzlichen „Build"-Schritt: Man kompiliert das Modell einmal für die eigene NVIDIA-GPU, und die resultierende Engine läuft auf dieser GPU schneller als ein allgemeiner Lader — sie läuft aber nur auf NVIDIA-Hardware und muss bei GPU- oder Modellwechsel neu gebaut werden.
📌Hinweis: Dieser Artikel basiert auf NVIDIAs offiziellem TensorRT-LLM-GitHub-Repository und öffentlicher Dokumentation, nicht auf eigenen Benchmarks. Konkrete Durchsatz- oder Latenzwerte fehlen bewusst, da sie für diesen Artikel nicht unabhängig gemessen wurden und stark von GPU-Generation, Modell, Batch-Zusammensetzung und TensorRT-LLM-Version abhängen. Dieser Artikel beschreibt TensorRT-LLM sachlich als Dritter; er ist nicht mit NVIDIA verbunden oder von NVIDIA autorisiert.
Was ist TensorRT-LLM?
TensorRT-LLM ist eine von NVIDIA veröffentlichte Open-Source-Bibliothek zur Optimierung und Ausführung von Large-Language-Model-Inferenz auf NVIDIA-GPUs. Sie baut auf TensorRT auf, NVIDIAs allgemeinem SDK für Deep-Learning-Inferenz, und ergänzt eine Schicht LLM-spezifischer Laufzeit-Funktionen sowie eine Python-API zum Definieren und Kompilieren von Modellen in optimierte Engines.
- Veröffentlicht und gepflegt von NVIDIA, quelloffen unter der Apache-2.0-Lizenz auf GitHub
- Erweitert NVIDIAs allgemeines TensorRT-Inferenz-SDK um transformer- und LLM-spezifische Optimierungen
- Bietet eine Python-API (
tensorrt_llm.LLM) sowie einentrtllm-build-Kommandozeilen-Workflow zum Kompilieren von Modellen - Enthält den Befehl
trtllm-serve, um direkt aus einer gebauten Engine einen OpenAI-kompatiblen Endpunkt bereitzustellen - Unterstützt viele beliebte offene Modellfamilien, wobei die genaue Unterstützung pro Modell und nötige Konvertierungsschritte je nach TensorRT-LLM-Release variieren — vor der Modellwahl die Dokumentation zu unterstützten Modellen des Projekts prüfen
Was macht TensorRT-LLM schnell?
Der Performance-Ansatz von TensorRT-LLM kombiniert einen vorgelagerten Kompilierungsschritt mit mehreren LLM-spezifischen Laufzeit-Optimierungen, statt sich auf eine einzelne Technik zu verlassen.
- In-Flight-Batching (NVIDIAs Begriff für kontinuierliches Batching): Neue Anfragen können einem laufenden Batch beitreten und abgeschlossene Anfragen ihn verlassen, ohne auf das Ende des gesamten Batches zu warten — das hält die GPU bei realem, ungleichmäßigem Traffic ausgelastet
- Paginierter KV-Cache: Der Attention-Key-Value-Cache wird in Blöcken fester Größe statt einer großen Allokation pro Anfrage verwaltet, was verschwendeten GPU-Speicher reduziert — konzeptionell ähnlich dem Paging-Ansatz, den vLLMs PagedAttention populär gemacht hat
- Benutzerdefinierte Attention- und GEMM-Kernels: handoptimierte CUDA-Kernels für die Operationen, die LLMs am häufigsten ausführen, kompiliert und ausgewählt für die Ziel-GPU während des Engine-Build-Schritts
- Vorgelagerte Engine-Kompilierung: Modellgraph, gewählte Präzision und Kernel-Auswahl werden vor dem Serving-Start in einer einzigen optimierten Engine-Datei fixiert, statt dynamisch beim Laden entschieden zu werden
- Unterstützung für spekulative Dekodierung: NVIDIA dokumentiert Draft-Modell- und andere Techniken der spekulativen Dekodierung, um pro Schritt mehrere Kandidaten-Tokens zu generieren und parallel zu verifizieren
Welche Hardware benötigt TensorRT-LLM?
TensorRT-LLM läuft ausschließlich auf NVIDIA-GPUs — es gibt kein Backend für CPU-only, AMD, Intel oder Apple Silicon. Innerhalb von NVIDIAs eigener GPU-Palette hängt die Verfügbarkeit bestimmter Optimierungen von der Architektur-Generation der GPU ab.
Blackwell (z. B. B200)
- Details:
- Die neueste unterstützte Architektur zum Zeitpunkt der Erstellung. Ergänzt laut NVIDIA-Dokumentation hardwarebeschleunigtes FP4 (NVFP4) neben FP8.
Hopper (z. B. H100, H200)
- Details:
- Hardware-FP8-Unterstützung; von NVIDIA als einer der ausgereiftesten Pfade für die neueren Quantisierungs- und Attention-Optimierungen von TensorRT-LLM dokumentiert.
Ada Lovelace (z. B. L4, L40S)
- Details:
- Unterstützt, wobei INT8 (einschließlich SmoothQuant) häufig als Fallback dient, wo die volle FP8-Tooling-Unterstützung schmaler ist als bei Hopper/Blackwell.
Ältere Architekturen (z. B. Ampere)
- Details:
- Für einige frühere NVIDIA-Rechenzentrums-GPUs besteht breitere Kompatibilität, aber die neuesten Quantisierungsformate und Kernel-Optimierungen zielen auf aktuelle Hardware — die genaue GPU-zu-Feature-Matrix für die geplante Version findet sich in NVIDIAs Release Notes.
Wer ein Modell auf einem Laptop, einem Mac oder einer Nicht-NVIDIA-GPU ausführen möchte, ist bei TensorRT-LLM falsch — llama.cpp und darauf aufbauende Tools wie Ollama und LM Studio zielen direkt auf CPU- und Apple-Silicon-Hardware ab und sind für dieses Szenario die bessere Wahl.
Welche Quantisierungsformate unterstützt TensorRT-LLM?
TensorRT-LLM unterstützt das Ausführen von Modellen mit reduzierter numerischer Präzision, um Speicherverbrauch zu senken und Durchsatz zu steigern, wobei die verfügbaren Formate von der Ziel-GPU-Generation abhängen.
FP8
- Details:
- Hardwarebeschleunigtes 8-Bit-Gleitkommaformat auf Hopper- und Blackwell-GPUs; laut NVIDIA-Dokumentation auf diesen Generationen meist der beste Kompromiss aus Präzision und Durchsatz.
FP4 (NVFP4)
- Details:
- Ein Blackwell-exklusives 4-Bit-Gleitkommaformat, das von NVIDIA für Blackwell-GPUs und aktuelle TensorRT-/CUDA-Toolchain-Versionen dokumentiert ist.
INT8 / INT4
- Details:
- Integer-Quantisierungspfade einschließlich SmoothQuant, dokumentiert als Fallback für GPU-Generationen (z. B. Ada), auf denen die volle FP8-Tooling-Abdeckung schmaler ist.
AWQ / GPTQ
- Details:
- Etablierte Community-Methoden zur 4-Bit-Gewichtsquantisierung, die TensorRT-LLM neben seinen eigenen Präzisionsoptionen unterstützt.
Dieser Artikel enthält keine unabhängig gemessenen Qualitätsverlust-Werte für jedes Format auf jeder GPU-Generation — diese variieren je nach Modellarchitektur und Aufgabe. Am zuverlässigsten ist es, Ausgaben mehrerer Formate mit den eigenen Prompts und der eigenen Hardware zu vergleichen.
Wie wird TensorRT-LLM bereitgestellt?
TensorRT-LLM lässt sich direkt über die eigene Python-/C++-Laufzeit betreiben, wird in der Produktion aber meist über eine von zwei rund um es gebauten NVIDIA-Deployment-Schichten genutzt.
trtllm-serve: ein in TensorRT-LLM enthaltener Befehl, der direkt aus einer gebauten Engine einen OpenAI-kompatiblen API-Endpunkt bereitstellt, ohne separates Serving-Framework- NVIDIA Triton Inference Server: eine allgemeine Model-Serving-Plattform mit TensorRT-LLM-Backend, die Request-Queuing, Multi-Model-Orchestrierung und produktionsreife Deployment-Funktionen wie Kubernetes-Integration ergänzt
- NVIDIA NIM: vorgefertigte, containerisierte Microservices, die als Teil eines NVIDIA-AI-Enterprise-Abos verkauft werden und ein TensorRT-LLM-optimiertes Backend hinter einer standardisierten API mit Herstellersupport bündeln — siehe den Vergleich der Enterprise-Inference-Server für einen tieferen Blick auf Lizenzierung und Support von NIM
Wie baut und betreibt man eine TensorRT-LLM-Engine?
TensorRT-LLM benötigt eine NVIDIA-GPU, einen passenden CUDA-Treiber und in der Regel NVIDIAs eigenes Container-Image, um Abhängigkeitskonflikte zu vermeiden, da es eng von bestimmten CUDA- und TensorRT-Toolchain-Versionen abhängt.
- 1Sicherstellen, dass eine unterstützte NVIDIA-GPU (Hopper-, Ada- oder Blackwell-Generation für die neuesten Optimierungen) mit aktuellem CUDA-Treiber vorhanden ist.
- 2NVIDIAs offizielles TensorRT-LLM-Container-Image pullen oder das
tensorrt_llm-Python-Paket in eine passende CUDA-Umgebung installieren — der Container-Weg vermeidet die meisten Abhängigkeitskonflikte. - 3Das Ausgangs-Modell-Checkpoint (z. B. von Hugging Face) über die TensorRT-LLM-Python-API oder Beispiel-Konvertierungsskripte für die jeweilige Modellfamilie konvertieren oder laden.
- 4Die optimierte Engine für die konkrete GPU mit dem Befehl
trtllm-buildbauen und dabei Präzision (FP16, FP8, INT4/INT8 oder FP4 auf Blackwell) sowie Batching-Konfiguration festlegen. - 5Die gebaute Engine starten — entweder direkt mit
trtllm-servefür einen OpenAI-kompatiblen Endpunkt oder indem das TensorRT-LLM-Backend des NVIDIA Triton Inference Server auf das Engine-Verzeichnis zeigt. - 6Eine Testanfrage an den bereitgestellten Endpunkt senden (
curloder ein beliebiger OpenAI-API-kompatibler Client), um zu bestätigen, dass die Engine korrekt lädt und generiert, bevor Produktions-Traffic darauf geroutet wird. - 7Den Build-Schritt erneut ausführen, sobald GPU-Generation oder Modell gewechselt werden oder ein neues TensorRT-LLM-Release genutzt werden soll — eine für eine GPU-Generation gebaute Engine läuft nicht garantiert optimal oder überhaupt auf einer anderen.
Muss ich die Engine für jede GPU neu bauen?
In der Regel ja für optimale Ergebnisse — eine Engine wird mit Kernel-Auswahl und Optimierungen für eine bestimmte GPU-Architektur-Generation kompiliert, daher erfordert der Wechsel zu einer anderen GPU-Generation typischerweise einen Neubau.
Kann ich ein vorquantisiertes Modell mit TensorRT-LLM verwenden?
Ja — TensorRT-LLM unterstützt den Bau von Engines aus mit AWQ oder GPTQ quantisierten Modellen, zusätzlich zur eigenen FP8-/INT8-/INT4-/FP4-Quantisierung, die während des Build-Schritts angewendet wird.
Wie schneidet TensorRT-LLM im Vergleich zu vLLM und llama.cpp ab?
TensorRT-LLM, vLLM und llama.cpp führen alle LLM-Inferenz aus, positionieren sich aber unterschiedlich zwischen Performance und Flexibilität.
TensorRT-LLM
- Details:
- Nur NVIDIA, Apache-2.0-lizenziert. Erfordert einen vorgelagerten Kompilierungsschritt pro GPU-Generation; zielt auf den höchstmöglichen Durchsatz auf dieser spezifischen NVIDIA-Hardware, im Austausch für Build-Schritt und Herstellerbindung.
vLLM
- Details:
- Apache-2.0-lizenziert, lädt Hugging-Face-Transformers-kompatible Modelle direkt ohne Kompilierungsschritt. NVIDIA-GPUs sind das primäre Ziel, mit dokumentierten (schmaleren) AMD-, Intel- und TPU-Backends.
llama.cpp
- Details:
- MIT-lizenzierte C/C++-Engine, die auf CPU, Apple Silicon und einer breiten Palette von GPU-Herstellern über das GGUF-Modellformat läuft — die hardwareflexibelste der drei, aber nicht für die Multi-GPU-Skalierung im Rechenzentrum gebaut, auf die TensorRT-LLM und vLLM zielen.
Dieser Artikel hat diese drei Engines nicht selbst gegeneinander benchmarkt und behauptet nicht, dass eine davon universell schneller ist — der Durchsatz hängt stark von Modell, GPU-Generation, Batch-Eigenschaften und der jeweiligen Engine-Version ab. Der eigentliche Vorteil von TensorRT-LLM ist Spitzenleistung speziell auf aktueller NVIDIA-Hardware, auf Kosten von Build-Schritt und reiner NVIDIA-Unterstützung; vLLM tauscht einen Teil dieser GPU-spezifischen Spitzenoptimierung gegen einen einfacheren Workflow ohne Kompilierung und breitere (wenn auch weiterhin primär NVIDIA-) Hardware-Abdeckung; llama.cpp tauscht weiteren Spitzendurchsatz gegen den Betrieb auf Hardware, die keine der beiden anderen adressiert, einschließlich CPUs und Macs.
Wie verhält sich TensorRT-LLM zu NVIDIA NIM und Triton?
TensorRT-LLM, NVIDIA NIM und der NVIDIA Triton Inference Server konkurrieren nicht miteinander — sie sind unterschiedliche Schichten desselben NVIDIA-Inferenz-Stacks, und der Unterschied ist bei der Deployment-Planung wichtig.
TensorRT-LLM
- Details:
- Die Engine und der Compiler: verwandelt ein Modell in eine optimierte, GPU-spezifische Inference-Engine. Kostenlos und quelloffen (Apache 2.0); wird selbst betrieben.
Artikel über TensorRT-LLM (5)
- SGLang Explained: RadixAttention and Structured LLM Serving (2026)Aktualisiert 6. September 2026
- TensorRT-LLM Explained: NVIDIA's GPU-Optimized Inference Engine (2026)Aktualisiert 6. September 2026
- vLLM Explained: High-Throughput LLM Serving with PagedAttention (2026)Aktualisiert 6. September 2026
- text-generation-webui in 2026: How Oobabooga's Local LLM UI Became "TextGen"Aktualisiert 5. September 2026
- Enterprise LLM Inference Servers 2026: vLLM vs TGI vs NVIDIA NIM vs OllamaAktualisiert 2. September 2026
Auch erwähnt in:
- Running LLMs and VLA Models On-Robot 2026: What Fits, What Doesn'tAktualisiert 2. September 2026
- Apple MLX vs NVIDIA CUDA for Local LLMs: Which System Should You Choose in 2026?Aktualisiert 29. August 2026
NVIDIA Triton Inference Server
- Details:
- Eine allgemeine, kostenlose und quelloffene Model-Serving-Plattform mit TensorRT-LLM-Backend, die Request-Routing, Multi-Model-Hosting und Produktions-Orchestrierung um eine oder mehrere Engines herum ergänzt.
NVIDIA NIM
- Details:
- Eine kostenpflichtige, vorgefertigte Microservice-Schicht, verkauft als Teil eines NVIDIA-AI-Enterprise-Abos, die ein TensorRT-LLM-optimiertes Backend hinter einer standardisierten API mit Herstellersupport bündelt — tauscht Eigenaufwand gegen ein unterstütztes, einsatzbereites Container-Deployment.
Ein üblicher Weg: Das Modell zu einer TensorRT-LLM-Engine bauen und dann über Triton für selbstverwaltete Produktions-Deployments servieren, oder den Build-Schritt ganz überspringen und einen vorgefertigten NIM-Container nutzen, falls sich das kostenpflichtige Abo und der Herstellersupport für das Team lohnen. Siehe den Vergleich der Enterprise-Inference-Server für die Lizenz- und Kostenabwägungen zwischen NIM, vLLM und TGI.
Für wen eignet sich TensorRT-LLM?
TensorRT-LLM passt zu Teams, die sich für NVIDIA-GPU-Hardware entschieden haben und den höchstmöglichen Inferenz-Durchsatz daraus benötigen — nicht zu Personen, die den einfachsten Weg suchen, ein Modell auszuführen.
TensorRT-LLM vs. Alternativen im Überblick
Diese Tools positionieren sich unterschiedlich zwischen Setup-Aufwand und Spitzenleistung.
TensorRT-LLM
- Setup:
- GPU-spezifische Engine mit
trtllm-buildkompilieren, dann mittrtllm-serveoder Triton servieren. NVIDIA-GPU und CUDA erforderlich. - Am besten für:
- Maximaler Durchsatz pro GPU auf NVIDIA-Hardware in der Produktion, auf Kosten eines Kompilierungsschritts.
vLLM
- Setup:
- Python-Paket via pip; OpenAI-kompatibler Server, gestartet mit
vllm serve. Kein Kompilierungsschritt; primäres Ziel NVIDIA-GPU. - Am besten für:
- Hoher Durchsatz für viele Nutzer mit einfacherem Workflow ohne Kompilierung.
llama.cpp
- Setup:
- CLI, integrierte Web-UI und OpenAI-kompatible API via llama-server. Läuft auf CPU oder einer breiten Palette von GPU-Herstellern.
- Am besten für:
- Hardware-Flexibilität, Embedded-/Edge-Deployment sowie CPU- oder Apple-Silicon-Nutzung.
NVIDIA NIM
- Setup:
- Vorgefertigter Container, bereitgestellt mit kostenpflichtigem NVIDIA-AI-Enterprise-Abo. Kein Build-Schritt für Endnutzer.
- Am besten für:
- Teams, die TensorRT-LLM-Leistung wollen, ohne die Build-Pipeline selbst zu betreiben.
Dieser Artikel hat Geschwindigkeit oder Ausgabequalität dieser Tools nicht selbst benchmarkt und behauptet nicht, dass eines für jede Arbeitslast technisch überlegen ist — der Vergleich oben deckt nur dokumentierte Architektur-, Setup- und Lizenzfakten ab. Siehe den Leitfaden zu Enterprise-Inference-Servern für einen tieferen Lizenz- und Deployment-Vergleich.
Was deckt dieser Artikel nicht ab?
Dies ist ein Erklärartikel auf Basis von NVIDIAs öffentlicher Dokumentation und Repository, kein praktischer Benchmark-Bericht.
- Keine unabhängig gemessenen Durchsatz-, Latenz- oder Requests-pro-Sekunde-Werte — diese hängen stark von GPU-Generation, Modell, Batch-Zusammensetzung und TensorRT-LLM-Version ab
- Keine unabhängig verifizierten Qualitätsverlust-Prozentsätze für bestimmte Quantisierungsformate auf bestimmten GPUs — diese variieren je nach Modellarchitektur und Aufgabe
- Keine vollständige Abdeckung jeder unterstützten Modellarchitektur, Kernel-Option oder erweiterten Funktion (disaggregiertes Serving, Expert-Parallelismus, LoRA) — dieser Artikel konzentriert sich auf die Konzepte, die die meisten Teams zuerst prüfen
- Keine Abdeckung von NVIDIA-AI-Enterprise- oder NIM-Preisen, da Enterprise-Abo-Preise nicht wie bei einem Endkundenprodukt veröffentlicht werden — aktuelle Preise direkt bei NVIDIA erfragen
- Kein Anspruch auf NVIDIA-Autorisierung oder -Partnerschaft — dieser Artikel beschreibt TensorRT-LLM sachlich als unabhängiger Erklärartikel eines Dritten auf Basis öffentlicher Quellen
Häufige Fehler beim Ausprobieren von TensorRT-LLM
Die meiste Reibung mit TensorRT-LLM entsteht, wenn der Build-/Kompilierungsschritt unterschätzt oder ein Verhalten wie bei einer Direktlade-Engine erwartet wird.
Häufig gestellte Fragen
Was ist TensorRT-LLM?
TensorRT-LLM ist eine kostenlose, quelloffene (Apache 2.0) Bibliothek von NVIDIA, die große Sprachmodelle in optimierte Inference-Engines kompiliert, die speziell für NVIDIA-GPUs gebaut sind, aufbauend auf NVIDIAs TensorRT-SDK für Deep-Learning-Inferenz.
Ist TensorRT-LLM kostenlos?
Ja. TensorRT-LLM selbst ist kostenlose, quelloffene Software unter der Apache-2.0-Lizenz. NVIDIA NIM, eine separate kostenpflichtige Microservice-Schicht, die ein TensorRT-LLM-Backend bündelt, erfordert ein NVIDIA-AI-Enterprise-Abo.
Läuft TensorRT-LLM auf AMD- oder Apple-GPUs?
Nein. TensorRT-LLM läuft ausschließlich auf NVIDIA-GPUs — es gibt kein Backend für CPU-only, AMD, Intel oder Apple Silicon, anders als vLLM oder llama.cpp, die breitere Hardware unterstützen.
Warum muss man bei TensorRT-LLM ein Modell erst kompilieren?
TensorRT-LLM baut ein Modell vorab zu einer Engine mit fixierter Kernel-Auswahl und Optimierungen für eine bestimmte GPU-Architektur-Generation — so erreicht es sein Leistungsziel. Das tauscht einen Build-Schritt und weniger herstellerübergreifende Flexibilität gegen höheren Spitzendurchsatz auf dieser spezifischen NVIDIA-GPU im Vergleich zu Engines, die alles dynamisch beim Laden entscheiden.
Welche Quantisierungsformate unterstützt TensorRT-LLM?
TensorRT-LLM unterstützt FP8 und FP4 (FP4 exklusiv für Blackwell-GPUs), INT8 und INT4 einschließlich SmoothQuant sowie Community-Formate wie AWQ und GPTQ, wobei die genaue Verfügbarkeit von der Ziel-GPU-Generation abhängt.
Ist TensorRT-LLM besser als vLLM?
„Besser" hängt vom Einsatzzweck ab: TensorRT-LLM zielt auf den höchstmöglichen Durchsatz pro GPU speziell auf NVIDIA-Hardware, auf Kosten eines vorgelagerten Kompilierungsschritts und reiner NVIDIA-Unterstützung. vLLM lädt Modelle direkt ohne Kompilierungsschritt und dokumentiert Backend-Unterstützung über NVIDIA-GPUs hinaus. Keines ist universell schneller — siehe die Vergleichstabelle oben.
Was ist der Unterschied zwischen TensorRT-LLM und NVIDIA NIM?
TensorRT-LLM ist die kostenlose, quelloffene Engine und der Compiler, die selbst betrieben werden. NVIDIA NIM ist eine separate, kostenpflichtige Microservice-Schicht, die ein TensorRT-LLM-optimiertes Backend hinter einer standardisierten API mit Herstellersupport bündelt, verkauft als Teil eines NVIDIA-AI-Enterprise-Abos.
Kann TensorRT-LLM Modelle über mehrere GPUs hinweg servieren?
Ja. NVIDIA dokumentiert Multi-GPU- und Multi-Node-Serving-Unterstützung in TensorRT-LLM für Modelle, die nicht auf eine einzelne GPU passen, typischerweise bereitgestellt über den NVIDIA Triton Inference Server für die Produktionsorchestrierung.