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

[GN⁺]

Hacker-News-Kommentare

• Eine bemerkenswerte Beobachtung zuletzt ist für mich das Fehlen von Unit-Tests. Sogar die Tests für den XLA-Compiler-Bug drucken anscheinend nur die Ausgabe aus, statt echte Unit-Tests zu sein, die in einer realen Test-Harness laufen und Coverage verfolgen. Als Gegenmaßnahme heißt es dann sinngemäß, man solle sich stärker auf Eval verlassen. Vollständiges Unit-Testing für das gesamte LLM ist derzeit unrealistisch, aber die bisher aufgetretenen Bugs lagen überwiegend in kleinen deterministischen Teilen des Systems. Dinge wie Load Balancing oder die Berechnung der Top-k-Wahrscheinlichkeiten sind technisch konstruierte Komponenten wie in jeder anderen Software und daher prinzipiell unit-testbar. Falls nötig, reicht dafür vielleicht schon ein injizierbarer PRNG. Nichtdeterministische Optimierungs-Bugs sind natürlich mühsam, aber auch klassische App-Test-Suites haben in der Vergangenheit Compiler- und Datenbank-Bugs aufgedeckt. Wenn man in CI viele Tests wiederholt ausführt, können selbst seltene Ereignisse sichtbar werden. In einem privaten Projekt lasse ich derzeit alle Unit-Tests parallel im selben Prozess laufen, und damit konnte ich selten auftretende Thread-Safety-Probleme und Datenbank-Deadlocks ziemlich effektiv finden. Vor ein paar Tagen hatte ich in einem Thread zum Java-Launch erwähnt, dass Java im Vergleich zu Python oft als „enterprise-tauglicher“ gilt, weil Code dort stärker mit Fokus auf Unit-Tests geschrieben wird. Durch den Wunsch nach Dependency Injection und Ähnlichem entsteht viel Abstraktion. In der Kultur rund um Skriptsprachen gab es dagegen oft entweder gar keine Tests oder nur oberflächliche Tests, etwa bloße Assertions auf Typen. Beim Lernen von PyTorch hatte ich einen ähnlichen Eindruck: Die Tutorials werden schrittweise komplexer, sagen aber fast nichts über Tests oder Code-Struktur. Für ML-Forschung mag das passen, wenn es vor allem darum geht, den Eval-Score zu steigern, für großflächige Production-Deployments aber eher nicht. Ich frage mich, ob AI-Labs nicht mehr Leute mit SRE- oder HA-Software-Engineering-Hintergrund brauchen. Persönlich bin ich skeptisch, ob aggressiv gefahrene Evals in Production wirklich der beste Schutz gegen Bugs sind.
  • Ich habe erlebt, dass ich der AI sehr detaillierte Prompts und Beispiele geben musste, damit sie in Python die Art von Unit-Tests schreibt, die ich will. Oft sieht man auch nur Assertions auf Typen. Ich will aber Assertions auf konkrete Werte. AI neigt außerdem dazu, alles zu mocken. Mocking ist nützlich, aber je mehr echter Code in einem Unit-Test tatsächlich aufgerufen wird, desto eher deckt man Risiken in Code-Interaktionen und Interfaces mit ab. Die von AI erzeugten Python-Unit-Tests sind jedoch oft so auf Mocking fixiert, dass am Ende nur tautologischer Code bestätigt wird. Deshalb nehme ich Warnungen vor übermäßigem Mocking und sorgfältige Testbeispiele aktiv in meine Prompts auf. Nebenbei: Auch Python hat hervorragende Werkzeuge, um strukturierten Code mit Dependency Injection und Ähnlichem zu schreiben.
• Ich war überrascht, im Artikel zu lesen, dass Anthropic direkten Einfluss auf die AWS-Bedrock-Infrastruktur haben könnte. Das widerspricht auch dem ursprünglichen Versprechen von AWS. Ich vermute, dass es bei Google Vertex AI ähnlich ist, habe das aber unter Compliance-Gesichtspunkten noch nicht geprüft.

