LLMOps: Was für den produktiven Betrieb zuerst zählt

Für ein Team aus 3 Personen beginnt LLMOps mit einem versionierten Release, einer verbindlichen Evaluierungsprüfung, einem nachvollziehbaren Trace und einem ausführbaren Rollback. Routing, Kostenkontrollen und Schutzmechanismen ergänzen diesen Kreislauf. Zusätzliche Infrastruktur lohnt sich, sobald ein konkreter Fehler oder ein Abstimmungsproblem sie erforderlich macht.

Betrieben wird das Feature, das Kunden tatsächlich nutzen. Ein Supportassistent kann eine flüssig formulierte Antwort liefern und dabei den Datensatz eines anderen Kunden abrufen, das falsche Tool aufrufen oder sein Budget für Wiederholungsversuche aufbrauchen. Dass der Modellendpunkt erreichbar ist, sagt noch nichts darüber aus, ob das Feature funktioniert.

Die folgenden Angaben zu Produktfunktionen und zum Umgang mit Abhängigkeiten wurden am 23. Oktober 2026 anhand der aktuellen Originaldokumentation geprüft. Die Teamgrößen und das durchgerechnete Evaluierungsbeispiel sind Planungsszenarien, keine Anbietergrenzen oder gemessenen Ergebnisse aus dem Produktivbetrieb.

Was ist LLMOps?

LLMOps sorgt dafür, dass Änderungen an einer Anwendung rund um ein großes Sprachmodell beobachtbar, prüfbar und rückgängig zu machen sind. Die Abkürzung steht für large language model operations. Dazu gehören Prompts, Modellversionen, Evaluierungen, Traces, Kosten, Schutzmechanismen, Gateways und klare Zuständigkeiten bei Fehlern.

Als Vergleich eignet sich eine Brücke im laufenden Betrieb. Neben dem Bauwerk selbst braucht es Prüfungen vor Umbauten, Belastungsgrenzen, Überwachung und die Möglichkeit, einen gefährlichen Abschnitt zu sperren. Eine stabilere Brücke ersetzt diese Betriebsaufgaben nicht. Bei einem leistungsfähigeren Modell gilt dasselbe.

Bei einem Supportassistenten sieht der Betriebskreislauf so aus: Die Anweisungen für Erstattungen ändern, den neuen Stand anhand repräsentativer Gespräche evaluieren, schrittweise freigeben, Ergebnisse prüfen und aus Fehlern Regressionstests machen. Ein Regressionstest prüft, ob ein bereits behobener Fehler nach einer neuen Änderung wieder auftritt.

Damit lässt sich eine Kundenbeschwerde konkret beantworten: Welcher Release hat die Anfrage bearbeitet, was ist dabei passiert und was lässt sich gefahrlos ändern? Prompt Engineering verbessert eine Anweisung. LLMOps sorgt dafür, dass diese Verbesserung auch nach der Bereitstellung für Nutzer wartbar bleibt.

LLMOps vs. MLOps: Wo liegen die Unterschiede?

LLMOps erweitert Machine Learning Operations, kurz MLOps, um das Verhalten einer LLM-Anwendung. Beide benötigen Versionierung, Evaluierung, kontrollierte Bereitstellung und Monitoring. Weder ist eines davon grundsätzlich deterministisch, noch entfällt dadurch die übliche Softwareentwicklung.

Bei dem hier betrachteten produktiven Feature wird das Modell nur selten selbst trainiert. Stattdessen wird ein vorhandenes Modell ausgewählt; verwaltet werden Prompts, Kontext, Modellupdates, Tool-Zugriffe und die umgebende Software. Trainingsorientiertes MLOps umfasst zusätzlich Trainingsdaten, Experimente, Modellartefakte und erneutes Training. Wer ein Modell feinabstimmt oder seine Inferenzinfrastruktur selbst betreibt, übernimmt diese Aufgaben auch im Rahmen von LLMOps.

Ausgangspunkt sollte der konkrete Fehler sein. Fehlt Unternehmenswissen, muss womöglich das Retrieval verbessert werden: der Prozess, der dem Modell relevante Dokumente bereitstellt. Wiederholte Verhaltensfehler können Anpassungen am Prompt oder später ein Fine-Tuning erfordern. In beiden Fällen muss nicht erst eine Trainingsplattform aufgebaut werden, um das Feature verantwortungsvoll zu betreiben.

