Kilawatt 리포트 내부 공개: GPU 장애 조치 훈련 10회, 제외된 시도 6회, 모든 수치 공개

공개 고지: 저는 Kilawatt Cloud의 설립자입니다. 아래에 나열된 모든 훈련을 자체 테스트 계정으로 실행하고 시간을 측정했으므로, 이는 저희 자체 테스트 기록이며 독립적인 보고서가 아닙니다.

질문점

칩 제조업체들은 모두 같은 약속을 판매합니다: 더 많은 컴퓨팅 능력, 더 빠른 속도. 소프트웨어를 통해 GPU를 구매하는 사람이라면 다음 질문이 더 중요합니다: 임대한 머신이 작업 도중에 사라지면 어떻게 될까요?

Image 1

자체적으로 작업을 구매하는 에이전트에게 실패한 작업은 손실된 구매이자 재구매를 하지 않을 이유가 됩니다. 저는 측정치를 원했기 때문에, 실제 GPU 머신 10대를 작업 도중에 파괴하고 플랫폼이 다음에 무엇을 하는지 시간을 측정했습니다.

훈련 진행 방식

10월 20일에 goose 에이전트 앱으로 8번의 훈련이 실행되었습니다. 각 작업은 저희 MCP 서버를 통해 x402 (Base의 USDC)로 구매되었고, 운영자가 상태 확인(health check)을 통과한 후 Vast.ai 머신을 수동으로 파괴했습니다. 두 번의 이전 훈련은 10월 14일에 진행되었으며, RunPod A100에서 체크포인팅 작업이 수행되었습니다.

Image 2

저는 두 가지를 측정했습니다:

1. 감지(Detection): 제가 파괴한 시점부터 플랫폼이 해당 머신을 실패로 표시하는 시간.

2. 장애 조치 주장(Failover claimed): 감지된 시점부터 플랫폼이 다른 공급업체에서 대체품을 확보한다고 주장하는 시간.

Image 3

결과

Image 4

모든 10회의 시도 동안 플랫폼은 매번 다른 공급업체(supplier)에 교체를 배치했습니다.

범위가 넓은 이유

제가 'Destroy'를 클릭한 시간을 초 단위가 아닌 분 단위로 기록했기 때문에, 각 감지 수치는 약 1분 간격의 범위입니다. 또한 상태 확인(Health checks)도 2분마다 실행되므로, 교체 이후 감지는 3~4분 정도 걸립니다.

이 시도에서 다루지 않는 것들

1. 교체 준비 시간 (Replacement-ready time). 데이터베이스가 이를 기록하고 있지 않았습니다. 교체된 장치들이 나중에 상태 확인을 통과했지만, 제가 타이밍 정보를 가지고 있지 않으므로 10월 20일 시도에 대한 복구 시간을 주장할 수 없습니다.

2. 10월 20일 작업의 재개 (Resume on the October 20 jobs). x402를 통해 구매한 작업은 체크포인트를 저장하지 않으므로, 이 여덟 건은 감지와 교체만을 측정합니다. 재개는 10월 14일에만 표시되었습니다.

3. 중앙값 또는 최악의 경우 (A median or worst case). 10회 시도는 너무 적기 때문에 정확한 개수와 범위를 제시합니다.

4. 공급업체 제거 시도 (A supplier-removal drill). 아직 실행되지 않았습니다.

5. 완전 자율 구매 (Fully autonomous buying). 사람이 각 구매 프롬프트를 입력하고 각 장치를 파괴했습니다. 이는 페이퍼잡(pay-per-job) 경로와 장애 조치(failover)가 함께 작동하는 것을 보여줍니다.

Image 5

제가 제외한 6개 작업

저는 10월 20일에 14개의 작업을 요청했고 그중 8개를 계산했습니다:

1. Vast.ai 호스트 하나에서 네 개가 부팅되지 않았습니다. 이 작업들은 자동 환불되었고, 저는 해당 호스트를 코드상으로 차단했습니다.
2. 하나의 600초 창(window)이 너무 짧았습니다.
3. 하나는 창의 끝에서 중지된 대체(replacement)였는데, 이는 단순한 시뮬레이션이 아니었습니다.

훈련 과정에서 발견된 문제점들 (What the drills broke)

1. 엔드포인트가 여러 번 거부될 때마다 '요청 속도 제한(rate limiting requests)'이라고만 표시했습니다. 실제 한계치와 언제 해제되는지 명시해야 합니다.
2. 인스턴스가 파괴된 후에도 작업의 동시성 슬롯(concurrency slot)이 15분 동안 유지되었습니다.
3. 두 개의 작업에 대해 '절대 준비 안 된 환불(never-ready refund)'이 제때 발생하지 않았습니다.
4. 일부 호스트에서 Docker 이미지를 가져오는 과정이 지연됩니다. 이를 사전에 캐싱하는 것이 목록에 있습니다.

Image 6

다음 계획 (What's next)

감지(Detection) 시간이 제가 원하는 것보다 2~4분 정도 느리며, 이를 단축하는 것이 로드맵의 최우선 순위입니다. 그 이후에는:

1. 각 대체 작업이 준비되는 시간을 기록할 것입니다.
2. 중앙값 및 가장 느린 시간으로 더 많은 세트를 실행할 것입니다.
3. 공급자 제거 훈련(supplier-removal drill)을 진행하고 이를 공개할 것입니다.

Image 7

방법론과 제외된 시도까지 포함한 전체 사례 연구는 여기에서 확인할 수 있습니다: https://www.kilawattcloud.dev/super-intelligence

저자 소개: Damian Dixon은 로스앤젤레지에 기반을 둔 Kilawatt Cloud의 설립자입니다.