DevOps mit KI und LLMOps: von der Pipeline zum sprechenden Modell

Informatec Digital » Ressourcen » DevOps mit KI und LLMOps: von der Pipeline zum sprechenden Modell

Das Aufkommen generativer KI und großer Sprachmodelle hat die Entwicklung, Bereitstellung und den Betrieb von Software grundlegend verändert. Gute DevOps-Pipelines oder klassische MLOps reichen nicht mehr aus : Mit dem Einsatz eines großen Sprachmodells betritt man eine Welt, in der das Modell spricht, argumentiert, improvisiert und sich mitunter unvorhersehbar verhält.

In diesem neuen Umfeld müssen Teams DevOps, KI und LLMOps kombinieren, um den gesamten Lebenszyklus LLM-basierter Anwendungen zu managen – von der Experimentierphase und schnellen Entwicklung bis hin zu Bereitstellung, Überwachung, Sicherheit und Kostenoptimierung. Dieser Artikel erläutert die komplexen Zusammenhänge und führt Sie Schritt für Schritt durch die Integration von ChatOps, DevOps, MLOps, GenAIOps und LLMOps in einen modernen Betrieb.

Von DevOps und MLOps zu LLMOps: Warum das Modell nicht mehr statisch ist

Jahrelang legten Entwicklungsteams Wert auf die Automatisierung der Softwarebereitstellung und die Reduzierung von Reibungsverlusten zwischen Entwicklung und Infrastruktur . Dies führte zur Entstehung von DevOps: kontinuierliche Integration, kontinuierliche Bereitstellung, Infrastruktur als Code, Observability und eine kollaborative Kultur, die endlose Übergaben zwischen Abteilungen überflüssig machte.

Als Daten Teil des Produkts wurden, entstand MLOps als Antwort auf den Bedarf an Reproduzierbarkeit und Nachvollziehbarkeit von Modellen des maschinellen Lernens . Praktiken wie die Versionierung von Datensätzen, die Orchestrierung der Trainingspipeline, die Drifterkennung und die kontinuierliche Evaluierung von Vorhersagemodellen wurden standardisiert.

Das Problem besteht darin, dass LLMs viele der in DevOps und MLOps impliziten Annahmen verletzen . Sie sind keine statischen APIs oder einfachen Funktionen, die eine deterministische Zahl zurückgeben: Sie antworten in natürlicher Sprache, vermischen Kontext, Anweisungen, Werkzeuge und Echtzeitdaten und können für dieselbe Eingabe zwei unterschiedliche Ausgaben erzeugen.

Dies bedeutet, dass es nicht ausreicht, das Modell und seine Gewichtungen zu versionieren ; es ist auch notwendig, die Eingabeaufforderungen, Vorlagen, semantischen Sicherheitsrichtlinien, Einschränkungen, verbundenen Tools, den injizierten Kontext und sogar die Geschäftsregeln zu kontrollieren, die das Verhalten des Systems bedingen.

Was ist LLMOps und welche Probleme löst es eigentlich?

LLMOps kann als operatives Rahmenwerk betrachtet werden, das die sichere, kontrollierte und nachhaltige Bereitstellung, Wartung und Skalierung von LLM-basierten Anwendungen ermöglicht . Es bildet den Rahmen, unter dem DevOps-Praktiken, MLOps und neue, für generative Modelle spezifische Funktionen zusammenwirken.

Im Kern konzentriert sich LLMOps weniger auf das „Training des perfekten Modells“, sondern vielmehr auf die Steuerung seines Verhaltens im Produktivbetrieb . Dies umfasst die Gestaltung und Versionierung von Prompt-Flows, die Anbindung von LLMs an interne Datenquellen, die Überwachung von Token-Kosten und Latenz sowie das Management semantischer Risiken (Halluzinationen, Informationslecks, Verzerrungen, toxische Reaktionen usw.).

Die Anforderungen, die LLMOps erfüllt und die DevOps/MLOps allein nicht abdecken können, umfassen so unterschiedliche Aspekte wie die Nachverfolgbarkeit von Gesprächen, die automatische Bewertung der Antwortqualität und A/B-Tests von Verhaltensvarianten . Es geht nicht nur um klassische Genauigkeit, sondern auch um Konsistenz, Ausrichtung auf die Geschäftsziele und Sicherheit.

