MLOps vs. LLMOps: Was sich ändert, wenn das Modell ein LLM ist

MLOps ist die Ingenieursdisziplin für die zuverlässige Entwicklung, Bereitstellung, Versionierung und den Betrieb von Machine-Learning-Systemen; LLMOps erweitert diese Disziplin auf Anwendungen, die auf großen Sprachmodellen basieren, bei denen das Produktionsverhalten nicht nur von einem Modellartefakt abhängt, sondern auch von Prompts, Kontext, Retrieval, Anbieter-/Modellversionen, Tool-Aufrufen, Sicherheitskontrollen und Evaluierungspipelines. LLMOps ersetzt MLOps nicht. Es verändert die operative Einheit von „einem Modell plus Serving-Pipeline“ hin zu „einer sich entwickelnden LLM-Anwendung, deren Verhalten aus mehreren unabhängig voneinander veränderlichen Komponenten entsteht“.

Was MLOps wirklich bedeutet

MLOps wendet Software-Engineering- und Betriebsdisziplin auf Machine-Learning-Systeme an. Die Produktionsherausforderung ist breiter als das Trainieren eines Modells: Datenerfassung, Datenvalidierung, Experimentieren, Reproduzierbarkeit, Modellbewertung, Bereitstellung, Infrastruktur und Monitoring müssen alle zusammenwirken.

Googles MLOps-Architekturleitfaden rahmt die Disziplin um kontinuierliche Integration, kontinuierliche Bereitstellung und kontinuierliches Training. CI validiert nicht nur Code, sondern auch Daten, Schemata und Modelle; CD stellt ML-Pipelines und Vorhersagedienste bereit; CT kann Modelle neu trainieren und erneut bereitstellen, wenn sich Daten oder Implementierungen ändern.

AWS-Leitfaden ergänzt dieselben operativen Belange aus einem anderen Blickwinkel: Modellherkunft, Modell-/Versionsnachverfolgbarkeit, Drift-Monitoring und Produktionsqualitätsüberwachung sind Kernbestandteile, um ML-Systeme nach der Bereitstellung zuverlässig zu halten.

Was sich ändert, wenn das Modell ein LLM ist

Große Sprachmodelle verändern das Produktionsproblem, weil die Anwendung oft nicht den vollständigen Modelltrainingslebenszyklus besitzt. Ein Team kann eine gehostete Modell-API aufrufen, ein offenes Modell lokal ausführen, zwischen Anbietern wechseln oder mehrere Modelle für verschiedene Aufgaben verwenden.

Das Modell ist daher nur eine versionierte Abhängigkeit innerhalb eines größeren Verhaltenssystems. Prompts, Retrieval-Ergebnisse, Kontextreihenfolge, Tools, Modell-Snapshot, Temperatur-/Reasoning-Einstellungen, Sicherheitsfilter und Laufzeitorchestrierung können alle die Ausgabe verändern.

Dies schafft eine breitere operative Frage: Welche Kombination aus Modell, Kontext, Daten, Prompt, Tools und Laufzeit hat dieses Verhalten erzeugt? LLMOps existiert, um diese Frage beantwortbar und die Antwort reproduzierbar genug für Ingenieursarbeit zu machen.

Das einfachste Beispiel

Angenommen, eine Anwendung beantwortet interne Richtlinienfragen.

In einer klassischen ML-Rahmung könnten Sie einen trainierten Klassifikator versionieren, ihn bereitstellen und die Vorhersagequalität überwachen. In einer LLM-Anwendung könnte die Antwort von einem gehosteten Modell-Snapshot, einem System-Prompt, einem Embedding-Modell, einem Vektorindex, Retrieval-Filtern, einem Reranker und dem schließlich ausgewählten Kontext abhängen.

Das Ändern einer dieser Komponenten kann die endgültige Antwort verändern, selbst wenn der Anwendungsendpunkt und die Benutzerfrage identisch bleiben.

Wo das einfache Beispiel endet

Einige LLM-Systeme trainieren oder fine-tunen noch ihre eigenen Modelle, sodass traditionelle MLOps-Praktiken wie Trainingspipelines, Modell-Registry und Datenherkunft weiterhin direkt relevant bleiben.