Den gesamten Release versionieren

Eine Prompt-Version hilft nur dann weiter, wenn auch die anderen Eingaben bekannt sind, die das Verhalten geprägt haben. Dafür eignet sich ein Release-Manifest: eine kurze Bestandsaufnahme der gemeinsam ausgelieferten Konfiguration.

• Stand der Anwendung, Prompt-Version und Kennung des ausgewählten Anbieters beziehungsweise Modells.
• Generierungseinstellungen und die zurückgegebene Modellkennung, sofern der Anbieter sie bereitstellt.
• Retrieval-Konfiguration und Stand der Dokumente oder des Index.
• Tool-Definitionen, Ausgabeschemas und Berechtigungsrichtlinie.
• Lockdatei der Abhängigkeiten und Identität des bereitgestellten Images.
• Evaluierungsdatensatz, Bewertungsraster und Konfiguration des bewertenden Modells, mit denen die Änderung freigegeben wurde.

Das Manifest gehört zum Bereitstellungsnachweis; seine Kennung sollte an die Traces aus dem Produktivbetrieb angehängt werden. Zugangsdaten gehören nicht hinein. Wo Anbieter es unterstützen, sollten explizite Modellversionen gewählt werden. Angekündigte Modellabschaltungen geben den Zeitrahmen für notwendige Migrationen vor.

Ein Erstattungsassistent zeigt, warum das wichtig ist: Sein Prompt kann unverändert bleiben, während aktualisierte Dokumente bereits eine neue Richtlinie liefern. Eine Änderung am Tool-Schema kann wiederum beeinflussen, welche Eingaben eine Aktion akzeptiert. Wird nur der Prompt zurückgesetzt, bleiben beide Änderungen bestehen. Das Rollback-Ziel muss deshalb eine kompatible Anwendungskonfiguration benennen, einschließlich der maßgeblichen Retrieval- und Richtlinienversionen.

Langfuse, eine Plattform für Anwendungs-Tracing und Evaluierung, dokumentiert zentral gespeicherte Prompts, Versionierung, Deployment-Labels und Verknüpfungen zwischen Prompts und Traces. Damit lässt sich eine Prompt-Version mit ihren Ergebnissen verbinden. Ein Deployment-Label bleibt allerdings ein veränderlicher Verweis: Für jede Anfrage muss die tatsächlich verwendete Version erfasst werden. Änderungen an diesem Verweis sollten dem festgelegten Freigabeprozess unterliegen. Prompt-Verwaltung in Langfuse.

Wenn sämtliche Änderungen bei der Entwicklung liegen, reichen zunächst Prompts im vorhandenen Repository. Eine Prompt-Registry wird sinnvoll, sobald Personen außerhalb der Entwicklung kontrolliert Änderungen vornehmen müssen oder mehrere Dienste dieselbe freigegebene Version benötigen. Der zusätzliche Baustein sollte ein tatsächliches Abstimmungsproblem lösen.

Evaluierungen zur Voraussetzung für die Freigabe machen

Eine Evaluierung wird erst dann zur Betriebskontrolle, wenn ihr Ergebnis einen Release stoppen kann. Ein Wert im Dashboard, auf den niemand reagieren muss, ist lediglich eine Messung.

Testfälle sollten aus repräsentativen Anfragen, bekannten Fehlern und Missbrauchsversuchen entstehen. Sensible Daten werden dabei entfernt oder ersetzt. Jeder Fall braucht ein erwartetes Ergebnis oder ein konkretes Kriterium. Zum Beispiel: die richtige Richtlinie erkennen, die bereitgestellten Belege zitieren, einen gültigen Aktionsvorschlag zurückgeben und den Zugriff auf einen Datensatz außerhalb des Kontos der anfragenden Person verweigern. Ein zurückgehaltener Testsatz sollte vor der wiederholten Optimierung durch die Prompt-Autoren geschützt bleiben.

Eine kleine, klar definierte Freigabeprüfung

Als Ausgangspunkt dienen beispielsweise 50 Fälle: 30 Routineanfragen, 10 Grenzfälle und 10 Missbrauchsversuche. Das ist eine Übung zum Einstieg und keine Aussage darüber, dass 50 Beispiele für das jeweilige Risiko ausreichen.

