Schluss mit verbranntem LLM-Budget: kosteneffizientes LLMOps

Hinweis: Dieser Beitrag wurde aus dem Englischen übersetzt. Fachbegriffe, Code und Befehle wurden bewusst im Original belassen.

In vielen Organisationen sind die wichtigsten Kostentreiber von LLM-Initiativen operative Ineffizienzen rund um das Model Serving – und nicht die Modellauswahl: ungenutzte GPUs, träges Startverhalten, unkontrolliertes Speicherwachstum und zonenübergreifender Netzwerkverkehr.

Dieses Muster tritt typischerweise auf, wenn aus einem Piloten ein dauerhaft verfügbarer Dienst wird, die Lastschwankungen zunehmen und weitere Teams die Plattform nutzen. In dieser Phase steigen die Infrastrukturausgaben häufig schneller als die Servicequalität, während die GPU-Auslastung niedriger ausfällt als erwartet und p95-Latenzziele verfehlt werden.

In der Praxis werden die Betriebskosten von LLMs häufig durch Wartezeit getrieben statt durch aktive Inferenz: CPU-Vorverarbeitung, Queueing, Cold Starts, Image Pulls, Downloads von Modellgewichten, zonenübergreifende Hops und Storage-I/O. Ziel ist es also, bezahlte Leerlaufzeit zu reduzieren.

Dieser Blogbeitrag geht diese Themen der Reihe nach durch und benennt Best Practices, um kosteneffizientes LLMOps auf Kubernetes zu erreichen.

Observability: die Grundvoraussetzung

Um Kosten zu senken, muss zunächst Observability geschaffen werden, damit sich die Kostenquellen nachvollziehen lassen. Kosten lassen sich als SRE-Problem mit Unit Economics behandeln: Statt monatliche Infrastrukturausgaben zu überwachen, können Organisationen Kosten auf Ebene einzelner Arbeitseinheiten messen (etwa Kosten pro tausend Tokens) und so bessere Erkenntnisse gewinnen. Dafür genügt die GPU-Auslastung allein nicht; es braucht eine direkte Verbindung zwischen Durchsatz und Nutzererlebnis. Zentrale Kennzahlen sind Tokens pro Sekunde, Kosten je 1.000 Tokens und p95-Latenz – korreliert mit dem GPU-Duty-Cycle.

Lässt sich die p95-Latenz nicht auf Queueing, Batching, Netzwerkplatzierung oder Storage-Throttling zurückführen, zielen Optimierungsbemühungen vermutlich auf die falsche Schicht. Instrumentieren Sie den Inferenzpfad wie jeden anderen Produktivdienst: Requestraten, Queue-Tiefe, Retries, Timeouts, Sättigungssignale, GPU-Telemetrie auf Node-Ebene und Zuordnung je Namespace.

Mindestens sollte jede Anfrage in Wartezeit in der Queue, Modellausführungszeit und nachgelagerte Retrieval-Zeit aufgeschlüsselt werden. Ohne diese Aufteilung bleibt jede Kostenanalyse spekulativ.

GPU-Effizienz auf k8s: keine ungenutzten Beschleuniger mehr bezahlen

Auf Kubernetes zählt es zu den häufigsten Verschwendungsquellen, für Beschleuniger zu zahlen, die aufgrund von Scheduling- und Dimensionierungsentscheidungen brachliegen. Ein wiederkehrendes Anti-Pattern besteht darin, jedem Pod eine GPU zuzuweisen – selbst wenn der Serving-Prozess das Gerät nicht auslastet oder der Traffic stark schwankt.

Sofern die Plattform es unterstützt und es im Risikomodell vertretbar ist, kann GPU-Sharing bzw. Mandantenfähigkeit die Packungsdichte drastisch verbessern. Solche Ansätze erfordern belastbare Isolationsmechanismen und klare SLO-Grenzen (Service Level Objectives). Auch ohne Sharing lassen sich erhebliche Einsparungen erzielen – durch passend dimensionierte GPU-Typen sowie Requests und Limits und indem GPU-Nodes über Taints/Tolerations und Affinities für GPU-Workloads reserviert werden.

Eine nützliche Diagnose lautet: Wenn Cluster für Lastspitzen hochskalieren, der durchschnittliche GPU-Duty-Cycle aber niedrig bleibt, liegt der Engpass häufig beim Scheduling und Anfragefluss – nicht bei der reinen GPU-Kapazität.