Ich kann nachvollziehen, dass der Zugriff von Engineers auf Nutzerinteraktionen mit Claude aufgrund interner Datenschutz- und Sicherheitsrichtlinien eingeschränkt ist. Ich stimme auch zu, dass direkt eingesandtes Nutzerfeedback weiterhin am hilfreichsten ist und dass man in Claude Code den Befehl /bug verwenden kann. Wenn man so meldet, können Engineers vermutlich den Kontext einsehen, aber aus Nutzersicht sollte dieser Ablauf sehr klar kommuniziert werden, denn ich bin selbst kein Claude-Code-Nutzer. Der Hinweis, in der Claude-App den „thumbs down“-Button zu verwenden, macht mir etwas Sorgen. Die meisten Nutzer werden einen Klick darauf wohl nicht als etwas so Gewichtiges wie einen Verzicht auf Privatsphäre verstehen.

• (Anthropic-Mitarbeiter, persönliche Meinung)

Die Aussage, Anthropic verwalte die AWS-Bedrock-Infrastruktur direkt, entspricht nicht den Tatsachen. Aktuell wird sie direkt von AWS betrieben. Zum Datenschutzhinweis beim „thumbs down“-Button: In dem Modal steht ausdrücklich, dass „beim Absenden dieses Feedbacks die gesamte aktuelle Unterhaltung an Anthropic übermittelt und zur Verbesserung des Modells verwendet wird“. Ich würde gern wissen, ob es Ideen gibt, diesen Hinweis noch verständlicher zu formulieren.

• Beim Klick auf „thumbs down“ erscheint die Meldung „Wenn du dieses Feedback absendest, wird die gesamte Unterhaltung an Anthropic übermittelt“, daher finde ich den Hinweis bereits ziemlich klar.
• Wenn selbst ein Labor wie Anthropic Infrastrukturdetails offenlegt, scheint die Lage recht ernst zu sein. Der Präzisions-Bug bei FMA (Fused Multiply-Add) ist wirklich bedauerlich; numerische Probleme sind oft extrem verwirrend und weiterhin ein Bereich, den AI nicht lösen kann. Unter massivem Druck, wenn Konkurrenten in Echtzeit Marktanteile abziehen, ist menschliches Eingreifen letztlich unverzichtbar, und die Ursachenanalyse kann Wochen dauern.
• Es heißt dort: „Eine Load-Balancing-Änderung vom 29. August leitete zufällig mehr Short-Context-Requests an die 1M-Context-Server, und am 31. August waren eine Stunde lang 16 % der Sonnet-4-Anfragen betroffen.“ Das klingt für mich so, als hätten die 1M-Context-Server bei kurzen Eingaben sogar schlechtere Performance. Vielleicht ist das das Ergebnis separater Mechanismen auf diesen Servern, etwa KV-Cache-Kompression, Eviction oder Sparse Attention?
  • Das liegt am RoPE-Scaling. Die meisten bekannten Open-Source-Frameworks implementieren statisches YaRN, bei dem der Scaling-Faktor unabhängig von der Eingabelänge fest ist, was die Leistung bei kurzen Texten beeinträchtigen kann. Es wird empfohlen, rope_scaling nur dann zusätzlich zu konfigurieren, wenn wirklich lange Kontexte benötigt werden, und den Faktor an die durchschnittliche Eingabelänge der Anwendung anzupassen. Bei etwa 520.000 Tokens wäre zum Beispiel Faktor 2.0 besser. Quelle (Qwen3-Next-80B-Erklärungsseite)
  • Der Kern ihres Postmortems ist doch, dass bei zwei der drei Probleme die genaue Ursache nicht gefunden wurde. Soweit ich weiß, kann meine Anfrage derzeit auf irgendeinen von drei völlig unterschiedlichen Code-Pfaden geleitet werden, jeweils mit eigenem Stack und eigenem Tuning. Diese Optimierungen können sich offenbar plötzlich ändern, ohne dass ein Modell-Upgrade stattfindet, sodass etwas, das gestern noch funktionierte, heute kaputt sein kann. Ich finde es eher frustrierend, so sehr, dass ich kaum nachvollziehen kann, warum diese Postmortems gelobt werden.
