LLMOps: Definition, Bausteine, Abgrenzung zu MLOps

LLMOps (kurz für Large Language Model Operations) bezeichnet die Betriebs-Disziplin, mit der Anwendungen rund um grosse Sprachmodelle (KI-Modelle wie GPT oder Claude) produktiv geplant, ausgerollt, geprüft und wirtschaftlich betrieben werden. Die Disziplin ruht auf fünf Bausteinen: Prompt- und Modell-Auswahl, Prompt-Management (Versionierung der Anweisungstexte an das Modell), Deployment (Bereitstellung als Dienst), Evaluation (regelmässige Qualitätsprüfung) sowie Observability und Kostensteuerung (Überwachung von Antwortqualität und Kosten pro Anfrage). LLMOps steht damit neben MLOps (Betrieb selbst trainierter Machine-Learning-Modelle) und DataOps (Betrieb der Datenpipelines).

Was ist LLMOps?

LLMOps schliesst eine Lücke im klassischen Machine-Learning-Betrieb. Eine produktive Anwendung mit grossem Sprachmodell besteht typischerweise aus Prompt-Templates (vorformulierten Anweisungen an das Modell), Retrieval-Pipelines (Suche in eigenen Wissensquellen), Tool-Calls (Aufrufen externer Funktionen durch das Modell), Guardrails (Sicherheits- und Inhaltsfiltern) und Aufrufen an gehostete Modelle bei Anbietern wie OpenAI, Anthropic, Google, Azure OpenAI oder AWS Bedrock. Der klassische MLOps-Werkzeugkasten (Feature Store, Trainings-Pipeline, Model Registry, Serving) deckt diesen Fall nur teilweise ab, weil Prompts geschrieben statt trainiert werden, die Modelle nicht dem eigenen Team gehören und die Kosten pro Token (Wort- oder Zeichenbaustein in Anfrage und Antwort) statt pro Trainings-Lauf entstehen.

Der Aufbau ruht auf fünf Bausteinen. Prompt- und Modell-Auswahl entscheidet je Anwendungsfall, welches Modell (Reasoning, günstig, spezialisiert) und welche Prompt-Strategie (Zero-Shot, Few-Shot, RAG, Fine-Tuning-Adapter) trägt. Prompt-Management versioniert Prompts wie Code, führt A/B-Tests und verknüpft eine Prompt-Version mit der zugehörigen Eval-Baseline. Deployment bündelt Model Serving (Inferenz-Endpoint, Skalierung, GPU-Zuweisung), die Inference Engine im Endpoint (vLLM, TensorRT-LLM, SGLang) und den LLM Gateway davor. Evaluation prüft Modell- und Prompt-Varianten offline gegen ein Golden-Dataset und online über LLM-as-a-Judge-Scores oder Human-Feedback. Observability und Kostensteuerung liefern die Signale für Betrieb und FinOps: Token-Verbrauch, Cost-per-Outcome, Time-to-First-Token, Halluzinations-Rate und Guardrail-Trigger.

Der Begriff hat sich zwischen 2023 und 2026 als eigenständige Kategorie im Markt etabliert. Gartner führt LLMOps im Hype Cycle for AI seit 2024 als eigene Position, die OpenTelemetry GenAI Semantic Conventions standardisieren die Span-Attribute für LLM-Calls, und die Aufzeichnungs- und Post-Market-Pflichten des EU AI Act (Artikel 12 und 72) verankern Teile des Signal-Modells als Compliance-Vorgabe für Hochrisiko-Systeme. Am Markt teilen sich die Kategorie spezialisierte Plattformen wie Langfuse, LangSmith, Arize Phoenix, Braintrust und Helicone, Gateway-Anbieter wie Portkey, Tray.ai und Databricks Mosaic AI Gateway sowie klassische Observability-Häuser mit LLM-Erweiterungen (Datadog LLM Observability, New Relic AI Monitoring).

Abgrenzung zu MLOps, DataOps, AgentOps und Agent Observability

Der Begriff wird häufig mit angrenzenden Disziplinen vermischt. Die folgende Tabelle ordnet die Unterschiede ein.

