클라우드가 실제로 고장 났을 뿐, 사용량 제한이 아니었다 – 그것은 실제로 더 나빴다

클라우드클라우드에 대해 이야기해 보자. 지난 한 달 동안 클라우드를 사용했다면 뭔가가 잘못된 것을 눈치채지 않았겠는가.

6주 동안 클라우드 사용자들은 미치고 있었다. 8월 초부터클라우드에 대한 불만이 레딧, X, 개발자 포럼에 홍수처럼 쏟아져 나왔다.문제는 모두 곳곳에 산재해 있었다:

• 완벽하게 작동하던 코드가突然 고장 났다
• 클라우드가 파일에 변경을 가했다고 주장했지만 실제로는 변경이 없다
• 영어 응답에突然 태국어 또는 중국어 문자가 나타난다
• 지시가 완전히 무시된다
• 같은 프롬프트에 대해 매우 다른 품질의 응답이 나타난다
• 클라우드 코드 사용자들은 그것이 이전보다 “로보토마이즈드” 되어 있다고 느꼈다

불만이 너무 심해져서 8월 말에는 사람들이 앤트로픽이 클라우드를 비밀리에 사용량 제한하고 있다고 확신했다. 음모론이 모든 곳에 퍼져 있었다 – 아마도 피크 시간 동안 품질을 낮추거나, 비용을 절약하기 위해 더 저렴한 모델을 교체했거나, 서버 비용을 관리하기 위해 의도적으로 品質을 낮춘 것일 수 있다.

사용자들은클라우드 프로를 구매하고 있었지만 클라우드 라이트와 같은 것을 받았다. 클라우드를 중심으로 워크플로우를 구축한 개발자들은突然 생산성이 떨어지는 것을 보게 되었다. 하지만 일부 사용자는 아무런 문제도 경험하지 못했다. 이것은 모든 것을 더 혼란스럽게 만들었다.

앤트로픽이 마침내 인정했다: 예, 우리는 문제가 있었다

사용자들의 불만과 증가하는 불만에도 불구하고, 앤트로픽은 방대한 기술적인 사고 분석 보고서를 발표했다. 그것은 기본적으로 다음과 같이 말한다: “당신이 옳았다. 클라우드는 고장 났다. 여기서 무슨 일이 있었는지를 설명하겠다.”

그리고答案은 흥미롭다.

그것은 하나의 문제가 아니었다. 세 가지 완전히 별개의 인프라 버그가同時에 발생하여完璧한 AI 열화를 일으켰다. 사용량 제한을 하지 않았다. 구석을 자르지 않았다. 단지 세 가지 다른 것들이同時에 고장 났을 뿐이다. 그것을 완전히 이해하고 고치기까지 6주가 걸렸다.

클라우드가 어떻게 고장 났는지 정확히 설명해 보겠다. 이것은 실제로 예상치 못한 방식으로 고장 날 수 있는 이러한 AI 시스템의 유용한 시각을 제공한다.

트리플 버그 멜트다운: 혼돈의 타임라인

출처: 앤트로픽

버그 #1: 잘못된 서버 문제

클라우드 소네트 4는 200,000 토큰 컨텍스트를 처리하도록 설계되었다. 하지만 8월 5일부터 일부 요청이 1백만 토큰 컨텍스트에 구성된 서버로 라우팅되었다.

초기에는 0.8%의 요청만 영향을 받았다. 별 문제가 없다고 생각했다. 하지만 8월 29일, 로드 밸런서 업데이트가 이 작은 문제를 큰 문제로 바꾸었다.突然, 피크 시간에 16%의 소네트 4 요청이 잘못된 서버로 라우팅되었다. 그리고 라우팅은 “sticky”했다. 한번 잘못 라우팅되면 계속해서 잘못 라우팅되었다.

8월 29일, 로드 밸런서 업데이트가 이 작은 문제를 큰 문제로 바꾸었다.突然, 피크 시간에 16%의 소네트 4 요청이 잘못된 서버로 라우팅되었다. 그리고 라우팅은 “sticky”했다. 한번 잘못 라우팅되면 계속해서 잘못 라우팅되었다.

영향:

• 클라우드 코드 사용자 중 약 30%가 해당 기간 동안 적어도 하나의 요청이 잘못 라우팅되었다
• 영향을 받은 사용자들의 응답 시간이 급격히 떨어졌다
• 같은 사용자가 반복적으로 문제를 경험했다. 반면에 다른 사용자들은 아무런 문제도 경험하지 못했다

버그 #2: 무작위 문자 생성기

8월 25일, 앤트로픽은 TPU 서버에 잘못된 구성으로 인해 클라우드가 무작위로 태국어 또는 중국어 문자를 영어 응답에 삽입하기 시작했다.

클라우드에게 파이썬 코드를 디버깅하라고 요청했을 때 다음과 같은 응답을 받는다는 것을 상상해 보라:

defcalculate_total(items):

total = 0

for item in items:

총계 += item.price # <- 무엇?

return 결과

영향을 받은 범위:

• 오푸스 4.1 및 오푸스 4: 8월 25-28일
• 소네트 4: 8월 25일 – 9월 2일

기술적인 원인은 토큰 생성 오류로 인해 존재하지 않아야 할 문자에 높은 확률을 할당하여 클라우드가 다음 단어를 선택하는 기본 메커니즘을 실제로 고장させ었다.

버그 #3: 보이지 않는 컴파일러 버그

이것은 공포스러운 버그이다. 구글의 XLA 컴파일러에 잠재된 버그가 있었다. 앤트로픽이 8월 25일에 토큰 선택을 개선하기 위해 코드를 배포했을 때 그것을 실수로 트리거했다.

