서버리스 GPU에 LLM 배포: 5개 플랫폼, 실제 가격, 정직한 콜드 스타트

서버리스 GPU에 LLM 배포: 5개 플랫폼, 실제 가격, 정직한 콜드 스타트

RunPod은 A100 80GB에 시간당 $2.72를 청구합니다. 점심시간까지 엔드포인트에 들어온 요청은 열두 건뿐입니다. 나머지 23시간 동안 GPU는 놀면서도 계속 과금됩니다. 서버리스 GPU에 LLM을 배포하면 요청이 실행되는 동안에만 비용을 냅니다. 이런 플랫폼은 다섯 곳입니다. 그리고 다섯 곳이 다섯 가지 다른 단위로 요금을 매깁니다. 아무도 이걸 같은 기준으로 정리해 주지 않습니다.

놀고 있는 GPU는 일하는 GPU와 정확히 같은 비용이 듭니다.

핵심 요약

• 서버리스 GPU는 요청이 실행되는 동안만 과금되고, 요청 사이에는 0으로 스케일됩니다.
• Cloud Run은 인스턴스당 GPU 1개. 70B 모델은 멀티 GPU가 필요하므로 서버리스로는 보통 호스팅할 수 없습니다.
• 모델 웨이트는 이미지에 포함하거나, 네트워크 볼륨에 두거나, 콜드 스타트마다 다시 다운로드합니다.
• 콜드 스타트는 세 가지로 구성됩니다: 컨테이너 부팅, 웨이트 로딩, 엔진 초기화. 빠른 것은 첫 번째뿐입니다.
• 하루 약 47,000건 미만이라면 scale-to-zero가 24/7 임대 GPU보다 저렴합니다.

LLM에게 '서버리스 GPU'란 실제로 무엇을 의미할까?

서버리스 GPU 플랫폼은 공유 GPU 하드웨어에서 추론 컨테이너를 실행하고, 요청이 도착하면 컨테이너를 띄우며, 트래픽이 끊기면 0으로 스케일합니다. 컨테이너가 살아 있는 동안에만 초 단위(또는 벤더에 따라 분 단위, 시간 단위)로 과금됩니다. 유휴 요금도, 예약 인스턴스도 없습니다.

과금 단위는 벤더마다 다릅니다. 그래서 다음 섹션에서 모든 가격을 $/GPU시간으로 통일했습니다.

두 가지 제약이 사람들을 놀라게 합니다. 첫째, Google Cloud Run은 인스턴스당 GPU를 최대 1개까지 허용합니다. VRAM 상한이 카드 한 장으로 막히는 셈입니다. 둘째, '서버리스'는 영구적인 상태를 의미하지 않습니다. 요청 사이에 웨이트를 RAM에 유지해 주는 장수 프로세스 같은 것은 없습니다. 컨테이너가 죽으면 메모리에 있던 모든 것도 함께 사라집니다. 바로 이 사실 하나가 아래 모델 웨이트 섹션의 스토리지 결정을 좌우합니다.

서버리스는 서버가 없다는 뜻이 아닙니다. 요청 사이에는 서버가 없다는 뜻이고, 바로 그 틈에서 모델 웨이트가 사라집니다.

어떤 서버리스 GPU 플랫폼을 골라야 할까? (2026년 가격, 나란히 비교)

이 플랫폼들은 어느 것과도 제휴 관계가 없고, 어디서도 제휴 수익을 받지 않습니다. 이 검색어와 유사어로 경쟁하는 글 일곱 개 중 네 개는 서버리스 GPU를 파는 회사가 발행했습니다. 이 표는 그렇지 않습니다.

모든 요금은 2026년 7월 30일에 각 벤더의 가격 페이지에서 직접 확인했습니다. 요금은 바뀌므로, 결정 전에 다시 확인하세요.