Durchsatz-Tuning: Batching, Routing und Autoscaling

Sobald das Scheduling stabil läuft, ist die Inferenzeffizienz ein großer Hebel für Plattformteams. Viele schlecht ausgelastete Cluster arbeiten mit zu kleinen Batches. Erhöhen Sie bei Online-Traffic die Nebenläufigkeit und aktivieren Sie dynamisches oder kontinuierliches Batching, sofern die Runtime es unterstützt. Der Kompromiss ist die Latenz: Größere Batches verbessern in der Regel Durchsatz und Kosten je Token, können aber die Tail-Latenz erhöhen, wenn das Anwachsen der Queue nicht kontrolliert wird. Am robustesten ist adaptives Batching innerhalb definierter Latenzbudgets.

Faustregel: Erhöhen Sie Batching und Nebenläufigkeit nur, solange p95 innerhalb des SLO-Budgets bleibt und die Wartezeit in der Queue stabil ist. Die Wartezeit muss langsamer wachsen als der Durchsatz.

Kombinieren Sie dies mit einer Routing-Policy: Leiten Sie den Großteil der Anfragen an kleinere Modelle und behalten Sie größere Modelle für Fallbacks, unsichere Fälle oder Premium-Pfade vor. In vielen Umgebungen senkt das die GPU-Zeit erheblich, hält die wahrgenommene Qualität aufrecht und verringert den Skalierungsdruck bei Lastspitzen.

Die Cluster-Mechanik ist ebenso wichtig wie die Modell-Mechanik. GPU-Node-Pools sollten isoliert und mit GPU-bewussten Constraints autoskaliert werden. Andernfalls zahlen Organisationen für Grundkapazität, die nur gelegentliche Spitzen bedient. Scale-ups sollten nicht von langsamen Image Pulls und Downloads von Modellgewichten dominiert werden; hängt die Node-Bereitschaft an großen Artefakten, reagiert das Autoscaling zu spät und überkompensiert.

Das Zwischenspeichern von Modellgewichten auf Node-Ebene und schlanke Container-Images sind Optimierungen mit großer Wirkung. Wer Cold Starts in Warm Starts verwandelt, muss weniger überprovisionieren, um Latenzen abzusichern.

Storage: der leise Budgetkiller

Storage ist der leise Budgetkiller im LLMOps, weil er unauffällig und unbegrenzt wächst: Experiment-Artefakte, Evaluierungsergebnisse, Checkpoints, Logs, Traces, Embeddings und Vektorindizes. Wird die Aufbewahrung nicht ausdrücklich gesteuert, ist praktisch unbegrenzte Anhäufung das Standardergebnis.

Wenden Sie Lifecycle-Policies konsequent an: TTL (Time to Live) für Logs und Traces, automatisiertes Aufräumen von Artefakten und klare Regeln, was langfristig aufbewahrt wird. Auch Storage-Tiering ist wirksam – etwa Hot Storage für häufig genutzte Artefakte und Cold Storage für selten genutzte Daten. Das gelingt allerdings nur, wenn ad hoc angelegte PVCs (PersistentVolumeClaims) und ungemanagte Buckets über Plattformrichtlinien kontrolliert werden. Überwachen Sie auf Kubernetes fortlaufend PVC-Wildwuchs und die Nutzung von Storage Classes.

Embeddings verdienen besondere Aufmerksamkeit, weil sie wiederkehrende Rechenkosten mit dauerhaftem Speicherwachstum verbinden. Erneutes Embedding unveränderter Dokumente ist eine verbreitete Quelle vermeidbarer Ausgaben – häufig verursacht durch Pipelines, die Content-Hashes, Versionen oder Chunking-Parameter nicht nachhalten. Änderungen am Chunking können die Indexgröße rasch anwachsen lassen. Ist das Chunking zu fein, wachsen sowohl Rechenaufwand als auch Speicherbedarf übermäßig. Embedding-Pipelines sollten daher den Grundprinzipien einer Datenplattform folgen: Idempotenz, Caching und explizite Änderungserkennung halten die Kosten stabil.

