Welche Best Practices gelten für den produktiven Betrieb von LLM-Anwendungen?
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.
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.
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
- ✓Die Anwendung läuft mit echtem Nutzungsverkehr und nutzungsabhängigen API-Kosten
Passt nicht
- ✗Es handelt sich um ein internes, einmaliges Experiment ohne Produktivbetrieb