Claude - 최근 3가지 이슈에 대한 사후 분석 (25.9.19)

A postmortem of three recent issues

(Claude - 최근 3가지 이슈에 대한 사후 분석)

 
이 보고서는 Claude의 응답을 간헐적으로 지연시켰던 세 가지 버그에 대한 기술 보고서입니다. 아래에서 발생한 문제, 해결에 시간이 걸린 이유, 그리고 향후 변경 사항에 대해 설명합니다.
 
8월부터 9월 초까지 세 가지 인프라 버그로 인해 Claude의 응답 품질이 간헐적으로 저하되었습니다. 이제 이 문제들을 해결했으며, 발생 원인을 설명하고자 합니다.
 
8월 초, 여러 사용자가 클로드의 응답이 좋지 않다고 신고하기 시작했습니다. 이러한 초기 신고는 일반적인 사용자 피드백의 변화와 구분하기 어려웠습니다.
 
8월 말, 이러한 신고의 빈도와 지속성이 증가함에 따라 저희는 조사를 시작하게 되었고, 그 결과 세 가지의 인프라 버그를 발견했습니다.
간단히 말씀드리자면, 저희는 수요, 시간대, 서버 부하로 인해 모델 품질을 저하시키지 않습니다. 사용자들이 보고한 문제는 오로지 인프라 버그 때문이었습니다.
 
사용자들이 Claude에게 일관된 품질을 기대한다는 점을 인지하고 있으며, 인프라 변경으로 인해 모델 출력에 영향이 발생하지 않도록 매우 높은 기준을 유지하고 있습니다. 하지만 최근 사고에서는 그 기준을 충족하지 못했습니다. 다음 분석에서는 문제의 원인, 탐지 및 해결에 예상보다 오랜 시간이 소요된 이유, 그리고 향후 유사한 사고 발생을 방지하기 위해 어떤 부분을 개선하고 있는지 설명합니다.
 
여기서는 일반적으로 인프라에 대한 이 정도의 기술적 세부 사항을 공유하지 않지만, 이러한 문제의 범위와 복잡성으로 인해 보다 포괄적인 설명이 필요했습니다.

---

대규모로 Claude 서비스를 제공하는 방법 - How we serve Claude at scale

저희는 1st-party API인 Amazon Bedrock과 Google Cloud의 Vertex AI를 통해 수백만 명의 사용자에게 Claude를 제공합니다.
 

역자주: AWS 와 GCP 상에서 별도 K8S를 구성하지 않고 CSP 에서 ready-made 된 AI PaaS 를 활용하여 Claude 서비스를 serving 하는 것으로 보임.
실제 K8S 와 같은 IaaS 를 사용자가 혹은 MSP 를 통해서 구축한 경우 유지비용이 더 저렴할 수 있다.
아마도 빠른 구축 대응 시간을 위해서 CSP 측의 AI 서비스를 사용한 것으로 추측된다.

 
AWS Trainium, NVIDIA GPU, Google TPU 등 다양한 하드웨어 플랫폼에 Claude를 배포합니다.
 
이러한 접근 방식을 통해 전 세계 사용자에게 서비스를 제공하는 데 필요한 용량과 지리적인 배분을 확보할 수 있습니다.
 
각 하드웨어 플랫폼은 서로 다른 특성을 가지고 있으며 특정 최적화가 필요합니다. 이러한 차이에도 불구하고, 저희는 모델 구현에 대한 엄격한 동등성 기준을 적용합니다.
 
저희의 목표는 사용자가 어떤 플랫폼에서 요청을 처리하든 동일한 품질의 응답을 받을 수 있도록 하는 것입니다. 이러한 복잡성으로 인해 모든 인프라 변경은 모든 플랫폼과 구성에 대한 신중한 검증이 필요합니다.

---

이벤트 타임라인 - Timeline of events

Claude API 이벤트의 타임라인 - 노란색: 문제 감지, 빨간색: 성능 저하 심화, 녹색: 수정 사항 배포.

 
이러한 버그들이 중복되는 특성으로 인해 진단이 특히 어려웠습니다. 첫 번째 버그는 8월 5일에 발생하여 Sonnet 4에 대한 요청의 약 0.8%에 영향을 미쳤습니다. 8월 25일과 26일에 배포된 두 개의 버그가 추가로 발생했습니다.
 