• Mit allem Respekt für das Anthropic-Team: Die Qualität der Claude-Statusseite ist intern eigentlich ein Code-Red. Im Juli gab es 50 Incidents, im August 40 und im September 21. Ich habe früher erlebt, dass man schon bei der Hälfte solcher Zahlen die Richtung hart auf Uptime und Qualität umstellt. Trotzdem ist Claude weiterhin ein großartiges Produkt, weshalb ich noch bezahle. Ich habe die API ausprobiert und direkt die Max-Mitgliedschaft gebucht. Das hat meine Produktivität stark erhöht. Aber wegen der wiederholten Qualitätsprobleme in den letzten Wochen frage ich mich inzwischen, ob ich das Abo weiterführen sollte. Ich bin dankbar für die ehrliche Kommunikation, aber aus Kundensicht ist der Frust groß. Ich glaube noch nicht, dass Probleme wie das Load Balancing vollständig erkannt oder gelöst sind. Konkret habe ich um 12 Uhr Ostküste / 9 Uhr Westküste herum deutlich das Gefühl, dass die Qualität von Claude Code spürbar sinkt. Ich hoffe, das Team findet und behebt die Probleme weiter. Auch lokal laufende Modelle haben mir zu Hause schon viele komplexe Bugs beschert, also verstehe ich, dass diese Probleme nicht einfach sind. Link zur Statusseite
  • Ich würde nicht pauschal sagen, dass Claude im Vergleich zu anderen Firmen besser oder schlechter ist, aber eines ist sicher: Auf vielen Statusseiten wird gelogen. In Wirklichkeit gibt es häufig Ausfälle, die dort gar nicht auftauchen. Ehrlich gesagt überrascht es mich heute fast mehr, wenn Probleme offen gemeldet werden. Ich selbst hatte mit Claude keine gravierenden Vorfälle, vielleicht hatte ich nur Glück. Aus meiner Sicht berichtet Claude seine Störungen eher gewissenhafter. Natürlich kann auch das bloßer Zufall sein.
  • Noch besorgniserregender ist, dass auf Statusseiten viele kleinere Vorfälle komplett fehlen. Das gilt für alle AI-Anbieter. Wenn sie Diagramme zu Echtzeit-Token-Latenz, fehlgeschlagenen Requests oder Tokens pro Sekunde veröffentlichen würden, wäre das ziemlich schockierend. OpenRouter-Daten zeigen, dass die API-Uptime keineswegs gut ist. Claude Code wird auch oft extrem langsam, sodass ich manuell abbrechen und erneut versuchen muss. Besonders zwischen 16 und 18 Uhr britischer Zeit wird es schlimm, wenn Europa sowie die US-Ost- und Westküste gleichzeitig aktiv sind. Heute gab es auch in Gemini AI Studio wegen Modellüberlastung einen 503-Fehler, aber auf der Statusseite stand nichts. Ich frage mich, ob Anbieter wie Claude nicht günstigere Off-Peak-Tarife einführen könnten, um die Nachfrage besser zu verteilen. Solche Tarife könnten nach außen aber negativ wirken. Zusätzlich scheint die Einführung der GB200-GPUs viel langsamer verlaufen zu sein als erwartet, und es gab offenbar viele Hardware- und Softwarefehler. Auch Probleme mit Flüssigkeitskühlung scheinen erheblich gewesen zu sein; wenn dort etwas schiefgeht, ist das fatal.
  • Dass Leute sagen „Claude ist trotzdem so gut, dass ich dafür zahle“, ist an sich schon eine wichtige Erkenntnis. Im Moment ist die Qualität der AI für Kunden, mich eingeschlossen, wichtiger als die Zuverlässigkeit des Dienstes. Klar werden Anbieter sich irgendwann stärker auf Zuverlässigkeit konzentrieren, aber warum sollte das derzeit Vorrang vor Qualität haben?
  • Der jüngste Qualitätsabfall verunsichert mich erheblich. Zum Glück nutze ich AI noch nicht in Production, aber schon im Entwicklungsprozess ist es extrem schwer, damit umzugehen, wenn ein Modell plötzlich „dümmer“ wird. Im Moment frage ich mich auch, ob mehrere Anbieter auf OpenRouter das Vertrauen untergraben, indem sie stillschweigend den Kontext verkürzen, die Quantisierung reduzieren oder die Zahl der Experts verringern, also heimlich Rechenressourcen einsparen.
  • Genau deshalb verfolgen viele die Strategie, die Zahl der auf der Statusseite ausgewiesenen Incidents zu minimieren. Die Kundenbewertungen verschlechtern sich dadurch kurzfristig, aber dieser negative Effekt verschwindet mit der Zeit. Wenn man hingegen konsequent eine Statusseite pflegt, bleibt ein klarer „Beleg“ für die Probleme bestehen. Langfristig ist Täuschung also oft vorteilhafter. S3 hatte tatsächlich schon mehrfach Fehler und Ausfälle, die nie öffentlich gemacht wurden, und niemand hat sich daran gestört. Die Leute reden viel, aber in ihrem tatsächlichen Verhalten belohnen sie diejenigen, die Dinge verbergen. Alle Startup-Growth-Hacker wissen das längst.
