Wdrożenie LLM na serverless GPU: 5 platform, realne ceny, uczciwe cold starty

Wdrożenie LLM na serverless GPU: 5 platform, realne ceny, uczciwe cold starty

RunPod kasuje 2,72 $/godz. za A100 80GB. Twój endpoint dostaje dwanaście żądań przed obiadem. Przez pozostałe 23 godziny GPU stoi bezczynnie, a licznik bije cały czas. Wdróż LLM na serverless GPU, a płacisz tylko wtedy, gdy żądanie działa. Pięć platform tak robi. Każda liczy w innej jednostce. Nikt ich nie normalizuje.

Bezczynne GPU kosztuje dokładnie tyle samo co zajęte.

Najważniejsze wnioski

• Serverless GPU nalicza opłaty tylko podczas działania żądania, a między żądaniami skaluje się do zera.
• Cloud Run daje jedno GPU na instancję; modele 70B potrzebują wielu GPU, więc serverless zwykle ich nie utrzyma.
• Wagi modelu siedzą w obrazie, na wolumenie sieciowym albo są pobierane od nowa przy każdym cold starcie.
• Cold start to trzy etapy: uruchomienie kontenera, załadowanie wag, inicjalizacja silnika. Szybki jest tylko pierwszy.
• Poniżej mniej więcej 47 000 żądań dziennie scale-to-zero wygrywa z wynajętym GPU 24/7.

Co właściwie znaczy „serverless GPU" dla LLM?

Platforma serverless GPU uruchamia Twój kontener inferencyjny na współdzielonym sprzęcie GPU, podnosi go, gdy przychodzi żądanie, i skaluje do zera, gdy ruch ustaje. Płacisz za sekundę (albo za minutę, albo za godzinę, zależnie od dostawcy) tylko wtedy, gdy kontener żyje. Zero rachunku za przestój. Zero zarezerwowanej instancji.

Jednostka rozliczeniowa różni się między dostawcami, dlatego następna sekcja normalizuje wszystko do $/GPU-godzinę.

Dwa ograniczenia zaskakują. Po pierwsze, Google Cloud Run pozwala na jedno GPU na instancję, maksymalnie. To ustawia sufit VRAM na poziomie jednej karty. Po drugie, „serverless" nie oznacza trwałego stanu. Nie ma długo żyjącego procesu, który trzyma Twoje wagi w RAM między żądaniami. Gdy kontener umiera, wszystko w pamięci umiera razem z nim. Ten jeden fakt napędza decyzję o storage'u w sekcji o wagach modelu poniżej.

Serverless nie znaczy bez serwera. Znaczy bez serwera między Twoimi żądaniami i dokładnie tam znikają wagi Twojego modelu.

Którą platformę serverless GPU wybrać? (ceny 2026, zestawienie)

Nie sprzedajemy żadnej z tych platform i nie bierzemy z żadnej prowizji afiliacyjnej. Spośród siedmiu artykułów konkurujących o to zapytanie i jego bliskie warianty, cztery opublikowała firma sprzedająca serverless GPU. Ta tabela nie.

Wszystkie stawki spisane z oficjalnych cenników dostawców 30.07.2026. Ceny się zmieniają; sprawdź ponownie, zanim podejmiesz decyzję.

Matematyka normalizacji, pokazana raz, żebyś mógł ją prześledzić: Modal A100 80GB po $0,000694/s pomnożone przez 3600 sekund daje $2,4984/godz. Beam: $0,000625 razy 3600 daje $2,25/godz. Baseten: $0,06667/min razy 60 daje $4,00/godz. Ta 1,8-krotna różnica między Beam a Baseten za to samo A100 jest realna i chowa się na widoku, bo nikt nie publikuje w tej samej jednostce.

Trzy zastrzeżenia. Cennik Beam wprost stwierdza, że nie nalicza opłat za spin-up serwera ani ładowanie obrazu kontenera. FAQ cennika Baseten odpowiada na pytanie „Czy płacę za czas bezczynności w Baseten?" słowami „Nie, nie płacisz za czas bezczynności", po czym dodaje, że czas płatny to „czas, w którym Twój model aktywnie się wdraża, skaluje w górę lub w dół albo generuje predykcje", więc licznik obejmuje więcej niż czas predykcji i właśnie tę część warto budżetować. RunPod publikuje w cenniku stawki godzinowe i żadnej liczby o cold starcie.