Darüber hinaus beschränken sich die Kosten nicht mehr auf das Modelltraining und das Hosting : Jede Eingabeaufforderung, jeder erweiterte Kontext und jeder gleichzeitige Aufruf verursacht GPU- oder Token-Verbrauch bei kommerziellen APIs. Ohne eine LLMOps-Schicht, die diese Ausgaben transparent macht und sie mit Hardware, Diensten und Anwendungsfällen verknüpft, steigen die Kosten unvorhersehbar an.

ChatOps + LLMOps + DevOps: Betriebsabläufe werden dialogorientiert

Einer der wichtigsten Trends ist die Integration von ChatOps und LLMOps in die DevOps-Kultur . Anstatt sich auf Dashboards, Skripte und Pipelines zu beschränken, steuern Teams zunehmend einen Großteil des Systems über Chat-Kanäle wie Slack, Microsoft Teams oder Discord.

ChatOps schlägt vor, dass tägliche Vorgänge (Bereitstellungen, Protokollabfragen, Neustarts, Konfigurationsänderungen) von Bots direkt im Kommunikationskanal ausgeführt werden – transparent für das gesamte Team. Jeder Befehl, jede Aktion und jedes Ergebnis wird im Gespräch protokolliert.

Wenn ein LLM zu diesem Ansatz hinzugefügt wird, entsteht eine neue Ebene der Intelligenz: Chatbots, die natürliche Sprache verstehen, Absichten interpretieren und komplexe Befehle auslösen oder Situationen analysieren können, ohne dass sich der Bediener jedes einzelne Skript oder jede einzelne Flagge merken muss.

Typische Beispiele für diese Konvergenz sind ein Bot, der von einem LLM unterstützt wird, Metriken von Prometheus und Protokolle von Loki liest, wenn jemand „Der Dienst der Gruppe X ist langsam“ eingibt, und Aktionen wie das Skalieren von Replikaten, das Durchführen eines Rollbacks oder das Starten bestimmter Tests vorschlägt, die alle in natürlicher Sprache erklärt werden.

Auf kultureller und operativer Ebene bedeutet dies schnellere Entscheidungen, weniger manuelle Eingriffe bei sich wiederholenden Aufgaben und eine reibungslosere Erfahrung für DevOps-Teams , die von der ständigen Brandbekämpfung zur Arbeit an strategischen Verbesserungen übergehen.

Schlüsselprinzipien eines LLM-Lebenszyklus in der Produktion

Die Durchführung eines anspruchsvollen LLM-Programms ist kein einmaliges Projekt, sondern ein fortlaufender Prozess, in dem jede Veränderung das Systemverhalten beeinflussen kann . Jede Organisation passt das Programm zwar an ihre individuellen Gegebenheiten an, typischerweise lassen sich jedoch sechs wesentliche, sich gegenseitig verstärkende Phasen unterscheiden.

Die erste Phase ist das Modelltraining bzw. die Modellanpassung . Diese kann von der Verwendung eines Basismodells bis hin zur Anwendung von Feinabstimmung, LoRa oder anderen Optimierungstechniken mit eigenen Daten reichen. Wichtig ist hierbei nicht nur die Performance, sondern auch eine vollständige Dokumentation: Datensätze, angewendete Filter, Hyperparameter, Tokenizer-Versionen, getestete Architekturen usw.

Wird diese Phase improvisiert und nicht dokumentiert, entsteht das Modell ohne Steuerung . Im Nachhinein wird es nahezu unmöglich sein, zu erklären, warum es so reagiert, wie es reagiert, oder ein bestimmtes Ergebnis bei einem Audit zu reproduzieren.

Die zweite Phase ist die Bereitstellung, bei der das Modell die Testumgebung verlässt und in den Produktivbetrieb übergeht. Bei LLMOps geht es dabei nicht einfach nur darum, es „in einen Container zu packen“: Man muss entscheiden , welche Hardware verwendet werden soll , wie der Speicher für langlaufende Kontexte verwaltet wird, welche Clustertopologie angewendet werden soll und wie die Skalierung entsprechend dem Datenverkehr erfolgen soll, ohne dass die Latenz sprunghaft ansteigt oder die Kosten unüberschaubar werden.

