Eine GPU-Inferenz-Engine tunen: Batching, Latenz, Metriken

Der Blickwinkel dieses Artikels: die Inferenz-Engine selbst, Batching, Quantisierung, Latenz und die Metriken, die zeigen, ob die Karte wirklich arbeitet. Nichts zu Scheduling oder Sharing: das sind andere Artikel.

Einleitung

Metriken, Frameworks und Strategien, um den ROI Ihrer GPUs zu maximieren

Die Kosten von GPUs im Produktivbetrieb erzeugen wachsenden wirtschaftlichen Druck. Eine H100-GPU kostet je nach Anbieter zwischen 2 und 10 CHF pro Stunde, also 17 500 bis 87 600 CHF pro Jahr für eine einzige durchgehend laufende Instanz. Laut einer Studie der AI Infrastructure Alliance von 2024 erreichen dennoch nur 7 % der Organisationen mehr als 85 % GPU-Auslastung unter Spitzenlast. Die übrigen 93 % verschwenden zwischen 15 und 60 % ihrer GPU-Kapazität, Zehntausende Franken pro Jahr und GPU.

Diese Ineffizienz hat drei technische Ursachen: suboptimale Datenpipelines, die GPUs warten lassen, unpassende Batching-Konfigurationen, die den Durchsatz begrenzen, und fehlendes granulares Monitoring, das Bottlenecks unsichtbar macht. Dieser Beitrag legt die vier Hebel der GPU-Optimierung im Produktivbetrieb dar, beschreibt die kritischen Metriken und schlägt ein Monitoring-Framework auf Basis von DCGM und Prometheus vor.

Das Ziel: aus untergenutzten GPUs leistungsfähige Aktiven mit messbarem ROI machen.

Ineffizienz in vier Metriken diagnostizieren

GPU-Optimierung beginnt bei der Messung. Vier Kennzahlen zeigen die Ursachen der Ineffizienz genau und beziffern die möglichen Gewinne.

GPU-Auslastung: die grundlegende Metrik

Die GPU-Auslastung misst den Zeitanteil, in dem mindestens ein Kernel auf der GPU läuft. Diese über nvidia-smi oder DCGM verfügbare Metrik ist der Indikator erster Ebene. Eine Auslastung unter 60 % zeigt ein Optimierungsproblem, eine Auslastung über 85 % kann auf Sättigung hinweisen, die ein Scale-up verlangt.

Zielwert GPU-Auslastung = 60-80 %

Interpretation:
- < 40 %, starke Unternutzung, Datenpipeline oder Batching unpassend
- 40-60 %, Optimierung nötig, spürbare Gewinne möglich
- 60-80 %, optimaler Bereich, gutes Verhältnis Leistung/Kosten
- > 85 %, mögliche Sättigung, P95/P99-Latenz prüfen

Vorsicht, Eine GPU mit 100 % Auslastung ist nicht zwingend optimal. Die Metrik unterscheidet nicht zwischen compute-intensiven und memory-bound Kernels. Eine durch Speicherzugriffe gesättigte GPU zeigt 100 % Auslastung und liefert dennoch suboptimale Leistung.

Speicherbandbreite: Bottlenecks erkennen

Die Auslastung der Speicherbandbreite misst, welcher Anteil der theoretischen Bandbreite tatsächlich genutzt wird. Bei einer A100 80GB mit 2039 GB/s HBM2e-Bandbreite bedeutet eine Auslastung von 30 %, dass nur 612 GB/s genutzt werden. Diese Differenz zeigt entweder ein Problem der Datenpipeline oder schlecht optimierte Kernels, die zu viel Rechenaufwand pro übertragenem Byte verlangen.

LLM-Inferenz-Workloads sind typischerweise memory-bound: Die GPU wartet länger auf Daten, als sie rechnet. Bei diesen Lasten bringt die Optimierung der Speicherbandbreite über Quantisierung (FP16, INT8) oder optimierte Kernels (FlashAttention) 2- bis 3-fache Durchsatzgewinne.