Disziplin	Objekt des Betriebs	Kern-Artefakte
LLMOps	LLM-Anwendung (Prompt + Modell-Aufruf)	Prompt-Registry, Golden-Dataset, LLM Gateway, Eval-Pipeline, Token-Metriken
MLOps	Selbst trainiertes ML-Modell	Feature Store, Trainings-Pipeline, Model Registry, Model-Monitoring
DataOps	Daten-Pipelines und Datenqualität	ETL/ELT-Orchestrierung, Data Quality Checks, Data Lineage
AgentOps	Autonomer Agent (Planung, Tools, Memory)	Agent-Development-Lifecycle, Tool-Kataloge, Memory-Stores, Human-in-the-Loop
Agent Observability	Signal-Modell im Agent-Lauf	Traces, Metrics, Logs, Quality/Cost/Latency/Safety-Signale

MLOps bleibt die Betriebs-Disziplin für selbst trainierte Modelle. Wer ein Klassifikations- oder Forecasting-Modell auf eigenen Daten trainiert und ausrollt, arbeitet mit Feature Store, Trainings-Runs und Model Registry. LLMOps setzt daneben an, weil das Modell fremd ist und die Kernartefakte Prompts und Golden-Datasets heissen. In produktiven KI-Landschaften laufen beide Disziplinen parallel: MLOps für die klassischen ML-Modelle, LLMOps für die GenAI-Anwendungen. Auf einer Plattform wie Databricks liegen Feature Store, MLflow und Mosaic AI Gateway darum unter einer Governance-Klammer.

DataOps liegt eine Schicht tiefer. Sie sichert, dass die Trainings- und Retrieval-Daten korrekt, aktuell und dokumentiert sind. LLMOps setzt darauf auf und kümmert sich um die Ebene darüber (Prompt, Modell, Antwort). AgentOps ist der Rahmen um autonome Agenten, die mehrere LLM-Aufrufe zu einer Aufgabenkette verbinden; Gartner führt es seit 2025 als eigene Kategorie neben LLMOps. Ein Agent nutzt LLMOps für seine Modell-Aufrufe und braucht darüber eigene Bausteine für Tool-Registrierung, Memory und Human-Approval. Agent Observability ist kein Nachbar auf Augenhöhe, sondern der Signalseiten-Baustein innerhalb von LLMOps und AgentOps: Sie liefert Traces, Metrics und Logs, aus denen der operative Betrieb seine Alarme und SLOs baut.

Beispiel: Betrieb eines Wissensassistenten mit RAG

Ein Unternehmen betreibt einen internen Wissensassistenten mit Retrieval-Augmented Generation auf einer eigenen Wissensdatenbank. Die LLMOps-Sicht spannt sich über fünf Ebenen.

Prompts liegen in einem Registry-Modul mit Version, Autor und Freigabestatus. Eine neue Prompt-Version wird zuerst gegen ein Golden-Dataset aus 500 kuratierten Fragen offline evaluiert, mit einem LLM-as-a-Judge-Score für Faktentreue und einem Human-Review-Sample für Randfälle. Erst nach freigegebener Baseline wird sie auf 10 Prozent des Live-Traffics geschaltet.

Modell-Aufrufe laufen durch einen LLM Gateway. Der Gateway routet je nach Anwendungsprofil auf ein günstiges Modell für Klassifikation und ein stärkeres Modell für die eigentliche Antwort, cached identische Anfragen, wendet einen PII-Filter vor externem Anbieter-Call an und schreibt Prompt, Antwort und Token-Verbrauch in ein Audit-Log. Die Kostenzuordnung erfolgt über virtuelle Keys pro Team.

Guardrails prüfen eingehende Prompts auf Injection-Muster und ausgehende Antworten auf PII-Verstösse. Halluzinations-Kontrolle läuft über eine Faithfulness-Metrik, die die Antwort gegen die abgerufenen Quellen abgleicht; Werte unter der Schwelle erzeugen ein Trace-Event für den Eval-Owner.

Online-Signale laufen in eine Observability-Plattform (zum Beispiel Langfuse oder Arize Phoenix), die die OpenTelemetry-Spans entgegennimmt und Metriken pro Endpoint aggregiert. Time-to-First-Token hat einen p95-Wert, Cost-per-Outcome hat einen Tages-Cap, der Faithfulness-Median wird gegen die Vorwoche verglichen. Weicht ein Signal um mehr als eine definierte Schwelle ab, landet ein Ticket beim zuständigen Owner.

Kostensteuerung schliesst den Kreis. Budgets pro Team werden am Gateway gesetzt, Cost-per-Outcome (Kosten pro beantworteter Anfrage) wird als operative Metrik geführt, günstigere Modell-Varianten werden über Model Routing eingesetzt, wo die Qualität es zulässt.