증상:
작업을 제출하면 IN_QUEUE 상태로 머물러 절대 이동하지 않습니다. 콘솔에서는 엔드포인트가 정상으로 보입니다. 워커는 계속 시작했다가 죽기 때문에, 충돌(crash)보다는 큐(queue) 문제처럼 보입니다.

일반적인 조언은 '핸들러 로그를 확인하라'인데, 이는 맞지만 무엇을 찾아야 하는지 알려주지는 않습니다. 제가 시간 낭비를 했던 특정 실패 모드이며 글로 정리된 적이 없습니다.

문제를 일으키는 설정

모델 가중치(model weights)를 이미지에 베이크(bake)하는 경우, 상위 변경 사항이 사용자 몰래 가중치를 교체하지 못하도록 리비전(revision)도 고정(pin)할 가능성이 높습니다. 이는 합리적입니다. 함정은 레포 ID(repo id)와 리비전이 보통 두 개의 다른 장소에서 관리된다는 것입니다:

• 레포 ID는 RunPod 템플릿의 환경 변수(env var)에서 가져옵니다.
• 리비전은 로더 옆 코드에 고정됩니다.

만약 레포 ID만 변경하고, 예를 들어 실제로 베이크한 양자화된 미러(quantized mirror) 대신 원래 레포를 MODEL_ID로 지정하면, 존재하지 않는 조합을 만들게 됩니다. 즉, 미러에서만 존재하는 커밋 해시(commit hash)를 다른 레포에 요청하는 것입니다.

실제 부팅 시 발생하는 일

로드는 로컬 캐시를 놓치고 (해당 레포는 베이크된 적이 없으므로), 네트워크 폴백(fall back)을 통해, 해당 레포가 절대 가지고 있지 않은 리비전을 요청하며, 시작 중에 404 오류가 발생합니다. 워커는 핸들러에 도달하기 전에 죽습니다.

외부에서 보면 이는 충돌처럼 보이지 않습니다. 엔드포인트는 정상이라고 보고하고, 워커는 순환(cycle)하며, 작업은 그저 큐에 머물러 있습니다.

확인 방법

엔드포인트 상태가 아닌 워커의 로그를 여세요. 부팅 시 가져오기(fetch) 시도를 찾으세요: 만약 베이크된 이미지가 가중치를 위해 네트워크에 접근한다면, 이미 무언가 잘못되었다는 뜻입니다. 그런 다음 템플릿 환경 변수에 있는 레포 ID와 Dockerfile이 다운로드한 정확한 레포 및 리비전을 비교하세요.

핵심 요약

가중치가 베이크된 경우, 레포 ID와 리비전을 하나의 단위로 취급해야 합니다. 두 가지 모두 같은 장소에 고정하거나, 런타임 시 둘 다 설정하지 마세요. 이를 템플릿 환경 변수와 코드 상수 사이에 분리하는 것이 바로 존재하지 않는 조합을 요청하게 만드는 방법입니다.