RunPod Serverless 개요

RunPod Serverless는 AI 모델 추론(inference)이나 컴퓨팅 집약적 워크로드를 서버를 관리하지 않고 내보내는 클라우드 컴퓨팅 플랫폼이에요. 실제로 쓴 컴퓨팅 시간만큼만 과금되고, 애플리케이션이 요청을 처리하지 않을 때는 유휴 비용이 들지 않아요. "모델을 항상 켜 두지 않고, 요청이 올 때만 GPU를 빌려 쓰는" 구조라고 보면 돼요.

출처: RunPod Serverless 개요

핵심 개념

엔드포인트(Endpoints)

Serverless 애플리케이션의 접근 지점이에요. 사용자나 애플리케이션이 코드를 실행하려고 요청을 보낼 URL을 제공하죠. 엔드포인트마다 컴퓨팅 자원, 확장 설정, 기타 파라미터를 다르게 구성할 수 있어요.

워커(Workers)

엔드포인트에 요청이 도착하면 코드를 실제로 실행하는 컨테이너 인스턴스예요. 각 워커는 애플리케이션 코드와 의존성을 담은 커스텀 Docker 컨테이너를 돌려요. RunPod가 워커의 라이프사이클을 관리해서, 필요할 때 시작하고 유휴 상태가 되면 멈춰 자원 사용을 최적화해 줘요.

핸들러 함수(Handler functions)

Serverless 애플리케이션의 핵심으로, 워커가 들어온 요청을 어떻게 처리하고 결과를 돌려줄지 정의하는 함수예요. 패턴은 아주 단순해요:

import runpod  # Required

def handler(event):
    # Extract input data from the request
    input_data = event["input"]

    # Process the input (replace this with your own code)
    result = process_data(input_data)

    # Return the result
    return result

runpod.serverless.start({"handler": handler})  # Required

핸들러 함수는 큐 기반 엔드포인트(기존 방식의 엔드포인트)에서만 써요. 로드 밸런싱 엔드포인트를 쓰면 요청 구조와 엔드포인트가 HTTP 서버를 어떻게 정의하느냐에 따라 달라져요.

요청(Requests)

엔드포인트로 보내는 HTTP 요청이에요. 엔드포인트가 처리할 파라미터, 페이로드, 헤더를 담을 수 있어요. 예를 들어 POST 요청으로 잡(job)을 제출하거나, GET 요청으로 잡 상태를 확인하고 결과를 가져오거나 엔드포인트 상태를 확인할 수 있어요.

클라이언트가 엔드포인트로 요청을 보내면 이런 순서로 진행돼요.

활성 워커가 없으면 RunPod가 자동으로 워커를 하나 시작해요(콜드 스타트).
워커가 준비될 때까지 요청은 큐에 대기해요.
워커가 핸들러 함수로 요청을 처리해요.
클라이언트가 /status를 호출하면 결과가 반환돼요(/runsync를 썼다면 자동으로 반환돼요).
워커는 추가 요청을 처리하려고 일정 시간 활성 상태를 유지해요.
새 요청이 없으면 유휴 워커는 결국 종료돼요.

flowchart TD
    Start([Endpoint receives a request]) --> Queue[Request queued]
    Queue --> CheckActive{Worker ready?}
    CheckActive -->|No| ColdStart[Start new worker if workers < max_workers]
    ColdStart --> WaitWorker[Wait for available worker]
    WaitWorker --> Process[Worker processes request using handler function]
    CheckActive -->|Yes| Process
    Process --> End(["Result is stored (/run) or returned immediately (/runsync)"])

콜드 스타트(Cold starts)

콜드 스타트는 실행 중인 워커가 없는 엔드포인트에 요청이 왔을 때부터 워커가 완전히 준비되어 요청을 처리할 수 있을 때까지의 시간을 말해요. 보통 컨테이너 시작, 모델을 GPU 메모리에 로드, 런타임 환경 초기화를 포함해요. 모델이 클수록 메모리에 로드하는 시간이 길어져 콜드 스타트와 응답 시간도 같이 늘어나요.

콜드 스타트를 줄이는 게 응답성 있고 비용 효율적인 엔드포인트를 만드는 핵심이에요. 캐시된 모델을 쓰거나 FlashBoot를 켜거나 활성 워커 수를 0보다 크게 설정하면 줄일 수 있어요.

로드 밸런싱 엔드포인트(Load balancing endpoints)

들어오는 트래픽을 사용 가능한 워커에 직접 전달해서 워커 풀에 분산시키는 엔드포인트예요. 큐 기반 엔드포인트와 달리 요청 백로그에 대한 큐잉 메커니즘을 제공하지 않아요.

로드 밸런싱 엔드포인트에서는 핸들러 함수 없이 FastAPI나 Flask 같은 원하는 HTTP 프레임워크로 커스텀 API 엔드포인트를 직접 정의할 수 있어요.

피트니스 체크와 프리플라이트 체크(Fitness checks / preflight checks)

워커가 트래픽을 받기 전에 시작 시 환경을 검증해 줘요. 피트니스 체크(프리플라이트 체크라고도 해요)는 워커가 잡을 처리하기 전에 등록된 체크를 순서대로 실행해서, GPU 부재, 모델 미로드, 잘못된 설정 같은 문제를 요청이 워커에 닿기 전에 잡아내요.

개발 워크플로우

전형적인 Serverless 개발 흐름이에요.

핸들러 함수 작성 — API 요청을 처리하도록.
RunPod SDK로 로컬 테스트.
Dockerfile 작성 — 핸들러 함수와 모든 의존성을 패키징.
워커 이미지를 Docker Hub(또는 다른 컨테이너 레지스트리)에 빌드·푸시 — GitHub 저장소에서 직접 배포도 가능해요.
워커 이미지를 Serverless 엔드포인트로 배포.
로그 모니터링과 실행 중인 워커 SSH 디버깅.
엔드포인트 설정을 조정해 성능·비용 최적화.
엔드포인트 로직을 갱신해야 하면 1번으로 돌아가 반복.

RunPod Serverless 개요