한 번만 보여 드리는 환산 계산입니다. 직접 검증해 보세요. Modal A100 80GB는 $0.000694/초에 3600초를 곱하면 $2.4984/시간입니다. Beam은 $0.000625에 3600을 곱하면 $2.25/시간. Baseten은 $0.06667/분에 60을 곱하면 $4.00/시간입니다. 같은 A100인데 Beam과 Baseten 사이에 1.8배 차이가 납니다. 실제로 존재하는 격차지만, 같은 단위로 공개하는 벤더가 하나도 없어서 눈에 띄지 않을 뿐입니다.

주의할 점 세 가지. Beam은 가격 페이지에서 서버 시작(spin-up)과 컨테이너 이미지 로딩에는 과금하지 않는다고 명시합니다. Baseten의 가격 FAQ는 'Baseten에서 유휴 시간에도 비용을 내나요?'라는 질문에 '아닙니다. 유휴 시간에는 과금하지 않습니다'라고 답한 뒤, 과금 시간을 '모델이 활발하게 배포되거나, 스케일 업/다운되거나, 예측을 수행하는 시간'이라고 덧붙입니다. 즉 계량기가 예측 시간보다 더 많은 것을 커버하므로, 예산을 짤 때는 이 부분을 염두에 둬야 합니다. RunPod은 가격 페이지에 시간당 요금만 공개하고 콜드 스타트 수치는 공개하지 않습니다.

Modal을 선택했다면, Modal 전체 배포 가이드를 별도로 작성해 두었습니다.

내 모델이 들어가기나 할까? VRAM, 단일 GPU 제한, 쿼터

70B 모델을 서버리스 GPU에서 돌릴 수 있을까요? 보통은 불가능합니다. FP16에서 70B는 약 140 GB의 VRAM이 필요합니다. Cloud Run은 인스턴스당 GPU 1개가 상한입니다(RTX PRO 6000 기준 최대 96 GB). 양자화(FP8/GGUF)나 멀티 GPU 플랫폼 없이는 계산이 맞지 않습니다.

Cloud Run의 기본 쿼터는 리전당, 프로젝트당 L4 GPU 3개입니다(RTX PRO 6000은 3,000 milliGPU로 별도로 부여). L4 리전은 여섯 곳입니다: asia-southeast1, asia-south1, europe-west1, europe-west4, us-central1, us-east4. 유럽에서의 서버리스 GPU를 묻는 분들에게 이것이 Cloud Run 쪽 데이터 거주성 답변의 절반입니다. Modal과 RunPod은 자체 EU 리전을 문서화해 두었고, 나머지 절반은 FAQ에 있습니다.

Ismaili Simba의 dev.to Cloud Run 가이드(2025년 4월)에 따르면 쿼터 요청은 '승인까지 시간이 좀 걸릴 수 있습니다(최대 영업일 기준 5일)'. 그리고 'Cloud Run에서 사용 가능한 L4 GPU에는 16GB RAM 제한이 있습니다.' 이 지연까지 감안해서 계획하세요.

모델별 VRAM 용량 산정이 필요하면 LLM VRAM 요구사항 가이드를 참고하세요.

모델 웨이트는 어디에 두고, 비용은 얼마일까?

2024년 11월의 Reddit 스레드는 우리가 2026년 7월 30일에 확인했을 때 이 검색어로 여전히 Google 5위에 있었습니다. 질문은 토씨 하나 안 다르고 이렇습니다:

"80GB 모델을 저장하는 요금을 찾을 수가 없습니다… API 호출마다 모델을 다운로드하고 싶지 않다면 대안이 뭘까요? (호출 시 pod가 프로비저닝됐다가 종료됩니다) … 왜 이 플랫폼들은 모델 스토리지 비용을 공개하지 않나요?"

