- D’août au début septembre, une dégradation de la qualité des réponses de Claude s’est produite en raison de trois bugs d’infrastructure
- Les principales causes étaient respectivement une erreur de routage de la fenêtre de contexte, une corruption de sortie et une erreur de non-compilation du top-k approximatif sur XLA:TPU
- Chaque bug s’est superposé aux autres sur différents matériels et chemins de déploiement, ce qui a rendu le diagnostic encore plus difficile
- Les raisons du retard dans la détection et la résolution incluaient des failles dans le processus de validation ainsi que des restrictions d’accès liées à la politique de confidentialité
- Anthropic cherche à prévenir des incidents similaires en renforçant l’évaluation et la supervision et en développant des outils de débogage plus rapides
Vue d’ensemble et contexte
- D’août au début septembre, des baisses intermittentes de la qualité des réponses de Claude ont été signalées
- Au départ, cela a été considéré comme une variation normale dans les retours utilisateurs, mais l’augmentation continue des signalements a déclenché une enquête
- Anthropic précise clairement que le problème n’était lié ni à la demande ni à la charge des serveurs, mais uniquement à des bugs d’infrastructure
- Claude est proposé à des millions d’utilisateurs via plusieurs plateformes (API, Amazon Bedrock, Google Vertex AI, etc.) et applique des critères de validation stricts pour garantir des résultats équivalents sur différents matériels comme AWS Trainium, les GPU NVIDIA et les TPU Google
- Cette analyse post-mortem explique les causes des bugs, les raisons des retards de diagnostic et de résolution, ainsi que les mesures mises en place pour éviter une récidive
Comment Claude est exploité à grande échelle
- Le service Claude maintient un déploiement mondial à travers plusieurs types de matériel (Trainium, GPU, TPU)
- Les critères d’équivalence d’implémentation pour garantir une qualité identique sur chaque plateforme sont stricts
- Lors de changements d’infrastructure, un processus de validation précis est nécessaire sur toutes les plateformes et configurations
Chronologie des principaux incidents
- 5 août : premier bug, affectant environ 0,8 % des requêtes Sonnet 4
- 25 et 26 août : déploiement des deuxième et troisième bugs, respectivement
- 29 août : un changement de load balancing a fortement augmenté le trafic concerné, ce qui a touché davantage d’utilisateurs
- Les symptômes de chaque bug se chevauchaient, rendant le diagnostic extrêmement difficile
Les trois bugs superposés et leur résolution
1. Erreur de routage de la fenêtre de contexte
- Le 5 août, certaines requêtes Sonnet 4 ont été mal routées vers des serveurs destinés à une fenêtre de contexte de 1M de tokens
- Après les changements de load balancing, jusqu’à 16 % des requêtes Sonnet 4 ont été affectées, avec aussi un impact limité sur Amazon Bedrock et Google Vertex AI
- Le mécanisme de routage étant "sticky", une fois qu’une connexion était établie vers un mauvais serveur, elle continuait ensuite à utiliser ce même serveur
- Résolution : amélioration de la logique de routage, patch appliqué à la plateforme d’Anthropic le 4 septembre, déployé sur Google Cloud jusqu’au 16 septembre, et déploiement progressif en cours sur Bedrock
2. Corruption de sortie (bug)
- Le 25 août, une mauvaise configuration a été appliquée aux serveurs TPU de l’API Claude, provoquant des erreurs lors de la génération de tokens
- Des caractères incohérents comme du thaï ou du chinois apparaissaient dans des réponses à des questions en anglais, et des erreurs de syntaxe manifestes étaient insérées dans le code
- Seuls Opus 4.1, Opus 4 et Sonnet 4 ont été affectés ; les plateformes tierces ne l’ont pas été
- Résolution : rollback du changement le 2 septembre et ajout au processus de déploiement de tests détectant les sorties contenant des caractères anormaux
3. Erreur de non-compilation du top-k approximatif sur XLA:TPU
- Le 25 août, un bug latent du compilateur XLA:TPU a été mis en évidence pendant l’amélioration de la méthode de sélection des tokens
- Claude Haiku 3.5, une partie de Sonnet 4 et Opus 3 ont été affectés
- Les plateformes tierces n’ont pas été touchées
- Résolution : rollback de Haiku 3.5 le 4 septembre et d’Opus 3 le 12 septembre ; Sonnet 4 n’a pas pu être reproduit directement mais a aussi été rollbacké par précaution
- En parallèle, Anthropic collabore avec l’équipe XLA:TPU pour corriger le bug du compilateur et passe à une méthode de top-k exacte
Analyse détaillée du bug du compilateur XLA
- Lors de la génération de tokens, Claude effectue un calcul de probabilité pour chaque candidat ainsi qu’un échantillonnage
- Les TPU fonctionnent dans un environnement distribué, où les calculs de probabilité des tokens doivent être synchronisés, ce qui ajoute de la complexité
- En décembre 2024, un problème a été découvert : à cause d’erreurs liées à l’usage d’une précision mixte bf16-32 bits, le token de probabilité maximale pouvait être omis ; un correctif temporaire avait alors été déployé
- Le 26 août, lors d’une refonte du code d’échantillonnage visant à résoudre la cause profonde, un bug plus profond a été révélé : dans certains cas, l’opération de top-k approximatif produisait des résultats complètement erronés
- Le correctif temporaire précédent avait masqué ce problème
- De plus, les symptômes du bug de l’opération de top-k approximatif variaient de manière irrégulière selon l’environnement d’exploitation et la taille des batchs
- Au lieu du top-k approximatif, l’équipe est récemment passée à un top-k exact, dont le coût en performance a fortement diminué, et a amélioré les principales opérations en les standardisant en fp32
Pourquoi la détection a été retardée
- Des procédures telles que des évaluations automatisées périodiques et des déploiements préalables sur un groupe restreint étaient déjà utilisées
- Ces incidents ont toutefois mis en évidence des failles du processus d’évaluation. Par exemple, certains tests détectaient mal les situations problématiques, et les politiques internes de protection de la vie privée (les ingénieurs ne pouvant pas accéder aux requêtes utilisateur détaillées) compliquaient une analyse rapide
- Les symptômes variaient selon les plateformes et les versions, rendant l’identification d’une cause unique difficile
- Même lorsque les signalements en ligne ont fortement augmenté, le lien avec un changement standard de load balancing n’a pas été compris immédiatement
Améliorations et mesures à venir
- Développement de tests d’évaluation plus sensibles et renforcement des évaluations automatisées capables de distinguer plus clairement les états corrompus des implémentations normales
- Extension des systèmes d’évaluation et de supervision à l’ensemble de l’environnement de production, avec par exemple des évaluations centrées sur l’exploitation réelle comme les erreurs de routage de fenêtre de contexte
- Mise en place de nouveaux outils de débogage plus rapides et plus précis, ainsi que d’une infrastructure et d’outils sur mesure permettant d’analyser rapidement les retours de la communauté tout en préservant la confidentialité
- Au-delà des évaluations internes, Anthropic souligne l’importance d’une collecte continue et fiable des retours utilisateurs : pour les erreurs ou bugs difficiles à prévoir, les signalements réels des utilisateurs jouent un rôle de signal crucial
- L’usage de la commande
"/bug" ou de la fonction « thumbs down », ainsi que l’envoi par e-mail de méthodes d’évaluation de la qualité du modèle, sont activement encouragés
Explications complémentaires
- XLA:TPU est un compilateur qui convertit le code du langage d’optimisation de haut niveau XLA en instructions TPU
- En raison de la taille du modèle, celui-ci est réparti non pas sur une seule puce mais sur plusieurs, et des opérations comme le tri doivent être implémentées sous forme vectorisée
- L’opération de top-k approximatif est utilisée pour améliorer les performances, mais elle peut introduire de graves problèmes, comme l’omission du token ayant la probabilité la plus élevée
- Une méthode de top-k exacte est désormais utilisée, et de légers changements peuvent apparaître dans la manière dont les tokens proches du seuil top-p sont inclus. Selon les cas, les utilisateurs peuvent avoir à ajuster la valeur de top-p
Aucun commentaire pour le moment.