LLMOps und MLOps

LLMOps steht für Large Language Model Operations. Gemeint sind die Verfahren, Werkzeuge und Zuständigkeiten, mit denen ein Unternehmen eine Anwendung auf Basis eines Sprachmodells verlässlich in den Alltag bringt und dort hält, etwa einen Chatbot im Kundenservice, eine Textprüfung in der Redaktion oder die Vorsortierung eingehender Anfragen. Microsoft beschreibt das Feld unter dem Namen GenAIOps als Praxis, große Sprachmodelle in der Produktion zu betreiben. Databricks zählt unter anderem Bewertung, Verwaltung von Prompts und Konfiguration, Kostenkontrolle und Überwachung dazu. Eine Norm für den Begriff gibt es nicht.

Der Begriff steht in einer Reihe. DevOps verbindet Softwareentwicklung und Betrieb mit automatischer Auslieferung und Überwachung. MLOps überträgt diese Arbeitsweise auf maschinelles Lernen, bei dem Daten, Training und Modellbewertung hinzukommen. LLMOps setzt bei Anwendungen an, deren Kern meist ein fremdes Sprachmodell ist, das per Schnittstelle angebunden wird und das der Anbieter ändern oder abschalten kann.

Für Führungskräfte beantwortet LLMOps die Frage, was nach einem gelungenen Pilot geschieht. Ohne geregelten Betrieb weiß niemand, ob eine Anwendung nach einem Modellwechsel noch so gut arbeitet wie beim Start, wer bei Fehlern eingreift und was sie im Monat kostet. Diese drei Fragen entscheiden, ob eine KI-Anwendung im Alltag bleibt.

Von DevOps über MLOps zu LLMOps.

Google beschreibt MLOps als Ingenieurskultur und Praxis, die Entwicklung und Betrieb von Systemen mit maschinellem Lernen zusammenführt. Neu gegenüber DevOps ist nach dieser Darstellung das laufende Nachtrainieren: Modelle werden mit neuen Daten automatisch neu trainiert und ausgeliefert, weil sich die Welt ändert, die sie abbilden.

Als frühe Grundlage des Feldes gilt ein Aufsatz von Google-Forschern um D. Sculley auf der Konferenz NeurIPS 2015. Er beschreibt maschinelles Lernen als Quelle versteckter technischer Schulden: Der eigentliche Modellcode ist nur ein kleiner Teil eines echten Systems, die Wartungskosten entstehen in Datenabhängigkeiten, Konfiguration, Rückkopplungen und Veränderungen der Umgebung.

Bei LLMOps verschiebt sich der Schwerpunkt. Die meisten Unternehmen trainieren kein eigenes Sprachmodell, sondern rufen ein fertiges Modell eines Anbieters auf. Dessen Gewichte lassen sich nicht ändern. Die Arbeit liegt deshalb bei Prompts, beim Kontext aus eigenen Daten, bei der Bewertung offener Antworten und bei den Kosten je Aufruf. Erst wenn ein Unternehmen ein Modell mit eigenen Daten nachtrainiert, also Fine-Tuning betreibt, kehren klassische MLOps-Aufgaben wie Trainingsdaten und Modellversionen zurück.

Versioniert wird mehr als der Code.

Das Verhalten einer Sprachmodell-Anwendung hängt an mehreren Teilen, die sich einzeln ändern können: der System Prompt und die Vorlagen für Anfragen, das Modell mit seiner genauen Versionskennung, Einstellungen wie die maximale Antwortlänge, die angebundenen Wissensquellen und die Werkzeuge, die ein Agent aufrufen darf. LLMOps behandelt jeden dieser Teile wie Programmcode. Jede Änderung bekommt eine Version, und jede Antwort im Protokoll lässt sich der Kombination zuordnen, die sie erzeugt hat.

Warum das zählt, zeigte 2023 eine Untersuchung von Lingjiao Chen, Matei Zaharia und James Zou. Sie verglichen die Fassungen von GPT-3.5 und GPT-4 vom März und Juni 2023 auf mehreren Aufgaben. Das Verhalten unterschied sich erheblich, bei einzelnen Aufgaben wurde die neuere Fassung deutlich schlechter. Hinter demselben Produktnamen kann sich also ein anderes Verhalten verbergen.

Daraus folgen zwei Regeln. Wo der Anbieter feste Versionskennungen anbietet, nutzt die Anwendung diese statt eines Namens, der automatisch auf die neueste Fassung zeigt. Und jede Änderung durchläuft denselben Ablauf: ändern, mit festen Testfällen prüfen, freigeben, im Betrieb beobachten.

Evals und Überwachung messen die Qualität.

Sprachmodelle liefern keine eindeutige Soll-Antwort, die sich wie bei klassischer Software mit einem Test abhaken ließe. Qualität wird deshalb gegen Kriterien und Referenzfälle geprüft. Vor jeder Änderung laufen Evals, also ein fester Satz typischer und schwieriger Fälle mit bekannten guten Antworten. Bewertet wird durch Regeln, durch Menschen in Stichproben oder durch ein zweites Modell, das Antworten nach festgelegten Maßstäben einstuft und selbst regelmäßig gegen menschliche Urteile geprüft wird.

Im Betrieb kommt die laufende Überwachung hinzu: Fehlerraten, Antwortzeiten, Abbrüche, Rückmeldungen der Nutzer, Anteil der Fälle, die an Menschen gehen, und Stichproben auf erfundene Aussagen. Auch ohne Modellwechsel kann die Qualität sinken, wenn sich die Anfragen ändern, etwa durch ein neues Produkt oder eine Gesetzesänderung.