Für Pflichtfelder, zulässige Tool-Argumente und Berechtigungsgrenzen eignen sich deterministische Prüfungen, also Regeln mit einem eindeutigen Ergebnis: bestanden oder nicht bestanden. Eigenschaften wie die Belegtreue einer Antwort sollten Menschen und ein Sprachmodell als Bewertungsinstanz prüfen. Für den Vergleich bleiben Bewertungsraster und Konfiguration dieses Modells fest. An relevanten Beispielen werden seine Entscheidungen mit menschlichen Bewertungen abgeglichen. Der Leitfaden zu LLM-as-a-Judge erklärt diesen Kalibrierungsschritt.

Ein neuer Stand, der sich von 46/50 auf 49/50 beziehungsweise von 92% auf 98% verbessert, kann trotzdem untragbar sein, wenn der verbleibende Fehler einen privaten Datensatz offenlegt. Ein Gesamtwert für Qualität darf kritische Teilbereiche der Anfragen nicht verdecken.

Für dieses Beispiel bietet sich folgende Freigabeprüfung an:

1. Keine kritischen Fehler in den Berechtigungs- und Aktionstests.
2. Die Qualität erreicht in jeder wichtigen Anfragekategorie den freigegebenen Referenzstand; unsichere oder strittige Fälle werden geprüft.
3. Latenz und Ressourcenverbrauch bleiben innerhalb der vereinbarten Betriebsgrenzen des Features.
4. Der vorherige kompatible Release ist weiterhin verfügbar, und die Entscheidung über ein Zurücksetzen ist klar zugeordnet.

Wichtige Fälle und Grenzfälle sollten wiederholt werden, wenn schwankende Ausgaben die Entscheidung beeinflussen könnten. Bestandene Tests liefern Belege für die Freigabe dieses Stands. Sie beweisen nicht, dass der Produktivbetrieb fehlerfrei bleiben wird.

LangSmith, eine Plattform für Evaluierung und Observability, dokumentiert Offline-Evaluierungen auf kuratierten Datensätzen und Online-Evaluierungen laufender Interaktionen. Als Bewertungsverfahren stehen unter anderem Code, menschliche Prüfung, LLM-Bewerter und paarweise Vergleiche zur Verfügung. Für den Betrieb ist die Trennung entscheidend: Offline-Prüfungen bestimmen, ob ein neuer Stand freigegeben werden darf; Online-Prüfungen helfen, Fehler zu entdecken, die im Datensatz fehlen. Dokumentation zur Evaluierung mit LangSmith.

Nach bestandener Freigabeprüfung erhält der neue Stand zunächst einen begrenzten Anteil der Anfragen. Beobachtet werden dieselben Kategorien wie in der Evaluierung. Auch eine neue Modellroute oder ein Fallback verändert das Verhalten. Bevor produktive Anfragen davon abhängen, braucht es entsprechende Belege.

LLM-Monitoring: Anfrage und Ergebnis nachvollziehen

Ein Trace sollte erklären, wie aus einer Anfrage eine Antwort wurde. Ein Span ist eine einzelne Operation innerhalb dieses Traces, etwa der Abruf von Dokumenten, ein Modellaufruf oder die Ausführung eines Tools.

Erfasst werden die Release-Kennung, zulässige Metadaten zur Anfrage, Retrieval-Referenzen, Modellaufrufe, Tool-Vorschläge und deren Ergebnisse, Validierungsentscheidungen, Wiederholungsversuche, Zeitmessungen und Token-Verbrauch. Ebenso sollte festgehalten werden, welche Route aus welchem Grund gewählt wurde. Der Trace muss mit dem Ergebnis für die Produktnutzung verknüpft sein: Wurde die Antwort akzeptiert, war eine Korrektur nötig oder musste ein Mensch übernehmen?

Eine langsame Antwort zu einer Erstattung kann beispielsweise nur wenig Zeit im Modell verbringen, während der Großteil auf wiederholte Aufrufe eines nicht erreichbaren Bestelldienstes entfällt. Ein Diagramm zur Modelllatenz erklärt das nicht. Ein Trace mit Dienstaufruf, Wiederholungsversuchen und abschließendem Ergebnis schon.

Die Tracing-Dokumentation von Langfuse beschreibt Prompts, Antworten, Token-Verbrauch, Latenz sowie zwischengeschaltete Tool- oder Retrieval-Schritte. Die Dokumentation zu Datensätzen sieht zudem vor, Testfälle aus produktiven Traces zu erstellen. So kann jeder untersuchte Fehler die nächste Freigabeprüfung verbessern. Tracing und Datensätze.

