Post-mortem de três problemas recentes de queda de qualidade no Claude

• De agosto até o início de setembro, houve uma queda na qualidade das respostas do Claude causada por três bugs de infraestrutura
• As principais causas dos problemas foram, respectivamente, erro de roteamento da janela de contexto, corrupção de saída e erro de miscompilation do approximate top-k no XLA:TPU
• Cada bug se sobrepunha aos outros em diferentes hardwares e caminhos de implantação, tornando o diagnóstico ainda mais difícil
• Entre os motivos para o atraso na detecção e correção estavam falhas no processo de validação e restrições de acesso decorrentes da política de privacidade
• A Anthropic está trabalhando na ampliação de avaliações e monitoramento e no desenvolvimento de ferramentas de depuração mais rápidas para evitar incidentes semelhantes

---

Visão geral e contexto

• De agosto até o início de setembro, foram relatados casos intermitentes de queda na qualidade das respostas do Claude
• No começo, isso foi considerado uma variação normal dentro do feedback dos usuários, mas a investigação começou à medida que os relatos continuaram aumentando
• A Anthropic deixou claro que a causa do problema não foi demanda nem carga de servidores, mas apenas bugs de infraestrutura
• O Claude atende milhões de usuários por várias plataformas (APIs, Amazon Bedrock, Google Vertex AI etc.) e mantém critérios rigorosos de validação para garantir resultados equivalentes em diferentes hardwares, como AWS Trainium, NVIDIA GPU e Google TPU
• Neste post-mortem, são explicadas as causas dos bugs, os motivos do atraso no diagnóstico e na correção, e as medidas para evitar recorrência

Como o Claude opera em larga escala

• O serviço do Claude mantém uma implantação global em vários hardwares (Trainium, GPU, TPU)
• Os critérios de equivalência de implementação para garantir a mesma qualidade em cada plataforma são rigorosos
• Ao fazer mudanças na infraestrutura, é necessário um processo de validação preciso em todas as plataformas e configurações

Linha do tempo dos principais incidentes

• 5 de agosto: primeiro bug, afetando cerca de 0,8% das requisições do Sonnet 4
• 25 e 26 de agosto: segundo e terceiro bugs implantados, respectivamente
• 29 de agosto: uma mudança no balanceamento de carga fez o tráfego problemático aumentar, afetando mais usuários
• Como os sintomas dos bugs se sobrepunham, a dificuldade de diagnóstico foi muito alta

Os três bugs sobrepostos e o processo de correção

1. Erro de roteamento da janela de contexto

• Em 5 de agosto, algumas requisições do Sonnet 4 foram roteadas incorretamente para servidores destinados à janela de contexto de 1M tokens
• Após a mudança no balanceamento de carga, o problema passou a afetar até 16% das requisições do Sonnet 4, com impacto pequeno também no Amazon Bedrock e no Google Vertex AI
• Como o roteamento era "sticky", ao se conectar uma vez ao servidor errado, as conexões seguintes continuavam indo para o mesmo servidor
• Correção: melhoria na lógica de roteamento, patch aplicado na plataforma própria em 4 de setembro, implantação no Google Cloud até 16 de setembro, e aplicação gradual em andamento no Bedrock

2. Corrupção de saída (bug)

• Em 25 de agosto, uma configuração incorreta foi aplicada aos servidores TPU da API do Claude, causando erros durante a geração de tokens
• Houve casos de mistura de caracteres sem sentido como tailandês ou chinês em respostas a perguntas em inglês, além de inserção de erros gramaticais evidentes em código
• Afetou apenas Opus 4.1, Opus 4 e Sonnet 4; plataformas de terceiros não foram impactadas
• Correção: rollback da mudança em 2 de setembro e adição de testes de detecção de saída com caracteres anômalos ao processo de implantação

3. Erro de miscompilation do approximate top-k no XLA:TPU

