LLMOps für Claude: Betriebsmodell, Rollen und SLOs

TL;DR

LLMOps ist der Betrieb von Anwendungen auf einem gemieteten Modell wie Claude. Sie trainieren keine Gewichte. Sie versionieren Prompts, lassen jede Änderung durch Evals laufen, überwachen Latenz, Fehler, Drosselung und Tokenkosten und migrieren, bevor ein Modell abgeschaltet wird. Anthropic kündigt mindestens 60 Tage vorher an, Bedrock meist 6 Monate.

Was ist LLMOps, und worin unterscheidet es sich von MLOps?

LLMOps umfasst alle Praktiken, die eine LLM-Anwendung korrekt, schnell, bezahlbar und aktuell halten, sobald echte Nutzer davon abhängen. Bei Claude über Bedrock, Google Cloud oder die Claude API ist das Modell eine gemietete Abhängigkeit. Ihre Stellschrauben sind Prompts, Kontext, Parameter, Routing und die fixierte Modellversion. MLOps setzt ein eigenes Modell voraus.

Das verschiebt die Arbeit im Team. Niemand trainiert Claude neu. Stattdessen liefert der Anbieter neue Versionen, schaltet alte nach festem Kalender ab und ändert, welche Parameter ein Modell akzeptiert. Abgerechnet wird pro Token, nicht pro GPU-Stunde. Ein längerer Prompt ist damit eine Budgetentscheidung. Qualität wird an freiem Text gemessen, Unit-Tests reichen nicht.

	MLOps (eigenes Modell)	LLMOps (Claude als Dienst)
Was Sie ändern	Trainingsdaten, Features, Gewichte	Prompts, Kontext, Tools, Modell-ID, Parameter
Release-Einheit	Modellartefakt	Prompt-Version plus fixierte Modell-ID
Qualitätsprüfung	Holdout-Metriken (Accuracy, AUC)	Eval-Set, bewertet per Code, Mensch oder zweitem LLM
Hauptkostentreiber	Training und Serving-Compute	Input-, Output- und Cache-Tokens pro Anfrage
Kapazitätsgrenze	Eigener Cluster	Quotas des Anbieters (RPM, Tokens pro Minute)
Lebenszyklusrisiko	Data Drift	Anbieter schaltet das Modell zu einem fremden Termin ab
Datenschutz-Schwerpunkt	Trainingsdaten	Prompts und Antworten in Logs

Wir sehen LLMOps als schmaleren Job als MLOps, nicht als größeren. Wer SRE und Change Management schon betreibt, bringt das meiste in bestehende Prozesse unter. Neu sind Evals, Token-Ökonomie und Modellabkündigungen.

Wie sieht der LLMOps-Lebenszyklus für Claude aus?

Der Zyklus hat sechs wiederkehrende Schritte: Prompt versionieren, evaluieren, hinter einer fixierten Modell-ID ausrollen, überwachen, Kosten steuern und das Modell vor der Abschaltung wechseln. Jeder Schritt braucht einen Verantwortlichen und einen Auslöser. Am häufigsten fällt der letzte Schritt weg, obwohl nur er eine harte externe Frist hat.

1. Prompts wie Code versionieren. Systemprompt, Tool-Definitionen und Beispiele liegen in Git, neben der fixierten Modell-ID. Eine Prompt-Änderung ist ein Pull Request.
2. Über Evals freigeben. Anthropics Eval-Leitfaden fordert konkrete, messbare Erfolgskriterien und automatisierte Bewertung. Mehr Fragen mit etwas unschärferer automatischer Bewertung schlagen wenige handbewertete. Bewerten soll ein anderes Modell als das, das die Antwort erzeugt hat.
3. Mit fixierter ID ausrollen. Nutzen Sie eine vollständige Modell- oder Inference-Profile-ID wie eu.anthropic.claude-sonnet-5 auf Bedrock, nie einen Alias, den Sie nicht kontrollieren.
4. Überwachen: Fehler, Drosselung, Latenz und Tokens pro Modell (nächster Abschnitt).
5. Kosten steuern mit Prompt Caching und Budgets. Bei Claude Opus 5.5 kostet Input 4 USD pro Million Tokens, ein Cache-Treffer 0,20 USD, laut Prompt-Caching-Seite. Standardmodelle lesen den Cache zu 0,1x des Eingabepreises.
6. Vor der Abschaltung wechseln. Das volle Eval-Set gegen den Nachfolger laufen lassen, dann die fixierte ID umstellen.

