Publiziert:

LLMOps und MLOps

LLMOps und MLOps: KI im Betrieb muss messbar, wiederholbar und nachweisbar sein

KI in Produktion ist eine Betriebsdisziplin, kein einmal trainiertes Modell: LLMOps und MLOps machen aus dem geglückten Prototyp einen wiederholbaren, messbaren und nachweisbaren Dienst.

Der Demo-Effekt täuscht. Ein Modell, das im Notebook überzeugt, ist noch lange kein Dienst, auf den sich eine Abteilung verlassen kann. Sobald KI produktiv läuft, stellt sich dieselbe Frage wie bei jeder anderen Software: Welche Version läuft gerade, wie gut ist sie wirklich, was kostet sie, und wann beginnt sie zu driften? MLOps hat diese Fragen für klassische Machine-Learning-Modelle beantwortet. LLMOps überträgt die Antwort auf Sprachmodelle und ergänzt sie um das, was an grossen Modellen neu ist. Diese Seite beschreibt, worin sich die beiden unterscheiden, wie der Lebenszyklus aussieht und warum das passende Tooling self-hostbar sein sollte.

Warum LLMOps nicht gleich MLOps ist

MLOps ist die reife Disziplin: Datensätze, Trainingscode und Modelle werden versioniert, getestet, automatisiert ausgeliefert und im Betrieb auf Modell-Drift überwacht. Die Grundprinzipien, Versionierung, Test, Automatisierung, Monitoring und Reproduzierbarkeit, gelten unverändert auch für Sprachmodelle. Drei Eigenschaften grosser Modelle verschieben aber den Schwerpunkt:

  • Nicht-deterministisch. Dieselbe Eingabe kann zwei verschiedene Antworten erzeugen. Ein fixer Testwert genügt nicht; es braucht eine Evaluation, die Qualität über viele Fälle statistisch beurteilt.
  • Prompt-as-Code. Das Verhalten steckt oft nicht im Modellgewicht, sondern im Prompt und im abgerufenen Kontext. Damit wird der Prompt zum versionierbaren Artefakt mit eigenem Lebenszyklus, ein Thema, das das Prompt- und Context-Engineering vertieft.
  • Fremde Inferenz. Wer ein Modell per API zukauft, kennt dessen Innenleben nicht und trägt laufende Kosten pro Aufruf. Kosten, Latenz und Token-Verbrauch werden zu Betriebsmetriken erster Ordnung.

Klassisches MLOps trainiert und überwacht ein Modell, das man besitzt. LLMOps orchestriert und überwacht ein Modell, das man oft nur aufruft, und macht den Prompt, die Evaluation und die Kosten zum eigentlichen Steuerungsobjekt.

Der LLMOps-Lebenszyklus

LLMOps ist eine Schleife, kein Projekt mit Enddatum. Jede Prompt-Änderung, jeder Modellwechsel und jeder neue Anwendungsfall durchläuft denselben Ablauf, der vier Schritte zu einem geschlossenen Kreislauf verbindet:

flowchart TD
    A["Versionieren<br/>Prompt, Modell, Kontext"] --> B["Evaluieren<br/>Test-Sets, LLM-as-Judge"]
    B --> C["Ausliefern<br/>kontrolliert, mit Rückfallpfad"]
    C --> D["Beobachten<br/>Kosten, Latenz, Drift, Traces"]
    D --> A

Der Kreislauf macht den Unterschied zwischen einem einmaligen Treffer und einem Dienst. Die Versionierung hält fest, welcher Prompt mit welchem Modell und welchem Kontext zusammengehört. Die Evaluation prüft vor jeder Auslieferung, ob die neue Version besser ist als die alte, statt sich auf das Bauchgefühl aus drei Beispielen zu verlassen; sie ist zugleich die Brücke zur KI-Evaluation und zu Guardrails. Die Auslieferung folgt denselben Mustern wie CI/CD, mit kontrolliertem Ausrollen und einem Rückfallpfad. Die Beobachtung schliesslich macht im Betrieb sichtbar, was ein Trace pro Anfrage festhält: den gesendeten Prompt, die Antwort, den Token-Verbrauch und die Latenz. Diese Telemetrie ist KI-spezifische Observability, und der offene Standard dafür, die Gen-AI-Konventionen von OpenTelemetry, sorgt dafür, dass sie sich in eine bestehende Monitoring-Landschaft einfügt.

Self-hostbares Tooling