Einen Rahmen dafür bietet das AI Risk Management Framework des US-amerikanischen National Institute of Standards and Technology (NIST) vom Januar 2023. Es ordnet Risikomanagement in vier Funktionen: Govern, Map, Measure und Manage. LLMOps liefert vor allem die laufenden Messungen und Eingriffe im Betrieb. Das Protokoll mit Eingabe, Ausgabe, Versionen, Dauer und Kosten ist dafür die Grundlage. Weil darin oft personenbezogene Daten stehen, braucht es Zugriffsrechte und Löschfristen.

Kosten entstehen je Aufruf.

Bei MLOps fallen die großen Kosten im Training und in der Infrastruktur an. Bei LLMOps zahlt ein Unternehmen meist je Aufruf, abgerechnet nach Token, den Texteinheiten, die das Modell liest und schreibt. Anbieter berechnen Eingabe und Ausgabe in der Regel getrennt.

Die Kosten hängen weniger am Listenpreis als an der Bauweise. Teure Muster sind lange Kontexte, weil jede Anfrage den gesamten Gesprächsverlauf und viele Dokumentstellen mitschickt, ein großes Modell für einfache Aufgaben, automatische Wiederholungen nach Fehlern und Agenten, die das Modell für eine Aufgabe viele Male aufrufen. Auch Evals und modellbasierte Prüfungen sind Aufrufe und kosten Geld.

Geregelter Betrieb macht diese Kosten sichtbar, bevor die Rechnung kommt. Jeder Aufruf wird mit Anwendung, Modell und Kosten gebucht. Budgets und Obergrenzen je Anwendung verhindern, dass ein fehlerhafter Agent in einer Schleife hängen bleibt. Kleinere Modelle übernehmen einfache Schritte wie das Einordnen einer Anfrage, größere nur die Schritte, die sie brauchen. Viele Anbieter bieten außerdem an, gleichbleibende Teile einer Anfrage zwischenzuspeichern, was wiederkehrende Kosten senkt. Welche Maßnahme sich lohnt, zeigt erst die Buchung je Aufruf.

Rückfall und Modellwechsel gehören zum Plan.

Ein Sprachmodell eines Anbieters ist eine Abhängigkeit mit Ablaufdatum. Anthropic sagt in seiner Dokumentation zu, Kunden mit aktiver Nutzung mindestens 60 Tage vor der Abschaltung öffentlich verfügbarer Modelle zu informieren; Anfragen an abgeschaltete Modelle schlagen fehl. OpenAI nennt für allgemein verfügbare Modelle eine Mindestfrist von sechs Monaten, für spezialisierte Varianten drei Monate, sofern Sicherheits- oder Compliance-Gründe keine kürzere Frist verlangen (Stand November 2026). Dazu kommen Störungen, Mengenbegrenzungen und Preisänderungen.

LLMOps plant dafür vorab. Für jede Anwendung ist festgelegt, was bei einem Ausfall geschieht: ein zweites Modell, das mit denselben Evals geprüft wurde, eine feste Standardantwort, eine Warteschlange oder die Übergabe an Menschen. Ein Modellwechsel ist ein geplanter Vorgang mit Testlauf, Vergleich der Ergebnisse und Freigabe.

Technisch hilft eine zentrale Schicht zwischen Anwendungen und Modellen, oft Gateway genannt. Laufen alle Aufrufe darüber, lassen sich Modelle tauschen, ohne jede Anwendung umzubauen, und Protokoll, Kostenbuchung und Rechte liegen an einer Stelle. Microsoft nennt in seinem Reifegradmodell für GenAIOps ausdrücklich Versionskontrolle und die Möglichkeit, Änderungen zurückzunehmen, als Merkmal fortgeschrittener Teams.

Typische Missverständnisse.

Erstes Missverständnis: LLMOps sei ein Werkzeug, das man kauft. Gemeint ist eine Arbeitsweise mit festen Abläufen und Zuständigkeiten. Plattformen für Protokolle, Evals oder Prompt-Verwaltung decken einzelne Teile ab, die Entscheidungen darüber, was getestet, freigegeben und überwacht wird, treffen Menschen.

Zweites Missverständnis: Gute Prompts machten Tests überflüssig. Prompts, Modelle und Anfragen ändern sich. Ohne laufende Prüfung fällt eine Verschlechterung erst auf, wenn sich Kunden oder Mitarbeitende beschweren.

Drittes Missverständnis: LLMOps sei etwas für Konzerne. Schon eine einzige Anwendung im Kundenkontakt braucht Versionen, Tests, Überwachung, Kostenkontrolle und einen Rückfallweg. Der Umfang wächst mit der Zahl der Anwendungen, das Prinzip bleibt gleich.

Viertes Missverständnis: LLMOps sei dasselbe wie MLOps. Wer kein eigenes Modell trainiert, braucht keine Trainingspipelines, aber dafür Prompt-Versionen, Antwortbewertung und Kostenbuchung je Aufruf.

Fünftes Missverständnis: LLMOps und AIOps seien verwandt. AIOps bezeichnet den Einsatz von KI zur Überwachung und Steuerung des IT-Betriebs, etwa um Störungen in Serverprotokollen früh zu erkennen. Der Name ist ähnlich, die Aufgabe eine andere.

Die Grenze des Begriffs

LLMOps sorgt dafür, dass eine Anwendung messbar und steuerbar läuft; ob ihr Einsatz sinnvoll, rechtlich zulässig und fachlich richtig ist, entscheidet sie nicht. Abzugrenzen ist LLMOps von MLOps, das Training und Bereitstellung eigener Modelle regelt, von DevOps als allgemeiner Grundlage des Softwarebetriebs und von AIOps, dem Einsatz von KI zur Überwachung von IT-Systemen. KI-Governance legt Regeln und Zuständigkeiten fest, LLMOps setzt sie im Betrieb technisch um.