An Schritt 6 bricht der Betrieb. Die Abkündigungsseite von Anthropic sagt mindestens 60 Tage Vorlauf für öffentlich verfügbare Modelle zu. Am 30. September 2026 hat Anthropic claude-sonnet-4-5-20250929 abgekündigt, Abschaltung am 30. November 2026, Nachfolger claude-sonnet-5-5. Diese Termine gelten für die Claude API. Bedrock und Google Cloud haben eigene Pläne. Die Lebenszyklus-Regeln von Bedrock kennen Legacy-Phasen von 6 Monaten oder 45 Tagen. Ein Legacy-Modell kann nach 15 Tagen ohne Nutzung den Zugriff verlieren.

Ein Modellwechsel ist kein Austausch einer Zeichenkette. Ab Claude 4.7 liefert ein vom Standard abweichender Wert für temperature, top_p oder top_k einen HTTP-400-Fehler. Ein Prompt, der ein Jahr lang lief, scheitert dann bei der ersten Anfrage an das neue Modell. Genau das soll der Eval-Lauf vor dem Wechsel finden.

Welche SLOs braucht eine Claude-Anwendung?

Legen Sie pro Anwendung vier SLOs fest: Verfügbarkeit, Latenz, Kosten pro Anfrage und Eval-Bestehensquote. Die Zielwerte unten sind unsere Empfehlungen als Startpunkt, keine Zusagen eines Anbieters. Kalibrieren Sie sie an zwei Wochen eigener Messwerte. Anbieter veröffentlichen Limits und Metriken, keine SLOs für Ihre Anwendung. Das Fehlerbudget definieren Sie selbst.

SLO (unsere Empfehlung)	Startwert	Messung auf Bedrock	Messung auf Google Cloud
Verfügbarkeit: erfolgreiche Anfragen nach Retries	99,5 % pro 30 Tage	InvocationServerErrors, InvocationThrottles gegen Invocations	prediction/online/error_count gegen response_count
Zeit bis zum ersten Token, Streaming-Chat, p95	unter 3 s	TimeToFirstToken	First-Token-Latenz im Model-Observability-Dashboard
Gesamtlatenz, p95	je Anwendungsfall	InvocationLatency	prediction/online/prediction_latencies
Kosten pro Anfrage, p50	Basiswert plus 20 %	Tokenzahlen im Invocation Log	Request-Response-Log, token_count-Metriken
Eval-Bestehensquote auf dem Golden Set	kein Rückgang gegenüber aktueller Version	Eigene Eval-Pipeline	Eigene Eval-Pipeline

Die Bedrock-Runtime-Metriken unter AWS/Bedrock enthalten TimeToFirstToken für Streaming-Aufrufe und EstimatedTPMQuotaUsage. AWS warnt, dass Letztere nur eine Näherung ist und nicht allein für die Kapazitätsplanung taugt. Gedrosselte Anfragen zählen weder als Invocations noch als Fehler. Rechnen Sie Drosselung deshalb als eigenen Term in die Verfügbarkeit ein. Auf Google Cloud zeigt das Model-Observability-Dashboard QPS, Token-Durchsatz und First-Token-Latenz auch für verwaltete Partnermodelle wie Claude.

Drosselung verdient einen eigenen Alarm. Bedrock reserviert beim Start jeder Anfrage Eingabetokens plus max_tokens aus der Quota. Output-Tokens verbrauchen bei Claude Opus 5.5, Sonnet 5, Opus 5 und Fable 5.1 dann das Zehnfache, laut der Seite zur Tokenzählung. Ein großzügiger max_tokens-Standardwert drosselt so einen Dienst, der real weit unter seinem Limit liegt.

aws cloudwatch put-metric-alarm --region eu-central-1 --alarm-name claude-throttles --namespace AWS/Bedrock --metric-name InvocationThrottles --dimensions Name=ModelId,Value=<model-id-wie-in-cloudwatch> --statistic Sum --period 300 --evaluation-periods 1 --threshold 10 --comparison-operator GreaterThanThreshold --alarm-actions <sns-topic-arn>

