세 가지 최근 Claude 품질 저하 이슈의 사후 분석

• 8월부터 9월 초까지 Claude 응답 품질 저하 현상이 세 가지 인프라 버그로 인해 발생함
• 문제의 주요 원인은 각각 컨텍스트 윈도우 라우팅 오류, 출력 손상, 그리고 XLA:TPU 근사 top-k 미컴파일 오류임
• 각 버그는 다양한 하드웨어 및 배포 경로에서 서로 겹쳐서 진단이 더욱 어려웠음
• 탐지 및 해결이 지연된 원인에는 검증 프로세스의 허점, 프라이버시 정책에 따른 접근 제약 등이 있었음
• Anthropic는 평가 및 모니터링 강화, 더 빠른 디버깅 도구 개발 등으로 유사 사고 예방에 나섬

개요 및 배경

• 8월부터 9월 초까지 Claude의 응답 품질이 간헐적으로 저하되는 현상이 보고되었음
• 초기에는 사용자 피드백 내에서 정상적 변동으로 여겨졌으나, 보고가 지속적으로 증가하면서 조사가 시작됨
• Anthropic는, 수요나 서버 부하 때문이 아니라 인프라 버그만이 문제 원인임을 명확히 밝힘
• Claude는 수백만 사용자에게 여러 플랫폼(APIs, Amazon Bedrock, Google Vertex AI 등)을 통해 서비스되고, AWS Trainium, NVIDIA GPU, Google TPU 등 다양한 하드웨어에서 동등한 결과를 보장하기 위해 엄격한 검증 기준을 가짐
• 이번 사후 분석에서는 버그 원인, 진단 및 해결 지연 이유, 그리고 재발 방지 대책을 설명함

Claude의 대규모 서비스 방안

• Claude 서비스는 여러 하드웨어(Trainium, GPU, TPU)를 통해 글로벌 배포를 유지함
• 각 플랫폼별 동일 품질 보장을 위한 구현 동등성 기준이 엄격함
• 인프라 변경 시, 모든 플랫폼 및 설정에서 정밀한 검증 과정 필요함

주요 이슈 발생 연표

• 8월 5일: 첫 번째 버그, Sonnet 4 요청의 약 0.8%에 영향
• 8월 25, 26일: 두 번째, 세 번째 버그 각각 배포됨
• 8월 29일: 로드 밸런싱 변경으로 인해 문제 트래픽이 급증, 더 많은 사용자가 영향을 받게 됨
• 각 버그는 증상이 중첩되어 진단 난이도가 매우 높았음

세 가지 중첩 버그 및 해결 과정

1. 컨텍스트 윈도우 라우팅 오류

• 8월 5일, 일부 Sonnet 4 요청이 1M 토큰 컨텍스트 윈도우를 위한 서버로 잘못 라우팅됨
• 로드 밸런싱 변경 이후 최대 16%의 Sonnet 4 요청에 영향, Amazon Bedrock과 Google Vertex AI에도 미미하게 영향 발생
• 라우팅 방식이 "sticky"이어서 잘못된 서버에 한 번 연결되면 이후에도 동일 서버에 계속 연결되는 문제가 있었음
• 해결: 라우팅 로직 개선, 9월 4일 자사 플랫폼에 패치 적용, Google Cloud에는 9월 16일까지 배포, Bedrock에는 순차 적용 진행 중임

2. 출력 손상(bug)

• 8월 25일, Claude API의 TPU 서버에 잘못된 설정 적용되어 토큰 생성 시 에러 발생
• 영어 질문에 태국어나 중국어 등 엉뚱한 문자가 섞여 나오는 등, 코드에 명백한 문법 오류가 삽입되는 현상 발생
• Opus 4.1 및 Opus 4, Sonnet 4에만 영향, 서드파티 플랫폼은 영향 없음
• 해결: 9월 2일에 변경분 롤백, 비정상 문자 출력 탐지 테스트를 배포 프로세스에 추가함

3. 근사 top-k XLA:TPU 미컴파일 오류