Ab hier kommt die kontinuierliche, verhaltensorientierte Überwachung ins Spiel . Es genügt nicht, nur die CPU- und RAM-Auslastung zu betrachten; notwendig ist die Überwachung der semantischen Qualität der Antworten, der Stabilität des Stils, der Fehlerrate, der Entwicklung der Kosten pro Token, des Auftretens gefährlicher oder inkonsistenter Antworten sowie von Änderungen der Antwortzeiten bei unterschiedlichen Nutzungsmustern.

In späteren Phasen werden Optimierungs- und Feinabstimmungsaufgaben durchgeführt: Anpassung von Eingabeaufforderungen, Änderung des Ampelsystems, Testen von Modellvarianten, Quantisierung, Durchführung von A/B-Tests, Änderung semantischer Sicherheitsrichtlinien oder Verfeinerung von Geschäftsregeln . Es ist ein beinahe handwerklicher Prozess, bei dem Daten, Entwicklung und Geschäftsprozesse zusammenkommen, um Prioritäten festzulegen.

Schließlich ist all dies in Sicherheits- und Governance-Ebenen (Zugriffskontrolle, Auditierung, Verhinderung von Datenlecks, Nutzungsbeschränkungen, Einhaltung gesetzlicher Vorschriften) und in eine Logik der kontinuierlichen Aktualisierung eingebettet, wobei das Modell und sein Ökosystem an Veränderungen bei Daten, Vorschriften und internen Bedürfnissen angepasst werden.

GenAIOps und der Benachrichtigungsflussansatz in Azure

Im LLMOps-Universum existieren sehr spezifische Vorschläge zur Strukturierung dieses Lebenszyklus. Einer der fortschrittlichsten Ansätze im Unternehmensumfeld ist GenAIOps mit Prompt Flows auf Azure Machine Learning, integriert in Azure DevOps . Dieser Ansatz bietet eine sehr systematische Vorgehensweise zum Erstellen von LLM-basierten Anwendungen.

Der Prompt-Flow ist nicht nur ein Prompt-Editor; er ist eine vollständige Plattform für das Entwerfen, Testen, Versionieren und Bereitstellen von LLM-Interaktionsabläufen , von einfachen Fällen (einem einzelnen Prompt) bis hin zu komplexen Orchestrierungen mit mehreren Knoten, externen Tools, Steuerelementen und automatisierten Auswertungen.

Ein entscheidendes Merkmal ist das zentrale Workflow-Repository , das als Unternehmensbibliothek dient. Anstatt dass jedes Team seine Vorgaben in separaten Dokumenten oder eigenen Repositories speichert, werden diese in einem einzigen verwalteten Repository mit übersichtlichen Zweigen, Revisionen und Historien zusammengeführt.

Darüber hinaus bietet die Plattform Möglichkeiten zum Experimentieren mit Varianten und Hyperparametern: Es ist möglich, verschiedene Kombinationen von Eingabeaufforderungen, Modellen, Temperatureinstellungen oder Sicherheitsrichtlinien auf mehreren Knoten des Ablaufs zu testen und die Ergebnisse mit übersichtlichen Metriken zu vergleichen.

Im Hinblick auf die Bereitstellung generiert GenAIOps mit Benachrichtigungsfluss Docker-Images, die sowohl den Fluss als auch die Prozesssitzung kapseln und in Umgebungen wie Azure App Services, Kubernetes oder verwalteten Prozessen ausgeführt werden können. Auf dieser Basis sind A/B-Bereitstellungen möglich, um Flussversionen in realen Umgebungen zu vergleichen.

Eine weitere Stärke liegt in der Verwaltung der Beziehungen zwischen Datensätzen und Abläufen. Jeder Auswertungsablauf kann mit mehreren Standard- und Testdatensätzen arbeiten , wodurch das Verhalten in verschiedenen Szenarien validiert werden kann, bevor es den Endnutzern zur Verfügung gestellt wird.