Andere Systeme verwenden nur externe Foundation-Model-APIs und führen nie kontinuierliches Training durch. Ihre Hauptbetriebsaufgabe ist Anwendungsbewertung, Modell-/Anbieter-Änderungsmanagement, Prompt-/Kontext-Versionierung, Retrieval-Qualität und Observability.

Es gibt daher keine einzige universelle „LLMOps-Pipeline“. Der genaue Lebenszyklus hängt davon ab, ob Sie trainieren, fine-tunen, selbst hosten, externes Wissen abrufen, Agents ausführen oder von verwalteten Modell-APIs abhängen.

MLOps vs. LLMOps

LLMOps erweitert MLOps, statt es zu ersetzen

Die Kernbetriebsprinzipien verschwinden nicht: Quellcodeverwaltung, CI/CD, Reproduzierbarkeit, Herkunft, Deployment-Kontrollen, Monitoring, Rollback und messbare Akzeptanzkriterien bleiben unerlässlich.

Die Erweiterung besteht darin, dass sich mehr verhaltensbestimmende Artefakte nun außerhalb der Modellgewichte befinden. Ein verwaltetes Foundation-Modell kann sein Verhalten durch Snapshot-Upgrades ändern, während sich die Anwendungsausgabe durch Prompt- oder Retrieval-Änderungen ohne jegliches Modell-Retraining ändern kann.

Deshalb ist die nützliche Hierarchie normalerweise DevOps → MLOps → LLMOps/GenAIOps als zunehmend spezialisierte operative Anliegen, nicht drei sich gegenseitig ausschließende Praktiken.

Was muss in LLMOps versioniert werden?

Modell-Snapshots werden zu Release-Abhängigkeiten

Bei gehosteten LLMs kontrolliert das Team möglicherweise nicht das Modelltraining, aber es kontrolliert weiterhin, welches Modell oder welchen Snapshot die Anwendung aufruft.

Die aktuelle API-Richtlinie von OpenAI warnt ausdrücklich, dass sich das Prompting-Verhalten zwischen Modell-Snapshots ändern kann, und empfiehlt, Produktionsanwendungen auf bestimmte Snapshots festzulegen, wo Konsistenz wichtig ist, und dann beim Upgrade Evals auszuführen.

Die operative Konsequenz ist eindeutig: Modell-Upgrades sollten als Anwendungs-Releases behandelt werden, nicht als unsichtbare Infrastrukturwartung.

Der Anbieter-Lebenszyklus wird Teil des Betriebs

LLM-Anwendungen hängen oft von Anbieter-Rate-Limits, Deprecation-Zeitplänen, API-Semantik, Kontextlimits, Datenverarbeitungsregeln und Preisen ab.

Ein Anbieter kann ein Modell als veraltet einstufen, während Ihr Anwendungscode unverändert bleibt. Der aktuelle Deprecation-Zeitplan von OpenAI enthält beispielsweise Auslaufdaten für 2026 für ältere Modell-Snapshots und Plattformoberflächen.

LLMOps benötigt daher zusätzlich zur Modellqualitätsüberwachung auch die Verfolgung des Anbieter-Lebenszyklus, Migrationstests und Fallback-Entscheidungen.

Prompts verhalten sich wie Produktionscode

Prompts sind ausführbare Verhaltenskonfiguration. Kleine Änderungen können die Ausgabequalität, die Werkzeugauswahl und die Richtlinieninterpretation verändern.

Die aktuelle Empfehlung von OpenAI rät dazu, Produktions-Prompts im Anwendungscode zu speichern, Prompt-Änderungen über Pull Requests zu überprüfen, typisierte Eingaben zu verwenden und Änderungen mit Tests und Evaluierungsprüfungen abzudecken.

Dadurch ähnelt die Prompt-Versionierung weniger dem Bearbeiten von Marketingtexten und mehr dem Ändern einer Funktion, deren Ausgabe probabilistisch und modellabhängig ist.

Context Engineering wird zu einem operativen Anliegen

Das Produktionsmodell erhält selten nur einen statischen Prompt. Es kann Gesprächsverlauf, abgerufene Dokumente, Werkzeugausgaben, Speicher, aktuellen Anwendungszustand und Richtlinienanweisungen erhalten.

LLMOps muss daher die Kontextzusammenstellung beobachten: welche Belege ausgewählt wurden, welche Zustandsversion aktuell war, ob eine Kürzung stattfand und ob wichtige Anweisungen die Komprimierung überlebt haben.