이 버그가 실제로 무엇을 했는지 상상해 보라 – 클라우드가 의도치 않게 가장 가능성이 높은 토큰을 생성할 때 제외했다. 클라우드는 올바른答案을 알고 있었지만 그것을 말할 수 없었다.

真正으로 혼란스러운 부분은 – 그들은 이미 2024년 12월에 이 버그를 해결한 것으로 생각했지만, 실제로는 해결하지 못했다. 8월에 그들이 생각했던 근본 원인을 “수정”했을 때, 해결책을 제거하고 실제 문제를 발생시켰다.

6주 동안 고칠 수 없었던 이유

당신은 어떻게 세계 최고의 엔지니어를 가진 앤트로픽이 6주 동안 이것을 해결하지 못했는지 궁금할 것이다.

答案은 이러한 시스템이 실제로 얼마나 복잡한지 보여준다:

1. 개인 정보 보호 제어로 인한 디버깅 차단

“클라우드와의 상호 작용에 대한 내부 개인 정보 보호 및 보안 제어로 인해 엔지니어가 사용자와의 상호 작용에 접근할 수 없게 된다. 특히 사용자 피드백으로 보고되지 않은 경우에는 더욱 그렇다.”

그들은 사용자가 명시적으로 피드백을 제공하지 않는 한 무엇이 고장 났는지 볼 수 없었다. 개인 정보 보호를 위해서는 좋지만 디버깅을 위해서는 끔찍하다.

2. 버그가 자신을 숨겼다

클라우드는 종종 개별적인 실수에서 회복하여 열화를 정상적인 변동으로 보이게 했다. 벤치마크와 평가에서는 이를 잡지 못했다. 왜냐하면 모델이 충분히 자체적으로 수정하여 테스트를 통과할 수 있었기 때문이다.

3. 멀티 플랫폼 혼돈

클라우드는 AWS Trainium, NVIDIAGPU, 구글 TPU – 세 가지 완전히 다른 하드웨어 플랫폼에서 실행된다. 각 버그는 각 플랫폼에서 다르게 나타났다:

• AWS Bedrock: 피크 시간에 0.18%의 소네트 4 요청이 영향을 받았다
• 구글 Vertex AI: 0.0004% 미만의 요청이 영향을 받았다
• 직접 API: 최대 16%의 요청이 영향을 받았다

이것은 여러 개의 무관한 문제로 보이게 만들었다.

4. 중첩되는 증상

세 가지 버그가同時에 발생하여 증상은 모든 곳에 산재해 있었다. 한 사용자는 태국어 문자를 받았을 수 있다. 다른 사용자는 열화된 응답을 받았을 수 있다. 세 번째 사용자는 완벽한 성능을 보았을 수 있다. 어떤 명확한 패턴도 없었다.

이것이 실제로 의미하는 바: AI 신뢰성

이 사례는 현재 AI 시스템의 상태에 대해 중요한 것을 보여준다: 그들은 보이는 것보다 훨씬 더 취약하다.

우리는 단지 AI 모델 자체에 대해 이야기하는 것이 아니다. 우리는 다음과 같은 것에 대해 이야기한다:

• 요청을 잘못된 곳으로 라우팅할 수 있는 라우팅 인프라
• 하드웨어 특정 구현이 다르게 동작할 수 있다
• 개월 동안 잠복할 수 있는 컴파일러 버그
• 소규모 문제를 주요 중단으로 증폭할 수 있는 로드 밸런서

한 가지 구성 오류, 한 가지 컴파일러 버그, 한 가지 라우팅 오류 – 그리고突然 AI 어시스턴트가 코드를忘れた 것처럼 행동하거나 의도하지 않은 언어를 말하기 시작한다.

실제로 고쳐졌는가?

앤트로픽은 9월 16일부터 세 가지 문제를 모두 해결했다고 말한다. 그들은:

• 라우팅 논리를 수정했다
• 문제가 있는 구성으로 돌아갔다
• 근사적인 상위 k 연산에서 정확한 상위 k 연산으로 전환했다(정확성을 위해 성능을 희생했다)
• 지속적인 프로덕션 모니터링을 추가했다

하지만 사용자들은 여전히 문제를 보고 있다. 일부 개발자들은 클라우드 코드가 여전히 이전의 성능과 비교했을 때 열화된 것처럼 느껴진다. 이것이:

• 버그의 잔여 효과
• 새로운 문제가 아직 식별되지 않은 것
• 수주간의 문제로 인한 심리적 편향
• 실제로 계속되는 열화

…우리는 아직 모른다.

결론

이 상황은 복잡한 AI 시스템이 예상치 못한 방식으로 고장 날 수 있는 완벽한 사례이다. 세 가지 별개의 버그가 몇 주 동안 발생하여巨大한 품질 열화를 일으켰고, 6주 동안 진단하고 고칠 수 있었다.

앤트로픽에게透明성을 제공한 점에 대해 일부赞賞할 수 있다. 기술적인 사고 분석 보고서를 발행하는 것은 대부분의 회사에서 할 수 없는 일이다. 하지만 이것은 이러한 시스템의 내부에서 얼마나 많은 것이 잘못될 수 있는지 보여준다.

클라우드나 다른 LLM을 기반으로 구축하는 모든 사람에게: 백업 계획, 검증, 중복성이 필요하다. 왜냐하면 우리는 이미 본 것처럼, 심지어 최고의 AI 시스템도同時에 세 가지 다른 문제를 가질 수 있으며, 실제로 무슨 일이 일어나고 있는지 알아내기까지 몇 주가 걸릴 수 있기 때문이다.

이러한 AI 모델을 지원하는 인프라는 모델 자체와同じ 정도로 중요하다. 그리고 현재, 그 인프라는 심각한 성장통을 겪고 있다.