• Es heißt, dass am 25. August eine fehlerhafte Konfiguration auf den TPU-Servern der Claude-API ausgerollt wurde, was bei der Token-Generierung Fehler verursachte. Code-Bugs kenne ich, aber LLMs werden ja nicht direkt von Menschen geschrieben, sondern entstehen durch groß angelegtes automatisiertes Training. Deshalb frage ich mich, wie solche Bugs überhaupt entstehen können. Wenn zum Beispiel mitten in einer englischen Antwort plötzlich „สวัสดี“ auftaucht, interessiert mich strukturell, wie so ein Fehler aus menschlicher Sicht in das System gelangen kann.
  • LLMs laufen letztlich auf von Menschen geschriebener Software. Im letzten Schritt erzeugt das Modell eine Wahrscheinlichkeitsverteilung über alle Tokens, also über das gesamte Vokabular von ungefähr 200.000 Einträgen. Danach entscheidet menschlich geschriebener Code, wie daraus das tatsächliche nächste Token ausgewählt wird. Man kann zum Beispiel immer das wahrscheinlichste Token nehmen oder zufällig aus den Top-k auswählen, um kreativere Ausgaben zu bekommen. Um dieses Top-k-Sampling effizient zu machen, wird ein Kernel mit XLA kompiliert, und offenbar gab es in diesem Kernel einen Bug, durch den gelegentlich Tokens außerhalb der Top-k gewählt wurden.
  • Ein LLM gibt letztlich eine Wahrscheinlichkeitsverteilung für das nächste Token aus, und das konkrete Ergebnis hängt dann vom verwendeten Sampling-Verfahren Beispiel ab. Wenn man zum Beispiel „zufällig eines der vier wahrscheinlichsten Tokens“ auswählt und dabei ein Operator, also etwa ein Vergleichszeichen, falsch ist, kann genau so ein Verhalten entstehen wie im Artikel beschrieben.
  • Zwischen Nutzer und Modellparametern liegen mehrere Schichten von menschen­geschriebenem Code.
  • Vereinfacht gesagt gibt es zwei Phasen: Training und Inferenz. Das Training ist ein lang laufender automatisierter Prozess, aber die Inferenz ist ein separater Software-Stack, der sofort ausgeführt wird, sobald der Prompt eines Nutzers hereinkommt. Dieser Stack erhält ständig Performance-Updates, und dabei entstehen dann solche inferenzbezogenen Probleme.
  • AI-Kernel arbeiten mit Gleitkommaoperationen. Dabei kann in Randfällen ein Wert, der eigentlich nicht negativ sein dürfte, auf seltsame Weise doch negativ werden. Aus Performance-Gründen werden Checks auf Overflow und Ähnliches manchmal abgeschaltet, und wenn dann ein negativer Wert auftaucht, wird er unter Umständen wie eine sehr große Zahl behandelt – ähnlich wie wenn man Index -1 in einem Array verwendet und das letzte Element herausbekommt.
