Two Bugs That Hid in Plain Sight: A vLLM Debugging Detective Story — Asaf Gardin & Yuval Belfer

한 줄 핵심

고신뢰도인데도 조용히 망가지는 vLLM/Jamba 계열 추론·학습 버그 두 건을, 로그프롭 비교와 재현 조건 압축으로 추적해 원인을 찾아낸 디버깅 사례다.

시간별 요약

1. 0:00
   무중단·무경고·고신뢰 이 문제들은 크래시나 경고 없이도 출력만 조용히 틀어지는 유형이며, 모델 품질 문제가 아니라 추론·실행 파이프라인의 엔지니어링 문제로 다뤄야 한다. 사례의 배경은 AI21의 Jamba 계열 모델을 학습·서빙하는 과정에서 발생한 실전 버그 추적이다.
2. 2:48
   천 번 중 한 번 나오는 횡설수설 첫 번째 문제는 1,000번 중 1번 정도만 나타나는 희귀한 gibberish로, 단일 요청이나 소규모 트래픽에서는 잘 드러나지 않는다. vLLM에서만 발생하고 다른 인프라 프레임워크에서는 보이지 않아, 엔진 특이적인 원인 추적이 필요했다.
3. 3:43
   GPU를 굶겨 빠르게 재현하기 재현을 빠르게 만들기 위해 GPU memory utilization을 90%에서 20%로 낮추고 동시에 많은 요청을 돌려, 특정 요청이 안정적으로 gibberish를 내도록 만들었다. temperature zero로 샘플링해 같은 실패를 반복 재현할 수 있게 하자 디버깅 루프가 짧아졌다.
4. 5:18
   평범한 기준선과의 logprob 비교 vLLM의 출력과 logprops를 Hugging Face transformers의 plain baseline과 비교해 분포 차이를 측정했다. 처음에는 CUDA prefill kernel, compute sanitizer, decode/prefill 분리 실험까지 했지만 이상이 보이지 않았고, 문제는 더 깊은 엔진 흐름에 있을 가능성이 커졌다.
5. 8:48
   forward pass에 request ID를 넣기 요청에 identity가 없어서 어느 prompt가 처리 중인지 추적할 수 없었기 때문에, request ID를 forward context에 실어 prefill과 decode 직전까지 전달했다. 이로써 특정 실패 요청에 breakpoint를 걸고 내부 메타데이터를 직접 관찰할 수 있게 됐다.
6. 9:30
   prefill보다 먼저 decode가 실행된 이유와 Mamba만 문제를 본 이유 문제 요청은 본래 prefill 후 decode여야 하는데, scheduler가 decode를 먼저 배치해 stale state를 읽고 있었다. attention은 KV를 덮어쓰는 구조라 버티지만, Mamba는 먼저 읽고 계산하므로 이전 요청의 오래된 상태를 써서 gibberish가 발생했다.
7. 11:47
   두 번째 사례: 12스텝마다 logprob가 튀는 현상 두 번째 문제는 RL과 inference에서 rollout과 FSTP 사이의 logprob가 가끔 크게 달라지는 현상으로, 같은 입력과 같은 가중치인데도 결과가 일치하지 않았다. 특히 12 step 주기로 반복적으로 스파이크가 나타나 다른 실패 메커니즘을 의심하게 했다.
8. 12:29
   실패의 모양을 바꾸는 레버 원인을 좁히기 위해 단순히 실패 횟수가 아니라 실패 시점과 형태를 바꾸는 레버를 찾았고, rollout per prompt를 8에서 16, 32, 64, 128로 늘려 재현 시점을 앞당겼다. 그 결과 128에서는 step 1에 바로 문제가 드러났고, GPU 메모리를 줄이면 오히려 문제가 사라진다는 단서도 얻었다.
9. 14:33
   되돌아간 32비트 인덱스 원인은 Mamba 커널이 unsigned 32-bit index를 써서 오프셋이 약 4 billion을 넘으면 wrap-around되는 것이었다. GPU 메모리를 줄이면 버퍼가 작아져 overflow에 도달하지 못했고, 해결은 u in32를 size_t로 바꿔 64-bit 범위로 넓히는 것이었다.
10. 15:42
    두 장면, 한 범인 두 사건은 서로 달라 보여도 모두 Mamba state cache 주변에서, 메모리 압박과 logprob 포렌식으로 드러난 조용한 실패라는 공통점을 가졌다. 핵심 교훈은 로그프롭 비교 스크립트, 메모리 압축 재현, 실패의 시간·공간·형태를 바꾸는 레버, 그리고 identity 추적을 직접 심는 습관이 필요하다는 점이다.

실무 인사이트

• 조용한 오답형 버그는 모델 개선보다 비교 기준선과 재현 조건 설계가 먼저여야 하며, logprob 비교를 자동화하면 원인 분리가 빨라진다.
• 희귀 버그는 트래픽을 늘리기보다 메모리·롤아웃 수·스케줄 순서를 조절해 실패를 압축시키는 방식이 디버깅 효율이 높다.
• 요청 ID 같은 identity를 forward pass까지 관통시키면, 텐서만 남는 구간에서도 어떤 요청이 어떤 경로를 탔는지 추적할 수 있다.