Durchsatz gegen Theorie: die Lücke messen

Der reale Durchsatz wird bei Sprachmodellen in Tokens pro Sekunde gemessen, bei Vision-Modellen in Inferenzen pro Sekunde. Diese Kennzahl wird mit dem theoretischen Durchsatz aus den Herstellerangaben verglichen. Eine Lücke von mehr als 40 % zwischen Theorie und Realität weist auf fehlende Optimierungen hin.

Beispielrechnung theoretischer Durchsatz (LLM-Inferenz):

Theoretischer Durchsatz = (GPU-TFLOPS × Präzision) / (Modellparameter × 2)

A100 80GB, 13B-Modell in FP16:
= (312 TFLOPS × 0.5) / (13B × 2)
= 156 / 26 = ~6 Tokens/Sekunde (Grössenordnung)

Gemessener Durchsatz < 4 Tokens/s → Optimierung erforderlich

Latenz P50/P95/P99, Servicequalität sichern

Latenz wird in Perzentilen gemessen, nicht als Mittelwert. Die P50-Latenz (Median) zeigt die typische Nutzererfahrung, P95 und P99 zeigen die verschlechterten Fälle, die 5 % beziehungsweise 1 % der Anfragen betreffen. Bei interaktiven Anwendungen (Chatbots, Assistenten) verschlechtert eine P99-Latenz über einer Sekunde die Nutzererfahrung deutlich.

Die vier technischen Optimierungshebel

Sind die Basismetriken etabliert, verbessern vier technische Hebel die GPU-Leistung im Produktivbetrieb deutlich.

1. Dynamische Batch-Grösse: Durchsatz maximieren

Die Batch-Grösse bestimmt, wie viele Anfragen gleichzeitig verarbeitet werden. Eine zu kleine Batch-Grösse nutzt die GPU nicht aus (30-40 % Auslastung), eine zu grosse sättigt den VRAM und führt zu Out-of-Memory. Die Formel für das Optimum berücksichtigt verfügbaren VRAM, Modellgrösse und Sequenzlänge.

Optimale Batch-Grösse = (verfügbarer VRAM - Modellgrösse) / Speicher pro Sequenz

Beispiel: A100 80GB, 13B-Modell in FP16, Sequenzen mit 512 Tokens

Modellgrösse in FP16, 13B × 2 Bytes = 26 GB
Speicher pro Sequenz, 512 Tokens × 13B × 2 Bytes / 1e9 ≈ 13 GB (Näherung KV-Cache*)
Verfügbarer VRAM, 80 - 26 = 54 GB

Optimale Batch-Grösse ≈ 54 / 13 ≈ 4 gleichzeitige Anfragen

Moderne Frameworks wie vLLM setzen Continuous Batching (oder In-flight Batching) um, das neue Anfragen dynamisch in einen laufenden Batch einfügt. Diese Technik verbessert den Durchsatz gegenüber statischem Batching um das 2,2- bis 3,5-Fache, gemäss den vLLM-Benchmarks auf LLaMA.

*Diese Schätzung gibt eine Grössenordnung, bildet den realen Speicherbedarf aber nicht getreu ab. In der Praxis dominieren KV-Cache, Kontextlänge und die Optimierungen der Inferenz-Engine; eine empirische Validierung ist für eine korrekte Dimensionierung nötig.

2. Präzision und Quantisierung: FP32 → FP16 → INT8

Geringere arithmetische Präzision senkt den VRAM-Bedarf und beschleunigt die Berechnung. FP32 (32-Bit-Gleitkomma) ist der Standard fürs Training, für die Inferenz aber überdimensioniert. FP16 halbiert die Speichernutzung bei einem Qualitätsverlust von in der Regel unter 1 %. INT8-Quantisierung viertelt den VRAM-Bedarf, mit einer Einbusse von 2 bis 5 % je nach Modell.

*INT4 verlangt eine Validierung im Einzelfall; die Qualitätsverluste variieren je nach Aufgabe.

