LLM-Plattform im Produktivbetrieb: LLMOps für Updates, Störungen, Rollen und Rufbereitschaft

Was LLMOps auf einer privaten LLM-Plattform umfasst

LLMOps ist der LLM-Betrieb in Produktion, die Day-2-Arbeit einer privaten LLM-Plattform: Sie hält Modelle, Serving-Engine, GPU-Treiber und RAG-Index aktuell, ohne die Antworten zu beschädigen, auf die sich die Mitarbeitenden verlassen, und umfasst Kapazität, Störungen, Prüfungen der Zugriffsrechte und die Aufbewahrung von Logs. Nach dem Aufbau hat jede Komponente ihren eigenen Release-Kalender, und jede Änderung muss getestet, schrittweise ausgerollt und umkehrbar sein.

Nehmen Sie eine Plattform für 500 bis 2.000 Mitarbeitende auf zwei bis vier GPU-Servern. Typischerweise laufen darauf ein Chat-Modell, ein Embedding-Modell und ein Reranker auf vLLM, ein Gateway mit Schlüsseln und Query-Log, ein Chat-Frontend, ein Vektorindex, der aus Dokumentquellen gespeist wird, und Kubernetes mit dem GPU Operator von NVIDIA. Das sind rund zehn Komponenten, und jede wird in ihrem eigenen Takt aktualisiert. Die Aufgabe besteht darin, jeweils nur eine davon zu ändern und zu wissen, bevor Nutzer es bemerken, ob die Antworten so gut geblieben sind wie zuvor.

LLMOps vs. MLOps: Modelle bereitstellen, die Sie nicht trainiert haben

MLOps ist rund um Modelle entstanden, die ein Unternehmen selbst trainiert: Datenpipelines, Trainingsläufe, eine Model Registry und erneutes Training, wenn sich die Daten verschieben. Auf einer LLM-Plattform kommt das Modell meist als Checkpoint von seinem Herausgeber. Was Sie selbst steuern, sind der Checkpoint und die Präzision, die Sie bereitstellen, der System-Prompt und das Chat-Template, die Retrieval-Pipeline und die Engine-Einstellungen, und jedes davon kann Antworten ebenso stark verändern wie ein neues Modell.

Die Qualität wird daher an einem festen Satz von Fragen mit erwarteten Antworten oder Quellen gemessen, der vor jeder Änderung läuft. Wo ein Unternehmen zusätzlich Fine-Tuning betreibt, folgt dieser Teil der MLOps-Praxis, und das Ergebnis kommt wie jeder andere neue Checkpoint auf die Plattform.

Release-Zyklen von vLLM, NVIDIA-Treibern und Modellen

Das Release-Dokument von vLLM sagt: „Wir streben alle 2 Wochen ein reguläres Release an“, und seit v0.12.0 erhöht jedes reguläre Release die Minor-Version. v0.30.0 erschien am 22. September 2026 und v0.31.0 am 5. Oktober. Dasselbe Dokument warnt, dass „Abwärtskompatibilität nur für eine begrenzte Zahl von Minor-Releases garantiert ist“. Nach der Deprecation-Policy von vLLM wird eine Funktion über mehrere Minor-Releases hinweg zuerst als veraltet markiert, dann standardmäßig abgeschaltet und dann entfernt, und die Warnung nennt die Version, die sie entfernt. Zu den Breaking Changes von v0.31.0 gehören das Entfernen von tokenizer_mode="slow" und eine umbenannte Option für den Mamba-Prefix-Cache; ein Startskript, das noch eine der beiden übergibt, muss daher vor dem Upgrade angepasst werden.

Die Seite von NVIDIA zum Lebenszyklus der Treiber, aktualisiert am 9. September 2026, besagt, dass pro Jahr zwei Production Branches erscheinen, jeder mit Bugfixes und Sicherheitsupdates „für bis zu 1 Jahr“. Ein Long Term Support Branch erhält drei Jahre lang vierteljährlich oder nach Bedarf Bugfix- und Sicherheits-Releases. NVIDIAs Tabelle der unterstützten Treiber vom selben Datum führt R580 als Long Term Support bis Juni 2028 und R595 als Production bis März 2027. Unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen erklärt, wie Sie einen Zweig festlegen und welche CUDA-Versionen jeder ausführt.

