MLOps & LLMOps
Welche Best Practices gelten für den produktiven Betrieb von LLM-Anwendungen?
Anders als bei selbst trainierten Modellen liegt bei LLM-Anwendungen ein wesentlicher Teil der Kontrolle beim externen Anbieter — das verändert, worauf ein Betriebsteam achten muss.
Nextise Wissen · · 6 Minuten Lesezeit
Direkte Antwort
LLMOps ergänzt klassisches MLOps um drei LLM-spezifische Praktiken — Prompt-Versionierung wie bei Code, laufendes Kostenmonitoring pro Anfrage wegen der nutzungsabhängigen API-Preise, und kontinuierliche qualitative Evaluation gegen ein Golden-Set, weil sich das Verhalten des zugrunde liegenden Modells bei Anbieter-Updates ändern kann, ohne dass der eigene Code sich verändert hat.
Ein Modell-Update beim Anbieter kann über Nacht das Verhalten einer Anwendung verändern, ohne dass im eigenen Repository eine einzige Zeile Code geändert wurde.
Prompt-Versionierung als Grundpraxis
Prompts sollten wie Code in Versionskontrolle liegen, mit klaren Änderungsprotokollen und der Möglichkeit, bei einer Regression schnell auf eine vorherige Version zurückzurollen.
Ohne diese Disziplin verliert sich schnell der Überblick, welche Prompt-Version welches Verhalten in Produktion erzeugt hat, besonders wenn mehrere Teammitglieder parallel an Prompt-Anpassungen arbeiten.
Laufendes Kostenmonitoring statt nachträglicher Rechnungsprüfung
Da LLM-Kosten nutzungsabhängig pro Token abgerechnet werden, kann ein fehlerhafter Prompt, eine Endlosschleife oder ein unerwarteter Nutzungsanstieg zu erheblichen, unbemerkten Kosten führen.
Ein Dashboard mit Kosten pro Anfrage, pro Nutzer und pro Feature, kombiniert mit Alerts bei Schwellenwertüberschreitung, verhindert, dass ein Kostenproblem erst bei der monatlichen Rechnung auffällt.
Kontinuierliche Evaluation gegen Modell- und Prompt-Änderungen
Weil sowohl eigene Prompt-Änderungen als auch Modell-Updates des Anbieters das Antwortverhalten verändern können, sollte jede Änderung automatisiert gegen ein Golden-Set realer Testfälle geprüft werden, bevor sie produktiv geht.
Diese Regressionstests sind der wichtigste Unterschied zu klassischem Software-Testing, weil sie nicht nur die eigene Codeänderung, sondern auch externe, nicht kontrollierbare Modelländerungen abfangen müssen — ein bekanntes Praxisbeispiel ist ein stillschweigend gewechseltes Standardmodell hinter einer API-Version, das plötzlich anders formatierte JSON-Antworten liefert und einen nachgelagerten Parser bricht, ohne dass im eigenen Code etwas geändert wurde.
Wann passt es — wann nicht?
Passt gut, wenn …
- Die Anwendung läuft mit echtem Nutzungsverkehr und nutzungsabhängigen API-Kosten
Ein anderer Ansatz ist nötig, wenn …
- Es handelt sich um ein internes, einmaliges Experiment ohne Produktivbetrieb
Wissen allein reicht nicht — wir zeigen, wie es im Betrieb funktioniert.
Unsere Seminare verbinden die Konzepte aus dem Wissen-Hub mit konkreter Praxis. Ihr Team lernt direkt an eigenen Aufgaben — praxisnah, kompakt, sofort anwendbar.
Schulungen entdeckenLassen Sie uns über Ihr nächstes Training sprechen.
Unser Team steht Ihnen rund um die Uhr zur Verfügung und freut sich auf Ihre Anfrage. Einfach anrufen oder eine Nachricht hinterlassen – wir kümmern uns schnellstmöglich um Ihre Anfrage, ob es um eine Schulung, einen Vortrag oder eine Präsentation geht. Jetzt loslegen!
Selina Schmid
Leiterin Kodschul