Praktisch wird Quantisierung über spezialisierte Frameworks umgesetzt: AWQ (Activation-aware Weight Quantization), GPTQ oder die FP8-Kernels der Hopper-GPUs (H100). Die H100 enthält eine Transformer Engine, die nativ in FP8 rechnet und den Durchsatz bei Transformer-Architekturen gegenüber FP16 um 20 bis 50 % verbessert.

3. Optimierte Inferenz-Frameworks: vLLM, TensorRT-LLM, SGLang

Spezialisierte Inferenz-Frameworks setzen Optimierungen um, die sich mit Standard-PyTorch oder -TensorFlow nicht nachbilden lassen. Drei Frameworks prägen den Markt 2025, jedes mit eigenen Kompromissen zwischen Leistung und Komplexität.

vLLM positioniert sich als Referenz-Framework für die Produktion. Die zentrale Neuerung, PagedAttention, behandelt den KV-Cache wie virtuellen Speicher, beseitigt Fragmentierung und erlaubt mehr gleichzeitige Anfragen. Laut den Cerebrium-Benchmarks 2024 erreicht vLLM mit 123 ms die beste Time To First Token (TTFT) auf LLaMA 3.1 70B mit H100 und laut Clarifai 4741 Tokens/Sekunde bei 100 gleichzeitigen Anfragen. Die native Hugging-Face-Integration und die OpenAI-kompatible API erleichtern die Einführung.

TensorRT-LLM von NVIDIA zielt auf Deployments mit maximalen Leistungsanforderungen. Auf TensorRT aufbauend kompiliert es Modelle in optimierte CUDA-Kernels und nutzt die Tensor Cores voll aus. Die LMSYS-Benchmarks 2024 zeigen, dass TensorRT-LLM vLLM bei geringer Nebenläufigkeit in der Latenz erreicht oder übertrifft (35-50 ms TTFT), unter hoher Last aber nachlässt. Die Setup-Komplexität (Kompilierung je Modell, zwingender Docker-Container) reserviert es für Teams mit CUDA-Erfahrung.

SGLang führt RadixAttention ein, eine Struktur zum Teilen von Präfixen über einen Radix-Baum. Dieser Ansatz glänzt bei Lasten mit starker Kontextwiederverwendung: Chat über mehrere Runden, Few-shot-Prompting, Agenten. Die LMSYS-Benchmarks zeigen für SGLang bis zum 3,1-Fachen des vLLM-Durchsatzes auf LLaMA-70B bei intensiver Präfix-Wiederverwendung. Für RAG-Anwendungen oder Agenten mit wiederkehrenden Prompts bringt SGLang erhebliche Gewinne.

Auswahlhilfe Inferenz-Framework:

• vLLM, allgemeine Produktion, hohe Nebenläufigkeit (>50 Anfragen/s), Hugging-Face-Integration erforderlich
• TensorRT-LLM, maximale Leistung, sehr niedrige Latenz (<50 ms), Teams mit NVIDIA-Erfahrung
• SGLang, RAG, Agenten, Chat über mehrere Runden mit starker Kontextwiederverwendung
• Ollama, schnelles Prototyping, lokale Entwicklung, nicht für Produktion im grossen Massstab geeignet

4. Die Datenpipeline optimieren

Ineffiziente Datenpipelines sind die Hauptursache für GPU-Unternutzung. Laut Clarifai verschwenden schlecht optimierte Pipelines bis zu 40 % der GPU-Zyklen. Drei kritische Optimierungen beseitigen diese Verluste.

Erstens die Datenlokalität. Datensätze in derselben Region wie die GPUs zu speichern senkt die Übertragungslatenz von 80-200 ms auf 5-15 ms. Für selten genutzte kalte Daten senkt Archivspeicher (S3 Glacier, Azure Archive) statt Hochleistungsspeicher die Kosten um 70 bis 90 %, ohne die heissen Daten zu beeinträchtigen.