답변은 세 개, 모두 낮은 점수이고, 어느 것도 답이 아닙니다. 2026년 7월 30일에 같은 검색을 돌렸을 때 상위 10개 결과에는 모델 스토리지 비용이 얼마인지 묻는 이 2년 된 스레드가 여전히 포함되어 있었습니다. 스레드 안에서 아무도 답하지 않았습니다. 그런데 두 플랫폼 모두 요금을 공개하고 있습니다. Modal은 GiB당 월 $0.09이며 첫 1 TiB는 무료입니다. 즉 80 GB 체크포인트의 요금은 $0.00입니다. RunPod은 1 TB 미만 네트워크 스토리지가 GB당 월 $0.07이므로 같은 체크포인트가 월 약 $5.60입니다.

세 번째 행이 바로 실패 모드입니다. ServerlessLLM에 대한 2024년 TU München 리뷰(arXiv 2411.15664)에 따르면 LLaMA-2-70B(130 GB)는 5 GB/s로 다운로드하는 데 26초 이상, GPU 8장에 로딩하는 데 약 84초가 걸리며, 토큰 생성 자체는 약 100 ms입니다. 이 수치들은 해당 리뷰에서 인용된 것이지 리뷰가 직접 측정한 것이 아닙니다.

RunPod 가격 페이지에는 Storage 섹션이 있습니다: 컨테이너 디스크 $0.10/GB/월, 볼륨 디스크는 실행 중 $0.10/GB/월, 유휴 시 $0.20/GB/월, 네트워크 스토리지는 1 TB 미만 $0.07/GB/월, 초과 시 $0.05/GB/월, 고성능 네트워크 스토리지 $0.14/GB/월. 숫자는 존재합니다. 다만 독자가 이 질문을 떠올리는 순간 비교하고 있을 GPU당 서버리스 요금 옆에도, 엔드포인트 설정 흐름 안에도 없다는 것뿐입니다. 은폐의 문제가 아니라 발견 가능성의 문제이고, 그 때문에 이 질문은 2년 뒤에도 여전히 살아 있습니다.

# Point the Hugging Face cache at a mounted network volume
# so weights persist across cold starts (RunPod / Modal pattern)
export HF_HOME=/workspace/hf-cache
export TRANSFORMERS_CACHE=/workspace/hf-cache
export HF_HUB_ENABLE_HF_TRANSFER=1

# Alternative: bake weights into the image at build time
FROM vllm/vllm-openai:latest
COPY ./model-weights /models/qwen3-27b-fp8
ENV MODEL_NAME=/models/qwen3-27b-fp8
# Downside: 30+ GB image, full rebuild to change models

아직 모델을 정하지 못했다면, 2026년 오픈 웨이트 모델 라운드업에서 각 옵션의 배포 요구 용량을 정리해 두었습니다.

배포 실전: RunPod 서버리스에서 vLLM을 엔드투엔드로

제로에서 호출 가능한 엔드포인트까지 여섯 단계입니다. 각 단계는 RunPod의 vLLM 절차(2026년 6월 22일 업데이트)와 대조해 검증하세요. 이 글에는 가격이 공개되어 있지 않습니다.

1. 모델을 고릅니다. GPU에 맞는 크기의 오픈 웨이트 모델을 선택합니다(위 VRAM 표 참고). Hugging Face에서 접근 제한이 걸린 모델이라면 먼저 액세스 토큰을 발급받으세요.

2. 서버리스 엔드포인트를 만듭니다. RunPod 콘솔에서 Serverless를 선택하고, vLLM 워커 템플릿을 고른 뒤, GPU 등급을 선택합니다.

3. 중요한 환경 변수를 설정합니다.

MODEL_NAME=Qwen/Qwen3.6-27B-FP8
MAX_MODEL_LEN=32768
GPU_MEMORY_UTILIZATION=0.90
DTYPE=auto

MODEL_NAME이 잘못되면 부팅 시 404가 납니다. MAX_MODEL_LEN을 VRAM보다 너무 높게 잡으면 첫 토큰 전에 OOM이 발생합니다. GPU_MEMORY_UTILIZATION을 0.95 이상으로 올리면 KV 캐시 급증에 대비할 여유가 사라집니다.