• Em 25 de agosto, durante o aprimoramento do método de seleção de tokens, veio à tona um bug latente no compilador XLA:TPU
• Afetou Claude Haiku 3.5, parte do Sonnet 4 e Opus 3
• Plataformas de terceiros não foram impactadas
• Correção: rollback do Haiku 3.5 em 4 de setembro e do Opus 3 em 12 de setembro; no Sonnet 4, embora o problema não tenha sido reproduzido diretamente, foi feito rollback como medida preventiva
• Em paralelo, a Anthropic está trabalhando com a equipe do XLA:TPU para corrigir o bug do compilador e migrar para o uso de exact top-k

Análise detalhada do bug no compilador XLA

• O Claude realiza cálculo de probabilidades e amostragem para cada candidato durante o processo de geração de tokens
• As TPUs operam em ambiente distribuído, exigindo sincronização dos cálculos de probabilidade dos tokens, o que traz complexidade adicional
• Em dezembro de 2024, foi identificado um problema em que o token de maior probabilidade podia ser omitido devido a erro causado pelo uso de precisão mista bf16-32 bits, e foi implantada uma correção temporária
• Em 26 de agosto, durante uma reformulação do código de amostragem para resolver a causa raiz, surgiu um bug mais profundo no approximate top-k que, em certos casos, produzia resultados completamente incorretos
• Esse bug estava sendo mascarado pela correção temporária anterior
• Além disso, o bug na operação approximate top-k apresentava sintomas irregulares conforme o ambiente de produção e o tamanho do batch
• Mais recentemente, em vez de approximate top-k, foi adotado o exact top-k, cujo custo de desempenho caiu bastante, e operações principais foram aprimoradas com padronização em fp32

Motivos para o atraso na detecção

• Estavam em uso procedimentos como avaliações automatizadas periódicas e implantação prévia em grupos selecionados
• Esses incidentes expuseram lacunas no processo de avaliação. Por exemplo, havia métricas que não detectavam bem as situações problemáticas, e a política interna de privacidade (engenheiros sem acesso a requisições específicas de usuários) dificultava a análise rápida
• Como os sintomas variavam conforme plataforma e versão, foi difícil identificar uma única causa
• Mesmo com o aumento repentino de relatos online, a relação com uma mudança padrão de balanceamento de carga não foi percebida de imediato

Melhorias futuras e medidas de resposta

• Desenvolvimento de métricas mais sensíveis, com reforço das avaliações automatizadas para distinguir com mais clareza implementações normais e estados corrompidos
• Expansão dos sistemas de avaliação e monitoramento para todo o ambiente real de produção, incluindo avaliações centradas em operação, como no caso de erros de roteamento da janela de contexto
• Criação de ferramentas de depuração mais rápidas e sofisticadas, além de infraestrutura e ferramentas customizadas para analisar rapidamente o feedback da comunidade preservando a privacidade
• Ênfase não apenas na avaliação interna, mas também na confiabilidade da coleta contínua de feedback dos usuários: para erros ou bugs difíceis de prever, os relatos reais dos usuários funcionam como um sinal importante
• Incentivo ativo ao uso do comando "/bug" ou da função de 'thumbs down', além do envio por e-mail de métodos de avaliação da qualidade do modelo

Observações de referência

• XLA:TPU é um compilador que converte código de linguagem de otimização de alto nível XLA em instruções para TPU
• Como o tamanho do modelo é grande, ele é distribuído por vários chips em vez de um único chip, e operações como sorting precisam ser implementadas em formato vetorizado
• A operação approximate top-k é usada para melhorar o desempenho, mas pode trazer problemas graves, como deixar de fora o token com maior probabilidade
• Atualmente, foi adotado o método exact top-k, e pode haver pequenas mudanças no padrão de inclusão de tokens próximos ao limite de top-p. Em alguns casos, o usuário pode precisar ajustar o valor de top-p

[GN⁺]

Comentários no Hacker News