Jeśli wybierzesz Modal, napisaliśmy osobny, pełny przewodnik po Modal.

Czy Twój model w ogóle się zmieści? VRAM, limity jednego GPU i quota

Czy da się uruchomić model 70B na serverless GPU? Zwykle nie. W FP16 model 70B potrzebuje ~140 GB VRAM. Cloud Run ma limit jednego GPU na instancję (maksymalnie 96 GB na RTX PRO 6000). Bez kwantyzacji (FP8/GGUF) albo platformy multi-GPU ta matematyka się nie spina.

Domyślna quota w Cloud Run to 3 GPU L4 na region na projekt (RTX PRO 6000 jest przyznawane osobno, jako 3000 milliGPU), w sześciu regionach L4: asia-southeast1, asia-south1, europe-west1, europe-west4, us-central1, us-east4. To jest połowa odpowiedzi o rezydencję danych ze strony Cloud Run dla każdego, kto pyta o serverless GPU w Europie; Modal i RunPod dokumentują własne regiony EU, a resztę znajdziesz w FAQ.

Przewodnik Ismaili Simby po Cloud Run na dev.to (kwiecień 2025) donosi, że wniosek o quotę „może trochę potrwać (do 5 dni roboczych), zanim zostanie zatwierdzony", a „GPU L4 dostępne w Cloud Run mają limit 16 GB RAM". Zaplanuj ten przestój.

Rozmiar VRAM dla poszczególnych modeli znajdziesz w naszym przewodniku po wymaganiach VRAM.

Gdzie mieszkają wagi Twojego modelu (i ile to kosztuje)?

Wątek na Reddicie z listopada 2024, który gdy sprawdzaliśmy 30.07.2026 wciąż siedział na 5. miejscu w Google dla dokładnie tego zapytania, pyta dosłownie:

„Nie udało mi się znaleźć stawki za przechowywanie modelu 80 GB… Jaka jest alternatywa, jeśli nie chcę pobierać modelu przy każdym wywołaniu API (pod podnoszony na żądanie i zamykany)? … Dlaczego te platformy nie podają kosztu storage'u modelu?"

Trzy odpowiedzi z niską punktacją, żadna nie jest odpowiedzią. Gdy uruchomiliśmy to wyszukiwanie 30.07.2026, w pierwszej dziesiątce wyników wciąż był ten dwuletni wątek pytający o koszt storage'u modelu. Nikt w wątku nie odpowiedział. Obie platformy publikują stawkę. W Modalu to $0,09 za GiB miesięcznie, a pierwszy TiB jest darmowy, więc checkpoint 80 GB kosztuje $0,00. W RunPod to $0,07 za GB miesięcznie za storage sieciowy poniżej 1 TB, co dla tego samego checkpointu daje około $5,60 miesięcznie.

Trzeci wiersz to tryb awaryjny. Przegląd ServerlessLLM z TU München z 2024 (arXiv 2411.15664) donosi, że LLaMA-2-70B (130 GB) potrzebuje ponad 26 sekund na pobranie przy 5 GB/s, plus ~84 sekund na załadowanie na 8 GPU, wobec ~100 ms generacji tokenu. Te liczby są w tym przeglądzie cytowane, a nie przez niego zmierzone.

Cennik RunPod ma sekcję Storage: dysk kontenera $0,10/GB/mies., dysk wolumenu $0,10/GB/mies. w działaniu i $0,20/GB/mies. w bezczynności, storage sieciowy $0,07/GB/mies. poniżej 1 TB i $0,05/GB/mies. powyżej, wysokowydajny storage sieciowy $0,14/GB/mies. Liczba istnieje. Tylko że nie siedzi obok stawek serverless za GPU, które czytelnik porównuje, gdy to pytanie przychodzi mu do głowy, ani w przepływie konfiguracji endpointu. Problem ze znajdywalnością, nie z tajnością, i wystarczający, żeby pytanie żyło dwa lata później.

# 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

Jeśli jeszcze nie wybrałeś modelu, nasz przegląd modeli open-weights na 2026 podaje rozmiary każdej opcji pod wdrożenie.

Wdrożenie: vLLM na RunPod Serverless, od A do Z