Ein häufiger Fehlerfall: In einer neuen Pipeline-Version werden die Chunking-Standards geändert – und die Indexgröße verdoppelt sich versehentlich in kurzer Zeit. Versionieren Sie die Chunking-Strategie explizit und koppeln Sie erneutes Embedding an eine Änderungserkennung.

Falls in Ihrer Organisation noch keine Aufbewahrungsstandards existieren, beginnen Sie mit einer cloud-neutralen Basisrichtlinie und justieren Sie von dort:

Netzwerk: der überraschende Kostenfaktor

Netzwerkgebühren sind eine häufige Quelle ungeplanter Ausgaben, besonders in Multi-AZ-Setups. Zonenübergreifende Aufrufe erhöhen Latenz und Kosten – und entstehen leicht unbeabsichtigt, wenn Dienste ohne bewusste Platzierung über Zonen verteilt werden.

Platzieren Sie stark interagierende Komponenten nach Möglichkeit gemeinsam und legen Sie die Topologie bewusst fest. Überquert jede Anfrage mehrfach AZ-Grenzen, steigen die Netzwerkkosten ohne entsprechenden geschäftlichen Nutzen. Wiederholte große Downloads – etwa von Modellgewichten und Container-Images – sind eine weitere vermeidbare Ausgabenquelle.

Caching auf Node-Ebene, clusternah platzierte Registries und passende Eviction-Policies senken sowohl Startzeit als auch Netzwerkkosten. Auch die Payload-Größe sollte gesteuert werden: Prompts und abgerufener Kontext können sehr groß werden. Plattformseitige Limits für die Kontextgröße, sinnvolle Standardwerte und optionale Komprimierung reduzieren das Netzwerkvolumen und verbessern zugleich die Reaktionszeiten.

Bei RAG-Workloads sollte die Lokalitätsplanung Retriever, Reranker, Vektorspeicher und Model Serving einschließen. Werden diese standardmäßig über verschiedene Zonen verteilt, steigen Latenz und Egress-Kosten in der Regel mit der Zeit.

Steigt der Egress nach einem Deployment plötzlich an, prüfen Sie zuerst die Platzierungsrichtlinien. In vielen Clustern ist Topologie-Drift die Hauptursache – noch vor Regressionen auf Anwendungsebene.

FinOps für LLMOps

Keine dieser Optimierungen ist ohne Governance dauerhaft tragfähig. An diesem Punkt wird FinOps für LLMOps zu einer Disziplin des Platform Engineering.

Anomalieerkennung ist für Egress, Speicherwachstum und Auslastungsregressionen erforderlich, da die meisten Kostensteigerungen unbeabsichtigt entstehen. Die Steuerungsebene sollte Budgets und Alerts, Quotas je Namespace sowie Schutzmechanismen an den Endpunkten umfassen – etwa Rate Limits, maximale Token-Grenzen und Timeouts –, um ausufernde Retries oder Prompt-Schleifen zu verhindern.

Verantwortlichkeiten sollten eindeutig sein: Für jeden Namespace oder Dienst braucht es benannte Verantwortliche für Budget, SLO und Modell-Routing-Policy. Bewährt hat sich ein wöchentlicher Anomalie-Review und ein monatlicher Review zur Anpassung von Quotas und Aufbewahrungsrichtlinien.

Zusammenfassung

LLM-Kosten auf Kubernetes werden selten allein von den Modellpreisen dominiert. Ausschlaggebend sind meist Cluster-Effizienz, Aufbewahrungsgewohnheiten und Topologieentscheidungen.

Nutzen Sie die folgende Triage-Übersicht als operativen Einstieg:

Wenn LLM-Serving als kostenintensives, latenzsensitives verteiltes System gemanagt wird, können Organisationen ihren ROI auch bei wachsender Nutzung sichern: Unit Economics messen, GPU-Auslastung optimieren, intelligent batchen, den Storage-Lebenszyklus steuern und für Workload-Lokalität entwerfen.

Wenn Sie Potenzial sehen, Ihre bestehende Plattform um LLMOps-Fähigkeiten zu erweitern, oder gezielte Beratung zur Integration von kosteneffizientem LLMOps in Ihre Abläufe benötigen, sprechen Sie uns an oder vereinbaren Sie ein 30-minütiges Gespräch – wir erläutern Ihnen alles Weitere und arbeiten gemeinsam an Ihren Zielen.