Postmortem zu drei aktuellen Qualitätsproblemen bei Claude

• Von August bis Anfang September kam es aufgrund von drei Infrastruktur-Bugs zu einer Verschlechterung der Antwortqualität von Claude
• Die Hauptursachen waren jeweils ein Routing-Fehler beim Kontextfenster, beschädigte Ausgaben und ein Fehler durch nicht kompilierte approximate top-k-Operationen in XLA:TPU
• Die einzelnen Bugs überlappten sich über verschiedene Hardware- und Deployment-Pfade hinweg, was die Diagnose zusätzlich erschwerte
• Zu den Gründen für die verzögerte Erkennung und Behebung zählten Lücken im Validierungsprozess und Zugriffsbeschränkungen aufgrund von Datenschutzrichtlinien
• Anthropic arbeitet an der Vermeidung ähnlicher Vorfälle durch stärkere Evaluierung und Überwachung sowie die Entwicklung schnellerer Debugging-Tools

---

Überblick und Hintergrund

• Von August bis Anfang September wurde über zeitweise Einbrüche bei der Antwortqualität von Claude berichtet
• Zunächst wurde dies im Nutzerfeedback als normale Schwankung angesehen, doch mit den anhaltend zunehmenden Meldungen begann eine Untersuchung
• Anthropic stellte klar, dass nicht Nachfrage oder Serverlast, sondern ausschließlich Infrastruktur-Bugs die Ursache waren
• Claude wird für Millionen von Nutzern über mehrere Plattformen hinweg bereitgestellt (APIs, Amazon Bedrock, Google Vertex AI usw.) und unterliegt strengen Validierungsstandards, um auf verschiedener Hardware wie AWS Trainium, NVIDIA GPUs und Google TPUs gleichwertige Ergebnisse sicherzustellen
• Dieses Postmortem erklärt die Ursachen der Bugs, die Gründe für die verzögerte Diagnose und Behebung sowie Maßnahmen zur Vermeidung ähnlicher Vorfälle in der Zukunft

Wie Claude im großen Maßstab bereitgestellt wird

• Der Claude-Dienst wird über mehrere Hardware-Plattformen hinweg (Trainium, GPU, TPU) global ausgerollt
• Für jede Plattform gelten strenge Maßstäbe zur Sicherstellung gleichbleibender Qualität
• Bei Änderungen an der Infrastruktur ist über alle Plattformen und Konfigurationen hinweg ein präziser Validierungsprozess erforderlich

Zeitlicher Ablauf der wichtigsten Vorfälle

• 5. August: erster Bug, betraf etwa 0,8 % der Sonnet-4-Anfragen
• 25. und 26. August: zweiter und dritter Bug wurden jeweils ausgerollt
• 29. August: Durch eine Änderung beim Load Balancing nahm der problematische Traffic stark zu, sodass mehr Nutzer betroffen waren
• Da sich die Symptome der einzelnen Bugs überlagerten, war die Diagnose sehr schwierig

Die drei sich überlappenden Bugs und ihre Behebung

1. Routing-Fehler beim Kontextfenster

• Am 5. August wurden einige Sonnet-4-Anfragen fälschlich an Server für das 1M-Token-Kontextfenster geleitet
• Nach Änderungen am Load Balancing waren zeitweise bis zu 16 % der Sonnet-4-Anfragen betroffen; auch Amazon Bedrock und Google Vertex AI waren in geringem Maß betroffen
• Weil das Routing „sticky“ war, blieben Anfragen nach einer einmaligen Verbindung mit einem falschen Server weiterhin mit demselben Server verbunden
• Behebung: Verbesserung der Routing-Logik, Patch am 4. September auf der eigenen Plattform eingespielt, Ausrollung auf Google Cloud bis zum 16. September, für Bedrock läuft die schrittweise Einführung noch

2. Beschädigte Ausgaben (Bug)

• Am 25. August wurde auf den TPU-Servern der Claude API eine fehlerhafte Konfiguration ausgerollt, die bei der Token-Generierung Fehler verursachte
• Dabei traten Phänomene auf wie das Einmischen fremder Schriftzeichen wie Thai oder Chinesisch in englische Fragen oder klar erkennbare Syntaxfehler im generierten Code
• Betroffen waren nur Opus 4.1, Opus 4 und Sonnet 4; Drittanbieter-Plattformen waren nicht betroffen
• Behebung: Rollback der Änderung am 2. September; zusätzlich wurden im Deployment-Prozess Tests zur Erkennung anomaler Zeichenausgaben ergänzt

3. Fehler durch nicht kompilierte approximate top-k-Operationen in XLA:TPU