• Ich glaube, dass es bei der Fehlersuche helfen könnte, den LLM-Inferenzprozess deterministischer zu machen. Vor Kurzem erschien auch ein Paper, das argumentiert, dass die übliche Erklärung „es liegt an der Reihenfolge der Gleitkomma-Verknüpfungen“ gar nicht der eigentliche Kern der Sache ist. Einführung zum relevanten Paper
  • Netzwerkverkehr oder Maschinenlast sind ihrem Wesen nach nichtdeterministisch. Vollständiger Determinismus, etwa für Audits, ist in absehbarer Zeit wohl nur für kostenunempfindliche Batch-Jobs realistisch. Auch Google Search oder das Laden von Empfehlungszahlen in sozialen Medien sind in der Praxis überhaupt nicht deterministisch. In verteilten Systemen lautet die zentrale Empfehlung eher graceful degradation, also Teilausfälle abzufedern. In einem vollständig deterministischen System wäre so etwas nicht möglich.
  • Deterministisches Design verschlechtert die Performance. Am Ende bleibt dann vielleicht nur ein Ansatz übrig, bei dem man noch ein weiteres Modell baut, das die Qualität des bestehenden Modells überwacht und Alarm schlägt – eine Art „IQ-Test“.
• Ich kann der Aussage zustimmen, dass die Fehlleitung bei Google Cloud Vertex AI zwischen dem 27. August und 16. September unter 0,0004 % lag. Ich nutze beruflich CC über diesen Account und habe keine Qualitätsverschlechterung wahrgenommen. Insgesamt hatte ich den Eindruck, dass diese Bugs zwar ernst waren, aber deutlich seltener auftraten, als Online-Berichte vermuten ließen. Der Zeitraum mit Problemen konzentrierte sich faktisch auch eher auf ein bis zwei Wochen. Gemessen an allen Requests war der betroffene Anteil relativ klein.
  • Im Firmenartikel selbst steht aber auch, dass „30 % der Claude-Code-Nutzer mindestens einmal an den falschen Server geroutet wurden und dadurch schlechtere Antwortqualität erlebten“. Das Routing ist „sticky“, das heißt: Ist man einmal einem falschen Server zugewiesen, gehen weitere Requests hintereinander an denselben Server. Wenn 30 % der Claude-Code-Nutzer Qualitätsprobleme hatten, ist das ein gewaltiger Bug.
  • In letzter Zeit traue ich Unternehmen generell nicht mehr leicht, weil selbst bei weltweiten Ausfällen oft nur Formulierungen wie „ein kleiner Teil der Nutzer sieht erhöhte Fehlerraten“ verwendet werden und die Statusseite erst angepasst wird, nachdem der CTO zugestimmt hat. Wenn es ein Unternehmen gäbe, das wirklich offen kommuniziert, wäre das ein echter Marktvorteil.
• Ich denke ebenfalls, dass es bei LLM-Diensten hilfreich wäre, das Verhalten deterministischer zu machen, um Probleme besser zurückzuverfolgen. Dabei wird auch ein jüngeres Paper erwähnt, wonach die Ursachen nicht nur auf die Reihenfolge von Floating-Point-Operationen zurückzuführen sind, sondern es weitere Gründe für den Zusammenbruch von Determinismus gibt. Link zum Paper
• Ich habe zuletzt erlebt, dass Claude beim Design von Web-Apps ernsthaft dazu neigte, im DOM zufälligen Text an beliebigen Stellen sichtbar zu machen. Das schien speziell in Kombination mit Svelte aufzutreten. Ob das mit den im Artikel beschriebenen Phänomenen zusammenhängt, weiß ich nicht, aber so starke Qualitätsprobleme hatte ich früher nicht.
• Ich wünschte, der Beitrag hätte konkrete Fehlfälle aufgenommen. In Claude Code erlebe ich häufig, dass es nach einem Tool-Call komplett stehen bleibt, und ich frage mich, ob das auf einen der hier genannten Bugs zurückzuführen war.
  • Ich erlebe in den letzten Tagen zunehmend genau dasselbe Problem. Vielleicht hat es nichts mit den im Text genannten Bugs zu tun und ist ein separater Fehler, aber ich hoffe, dass ich mich irre. Aufforderungen wie „Warum hast du angehalten? Bitte fahre fort“ muss ich in letzter Zeit auffällig oft erneut schicken.