초기 영향은 제한적이었지만, 8월 29일 로드 밸런싱 변경으로 인해 영향을 받는 트래픽이 증가하기 시작했습니다.
 
이로 인해 더 많은 사용자가 문제를 겪는 반면, 다른 사용자는 정상적인 성능을 유지하여 혼란스럽고 모순되는 보고서가 생성되었습니다.

---

설상가상 3가지 이슈 중첩 - Three overlapping issues

아래에서는 성능 저하를 일으킨 세 가지 버그에 대해 설명하고, 버그가 발생한 시점과 해결 방법을 설명하도록 하겠습니다.

1. 컨텍스트 윈도우 라우팅 애러 - Context window routing error

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%로 최고치를 기록했습니다. 8월 27일부터 9월 16일까지 Google Cloud의 Vertex AI에서 잘못된 라우팅으로 인해 발생한 요청은 전체 요청의 0.0004% 미만이었습니다.
 
하지만 일부 사용자는 더 심각한 영향을 받았습니다. 저희 라우팅 방식이 "고정적"이기 때문입니다. 즉, 잘못된 서버에서 요청이 처리되면 이후의 후속 요청도 동일한 잘못된 서버에서 처리될 가능성이 높았습니다.
 
해결 방법: 짧은 컨텍스트 및 긴 컨텍스트 요청이 올바른 서버 풀로 전달되도록 라우팅 로직을 수정했습니다. 9월 4일에 수정 사항을 배포했습니다.
 
1st-party 플랫폼과 Google Cloud의 Vertex에 대한 배포는 9월 16일에 완료되었습니다. 현재 (9월17일) Bedrock에 수정 사항을 배포하는 중입니다.

2. 출력 손상 - Output corruption

8월 25일, Claude API TPU 서버에 잘못된 구성을 배포하여 토큰 생성 중 오류가 발생했습니다.
 
런타임 성능 최적화 과정에서 발생한 문제로 인해 맥락상 거의 생성되지 않아야 할 토큰에 높은 확률이 할당되는 경우가 있었습니다.
 

8월말 Claude Code 사용자 결과 - 나오지 말아야할 토큰 단어가 표출되고 있다.

 
예를 들어, 영어 프롬프트에 태국어 또는 중국어 문자를 응답으로 생성하거나 코드에서 명백한 구문 오류를 생성하는 경우가 있었습니다. 예를 들어, 영어로 질문을 한 일부 사용자는 응답 중간에 "สวัสดี"라는 문구를 보았을 수 있습니다.
 
이 손상은 8월 25일~28일 사이에 Opus 4.1과 Opus 4에 대한 요청과 8월 25일~9월 2일 사이에 Sonnet 4에 대한 요청에 영향을 미쳤습니다. 3rd-parity 플랫폼은 이 문제의 영향을 받지 않았습니다.
 
해결 방법: 문제를 파악하고 9월 2일에 변경 사항을 롤백했습니다. 배포 프로세스에 예상치 못한 문자 출력에 대한 감지 테스트를 추가했습니다.

3. XLA 컴파일링 오류 - Approximate top-k XLA:TPU miscompilation

8월 25일, Claude가 텍스트 생성 시 토큰을 선택하는 방식을 개선하는 코드를 배포했습니다.
 
이 변경으로 인해 XLA:TPU 컴파일러에 잠재적인 버그가 발생하여 Claude Haiku 3.5에 대한 요청에 영향을 미치는 것으로 확인되었습니다.
 
또한 이 문제가 Claude API의 Sonnet 4 및 Opus 3 하위 세트에도 영향을 미쳤을 것으로 예상됩니다. 3rd-parity 플랫폼은 이 문제의 영향을 받지 않았습니다.
 