• 8월 25일, 토큰 선택 방식 고도화 중 XLA:TPU 컴파일러의 잠재적 버그가 드러남
• Claude Haiku 3.5, 일부 Sonnet 4, Opus 3에 영향
• 서드파티 플랫폼은 영향 없음
• 해결: Haiku 3.5는 9월 4일, Opus 3은 9월 12일 각각 롤백, Sonnet 4에는 직접 재현되진 않았으나 예방조치로 롤백함
• 병행하여 XLA:TPU 팀과 협력해 컴파일러 버그를 수정 중, 정확한 top-k 방식 사용으로 전환

XLA 컴파일러 버그 상세 분석

• Claude는 토큰 생성 과정에서 각 후보에 대한 확률 계산과 표본 추출 작업을 수행함
• TPUs는 분산 환경에서 동작, 토큰 확률 계산을 동기화해야 하며 복잡함 동반
• 2024년 12월, bf16-32비트 혼합 정밀도 사용에 따른 오차로 최상위 확률 토큰이 누락되는 문제 발견, 이에 대한 임시 수정 배포
• 8월 26일, 근본 원인을 해결하기 위한 샘플링 코드 개편 중, 근사 top-k 연산에서 특정 경우에 완전히 잘못된 결과가 출력되는 더 심층적인 버그가 노출됨
• 이 버그는 이전 임시 수정이 문제를 가렸음
• 또한, 근사 top-k 연산의 버그는 운영 환경 및 배치 크기에 따라 증상이 불규칙하게 달라졌음
• 근사 top-k 대신, 최근에는 성능 부담이 크게 줄어든 exact top-k로 전환했으며 주요 연산들을 fp32 표준화로 개선함

탐지 지연 원인

• 주기적인 자동화 평가와 사전 그룹 배포 등의 절차 사용 중
• 이번 사건들은 평가 프로세스의 허점이 드러났음. 예를 들어, 문제 상황을 잘 탐지하지 못하는 평가 항목, 내부 개인정보보호 정책(엔지니어가 구체적인 사용자 요청 접근 불가) 때문에 신속한 분석이 어려움
• 증상이 플랫폼 및 버전에 따라 다양하게 나타나 단일한 원인 규명이 힘들었음
• 온라인 보고 급증 시에도, 표준적 로드밸런싱 변경과 연관성을 즉시 인지하지 못함

향후 개선 및 대응책

• 민감도 높은 평가 항목 개발, 손상 상태와 정상 구현을 더 명확히 판별할 수 있는 자동화 평가 강화
• 실제 운영 환경 전체에 평가 및 모니터링 시스템 확대, 예를 들어 컨텍스트 윈도우 라우팅 에러와 같은 운영 환경 중심 평가 수행
• 더 빠르고 정교한 디버깅 도구 신설, 커뮤니티 피드백을 프라이버시 유지 하에 신속히 분석할 수 있도록 인프라와 커스텀 도구 개발
• 내부 평가뿐 아니라, 사용자 피드백의 지속적 수집 신뢰 강조: 예측하기 어려운 에러나 버그는 실제 사용자 신고가 중요 신호 역할을 함
• "/bug" 명령어 혹은 'thumbs down' 기능 활용, 이메일 통한 모델 품질 평가 방법 제보를 적극 장려함

참고 설명

• XLA:TPU는 XLA 고수준 최적화 언어 코드를 TPU 명령어로 변환하는 컴파일러임
• 모델 사이즈가 크기 때문에 하나의 칩이 아닌 여러 칩에 분할 배치, sorting 오퍼레이션 등은 벡터화 형태로 구현 필요
• 근사 top-k 연산은 성능 향상을 위해 사용되지만, 확률이 가장 높은 토큰을 누락하는 등의 심각한 문제를 내포할 수 있음
• 현재 정확한 top-k 방식을 도입하였으며, top-p 임계값에 근접하는 토큰 포함 양상에 미세한 변화가 있을 수 있음. 경우에 따라 사용자는 top-p 값을 조정해야 할 수도 있음