MLOps vs. LLMOps: Infrastruktur für Foundation Models

Viacheslav Dubrov

2025-05-06 · Aktualisiert 2026-07-15 · 7 Min. · KI-Infrastruktur

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Wenn ein Release eines Foundation Models regressiert, ist die Weight-Datei möglicherweise unverändert: Ein Prompt, ein Retrieval Index, eine Tool-Berechtigung, eine Route oder eine Policy kann sich geändert haben. Für Engineers aus den Bereichen ML, Plattformen und AI-Anwendungen, die bereits konventionelles MLOps betreiben, ist das praktische Artefakt daher ein Release Manifest, das diese Abhängigkeiten benennt und auf den zuerst zu prüfenden Kontrollpunkt verweist, sobald ein Fehler auftritt.

Dies ist ein redaktionelles Betriebsmodell und keine Aussage, dass jede Anwendung dieselbe Plattform benötigt. Beibehalten werden sollten MLOps-Lineage, gestaffelte Auslieferung, Monitoring und Rollback; erweitert werden muss jedoch die Versionierungseinheit, sobald generierte Antworten oder Tool-Aktionen vom Verhalten von mehr als nur den Weights abhängen.

TL;DR. Behalte MLOps-Lineage, Automatisierung, gestaffelte Auslieferung, Monitoring und Rollback bei. Erweitere das Release Manifest um Provider oder Weights, Prompts, Schemas, Retrieval-Zustand, Tools, Routing und Policy. Führe dieses Manifest durch mehrere Evaluationsschichten und nutze anschließend datenschutzbewusste Traces, um Produktionsfehler in neue Tests zu überführen.

Was MLOps bereits gelöst hat

MLOps hat Kontrollen etabliert, die nicht obsolet werden, wenn das Model Text generiert:

• Lineage von Daten, Code, Konfiguration und Model bis zu einem Release
• wiederholbare Training- oder Build-Pipelines
• Offline-Validierung vor der Promotion
• Registries und unveränderliche Artifact-Identität
• gestaffelter Rollout, Service-Level Objectives, Rollback und Incident Response
• Infrastruktur-Telemetrie und Kapazitätsplanung
• Access Control, Aufbewahrung und Audit-Policy für Daten

Foundation Models beseitigen diese Anforderungen nicht. Sie machen lediglich den alten Begriff „Model-Version“ zu klein.

Die Release-Einheit wurde zu einem System Manifest

Für ein System mit einem Foundation Model empfehle ich ein Manifest, das mindestens Folgendes erfasst:

application code revision
model provider + model/revision + serving configuration
system and task prompts
response schema + decoding parameters
retrieval corpus snapshot + parser + chunker + embedding model + index
tool definitions + implementation revisions + permission policy
routing, fallback, caching, and budget policy
safety and business-rule revisions
evaluation dataset + scorer revisions

Die genaue Liste hängt vom jeweiligen System ab. Die redaktionelle Regel lautet: Identifiziere jede unabhängig veränderbare Komponente, die das für User sichtbare Verhalten beeinflussen kann.

Behandle einen Provider-Model-Namen als veränderlich, sofern der Provider keine unveränderliche Revision dokumentiert. Ein Checkpoint-Hash hilft bei der Identifikation von selbst gehosteten Weights; dennoch würde ich auch Runtime, Quantization, Template und Parallelism-Konfiguration erfassen.

Fünf erweiterte Fehleroberflächen

Der Unterschied zwischen MLOps und LLMOps wird in der Fehleranalyse deutlicher als in Tool-Listen.

1. Model und Serving

Für die Planung sollten Hosted-Model-Aspekte (Provider-Verfügbarkeit, Quotas, regionale Verarbeitung und Nutzungskosten) von Self-Hosted-Aspekten (Weight-Versorgung, GPU-Kapazität, Batching, Cache-Policy, Quantization und Serving) getrennt werden. Die relevanten Kontrollen hängen vom gewählten Deployment ab.

In beiden Betriebsmodi sollten Latency, Fehler, Throughput, Saturation, Kosten und Checks der Task-Qualität in die Release-Entscheidung einfließen.

2. Prompt, Schema und Orchestration

Bei einem System, das Requests zur Laufzeit zusammenstellt, sollte der zusammengestellte Request statt nur des Prompt-Texts versioniert werden: Message-Reihenfolge, Tool-Beschreibungen, Response Schema, Decoding, Retries, Truncation und umgebender Code können das Verhalten jeweils verändern.

Behandle parsierbares JSON als Transport-Check und teste die Business-Invarianten der Task anschließend separat.

3. Retrieval und Context

Retrieval fügt zwischen der Source of Truth und dem Model ein unabhängiges Datenprodukt hinzu:

Bei einem Retrieval-Augmented-System sollten Source-Revision, Parser- und Chunker-Versionen, Embedding-Identität, Index-Build, Access-Control-Metadaten und Löschstatus aufbewahrt werden. Das ursprüngliche RAG-Design trennt Retrieval und Generation; nutze diese Trennung, um Evidence Retrieval, Autorisierungsfilterung und die Verwendung von Evidence unabhängig voneinander zu testen. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks beschreibt die Retrieve-then-Generate-Architektur.

Verwende keinen Vector Index als Ersatz für einen Feature Store oder ein Warehouse: Similarity Retrieval, Point-in-Time-Features und analytische Fakten haben unterschiedliche Anforderungen an Queries und Konsistenz.

4. Tools und Aktionen

Wenn ein Model APIs aufrufen kann, gehören Tool-Authentifizierung, Least Privilege, Argumentvalidierung, Timeouts, Idempotenz, Approval Policy und Postcondition-Checks zur operativen Grenze. Das Generative AI Profile von NIST benennt Risiken durch schädliche Inhalte, Datenschutz und Security; die aufgeführten Kontrollen sind eine abgegrenzte Engineering-Empfehlung und kein vollständiger Kontrollkatalog.

Trace, welches Tool angeboten, ausgewählt, aufgerufen, abgelehnt, erneut versucht und committed wurde. Eine flüssige finale Antwort beweist nicht, dass der Aktionspfad korrekt war.

5. Safety, Security und Policy

Content Filter sind eine einzelne Kontrolle und keine vollständige Guardrail-Schicht. Zu den Bedrohungen gehören außerdem Prompt Injection, Cross-Tenant Retrieval, Offenlegung von Secrets, übermäßige Handlungsautonomie, nicht vertrauenswürdiger Model- oder Node-Code sowie unsichere Tool-Argumente.

Drücke deterministische Business-Regeln nach Möglichkeit außerhalb des Models aus. Definiere verbleibende Risiken, teste adversariale Fälle und benenne einen Owner für Policy-Änderungen. Das Generative AI Profile von NIST ist ein nützliches Risiko-Inventar, aber kein fertiger Abnahmetest.

Evaluation wird zum Release Gate

Verlasse dich bei Release-Entscheidungen für Free-Form-Output nicht auf eine einzelne aggregierte Accuracy-Zahl. Nutze mehrere Evidenztypen und definiere für jeden Fehlermodus, welcher davon maßgeblich ist.

Baue einen Evaluations-Stack mit mehreren Evidenztypen auf:

1. Deterministische Checks: Schema-Validität, vorhandene Citations, erlaubte Tools, Argument-Constraints, Policy-Regeln, Latency und Budget.
2. Komponentenmetriken: Retrieval Recall und Ranking, Tool-Selection-Accuracy, Korrektheit von Tool-Argumenten und Route Selection.
3. End-to-End-Tasks: Repräsentative Inputs mit expliziten Erfolgskriterien und Slice-Labels.
4. Model-basierte Bewertung: Rubrikgesteuerte Beurteilungen, kalibriert anhand von Expertenlabels und überwacht auf Judge Drift.
5. Human Review: Ambige, folgenreiche, neuartige oder gesampelte Fälle, bei denen Automatisierung nicht maßgeblich ist.
6. Adversariale Tests: Injection-, Data-Boundary-, Abuse-, Refusal- und Side-Effect-Fälle, die an das Threat Model gekoppelt sind.

Speichere Ergebnisse pro Beispiel und nicht nur Mittelwerte, damit das Release Review Regressionen nach Sprache, Tenant, Dokumenttyp oder Aktionsklasse untersuchen kann.

Vergleiche für ein Deployment Gate ein Candidate Manifest mit dem aktuellen Release anhand derselben versionierten Suite. Lege Schwellenwerte für Quality, Safety, Latency und Kosten gemeinsam fest; eine günstigere Route, die die Task nicht erfüllt, ist keine Optimierung.

Traces verbinden Produktion mit Evaluation

Infrastrukturmetriken können einen langsamen Model Call zeigen. Sie zeigen jedoch nicht, dass Retrieval ein nicht autorisiertes Dokument zurückgegeben hat oder dass ein Tool mit dem falschen Account aufgerufen wurde. Die Tracing-Dokumentation von MLflow beschreibt Traces, die für die Untersuchung dieses Pfads erforderliche Zwischenschritte und Metadaten erfassen.

Erfasse einen Trace über den gesamten Entscheidungsweg:

• Identität des Release Manifests und Request-Korrelation
• Model- und Provider-Calls, Latency, Nutzung und Finish-Status
• Retrieval-Query, Dokument-IDs, Scores und Filterentscheidungen
• Prompt-/Template-Revision, ohne sensible Inhalte indiscriminately zu speichern
• Tool-Angebote, Argumente, Freigaben, Ergebnisse und IDs von Side Effects
• Policy-Entscheidungen, Retries, Fallbacks und finales Ergebnis