Eine Modellregression und eine Kontextregression können bei der endgültigen Antwort identisch aussehen. Das Nachverfolgen des tatsächlichen Kontextpfads ermöglicht es dem Team, sie zu unterscheiden.

RAG schafft einen eigenen operativen Lebenszyklus

Ein RAG-System führt eine zweite Produktionspipeline neben der Modellinferenz ein: Ingestion, Extraktion, Chunking, Metadaten, Embeddings, Indizes, Retrieval, Reranking und Kontextauswahl.

Der Wissenskorpus kann sich täglich ändern, selbst wenn Modell und Prompt unverändert bleiben. Ein veralteter Index oder ein defekter Metadatenfilter kann daher die Antwortqualität beeinträchtigen, ohne dass ein Modell-Drift vorliegt.

LLMOps für RAG sollte Korpus-/Indexversion, Embedding-Modell, Chunking-Richtlinie, Retrieval-Konfiguration, Quellenaktualität und Retrieval-Metriken getrennt von der Generierungsqualität verfolgen.

Evals ersetzen „sieht gut aus für mich“ durch Release-Beweise

Generative Ausgaben sind oft offen, sodass Exact-Match-Tests für viele Aufgaben unzureichend sind. LLMOps fügt Evaluierungsdatensätze und Scorer hinzu, die Aufgabenerfolg, Korrektheit, Sicherheit, Fundiertheit, Stil oder domänenspezifische Akzeptanzkriterien messen können.

Der aktuelle GenAI-Evaluierungsstack von MLflow unterstützt versionierte Evaluierungsdatensätze, Prompt-/Modellvergleiche, benutzerdefinierte Scorer und die Evaluierung über vollständige Traces.

Die stärkste Praxis ist evaluierungsgetriebene Entwicklung: Definieren Sie repräsentative Fälle und Akzeptanzkriterien vor oder parallel zu Änderungen und vergleichen Sie dann Releases anhand derselben Evidenz.

LLM-as-a-judge ist nützlich, aber keine Ground Truth

LLM-Richter können die Evaluierung für Qualitäten skalieren, die teuer als deterministische Assertions zu kodieren sind, wie Relevanz, Tonalität oder Groundedness.

Der Richter ist jedoch ein weiteres Modell mit eigenem Bias, eigener Version und eigenem Prompt. Die Richter-Konfiguration sollte daher versioniert und gegen menschliche oder deterministische Referenzfälle kalibriert werden, wo Konsequenzen wichtig sind.

Eine Produktions-Evaluierung kann deterministische Checks, referenzbasierte Metriken, Modell-Richter und menschliche Überprüfung kombinieren, anstatt eine einzige Metrik alle Qualitätsdimensionen repräsentieren zu lassen.

Tracing wird wichtiger als Endpoint-Logs

Traditionelle API-Logs können Ihnen sagen, dass eine Anfrage zwei Sekunden gedauert hat und HTTP 200 zurückgegeben wurde. Sie können Ihnen nicht sagen, welche abgerufenen Chunks ausgewählt wurden, welches Tool der Agent aufgerufen hat oder welcher Modell-Span die meisten Tokens verbraucht hat.

Das aktuelle GenAI-Tracing von MLflow erfasst Prompts, Retrievals, Tool-Aufrufe und Anwendungs-Spans, und sein Produktions-Evaluierungsablauf kann Zwischeninformationen der Trajektorie bewerten, nicht nur den finalen Text.

Dies ist ein bedeutender LLMOps-Wandel: Observability folgt dem Verhaltensgraphen der Anwendung, nicht nur dem Serving-Endpoint.

Agenten erweitern LLMOps zu Runtime-Operationen

Eine agentische Anwendung kann mehrere Modellaufrufe, Tool-Aufrufe und Zustandsübergänge ausführen, bevor sie ein Ergebnis liefert.

Der Betrieb von Agenten erfordert daher Schrittanzahlen, Tool-Call-Traces, Berechtigungsverweigerungen, Wiederholungen, Schleifenerkennung, menschliche Genehmigungen und verifizierten Endzustand zusätzlich zu gewöhnlichen Modell-Latenz- und Token-Metriken.

Eine korrekte finale Antwort kann eine schlechte Trajektorie verbergen, daher muss die Agenten-Evaluierung sowohl den Pfad als auch das Ergebnis untersuchen.

