LLM과 멀티모달 모델이 대중화되면서 GPU 수요는 “늘었다” 수준이 아니라 폭발했습니다. 문제는 많은 팀이 여전히 고정 GPU 인스턴스(EC2/GKE의 상시 구동 GPU 노드) 중심으로 AI 서비스를 운영한다는 점입니다. 겉보기엔 가장 단순한 선택처럼 보이지만, 최근의 AI 워크로드 특성과 정면으로 충돌하면서 한계가 빠르게 드러나고 있습니다.
GPU 수요는 폭증했는데, 실제 트래픽은 ‘항상 바쁘지’ 않다
LLM/GenAI 서비스의 요청 패턴은 전통적인 웹 서비스와 비슷해 보이면서도 훨씬 극단적입니다.
- 트래픽이 들쭉날쭉(bursty)합니다. 캠페인, 푸시, 특정 시간대(업무 시작/종료), 기능 릴리스 직후에 요청이 갑자기 튀고, 나머지 시간엔 조용해집니다.
- 하지만 모델은 무겁습니다. 한 번 호출될 때마다 VRAM을 크게 점유하고, 토큰 생성/디코딩 과정에서 GPU를 강하게 씁니다.
- 동시에, 대부분의 서비스는 하루 24시간 내내 GPU를 100%로 ‘꾸준히’ 쓰지 않습니다. 즉, “필요할 때는 매우 비싸고, 필요 없을 때는 놀고 있는” 자원이 됩니다.
이 구조에서 고정 GPU 인스턴스를 상시로 켜두면, 피크를 견디기 위해 미리 크게 잡아둔 GPU가 비피크 시간에 유휴 상태로 남는 시간이 길어집니다. GPU는 대표적인 고가 자원이라, 유휴 시간이 곧바로 비용 낭비로 직결됩니다.
고정 GPU 인스턴스가 한계에 부딪히는 이유: 비용과 운영의 이중 압박
전통적인 방식의 핵심 문제는 두 가지입니다.
1) 비용 구조가 트래픽 현실과 맞지 않는다
고정 GPU 인스턴스는 기본적으로 인스턴스를 켜놓는 시간에 비용이 매입니다. 요청이 없어도, GPU가 놀고 있어도, 과금은 계속됩니다. 특히 LLM처럼 “요청당 비용”이 큰 워크로드에서는 다음이 자주 발생합니다.
- 피크 대비로 용량을 확보 → 평소엔 유휴 비용 증가
- 유휴 비용을 줄이려 용량을 줄임 → 피크에서 지연/장애 위험 증가
즉, 비용 최적화와 성능 안정성 사이에서 지속적으로 트레이드오프를 강요받습니다.
2) 운영 난이도가 급격히 올라간다
GPU 기반 서비스는 CPU 서비스보다 운영 변수가 많습니다.
- GPU 노드 프로비저닝 및 드라이버/런타임(CUDA 등) 관리
- 오토스케일링 정책(특히 피크 대응) 설계
- 배포, 롤백, 모니터링, 장애 대응
- 모델 로딩 시간/메모리(VRAM) 압박에 따른 워커 구성 최적화
Kubernetes로 잘 운영하던 팀도, GPU 워크로드에서는 “그냥 클러스터에 올리면 끝”이 되기 어렵습니다. 결과적으로 AI 기능을 빠르게 실험하고 제품화해야 하는 시점에, 인프라 운영이 발목을 잡는 경우가 많습니다.
그래서 Serverless GPU가 떠오른다: “필요할 때만 GPU를 쓰는” 실행 모델
여기서 등장하는 해법이 Serverless GPU입니다. 핵심은 단순합니다.
- 요청이 있을 때만 GPU 워커가 올라오거나 할당되고
- 요청이 없으면 scale to zero로 내려가며
- 비용은 보통 실제 실행 시간(초 단위) 중심으로 청구됩니다.
즉, “GPU를 소유/상시 임대”하는 관점에서 벗어나, 함수/엔드포인트 단위로 GPU를 호출해 쓰는 방식으로 바뀌는 것입니다. 이 모델은 특히 다음 상황에서 효과가 큽니다.
- 트래픽이 불규칙하고, 유휴 시간이 길다
- 서비스는 빠르게 만들어야 하는데 인프라 운영 여력이 부족하다
- PoC/프로토타입을 자주 만들고 버리는 조직이다
현실적인 단서: cold start가 비용 절감의 대가가 될 수 있다
Serverless가 만능은 아닙니다. 요청이 없으면 내려가야 비용이 줄어드니, 다시 요청이 들어올 때 cold start(컨테이너/모델 로딩으로 인한 초기 지연)가 발생할 수 있습니다. GPU 서버리스에서는 이 지연이 CPU 기반 Serverless보다 더 커질 수 있습니다(모델 크기, VRAM 로딩, 의존성 초기화 때문).
따라서 “왜 뜨는가?”를 한 문장으로 정리하면 이렇습니다.
- AI 워크로드는 비싸고(고성능 GPU), 불규칙하며(bursty), 빠른 실험이 필요해졌다.
- 고정 인스턴스는 비용/운영 측면에서 이 변화를 따라가기 어렵다.
- 그래서 Serverless GPU처럼 ‘필요할 때만 GPU를 쓰는’ 구조가 급부상하고 있다.
Serverless GPU 플랫폼 핵심 개념: 초 단위 과금·Scale to Zero·Python 함수 배포로 바뀌는 개발 방식
초 단위 과금과 scale to zero, Python 함수 단위 배포까지… Serverless GPU 플랫폼은 “GPU를 빌려 쓰는 방식” 자체를 바꿉니다. 예전처럼 GPU 인스턴스를 오래 켜 두고(유휴 비용을 감수하며) 운영하는 게 아니라, 요청이 들어오는 순간에만 GPU를 붙였다가 일이 끝나면 다시 내려버리는 구조가 핵심입니다. 그 결과 개발자는 인프라 부담에서 벗어나 모델·코드·지연시간 설계에 더 집중할 수 있게 됩니다.
Serverless GPU 플랫폼이 “서버리스”인 이유: GPU를 인프라가 아니라 실행 단위로 다룬다
전통적인 GPU 운영은 보통 다음 흐름입니다: 인스턴스 생성 → 드라이버/런타임 세팅 → 모델 배포 → 오토스케일링/모니터링 구성. 반면 Serverless GPU는 관점을 바꿉니다.
- 개발자는 함수(Function) 또는 엔드포인트(Endpoint)를 배포한다
- 플랫폼이 스케줄링, GPU 할당, 스케일링, 장애 처리를 수행한다
- 결과적으로 “GPU 노드”가 아니라 요청/실행 단위로 리소스가 붙는다
즉, Serverless의 본질은 “서버가 없다”가 아니라 서버를 신경 쓰지 않아도 되게 만드는 실행 모델입니다. GPU도 그 흐름을 그대로 따라오고 있습니다.
초 단위 과금(per-second billing): “GPU 사용 시간”만 비용이 된다
Serverless GPU에서 가장 체감이 큰 변화는 과금 구조입니다.
- 고정 인스턴스: 인퍼런스를 하지 않는 시간에도 시간 단위로 비용 발생
- Serverless GPU: 실제 실행된 시간 기준으로 초 단위에 가깝게 과금
이 구조는 특히 bursty 트래픽(특정 시간에 몰렸다가 잠잠해지는 패턴)에서 효과가 큽니다. 예를 들어 사내 도구, PoC API, 이벤트성 트래픽, 하루 중 일부 시간만 바쁜 서비스는 GPU 사용률이 낮아지기 쉬운데, 이때 “켜진 시간 전체를 과금”하는 방식은 낭비가 커집니다. Serverless는 그 낭비를 구조적으로 줄여 줍니다.
Scale to Zero: 요청이 없으면 0으로 내려 비용을 ‘완전히’ 멈춘다
Serverless GPU 플랫폼은 보통 유휴 상태가 일정 시간 지속되면 워커(컨테이너/런타임)를 내립니다.
- 요청 없음 → 인스턴스/워커가 0으로 축소(scale to zero)
- 요청 발생 → 다시 띄워서 처리
이 덕분에 “항상 최소 1대는 켜 두는 비용”을 없앨 수 있습니다. 다만 여기에는 반드시 따라오는 트레이드오프가 있습니다.
- 워커가 내려간 상태에서 첫 요청이 들어오면 cold start(콜드 스타트)가 발생할 수 있음
- 모델 다운로드/로딩, 컨테이너 기동, GPU 할당 등의 단계로 인해 수 초~수 분까지 지연이 커질 수 있음
따라서 scale to zero는 비용 측면에서 강력하지만, 서비스가 요구하는 지연시간 SLO와 함께 설계해야 합니다.
Python 함수 단위 배포: “서빙 코드” 중심으로 개발 흐름이 단순해진다
Modal 계열로 대표되는 Serverless GPU는 특히 Python-native 경험을 강조합니다. 일반적인 사용 감각은 다음과 같습니다.
- Python으로 inference 함수(입력 → 전처리 → 모델 실행 → 후처리)를 작성
- 필요한 라이브러리/모델 로딩 로직을 함께 정의
- 플랫폼이 이를 실행 가능한 형태로 패키징하고, 요청에 맞춰 GPU에서 실행
여기서 중요한 포인트는, 개발자가 쿠버네티스 디플로이먼트/오토스케일러/노드풀을 직접 만지지 않아도 “함수 단위로 배포·확장”이 가능해진다는 점입니다. 결과적으로 팀은 다음에 집중하게 됩니다.
- 모델 로딩 시간을 줄이는 방식(가중치 캐시, 초기화 최적화)
- VRAM 사용량과 배치/동시성 전략
- cold start를 감당할지, keep-warm 같은 옵션이 필요한지
즉, 운영의 복잡도가 사라지는 만큼 모델 서빙의 성능·비용 최적화가 개발자의 주 관심사로 올라옵니다.
정리: Serverless GPU의 핵심은 “유휴 비용 제거 + 실행 단위 추상화”다
Serverless GPU 플랫폼의 속살을 한 문장으로 요약하면 이렇습니다.
- 필요할 때만 GPU를 붙이고(온디맨드 실행),
- 끝나면 0으로 내려 유휴 비용을 없애며,
- Python 함수/엔드포인트 단위로 배포·확장을 추상화한다.
이 조합이 개발자에게 주는 자유는 분명합니다. 하지만 동시에 cold start, 모델 로딩, 지연시간 목표, 비용 예측(트래픽 프로파일 기반)까지 함께 봐야 “진짜 Serverless”의 효율을 얻을 수 있습니다.
Serverless RunPod Serverless: 실전에서 빛나는 하이브리드 GPU 아키텍처
Serverless와 On-Demand GPU를 동시에 제공하는 RunPod. 같은 플랫폼 안에서 “필요할 때만 GPU를 쓰고(scale to zero), 필요하면 오래 붙잡고 쓰는” 두 세계가 공존합니다. 겉으로는 엔드포인트 하나지만, 내부에서는 꽤 많은 일이 자동으로 굴러가죠. 여기서는 RunPod Serverless를 중심으로 플랫폼 내부에서 어떤 흐름으로 GPU가 붙고 떨어지는지, 그리고 실무에서 어떤 아키텍처로 쓰면 효과가 큰지를 정리해 보겠습니다.
Serverless RunPod의 핵심: “함수 단위 GPU” + “필요하면 On-Demand로 확장”
RunPod의 강점은 단순히 Serverless GPU를 제공하는 데서 끝나지 않습니다. 짧고 들쭉날쭉한 인퍼런스는 Serverless로, 길고 무거운 학습/튜닝이나 지속 서빙은 On-Demand로 자연스럽게 넘길 수 있는 구조가 핵심입니다.
- RunPod Serverless: 함수/엔드포인트 기반 서빙, 요청이 없으면 0으로 축소, 사용한 만큼(초 단위) 과금
- RunPod On-Demand: 전통적인 GPU 인스턴스 임대(장시간 점유), 학습/지속 워커에 적합
이 하이브리드 조합이 좋은 이유는 간단합니다. LLM 서비스는 현실에서 “항상 일정한 부하”보다 갑자기 몰렸다가 사라지는 패턴이 훨씬 흔하고, 동시에 배치 학습·튜닝·오프라인 전처리 같은 장시간 잡도 섞여 있기 때문입니다.
Serverless RunPod 내부에서 벌어지는 일: 요청 1건이 GPU를 붙이는 과정
공식 문서가 내부 구현을 모두 공개하진 않지만, Serverless GPU 플랫폼들이 보통 따르는 실행 흐름은 상당히 유사합니다. RunPod Serverless도 실무 관점에서는 아래 순서로 이해하면 아키텍처 설계가 쉬워집니다.
1) 배포 단계: “모델 코드”를 실행 가능한 런타임으로 고정
- 개발자는 인퍼런스 로직을 함수/컨테이너 형태로 올립니다.
- 플랫폼은 이를 실행 가능한 형태(컨테이너 이미지, 런타임 스펙, 의존성)로 패키징합니다.
- 여기서 이미 성능의 절반이 결정됩니다.
예: 모델 가중치 다운로드 위치, 캐시 전략, 토크나이저 로딩 방식, GPU 메모리 할당 방식 등
2) 요청 유입: 라우팅 → 스케줄링 → GPU 워커 할당
요청이 들어오면 플랫폼은 내부적으로 “이 요청을 어느 GPU에서 실행할지”를 결정해야 합니다.
- Warm 워커가 있으면: 즉시 할당(지연이 짧음)
- 없으면: 새 워커를 띄우며 cold start 발생
- 컨테이너 풀/이미지 풀링
- GPU 노드 확보 및 컨테이너 실행
- 모델 로딩(가중치 로드, 그래프 초기화, KV cache 준비 등)
이 구간이 Serverless GPU의 가장 큰 트레이드오프입니다. 즉, 비용은 아끼지만(필요할 때만 GPU), 초기 지연이 생길 수 있다는 점을 받아들여야 합니다.
3) 실행 단계: 동시성(Concurrency)과 배치(Batching)의 게임
GPU 인퍼런스 비용 효율은 “GPU를 얼마나 바쁘게 만들었는가”로 결정됩니다. RunPod 같은 Serverless 환경에서는 다음 설계를 고민하게 됩니다.
- 동시 요청을 한 워커에 얼마나 태울지(동시성)
- 짧은 시간 창에서 요청을 묶어 처리할지(마이크로 배칭)
- 스트리밍 응답 여부(스트리밍은 UX에 좋지만 워커 점유 시간이 길어질 수 있음)
결국 목표는 단순합니다. 사용자 지연을 무너뜨리지 않는 선에서 GPU utilization을 올리는 것입니다.
4) 유휴 처리: scale to zero로 비용 최적화
요청이 끊기면 워커는 일정 조건에서 내려갑니다.
- 워커 종료 → GPU 반환 → 비용 정지(또는 최소화)
- 다음 요청 때는 다시 cold start 가능
이 “내려가는 순간”이 곧 Serverless의 비용 절감 포인트입니다. 반대로 트래픽이 계속 있는 서비스라면, scale to zero가 오히려 불리해질 수 있어 On-Demand나 상시 워커 전략이 필요해집니다.
Serverless RunPod을 실무에 맞게 쓰는 아키텍처 패턴 3가지
패턴 A: Bursty LLM API(낮은 평균 QPS, 높은 피크) — Serverless 정석
- 평소 트래픽이 낮고 이벤트성으로 튀는 제품(데모, 내부 도구, 기능 실험)
- Serverless 엔드포인트로 바로 노출
- 관건: cold start를 UX로 흡수
- “답변 생성 준비 중” 같은 상태 표시
- 첫 토큰 지연(TTFT)을 SLA에서 분리 설계
패턴 B: “Serverless 프론트” + “On-Demand 백그라운드” 혼합
- 실시간 요청은 Serverless로 받고
- 무거운 작업(재랭킹, 문서 대량 임베딩, 배치 요약, 학습/튜닝)은 On-Demand 워커/파이프라인으로 분리
장점:
- 사용자-facing 경로는 운영이 단순해지고
- 비용이 큰 배치 작업은 긴 작업에 유리한 실행 모델로 가져갈 수 있습니다.
패턴 C: 온디맨드로 기준 성능 확보 + Serverless로 피크 흡수(스파이크 버퍼)
- 기본 트래픽은 On-Demand로 안정적으로 처리(지연 최소화)
- 갑작스러운 스파이크는 Serverless 엔드포인트로 흡수
이 접근은 “늘 빠른 응답”을 유지하면서도, 피크 대비를 위해 GPU를 24/7로 과잉 보유하는 문제를 줄입니다.
Serverless RunPod 설계 시 체크리스트: “마법”이 아니라 “변수”를 관리하는 일
RunPod Serverless를 안정적으로 쓰려면 아래 변수를 미리 잡아야 합니다.
- cold start 예산: 우리 서비스는 첫 응답까지 몇 초까지 허용 가능한가?
- 모델 로딩 전략: 가중치/토크나이저/런타임 초기화를 어디까지 줄였는가?
- GPU SKU 선택: H100이 필요한지, A100/4090/L4급으로 충분한지(성능 vs 비용)
- 동시성 한도: 한 워커에 몇 요청까지 태울 때 품질/지연이 깨지는가?
- 비용 산정 방식: “월 호출 수 × 평균 실행 시간 × 초당 단가”로 Serverless 비용을 먼저 계산하고, 24/7 On-Demand와 역전되는 지점을 확인
결론적으로 RunPod의 하이브리드 구조는 “Serverless로 시작해서, 필요할 때 On-Demand로 확장”하기에 좋습니다. 중요한 건 플랫폼이 아니라, 트래픽 프로파일과 지연 목표에 맞춰 두 실행 모델을 어떻게 섞을지입니다.
Serverless GPU: 언제, 어떤 워크로드에 선택해야 할까?
트래픽이 들쭉날쭉하고 “피크 때만” GPU가 많이 필요하다면, 고정 GPU 인스턴스를 24/7로 켜두는 방식은 비용과 운영 부담이 빠르게 커집니다. 이럴 때 Serverless GPU는 빠른 확장 + 유휴 시간 비용 최소화라는 두 가지 요구를 동시에 만족시키는 선택지가 될 수 있습니다. 다만 모든 상황에 정답은 아니어서, 아래처럼 명확한 가이드라인으로 판단하는 것이 현실적입니다.
Serverless GPU가 특히 잘 맞는 경우 (선택 신호)
아래 조건에 많이 해당될수록 Serverless에 유리합니다.
트래픽이 bursty(스파이크형)
이벤트/캠페인/업무 시간대에만 요청이 몰리고, 나머지 시간은 한산한 패턴이라면 scale to zero의 효과가 큽니다. 요청이 없을 때 리소스가 내려가면, 유휴 GPU 비용을 구조적으로 줄일 수 있습니다.워크로드가 stateless에 가깝다
각 요청이 독립적이고(예: 텍스트 요약, 이미지 생성, RAG 질의응답), 장시간 세션을 유지하지 않는다면 Serverless 모델(함수/엔드포인트 단위 실행)에 자연스럽게 들어맞습니다.cold start 지연을 SLO로 감당할 수 있다
Serverless GPU는 요청이 다시 들어올 때 컨테이너/모델 로드가 발생해 수 초~수 분의 cold start가 생길 수 있습니다.- “첫 요청이 느릴 수 있음”을 허용하거나
- keep-warm, 최소 워커 유지 같은 옵션을 쓰거나
- 사용자 경험 상 첫 응답 지연을 흡수할 장치(로딩 UI, 비동기 처리)가 있다면
Serverless 선택 가능성이 올라갑니다.
짧은 실행이 자주 발생한다(특히 30분 미만 작업이 많다)
초 단위 과금 모델의 장점은 “짧게 자주” 돌릴수록 커집니다. 반대로 장시간 점유가 많아지면 on-demand/bare-metal이 더 싸질 가능성이 높습니다.인프라 운영을 최소화해야 한다(Zero infra management)
Kubernetes/GPU 노드 관리/오토스케일링/드라이버 호환성/배포 파이프라인까지 직접 안고 가기 어렵다면, Serverless는 “코드와 모델”에 집중하게 해주는 쪽으로 가치를 줍니다.