• Algo que me chamou atenção recentemente foi perceber a ausência de testes unitários. Até os testes para o bug do compilador XLA pareciam só imprimir a saída, bem longe de testes unitários de verdade executados por um harness real com acompanhamento de cobertura. A resposta parece ser algo na linha de depender mais de Eval. Hoje, fazer testes unitários do LLM inteiro é irrealista, mas a maior parte dos bugs revelados até agora estava em pequenas partes determinísticas do sistema. Por exemplo, balanceamento de carga, cálculo de probabilidade top-k etc. são todos componentes projetados como qualquer outro software, então em princípio podem ser testados com testes unitários. Se necessário, um PRNG injetável já bastaria. Bugs de otimização não determinísticos são claramente complicados, mas até suítes de teste de apps tradicionais já encontraram bugs de compilador e de banco de dados no passado. Se você repetir muitos testes no CI, até eventos raros podem aparecer. Em um projeto pessoal meu, executo todos os testes unitários em paralelo no mesmo processo, e com isso consegui encontrar com eficácia problemas raros de thread safety e deadlocks de banco de dados. Há alguns dias, numa thread sobre o lançamento do Java, eu comentei que uma razão de Java ser visto como mais “enterprise” que Python é que o código costuma ser escrito com forte foco em testes unitários. Há muita abstração por causa de desejos como injeção de dependência. Já na cultura de linguagens de script, muitas vezes não há testes, ou eles são só superficiais por aparência (por exemplo, apenas assertions de tipo). Tive impressão parecida ao aprender PyTorch: os tutoriais vão cobrindo coisas cada vez mais complexas, mas quase não falam de testes nem de estrutura de código. Isso pode servir para pesquisa em ML, em que o objetivo é subir métricas de avaliação, mas não combina com deploy em produção em larga escala. Fico pensando se não faltam mais pessoas de SRE ou de engenharia de software HA nos laboratórios de IA. Pessoalmente, sou cético de que rodar apenas Eval agressivamente em produção seja a melhor forma de evitar bugs
  • Já tive de fornecer prompts detalhados e exemplos para a IA escrever em Python o tipo de teste unitário que eu queria. Também vi com frequência casos em que ela usava só assertions sobre tipos. O que eu quero são assertions sobre os próprios valores. A IA tende a fazer mocking de tudo; mocking é útil, mas quanto mais o teste unitário chama o código real, mais ele cobre riscos de interação entre partes do código e da interface. Só que os testes unitários em Python gerados por IA ficam obcecados por mocking e muitas vezes acabam só verificando código tautológico. Por isso, incluo ativamente no prompt avisos para tomar cuidado com mocking e exemplos de testes bem detalhados. Vale notar que Python também tem ótimas ferramentas para escrever código estruturado, inclusive com injeção de dependência
• Fiquei surpreso com a matéria dizer que a Anthropic poderia influenciar diretamente a infraestrutura do AWS Bedrock. Isso contraria a promessa original da AWS. Imagino que o mesmo valha para o Google Vertex AI, mas ainda não confirmei isso do ponto de vista de compliance.

Concordo com a parte que diz que, por políticas internas de privacidade e segurança, o acesso dos engenheiros às interações dos usuários do Claude é limitado. Também concordo que o mais útil continua sendo o usuário enviar feedback diretamente, e que no Claude Code existe o comando /bug. Se reportar com esse comando permite que os engenheiros vejam o contexto, eu gostaria que isso fosse comunicado de forma muito clara para o usuário (eu não sou usuário do Claude Code). A orientação para usar o botão de "thumbs down" no app do Claude me preocupa um pouco. A maioria dos usuários provavelmente não entende esse clique como algo com o mesmo peso de abrir mão da privacidade

• (Funcionário da Anthropic, falando em caráter pessoal)

Não é verdade que a Anthropic gerencia diretamente a infraestrutura do AWS Bedrock. Hoje quem opera isso é a própria AWS. Sobre o aviso de privacidade do botão de "thumbs down", o modal informa explicitamente: "Ao enviar este feedback, a conversa atual inteira será compartilhada com a Anthropic e usada para melhorar o modelo". Fico curioso se existe uma forma de deixar esse texto ainda mais fácil de entender