Protokolliert werden dürfen nur Inhalte, deren Speicherung zulässig ist. Zugangsdaten müssen entfernt werden, bevor Telemetriedaten die Anwendung verlassen. Der Zugriff auf Traces ist zu beschränken, die Aufbewahrungsdauer bewusst festzulegen. Ein Debugging-Protokoll kann dieselben Kundendaten enthalten wie das Produkt selbst. Wo vollständige Inhalte ungeeignet sind, bleiben stattdessen Referenzen, strukturierte Entscheidungen und freigegebene, bereinigte Beispiele erhalten.

Alarme sollten von der nötigen Reaktion her geplant werden: Wer kümmert sich um mehr fehlgeschlagene Aktionen, übermäßige Wiederholungsversuche, ungewöhnlichen Ressourcenverbrauch oder sinkende Akzeptanz? Ein Signal ohne Zuständigkeit hilft bei einer Störung nicht weiter. Für die Auswahl geeigneter Lösungen bieten der Observability-Leitfaden nach Teamgröße und der Vergleich von LangSmith und Langfuse weitere Orientierung.

Routing, Wiederholungsversuche und Kosten begrenzen

Bevor die Modellwahl optimiert wird, braucht es eine Obergrenze dafür, wie viel Arbeit eine Anfrage auslösen darf. Dazu gehören Grenzen für Ausgabelänge, Laufzeit, Wiederholungsversuche, parallele Arbeit und Agentenschritte. Der Verbrauch sollte einem Feature und einem Mandanten zugeordnet werden, also einem Kunden oder einer Organisation, die dieselbe Anwendung mitnutzt.

Die Komponenten erfüllen unterschiedliche Aufgaben. Ein Gateway bündelt den Zugang zu Modellanbietern. Ein Router wählt ein zulässiges Modell oder Deployment aus. Ein Cache verwendet ein früheres Ergebnis erneut, sofern das zulässig ist. Keine dieser Komponenten legt automatisch die Qualitätsrichtlinie der Anwendung fest.

LiteLLM, ein Modell-Gateway und Proxy, dokumentiert eine einheitliche Schnittstelle, Authentifizierung, Kostenerfassung, Budgets und Lastverteilung. Die Routing-Dokumentation behandelt Wiederholungsversuche, Fallbacks und Zeitlimits. Daraus sollten explizite Regeln entstehen: Ein nicht erreichbarer Endpunkt kann einen Fallback rechtfertigen, aber nur auf eine Route, deren Verhalten und Anforderungen an den Umgang mit Daten freigegeben wurden. Gateway-Dokumentation und Routing-Dokumentation.

Grenzen müssen mit gleichzeitigen Anfragen und den tatsächlich genutzten Endpunkten getestet werden. Ein Alarm ist von einer blockierenden Kontrolle zu unterscheiden. Zu prüfen ist außerdem, wie bereits laufende Arbeit, Wiederholungsversuche und Fallback-Aufrufe den Gesamtverbrauch beeinflussen. Eine Begrenzung pro Anfrage auf Anwendungsebene bleibt nötig, auch wenn das Gateway die Kosten erfasst.

Für den Einstieg ins Routing genügt eine eng gefasste Regel: Eine eindeutig eingeordnete Anfragekategorie mit geringem Risiko geht erst dann an ein kleineres Modell, wenn dieses die relevanten Evaluierungen bestanden hat. Uneindeutige Aufgaben bleiben auf der freigegebenen Route mit dem leistungsfähigeren Modell. Der Leitfaden zu Modell-Routern zeigt, wie sich diese Auswahlregel prüfen lässt.

Semantisches Caching verwendet Ergebnisse anhand ihrer Bedeutung erneut, statt nur bei identischem Text. Es sollte nur dort hinzukommen, wo gleichwertige Fragen gefahrlos dieselbe Antwort erhalten dürfen. Eine Erklärung aus einem öffentlichen Hilfecenter eignet sich für den Einstieg eher als ein Kontostand. Berechtigungen, relevante Versionsstände und Aktualität müssen die Wiederverwendung begrenzen. Ändern sich diese Voraussetzungen, ist der Cache zu invalidieren. Eine Aktion wie die Auszahlung einer Erstattung darf nicht aus einer gespeicherten Antwort erneut ausgeführt werden. Vor der Einführung sollten die Grenzen des semantischen Cachings geklärt sein.