Zweitens komprimierte Formate. Daten in Parquet oder ORC statt CSV zu speichern verringert die Grösse um 60 bis 80 % und beschleunigt das Lesen dank spaltenweiser Kompression. Die Dekompressionszeit ist gegenüber den Gewinnen bei Netz- und Plattenübertragung vernachlässigbar.

Drittens Prefetching und Caching. Batch N+1 zu laden, während die GPU Batch N verarbeitet, beseitigt Wartezeiten. Der PyTorch DataLoader setzt das über den Parameter num_workers um. Als Faustregel: num_workers = 2 × Anzahl_GPUs, um Parallelität und Overhead auszubalancieren.

Empfohlener Monitoring-Stack

Wirksames GPU-Monitoring ruht auf drei Schichten, Erfassung der Low-Level-Metriken, Aggregation und Time-Series-Speicherung, Visualisierung und Alerting. Die empfohlene Architektur kombiniert DCGM, Prometheus und Grafana.

DCGM: NVIDIA-Metriken erfassen

Der NVIDIA Data Center GPU Manager (DCGM) ist die Referenzschicht für die Erfassung bei Rechenzentrums-GPUs. Anders als nvidia-smi, das für punktuelle Kontrollen gedacht ist, liefert DCGM einen kontinuierlichen Metrikstrom über eine API. Der DCGM Exporter überführt diese Metriken ins Prometheus-Format, erreichbar über einen HTTP-Endpoint auf Port 9400.

Installation DCGM Exporter (Docker):

docker run -d
--gpus all
--cap-add SYS_ADMIN
--network host
--name dcgm-exporter
--restart unless-stopped
nvcr.io/nvidia/k8s/dcgm-exporter:3.3.8-3.6.0-ubuntu22.04

# Prüfung
curl localhost:9400/metrics | grep DCGM_FI_DEV_GPU_UTIL

DCGM liefert über 50 Metriken, darunter, GPU-Auslastung (DCGM_FI_DEV_GPU_UTIL), VRAM-Nutzung (DCGM_FI_DEV_FB_USED), GPU- und Speichertemperatur (DCGM_FI_DEV_GPU_TEMP, DCGM_FI_DEV_MEMORY_TEMP), Leistungsaufnahme (DCGM_FI_DEV_POWER_USAGE), SM- und Speichertakt (DCGM_FI_DEV_SM_CLOCK, DCGM_FI_DEV_MEM_CLOCK) sowie PCIe-Fehlerzähler (DCGM_FI_DEV_PCIE_REPLAY_COUNTER).

Prometheus, Time-Series-Speicherung

Prometheus scrapt die Metriken des DCGM Exporters in regelmässigen Abständen (typisch 15 Sekunden) und legt sie in seiner Time-Series-Datenbank ab. Die Prometheus-Konfiguration definiert die zu scrapenden Targets und die Aufbewahrung.

Prometheus-Konfiguration (prometheus.yml):

scrape_configs:
- job_name, 'dcgm-exporter'
static_configs:
- targets, ['localhost:9400']
scrape_interval, 15s
scrape_timeout, 10s

In Kubernetes-Deployments wird der DCGM Exporter über Helm oder als Teil des NVIDIA GPU Operators ausgerollt, mit automatischer Service Discovery. Prometheus erkennt die DCGM-Exporter-Pods automatisch über Kubernetes-Labels.

Grafana: Visualisierung und Alerting

Grafana konsumiert die Prometheus-Metriken und erzeugt interaktive Dashboards. NVIDIA stellt ein vorkonfiguriertes Dashboard bereit (ID 12239), das die wesentlichen GPU-Metriken zeigt. Zu den kritischen Panels zählen: GPU-Auslastung über die Zeit (Cluster-Mittel und je GPU), VRAM-Nutzung mit Schwellenlinien bei 70 % und 90 %, GPU- und Speichertemperatur, momentane und kumulierte Leistungsaufnahme sowie P50/P95/P99-Latenz der Anwendungsanfragen.