Modellherausgeber veröffentlichen überarbeitete Checkpoints, wenn sie fertig sind, oft als neues Repository. Qwen etwa stellte Qwen3-235B-A22B-Instruct-2507 als „die aktualisierte Version“ des Non-Thinking-Modus von Qwen3-235B-A22B vor. Die Option --revision von vLLM akzeptiert „einen Branch-Namen, einen Tag-Namen oder eine Commit-ID“; legen Sie also den Commit fest, den Sie evaluiert haben. Geben Sie Anwendungen einen stabilen Modellnamen und ordnen Sie ihn der Version zu, die jede vLLM-Instanz bereitstellt. vLLM antwortet auf jeden Namen, der in --served-model-name angegeben ist, und versieht seine Prometheus-Metriken mit dem ersten als Label. Starten Sie jede Version mit ihrem eigenen Namen an erster und dem stabilen Namen an zweiter Stelle, sodass sie die Anfragen beantwortet, die Anwendungen senden, und auf einem Dashboard getrennt bleibt.

Day-2-Aufgaben, Häufigkeit und Verantwortliche

Vier Rollen teilen sich die Arbeit an der Plattform. Der Plattform-Owner, meist in der Infrastruktur angesiedelt, betreibt GPU-Server, Treiber, Kubernetes und die Serving-Engine. Der Modell-Owner wählt die Checkpoints aus, pflegt den Evaluationssatz und gibt jede Änderung frei, die Antworten verändern kann. Ein Daten-Owner für jede RAG-Quelle entscheidet, welche Dokumente aufgenommen werden, welche Verzeichnisgruppen sie lesen dürfen und wann sie entfernt werden. Die IT-Sicherheit verantwortet die Prüfung der Zugriffsrechte, das Query-Log und Hinweise auf Schwachstellen. Eine Person kann zwei Rollen innehaben.

Häufigkeiten und Verantwortliche sind unsere Beispiele für eine Plattform mit 500 bis 2.000 Nutzern, keine Vorgaben der Hersteller. Angaben zu Releases aus RELEASE.md von vLLM und der Seite von NVIDIA zum Lebenszyklus der Treiber vom 9. September 2026.

Ein Index, der mit einem Embedding-Modell erstellt wurde, lässt sich nicht mit Abfragevektoren eines anderen durchsuchen. Der Migrationsleitfaden von Qdrant sagt: „Ein Modellwechsel erfordert, alle Vektoren Ihrer Collection neu einzubetten“, baut die neue Collection neben der alten auf und schaltet auf sie um, sobald sie mindestens so gut abschneidet. Die Werte für die Kapazitätsprüfung stammen aus den Serving-Metriken, die unser Leitfaden zum LLM-Monitoring mit vLLM-Metriken definiert.

LLM-Modelle in Produktion aktualisieren: Evaluation, Canary und Rollback

Ein Modellwechsel, ein Engine-Upgrade und ein neues Chat-Template folgen demselben Verfahren. Unser Leitfaden zur LLM-Evaluation vor Modell-Upgrades behandelt den Evaluationsschritt und seine Freigabekriterien.

1. Halten Sie fest, was sich ändert, die festgelegte Revision oder Version und den alten Stand, zu dem Sie zurückkehren.
2. Führen Sie den Evaluationssatz auf einer Testinstanz gegen die neue Version aus und vergleichen Sie ihn mit den Ergebnissen der aktuellen Version.
3. Stellen Sie die neue Version neben der alten bereit, mit ihrem eigenen Modellnamen an erster und dem stabilen Namen an zweiter Stelle.
4. Leiten Sie einen kleinen Anteil des Traffics oder nur eine Pilotgruppe auf sie und beobachten Sie Fehler, Latenz und Rückmeldungen der Nutzer.
5. Verlagern Sie den restlichen Traffic schrittweise und lassen Sie die alte Version laufen, bis die Änderung abgeschlossen ist.
6. Ein Rollback setzt den Anteil der neuen Version auf null; halten Sie das Ergebnis danach im Änderungsprotokoll fest.