Auf der Claude API trägt der 429 bei einem Ratenlimit einen retry-after-Header. Der 429 bei erreichtem monatlichem Spend Cap hat keinen, und Retries scheitern, bis der Zugang wieder offen ist, so die Seite zu Ratenlimits. Alarmieren Sie error.details.error_code = enforced_spend_limit_reached getrennt. Das ist ein Budget-Vorfall, kein Kapazitätsproblem.

Welche Werkzeuge gehören in den LLMOps-Stack?

Vier Kategorien decken den Großteil ab: ein Gateway für Schlüssel, Routing und Budgets, Tracing für jede einzelne Anfrage, ein Eval-Runner und Kostenberichte. Starten Sie mit dem, was die Cloud mitbringt, ergänzen Sie OpenTelemetry-Instrumentierung und holen Sie ein eigenes Werkzeug erst, wenn eine Lücke schmerzt. Vertiefungen stehen in eigenen Artikeln.

Kategorie	In der Plattform enthalten	Offener Standard oder selbst betrieben
Gateway	Bedrock-IAM und Inference Profiles; Google-Cloud-Quotas	LiteLLM im eigenen EU-Netz
Anfrage-Logs	Bedrock Invocation Logging (CloudWatch Logs, S3); Google Cloud Request-Response-Logging (BigQuery)	OTLP an den eigenen Collector
Tracing	CloudWatch, Cloud Monitoring	OpenTelemetry-GenAI-Konventionen; Langfuse per OTLP
Evals	Bedrock Model Evaluation	Eigene Testumgebung in der CI
Kosten	Cost Explorer, Cloud Billing; Anthropic Usage and Cost API	Kostenlogs des Gateways

Bei den Anfrage-Logs trifft LLMOps auf die DSGVO. Das Bedrock Invocation Logging ist standardmäßig aus. Eingeschaltet erfasst es vollständige Anfragen und Antworten, inline bis 100 KB, darüber in S3. Ziele müssen im selben Konto und in derselben Region liegen. Das Request-Response-Logging von Google Cloud unterstützt Claude als Preview, schreibt nach BigQuery und nimmt eine Sampling-Rate zwischen 0 und 1. Beide Logs enthalten jede personenbezogene Angabe, die Nutzer eintippen. Legen Sie Aufbewahrung und Zugriff fest, bevor Sie sie einschalten, und tragen Sie das ins Verzeichnis der Verarbeitungstätigkeiten ein.

Für portables Tracing gibt es die OpenTelemetry-GenAI-Konventionen. Sie stehen noch auf Status Development, definieren aber bereits ein Anthropic-Profil. Ein Detail entscheidet über korrekte Kosten-Dashboards: Anthropics input_tokens enthält keine Cache-Tokens. Die Konvention rechnet den Gesamt-Input deshalb als input_tokens + cache_read + cache_write.

from opentelemetry import trace

tracer = trace.get_tracer("claude-app")

def record_usage(span, model: str, usage) -> None:
    span.set_attribute("gen_ai.provider.name", "anthropic")
    span.set_attribute("gen_ai.request.model", model)
    cache_read = usage.cache_read_input_tokens or 0
    cache_write = usage.cache_creation_input_tokens or 0
    span.set_attribute("gen_ai.usage.cache_read.input_tokens", cache_read)
    span.set_attribute("gen_ai.usage.cache_write.input_tokens", cache_write)
    span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens + cache_read + cache_write)
    span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

Langfuse nimmt OTLP auf /api/public/otel über HTTP an (JSON oder Protobuf, kein gRPC). Dieselben Spans können also eine selbst gehostete Trace-Oberfläche füttern. Die Tokenpreise hinter diesen Dashboards stehen in unserem Claude-API-Kostenvergleich.

Wer ist im LLMOps-Team wofür verantwortlich?

Vier Rollen tragen LLMOps: Product Owner für Qualitätskriterien, Anwendungsentwicklung für Prompts und Evals, Plattform-Engineering für Gateway, Quotas und Logging, und eine Rufbereitschaft für Störungen. In kleinen Teams hält eine Person zwei Rollen. Scheitern wird es, wenn Modellabkündigung und Eval-Pflege keinen benannten Verantwortlichen haben.