Die Plattform registriert außerdem automatisch neue Versionen von Datensätzen und Datenflüssen nur dann, wenn tatsächliche Änderungen vorliegen, und generiert umfassende Berichte in Formaten wie CSV und HTML, um datengestützte Entscheidungen und nicht Intuition zu unterstützen.

Die vier Phasen von GenAIOps mit Benachrichtigungsablauf

Der GenAIOps-Ansatz unterteilt den Lebenszyklus in vier klar voneinander abgegrenzte Phasen, wodurch das typische Chaos vermieden wird, bei dem es heißt: „Wir probieren Dinge mit KI aus und schauen, was passiert.“

Die erste Phase, die Initialisierung, konzentriert sich auf die präzise Definition des Geschäftsziels und die Sammlung repräsentativer Datenbeispiele . Hier wird die grundlegende Struktur des Eingabeaufforderungsprozesses skizziert und die Architektur entworfen, die anschließend verfeinert wird.

In der Experimentierphase wird der Ablauf auf diese Beispieldaten angewendet und verschiedene Varianten von Eingabeaufforderungen, Modellen und Konfigurationen werden evaluiert . Die Iteration wird fortgesetzt, bis eine akzeptable Kombination gefunden ist, die die Mindestanforderungen an Qualität und Konsistenz erfüllt.

Im nächsten Schritt folgt die Evaluierungs- und Optimierungsphase, in der größere und vielfältigere Datensätze für ein strenges Benchmarking verwendet werden . Erst wenn der Workflow eine konsistente, den definierten Standards entsprechende Leistung erbringt, gilt er als bereit für den nächsten Schritt.

In der Implementierungsphase wird der Workflow schließlich hinsichtlich Effizienz optimiert und in der Produktion bereitgestellt. Dies umfasst A/B-Tests, Monitoring, Nutzerfeedback und kontinuierliche Verbesserungszyklen . Der Prozess ist nie wirklich abgeschlossen: Der Workflow wird fortlaufend auf Basis von Beobachtungen aus der Praxis angepasst.

Diese Methodik ist in einer GenAIOps-Repository-Vorlage verpackt, mit Code-First-Pipelines und lokalen sowie Cloud-basierten Ausführungstools zur Entwicklung, Evaluierung und zum Start von LLM-basierten Anwendungen, ohne dass das Rad für jedes Projekt neu erfunden werden muss.

Integration mit Azure DevOps: Repositories, Pipelines und Authentifizierung

Um GenAIOps von der Theorie in die Praxis umzusetzen, ist die Integration mit Azure DevOps entscheidend. Die typische Vorlage beginnt mit einem Repository in Azure Repos mit zwei Hauptzweigen, „main“ und „development“ , die unterschiedliche Umgebungen und Strategien zur Codebereitstellung widerspiegeln.

Das Beispiel-Repository wird von GitHub geklont, ist mit Azure Repos verknüpft und der übliche Workflow beinhaltet das Erstellen von Feature-Branches aus dem Entwicklungsverzeichnis . Änderungen werden dann über Pull Requests übertragen, die automatisch Validierungs- und Testpipelines auslösen.

Um Azure DevOps die Interaktion mit Azure Machine Learning und anderen Diensten zu ermöglichen, wird in Azure ein Dienstprinzipal als technische Identität konfiguriert . Diese Identität wird in einer Azure DevOps-Dienstverbindung verwendet und ermöglicht die Authentifizierung von Pipelines, ohne dass Klartextschlüssel offengelegt werden müssen.

Diese Entität verfügt üblicherweise über Eigentümerberechtigungen für das ML-Abonnement oder die Worker-Ressource, wodurch Pipelines Endpunkte bereitstellen, Modelle registrieren und Richtlinien in Keystores aktualisieren können . Zur Erhöhung der Sicherheit kann die Rolle durch Anpassung der YAML-Schritte, die die Berechtigungen verwalten, in die Rolle „Mitwirkender“ geändert werden.

Zusätzlich wird in Azure DevOps eine Gruppe von Variablen erstellt, die sensible Daten wie den Namen der Dienstverbindung oder Ressourcenkennungen speichert . Diese Variablen werden Pipelines als Umgebungsvariablen zur Verfügung gestellt, sodass kritische Informationen nicht im Code fest codiert werden müssen.