Grafana-Alerts lösen je nach konfigurierbaren Schwellen Benachrichtigungen über Slack, PagerDuty oder E-Mail aus. Empfohlene Alerts: GPU-Auslastung unter 40 % während 30 Minuten (Unternutzung), VRAM über 90 % während 5 Minuten (OOM-Risiko), GPU-Temperatur über 80 °C während 10 Minuten (Throttling-Risiko), PCIe-Fehler über 0 (Hardwareproblem).

Die fünf Fehler, welche die Leistung verschlechtern

1. Kontinuierliches Monitoring vernachlässigen

Symptom: GPUs ohne granulares Monitoring betreiben und sich nur auf punktuelle nvidia-smi-Aufrufe oder aggregierte Cloud-Provider-Metriken verlassen.

Auswirkung: Ohne Sichtbarkeit lässt sich Ineffizienz nicht erkennen. Eine Spheron-Studie von 2025 zeigt, dass Organisationen ohne Monitoring GPUs entdecken, die wochenlang unter 30 % Auslastung laufen und Zehntausende Franken verschwenden. Bottlenecks (Datenpipeline, unpassende Batch-Grösse) bleiben unsichtbar, bis Nutzende sich über hohe Latenz beschweren.

Lösung: DCGM Exporter, Prometheus und Grafana ab der ersten ausgerollten GPU einsetzen. Overhead: rund 5 % GPU-Leistung, durch die erkannten Optimierungen weit mehr als ausgeglichen. Dashboards mit Alerts definieren bei Auslastung unter 40 %, VRAM über 90 %, P95-Latenz über 500 ms. Wöchentliche Durchsicht der Metriken mit dem Engineering-Team, um Optimierungspotenzial zu finden.

2. Standard-PyTorch oder -TensorFlow in Produktion einsetzen

Symptom: Modelle direkt mit PyTorch oder TensorFlow ausliefern, ohne spezialisiertes Inferenz-Framework.

Auswirkung: PyTorch und TensorFlow sind fürs Training optimiert, nicht für Produktionsinferenz. Ohne Continuous Batching, optimierte KV-Cache-Verwaltung und spezialisierte Kernels sinkt der Durchsatz gegenüber vLLM oder TensorRT-LLM um das 2- bis 4-Fache. Bei einem Dienst mit 1000 Anfragen pro Tag heisst das 250 bis 500 statt 1000 Anfragen auf derselben GPU, also 2 bis 4 GPUs statt einer. Zusätzliche Jahreskosten: 35 000 bis 105 000 CHF bei A100.

Lösung: auf vLLM für allgemeine Produktion migrieren (Setup 1-2 Tage), auf TensorRT-LLM bei kritischer Latenz (Setup 1-2 Wochen) oder auf SGLang für RAG und Agenten. Vor und nach der Migration benchmarken, um die realen Gewinne zu beziffern. In 90 % der Fälle bietet vLLM das beste Verhältnis von Leistung zu Komplexität.

3. Quantisierung ignorieren

Symptom: alle Modelle in FP32 oder FP16 ausliefern, ohne INT8 oder fortgeschrittene Quantisierungstechniken zu prüfen.

Auswirkung: INT8-Quantisierung halbiert den VRAM-Bedarf gegenüber FP16 bei 2 bis 5 % Qualitätsverlust. Bei einem 13B-Modell, das von 26 GB (FP16) auf 13 GB (INT8) fällt, lässt sich entweder die Batch-Grösse verdoppeln (2× Durchsatz) oder es lassen sich zwei Modelle auf derselben GPU betreiben. Keine Quantisierung bedeutet 40 bis 50 % verschwendete GPU-Kapazität.

Lösung: INT8 für Produktionsinferenz systematisch prüfen. Auf repräsentativen Datensätzen testen, Qualitätsverlust messen (Accuracy, F1, BLEU je nach Aufgabe). Liegt der Verlust unter 5 % und ist für den Anwendungsfall vertretbar, in INT8 ausrollen. AWQ oder GPTQ für optimale Quantisierung nutzen. Bei Hopper-GPUs (H100) natives FP8 über unterstützte Frameworks nutzen (vLLM, TensorRT-LLM).