1. 최소/최대 워커와 유휴 타임아웃을 설정합니다. 최소 워커 0은 scale-to-zero(그리고 콜드 스타트)를 의미합니다. 최소 워커 1은 콜드 스타트를 없애지만 계속 과금됩니다. 아래 콜드 스타트 섹션에서 이 트레이드오프를 자세히 다룹니다.

2. 네트워크 볼륨을 연결합니다. 모델 웨이트 섹션에서 정한 방식대로 볼륨을 붙이거나, 이미지 포함 방식을 받아들입니다. 이 단계를 건너뛰면 콜드 스타트마다 체크포인트를 다시 다운로드합니다.

3. 첫 요청을 쏩니다. 콘솔에서 엔드포인트 ID를 확인하고 토큰이 돌아오는지 확인합니다.

curl -X POST "https://api.runpod.ai/v2/${ENDPOINT_ID}/runsync" \
  -H "Authorization: Bearer ${RUNPOD_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "input": {
      "messages": [{"role": "user", "content": "Explain cold starts in one sentence."}],
      "max_tokens": 60
    }
  }'

서빙 엔진 자체를 저울질하고 있다면, vLLM과 SGLang을 처리량과 지연 시간 기준으로 비교한 글이 있습니다.

앱에서 엔드포인트를 어떻게 호출할까?

후보에 오른 플랫폼은 모두 OpenAI 호환 API를 지원합니다. Python 스니펫 하나로 어디서나 동작합니다. 프로바이더를 바꾸는 것은 코드 재작성이 아니라 base_url 한 줄 변경입니다. 그러면 '어떤 프로바이더?'라는 질문은 록인 결정에서 설정 결정으로 바뀝니다.

import os

from openai import OpenAI

ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]

client = OpenAI(
    base_url=f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
    api_key=os.environ["RUNPOD_API_KEY"],
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.6-27B-FP8",
    messages=[{"role": "user", "content": "What is scale to zero?"}],
    max_tokens=120,
)
print(response.choices[0].message.content)

# Same code, different provider. One line changes.
ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]

PROVIDERS = {
    "runpod": f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
    "modal": "https://your-app--your-func.modal.run/v1",
    "beam": "https://your-beam-endpoint/v1",
}

client = OpenAI(base_url=PROVIDERS["modal"], api_key="your-key")

모든 프로바이더가 OpenAI의 방언을 구사한다면, '어떤 서버리스 GPU 프로바이더?'는 더 이상 아키텍처 결정이 아니라 설정 한 줄이 됩니다.

엔드포인트가 여러 개가 되면, LLM 게이트웨이 비교 글에서 라우팅과 페일오버를 다룹니다. 더 가벼운 구성을 원한다면 LiteLLM 프록시로 재시도와 로깅을 추가할 수 있습니다.

콜드 스타트는 실제로 얼마나 걸릴까?

서버리스 GPU의 7B 모델이라면, 완전한 콜드 스타트(컨테이너 부팅 + 웨이트 로딩 + 엔진 초기화)에 1030초를 예상하세요. 실무자 보고 기준입니다. 벤더 문서는 컨테이너 부팅만으로 15초를 제시합니다. 이 두 숫자 사이의 간격이 바로 네트워크를 건너는 체크포인트의 무게입니다.

RunPod 제품 페이지는 200 ms 미만의 FlashBoot 콜드 스타트를 주장합니다(벤더 주장이지 측정치가 아닙니다). r/LLMDevs의 한 실무자는 이렇게 보고합니다: "제 경험상 콜드 스타트는 좋지 않습니다… 대략 10~30초 정도라고 말하겠네요". 그리고 덧붙입니다. "다만 제 경험의 대부분은 diffusion 모델 중심입니다." 둘 다 사실입니다. 서로 다른 것을 재고 있을 뿐입니다.

콜드 스타트 수치는 세 숫자가 쌓인 것입니다:

1. 컨테이너 부팅. Modal 문서: "컨테이너는 약 1초 만에 부팅됩니다." Cloud Run: 드라이버가 사전 설치된 인스턴스는 "약 5초 안에 시작됩니다."