Tracing schafft eine neue Data-Governance-Oberfläche. Wende vor der Erfassung vollständiger Prompts oder Dokumente Data Minimization, Redaction, Tenant-Isolation, Verschlüsselung, Sampling, Aufbewahrungsregeln und Access Review an. Die GenAI Semantic Conventions von OpenTelemetry können die Interoperabilität unterstützen, befinden sich jedoch noch in Entwicklung. Pinne die Version der Convention oder des Schemas sowie die Versionen von Instrumentation und Collector.

Der Improvement Loop lautet:

production trace → triaged failure → labeled regression case
                 → candidate change → offline comparison
                 → staged release → monitored outcome

User-Feedback kann die Untersuchung priorisieren, ist aber keine Ground Truth. Bewahre den umgebenden Trace auf und hole für folgenreiche Fälle Expertenlabels ein.

Das Serving Gateway ist eine Policy-Grenze

Ein Gateway kann Application Clients von Providern oder selbst gehosteten Engines entkoppeln. Zu den Verantwortlichkeiten, die dort sinnvoll aufgehoben sind, gehören:

• Authentifizierung, Tenant-Budgets, Quotas und Rate Limits
• stabile Request- und Response-Contracts
• Route Selection nach Capability, Region, Latency oder evaluierter Quality
• begrenzte Retries, Circuit Breaker und explizite Fallback-Semantik
• Cache-Partitionierung und Policy für sensible Daten
• Nutzungszuordnung und Weitergabe des Release Manifests

Fallback ist ebenso eine Verhaltensänderung wie ein Reliability-Mechanismus. Wenn ein kleineres Model, ein alternativer Provider oder ein reduzierter Context die Task-Qualität verändert, muss dieser Branch als eigene Route evaluiert und getraced werden.

Verlagere nicht jede Orchestration-Entscheidung in das Gateway. Halte Domain-Regeln nahe an der Anwendung und mache Ownership sichtbar.

Fine-Tuning ist eine Intervention, nicht die Reifegradleiter

Wähle die Intervention anhand des beobachteten Fehlers:

LoRA friert pretrained Weights ein und ergänzt trainierbare Low-Rank-Matrizen, wodurch die Zahl der trainierbaren Parameter für die Downstream-Task sinkt. Diese Optimierung beseitigt weder Data Governance, das Licensing des Base Models, Evaluation, Serving-Kompatibilität noch Rollback-Anforderungen.

Eine praktische Einführungssequenz

1. Definiere die User-Task, Schadensgrenzen, Service-Ziele und den Kostenrahmen.
2. Erstelle das Release Manifest, bevor du eine Prompt Registry, eine Vector Database oder ein Gateway-Produkt einführst.
3. Baue einen kleinen, geslicten Evaluationsdatensatz und deterministische Komponenten-Tests auf.
4. Instrumentiere einen End-to-End-Trace mit Privacy Controls und stabilen Release-Identitäten.
5. Führe das Release über Shadow, Canary oder begrenzten Traffic aus und definiere einen expliziten Rollback-Trigger.
6. Überführe geprüfte Produktionsfehler in Regression Cases und wiederhole den Prozess.

Füge Infrastruktur nur hinzu, wenn sie eine benannte Kontrolle verantwortet oder einen gemessenen Bottleneck beseitigt. Eine „LLMOps-Plattform“ ist keine Architekturvoraussetzung.

Fazit

LLMOps ist MLOps, angewendet auf eine größere Verhaltenseinheit. Das Model bleibt wichtig, aber Prompts, abgerufene Evidence, Tool-Berechtigungen, Routing und Policy können das Ergebnis verändern, ohne dass sich die Weights ändern.

Versioniere diese gesamte Einheit, evaluiere sie vor dem Release, trace sie mit Privacy Boundaries und rolle sie als ein System zurück.

Referenzen

• MLflow: Evaluating Production Traces – Produktions-Traces für Evaluation wiederverwenden und Informationen aus Zwischenstufen des Traces bewerten.
• MLflow: LLM- und Agent-Tracing – Zwischenschritte und Trace-Metadaten für Untersuchungen erfassen.
• OpenTelemetry GenAI Semantic Conventions – Aktuelle Conventions im Entwicklungsstatus für GenAI-Spans, Metriken, Events und provider-spezifische Daten.
• NIST AI 600-1: Generative AI Profile – Risikokategorien für Prompt Injection, Datenschutz, Security und verwandte Generative-AI-Themen.
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks – Ursprüngliche Retrieve-then-Generate-Architektur.
• LoRA: Low-Rank Adaptation of Large Language Models – Eingefrorene pretrained Weights plus trainierbare Low-Rank-Matrizen für die Downstream-Anpassung.