Schutzmechanismen direkt vor der Aktion durchsetzen

Die Anwendung muss entscheiden, was eine anfragende Person tun darf, auch wenn das Modell eine Aktion mit großer Sicherheit vorschlägt. Guardrails sind Prüfungen oder Einschränkungen für Eingaben, Ausgaben und Aktionen. Ein Inhaltsklassifikator deckt davon nur einen Teil ab.

Bei einem Erstattungsassistenten werden die vorgeschlagene Operation und ihre Argumente vor der Ausführung gegen die Berechtigungen des authentifizierten Kunden geprüft. Das Tool erhält nur die Rechte, die es benötigt. Wo die Folgen es rechtfertigen, braucht es eine auf die jeweilige Aktion zugeschnittene Prüfung. Ausgaben sind erneut zu validieren, bevor sie an ein anderes System gelangen. Abgerufene Dokumente und Modellausgaben gelten als nicht vertrauenswürdig. Diese Grundsätze folgen den OWASP-Empfehlungen zur Abwehr von Prompt Injection.

Auch das Verhalten bei Ausfällen muss feststehen. Ist eine vorgeschriebene Berechtigungsprüfung nicht verfügbar, darf die Aktion nicht ausgeführt werden. Eine verspätete optionale Qualitätsbewertung muss einen unbedenklichen Entwurf dagegen nicht blockieren. Es sollte dokumentiert sein, welche Prüfungen die Ausführung zwingend stoppen und bei welchen stattdessen ein Mensch übernehmen darf.

Neben Angriffen gehören legitime Anfragen in die Tests, damit ein zu weit gefasster Filter das Produkt nicht unbemerkt unbrauchbar macht. Der Leitfaden zu KI-Guardrails ordnet diese Prüfungen den Systemgrenzen zu, die ein kleines Team zuerst absichern kann.

Störungen als Teil des Lebenszyklus behandeln

Vor der Wahl einer Wiederherstellungsmaßnahme muss geklärt werden, ob sich das Verhalten verschlechtert hat, ein Dienst ausgefallen ist oder eine Sicherheitskompromittierung vorliegt. Diese Fälle verlangen unterschiedliche Reaktionen.

Bei einer Verschlechterung des Verhaltens wird der Rollout gestoppt. Repräsentative Traces werden gesichert, der letzte kompatible Release wird wiederhergestellt und der Fehler in den Evaluierungsdatensatz aufgenommen. Bei einem Anbieterausfall kommt ein evaluierter Fallback oder eine klare vorübergehende Fehlermeldung zum Einsatz. Bei Verdacht auf eine Kompromittierung wird die betroffene Ausführungsumgebung isoliert und die für Sicherheit verantwortliche Person einbezogen. Ein geänderter Prompt kann das Vertrauen in den Host nicht wiederherstellen.

Der LiteLLM-Vorfall als konkretes Beispiel

Am 21. Oktober 2026 meldete LiteLLM, dass Release 1.107.0 Schadsoftware zum Diebstahl von Zugangsdaten und Werkzeuge zur Ausführung von Code aus der Ferne enthielt. Zu den betroffenen Container-Tags gehörten v1.107.0, latest, main-latest und main-stable; die private Enterprise-Registry war nicht betroffen. Der offizielle Quellcode-Tag enthielt die schädlichen Dateien nicht: Die ausgelieferten Artefakte stammten aus einem von Angreifern kontrollierten Repository. Vorfallsbericht von LiteLLM.

Der Bericht warnt Betroffene davor, mit pip install zu beginnen, weil Python-Start-Hooks den Schadcode erneut ausführen können. Stattdessen empfiehlt er, Umgebungen neu aufzubauen und Zugangsdaten zu erneuern, auf die der kompromittierte Host zugreifen konnte. Als die Angaben für diesen Artikel geprüft wurden, war die Untersuchung noch als laufend gekennzeichnet. Für eine betroffene Installation sind die aktuellen Angaben des Berichts zu Betroffenheit und Abhilfe maßgeblich.

Die Lehre für den Betrieb reicht über dieses Gateway hinaus: Erfasst und freigegeben werden muss das tatsächlich bereitgestellte Artefakt, nicht nur der geprüfte Quellcodestand.