Durch die Konfiguration lokaler und entfernter Repositories kann der Entwicklungszweig mithilfe von Zweigrichtlinien geschützt werden, die vor dem Zusammenführen eine Pull-Request-Pipeline erfordern. Diese Pipeline übernimmt die Build-Validierung und die Durchführung von Experimenten, um zu verhindern, dass fehlerhafte Änderungen eingeführt werden.

Sobald der Code in die Entwicklungsphase eintritt, wird eine Entwicklungspipeline ausgelöst, die vollständige CI- und CD-Phasen umfasst : Durchführung von Experimenten und Evaluierungen, Registrierung von Flows in der Azure ML-Modellregistrierung, Bereitstellung von Endpunkten und Smoke-Tests sowie Integration in die neu erstellten Endpunkte.

Das gleiche Muster wird auf einen Versions- oder Release-Branch übertragen, der mit Produktionsumgebungen verbunden ist. Dort durchlaufen die CI/CD-Pipelines für die Produktion den Zyklus aus Experimentieren, Evaluieren und Bereitstellen erneut , jedoch auf Produktionsinfrastruktur und -daten, mit verbesserter Kontrolle und bei Bedarf zusätzlichen manuellen Überprüfungen.

Ein zentrales Merkmal dieser Pipelines ist die „manuelle Überprüfung“: Nach der CI-Phase wird die CD-Ausführung blockiert, bis eine Person die Fortsetzung manuell über die Azure Pipelines-Oberfläche genehmigt. Erfolgt die Genehmigung nicht innerhalb einer festgelegten Zeit (z. B. 60 Minuten), wird die Ausführung abgelehnt.

Lokale Umsetzung und Anbindung an LLM-Anbieter

Nicht alles läuft über Pipelines: GenAIOps unterstützt auch die lokale Ausführung für schnelle Experimente . Sie können das Vorlagen-Repository klonen, eine .env-Datei im Stammverzeichnis erstellen und darin Verbindungen zu Azure OpenAI oder anderen kompatiblen Endpunkten definieren.

Diese Verbindungen enthalten Parameter wie api_key, api_base, api_type und api_version und werden innerhalb der Flows über ihren Namen referenziert (z. B. eine Verbindung namens „aoai“ mit einer bestimmten API-Version). Dadurch kann derselbe Flow lokal und in der Cloud ohne Codeänderungen ausgeführt werden.

Um diese Methode zu verwenden, erstellen Sie einfach eine virtuelle Umgebung oder eine Conda-Umgebung und installieren Sie die erforderlichen Abhängigkeiten (Promptflow, promptflow-tools, promptflow-sdk, OpenAI, Jinja2, Python-dotenv usw.). Anschließend können Sie Testskripte in einem lokalen Ausführungsordner schreiben und Experimente mit den definierten Abläufen durchführen.

Diese Dualität von Cloud und On-Premises passt perfekt zu einem ausgereiften DevOps-Ansatz: Tests im kleinen Maßstab werden lokal durchgeführt, die formale Validierung erfolgt in Pipelines, und anschließend werden Deployments in größeren Umgebungen mit Kontrollen und Auditing durchgeführt . Alles wird in Git versioniert und mit Azure DevOps verbunden.

Typische Werkzeuge in einem DevOps-Ökosystem mit KI und LLMOps

Über den konkreten Vorschlag von Azure hinaus stützt sich ein modernes DevOps-Ökosystem mit KI und LLMOps typischerweise auf eine Reihe von Tools, die ChatOps, Modellorchestrierung, Monitoring und Observability abdecken.

In der ChatOps-Schicht ist es üblich, Slack mit Bots wie Hubot , Microsoft Teams mit Agenten auf Basis von Power Virtual Agents oder Discord zusammen mit Frameworks wie Botpress oder Rasa zu kombinieren, um benutzerdefinierte Assistenten zu erstellen, die sich mit Pipelines, Überwachungssystemen und internen Diensten verbinden.

