Triton Inference Server: Multi-Modell GPU teilen

TL;DR

NVIDIA Triton Inference Server lädt mehrere KI-Modelle gleichzeitig auf eine GPU und verteilt Anfragen intelligent. Statt drei dedizierte GPUs für drei Modelle reicht eine einzige A100. Ein Automobilzulieferer reduzierte seine GPU-Kosten von €54.000 auf €18.000 pro Jahr – bei gleichbleibender Latenz unter 50 ms.

Das Kosten-Problem: Eine GPU pro Modell

Mittelständler mit mehreren KI-Modellen in Produktion stehen vor einem Skalierungsproblem. Das Qualitätskontrollmodell läuft auf GPU 1, der Chatbot auf GPU 2, das Prognosemodell auf GPU 3. Jede GPU kostet €500–€1.500 pro Monat in der Cloud oder €8.000–€15.000 einmalig für On-Premise-Hardware.

Das Problem: Keine dieser GPUs ist dauerhaft ausgelastet. Das Qualitätskontrollmodell arbeitet nur während der Produktion (8 Stunden/Tag). Der Chatbot hat Spitzen zwischen 9 und 17 Uhr. Das Prognosemodell läuft einmal pro Stunde für 30 Sekunden. Durchschnittliche GPU-Auslastung: 15–25 %.

Triton löst dieses Problem durch Multi-Model-Serving: Alle Modelle teilen sich eine GPU, und Triton verwaltet den Speicher dynamisch.

Triton: Multi-Model-Serving erklärt

Triton lädt Modelle aus verschiedenen Frameworks (PyTorch, TensorFlow, ONNX, TensorRT) in den GPU-Speicher und bedient Anfragen über eine einheitliche REST/gRPC-API. Die Schlüsselfunktionen:

Dynamic Batching: Einzelne Anfragen werden zu Batches zusammengefasst. Statt drei einzelne Inferenz-Durchläufe führt Triton einen Batch-Durchlauf aus – 3x schneller bei gleicher GPU-Last.

Model Concurrency: Mehrere Modelle teilen den GPU-Speicher. Triton entscheidet, welches Modell wann GPU-Zyklen bekommt, basierend auf der aktuellen Auslastung.

Model Repository: Neue Modelle werden durch Ablegen einer Datei im Repository geladen – kein Server-Neustart nötig.

# Triton Model Repository Struktur
model_repository:
  qualitaetskontrolle:
    config_pbtxt: |
      name: "qualitaetskontrolle"
      platform: "onnxruntime_onnx"
      max_batch_size: 16
      instance_group:
        - count: 1
          kind: KIND_GPU
      dynamic_batching:
        max_queue_delay_microseconds: 50000
  chatbot_embedding:
    config_pbtxt: |
      name: "chatbot_embedding"
      platform: "pytorch_libtorch"
      max_batch_size: 32
      instance_group:
        - count: 1
          kind: KIND_GPU
  prognose_modell:
    config_pbtxt: |
      name: "prognose_modell"
      platform: "onnxruntime_onnx"
      max_batch_size: 8
      instance_group:
        - count: 1
          kind: KIND_GPU

Setup: Triton auf einem GPU-Server

Die Installation dauert 30 Minuten. Voraussetzung: Ein Linux-Server mit NVIDIA GPU (mindestens T4, empfohlen A10 oder A100), Docker und nvidia-container-toolkit.

Starten Sie Triton mit dem Docker-Image von NVIDIA. Legen Sie Ihre exportierten Modelle im ONNX- oder TorchScript-Format in das Model Repository. Triton lädt sie automatisch und stellt eine API unter Port 8000 (HTTP) und 8001 (gRPC) bereit.

Die API ist OpenAI-kompatibel konfigurierbar. Bestehende Anwendungen, die bisher direkt mit einem einzelnen Modell kommuniziert haben, brauchen nur die URL zu ändern.

Performance-Vergleich: Triton vs. FastAPI

Der Latenz-Unterschied ist minimal. Durch Dynamic Batching ist Triton bei P99 sogar schneller, weil Lastspitzen besser abgefedert werden. Der Durchsatz vervierfacht sich durch Batch-Verarbeitung.