Abhängigkeiten festschreiben und trotzdem weiter pflegen

Freigegebene Versionen von Abhängigkeiten sollten festgeschrieben und ihre Hashwerte aufbewahrt werden. Container-Images werden über ihren Digest fixiert, also die Kennung ihres Inhalts. Eine Installation mit Hashprüfung benötigt festgelegte Abhängigkeiten mit Hashwerten. Digest-Referenzen verhindern, dass unbemerkt einem veränderlichen Container-Tag gefolgt wird. Hinweise zur sicheren Installation von Python-Paketen und Hinweise zum Fixieren von Container-Images.

Diese Kontrollen belegen die Identität eines Artefakts, nicht seine Unbedenklichkeit. Wird ein schädliches Artefakt festgeschrieben, bleibt genau dieses schädliche Artefakt erhalten. Deshalb müssen Herkunft und Sicherheitshinweise geprüft, Updates isoliert getestet und dasselbe freigegebene Artefakt durch die Bereitstellungsstufen geführt werden. Die Aktualisierung festgeschriebener Versionen braucht eine zuständige Person, damit Reproduzierbarkeit nicht zu unbegrenzt aufgeschobener Sicherheitspflege führt.

Das Betriebshandbuch sollte kurz genug bleiben, um unter Druck nutzbar zu sein: zuständige Person, Abschaltmöglichkeit, Verzeichnis betroffener Artefakte, letzter freigegebener Release, Umfang betroffener Zugangsdaten, Kommunikationsweg und Bedingungen für die Wiederaufnahme des Dienstes. Der Ablauf wird mit ungefährlichen Fehlern geübt.

LLMOps-Tools: Was ein Team aus 3 Personen braucht

Als Grundlage dienen der bestehende Bereitstellungsablauf und eine zentrale Stelle für Traces und Evaluierungsergebnisse. Ein eigenes Produkt für jede Phase des Lebenszyklus verursacht zunächst mehr Integrationsarbeit, bevor daraus bessere Kontrolle entsteht.

Das sind Zuständigkeiten, keine fünf zusätzlichen Stellen. Mehrere Aufgaben können bei derselben Person liegen; die Verantwortung muss trotzdem ausdrücklich zugeordnet sein.

Langfuse ist eine kompakte Option, wenn Traces, Prompt-Verwaltung und Datensätze in einem System zusammenkommen sollen und bei Bedarf Self-Hosting möglich sein soll. Der dokumentierte Funktionsumfang unterstützt diese Bündelung. Was als akzeptable Antwort gilt und wann ein Release gestoppt werden muss, kann die Plattform dem Team jedoch nicht abnehmen. Dokumentierter Funktionsumfang von Langfuse.

LangSmith kommt infrage, wenn Offline-Experimente, Online-Evaluierung und die Prüfung produktiver Traces zum Arbeitsablauf passen. Die Observability-Dokumentation beschreibt außerdem Dashboards, Alarme und Feedback. In der Praxis bleibt dasselbe Messproblem: Auch eine umfassend instrumentierte Anwendung kann einen nicht repräsentativen Datensatz haben. Zunächst sollte ein System gewählt und sichergestellt werden, dass seine Fehlerbefunde zu Maßnahmen führen, bevor die Telemetrie doppelt aufgebaut wird. Observability mit LangSmith.

LiteLLM lohnt sich, wenn ein gemeinsamer Anbieterzugang und gemeinsame Regeln den Betrieb eines Gateways rechtfertigen. Eine einzelne Anwendung mit einem einzelnen Anbieter kann zunächst Kontrollen im eigenen Backend nutzen. Sobald mehrere Dienste einheitliche Zugangsdaten, Budgets oder freigegebene Routen benötigen, lässt sich die zentrale Verwaltung dieser Regeln leichter begründen. Datenbank, Zugangsdaten und Updates des Gateways gehören dann ebenfalls zu den Betriebsaufgaben.

Was ändert sich bei 30 Personen?

Bei 30 Personen liegt das Hauptproblem in der Abstimmung von Änderungen zwischen verschiedenen Verantwortlichen. Zusätzliche Dashboards klären nicht, wer einen Prompt freigeben, einen Fallback genehmigen oder den Trace eines Kunden einsehen darf.

