Der Betrieb eines Large Language Models in einer Produktionsumgebung beschränkt sich längst nicht mehr darauf, das Modell zu trainieren, zu testen, bereitzustellen und Dashboards zu überwachen. Ein modernes System kann Prompts, Vektordatenbanken und Wissensquellen miteinander verknüpfen und anschließend offene Texte erzeugen, die neben ihrer Genauigkeit auch nach Tonalität, Sicherheit und Vertrauenswürdigkeit bewertet werden. Daraus leitet Daniel Bryant in einem auf dem CNCF-Blog veröffentlichten Beitrag eine praktische Frage ab: Wem sollte die KI-Pipeline gehören?
Der Autor ist der Ansicht, dass die Antwort nicht darin liegt, LLMOps ein eigenes Königreich zu geben, sondern sie in eine gut organisierte Engineering-Plattform zu integrieren, die die erforderlichen Fähigkeiten über dieselben Schnittstellen bereitstellt, welche Entwicklungsteams auch für andere Workloads verwenden.
Was ist mit LLMOps gemeint?
LLMOps bezeichnet die Gesamtheit der Praktiken, Werkzeuge und Workflows, die erforderlich sind, um Large Language Models zu entwickeln, bereitzustellen und während ihres gesamten produktiven Lebenszyklus zu verwalten. Dieser Lebenszyklus umfasst Datenmanagement, Prompt-Engineering, Feinabstimmung, Bereitstellung und Inferenzbereitstellung, Monitoring und Evaluation sowie Sicherheit und Governance.
Der Analyse zufolge ist LLMOps nicht lediglich eine Umbenennung von MLOps. Large Language Models sind bei Feinabstimmung und Betrieb teurer, und die Bewertung ihrer Ausgaben ist schwieriger, als die Leistung auf eine eindeutige Genauigkeitszahl zu reduzieren. Es reicht nicht aus, dass das Modell korrekt ist; es muss auch sicher und vertrauenswürdig sein – Eigenschaften, deren Messung komplexer ist.
Auch mit der ersten Bereitstellung ist der Betrieb des Modells nicht abgeschlossen. Modelle können von ihrem bisherigen Verhalten abweichen, die Kosten können steigen, Prompts können nicht mehr wie gewohnt funktionieren, und Integrationen mit CRM-Systemen oder internen Wissensdatenbanken müssen kontinuierlich überwacht werden.
Ein Lebenszyklus mit Überschneidungen zum Plattform-Engineering
Der LLMOps-Lebenszyklus reicht von der Datenaufbereitung und dem Prompt-Engineering – wobei Prompts als versionierbare Artefakte und nicht als vorübergehende Texte behandelt werden – bis zur Feinabstimmung offener Basismodelle mit Bibliotheken wie Hugging Face Transformers. Er umfasst außerdem die Versionierung von Modellen und Prompts sowie die Nachverfolgung ihrer Herkunft, die Bereitstellung von Inferenz über von Grafikprozessoren unterstützte Endpunkte und das Monitoring anhand menschlichen Feedbacks, um Drift und Kosten zu erkennen.
Jeder Teil dieses Lebenszyklus benötigt Infrastruktur, Zugriffskontrollen und eine Laufzeitumgebung – Bereiche, die bereits in den Zuständigkeitsbereich des Plattform-Engineerings fallen. Der Autor unterscheidet jedoch zwischen den beiden Bereichen: Plattform-Engineering konzentriert sich auf die Infrastruktur, während sich MLOps auf Modelle konzentriert. Daher hält er nicht die Frage „Wem gehört die Pipeline?“ für die nützlichste, sondern: „Wem gehört jede einzelne Schicht, und gibt es tatsächlich eine Stelle, die sie koordiniert?“
Das Risiko eines parallelen Stacks
Die Analyse unterteilt die Landschaft der Softwarebereitstellung in DevOps-Teams, die möglicherweise in Bereitstellungsanfragen untergehen, Plattform-Engineering-Teams, die standardisierte Self-Service-Pfade aufbauen, und MLOps-Teams, die parallele Stacks geschaffen haben, weil DevOps-Tools nicht für die Verwaltung von Datenversionen oder die Überwachung von Drift ausgelegt waren. Mit der Einführung von LLMOps könnte ein dritter, unabhängiger Stack für Prompts, Vektordatenbanken und RAG-Pipelines entstehen – fernab der für Governance verantwortlichen Stelle.
Der Autor verbindet diese Möglichkeit mit dem Problem „verborgener KI-Operationen“. Ein Team könnte eine eigene RAG-Pipeline aufbauen, die mit einer nicht überprüften Vektordatenbank verbunden ist, ohne dass für die verantwortliche Stelle ersichtlich wäre, was tatsächlich läuft. Das größte Betriebsrisiko liegt der Analyse zufolge nicht lediglich in einem Chatbot, der Halluzinationen erzeugt, sondern in der Verbreitung dieser Fähigkeiten außerhalb der Plattform und ihrem anschließenden Verbleib außerhalb des Sicht- und Kontrollbereichs.
Der Autor schlägt nicht vor, die Teams zu verlangsamen, um dies zu verhindern, sondern die Plattform so leistungsfähig zu machen, dass sie Anfragen schnell erfüllen kann, während Governance in den Nutzungspfad selbst integriert wird. Fehlt ein fertiger Pfad, kann dies Teams dazu bewegen, ihre Fähigkeiten außerhalb der Plattform aufzubauen. Ein standardisierter Pfad hilft dagegen, diese Fähigkeiten in eine verwaltbare Umgebung zurückzuführen.
LLMOps innerhalb der Plattformschichten
Bryant stützt sich auf das Whitepaper zu Plattformen der CNCF-TAG-App-Delivery-Gruppe, das die Umgebung in drei Schichten unterteilt: Produkte oben, Plattformen in der Mitte als möglichst dünne Integrationsschicht und Anbieter von Fähigkeiten unten.
Nach diesem Modell können Funktionen wie Feinabstimmungsaufgaben, Vektordatenbanken, Prompt-Logs und Inferenzendpunkte als weitere Plattformfähigkeiten behandelt werden. Wie andere Fähigkeiten benötigen sie APIs, Versionierung und eine klare Zuständigkeit. Der Autor verweist auf Werkzeuge innerhalb des CNCF-Ökosystems, die dieses Modell unterstützen können: Backstage stellt standardisierte Pfade in der Produktschicht dar, während Crossplane die Infrastruktur in der unteren Schicht zusammenführt. Frameworks wie Kratix, KusionStack und KubeVela arbeiten in der Mitte, um eine LLM-Pipeline über eine Self-Service-Schnittstelle bereitzustellen, die den übrigen Diensten ähnelt.
Praktische Kontrollen für die Governance der Pipeline
Die Analyse empfiehlt Plattformteams, eine Reihe praktischer Kontrollen einzuführen:
- Governed APIs statt informeller Skripte: Feinabstimmungsaufgaben, die Bereitstellung von Prompts und Inferenzendpunkte sollten über dieselbe Self-Service-Schnittstelle angefordert werden, die auch für die übrigen Anforderungen der Entwickler verwendet wird.
- Richtlinien bei der Anfrage anwenden: Kostenlimits, Regeln zur Datenresidenz und Zugriffskontrollen für Modelle sollten vor Beginn der Aufgabe geprüft werden – nicht erst, nachdem eine Cloud-Rechnung aufgetaucht ist.
- Eine dem Ausmaß der Auswirkungen angemessene menschliche Genehmigung: Nicht jeder Prompt benötigt eine vorherige Genehmigung. Ein Modell, das personenbezogene Kundendaten verarbeitet oder autonome Entscheidungen trifft, kann jedoch eine solche Genehmigung erfordern.
- Ein klares Audit-Protokoll: Das Protokoll sollte Fragen beantworten wie: Was wurde geändert und warum? Dabei kann es um das Modell, den Prompt oder die Daten gehen. Außerdem sollte ersichtlich sein, wer die Änderung genehmigt hat oder was genehmigt wurde.
Der Autor kommt zu dem Schluss, dass eine LLM-Pipeline ein weiterer automatisierter Verbraucher von Plattformfähigkeiten ist und dieselben Garantien benötigt wie ein menschlicher Entwickler oder ein autonomer Agent. Teams, die mit diesem Modell erfolgreich sind, entscheiden sich nicht für eine Seite im Streit zwischen DevOps, Plattform und MLOps. Stattdessen behandeln sie die gesamte Pipeline als ein versionierbares, überwachbares und kostenbewusstes Produkt mit kontinuierlichen Feedbackschleifen.
In diesem Sinne ist LLMOps für Bryant weder eine Aufhebung noch eine Neuerfindung der Frage nach der Zuständigkeit. Vielmehr setzt LLMOps bestehende Plattformen aufgrund der Größe der Modelle, ihrer hohen Kosten und der schwierigen Bewertung stärker unter Druck. Die Lösung besteht seiner Ansicht nach darin, den standardisierten Pfad einmal aufzubauen und ihn anschließend als kontrollierte Fähigkeit für Entwickler, Datenwissenschaftler und intelligente Agenten über eine gemeinsame API oder Benutzeroberfläche bereitzustellen. Er weist darauf hin, dass diese Diskussion innerhalb der CNCF weitergeführt wird, insbesondere in der Platforms Working Group der TAG App Delivery, die allen offensteht, die sich daran beteiligen möchten.