Kleine Modelle fressen große GPU-Budgets durch Prealloc

Kleine Modelle sollten Kosten senken. In der Praxis belegen vier vLLM-Instanzen oft vier GPUs, weil jede Engine den Großteil des Speichers vorab greift. Der Engpass ist nicht die Karte. Es ist der Serving-Stack.

Das Wichtigste in Kürze

Verwandt:Das Modell-Laden frisst die teure TPU-Stunde  /  Kimi K3: Wenn KI die eigene Infrastruktur baut

Vier Modelle, vier Karten, ein Denkfehler

FinOps-Reports zeigen dann wachsende GPU-Kosten trotz „kleinerer“ Modelle. Die Story im Steering Committee klingt paradox. In den Node-Metrics ist sie banal: vier Prozesse, vier Allokationen, vier Rechnungen. Ohne Packing-Disziplin wird Model-Specialization zum Kostentreiber statt zum Sparhebel.

Teams zerlegen den Agent-Stack in Spezialisten: Embedding, Rerank, Structured Extraction, Generation. Jedes Stück ist klein. Jede vLLM- oder TEI-Instanz verhält sich trotzdem wie der alleinige Eigentümer der GPU. Wer 90 Prozent VRAM beim Start allokiert, lässt dem Nachbarn keinen Platz. Das Ergebnis ist Hardware-Multiplikation trotz „Small Models“.

Serverless Inference löst das nur scheinbar. Cold Starts von Dutzenden Sekunden bis in Richtung einer Minute sind für Reranker in der Suchstrecke tödlich. Warm-Pools kosten wieder Idle. On-Prem oder reserved GPU ohne Shared Serving ist die teure Variante derselben Lücke.

Was Shared Inference wirklich braucht

Ein Server-Prozess, der mehrere Modelle kennt. Load on first use. LRU-Eviction, wenn Speicher eng wird. Kein process-pro-Modell-Dogma. Open-Source-Projekte und kommerzielle Inference-Router zielen genau dorthin. Der Name des Projekts ist austauschbar. Die Architekturfrage bleibt: Wer owns den Memory-Scheduler?

Platform-Teams sollten drei SLOs festnageln. Erstens p95-Latenz pro Tool-Typ. Zweitens VRAM-Headroom unter Last. Drittens Euro pro 1 Million Tokens über den gemischten Stack, nicht pro Einzelmodell im Idealzustand. Ohne diese drei Zahlen bleibt jede GPU-Bestellung Bauchgefühl.

Betriebsregeln, die Geld sparen

Trennt Prefill-schwere und Decode-schwere Last, wenn eure Hardware das hergibt. Cached Models für heiße Pfade, lazy load für Randtools. Keine stillen Shadow-Deployments zweier Full-Engines „nur zum Testen“ auf Production-GPUs. Observability auf Model-Load-Events: Jeder Load ist ein Kosten- und Latenz-Spike.

Gegen den Cloud-API-Pfad gewinnt Shared On-Box, wenn Traffic stabil und Daten residual bleiben sollen. Gegen den reinen Single-Model-Server gewinnt Shared Serving, sobald mehr als zwei Modelle dauerhaft heiß sind. Gegen naives Kubernetes-pro-Pod-pro-Modell gewinnt ein Inference-Daemon mit klarer Quota.

Kubernetes macht das Problem oft schlimmer, wenn jede Inference-Variante als eigener Deployment mit GPU-Request 1 läuft. Der Scheduler sieht Ressourcen-Anfragen, nicht Modell-Überlappung. Ohne Device-Plugin-Strategien und gezieltes Packing entstehen idle VRAM-Inseln neben wartenden Pods.

Ein pragmatischer Mittelweg für viele DACH-Teams: ein Inference-Node-Pool mit festem Shared-Server pro Node, davor ein leichter Router. Autoscaling auf Node-Ebene, nicht pro Modell-Pod. Spezielle High-QPS-Modelle dürfen dediziert bleiben. Alles andere teilt sich.

Dokumentiert den Worst Case. Was passiert, wenn das Generator-Modell den Reranker verdrängt? Ist der LRU-Pfad akzeptabel oder braucht ihr Pinning für die Top-2-Modelle? Ohne Pinning-Policy wird der erste Traffic-Spike zum Latenz-Chaos.

Montag-Checkliste

Listet alle Inference-Prozesse und deren VRAM-Claims. Sucht doppelte Base-Weights. Simuliert den Fall „Reranker + Generator gleichzeitig“. Wenn dafür zwei Karten brennen, habt ihr kein Kapazitätsproblem. Ihr habt ein Packing-Problem. Löst das, bevor die nächste Bestellung rausgeht.

Häufige Fragen

Bildquelle: KI-generiert (Juli 2026)