Rolle	Verantwortet	Wiederkehrende Aufgabe
Product Owner	Erfolgskriterien, Abnahme der Evals	Gibt Änderungen am Eval-Set und Qualitätsabwägungen frei
Anwendungsentwicklung	Prompts, Tools, Eval-Fälle	Übernimmt fehlgeschlagene Produktionsfälle ins Eval-Set
Plattform-Engineering	Gateway, Quotas, Invocation Logging, IAM	Quota-Anträge, max_tokens-Tuning, Log-Aufbewahrung
Rufbereitschaft	SLOs für Verfügbarkeit und Latenz	Alarme zu Drosselung und 5xx, Anbieterstatus, Rollback
Datenschutzbeauftragte	Log-Inhalte, AVV, Unterauftragsverarbeiter	Prüft Logging-Umfang und Aufbewahrung

Die Modellabkündigung gehört zum Plattform-Engineering, die Evals dazu fährt die Anwendungsentwicklung. Auslöser ist die Abkündigungs-Mail oder der Legacy-Status auf einer Bedrock-Modellkarte. Für Sonnet 5 nennt diese Karte derzeit ein EOL nicht vor dem 30. Juni 2027 und eine Legacy-Phase von mindestens 6 Monaten. Welche Regionen für dieselben Modelle in Frage kommen, steht in unserem Amazon-Bedrock-Überblick.

Selbst betreiben oder auslagern?

Betreiben Sie LLMOps selbst, wenn Claude ein Kernprodukt trägt und Sie Rufbereitschaft und Plattform-Team schon haben. Lagern Sie Teile aus, wenn Sie ein oder zwei Claude-Anwendungen haben, keine 24/7-Bereitschaft und niemanden, zu dessen Job das Lesen von Abkündigungen gehört. Evals bleiben in beiden Fällen bei Ihnen, denn nur Ihr Team weiß, was eine richtige Antwort ist.

Was der Eigenbetrieb kostet, als unsere Schätzung und nicht als gemessener Wert: pro produktiver Anwendung etwa eine halbe Stelle Plattform-Engineering für Gateway, Quotas, Logging und Modellwechsel, einige Stunden pro Woche Anwendungsentwicklung für die Eval-Pflege und ein Anteil an einer bestehenden Rufbereitschaft. Die wiederkehrenden Aufgaben stehen fest: wöchentliche Durchsicht von Drosselung und Kosten pro Anfrage, monatliche Pflege des Eval-Sets und ein Migrationsprojekt pro Abkündigung.

Ein Managed-Service-Anbieter lohnt sich für die Plattformschicht: Rufbereitschaft für Gateway und Quotas, Einrichtung des Invocation Logging und das Verfolgen der Abschaltpläne auf Bedrock und Google Cloud. Weniger sinnvoll ist er für Eval-Design und Prompt-Änderungen. Ein Dienstleister, der Ihre Prompts ohne Ihr Eval-Gate ändert, liefert Änderungen, die Sie nicht beurteilen können.

Was Sie von einem Anbieter für LLMOps konkret verlangen sollten:

1. SLA, das an Ihre SLOs gekoppelt ist: Reaktionszeit auf Drossel- und 5xx-Alarme, mit den SLO-Definitionen im Vertrag, nicht nur “best effort”.
2. AVV nach Art. 28 DSGVO, der die Logs abdeckt: wo Invocation Logs und Traces liegen, wie lange, und wer Prompt-Inhalte lesen darf.
3. Liste der Unterauftragsverarbeiter, inklusive jedes Tracing- oder Eval-SaaS, das der Anbieter einbringt.
4. Zugriffsmodell: Zugriff nur über Rollen in Ihrem AWS- oder Google-Cloud-Konto, protokolliert in CloudTrail oder Cloud Audit Logs, nie über geteilte Root-Schlüssel.
5. Pflicht bei Abkündigungen: schriftliche Zusage, jede Abkündigung zu melden und Ihr Eval-Set vor dem Wechsel gegen den Nachfolger laufen zu lassen.
6. Exit: Prompts, Eval-Sets, Dashboards und Alarmdefinitionen liegen in Ihrem Repository, damit eine Übergabe nicht bei null beginnt.