• Am 25. August wurde bei der Weiterentwicklung der Token-Auswahl ein latenter Bug im XLA:TPU-Compiler sichtbar
• Betroffen waren Claude Haiku 3.5, einige Sonnet-4-Deployments und Opus 3
• Drittanbieter-Plattformen waren nicht betroffen
• Behebung: Rollback für Haiku 3.5 am 4. September und für Opus 3 am 12. September; Sonnet 4 war nicht direkt reproduzierbar betroffen, wurde aber vorsorglich ebenfalls zurückgesetzt
• Parallel dazu arbeitet Anthropic mit dem XLA:TPU-Team an einer Behebung des Compiler-Bugs und stellt auf eine exakte top-k-Methode um

Detaillierte Analyse des XLA-Compiler-Bugs

• Claude berechnet bei der Token-Generierung Wahrscheinlichkeiten für Kandidaten und führt daraus Sampling durch
• TPUs arbeiten in einer verteilten Umgebung, wodurch die Synchronisation der Token-Wahrscheinlichkeiten komplex wird
• Im Dezember 2024 wurde ein Problem entdeckt, bei dem durch gemischte bf16- und 32-Bit-Präzision Fehler entstanden und Token mit der höchsten Wahrscheinlichkeit ausgelassen wurden; dafür wurde eine temporäre Korrektur ausgerollt
• Am 26. August wurde bei einer Überarbeitung des Sampling-Codes zur Behebung der Grundursache ein tieferliegender Bug sichtbar, bei dem approximate top-k in bestimmten Fällen vollständig falsche Ergebnisse ausgab
• Der frühere temporäre Fix hatte diesen Fehler verdeckt
• Außerdem zeigte der Bug in approximate top-k je nach Produktionsumgebung und Batch-Größe unregelmäßige Symptome
• Statt approximate top-k wurde inzwischen auf exact top-k umgestellt, dessen Performance-Kosten zuletzt deutlich gesunken sind; außerdem wurden zentrale Operationen durch Standardisierung auf fp32 verbessert

Gründe für die verzögerte Erkennung

• Es wurden regelmäßige automatisierte Evaluierungen und gestaffelte Vorab-Rollouts eingesetzt
• Die Vorfälle legten jedoch Lücken im Evaluierungsprozess offen. So erkannten bestimmte Tests problematische Zustände nicht zuverlässig, und interne Datenschutzrichtlinien (Ingenieure können nicht auf konkrete Nutzeranfragen zugreifen) erschwerten eine schnelle Analyse
• Da die Symptome je nach Plattform und Version unterschiedlich auftraten, war es schwer, eine einheitliche Ursache zu identifizieren
• Selbst als Online-Meldungen stark zunahmen, wurde der Zusammenhang mit einer gewöhnlichen Änderung beim Load Balancing nicht sofort erkannt

Künftige Verbesserungen und Gegenmaßnahmen

• Entwicklung sensiblerer Evaluierungsmetriken und Ausbau automatisierter Evaluierungen, die beschädigte Zustände klarer von korrekten Implementierungen unterscheiden können
• Ausweitung von Evaluierungs- und Monitoring-Systemen auf die gesamte Produktionsumgebung, etwa durch produktionsnahe Tests für Fehler wie Routing-Probleme beim Kontextfenster
• Aufbau schnellerer und präziserer Debugging-Tools sowie Infrastruktur und kundenspezifischer Werkzeuge, um Community-Feedback unter Wahrung des Datenschutzes zügig analysieren zu können
• Zusätzlich zu internen Evaluierungen wird die kontinuierliche Erfassung von Nutzerfeedback betont: Schwer vorhersagbare Fehler und Bugs werden oft zuerst durch reale Nutzermeldungen sichtbar
• Die Nutzung des Befehls "/bug" oder der Funktion „thumbs down“ sowie Hinweise per E-Mail zur Bewertung der Modellqualität werden ausdrücklich empfohlen

Zusätzliche Erläuterungen

• XLA:TPU ist ein Compiler, der Code in der Hochsprachen-Optimierungssprache XLA in TPU-Befehle umwandelt
• Aufgrund der großen Modellgröße werden Modelle nicht auf einem einzelnen Chip, sondern verteilt über mehrere Chips ausgeführt; Operationen wie Sorting müssen daher in vektorisierter Form implementiert werden
• approximate top-k wird zur Leistungssteigerung eingesetzt, kann jedoch schwerwiegende Probleme verursachen, etwa wenn Token mit der höchsten Wahrscheinlichkeit ausgelassen werden
• Inzwischen wurde auf exact top-k umgestellt; dabei kann es zu leichten Änderungen bei der Einbeziehung von Tokens nahe dem top-p-Schwellenwert kommen. In manchen Fällen müssen Nutzer ihren top-p-Wert eventuell anpassen