Produktteams bleiben für ihre Datensätze, Abnahmekriterien und Ergebnisse verantwortlich. Eine Plattformverantwortung übernimmt die gemeinsame Gateway-Konfiguration, die Identität der bereitgestellten Artefakte sowie Zugriff und Aufbewahrung von Traces. Festzulegen ist, wer Modell- und Richtlinienänderungen genehmigt, wer welchen Alarm erhält und wer die Abschaltung auslösen darf.

Einheitliche Release-Metadaten und Trace-Felder machen Vorfälle über Dienstgrenzen hinweg nachvollziehbar. Umgebungen und kundenspezifische Zugriffsbereiche werden getrennt. Für strittige Bewertungen braucht es Warteschlangen zur Prüfung. Regelmäßige Kontrollen sollten Modellabschaltungen, Sicherheitshinweise zu Abhängigkeiten und Datensatzdrift abdecken, also Veränderungen bei den Anfragen, die das Produkt erhält.

Wann sich eine LLMOps-Plattform lohnt

Eine gemeinsame Plattform wird sinnvoll, sobald wiederkehrende Abstimmungsfehler teurer sind als ihr Betrieb: inkompatible Prompt-Releases, doppelt aufgebaute Evaluierungsinfrastruktur, uneinheitliche Zugriffsregeln oder Vorfälle, die ohne klare Zuständigkeit mehrere Dienste betreffen.

Die Teamgröße ist ein Planungsszenario, keine technische Schwelle. Ein kleines Team, dessen Anwendung folgenschwere Aktionen ausführt, kann sofort strenge Kontrollen benötigen. Ein größeres Team mit einem klar begrenzten internen Feature kommt womöglich weiterhin mit wenigen Komponenten aus. Der Umfang der Kontrollen richtet sich nach dem möglichen Schadensausmaß und den Zuständigkeitsproblemen.

Welche Erwartungen sind überzogen?

Eigenes Training ist keine Einstiegsvoraussetzung. Wer ein gehostetes Modell nutzt, hat bereits ein System, das evaluiert und betrieben werden muss. Zuerst kommt der Release-Kreislauf. Danach lässt sich entscheiden, ob Fine-Tuning einen nachgewiesenen Fehler beheben kann.

Ein hoher Wert eines LLM-Bewerters ist kein allgemeines Qualitätssiegel. Er bezieht sich auf das vorgegebene Bewertungsraster und die ausgewählten Beispiele. Wo Fehlentscheidungen klare Folgen haben, bleiben menschliche Prüfung und deterministische Kontrollen erforderlich.

Automatisches Routing macht Fallbacks nicht beliebig austauschbar. Eine Route kann das Ausgabeverhalten, die Tool-Nutzung und den Zielort von Daten verändern. Solche Änderungen müssen bewusst freigegeben werden.

Observability bedeutet nicht, alles zu speichern. Aussagekräftige Traces brauchen ausreichend Kontext für die Fehleranalyse. Zugriffsregeln und die Bereinigung sensibler Inhalte müssen zu diesem Kontext passen.

LLMOps lernen: Buch oder Kurs?

Lernmaterial sollte sich an der Betriebsaufgabe orientieren, die noch nicht beherrscht wird. Ein Buch kann helfen, Architekturentscheidungen zu durchdenken. Ein Kurs ist dann nützlich, wenn seine Übungen dazu führen, einen Datensatz aufzubauen, Traces zu untersuchen, einen Release an Prüfungen zu knüpfen und den Betrieb nach einem Fehler wiederherzustellen. Ein Lehrplan, der sich nur auf Training konzentriert, lässt bei einem API-basierten Feature wichtige Lücken.

Die ersten Schritte für Montag

Wenn Kunden bereits auf das Feature angewiesen sind, müssen Freigabeprüfung, Aktionsberechtigungen und Wiederherstellungsablauf jetzt eingerichtet werden. Bei einem isolierten Prototyp ohne Kundendaten oder externe Aktionen können gemeinsame Gateways und Plattformverwaltung noch warten. Die Experimente sollten trotzdem reproduzierbar bleiben.

1. 1

   Ein Feature und seine Fehlerbedingungen festlegen

   Ausgangspunkt ist der wichtigste produktive Ablauf. Festgehalten werden akzeptable Ergebnisse, verbotene Aktionen, die zuständige Person und die Bedingungen, unter denen ein Release gestoppt werden muss.