Sześć kroków od zera do endpointu, który można wywołać. Każdy zweryfikuj z procedurą vLLM od RunPod (aktualizacja 22.06.2026), która nie publikuje cen.

1. Wybierz model. Dobierz model open-weights do swojego GPU (patrz tabela VRAM powyżej). Jeśli model jest gated na Hugging Face, najpierw wygeneruj token dostępu.

2. Utwórz endpoint serverless. W konsoli RunPod wybierz Serverless, wskaż szablon workera vLLM i wybierz poziom GPU.

3. Ustaw zmienne środowiskowe, które mają znaczenie.

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

Błędny MODEL_NAME oznacza 404 przy starcie. MAX_MODEL_LEN ustawiony za wysoko względem VRAM oznacza OOM przed pierwszym tokenem. GPU_MEMORY_UTILIZATION powyżej 0,95 nie zostawia zapasu na skoki KV-cache.

1. Ustaw min./maks. liczbę workerów i idle timeout. Min. workerów na 0 daje scale-to-zero (i cold starty). Min. workerów na 1 zabija cold starty, ale nalicza bez przerwy. Sekcja o cold startach poniżej rozkłada ten kompromis na czynniki.

2. Podłącz wolumen sieciowy, który wybrałeś w sekcji o wagach modelu, albo zaakceptuj ścieżkę wypiekania w obrazie. Jeśli to pominiesz, każdy cold start pobiera checkpoint od nowa.

3. Wyślij pierwsze żądanie. Odczytaj ID endpointu z konsoli i potwierdź, że tokeny wracają.

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
    }
  }'

Jeśli rozważasz sam silnik serwujący, porównaliśmy vLLM i SGLang pod kątem przepustowości i opóźnień.

Jak wywołać endpoint z Twojej aplikacji?

Każda platforma z krótkiej listy mówi API kompatybilnym z OpenAI. Jeden snippet w Pythonie działa wszędzie. Zmiana dostawcy to podmiana base_url, a nie przepisywanie kodu. To zmienia pytanie „który dostawca" z decyzji o przywiązaniu w decyzję konfiguracyjną.

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")

Jeśli każdy dostawca mówi dialektem OpenAI, „który dostawca serverless GPU" przestaje być decyzją architektoniczną, a staje się jedną linią konfiguracji.

Gdy masz już wiele endpointów, nasze porównanie bramek LLM obejmuje routing i failover. Dla lżejszej konfiguracji proxy LiteLLM dokłada ponowienia i logowanie.

Jakiego cold startu naprawdę się spodziewać?

Dla modelu 7B na serverless GPU spodziewaj się 10-30 sekund przy prawdziwym cold starcie (uruchomienie kontenera plus załadowanie wag plus inicjalizacja silnika), sądząc po raportach praktyków. Dokumentacja dostawców podaje 1-5 sekund na samo uruchomienie kontenera. Różnica między tymi liczbami to Twój checkpoint przechodzący przez sieć.

Strona produktowa RunPod obiecuje cold starty FlashBoot poniżej 200 ms (obietnica dostawcy, nie pomiar). Praktyk na r/LLMDevs raportuje: „cold starty w moim doświadczeniu nie są świetne… powiedziałbym ~10-30 s", dodając „ale większość mojego doświadczenia kręci się wokół modeli dyfuzyjnych". Obie strony mają rację. Mierzą różne rzeczy.

Liczba cold startu to trzy złożone liczby:

1. Uruchomienie kontenera. Dokumentacja Modala: „Kontenery uruchamiają się w około sekundę". Cloud Run: instancje z preinstalowanymi sterownikami „startują w około 5 sekund".

2. Załadowanie wag. Część, którą nikt się nie chwali. Przegląd ServerlessLLM z TU München z 2024 (arXiv 2411.15664) podaje dla LLaMA-2-70B ponad 26 sekund pobierania plus ~84 sekund ładowania na 8 GPU.

3. Inicjalizacja silnika. Przechwytywanie grafu i rozgrzewka vLLM. Logesh Umapathi zmierzył dla Qwen3.6-27B-FP8 na A100-80GB zejście z bazowych 460 s do 219 s w trybie eager i do ~70 s z trybem sleep vLLM plus snapshotami GPU Modala. To 6,5 raza, opublikowane 17.05.2026.