Im Bereich LLMOps/MLOps sind Plattformen wie Kubeflow und MLflow für die Verwaltung von Pipelines, Modellaufzeichnungen und Experimenten üblich. Hinzu kommen spezielle Tools wie Weights & Biases (W&B) für die erweiterte Metrikverfolgung, den Vergleich von Durchläufen oder detaillierte Visualisierungen.

Die Entwicklung von Anwendungen auf Basis von LLM erfolgt typischerweise mithilfe von Frameworks wie LangChain oder Bibliotheken wie OpenLLM . Diese erleichtern das Zusammenstellen von Prompt-Ketten, Konnektoren zu externen Daten, Tools und mehrstufigen Agenten. Parallel dazu entstehen Lösungen für die LLM-spezifische Observability, die die Überwachung von Prompts, Antworten, Kosten und Qualität ermöglichen.

In der Integration mit klassischen DevOps-Methoden bleiben Tools wie Jenkins oder GitLab CI für den CI/CD-Teil relevant, Kubernetes und ArgoCD für die kontinuierliche Cloud-native Bereitstellung und Observability-Stacks wie Prometheus, Grafana und Loki für Metriken, Dashboards und Logs.

Herausforderungen, Einschränkungen und schrittweise Übernahme

Die Einführung dieser Praktiken und Tools hat ihren Preis. Die Verwaltung von Eingabeaufforderungen, Modellversionen und Workflow-Varianten ist komplex, insbesondere wenn mehrere Teams gleichzeitig arbeiten – ein Szenario, in dem Strategien wie GitOps hilfreich sind , um Änderungen und Bereitstellungen zu koordinieren.

Darüber hinaus stellen ChatOps-Bots und LLMs mit handlungsrelevanten Funktionen ein erhebliches Sicherheitsrisiko dar, wenn sie in Produktionsumgebungen über zu hohe Berechtigungen verfügen oder die Datenexpositionsgrenzen nicht ordnungsgemäß kontrolliert werden.

Hinzu kommt die Abhängigkeit von Open-Source-Modellen mit sensiblen Lizenzbedingungen oder kommerziellen APIs , die Bedingungen, Preise oder Beschränkungen ändern können. Erschwerend kommt hinzu, dass die fundierte Evaluierung von LLMs im Produktivbetrieb weiterhin ein ungelöstes Problem darstellt und viele Fragen noch unbeantwortet sind.

Daher ist es sinnvoll, die Einführung von LLMOps und ChatOps innerhalb von DevOps schrittweise und kontrolliert anzugehen und damit zu beginnen, wiederkehrende Aufgaben mit einfachen Bots zu automatisieren (Neustarts, Log-Abfragen, Build-Tagging usw.).

Später können LLMs für Supportaufgaben, die Klassifizierung von Vorfällen oder die Unterstützung bei der Fehlersuche eingesetzt werden , beispielsweise um Fehler aus Protokollen zu erklären oder auf der Grundlage interner Dokumentationen Abhilfemaßnahmen vorzuschlagen.

Sobald der klassische ML-Betrieb stabilisiert ist, ist es an der Zeit, sich mit LLMOps und spezialisierten Sprachmodellen für Bereiche wie Kundenservice, DevSecOps oder QA auseinanderzusetzen und dabei alle Erkenntnisse aus den vorherigen Phasen zu nutzen.

Der Horizont, auf den all diese Praktiken hinweisen, ist eine dialogorientierte, vorausschauende und zunehmend autonome Entwicklungsumgebung , in der ein Großteil der Entwicklung und des Betriebs in natürlicher Sprache ausgedrückt wird und KI dabei hilft, proaktive Entscheidungen über Bereitstellungen, Skalierung oder Rollbacks zu treffen.

Mit diesem Puzzle – DevOps, ChatOps, MLOps, GenAIOps und LLMOps – verfügen Unternehmen über einen soliden Rahmen, um LLM-basierte Systeme zu entwickeln und zu pflegen, die wirklich Mehrwert bieten und die Kontrolle über Qualität, Kosten, Sicherheit und Ausrichtung auf das Geschäft behalten, anstatt bei bloßen Prototypen oder isolierten Tests zu bleiben, die scheitern, sobald sie in die Produktion gelangen.