Tokens, Modellaufrufe und Kontext werden zu Kostenvariablen

Die klassischen ML-Inferenzkosten werden oft von der Serving-Infrastruktur oder der Compute pro Vorhersage dominiert. LLM-Anwendungen können Anbieter-Token-Preise, wiederholte Agentenaufrufe, Embedding-Aufrufe, Reranking und Tool-/Runtime-Overhead hinzufügen.

Kosten müssen daher einer Aufgabe oder einem Trace zugeordnet werden, nicht nur einem Endpunkt. Ein Workflow, der acht versteckte Modellaufrufe macht, kann funktional korrekt, aber operativ inakzeptabel sein.

Latenz verhält sich genauso: Modelllatenz, Retrieval, Reranking und externe Tools setzen sich zu einer End-to-End-Benutzerlatenz zusammen.

Caching wird semantisch, nicht nur technisch

LLM-Systeme können Prompts, Embeddings, Retrieval-Ergebnisse oder vollständige Antworten cachen, aber der Cache-Schlüssel muss die Semantik widerspiegeln, die das Ergebnis verändern kann.

Ein Antwort-Cache, der Modellversion, Mandant, Berechtigungen oder Aktualität der Quelle ignoriert, kann eine technisch gültige, aber semantisch ungültige Antwort zurückgeben.

LLMOps behandelt Cache-Invalidierung daher als Teil der Modell-/Kontext-/Daten-Versionierung und nicht nur als Infrastruktur-Optimierung.

Sicherheit und Berechtigungen werden zu Release-Kriterien

Generative Systeme können unbegrenzten Text erzeugen und Agenten können externe Aktionen auslösen. Sicherheitstests stehen daher näher an gewöhnlicher CI/CD als in vielen klassischen prädiktiven ML-Systemen.

Berechtigungsprüfungen, Prompt-Injection-Tests, Mandantenisolationstests und Genehmigungen für Nebenwirkungen sollten reproduzierbare Regressionstests sein, wo diese Risiken bestehen.

Das Modell kann eine Operation vorschlagen, aber die Laufzeit muss weiterhin die Autorisierung durchsetzen. LLMOps verantwortet den Nachweis, dass diese Kontrollen nach Änderungen an Modell, Prompt oder Tools weiterhin funktionieren.

Wie CI in LLMOps aussieht

Wie CD in LLMOps aussieht

Ein Produktions-Release kann überhaupt kein neues Modellartefakt bereitstellen. Es kann einfach einen neuen Prompt, eine Retrieval-Konfiguration, ein Toolset oder eine Anbieterzuordnung ausliefern.

Das Release-Bundle sollte daher die vollständige verhaltensbestimmende Konfiguration identifizieren und nicht nur das Anwendungs-Container-Image.

Feature-Flags, gestaffelte Rollouts, Shadow-Evaluierung, Canary-Traffic und Rollback sind nützlich, weil LLM-Verhalten auf Arten regressieren kann, die statische Vertragstests nicht erkennen.

Kontinuierliches Training wird optional; kontinuierliche Evaluierung wird zentral

Traditionelles MLOps betont oft kontinuierliches Training, wenn neue Daten oder Drift ein Neutraining rechtfertigen.

Viele LLM-Anwendungen trainieren niemals das Foundation-Modell. Ihr äquivalenter kontinuierlicher Kreislauf ist die kontinuierliche Evaluierung: Fehler und repräsentative Produktionsfälle sammeln, sie den Evaluierungsdatensätzen hinzufügen, Kandidatenänderungen an Prompt/Modell/Retrieval testen und nur dann neu bereitstellen, wenn sich die Evidenz verbessert.

Fine-Tuning kann einen Trainingslebenszyklus wieder einführen, sollte aber in denselben übergeordneten Evaluierungs- und Release-Prozess eingebettet sein.

Was sollte in der Produktion überwacht werden?

Produktions-Traces können zu Evaluierungsdaten werden

Eines der nützlichsten modernen LLMOps-Muster besteht darin, gesampelte Produktions-Traces in Evaluierungsdatensätze umzuwandeln.

MLflow unterstützt derzeit das Abrufen von Produktions-Traces und die Bewertung nicht nur von Ausgaben, sondern auch von Zwischen-Spans wie Retrieval- oder Tool-Aufruftrajektorien.