해결책: 저희는 Haiku 3.5에 영향을 미치는 버그를 처음 발견했고 9월 4일에 롤백했습니다. 나중에 저희는 이 버그와 호환되는 Opus 3의 문제에 대한 사용자 보고를 확인했고 9월 12일에 롤백했습니다. 광범위한 조사 끝에 Sonnet 4에서 이 버그를 재현할 수 없었지만, 주의를 기울여 롤백하기로 결정했습니다.
 
동시에, 저희는
 
(a) XLA:TPU 팀과 협력하여 컴파일러 버그 수정 작업을 진행했으며,
(b) 향상된 정밀도로 정확한 Top-k를 사용할 수 있도록 수정 사항을 적용했습니다.
 
자세한 내용은 아래 심층 분석을 참조하세요.

---

A closer look at the XLA compiler bug - XLA 컴파일러 버그에 대한 자세한 살펴보기

이러한 문제의 복잡성을 보여주기 위해 XLA 컴파일러 버그가 어떻게 나타났는지, 그리고 왜 특히 진단하기 어려웠는지 설명하겠습니다.
 
클로드는 텍스트를 생성할 때, 가능한 다음 단어 각각에 대한 확률을 계산한 다음, 이 확률 분포에서 무작위로 샘플을 선택합니다. "top-p 샘플링"을 사용하여 무의미한 출력을 방지하고, 누적 확률이 임계값(일반적으로 0.99 또는 0.999)에 도달하는 단어만 고려합니다. TPU (AWS Trainium) 에서 저희 모델은 여러 칩에 걸쳐 실행되며, 확률 계산은 서로 다른 위치에서 수행됩니다. 이러한 확률을 정렬하려면 칩 간의 데이터를 조정해야 하는데, 이는 매우 복잡합니다.
 
2024년 12월, TPU 구현에서 temperature 값이 0 일 때 가장 가능성이 높은 토큰이 가끔씩 삭제되는 현상을 발견했습니다.
https://docs.claude.com/en/docs/about-claude/glossary#temperature

Glossary - Claude Docs

 

📌 temperature 값은 텍스트 생성 중 모델 예측의 무작위성을 제어하는 매개변수입니다. temperature 값이 높을수록 더욱 창의적이고 다양한 출력이 생성되어 다양한 표현 방식을 사용할 수 있으며, 소설의 경우 답변의 다양성도 확보할 수 있습니다. temperature 값이 낮을수록 가장 가능성 있는 표현 방식과 답변에 집중하는 더욱 보수적이고 결정론적인 출력이 생성됩니다. temperature 값을 조정하면 사용자는 언어 모델이 가장 가능성 있는 예측만을 선택하는 대신, 드물거나 흔하지 않거나 놀라운 단어 선택과 시퀀스를 탐색하도록 유도할 수 있습니다.

 
이 문제를 해결하기 위해 임시 해결책(workaround)을 구축했습니다.

temperature값이 0일 때 예기치 않게 토큰이 삭제되는 버그를 해결하기 위한 2024년 12월 패치의 코드 조각

 
근본 원인은 혼합 정밀도 연산과 관련이 있습니다. Claude 모델은 다음 토큰 확률을 bf16 (Brain Float 16- 16비트 부동 소수점)으로 계산합니다. 그러나 벡터 프로세서는 fp32 (32비트 부동 소수점)를 기본적으로 사용하기 때문에 TPU 컴파일러(XLA)는 일부 연산을 fp32로 변환하여 런타임을 최적화할 수 있습니다. 이 최적화 단계는 xla_allow_excess_precision 플래그 값이 true 값으로 default 상태로 설정됩니다.
 
이로 인해 불일치가 발생했습니다. 가장 높은 확률의 토큰에 대해 합의되어야 할 연산들이 서로 다른 정밀도 수준에서 실행되고 있었던 것입니다. 정밀도 불일치는 어떤 토큰의 확률이 가장 높은지에 대해 합의하지 못했음을 의미합니다.
 
이로 인해 가장 높은 확률의 토큰이 고려 대상에서 완전히 사라지는 경우가 발생했습니다.
 
8월 26일, 저희는 정밀도 문제를 해결하고 Top-p 임계값에 도달하는 확률을 처리하는 방식을 개선하기 위해 샘플링 코드를 재작성했습니다. 하지만 이러한 문제를 해결하는 과정에서 더 까다로운 문제가 드러났습니다.
 