2. 웨이트 로딩. 아무도 광고하지 않는 부분입니다. ServerlessLLM에 대한 2024년 TU München 리뷰(arXiv 2411.15664)는 LLaMA-2-70B가 다운로드에 26초 이상, GPU 8장 로딩에 약 84초가 걸린다고 제시합니다.

3. 엔진 초기화. vLLM 그래프 캡처와 웜업입니다. Logesh Umapathi가 측정한 결과에 따르면 A100-80GB에서 Qwen3.6-27B-FP8는 베이스라인 460초에서 eager 모드 적용 시 219초, vLLM sleep 모드와 Modal GPU 스냅샷을 더해 약 70초까지 내려갑니다. 6.5배 개선이며, 2026년 5월 17일에 공개되었습니다.

공개된 데이터에 대한 우리의 해석은 이렇습니다. 벤더 수치는 컨테이너를 잽니다. 실무자 수치는 요청 전체를 잽니다. 그 두 스톱워치 사이에 80 GB 웨이트가 네트워크를 건너는 시간이 있습니다. 유형 열이 바로 핵심입니다.

할 수 있는 것: vLLM sleep 모드, GPU 스냅샷, 그리고 스케일다운 윈도우 튜닝. Modal의 기본 유휴 시간은 60초입니다(2초~20분 사이 설정 가능). 워머 워커는 콜드 스타트를 없애지만 항상 켜진 상태로 과금됩니다.

# Modal scaledown config (illustrative)
# A 60s window means you pay for 60 idle seconds per burst.
# A warm worker (min_containers=1) costs ~$2.50/hr on A100 80GB, 24/7.
@app.function(
    gpu="A100",
    scaledown_window=60,  # seconds idle before shutdown
    # min_containers=1,   # uncomment to kill cold starts; costs $60/day
)

서버리스 GPU가 항상 켜둔 GPU보다 저렴할까?

서버리스 GPU는 GPU가 하루 대부분을 놀 때 더 저렴합니다. A100 80GB에서 하루 3,000건, 건당 평균 2초라면, 서버리스는 하루 약 $4.17인 반면 24/7 임대 GPU는 하루 $65.28입니다. 교차점은 물량의 문제가 아니라 가동률(duty cycle)의 문제입니다.

가정(우리가 설정한 것이며, 직접 다시 계산해 볼 수 있게 밝힙니다): A100 80GB는 Modal의 $2.50/시간, 요청당 평균 GPU 시간 2초, 임대 GPU는 RunPod의 $2.72/시간으로 24시간 가동, 호스팅 토큰 API는 토큰 100만 개당 $0.40(중간대 공개 요금), 요청당 약 1,000 토큰.

교차점은 하루 약 47,000건에서 형성됩니다. 그 이하면 서버리스가 이깁니다. 호스팅 토큰 API는 범용 모델 기준 저물량 구간에서 둘 다 이깁니다. 손익분기점은 요청 수가 아니라, GPU가 아무 일도 하지 않는 시간이 몇 시간인지에 달려 있습니다.

BentoML의 2024년 8월 분석은 이 트레이드오프를 잘 정리했지만, 가격 예시가 GPT-3.5-turbo 시대 것이라 2년이 지났습니다.

내 물량에서 호스팅 토큰 API 비용이 얼마인지 궁금하다면 LLM API 가격 비교 글을 참고하세요. 추론 쪽에서 요청당 비용을 줄이려면, 프롬프트 캐싱이 반복되는 컨텍스트에서 보통 30-60%를 절약해 줍니다.

# Break-even calculator: adjust these and re-run
REQUESTS_PER_DAY = 3000
SECONDS_PER_REQUEST = 2
SERVERLESS_RATE_HR = 2.50   # Modal A100 80GB
RENTED_RATE_HR = 2.72       # RunPod A100 80GB, 24/7

serverless_daily = REQUESTS_PER_DAY * SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR
rented_daily = RENTED_RATE_HR * 24

