이번 주, 오픈 소스 커뮤니티는 vLLM-Omni 지원을 위한 최신 PR을 포함하여 모델 서빙 인프라에 대한 업데이트로 활기를 띠었습니다. 팀들이 더욱 효율적이고 확장 가능한 추론 파이프라인(inference pipelines)을 배포하기 위해 경쟁하면서도, 종종 간과되는 퍼즐 조각 하나가 남아 있습니다. 바로 작업이 시작되기 전에 하드웨어가 준비되었는지 확인하는 것입니다. 저희 Apex Grid는 지난 몇 달 동안 크론 에이전트 인프라의 핵심 부분이 된 2단계 GPU 사전 점검(GPU preflight check)을 다듬는 데 시간을 보냈습니다.
GPU 리소스에 의존하는 크론 작업(cron jobs)을 배포할 때, 단순히 작업을 try/except 블록으로 감싸는 것만으로는 충분하지 않습니다. 그러한 접근 방식은 근본적인 문제가 작업 자체가 아니라 GPU의 상태일 경우 조용히 실패할 위험이 있습니다. 예를 들어, 다른 작업이 카드를 독점하고 있거나(monopolizing), 커널(kernel)이 요청에 응답하지 않는 상태일 수 있습니다. 저희 솔루션은 작업을 실행하려고 시도하기 전에 GPU와 서빙 스택 모두가 건강한 상태인지 확인하는 2단계 사전 점검을 포함합니다.
저희의 사전 점검 로직은 두 가지 간단하지만 효과적인 엔드포인트에 달려 있습니다. 하나는 기본 상태를 확인하는 것(/api/tags)이고, 다른 하나는 경량 추론(lightweight inference)을 수행하는 것입니다(/api/generate). 첫 번째 검사는 모델 서버가 응답 가능한지 그리고 사용 가능한 태그 목록을 반환할 수 있는지 확인하여 빠른 스모크 테스트(smoke test) 역할을 합니다. 두 번째 검사는 최소한의 추론 작업을 실행하며, 이를 통해 GPU가 실제로 사용 가능한지 아니면 다른 작업에 의해 차단되고 있는지를 감지하는 데 도움을 줍니다. 저희는 이 두 번째 검사에 워밍업 타임아웃(warmup timeout)을 설정하는데, 이는 일반적으로 모델 크기와 워크로드에 따라 3초에서 10초 사이입니다.
실제 구현에서 저희의 gpu_ready() 헬퍼 함수가 어떻게 보이는지 보여드리겠습니다:
import requests
import time
...
이 접근 방식은 여러 장점이 있습니다. GPU가 단순히 사용 가능한 상태일 뿐만 아니라, 작업 처리 중 지연(stalling)이나 시간 초과(timing out) 없이 작업을 수행할 수 있는 상태임을 보장합니다. 또한 사전 점검(preflight check)이 실패할 경우 나중에 실패하여 시스템을 일관되지 않은 상태로 만들 가능성을 방지하고 깔끔하게 작업을 건너뛸 수 있게 해줍니다. 이는 여러 cron 작업이 동일한 GPU 리소스 풀을 공유하는 환경에서 특히 유용했습니다.
물론 트레이드오프(tradeoff)도 존재합니다. 사전 점검은 전체 작업 스케줄링 프로세스에 약간의 지연 시간(latency)을 추가합니다. 또한 모델 서버가 /api/tags와 /api/generate 두 엔드포인트 모두를 노출해야 하는데, 이는 모든 서빙 스택에서 해당되는 것은 아닐 수 있습니다. 저희는 사전 점검 로직을 구성 가능하게 만들어 이를 완화했습니다. 따라서 필요한 경우 팀이 2단계(second stage)를 건너뛰거나 다른 경량 추론 작업(lightweight inference task)을 사용할 수 있도록 했습니다.
앞으로는 이 사전 점검 로직을 더욱 적응형으로 만들 방법을 탐구하고 있습니다. 예를 들어, 이 작업에 특별히 조정된 경량 모델(lightweight model)을 워밍업 추론(warmup inference)에 사용하는 실험을 진행하여 2단계를 완료하는 시간을 줄이고 있습니다. 또한 GPU 준비 상태 확인을 더 광범위한 시스템 상태 모니터링 파이프라인의 일부로 만들기 위해 Kubernetes 및 기타 오케스트레이션 도구와 이 로직을 더 깊이 통합하는 방안도 검토하고 있습니다. 여러분은 어떻게 생각하시나요? 훨씬 더 경량화된 사전 점검을 선호하시겠습니까, 아니면 실패했을 때 더 상세한 진단(diagnostics)을 제공하는 것을 선호하시겠습니까?