"""
JAX의 'bf16' 최적화 '버그'의 최소 재현 코드입니다.

2024년 12월에 해결될 "버그"의 근본 원인이 된 8월 11일 변경 사항의 일부로 병합된 최소화된 재생산자를 보여주는 코드 조각입니다. 

실제로 이는 xla_allow_excess_precision 플래그의 예상된 동작입니다.

이 코드는 JAX gun에서 bf16 값 비교 시 최적화 장벽 없이
형 변환을 한 후 잘못된 결과가 나오는 것을 보여줍니다.

'XLA_FLAGS=--xla_allow_excess_precision=False'로 실행하면 문제가 해결됩니다.
TPU에서 실행해야 문제를 재현할 수 있습니다.
또한 test_mask_top_k_and_top_p_logits_jax_bug도 테스트해야 합니다.
"""

import tempfile
import jax
import jax.numpy as jnp

def test_jax_bf16_optimization_bug():
  """JAX bf16 최적화 '버그'를 위한 최소 테스트 케이스입니다."""
  key = jax.random.PRNGKey(42)
  x = jax.random.normal(key, (2, 1, 1024), dtype=jnp.float32)

  def f(inp: jax.Array, workaround: bool) -> jax.Array:
    x = jax.nn.softmax(inp, axis=-1)
    x = x.astype(jnp.bfloat16)
    y = jnp.max(x, axis=-1, keepdims=True)

    if workaround:
      x, y = jax.lax.optimization_barrier((x, y))

    x = x.astype(jnp.float32)
    y = y.astype(jnp.float32)
    return jnp.where(x >= y, inp, -50000)

  jitted_f = jax.jit(f, static_argnames=["workaround"])
  result_without_barrier = jitted_f(x, workaround=False)
  result_with_barrier = jitted_f(x, workaround=True)

  # 보존된 값의 수를 계산합니다 (총 2개가 예상됨).
  preserved_without = jnp.sum(result_without_barrier > -50000)
  preserved_with = jnp.sum(result_with_barrier > -50000)

  print("\n결과:")
  print(f"장벽 없이: 보존된 값 {preserved_without}개 (예상: 2)")
  print(f"장벽 포함: 보존된 값 {preserved_with}개 (예상: 2)")

test_jax_bf16_optimization_bug()

 

✅ 추가 설명
📌 원인: 컴파일러 최적화

JAX는 내부적으로 XLA(Accelerated Linear Algebra) 컴파일러를 사용하여 코드를 장치(CPU, GPU, TPU)에 맞게 최적화합니다. 이 과정에서 컴파일러는 연산의 순서를 바꾸거나 불필요한 연산을 제거하는 등의 최적화를 수행합니다.

최적화 없는 경우 (기대 동작): float32 -> softmax -> bfloat16 변환 -> max 계산 -> float32 변환 -> 비교. 이 순서대로 정확히 실행되어야 합니다.최적화가 적용된 경우 (문제 발생): 컴파일러가 "어차피 x와 y는 같은 bfloat16 배열에서 나왔으니, 굳이 정밀도를 낮췄다가 다시 높여서 비교할 필요 없이, 더 높은 정밀도(float32) 상태에서 비교하자"라고 판단할 수 있습니다.

이렇게 되면 bfloat16으로 변환했을 때 발생해야 할 정밀도 손실이 비교 연산에 제대로 반영되지 않아, 최댓값과 거의 같지만 미세하게 작은 여러 값들이 y보다 크거나 같다고 잘못 판단될 수 있습니다. 그 결과, 2개가 아닌 훨씬 많은 값이 -50000으로 대체되지 않고 살아남게 됩니다.

📌 해결책 1: jax.lax.optimization_barrier

코드에서 workaround=True일 때 사용하는 jax.lax.optimization_barrier는 컴파일러에게 "이 지점을 기준으로 연산을 나누어라. 이 장벽을 넘어서는 최적화를 수행하지 말라"고 명시적으로 지시하는 역할을 합니다.