Die Tool-Landschaft ist die flüchtigste Schicht dieser Seite. Entscheidend ist nicht der einzelne Name, sondern dass die belastbaren Werkzeuge quelloffen und self-hostbar sind. Genau das entscheidet über die Datenhoheit: Die Telemetrie einer KI-Anwendung, also die echten Nutzeranfragen samt Daten, bleibt im eigenen Haus, statt zu einem fremden Anbieter zu fliessen.

  • Langfuse bündelt Tracing, Prompt-Management und Evaluation in einer quelloffenen Plattform und spricht OpenTelemetry.
  • Agenta verbindet Prompt-Versionierung, Evaluation samt LLM-as-Judge und Beobachtung unter einer MIT-Lizenz.
  • LiteLLM stellt als self-hostbares Gateway eine einheitliche Schnittstelle zu vielen Modellen bereit, mit virtuellen Schlüsseln und Kostenverfolgung.
  • PostHog AI Observability misst Kosten, Latenz und Traces im Produktverhalten und ist quelloffen self-hostbar.

Welches Werkzeug passt, hängt vom Anwendungsfall ab; die gemeinsame Eigenschaft ist die Datenresidenz. Wer die Telemetrie self-hostet, hält die Kontrolle dort, wo auch die Data Governance sie verlangt, und macht KI-Betrieb mit Schweizer Datenschutz vereinbar.

Wo LLMOps bricht

  • Prompt-Wildwuchs. Prompts leben verstreut im Code, niemand weiss, welche Version produktiv ist. Ohne Versionierung lässt sich eine Verschlechterung weder erklären noch zurücknehmen.
  • Keine Evaluation. Eine neue Version geht ohne Test-Set live, weil sie in drei Beispielen gut aussah. Die Regression zeigt sich erst beim Nutzer.
  • Blinder Betrieb. Kosten, Latenz und Qualität werden nicht gemessen. Der erste Hinweis auf ein Problem ist die Rechnung oder die Beschwerde.
  • Drift unbemerkt. Ein zugekauftes Modell ändert still sein Verhalten, oder die Eingabedaten verschieben sich. Ohne Beobachtung bleibt die schleichende Verschlechterung unsichtbar.

Telemetrie im eigenen Haus

Eine produktive KI-Anwendung verarbeitet laufend echte Eingaben, und genau diese Telemetrie ist der heikelste Datenstrom einer Organisation. Läuft das Observability-Tooling self-hosted, bleibt dieser Strom im eigenen Haus, statt zu einem fremden Anbieter zu fliessen. Die Disziplin, KI-Betrieb messbar und nachweisbar zu machen, ist die Leistung Observability und Telemetrie; die belegbare KI auf eigener Infrastruktur, in die dieses Tooling eingebettet wird, deckt die KI-Werkbank ab. Die Auslieferungs- und Plattformseite, auf der LLMOps aufsetzt, beschreibt das Platform Engineering; die KI-spezifische Entwicklungssicht behandelt die KI-Entwicklung. Die Mess- und Kontrollebene, die LLMOps in die Aufsicht einbettet, ist Teil der KI-Governance. Für Schweizer Organisationen ist das zugleich die Souveränitätsfrage: Bei einem US-Anbieter verlässt der Telemetrie-Strom das Land, self-hosted bleibt er unter Schweizer Datenschutz.

Referenzen

  • Langfuse LLM Observability and Application Tracing. Quelloffene Plattform für Tracing, Prompt-Management und Evaluation, self-hostbar und OpenTelemetry-kompatibel. (2026). langfuse.com/docs/observability/overview
  • Agenta Open-source LLMOps platform. Prompt-Versionierung, Evaluation mit LLM-as-Judge und Beobachtung unter MIT-Lizenz, self-hostbar. (2026). github.com/Agenta-AI/agenta
  • LiteLLM LLM Gateway and unified interface. Self-hostbares Gateway mit einheitlicher Schnittstelle zu vielen Modellen, virtuellen Schlüsseln und Kostenverfolgung. (2026). docs.litellm.ai/docs/
  • PostHog AI Observability. Beobachtung von Kosten, Latenz und Traces für KI-Produkte, quelloffen self-hostbar unter MIT-Lizenz. (2026). posthog.com/ai-observability
  • OpenTelemetry Semantic Conventions for Generative AI. Der offene Standard für Traces, Spans und Attribute von KI-Systemen, herstellerunabhängig. (2024). github.com/open-telemetry/semantic-conventions-genai
  • ml-ops.org MLOps Principles. Die Grundprinzipien produktiven Machine Learnings: Versionierung, Test, Automatisierung, Monitoring und Reproduzierbarkeit. (2020). ml-ops.org/content/mlops-principles

Verwandte Themen