Dies schließt den Kreislauf zwischen Observability und Entwicklung: echte Fehler können zu Regressionsfällen im nächsten Release werden, anstatt in Logs zu verschwinden.

Reproduzierbarkeit wird bedingt statt exakt

Klassische ML-Reproduzierbarkeit zielt oft darauf ab, ein Modell aus versioniertem Code, Daten, Umgebung und Trainingsparametern nachzubilden.

Gehostete LLM-Anwendungen können nicht immer identische Ausgaben Token für Token reproduzieren, da die Generierung probabilistisch ist und Anbieter die Infrastruktur kontrollieren können.

LLMOps zielt daher auf verhaltensbasierte Reproduzierbarkeit ab: genügend Modell-/Anbieter-/Versions-, Prompt-, Kontext-Eingaben, Retrieval-Zustand und Laufzeitkonfiguration aufzeichnen, um die Bedingungen zu reproduzieren und das Verhalten innerhalb erwarteter Toleranzen zu validieren.

Lineage erweitert sich von Modell-Lineage zu Anwendungs-Lineage

Die MLOps-Richtlinien von AWS betrachten Modell-Lineage als die Historie von Code-, Daten-, Modell- und Infrastruktur-Artefakten, die für Diagnose und Reproduzierbarkeit benötigt werden.

Für LLM-Anwendungen sollte Lineage zusätzlich Prompts, Eval-Datensätze, Retrieval-/Index-Versionen, Tool-Schemas, Agent-/Laufzeitkonfiguration und Anbieter-/Modell-Snapshots verbinden.

Die Ziel Frage wird: Welche exakte Anwendungskonfiguration hat diesen Trace erzeugt?

Multi-Provider- und Modell-Routing erzeugen Betriebsrichtlinien

Sobald eine Anwendung mehrere Anbieter oder lokale Modelle nutzen kann, wird Routing zu einer Betriebsrichtlinie statt zu einem einfachen Modell-String.

Das Routing kann von Fähigkeit, Latenz, Kosten, Datenschutz, Kontextlänge, Verfügbarkeit, Tool-Unterstützung oder Lokalität abhängen. Ein Fallback kann die Verfügbarkeit aufrechterhalten, während sich die Antwortqualität oder die Annahmen zur Datenverarbeitung ändern.

LLMOps sollte daher protokollieren, welche Route tatsächlich ausgewählt wurde, und Routen unabhängig voneinander bewerten, anstatt jeden kompatiblen Endpunkt als verhaltensmäßig austauschbar zu behandeln.

Belege aus der ursprünglichen Implementierung

Aaasaasa AI Client: Anbieter, Modell und Laufzeitumgebung sind separate operative Objekte

Der Aaasaasa AI Client trennt Agent/Client, Anbieter, Modell, Laufzeitort und Berechtigungen. Sein AI Hub unterstützt Ollama, LM Studio/OpenAI-kompatible Endpunkte und andere Anbieterprotokolle, anstatt „das Modell“ als eine globale Einstellung zu behandeln.

Die Implementierung umfasst dynamische lokale Modellerkennung, Streaming, Thinking-Ausgabe und explizite Ollama-Steuerungen zum Warmladen/Laden und Entladen. Das ist ein operativer Beleg dafür, dass lokales LLM-Serving Ressourcen-Lebenszyklus-Probleme mit sich bringt, die über einen API-Modellnamen hinausgehen.

Der Anbieterstatus wird über Anbieteradapter abgefragt, und Verbindungstypen unterscheiden lokale, Cloud-API-, kontogestützte, Remote-Agent- und Web-Client-Pfade. Dies sind konkrete operative Dimensionen, die eine LLM-bewusste Plattform sichtbar machen muss.

Das Repository wahrt außerdem eine wichtige Grenze: Eine lokale Laufzeitumgebung ist nicht automatisch lokale Inferenz. Anbieter/Modell/Laufzeitort sind versionierte oder konfigurierbare Belange, die Datenschutz, Latenz, Kosten und Verfügbarkeit beeinflussen.

Source of Truth Research Engine: Der Zustand einer LLM-Anwendung reicht über das Modell hinaus

Die Source of Truth Research Engine kombiniert lexikalische Suche, optionale Embeddings, Quellen-Snapshots, SHA-256-Identität, Claims, Provenienz und Widerspruchsverfolgung rund um lokale modellgestützte Recherche.

