Rechenkapazität und Provisionierung
Beschaffung von GPU-Kapazität, Node-Pools, Treiber und CUDA-Stacks, die mit der Serving-Engine kompatibel gehalten werden.
Leitfaden KI-Inferenz
Infrastruktur und Betrieb
Alles rund um das Modell, was den Serving-Betrieb aufrechterhält: die Plattformkomponenten, die operative Disziplin, um Modelländerungen sicher auszuliefern, das Skalieren unter stoßweiser Last, der Betrieb über Regionen und Clouds hinweg und das Zusammensetzen mehrerer Modelle zu einem Produkt.
Was zur Inferenz-Infrastruktur gehört
Serving-Schicht
Die Inferenz-Engine plus ein vorgelagertes Gateway: Authentifizierung, Kontingente, Routing, Failover zwischen Backends.
Orchestrierung und Skalierung
Modelle auf Hardware einplanen, Autoscaling-Richtlinien, dynamische Zuteilung über Workloads hinweg.
Versionierung und Registry
Welches Modell, welche Gewichte, welcher Prompt und welche Konfiguration wo live sind; diese Frage beantworten zu können, ist die Voraussetzung für sichere Änderungen.
Sicherheit
Zugriffskontrolle auf Aufrufe und auf Modellartefakte, Schutz von Prompts und Ausgaben, Nachvollziehbarkeit, wer was geändert hat.
Kostensteuerung
Servingkosten je Workload und je Feature; die Hebel sind Modellwahl, passende Hardware, Batching, Routing und Skalierungsrichtlinien.
InferenceOps: Modelländerungen sicher ausliefern
Die Betriebspraxis, Modell-Deployments mit derselben Strenge zu behandeln wie Code-Deployments, angepasst an Artefakte, deren Fehler sich im Verhalten zeigen und nicht nur als Absturz:
- Release-Pipeline: standardisierte Deployment-Abläufe mit Validierung vor dem Release (Qualitäts-Regressionssuites, Prüfungen von Latenz und Token-Rate), bevor Traffic eintrifft.
- Schrittweiser Rollout: Canary- oder Blue-Green-Releases, die den Kandidaten unter echtem Traffic mit der Live-Version vergleichen, mit einem automatischen Rollback, der an diesen Vergleich gekoppelt ist.
- Fehlertoleranz: Retries mit Budget, Timeouts, Circuit Breaker und Load Shedding, damit ein degradiertes Modell oder ein degradierter Anbieter keine Kettenreaktion auslöst.
- Governance: eine Registry mit Lebenszyklusstatus, Verantwortlichkeiten, Audit-Trails und Compliance-Metadaten; Nachvollziehbarkeit des Deployments von der Anfrage zurück bis zur Modellversion.
- Kostenhygiene: Erkennung ungenutzter GPUs und Prüfung der Auslastung; ungenutzte reservierte Kapazität verbrennt Budget am unauffälligsten.
Schnelles Skalieren und das Cold-Start-Problem
Inferenz-Traffic kommt stoßweise, und GPU-Minuten sind in beide Richtungen teuer: Überprovisionierung verschwendet Geld, Unterprovisionierung verwirft Anfragen. Elastisches Skalieren für LLMs ist aus zwei Gründen schwieriger als klassisches Autoscaling:
Cold Starts dauern lange
Eine neue Replik zahlt drei Rechnungen nacheinander: eine GPU-Instanz provisionieren, ein großes Container-Image ziehen und zig Gigabyte an Gewichten aus dem Speicher in den GPU-Speicher laden. Gegenmaßnahmen setzen an jeder Stufe an: warme Pools, Caching und Verschlanken des Images, Gewichte auf schnellem lokalem Speicher oder parallel gestreamt. Scale-to-Zero spart Leerlaufkosten, legt aber den vollen Cold Start auf die erste Anfrage; entscheiden Sie das je Workload.
Die naheliegenden Signale führen in die Irre
Die CPU-Auslastung sagt wenig über einen GPU-gebundenen Dienst aus, und die gemeldete GPU-Auslastung kann hoch wirken, während der Chip kaum nützliche Arbeit leistet. Skalieren Sie stattdessen anhand von Signalen der Nachfrageseite: Warteschlangentiefe, laufende Nebenläufigkeit und Anfragerate, korreliert mit den Batch-Größen, die die Engine tatsächlich erreicht.
Verteilt, Multi-Region, Multi-Cloud
- Verteilte Inferenz erstreckt sich über zwei Ebenen: das Sharding eines Modells über GPUs und Knoten hinweg (Tensor-, Pipeline- und Expertenparallelität, behandelt unter Serving-Optimierung) sowie die Verteilung einer Flotte von Repliken über Zonen und Cluster hinweg, mit zustandsbewusstem Scheduling, Health Checks und Wiederherstellung nach Ausfällen.
- Warum Teams auf Multi-Region oder Multi-Cloud setzen: GPU-Knappheit und Preisunterschiede zwischen Anbietern und Regionen, Latenz für die Nutzer, Failover, Vorgaben zum Datenstandort (Auflagen im Stil der GDPR binden manche Daten an Rechtsräume) und die Vermeidung von Lock-in.
- Was dafür nötig ist: Modellartefakte nahe jedem Serving-Standort replizieren, globales Load Balancing mit kapazitäts- und compliancebewusstem Routing, automatisiertes Failover und einheitliche Observability mit Kostenzuordnung je Standort.
- Der Preis dafür: Traffic zwischen Regionen kostet echte Latenz und Egress-Gebühren, und jede zusätzliche Cloud vervielfacht die Betriebsfläche. Konzentrieren Sie standardmäßig; verteilen Sie nur aus einem benannten Grund.
Pipelines aus mehreren Modellen
Produktfeatures bestehen selten aus einem einzigen Modell. Eine Antwort mit Retrieval-Augmentierung verkettet ein Embedding-Modell, einen Retriever, oft einen Reranker, einen Generator und Sicherheitsprüfungen; Dokumenten-KI verkettet OCR, Layout, Klassifikation und Zusammenfassung; multimodale Assistenten ergänzen Encoder je Modalität. Spezialisten zu kombinieren schlägt ein monolithisches Modell, wenn die Stufen unterschiedliche Fähigkeiten benötigen, auf unterschiedlicher Hardware am besten laufen und sich unterschiedlich skalieren.
- Topologien: sequenzielle Stufen, paralleles Fan-out mit Zusammenführung und bedingtes Routing dazwischen.
- Skalieren und platzieren Sie jede Stufe unabhängig; ein kleiner Klassifikator braucht nicht die GPU-Klasse des Generators.
- Planen Sie das Latenzbudget über den gesamten Graphen explizit und halten Sie die Schnittstellen der Stufen stabil; Fehlermodi je Stufe müssen beobachtbar sein, sonst wird die Diagnose zum Raten.
- Abzugrenzen von Pipeline-Parallelität (ein Modell in Stufen zerlegt) und von agentischen Schleifen (dynamischer, modellgesteuerter Kontrollfluss); der Graph einer Pipeline wird von der Anwendung festgelegt.
Selbst bauen oder einkaufen, ehrlich kalkuliert
Selbst betriebene Inferenz-Infrastruktur bringt Kosten mit sich, die in der ersten Schätzung selten auftauchen: GPU-Beschaffung in einem knappen Markt, Autoscaling und Steuerung der Nebenläufigkeit von Hand gebaut und getunt, Optimierungen (Prefix-Caching, Disaggregation), die Plattformen mitbringen, Eigenbau-Stacks aber selbst umsetzen müssen, GPU-taugliche Observability und ein Abhängigkeitskarussell aus Engine-, Framework- und Treiberversionen, die im Gleichschritt wandern müssen. Dazu kommen der Klebstoff auf Anwendungsebene (Vor- und Nachverarbeitung, Konnektoren, Streaming- und Caching-Verhalten je Modell) und die knappen, teuren Fachkräfte, die das alles betreiben. Wägen Sie diese laufenden Engineering-Kosten gegen Plattformgebühren ab, dazu die Opportunitätskosten dessen, was das Team nicht baut; die richtige Antwort hängt von der Größenordnung ab, prüfen Sie sie mit wachsendem Volumen erneut.