Nasza interpretacja opublikowanych danych: liczby dostawców mierzą czas kontenera. Liczby praktyków mierzą całe żądanie. Między tymi dwoma stoperami siedzi 80 GB wag przechodzących przez sieć. Kolumna Typ jest sednem.

Co robić: tryb sleep vLLM, snapshoty GPU i strojenie okna scaledown. Domyślny idle Modala to 60 sekund (konfigurowalne 2 s-20 min). Ciepły worker zabija cold starty, ale liczy się jak zawsze włączony.

# 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
)

Czy serverless GPU jest tańsze niż GPU działające non stop?

Serverless GPU jest tańsze, gdy Twoje GPU stoi bezczynnie przez większą część dnia. Przy 3 000 żądań dziennie o średniej 2 sekundy każde na A100 80GB, serverless kosztuje około $4,17/dzień wobec $65,28/dzień za wynajęte GPU działające 24/7. Punkt przecięcia to kwestia cyklu pracy, a nie wolumenu.

Założenia (nasze, podane, żebyś mógł je przeliczyć): A100 80GB po $2,50/godz. w Modalu, średnio 2 sekundy czasu GPU na żądanie, wynajęte GPU po $2,72/godz. w RunPod przez całą dobę, hostowane API tokenowe po $0,40/1 mln tokenów (stawka ze środka publikowanych widełek) i ~1000 tokenów na żądanie.

Punkt przecięcia wypada około 47 000 żądań dziennie. Poniżej wygrywa serverless. Hostowane API tokenowe bije obie opcje przy małym wolumenie z typowym modelem. Próg rentowności nie zależy od tego, ile żądań dostajesz. Zależy od tego, ile godzin Twoje GPU spędza na nicnierobieniu.

Analiza BentoML z sierpnia 2024 dobrze ujmuje ten kompromis, choć jej przykłady cenowe pochodzą z epoki GPT-3.5-turbo i są o dwa lata nieświeże.

Ile hostowane API tokenowe kosztuje przy Twoim wolumenie, zobacz w naszym porównaniu cen API LLM. Żeby obciąć koszt żądania po stronie inferencji, cache'owanie promptów zwykle oszczędza 30-60% na powtarzanym kontekście.

# 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")

Kiedy serverless GPU to zły wybór

• Utrzymujący się duży ruch. Powyżej ~47 000 żądań dziennie przy tych stawkach cykl pracy się odwraca i wynajęte GPU jest tańsze za żądanie.
• Twarde SLO poniżej sekundy na zimnej ścieżce. Żaden trik ze snapshotami nie sprawi, że pierwsze żądanie będzie natychmiastowe. Trzymaj ciepłego workera albo wynajmij maszynę.
• Modele 70B+ wymagające wielu GPU. Jedno GPU na instancję w Cloud Run kończy tę rozmowę.
• Ścisła rezydencja danych. Sześć regionów L4 to całe menu w Cloud Run.
• Ekonomia pojedynczego żądania, która przegrywa ze slotem workera, za który już płacisz. Jeśli masz wolny zapas GPU, dołożenie inferencji nie kosztuje nic dodatkowo.

Jeśli Twoje GPU jest zajęte szesnaście godzin dziennie, serverless jest opcją drogą i każdy, kto twierdzi inaczej, sprzedaje serverless.

Ścieżkę local-first znajdziesz w naszym przewodniku po narzędziach do lokalnych LLM.

O autorze

Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline'y głosowe/SDR dla klientów B2B. Pisze o stosie narzędzi LLM, którego zespół Techsy naprawdę używa w produkcji. Znajdź go na LinkedIn.

Często zadawane pytania

Czym jest serverless GPU?

Platforma serverless GPU uruchamia kontener Twojego modelu na współdzielonym sprzęcie, skaluje do zera między żądaniami i nalicza tylko za aktywne obliczenia. Dostajesz endpoint inferencyjny bez zarządzania trwałą instancją GPU. Ceną jest opóźnienie cold startu przy podnoszeniu.

Ile kosztuje uruchomienie LLM na serverless GPU?

A100 80GB chodzi po $2,25/godz. w Beam, $2,50/godz. w Modalu i $2,72/godz. w RunPod (zweryfikowane 30.07.2026). Twój rachunek zależy od cyklu pracy: 3 000 żądań dziennie po 2 s każde kosztuje ~$4/dzień w Modalu. Storage dokłada $0,09/GiB/miesiąc, a 1 TiB jest darmowy.