4. Die Batch-Grösse zu klein wählen

Symptom: Batch-Grösse 1 oder eine zu klein belassene statische Batch-Grösse ohne Optimierung.

Auswirkung: Eine Batch-Grösse von 1 nutzt die GPU massiv nicht aus (20-40 % Auslastung). Die GPU wartet länger zwischen Anfragen, als sie rechnet. Eine optimale Batch-Grösse (berechnet aus verfügbarem VRAM und Sequenzlänge) verbessert den Durchsatz um das 3- bis 5-Fache, ohne die Median-Latenz zu erhöhen. Eine unpassende Batch-Grösse verschwendet 60 bis 80 % der GPU-Kapazität.

Lösung: optimale Batch-Grösse über die Formel (verfügbarer VRAM - Modellgrösse) / Speicher pro Sequenz berechnen. In Produktionsanwendungen Continuous Batching einsetzen (vLLM, TGI), das dynamisch nachregelt. GPU-Auslastung überwachen: liegt sie unter 60 %, die Batch-Grösse bis auf 70-80 % erhöhen. Die Wirkung auf die P95/P99-Latenz messen: bleibt der Anstieg vertretbar (unter 20 %), die neue Batch-Grösse übernehmen.

5. Die Energiekosten vernachlässigen

Symptom: nur auf Leistung optimieren, ohne den Stromverbrauch zu berücksichtigen.

Auswirkung: Eine H100 kann unter Volllast bis 700 W ziehen, also 16,8 kWh pro Tag oder 6132 kWh pro Jahr. In der Schweiz (Strom rund 0,20 CHF/kWh inklusive Kühlung) sind das 1226 CHF pro Jahr und GPU. Eine suboptimale GPU, die unnötig auf 100 % Auslastung läuft statt mit Optimierungen auf 70 %, verschwendet 30 % dieser Energie, also 368 CHF pro Jahr. Auf einem Cluster mit 10 GPUs sind das 3680 CHF pro Jahr vermeidbare Stromkosten.

Lösung: Leistungsaufnahme über DCGM überwachen (DCGM_FI_DEV_POWER_USAGE). Auf Leistung pro Watt optimieren, nicht nur auf rohe Leistung. Techniken: Quantisierung (senkt den Verbrauch um 20-30 %), optimale Batch-Grösse (vermeidet Unternutzung), automatische Abschaltpläne (Dev- und Testumgebungen ausserhalb der Arbeitszeiten aus), zur Last passende GPU-Wahl (L40S mit 350 W gegenüber H100 mit 700 W für reine Inferenz). Für GPU-Entscheide einen TCO über 36 Monate inklusive Strom rechnen.

Praxisfall: einen RAG-Chatbot optimieren

Ein konkreter Fall, interner RAG-Chatbot eines Schweizer Unternehmens, 500 Mitarbeitende, rund 2000 Anfragen pro Tag, Modell LLaMA-2 13B, zunächst auf einer A100 40GB betrieben.

Ausgangslage: Modell mit Standard-PyTorch in FP16 ausgeliefert, Batch-Grösse 1, kein detailliertes Monitoring. Beobachtete Werte: GPU-Auslastung 35 %, Durchsatz 1,2 Tokens/Sekunde, P95-Latenz 800 ms, GPU-Kosten 3200 CHF/Monat (Cloud-Anbieter).

Angewandte Optimierungen:

1. Migration auf vLLM mit Continuous Batching → GPU-Auslastung 72 %, Durchsatz 3,8 Tokens/Sekunde (+217 %)
2. INT8-Quantisierung über AWQ → VRAM von 26 GB auf 13 GB, damit optimale Batch-Grösse 8 statt 3
3. DCGM, Prometheus und Grafana eingeführt → volle Sichtbarkeit, Alerts bei Anomalien
4. Datenpipeline optimiert → Prefetching aktiviert, Datensätze in Parquet, Speicher in derselben Region

Gemessene Ergebnisse:

• GPU-Auslastung, 35 % → 68 % (+94 %)
• Durchsatz, 1,2 → 4,1 Tokens/Sekunde (+242 %)
• P95-Latenz, 800 ms → 320 ms (-60 %)
• Möglicher Wechsel von A100 40GB auf L40S 48GB, Kosten 3200 → 1800 CHF/Monat (-44 %)
• Jährliche Ersparnis, 16 800 CHF

Dieser Fall zeigt den ROI der GPU-Optimierung, rund 40 Stunden Engineering-Aufwand (Framework-Migration, Tests, Monitoring), Amortisation in weniger als drei Monaten über die Infrastrukturersparnis.

Zusammengefasst, drei Kernpunkte

Monitoring macht aus GPU-Kosten ein optimierbares Aktivum

DCGM, Prometheus und Grafana legen sofort Ineffizienzen offen, die ohne Instrumentierung unsichtbar bleiben. Die vier kritischen Metriken: GPU-Auslastung (Ziel 60-80 %), Speicherbandbreite (über 50 % bei memory-bound Lasten), Durchsatz (über 60 % der Theorie) und P95/P99-Latenz, zeigen genau, wo zu optimieren ist. Der Monitoring-Overhead (rund 5 % GPU-Leistung) ist gegenüber den Gewinnen vernachlässigbar: Laut der Studie der AI Infrastructure Alliance 2024 erreichen nur 7 % der Organisationen ohne strukturiertes Monitoring über 85 % Auslastung. Die übrigen 93 % verschwenden 15 bis 60 % Kapazität, also Zehntausende Franken pro Jahr und GPU. Monitoring ist keine Kostenstelle, sondern eine Investition mit sofortigem ROI.

Spezialisierte Inferenz-Frameworks vervielfachen die Leistung um das 2- bis 4-Fache

Standard-PyTorch und -TensorFlow sind nicht für Produktionsinferenz gebaut. Spezialisierte Frameworks (vLLM, TensorRT-LLM, SGLang) setzen Continuous Batching, optimierte KV-Cache-Verwaltung und spezialisierte CUDA-Kernels um und erzielen 2- bis 4-fache Durchsatzgewinne. vLLM erreicht laut den Clarifai-Benchmarks 2024 bei 100 gleichzeitigen Anfragen 4741 Tokens/Sekunde gegenüber rund 1500 mit Standard-PyTorch. Für allgemeine Produktion bietet vLLM den besten Kompromiss: Setup in 1-2 Tagen, OpenAI-kompatible API, native Hugging-Face-Integration. TensorRT-LLM zielt auf sehr niedrige Latenz (unter 50 ms TTFT), verlangt aber CUDA-Erfahrung. SGLang glänzt bei RAG und Agenten mit intensiver Kontextwiederverwendung (3-fache Gewinne über RadixAttention). Die Wahl des Frameworks hängt vom Anwendungsfall ab, nicht von einer absoluten Rangfolge.

Quantisierung setzt 40 bis 50 % Kapazität frei, ohne spürbare Einbussen

INT8-Quantisierung halbiert den VRAM-Bedarf gegenüber FP16, bei Qualitätsverlusten von 2 bis 5 %, die in der Produktion meist vertretbar sind. Ein 13B-Modell fällt von 26 GB (FP16) auf 13 GB (INT8) und erlaubt entweder die doppelte Batch-Grösse (2× Durchsatz) oder zwei Modelle auf derselben GPU. Fortgeschrittene Techniken (AWQ, GPTQ) optimieren den Kompromiss zwischen Leistung und Qualität. Bei Hopper-GPUs (H100) verbessert natives FP8 über die Transformer Engine den Durchsatz bei Transformer-Architekturen um 20 bis 50 %. Die systematische Prüfung der Quantisierung auf repräsentativen Datensätzen zeigt häufig, dass INT8 95 bis 98 % der FP16-Qualität zu einem Bruchteil der Kosten liefert. Auf Quantisierung in der Produktion zu verzichten heisst, 40 bis 50 % der bezahlten GPU-Kapazität zu verschwenden.