print(f"Serverless: ${serverless_daily:.2f}/day")
print(f"Rented 24/7: ${rented_daily:.2f}/day")
print(f"Crossover: {int(RENTED_RATE_HR * 24 / (SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR))} req/day")

서버리스 GPU가 잘못된 선택인 경우

• 지속적으로 높은 트래픽. 이 요금 기준 하루 약 47,000건을 넘으면 가동률이 뒤집혀서, 임대 GPU의 요청당 비용이 더 저렴합니다.
• 콜드 경로에서의 엄격한 서브초 SLO. 어떤 스냅샷 트릭도 첫 요청을 즉시로 만들지 못합니다. 워머 워커를 유지하거나 박스를 임대하세요.
• 멀티 GPU가 필요한 70B 이상 모델. Cloud Run의 인스턴스당 GPU 1개 제한에서 그 대화는 끝납니다.
• 엄격한 데이터 거주성. Cloud Run에서 L4 리전 여섯 개가 메뉴의 전부입니다.
• 이미 비용을 내고 있는 워커 슬롯에 밀리는 요청당 경제성. 남는 GPU 여유가 있다면, 추론을 추가하는 데 드는 추가 비용은 없습니다.

GPU가 하루 열여섯 시간을 바쁘게 돌아가고 있다면, 서버리스가 비싼 선택지입니다. 그리고 그렇지 않다고 말하는 사람은 서버리스를 팔고 있는 것입니다.

로컬 우선 경로가 궁금하다면 로컬 LLM 도구 가이드를 참고하세요.

저자 소개

Mert Batur는 Techsy.io의 공동 창업자로, 팀은 B2B 고객을 위한 AI 에이전트, 자동화 시스템, 음성/SDR 파이프라인을 구축합니다. Techsy 팀이 실제로 프로덕션에서 사용하는 LLM 도구 스택에 대해 씁니다. LinkedIn에서 연결하세요.

자주 묻는 질문

서버리스 GPU란 무엇인가요?

서버리스 GPU 플랫폼은 공유 하드웨어에서 모델 컨테이너를 실행하고, 요청 사이에는 0으로 스케일하며, 활성 컴퓨팅에만 과금합니다. 영구적인 GPU 인스턴스를 관리하지 않고도 추론 엔드포인트를 얻습니다. 트레이드오프는 시작 시 콜드 스타트 지연입니다.

서버리스 GPU에서 LLM을 실행하는 비용은 얼마인가요?

A100 80GB는 Beam에서 $2.25/시간, Modal에서 $2.50/시간, RunPod에서 $2.72/시간입니다(2026년 7월 30일 검증). 청구액은 가동률에 달려 있습니다: 하루 3,000건, 건당 2초라면 Modal에서 하루 약 $4입니다. 스토리지는 GiB당 월 $0.09가 추가되며 1 TiB는 무료입니다.

모델 웨이트 저장에도 비용을 내나요?

네. 하지만 저렴합니다. Modal은 GiB당 월 $0.09를 청구하며 월 1 TiB까지 무료이므로, 80 GB 체크포인트는 비용이 들지 않습니다. RunPod 가격 페이지는 1 TB 미만 네트워크 스토리지를 GB당 월 $0.07로 명시하며, 같은 80 GB라면 월 약 $5.60입니다.

요청할 때마다 모델을 다시 다운로드하나요?

캐시된 것이 없을 때만 그렇습니다. 영구 볼륨에 있거나 이미지에 포함된 웨이트는 콜드 스타트에서 살아남습니다. Hugging Face 캐시를 임시 스토리지로 향하게 두면 130 GB 모델을 시작할 때마다 다시 다운로드합니다. 이것이 피해야 할 실패 모드입니다.

7B 모델의 콜드 스타트는 얼마나 걸리나요?