Czy płacę za przechowywanie wag modelu?

Tak, ale to tanie. Modal liczy $0,09/GiB/miesiąc z darmowym 1 TiB/miesiąc, więc checkpoint 80 GB nie kosztuje nic. Cennik RunPod podaje storage sieciowy po $0,07/GB/miesiąc poniżej 1 TB, czyli około $5,60/miesiąc za te same 80 GB.

Czy mój model pobiera się przy każdym żądaniu?

Tylko jeśli nic nie jest zcache'owane. Wagi na trwałym wolumenie albo wypieczone w obrazie przeżywają cold starty. Skieruj cache Hugging Face na ulotny storage, a model 130 GB będzie pobierany przy każdym podniesieniu. To jest właśnie tryb awaryjny, którego trzeba unikać.

Ile trwa cold start modelu 7B?

Spodziewaj się 10-30 sekund przy prawdziwym cold starcie, według raportów praktyków (r/LLMDevs, grudzień 2024). Kontener startuje w 1-5 s (dokumentacja Modala i Cloud Run). Reszta to ładowanie wag i inicjalizacja silnika. Ze snapshotami i trybem sleep Umapathi zmierzył ~70 s dla modelu 27B, w dół z 460 s.

Czy uruchomię model 70B na serverless GPU?

Zwykle nie. Model 70B w FP16 potrzebuje ~140 GB VRAM. Cloud Run pozwala na jedno GPU na instancję (maksymalnie 96 GB). Żeby zmieścić się na jednej karcie 80 GB, potrzebujesz kwantyzacji FP8 albo platformy multi-GPU. Większość platform serverless ma limit jednego GPU.

Czy serverless GPU jest tańsze niż wynajem GPU 24/7?

Poniżej ~47 000 żądań dziennie (przy 2 s/żądanie na A100 80GB) tak. Serverless liczy tylko aktywne sekundy; wynajęte GPU liczy 24 godziny niezależnie. Powyżej wygrywa wynajęte GPU. Hostowane API tokenowe bije obie opcje przy małym wolumenie. Patrz tabela progu rentowności powyżej.

Czy wdrożę LLM na serverless GPU za darmo?

Modal daje $30/miesiąc darmowych kredytów (Starter). Beam daje $30/miesiąc. Kredyt $300 dla nowych kont GCP pokrywa użycie GPU w Cloud Run. Wystarczy na prototyp, nie na ruch produkcyjny. Żadna platforma nie oferuje trwałego darmowego poziomu dla inferencji GPU.

Którzy dostawcy serverless GPU są dostępni w Europie?

Cloud Run serwuje GPU L4 w europe-west1 (Belgia) i europe-west4 (Holandia). Modal dokumentuje wybór regionu EU (eu-west, eu-north, eu-south) w cenach 1,5-1,75 raza stawki bazowej. RunPod wymienia europejskie centra danych, w tym EU-NL-1 i EU-FR-1. Ustaw region jawnie; żaden z nich nie ma domyślnie EU.

Czy potrzebuję Dockera, żeby wdrożyć LLM na serverless GPU?

Nie zawsze. RunPod oferuje gotowe szablony workerów vLLM, które pomijają Dockera. Modal buduje kontenery z definicji obrazu w Pythonie, w kodzie. Dla niestandardowych zależności napiszesz Dockerfile. Dla standardowego serwowania vLLM gotowa ścieżka działa w kilka minut.

Podsumowanie

Pięć platform, pięć jednostek rozliczeniowych, jedna znormalizowana tabela. Decyzja jest prostsza, niż sugerują strony dostawców:

• Wybieraj GPU po VRAM, nie po marce.
• Trzymaj wagi na wolumenie, nie w obrazie, chyba że nigdy nie zmieniasz modeli.
• Spodziewaj się 10-30-sekundowych cold startów i planuj wokół nich.
• Poniżej ~47 000 żądań dziennie scale-to-zero wygrywa kosztowo.
• Silnik serwujący za endpointem jest wymienny; base_url to jedna linia.

Masz endpoint, który można wywołać. Dalej: co stanie przed nim, gdy potrzebujesz routingu i failoveru? Nasze porównanie bramek LLM odpowiada na to pytanie. Albo omów swoją konfigurację z nami.