2. 2

   Den aktuellen Release eindeutig zuordnen

   Prompt, Modell, Kontext, Tools, Richtlinie und die Identität der Abhängigkeiten werden erfasst. Dieser Nachweis wird mit einem von sensiblen Inhalten bereinigten Anfrage-Trace verknüpft.

3. 3

   Bekannte Fehler zur Freigabeprüfung machen

   Repräsentative Evaluierungsfälle bilden die Grundlage. Der aktuelle Release dient als Referenz. Bevor eine Verschlechterung in einer kritischen Kategorie akzeptiert wird, ist eine Prüfung vorgeschrieben.

4. 4

   Die Wiederherstellung üben

   Rollback und Abschaltung werden in einer sicheren Umgebung vorgeführt. Bevor eine weitere Plattform hinzukommt, werden die nächste Untersuchung und die nächste Prüfung von Abhängigkeitsupdates verbindlich zugeordnet.

Häufige Fragen zu LLMOps

Was unterscheidet ein LLM von LLMOps?

Ein LLM ist das Modell, das eine Ausgabe erzeugt. LLMOps bezeichnet die Betriebsdisziplin rund um die Anwendung, die es nutzt: Änderungen steuern, Verhalten prüfen, Anfragen beobachten und den Betrieb nach Fehlern wiederherstellen.

Wofür steht LLMOps?

LLMOps steht für large language model operations. Für ein Anwendungsteam gehören dazu auch die Prompts, der Kontext, die Tools und der Release-Prozess rund um das Modell.

Was sind die wichtigsten Unterschiede zwischen LLMOps und AgentOps?

AgentOps legt zusätzlichen Schwerpunkt auf mehrstufige Ausführung: Tool-Aktionen, dauerhaften Zustand, Berechtigungen, Schrittgrenzen und den Abschluss von Aufgaben. Ein Agent ist ein System, das mithilfe eines Modells Aktionen auswählt. Diese Aktionen müssen denselben Release- und Vorfallskontrollen unterliegen.

Welcher Kurs eignet sich am besten für LLMOps?

Für die hier angesprochene Zielgruppe empfiehlt sich ein Kurs, dessen bewertetes Projekt Evaluierung, Tracing, Bereitstellung und Wiederherstellung umfasst. Ein Kurs, der sich nur auf das Training eines Modells konzentriert, deckt die Betriebsaufgaben eines vorhandenen produktiven Features nicht ab.

Gibt es eine kostenlose MLOps-Zertifizierung?

Verfügbarkeit und Prüfungsbedingungen hängen vom Anbieter ab. Vor der Anmeldung sollte dessen aktuelle Zertifizierungsseite geprüft werden. Eine Zertifizierung ist keine Voraussetzung dafür, die hier beschriebenen Release-Kontrollen umzusetzen.

Kann man maschinelles Lernen in 3 Monaten lernen?

Der Zeitraum eignet sich für ein klar begrenztes Lernprojekt, nicht als Versprechen umfassender Produktionserfahrung. Für ein bestehendes LLM-Feature bietet sich eine versionierte Anwendung mit Evaluierungen, Traces und einem nachweislich funktionierenden Wiederherstellungsablauf an.

Wird man im Bereich maschinelles Lernen gut bezahlt?

Die Vergütung hängt von Rolle, Standort und Berufserfahrung ab. Eine LLMOps-Stellenbezeichnung allein sagt noch nichts über das Gehalt aus. Bei der Einstellung sollte geprüft werden, ob eine Person einen Evaluierungsfehler erklären und den daraus entstehenden Release sicher betreiben kann.

Ist man mit 30 zu alt, um Python zu lernen?

Nein. Ein kleines praktisches Projekt und regelmäßiges Üben sind ein guter Einstieg. Die für diesen Lebenszyklus nötige Anwendungsentwicklung lässt sich lernen, ohne zuvor Modellforschung zu betreiben.

Sind KI und maschinelles Lernen sehr schwierig?

Das hängt vom Umfang ab. Ein Feature zu betreiben, das ein vorhandenes Modell aufruft, und ein neues Modell zu erforschen sind unterschiedliche Lernvorhaben. Der Einstieg sollte bei den Software- und Evaluierungsaufgaben liegen, die das eigene Feature bereits mitbringt.

Für praktische Anleitungen zur Entwicklung und zum Betrieb von KI-Features: den Newsletter abonnieren.