Dies ist ein nützlicher LLMOps-Beleg, weil allein die Änderung des Modells das Recherchesystem nicht definiert. Retrieval, Quellenerfassung, Evidenzklassifizierung und persistente Provenienz sind unabhängige operative Artefakte.

Die Implementierung behandelt semantische Ähnlichkeit bewusst als Entdeckung und nicht als Evidenz, was zeigt, warum LLMOps-Observability Retrieval-Verhalten von der Gültigkeit von Claims unterscheiden sollte.

Häufige LLMOps-Fehlermodi

Häufige Missverständnisse

Eine praktische LLMOps-Designsequenz

LLMOps-Architektur-Checkliste

Randfälle und Einschränkungen

Eine einfache Anwendung, die ein festes gehostetes Modell ohne Retrieval oder Tools aufruft, benötigt möglicherweise nur leichtgewichtige LLMOps: versionierten Prompt-Code, Evals, Modell-Pinning, grundlegendes Tracing und Anbieterüberwachung.

Ein selbst gehostetes feinabgestimmtes Modell kann nahezu den vollständigen klassischen MLOps-Stack plus LLM-spezifische Anwendungsbewertung erfordern, wodurch die Grenze zwischen MLOps und LLMOps absichtlich unscharf wird.

Eine Agentenplattform kann minimale Modelltrainingsoperationen, aber umfangreiche Runtime-Operationen haben, weil Fehler bei Tool-Auswahl, Zustand und Orchestrierung auftreten.

Ein RAG-lastiges System kann operativ von Dokumentenaufnahme und Retrieval-Qualität statt von Modell-Serving dominiert werden.

Die Terminologie wird sich weiterentwickeln. Die dauerhafte Architekturfrage ist nicht, welches „Ops“-Label gewinnt, sondern welche Artefakte Verhalten erzeugen und daher versioniert, bewertet, beobachtet und gesteuert werden müssen.

Was würde diese Antwort ändern?

Wenn Foundation-Model-Anbieter perfekt stabiles Modellverhalten und langfristige Versionsunterstützung standardisieren, könnte Anbieter-/Snapshot-Management operativ weniger bedeutsam werden.

Wenn Anwendungen zunehmend Fine-Tuning oder Training übernehmen, rücken klassische MLOps-Anliegen wieder stärker in den Mittelpunkt.

Das operative Prinzip bliebe: Jede Komponente, die das Produktionsverhalten wesentlich verändern kann, gehört in Lineage, Testing, Observability und Change Control.

Verwandtes kanonisches Wissen

LLMOps steht unter AI Governance und Enterprise AI Architecture: Governance definiert, welche Änderungen Nachweise und Genehmigung erfordern, während LLMOps die operative Maschinerie bereitstellt, um diese Änderungen zu versionieren, zu bewerten, bereitzustellen und zu beobachten.

Context Engineering und RAG sind operative Subdomänen innerhalb vieler LLM-Anwendungen, weil Kontext und Retrieval das Verhalten unabhängig vom Modell ändern können.

Agentic AI erweitert LLMOps weiter in Trajektorien-, Berechtigungs- und Tool-Runtime-Operationen.

Häufig gestellte Fragen

Glossar

Fazit

MLOps und LLMOps teilen dasselbe Engineering-Ziel: KI-Systeme ausreichend reproduzierbar, testbar und beobachtbar zu machen, um sie zuverlässig in der Produktion zu betreiben.

Der Unterschied liegt in der Form des Systems. Klassisches MLOps konzentriert sich oft auf Training und Serving von Modellartefakten; LLMOps muss einen Verhaltens-Stack betreiben, in dem Modell-Snapshots, Prompts, Kontext, Retrieval, Tools, Berechtigungen und Anbieter sich unabhängig ändern können.

Die kürzeste nützliche Regel lautet: Versionieren, evaluieren und beobachten Sie alles, was das Verhalten der LLM-Anwendung wesentlich ändern kann – nicht nur das Modell.

Primärquellen und aktuelle Dokumentation

Die folgenden Quellen untermauern die MLOps-Basis und die aktuellen operativen Muster für LLM- und Agenten-Anwendungen. Projektabschnitte sind originale Implementierungsbelege und bewusst enger gefasst als Aussagen über eine vollständige LLMOps-Plattform.