즉, 이 함수를 사용하면 x와 y를 bfloat16으로 계산하는 부분이 완전히 끝난 후에 다음 단계(비교 연산)가 진행되도록 보장합니다. 이로써 컴파일러의 과도한 최적화를 막고 우리가 의도한 대로 코드가 실행되어 정확한 결과(2개)를 얻게 됩니다.

📌 해결책 2: XLA 플래그 설정

코드의 주석에 언급된 XLA_FLAGS=--xla_allow_excess_precision=False는 XLA 컴파일러에게 "연산 과정에서 초과 정밀도를 허용하지 말라"고 지시하는 환경 변수입니다. 이 플래그를 설정하고 코드를 실행하면, 컴파일러가 임의로 더 높은 정밀도를 사용하여 계산하는 것을 막아주므로 optimization_barrier 없이도 올바른 결과를 얻을 수 있습니다.

 
저희는 근본 원인을 해결했다고 판단하여 12월 임시 해결책을 제거했습니다.

이로 인해 가장 높은 확률의 토큰을 빠르게 찾는 성능 최적화 기법인 근사 Top-k 연산에 더 심각한 버그가 발생했습니다. 
https://arxiv.org/abs/2206.14286

TPU-KNN: K Nearest Neighbor Search at Peak FLOP/s

 
이 근사값 함수(lax.apporx_max_k)는 때때로 완전히 잘못된 결과를 반환했지만, 특정 배치 크기와 모델 구성에서만 그랬습니다. 12월 임시 해결책이 의도치 않게 이 문제를 가리고 있었던 것입니다.
 

import jax.lax as lax
import jax.numpy as jnp
import numpy as np

# 비교할 상위 값의 개수
k = 256
# 배열의 전체 크기
N = 12000

print(f"배열 크기(N) = {N}, 찾는 상위 값 개수(k) = {k}")
print("="*40)
print("근사치(approx_max_k)와 정확한 값(top_k)이 다른 경우를 출력합니다.")
print("="*40)

# 0부터 N-1까지 반복
for i in range(N):
    # 크기 N의 배열을 0으로 초기화합니다.
    arr = jnp.zeros((N,), dtype=jnp.float32)
    # i번째 위치에만 1.0을 설정합니다.
    # JAX는 불변성을 가지므로 .at[].set()을 사용해 새로운 배열을 생성합니다.
    arr = arr.at[i].set(1.0)

    # approx_max_k 실행 (근사치 계산)
    approx_values, approx_indices = lax.approx_max_k(arr, k=k)

    # top_k 실행 (정확한 계산)
    exact_values, exact_indices = lax.top_k(arr, k=k)

    # 두 결과의 첫 번째 값(가장 큰 값)이 다른지 확인합니다.
    # 이 코드에서는 가장 큰 값은 항상 1.0이어야 합니다.
    if approx_values[0] != exact_values[0]:
        print(f"차이 발견! i = {i}: 정확한 최댓값 = {exact_values[0]}, 근사 최댓값 = {approx_values[0]}")

print("="*40)
print("비교 완료.")

 
버그의 동작은 실망스러울 정도로 일관성이 없었습니다. 버그 발생 전후에 어떤 작업이 실행되었는지, 디버깅 도구가 활성화되었는지 등 관련 없는 요인에 따라 동작이 달라졌습니다. 동일한 프롬프트가 어떤 요청에서는 완벽하게 작동하다가 다음 요청에서는 실패할 수도 있었습니다.
 
조사 과정에서 정확한 Top-k 연산이 더 이상 이전처럼 심각한 성능 저하를 초래하지 않는다는 사실을 발견했습니다.
 
approx Top-k 연산에서 정확한 Top-k 연산으로 전환하고, 일부 추가 연산을 fp32 정밀도에 맞춰 표준화했습니다.
 
모델 품질은 협상의 여지가 없으므로, 효율성에 미치는 영향은 미미한 것으로 받아들였습니다.

---

탐지가 어려웠던 이유 - Why detection was difficult