• Ao clicar em "thumbs down", aparece a mensagem "Ao enviar este feedback, a conversa inteira será compartilhada com a Anthropic", então eu diria que o aviso é bem claro
• Se um laboratório do porte da Anthropic está compartilhando detalhes tão profundos da infraestrutura, a situação deve estar bem difícil. O bug de precisão em FMA (multiplicação-acumulação) foi realmente lamentável, e problemas numéricos muitas vezes são extremamente confusos, ainda fora do alcance da IA. Num cenário de pressão extrema em que concorrentes tomam participação de mercado em tempo real, intervenção humana acaba sendo indispensável, e descobrir a causa pode levar semanas
• Há uma explicação dizendo que “uma mudança de balanceamento de carga em 29 de agosto acabou enviando mais requisições de contexto curto para servidores de contexto 1M, e por uma hora em 31 de agosto 16% das requisições do Sonnet 4 foram afetadas”. Isso dá a entender que os servidores de contexto 1M têm desempenho pior justamente com entradas de contexto curto. Talvez seja efeito de alguma solução separada nesses servidores, como compressão de cache KV, eviction, sparse attention etc.?
  • Isso acontece por causa do escalonamento de RoPE (rotary position embedding). A maioria dos frameworks open source famosos implementa YaRN estático, em que o fator de escala fica fixo independentemente do tamanho da entrada, o que pode prejudicar o desempenho em textos curtos. Só recomendo adicionar a configuração de rope_scaling quando realmente precisar de contexto longo, e é melhor ajustar o fator ao comprimento médio de entrada da aplicação. Por exemplo, se ficar em torno de 520 mil tokens, configurar factor como 2.0 tende a ser melhor Fonte (página de descrição do Qwen3-Next-80B)
  • O ponto central do post-mortem deles é que, em dois dos três problemas, a causa exata não foi encontrada. Pelo que entendo, minha requisição agora pode ir para qualquer um de três caminhos de código completamente diferentes, cada um com stack e tuning próprios. Essa otimização pode mudar de repente sem relação com upgrade de versão do modelo, então algo que funcionava ontem pode quebrar hoje. Isso me deixa ainda mais frustrado, a ponto de eu nem entender por que esse tipo de post-mortem recebe elogios