실무자 보고(r/LLMDevs, 2024년 12월) 기준 완전한 콜드 스타트에 10-30초를 예상하세요. 컨테이너는 1-5초 안에 부팅됩니다(Modal, Cloud Run 문서). 나머지는 웨이트 로딩과 엔진 초기화입니다. 스냅샷과 sleep 모드를 쓰면 Umapathi는 27B 모델에서 460초에서 약 70초로 줄어드는 것을 측정했습니다.

70B 모델을 서버리스 GPU에서 돌릴 수 있나요?

보통은 불가능합니다. FP16의 70B 모델은 약 140 GB의 VRAM이 필요합니다. Cloud Run은 인스턴스당 GPU 1개를 허용합니다(최대 96 GB). 80 GB 카드 한 장에 맞추려면 FP8 양자화가 필요하거나, 멀티 GPU 플랫폼이 필요합니다. 대부분의 서버리스 환경은 GPU 1개가 상한입니다.

서버리스 GPU가 GPU를 24/7 임대하는 것보다 저렴한가요?

하루 약 47,000건 미만(A100 80GB, 요청당 2초 기준)이라면 그렇습니다. 서버리스는 활성 시간에만 과금하고, 임대 GPU는 무조건 24시간 과금합니다. 그 이상이면 임대 GPU가 이깁니다. 저물량에서는 호스팅 토큰 API가 둘 다 이깁니다. 위 손익분기점 표를 참고하세요.

서버리스 GPU에 LLM을 무료로 배포할 수 있나요?

Modal은 월 $30 무료 크레딧(Starter)을 제공합니다. Beam은 월 $30을 제공합니다. GCP의 신규 계정 $300 크레딧으로 Cloud Run GPU 사용을 충당할 수 있습니다. 프로토타입에는 충분하지만 프로덕션 트래픽을 돌리기에는 부족합니다. GPU 추론에 영구 무료 티어를 제공하는 플랫폼은 없습니다.

유럽에서 사용할 수 있는 서버리스 GPU 프로바이더는 어디인가요?

Cloud Run은 europe-west1(벨기에)과 europe-west4(네덜란드)에서 L4 GPU를 제공합니다. Modal은 EU 리전 선택을 문서화해 두었습니다(eu-west, eu-north, eu-south). 기본 요금의 1.5-1.75배로 책정됩니다. RunPod은 EU-NL-1, EU-FR-1을 포함한 유럽 데이터 센터를 명시합니다. 리전은 명시적으로 고정하세요. 어느 곳도 EU를 기본값으로 두지 않습니다.

서버리스 GPU에 LLM을 배포하는 데 Docker가 필요한가요?

항상 그런 것은 아닙니다. RunPod은 Docker를 건너뛰는 사전 빌드된 vLLM 워커 템플릿을 제공합니다. Modal은 코드의 Python 이미지 정의로 컨테이너를 빌드합니다. 커스텀 의존성이 필요하다면 Dockerfile을 작성하게 됩니다. 표준 vLLM 서빙이라면 사전 빌드 경로로 몇 분 안에 동작합니다.

결론

다섯 플랫폼, 다섯 가지 과금 단위, 하나의 정규화된 표. 결정은 벤더 페이지가 보이게 만드는 것보다 단순합니다:

• GPU는 브랜드가 아니라 VRAM으로 고르세요.
• 모델을 절대 교체하지 않는 경우가 아니라면, 웨이트는 이미지가 아니라 볼륨에 두세요.
• 10-30초 콜드 스타트를 예상하고 그에 맞춰 계획하세요.
• 하루 약 47,000건 미만이라면, 비용에서는 scale-to-zero가 이깁니다.
• 엔드포인트 뒤의 서빙 엔진은 교체 가능합니다. base_url 한 줄이면 됩니다.

이제 호출 가능한 엔드포인트가 있습니다. 다음은? 라우팅과 페일오버가 필요해질 때 그 앞에 무엇을 둘 것인가입니다. LLM 게이트웨이 비교 글이 그 답입니다. 또는 여러분의 구성에 대해 함께 이야기해 봅시다.