Anthropic의 검증 프로세스는 일반적으로 안전 평가 및 성능 지표와 함께 벤치마크를 활용합니다. 엔지니어링 팀은 임의 점검을 수행하고 소규모 "카나리아" 그룹에 먼저 배포합니다.
 
이러한 문제들은 우리가 더 일찍 발견했어야 할 중요한 결함을 드러냈습니다. 우리가 실행한 평가는 사용자들이 보고한 성능 저하를 제대로 포착하지 못했습니다.
 
부분적으로는 클로드가 단독적인 실수에서 종종 잘 회복하기 때문입니다. 또한, 당사의 개인정보 보호 관행으로 인해 보고 내용 조사에 어려움이 있었습니다.
 
Anthropic 의 내부 개인정보 보호 및 보안 관리 체계는 엔지니어가 클로드와의 사용자 상호작용에 접근할 수 있는 방식과 시기를 제한하며, 특히 이러한 상호작용이 피드백으로 보고되지 않은 경우 더욱 그렇습니다.
 
이는 사용자 개인정보를 보호하지만, 엔지니어가 버그를 식별하거나 재현하는 데 필요한 문제가 있는 상호작용을 조사하는 것을 방해합니다.
 
각 버그는 플랫폼마다 다른 증상을 각기 다른 속도로 나타냈습니다. 이로 인해 단일 원인을 지적하지 않는 혼란스러운 보고서들이 뒤섞였습니다. 마치 무작위적이고 일관성 없는 성능 저하처럼 보였습니다.
 
더 근본적으로는, 시끄러운 평가에 지나치게 의존했습니다. 온라인 신고 증가를 인지하고 있었지만, 이를 최근 변경 사항과 명확하게 연결할 방법이 없었습니다. 8월 29일 부정적인 신고가 급증했을 때, 일반적인 로드 밸런싱 변경 사항과 즉시 연결 짓지 못했습니다.
 

역자주: 서비스를 운영하다보면 이슈/장애는 하인리히 법칙에 따라 작은 이슈들이 모여 큰 이슈가 발생하게 된다.
특히 동시 다발적으로 이슈가 발생하다보면 원인규명, 재현 그리고 가설검증에 난이도가 급상승하게 된다.

---

우리가 도전하는 것 - What we're changing

저희는 인프라를 지속적으로 개선하는 동시에, Claude를 지원하는 모든 플랫폼에서 위에서 언급한 버그를 평가하고 방지하는 방식도 개선하고 있습니다. 변경 사항은 다음과 같습니다.

• 더욱 민감한 평가: 문제의 근본 원인을 파악하기 위해, 제대로 작동하는 구현과 제대로 작동하지 않는 구현을 더욱 확실하게 구분할 수 있는 평가를 개발했습니다. 모델 품질을 더욱 면밀히 모니터링하기 위해 이러한 평가를 지속적으로 개선해 나갈 것입니다.
• 더 많은 곳에서 품질 평가를 실시: Anthropic은 시스템에 대한 정기적인 평가를 실시하지만, 컨텍스트 창 부하 분산 오류와 같은 문제를 포착하기 위해 실제 운영 시스템에서도 지속적으로 평가를 실시할 것입니다.
• 더욱 빠른 디버깅 도구: 사용자 개인정보 보호를 침해하지 않으면서 커뮤니티에서 수집된 피드백을 더욱 효과적으로 디버깅할 수 있는 인프라와 도구를 개발할 것입니다. 또한, 여기에서 개발된 일부 맞춤형 도구는 향후 유사한 사고 발생 시 해결 시간을 단축하는 데 사용될 것입니다.

평가와 모니터링은 중요합니다. 하지만 이러한 사고들을 통해 클로드의 응답이 일반적인 기준에 미치지 못할 경우 사용자로부터 지속적인 보고가 필요하다는 것을 알게 되었습니다.
 
관찰된 구체적인 변경 사항, 예상치 못한 동작 사례, 그리고 다양한 사용 사례의 패턴을 통해 문제를 파악하는 데 도움이 되었습니다.
 
Anthropic은 사용자 커뮤니티의 기여에 감사드립니다.
 

참고 원문

https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues

A postmortem of three recent issues