• Com todo respeito à equipe da Anthropic, a qualidade da página de status do Claude já deveria acionar um código vermelho internamente. Houve 50 incidentes em julho, 40 em agosto e 21 em setembro. Em experiências passadas, metade disso já bastava para mudar drasticamente o foco para uptime e qualidade. Ainda assim, o Claude continua sendo um produto excelente, então sigo pagando. Testei a API e assinei o Max na hora. Minha produtividade disparou por causa disso. Mas, com essa repetição de quedas de qualidade nas últimas semanas, comecei a me perguntar se devo continuar assinando. Agradeço a sinceridade em compartilhar a situação, mas, do ponto de vista do cliente, a insatisfação é grande. Na minha visão, problemas como o de balanceamento de carga ainda não foram totalmente detectados nem resolvidos. Especificamente, por volta de 12h no leste / 9h no oeste, a qualidade do Claude Code cai bastante na minha percepção. Espero que a equipe continue encontrando e corrigindo esses problemas. Também já bati muito a cabeça com bugs complexos rodando modelos locais em casa, então entendo que isso não é fácil. Link da página de status
  • Não dá para afirmar que o Claude seja melhor ou pior do que outras empresas nesse aspecto, mas uma coisa é certa: muitas páginas de status mentem. Na prática, falhas acontecem com frequência e muitas vezes não aparecem na página de status. Hoje em dia, o que me surpreende é quando uma empresa comunica os problemas com honestidade. Pessoalmente, não enfrentei problemas graves com o Claude, mas talvez eu tenha dado sorte. Da minha perspectiva, o Claude até parece reportar melhor as indisponibilidades. Claro, isso também pode ser só coincidência
  • O mais preocupante é que muitas pequenas falhas ficam de fora da página de status. Todos os provedores de IA fazem algo parecido. Se publicassem gráficos com estatísticas de latência de token em tempo real, requisições com falha e throughput em tokens por segundo, o choque seria grande. Pelos dados do OpenRouter, dá para ver que o uptime da API está longe de ser bom. O Claude Code também às vezes fica tão lento que eu preciso interromper manualmente e tentar de novo. Fica especialmente ruim entre 16h e 18h no horário do Reino Unido, quando Europa, costa leste e costa oeste dos EUA se sobrepõem. Hoje mesmo o Gemini AI Studio deu erro 503 por sobrecarga do modelo, mas a página de status não mostrou nada. Fico pensando se Claude e outros não poderiam introduzir planos mais baratos fora do horário de pico para distribuir melhor a demanda. Por outro lado, isso pode parecer ruim do ponto de vista de imagem. Além disso, a chegada das GPUs GB200 parece ter sido muito mais lenta do que o esperado, com vários problemas de hardware e software. Questões de refrigeração líquida também parecem ter sido complicadas (e, se falharem, o estrago é grande)
  • O ponto mais importante é justamente a frase “mesmo assim eu pago porque o Claude é bom demais”. Hoje, a qualidade da IA pesa mais para os clientes (inclusive eu) do que a confiabilidade do serviço. Claro que as empresas vão dar mais foco à confiabilidade no futuro, mas por que deveriam priorizá-la acima da qualidade neste momento?
  • Essa queda recente na qualidade me deixou bem inseguro. Felizmente ainda não uso IA em serviços de produção, mas durante o desenvolvimento é muito difícil contornar quando o modelo simplesmente “fica mais burro” de repente. Neste momento, fico até desconfiado se vários vendors no OpenRouter não estão quebrando a confiança ao cortar contexto em segredo, reduzir quantização, diminuir número de experts e fazer outros truques para economizar computação sem avisar
  • É por isso que existe a estratégia de minimizar o número de incidentes marcados na página de status. A avaliação dos clientes piora por um tempo, mas depois o impacto negativo some. Já manter a página de status atualizada deixa um “registro” claro dos problemas. No longo prazo, enganar acaba sendo mais vantajoso. O S3, por exemplo, teve várias falhas e erros que não foram divulgados, e ninguém ligou. As pessoas falam muito, mas na prática o sistema recompensa quem esconde. Todo growth hacker de startup já sabe disso
• A explicação diz que, em 25 de agosto, uma configuração incorreta foi implantada em servidores TPU da API do Claude, causando erros durante a geração de tokens. Estou acostumado com bugs de código, mas no caso de LLMs o modelo não é escrito manualmente por humanos, e sim produzido por treinamento automatizado em larga escala, então fico curioso sobre como um bug desses pode surgir. Por exemplo, quando um modelo responde a uma pergunta em inglês e de repente solta “สวัสดี” no meio, fico imaginando estruturalmente como um bug desses pode ser introduzido
  • No fim das contas, um LLM roda em cima de código escrito por humanos. Na etapa final, o modelo gera uma distribuição de probabilidade sobre todos os tokens (vocab de cerca de 200 mil itens). Depois disso, humanos decidem como escolher o próximo token real. Por exemplo, sempre escolher o token de maior probabilidade, ou sortear aleatoriamente entre os top-k para aumentar a criatividade. Para processar esse top-k sampling com eficiência, o kernel é compilado com XLA, e aparentemente houve um bug nesse kernel que às vezes permitia escolher tokens fora do top-k
  • Um LLM solta uma distribuição de probabilidade para o próximo token, e o resultado final muda de acordo com o método de sampling exemplo. Por exemplo, se a regra for “escolher aleatoriamente entre os 4 de maior probabilidade” e o operador (desigualdade) estiver errado, acontece exatamente esse tipo de coisa
  • Entre o usuário e os parâmetros do modelo existem várias camadas de código escritas por humanos
  • Resumindo, há duas etapas: treinamento e inferência. O treinamento é automatizado e longo, mas a inferência é uma stack de software separada, executada imediatamente quando chega o prompt do usuário. Essa stack recebe atualizações contínuas para melhorar desempenho, e é nesse processo que surgem esses problemas ligados à inferência
  • Kernels de IA trabalham com operações de ponto flutuante, então às vezes um valor que não deveria ser negativo acaba ficando negativo por algum caso estranho dentro da faixa normal dos números reais. Por desempenho, certos checks de overflow podem ser desativados, e quando aparece um valor negativo ele pode acabar sendo tratado como um número muito grande (como pedir o índice -1 de um array e receber o último elemento)