Die Kubernetes Gateway API teilt Traffic über Gewichte an einer HTTPRoute auf, und ihr Leitfaden hält fest, dass „das Gewicht eine proportionale Aufteilung des Traffics angibt (statt eines Prozentsatzes)“, mit 90 und 10 als Canary-Beispiel. Laufen beide Versionen gleichzeitig, brauchen beide GPU-Speicher; planen Sie das Canary also auf einem Server mit freier Kapazität oder verlagern Sie für die Dauer ein Replikat der alten Version. Bei einer Änderung innerhalb eines Deployments kehrt kubectl rollout undo zur vorherigen Revision zurück, und Kubernetes behält standardmäßig 10 alte ReplicaSets für ein Rollback. Ein Rollout, der innerhalb von progressDeadlineSeconds, standardmäßig 600 s, keinen Fortschritt macht, gilt als fehlgeschlagen und meldet ProgressDeadlineExceeded; der Controller bearbeitet ihn weiter und rollt nicht von selbst zurück. Ein Replikat, das einen großen Checkpoint über das Netzwerk lädt, kann länger brauchen; setzen Sie die Frist daher über die Ladezeit, die Sie in Tests sehen.

Im Rahmen unserer Leistung Private AI/ML bauen und betreuen wir die Plattform und schulen Ihr Team für ihren Betrieb. Nennen Sie uns die Modelle und Engines, die Sie betreiben, und wie Änderungen heute in die Produktion gelangen.

Runbooks für typische Störungen einer LLM-Plattform

Schreiben Sie für jedes wiederkehrende Symptom ein einseitiges Runbook.

Erste Prüfungen aus den Leitfäden von vLLM zur Fehlersuche und zum Speicher (September 2026) und aus NVIDIAs XID-Katalog; die nächsten Schritte sind unsere Vorschläge.

Der Speicherleitfaden von vLLM nennt Tensor-Parallelismus, quantisierte Modelle, ein kürzeres max_model_len, ein kleineres max_num_seqs und weniger CUDA Graphs als Wege, den Speicherbedarf zu senken, und das Flag enforce_eager schaltet die Graph-Erfassung vollständig ab. Für eine Instanz, die keinen Fortschritt mehr macht, schlägt sein Leitfaden zur Fehlersuche VLLM_LOGGING_LEVEL=DEBUG, CUDA_LAUNCH_BLOCKING=1 und für die Kommunikation zwischen mehreren GPUs NCCL_DEBUG=TRACE vor. Setzen Sie diese auf einem Replikat ein, das keinen Nutzer-Traffic trägt. Unser Leitfaden zum GPU-Server-Monitoring mit DCGM erklärt, welche XID-Meldungen einen Reset oder einen geleerten Knoten verlangen. Das SRE-Buch verlangt Postmortems „nach bedeutenden Vorfällen“ mit vollständiger Zeitleiste, und jedes sollte mit einem geänderten Runbook oder Alarm enden.

SLOs und Rufbereitschaft für einen internen LLM-Dienst

Das SRE-Buch definiert ein SLO als „einen Zielwert oder Wertebereich für ein Service-Level, das durch einen SLI gemessen wird“, und ergänzt, dass es „sowohl unrealistisch als auch unerwünscht“ ist, auf der Einhaltung von SLOs zu 100 Prozent der Zeit zu bestehen. Es zieht Perzentile Mittelwerten vor und behandelt die zulässige Unterschreitung als Fehlerbudget. Für einen internen Assistenten decken drei SLOs das meiste ab, was Nutzer bemerken. Unsere Beispielziele sind: 99,5 Prozent der Anfragen während der Geschäftszeiten in jedem Monat ohne Fehler beantwortet; 95 Prozent der ersten Token innerhalb von 2,5 s, gemessen am Gateway; und kein Release, dessen Evaluationsergebnisse unter denen der ersetzten Version liegen. Ist das Fehlerbudget des Monats aufgebraucht, warten Änderungen, bis die Ursache behoben ist.

