Model Serving

Überblick

Model Serving überbrückt die Lücke zwischen trainierten Modellen und Produktionsanwendungen. Training produziert eine 7GB-Modelldatei—Serving lässt dieses Modell 10.000 Anfragen pro Sekunde mit 50ms Latenz beantworten. Die Herausforderung: KI-Modelle sind rechenintensiv (GPT-4 benötigt ~100 Milliarden Operationen pro Token), speicherintensiv (lädt GBs in VRAM) und ressourcenbeschränkt (GPUs kosten €3/Stunde). Effektives Serving erfordert Batching mehrerer Requests zusammen, Caching häufiger Anfragen, Quantisierung von Gewichten zur Speicherreduzierung und horizontale Skalierung über mehrere GPUs.

Model Serving vs Training

• **Training**: Batch-Processing, dauert Stunden/Tage, verwendet mehrere GPUs, kann Fehler wiederholen, offline
• **Serving**: Echtzeit, benötigt <100ms, einzelne GPU pro Request, muss Fehler elegant behandeln, benutzerseitig
• **Training-Optimierungen**: Große Batches, Gradient Checkpointing, Mixed Precision, verteilt über GPUs
• **Serving-Optimierungen**: Kleine Batch-Größe, Dynamic Batching, Quantisierung, KV-Cache, Speculative Decoding

Hauptherausforderungen beim Serving

• **Latenz**: Benutzer erwarten <100ms Antworten, aber große Modelle benötigen 500ms+ pro Forward-Pass
• **Durchsatz**: 1000+ Requests/Sekunde mit begrenzten GPU-Ressourcen handhaben
• **Speicher**: 70B-Parameter-Modell benötigt 140GB VRAM, aber H100 hat nur 80GB
• **Kosten**: GPU-Instanzen kosten €2-€8/Stunde, muss Auslastung maximieren, um Kosten zu rechtfertigen
• **Zuverlässigkeit**: 99,9% Uptime erforderlich, Modelle müssen Grenzfälle elegant behandeln
• **Skalierung**: Traffic variiert 10× zwischen Peak- und Off-Peak-Zeiten

Business-Integration

Model Serving bestimmt KI-Produkt-Lebensfähigkeit. Ein Chatbot mit 5-Sekunden-Antwortzeiten versagt—Benutzer brechen ab. Ein Bildgenerator, der €2/Bild kostet, ist nicht profitabel—Serving-Optimierungen reduzieren Kosten auf €0,05. Eine Empfehlungs-Engine, die unter Black-Friday-Traffic abstürzt, verliert Millionen—Autoscaling verhindert Ausfälle. Effektives Serving macht KI-Produkte schnell, günstig und zuverlässig genug für Produktion. Wichtige Business-Metriken: P95-Latenz (95% der Requests <100ms), Durchsatz (Requests/Sekunde/GPU), Kosten pro Inferenz (€0,001-€0,10) und Uptime (99,9%+).

Praxisbeispiel: E-Commerce-Suche

Eine E-Commerce-Seite verwendet ein 7B-Embedding-Modell für semantische Produktsuche. Initiales Deployment: naive Flask-API, lädt Modell bei jeder Anfrage, 3000ms Latenz, 1 Request/Sekunde Durchsatz. Nach Serving-Optimierungen: TorchServe mit Batching, quantisiertes INT8-Modell, Caching, Ergebnis: 80ms Latenz, 200 Requests/Sekunde Durchsatz, €0,002/Request Kosten. Dies ermöglicht Echtzeit-Suche für 10M Benutzer mit 4 GPU-Instanzen (€288/Tag) statt 800 Instanzen (€57.600/Tag).

Implementierungsbeispiel

Technische Spezifikationen

• **Ziel-Latenz**: P50 <50ms, P95 <100ms, P99 <200ms für Produktionssysteme
• **Durchsatz**: 100-1000 Requests/Sekunde/GPU je nach Modellgröße
• **Batch-Größe**: 8-32 optimal für Transformer, 64-128 für CNNs
• **Speicher**: INT8-Quantisierung reduziert VRAM um 4×, INT4 um 8× mit <2% Genauigkeitsverlust
• **Kosten**: €0,001-€0,10 pro Inferenz je nach Modellgröße und Optimierung
• **Frameworks**: TorchServe, TensorFlow Serving, vLLM, Ray Serve, Triton Inference Server

Best Practices

• Spezialisierte Serving-Frameworks verwenden (vLLM für LLMs, TorchServe für allgemeine Modelle) nicht Flask
• Batching aktivieren—8-32 Requests zusammen handhaben für 5-10× Durchsatzverbesserung
• Modelle zu INT8 oder INT4 quantisieren—reduziert Speicher 4-8× mit minimalem Genauigkeitsverlust
• Häufige Anfragen cachen—80% der Anfragen sind Wiederholungen, Caching spart 80% Rechenleistung
• P95/P99-Latenz überwachen nicht nur Durchschnitt—Tail-Latenz ist wichtig für Benutzererfahrung
• Autoscaling basierend auf Queue-Tiefe nicht CPU—GPU-Auslastung ist entscheidend
• Health Checks und Graceful Shutdown verwenden—vermeiden Sie Serving veralteter oder abgestürzter Modelle