• Acho que pensar em tornar a inferência de LLM determinística ajudaria no rastreamento de problemas. Saiu recentemente até um artigo dizendo que a tese comum de que “é por causa da ordem de associação dos pontos flutuantes” na verdade não explica o essencial do problema Artigo relacionado
  • Tráfego de rede e carga das máquinas são inerentemente não determinísticos. No curto prazo, determinismo completo (por exemplo, para auditoria) só parece realista em jobs em batch onde custo não importa tanto. Na prática, nem a busca do Google nem o carregamento de contagens em redes sociais são determinísticos. Em sistemas distribuídos, o conselho central é graceful degradation, e num sistema totalmente determinístico esse tipo de resposta não seria possível
  • Um design determinístico prejudica o desempenho. No fim, sobra uma abordagem tipo “teste de QI”, em que você faz outro modelo só para monitorar e alertar sobre a qualidade do modelo principal
• Concordo com a parte que diz que “no Google Cloud Vertex AI, o roteamento incorreto entre 27 de agosto e 16 de setembro foi inferior a 0,0004%”. No trabalho, uso CC nessa conta e nunca senti queda de qualidade. No geral, apesar de esses bugs serem sérios, tive a impressão de que foram bem mais raros do que sugerem os relatos online. O período dos incidentes também ficou, na prática, concentrado em 1 ou 2 semanas. A parcela de requisições afetadas em relação ao total também foi relativamente pequena
  • Mas a própria matéria diz que “30% dos usuários do Claude Code foram roteados pelo menos uma vez para o servidor errado e sofreram degradação de qualidade”. Como o roteamento é sticky, depois de cair uma vez no servidor errado as requisições continuam indo para ele em sequência. Se 30% dos usuários do Claude Code sofreram degradação de qualidade, isso é um bug enorme
  • Hoje em dia eu confio pouco em empresas, porque mesmo em incidentes globais elas costumam usar eufemismos do tipo “alguns poucos usuários observaram aumento de erros”, e só atualizam a página de status depois que o CTO aprova. Se existir uma empresa que realmente se comunique com honestidade, isso seria uma vantagem competitiva no mercado
• Há quem ache que fazer serviços de LLM operarem de forma determinística ajudaria a rastrear problemas. Também foi citado um artigo recente mostrando que a causa atribuída apenas à ordem de associação em operações de floating point na verdade envolve vários outros fatores de quebra de determinismo. Link do artigo
• No design de webapps, recentemente tive casos graves de o Claude fazer aparecer texto aleatório no DOM. Parece acontecer especificamente ao usar junto com Svelte. Não tenho certeza se isso está relacionado aos fenômenos citados no texto, mas antes eu nunca tinha visto uma queda de qualidade tão séria
• Gostaria que a postagem tivesse incluído exemplos concretos de falhas reais. No Claude Code, tenho enfrentado com frequência casos em que ele simplesmente trava depois de uma chamada de ferramenta, e fiquei curioso se isso tem relação com algum dos bugs mencionados desta vez
  • Eu também venho passando exatamente por isso, e com frequência crescente nos últimos dias. Acho que talvez seja separado dos bugs do texto (embora continue sendo um bug), mas torço para que meu palpite esteja errado. A quantidade de vezes em que preciso mandar algo como “por que você parou? continue” aumentou de forma bem visível