Die Rufbereitschaft ergibt sich aus diesen Zielen. Das SRE-Buch von Google bemisst eine Rufbereitschaft über alle Stunden des Tages, mit einer primären und einer sekundären Bereitschaft, mit mindestens acht Ingenieuren an einem Standort oder sechs je Standort bei zwei Standorten und begrenzt die Rufbereitschaft auf 25 Prozent der Zeit eines Ingenieurs. Bei einer Plattform, die zwei oder drei Personen betreiben, legen Sie fest, zu welchen Stunden der Assistent verfügbar sein muss, ob ein Ausfall außerhalb dieser Zeiten bis zum nächsten Arbeitstag wartet und wer welchen Teil abdeckt; ein Supportvertrag nennt dabei seine Zeiten und Reaktionszeiten. Unser Leitfaden zur LLM-Hochverfügbarkeit mit zwei GPU-Knoten behandelt die Redundanz, durch die Einsätze seltener werden.

Nach dem Aufbau betreiben Ihre eigenen Mitarbeitenden die Plattform, oder wir betreuen sie unter einem vereinbarten SLA. Schreiben Sie uns, wer Ihre Plattform heute betreibt und welche Unterstützung Sie von einem Anbieter wünschen.

Prüfung der Zugriffsrechte und Aufbewahrung des Query-Logs

Der Zugriff auf Modelle und RAG-Quellen sollte Verzeichnisgruppen folgen, sodass eine Prüfung bedeutet, die Gruppenmitgliedschaften mit den Entscheidungen der Daten-Owner abzugleichen. Die Durchführungsverordnung (EU) 2024/2690, die für die in ihrem Artikel 1 aufgezählten Anbieter digitaler Infrastruktur und digitaler Dienste gilt, verlangt in Nummer 11.2.3 ihres Anhangs, dass sie „die Zugangs- und Zugriffsrechte in geplanten Zeitabständen“ überprüfen und die Ergebnisse dokumentieren. Für andere Unternehmen ist sie ein brauchbarer Maßstab. Prüfen Sie Dienstkonten und Gateway-Schlüssel im selben Zyklus.

Das Query-Log hält fest, wer was gefragt hat und welche Quellen verwendet wurden, und enthält daher personenbezogene Daten. Nach Artikel 5 Absatz 1 Buchstabe e DSGVO werden personenbezogene Daten in einer Form gespeichert, die die Identifizierung der betroffenen Personen „nur so lange ermöglicht, wie es für die Zwecke, für die sie verarbeitet werden, erforderlich ist“, und nach Nummer 3.2.5 desselben Anhangs „führen und sichern“ die Einrichtungen in ihrem Anwendungsbereich „die Protokolle für einen vorab festgelegten Zeitraum“ und schützen sie vor unbefugten Zugriffen oder Änderungen. Legen Sie die Aufbewahrungsfrist und die Personen, die das Log lesen dürfen, vor dem ersten Eintrag fest und automatisieren Sie die Löschung. Wie lange der Text aufbewahrt werden darf, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

Was wir tun

Unsere Leistung Private AI/ML übernimmt das Deployment offener und kommerzieller Modelle on-premise mit vLLM, Ollama oder NVIDIA AI Enterprise, wo es passt auf einer Kubernetes-basierten Plattform, mit Protokollierung von Anfragen und Antworten sowie Daten- und Berechtigungsverwaltung. Wir bauen und betreuen die Plattform und schulen Ihr Team, sie zu betreiben und weiterzuentwickeln; danach ist es Ihre Wahl, ob Ihre eigenen Mitarbeitenden sie betreiben oder wir sie unter einem vereinbarten SLA betreuen. Eurokommerz hält den Vertrag und liefert die GPU-Server, das Engineering kommt von unserem Engineering-Partner Vixen.UNO. Das erste Gespräch ist kostenlos, und der Preis des technischen Assessments steht vor Beginn fest. Wie wir während eines Projekts mit Daten umgehen, beschreibt unsere Seite Sicherheit & Compliance.

FAQ