Kostenersparnis: Praxisbeispiel

Ein Automobilzulieferer (320 Mitarbeiter) betrieb fünf KI-Modelle auf fünf separaten T4-GPUs in der Azure Cloud:

• Visuelle Qualitätskontrolle (ResNet-50)
• Stücklistenklassifikation (BERT)
• Nachfrageprognose (LSTM)
• Anomalieerkennung Schweißnaht (YOLOv8)
• Dokument-Embedding für RAG (BGE-M3)

Vorher: 5 x Standard_NC4as_T4_v3 = €4.500/Monat = €54.000/Jahr

Nachher: 1 x Standard_NC24ads_A100_v4 + 1 x Standard_NC4as_T4_v3 = €1.500/Monat = €18.000/Jahr

Die Einsparung von €36.000/Jahr amortisierte die Umstellungskosten (€8.000) in weniger als drei Monaten. Details zur GPU-Kostenplanung finden Sie im Budget-Guide.

Triton mit Kubernetes: Auto-Scaling

Für Unternehmen mit variablem Workload empfiehlt sich Triton auf Kubernetes. Der Horizontal Pod Autoscaler skaliert basierend auf GPU-Auslastung oder Queue-Länge:

• Nachts: 1 Triton-Pod auf einer T4 (Prognosen, Batch-Jobs)
• Tagsüber: 2 Pods auf A10 (Echtzeit-Qualitätskontrolle + Chatbot)
• Lastspitzen: 3 Pods (automatisch, innerhalb von 2 Minuten)

Diese Flexibilität senkt die durchschnittlichen GPU-Kosten um weitere 20–30 % gegenüber statischer Provisionierung.

Migration bestehender Modelle

Die häufigste Hürde: Modelle müssen in ein Triton-kompatibles Format exportiert werden. PyTorch-Modelle exportieren Sie als TorchScript oder ONNX. TensorFlow-Modelle als SavedModel. Scikit-learn-Modelle über den ONNX-Konverter.

Der Export dauert pro Modell 1–4 Stunden inklusive Validierung. Ein KI-Team mit ML-Engineer erledigt die Migration von fünf Modellen in einer Woche.

Triton unterstützt auch Python-Backend für Modelle, die sich nicht exportieren lassen. Die Performance ist dann geringer, aber der Migrationspfad ist offen.

Häufige Fragen

Wie viele Modelle passen auf eine GPU?

Abhängig vom GPU-Speicher und der Modellgröße. Auf einer A100 (80 GB) passen 5–15 typische Computer-Vision- und NLP-Modelle gleichzeitig. Auf einer T4 (16 GB) 2–5 Modelle. LLMs mit 7B+ Parametern belegen eine GPU allein.

Ist Triton nur für NVIDIA GPUs?

Ja, die GPU-Beschleunigung erfordert NVIDIA GPUs mit CUDA. Für CPU-only-Inferenz funktioniert Triton ebenfalls, aber ohne die Performance-Vorteile von Dynamic Batching auf der GPU.

Kann ich Triton mit bestehenden REST-APIs nutzen?

Ja. Triton bietet eine HTTP/REST-API und eine gRPC-API. Bestehende Anwendungen ändern nur die Endpoint-URL. Das Request-Format ist standardisiert und OpenAI-kompatibel konfigurierbar.

Was passiert bei GPU-Speicher-Engpässen?

Triton entlädt selten genutzte Modelle automatisch aus dem GPU-Speicher und lädt sie bei Bedarf nach. Die Latenz erhöht sich beim ersten Request nach dem Nachladen um 200–500 ms. Der ROI bleibt positiv, solange weniger als 10 % der Requests vom Nachladen betroffen sind.

Brauche ich Triton bei nur einem Modell?

Auch bei einem einzelnen Modell bietet Triton Vorteile: Dynamic Batching erhöht den Durchsatz um 50–200 %, und das Model Repository ermöglicht Zero-Downtime-Updates. Der Mehraufwand für das Setup ist minimal.