요약: 8월에서 9월 초 사이에 세 가지 인프라 버그로 인해 Claude의 응답 품질이 주기적으로 저하되었습니다. Anthropic은 이러한 문제를 모두 해결했으며, 어떤 경우에도 수요, 시간대, 서버 부하에 따라 모델 품질을 의도적으로 낮추지 않는다는 점을 명확히 했습니다. 이번 포스트모템에서는 문제가 발생한 원인, 탐지 및 해결이 예상보다 오래 걸린 이유, 그리고 재발 방지를 위한 개선 사항을 상세히 설명합니다.
8월에서 9월 초 사이에 세 가지 인프라 버그로 인해 Claude의 응답 품질이 주기적으로 저하되었습니다. 우리는 이제 이러한 문제를 해결했으며, 무슨 일이 있었는지 설명하고자 합니다.
8월 초, 일부 사용자들이 Claude의 저하된 응답을 보고하기 시작했습니다. 이 초기 보고들은 사용자 피드백의 일반적인 변동성과 구별하기 어려웠습니다. 8월 말, 이러한 보고의 빈도와 지속성이 증가하자 우리는 조사를 시작했고, 이를 통해 세 가지 별도의 인프라 버그를 발견했습니다.
명확히 말씀드리자면: 우리는 수요, 시간대, 또는 서버 부하로 인해 모델 품질을 낮추지 않습니다. 사용자들이 보고한 문제는 인프라 버그로만 인한 것이었습니다. 우리는 사용자들이 Claude에게 일관된 품질을 기대한다는 점을 인지하며, 인프라 변경이 모델 출력에 영향을 미치지 않도록 하는 데 있어 매우 높은 기준을 유지합니다. 이번 사건에서 우리는 그 기준에 미치지 못했습니다.
다음 포스트모템은 무엇이 잘못되었는지, 탐지와 해결이 우리가 원했던 것보다 왜 오래 걸렸는지, 그리고 유사한 향후 사건을 예방하기 위해 무엇을 변경하고 있는지 설명합니다. 우리는 일반적으로 인프라에 대한 이 정도의 기술적 세부 사항을 공유하지 않지만, 이번 문제의 규모와 복잡성으로 인해 더 포괄적인 설명이 필요하다고 판단했습니다.
대규모로 Claude를 제공하는 방법
우리는 자사 API, Amazon Bedrock, Google Cloud의 Vertex AI를 통해 수백만 명의 사용자에게 Claude를 제공합니다. 우리는 AWS Trainium, NVIDIA GPU, Google TPU를 포함한 여러 하드웨어 플랫폼에 Claude를 배포합니다. 이 접근 방식은 전 세계 사용자에게 서비스를 제공하는 데 필요한 용량과 지리적 분포를 제공합니다.
각 하드웨어 플랫폼은 서로 다른 특성을 가지며 특정 최적화가 필요합니다. 이러한 변형에도 불구하고, 우리는 모델 구현에 대해 엄격한 등가성 기준을 가지고 있습니다. 우리의 목표는 어떤 플랫폼이 요청을 처리하든 사용자가 동일한 품질의 응답을 받는 것입니다. 이러한 복잡성은 모든 플랫폼과 구성에서 인프라 변경에 주의 깊은 검증이 필요함을 의미합니다.
사건 타임라인
Claude API에서의 사건을 보여주는 예시 타임라인. 노란색: 문제 감지됨, 빨간색: 저하 악화됨, 녹색: 수정 사항 배포됨.
이러한 버그의 겹치는 특성으로 인해 진단이 특히 어려웠습니다. 첫 번째 버그는 8월 5일에 도입되어 Sonnet 4에 대한 약 0.8%의 요청에 영향을 미쳤습니다. 8월 25일과 26일의 배포에서 두 개의 추가 버그가 발생했습니다. 초기 영향은 제한적이었지만, 8월 29일의 로드 밸런싱 변경이 영향을 받는 트래픽을 증가시키기 시작했습니다. 이로 인해 더 많은 사용자가 문제를 경험했고 다른 사용자들은 정상적인 성능을 계속 경험하여 혼란스럽고 모순적인 보고가 생성되었습니다.
세 가지 겹치는 문제
아래에서 저하를 일으킨 세 가지 버그, 발생 시점, 해결 방법을 설명합니다:
1. 컨텍스트 윈도우 라우팅 오류
8월 5일, 일부 Sonnet 4 요청이 1M 토큰 컨텍스트 윈도우를 위해 구성된 서버에 잘못 라우팅되었습니다. 이 버그는 처음에 0.8%의 요청에 영향을 미쳤습니다. 8월 29일, 정기적인 로드 밸런싱 변경이 의도치 않게 1M 컨텍스트 서버로 라우팅된 짧은 컨텍스트 요청의 수를 증가시켰습니다. 8월 31일 가장 심각하게 영향을 받은 시간에 Sonnet 4 요청의 16%가 영향을 받았습니다. 이 기간 동안 요청을 한 Claude Code 사용자의 약 30%가 적어도 하나의 메시지가 잘못된 서버 유형으로 라우팅되어 저하된 응답을 받았습니다.
Amazon Bedrock에서는 8월 12일부터 Sonnet 4 요청의 최대 0.18%가 잘못 라우팅되었습니다. Google Cloud의 Vertex AI에서는 8월 27일부터 9월 16일 사이에 0.0004% 미만의 요청이 잘못된 라우팅의 영향을 받았습니다. 그러나 일부 사용자는 더 심각하게 영향을 받았는데, 이는 우리의 라우팅이 “스티키(sticky)”하기 때문입니다. 이는 잘못된 서버에서 요청이 처리되면 후속 후속 요청도 동일한 잘못된 서버에서 처리될 가능성이 높음을 의미합니다.
해결 방법: 우리는 짧은 컨텍스트와 긴 컨텍스트 요청이 올바른 서버 풀로 향하도록 라우팅 로직을 수정했습니다. 9월 4일에 수정 사항을 배포했습니다. 자사 플랫폼과 Google Cloud의 Vertex AI로의 롤아웃은 9월 16일에 완료되었으며, AWS Bedrock으로는 9월 18일에 완료되었습니다.
2. 출력 손상
8월 25일, 우리는 Claude API TPU 서버에 잘못된 구성을 배포하여 토큰 생성 중 오류가 발생했습니다. 런타임 성능 최적화로 인한 문제가 가끔씩 컨텍스트상 거의 생성되지 않아야 할 토큰에 높은 확률을 할당했습니다. 예를 들어, 영어 프롬프트에 대한 응답으로 태국어 또는 중국어 문자를 생성하거나, 코드에서 명백한 구문 오류를 생성하는 경우가 있었습니다. 예를 들어, 영어로 질문한 소수의 사용자가 응답 중간에 “สวัสดี”를 볼 수 있었습니다. 이러한 손상은 8월 25-28일에 Opus 4.1 및 Opus 4에 대한 요청, 그리고 8월 25일-9월 2일에 Sonnet 4에 대한 요청에 영향을 미쳤습니다. 제3자 플랫폼은 이 문제의 영향을 받지 않았습니다.
해결 방법: 우리는 문제를 식별하고 9월 2일에 변경 사항을 롤백했습니다. 우리는 배포 프로세스에 예기치 않은 문자 출력에 대한 탐지 테스트를 추가했습니다.
3. 근사적 top-k XLA:TPU 잘못된 컴파일
8월 25일, 우리는 Claude가 텍스트 생성 중 토큰을 선택하는 방법을 개선하는 코드를 배포했습니다. 이 변경은 의도치 않게 XLA:TPU [1] 컴파일러의 잠재적인 버그를 트리거했으며, 이는 Claude Haiku 3.5에 대한 요청에 영향을 미치는 것으로 확인되었습니다. 우리는 또한 이것이 Claude API의 Sonnet 4 및 Opus 3의 하위 집합에 영향을 미쳤을 수 있다고 생각합니다. 제3자 플랫폼은 이 문제의 영향을 받지 않았습니다.
해결 방법: 우리는 먼저 Haiku 3.5에 영향을 미치는 버그를 관찰하고 9월 4일에 롤백했습니다. 나중에 우리는 이 버그와 호환되는 Opus 3 문제에 대한 사용자 보고를 발견하고 9월 12일에 롤백했습니다. 광범위한 조사 끝에 Sonnet 4에서 이 버그를 재현할 수 없었지만, 추가적인 주의를 위해 롤백하기로 결정했습니다. 동시에 우리는 (a) 컴파일러 버그 수정을 위해 XLA:TPU 팀과 협력하고 (b) 향상된 정밀도로 정확한 top-k를 사용하는 수정 사항을 배포했습니다. 자세한 내용은 아래 심층 분석을 참조하십시오.
XLA 컴파일러 버그에 대한 자세한 분석
이러한 문제의 복잡성을 설명하기 위해, XLA 컴파일러 버그가 어떻게 나타났는지와 진단이 왜 특히 어려웠는지를 보여드리겠습니다.
Claude가 텍스트를 생성할 때, 각 가능한 다음 단어에 대한 확률을 계산한 다음 이 확률 분포에서 무작위로 샘플을 선택합니다. 우리는 무의미한 출력을 피하기 위해 “top-p 샘플링”을 사용합니다. 누적 확률이 임계값(일반적으로 0.99 또는 0.999)에 도달하는 단어만 고려합니다.
TPU에서 우리의 모델은 여러 칩에 걸쳐 실행되며, 확률 계산이 다른 위치에서 발생합니다. 이러한 확률을 정렬하기 위해 칩 간에 데이터를 조정해야 하며, 이는 복잡합니다.
2024년 12월, 우리는 온도가 0일 때 우리의 TPU 구현이 가끔 가장 확률이 높은 토큰을 삭제한다는 것을 발견했습니다. 우리는 이 경우를 수정하기 위한 해결 방법을 배포했습니다.
근본 원인은 혼합 정밀도 산술에 관련되었습니다. 우리의 모델은 bf16(16비트 부동 소수점)으로 다음 토큰 확률을 계산합니다. 그러나 벡터 프로세서는 fp32 기본이므로, TPU 컴파일러(XLA)는 일부 작업을 fp32(32비트)로 변환하여 런타임을 최적화할 수 있습니다. 이 최적화 패스는 기본적으로 true인 xla_allow_excess_precision 플래그로 보호됩니다. 이로 인해 불일치가 발생했습니다. 가장 높은 확률 토큰에 동의해야 하는 작업이 서로 다른 정밀도 수준에서 실행되고 있었습니다.
정밀도 불일치는 가장 높은 확률 토큰이 어떤 토큰인지에 동의하지 못하게 했습니다. 이로 인해 가장 높은 확률 토큰이 때때로 고려 대상에서 완전히 사라졌습니다.
8월 26일, 우리는 정밀도 문제를 수정하고 top-p 임계값에 도달하는 확률 처리 방법을 개선하기 위해 샘플링 코드를 재작성하여 배포했습니다. 하지만 이러한 문제를 수정하는 과정에서 더 까다로운 문제를 노출했습니다.
우리의 수정 사항은 근본 원인을 해결했다고 믿었기 때문에 12월의 해결 방법을 제거했습니다. 이로 인해 근사적 top-k 연산(가장 높은 확률 토큰을 빠르게 찾는 성능 최적화)에서 더 깊은 버그가 발생했습니다. 이 근사치는 때때로 완전히 잘못된 결과를 반환했지만, 특정 배치 크기와 모델 구성에서만 그렇습니다. 12월의 해결 방법이 의도치 않게 이 문제를 마스크하고 있었습니다.
버그의 동작은 좌절스럽게 일관성이 없었습니다. 그것은 이전 또는 이후에 실행된 작업과 같은 무관한 요인과 디버깅 도구가 활성화되어 있는지 여부에 따라 달라졌습니다. 동일한 프롬프트가 한 요청에서는 완벽하게 작동하고 다음 요청에서는 실패할 수 있습니다.
조사하는 동안 우리는 또한 정확한 top-k 연산이 더 이상 과거처럼 prohibitive한 성능 저하를 일으키지 않는다는 것을 발견했습니다. 우리는 근사적에서 정확한 top-k로 전환하고 일부 추가 작업을 fp32 정밀도로 표준화했습니다. 모델 품질은 양보할 수 없으므로 우리는 사소한 효율성 영향을 수용했습니다.
탐지가 어려웠던 이유
우리의 검증 프로세스는 일반적으로 벤치마크와 함께 안전성 평가 및 성능 메트릭에 의존합니다. 엔지니어링 팀들은 스팟 체크를 수행하고 먼저 작은 “카나리” 그룹에 배포합니다. 이러한 문제는 우리가 더 일찍 식별했어야 할 중요한 격차를 드러냈습니다.
우리가 실행한 평가는 단순히 사용자들이 보고한 저하를 포착하지 못했는데, 이는 부분적으로 Claude가 격리된 실수에서 종종 잘 회복하기 때문입니다. 우리 자체의 개인정보 보호 관행도 보고를 조사하는 데 어려움을 만들었습니다. 우리의 내부 개인정보 보호 및 보안 제어는 엔지니어가 Claude와의 사용자 상호작용에 언제 어떻게 액세스할 수 있는지를 제한합니다. 특히 피드백으로 보고되지 않은 상호작용의 경우 그렇습니다. 이는 사용자 개인정보를 보호하지만 엔지니어가 버그를 식별하거나 재현하는 데 필요한 문제가 있는 상호작용을 검사하는 것을 방지합니다.
각 버그는 서로 다른 플랫폼에서 서로 다른 속도로 서로 다른 증상을 생성했습니다. 이는 단일 원인을 가리키지 않는 혼란스러운 보고의 혼합을 만들었습니다. 무작위이고 일관성 없는 저하처럼 보였습니다. 더 근본적으로, 우리는 노이즈가 많은 평가에 너무 많이 의존했습니다. 우리가 온라인 보고의 증가를 인지하고 있었지만, 우리의 최근 변경 각각에 연결하는 명확한 방법이 부족했습니다. 8월 29일 부정적인 보고가 급증했을 때, 우리는 그것을 그렇지 않으면 표준적인 로드 밸런싱 변경에 즉시 연결하지 않았습니다.
우리가 변경하는 것
우리는 인프라를 계속 개선하면서, Claude를 제공하는 모든 플랫폼에서 위에서 논의한 것과 같은 버그를 평가하고 예방하는 방법도 개선하고 있습니다. 우리가 변경하는 것은 다음과 같습니다:
더 민감한 평가: 주어진 문제의 근본 원인을 발견하는 데 도움을 위해, 작동하는 구현과 손상된 구현을 더 신뢰할 수 있게 구별할 수 있는 평가를 개발했습니다. 모델 품질을 더 면밀히 모니터링하기 위해 이러한 평가를 계속 개선할 것입니다.
더 많은 곳에서의 품질 평가: 우리는 시스템에서 정기적인 평가를 실행하지만, 컨텍스트 윈도우 로드 밸런싱 오류와 같은 문제를 포착하기 위해 실제 프로덕션 시스템에서 연속적으로 실행할 것입니다.
더 빠른 디버깅 도구: 우리는 사용자 개인정보를 희생하지 않고 커뮤니티 기반 피드백을 더 잘 디버깅할 수 있는 인프라와 도구를 개발할 것입니다. 또한, 여기서 개발된 일부 사용자 정의 도구는 그러한 사건이 발생할 경우 향후 유사한 사건에서 치료 시간을 줄이는 데 사용될 것입니다.
평가 및 모니터링은 중요합니다. 하지만 이러한 사건은 Claude의 응답이 통상적인 표준에 미치지 않을 때 사용자로부터의 지속적인 신호도 필요하다는 것을 보여주었습니다. 관찰된 특정 변경 사항, 경험한 예기치 않은 동작의 예, 그리고 다양한 사용 사례에서의 패턴에 대한 보고는 모두 우리가 문제를 격리하는 데 도움이 되었습니다. 사용자들이 계속해서 우리에게 직접 피드백을 보내주시는 것이 특히 도움이 됩니다. Claude Code에서 /bug 명령을 사용하거나 Claude 앱에서 “엄지 아래” 버튼을 사용하여 그렇게 할 수 있습니다.
개발자와 연구자들은 종종 우리의 내부 테스트를 보완하는 모델 품질을 평가하는 새롭고 흥미로운 방법을 만듭니다. 공유하고 싶으시다면 feedback@anthropic.com으로 문의하십시오. 우리는 이러한 기여에 대해 커뮤니티에 계속 감사하고 있습니다.
감사의 글
Sam McAllister가 작성했으며, Stuart Ritchie, Jonathan Gray, Kashyap Murali, Brennan Saeta, Oliver Rausch, Alex Palcuie 및 기타 많은 분들에게 감사드립니다.
[1] XLA:TPU는 XLA High Level Optimizing language(종종 JAX를 사용하여 작성됨)를 TPU 머신 명령어로 변환하는 최적화 컴파일러입니다.
[2] 우리의 모델은 단일 칩에 너무 크며 수십 개 이상의 칩에 분할되어 있어, 우리의 정렬 연산이 분산 정렬입니다. TPU(GPU 및 Trainium과 마찬가지로)도 CPU와 다른 성능 특성을 가지고 있어 직렬 알고리즘 대신 벡터화된 연산을 사용하는 다른 구현 기술이 필요합니다.
[3] 우리는 상당한 성능 향상을 제공했기 때문에 이 근사 연산을 사용하고 있었습니다. 근사치는 가장 낮은 확률 토큰의 잠재적 부정확성을 수락하여 작동하며, 이는 품질에 영향을 미치지 않아야 합니다. 단, 버그로 인해 가장 높은 확률 토큰을 삭제하는 경우는 제외합니다.
[4] 이제 올바른 top-k 구현은 top-p 임계값 근처에 있는 토큰의 포함에 약간의 차이를 만들 수 있으며, 드물게 사용자가 top-p 선택을 재조정하여 이점을 얻을 수 있습니다.
핵심 포인트
- Anthropic은 8월에서 9월 초 사이에 세 가지 인프라 버그로 인해 Claude의 응답 품질이 저하되었음을 인정하고 모두 해결했다고 발표했습니다.
- 세 가지 버그는 (1) 컨텍스트 윈도우 라우팅 오류, (2) 출력 손상, (3) XLA:TPU 근사적 top-k 잘못된 컴파일로, 각각 다른 시기에 다른 플랫폼에 영향을 미쳤습니다.
- 회사는 수요, 시간대, 서버 부하로 인해 모델 품질을 의도적으로 낮추지 않는다는 점을 명확히 하며, 인프라 변경이 모델 출력에 영향을 미치지 않도록 하는 데 있어 기준에 미치지 못했음을 시인했습니다.
- 재발 방지를 위해 더 민감한 평가 시스템, 프로덕션 시스템에서의 연속적 품질 평가, 그리고 커뮤니티 피드백 디버깅 도구 개발을 계획하고 있습니다.