FAQ

Was ist der Unterschied zwischen LLMOps und MLOps?

MLOps verwaltet Modelle, die Sie selbst trainieren: Datenpipelines, Trainingsläufe, Modellartefakte. LLMOps verwaltet Anwendungen auf einem gemieteten Modell, das Sie nicht trainieren. Die Arbeit verlagert sich auf Prompt-Versionierung, Evals, Tokenkosten, Anbieter-Quotas und den Wechsel, bevor der Anbieter eine Modellversion abschaltet.

Wie viel Vorlauf gibt es vor der Abschaltung eines Claude-Modells?

Auf der Claude API kündigt Anthropic öffentlich verfügbare Modelle mindestens 60 Tage vorher an. Bedrock legt eigene Termine fest, mit einer Legacy-Phase von 6 Monaten oder 45 Tagen, meist 6 Monate. Google Cloud hat ebenfalls einen eigenen Plan. Maßgeblich ist die Plattform, die Sie tatsächlich aufrufen.

Wie viel spart Prompt Caching bei Claude?

Ein Cache-Read kostet bei Standardmodellen 0,1x des Eingabepreises und bei Claude Opus 5.5 0,05x: 4 USD Input gegenüber 0,20 USD pro Million Tokens. Ein 5-Minuten-Cache-Write kostet 1,25x. Auf der Claude API zählen Cache-Reads bei den meisten Modellen außerdem nicht auf das Limit für Eingabetokens pro Minute.

Welche Metriken sollten wir für Claude auf Bedrock alarmieren?

InvocationThrottles, InvocationServerErrors und TimeToFirstToken pro Modell-ID im Namespace AWS/Bedrock. Für die Kosten verfolgen Sie InputTokenCount, OutputTokenCount und die Cache-Tokenzahlen. EstimatedTPMQuotaUsage behandeln Sie als Näherung, wie AWS selbst.

Liefern Anthropic oder AWS SLOs für LLM-Anwendungen?

Nein. Anbieter veröffentlichen Ratenlimits, Quotas, Fehlercodes und Metriken. Die SLOs Ihrer Anwendung, etwa 99,5 % Verfügbarkeit oder ein Zielwert für die Zeit bis zum ersten Token, definieren Sie selbst. Die Werte in diesem Artikel sind unsere Empfehlung als Startpunkt.

Sollte Invocation Logging in Produktion an sein?

Ja, mit Grenzen. Ohne Anfrage-Logs können Sie weder Fehler analysieren noch Eval-Fälle aus echten Ausfällen bauen. Die Logs enthalten aber personenbezogene Daten. Beschränken Sie den Zugriff, legen Sie eine Aufbewahrungsfrist fest, dokumentieren Sie das im Verzeichnis der Verarbeitungstätigkeiten und nutzen Sie auf Google Cloud Sampling, wenn kein Volllogging nötig ist.

Quellen

1. Anthropic: Model deprecations (1. Oktober 2026)
2. Anthropic: Rate limits (1. Oktober 2026)
3. Anthropic: Prompt Caching (1. Oktober 2026)
4. Anthropic: Erfolgskriterien und Evals (1. Oktober 2026)
5. Anthropic: API-Fehler (1. Oktober 2026)
6. Anthropic: Usage and Cost API (1. Oktober 2026)
7. AWS: CloudWatch-Metriken für bedrock-runtime (1. Oktober 2026)
8. AWS: Model Invocation Logging (1. Oktober 2026)
9. AWS: Tokenzählung in Amazon Bedrock (1. Oktober 2026)
10. AWS: Modell-Lebenszyklus in Bedrock (1. Oktober 2026)
11. AWS: Modellkarte Claude Sonnet 5 (1. Oktober 2026)
12. Google Cloud: Quotas für Anthropic Claude (1. Oktober 2026)
13. Google Cloud: Request-Response-Logging (1. Oktober 2026)
14. Google Cloud: Modelle überwachen (1. Oktober 2026)
15. OpenTelemetry: GenAI Semantic Conventions (1. Oktober 2026)
16. Langfuse: OpenTelemetry-Integration (1. Oktober 2026)