Deploy LLM pe GPU serverless: 5 platforme, prețuri reale, cold start-uri fără menajamente

Deploy LLM pe GPU serverless: 5 platforme, prețuri reale, cold start-uri fără menajamente

RunPod taxează 2,72 $/oră pentru un A100 80GB. Endpointul tău primește douăsprezece cereri înainte de prânz. GPU-ul stă degeaba în restul de 23 de ore și facturează tot timpul. Fă deploy la un LLM pe GPU serverless și plătești doar cât rulează o cerere. Cinci platforme fac asta. Fiecare facturează în altă unitate de măsură. Nimeni nu le normalizează.

Un GPU inactiv costă exact cât unul ocupat.

Concluziile pe scurt

• GPU-ul serverless facturează doar cât rulează o cerere și scalează la zero între cereri.
• Un singur GPU per instanță pe Cloud Run; modelele de 70B au nevoie de mai multe GPU-uri, deci serverless de obicei nu le poate găzdui.
• Greutățile modelului stau în imagine, pe un volum de rețea sau se re-descarcă la fiecare cold start.
• Cold start-ul înseamnă trei lucruri: pornirea containerului, încărcarea greutăților, inițializarea motorului. Doar primul e rapid.
• Sub aproximativ 47.000 de cereri pe zi, scale-to-zero bate un GPU închiriat 24/7.

Ce înseamnă de fapt „serverless GPU" pentru un LLM?

O platformă serverless GPU rulează containerul tău de inferență pe hardware GPU partajat, îl pornește când sosește o cerere și scalează la zero când traficul se oprește. Plătești pe secundă (sau pe minut, sau pe oră, în funcție de vendor) doar cât containerul e activ. Fără factură de inactivitate. Fără instanță rezervată.

Unitatea de facturare diferă de la vendor la vendor, de aceea secțiunea următoare normalizează totul în $/GPU-oră.

Două restricții îi surprind pe oameni. Prima: Google Cloud Run permite un singur GPU per instanță, maximum. Asta îți plafonează plafonul de VRAM la o singură placă. A doua: „serverless" nu înseamnă stare persistentă. Nu există niciun proces longeviv care să-ți țină greutățile în RAM între cereri. Când containerul moare, tot ce e în memorie moare odată cu el. Exact acest fapt dictează decizia de stocare din secțiunea despre greutățile modelului de mai jos.

Serverless nu înseamnă fără server. Înseamnă fără server între cererile tale, și exact acolo dispar greutățile modelului tău.

Ce platformă serverless GPU ar trebui să alegi? (prețuri 2026, comparate)

Nu vindem niciuna dintre aceste platforme și nu încasăm venituri de afiliere de la vreuna. Dintre cele șapte articole care concurează pe această interogare și variantele ei apropiate, patru sunt publicate de o companie care vinde serverless GPU. Acest tabel nu e.

Toate tarifele sunt citite de pe paginile de prețuri ale vendorilor, pe 2026-07-30. Tarifele se schimbă; reverifică înainte să te angajezi.

Aritmetica normalizării, arătată o singură dată ca să o poți verifica: Modal A100 80GB la 0,000694 $/s înmulțit cu 3600 de secunde înseamnă 2,4984 $/oră. Beam: 0,000625 $ ori 3600 înseamnă 2,25 $/oră. Baseten: 0,06667 $/min ori 60 înseamnă 4,00 $/oră. Acea diferență de 1,8x între Beam și Baseten pentru același A100 e reală și se ascunde la vedere, pentru că nimeni nu publică aceeași unitate de măsură.

Trei avertismente. Pagina de prețuri Beam spune explicit că nu facturează pornirea serverului sau încărcarea imaginii de container. FAQ-ul de prețuri Baseten răspunde la „Plătesc pentru timpul inactiv pe Baseten?" cu „Nu, nu plătești pentru timpul inactiv", apoi adaugă că timpul facturat e „timpul în care modelul tău se desfășoară activ, scalează în sus sau în jos sau face predicții", deci contorul acoperă mai mult decât timpul de predicție, și tocmai partea asta merită bugetată. RunPod publică tarife pe oră și nicio cifră de cold start pe pagina de prețuri.

Dacă Modal e alegerea ta, am scris separat ghidul complet Modal, pas cu pas.

Modelul tău chiar încape? VRAM, limita de un GPU și cote

Poți rula un model de 70B pe un GPU serverless? De obicei nu. La FP16, un 70B are nevoie de ~140 GB VRAM. Cloud Run plafonază la un GPU per instanță (maximum 96 GB pe RTX PRO 6000). Socoteala nu se închide fără cuantizare (FP8/GGUF) sau o platformă multi-GPU.

Cota implicită Cloud Run e de 3 GPU-uri L4 per regiune per proiect (RTX PRO 6000 se acordă separat, ca 3.000 milliGPU), pe șase regiuni L4: asia-southeast1, asia-south1, europe-west1, europe-west4, us-central1, us-east4. Asta e jumătatea Cloud Run din răspunsul despre rezidența datelor pentru oricine întreabă de serverless GPU în Europa; Modal și RunPod își documentează propriile regiuni EU, iar FAQ-ul conține restul.

Tutorialul Cloud Run al lui Ismaili Simba de pe dev.to (aprilie 2025) raportează că cererea de cotă „poate dura ceva timp (până la 5 zile lucrătoare) până e aprobată" și că „GPU-urile L4 disponibile pe Cloud Run au o limită de 16 GB RAM." Planifică acea întârziere.

Pentru dimensionarea VRAM model cu model, vezi ghidul nostru de cerințe VRAM.

Unde stau greutățile modelului tău (și cât costă asta)?

Un fir de Reddit din noiembrie 2024 care încă stătea pe locul 5 pe Google pentru exact această interogare când am verificat pe 2026-07-30 întreabă, cuvânt cu cuvânt:

„Nu am reușit să găsesc un tarif pentru stocarea modelului de 80 gb... Ce alternativă am dacă nu vreau să descarc modelul la fiecare apel de api (podul e provizionat la apel, apoi închis)?... De ce aceste platforme nu listează costul de stocare a modelului?"

Trei răspunsuri cu scor mic, niciunul un răspuns propriu-zis. Când am rulat această căutare pe 2026-07-30, primele zece rezultate includeau încă acel fir vechi de doi ani care întreba cât costă stocarea modelului. Nimeni din fir nu a răspuns. Ambele platforme publică tariful. Pe Modal e 0,09 $ per GiB pe lună, cu primul TiB gratuit, deci acel checkpoint de 80 GB se facturează cu 0,00 $. Pe RunPod e 0,07 $ per GB pe lună pentru stocare de rețea sub 1 TB, ceea ce pune același checkpoint la aproximativ 5,60 $ pe lună.

Al treilea rând e modul de eșec. O recenzie TU München din 2024 a ServerlessLLM (arXiv 2411.15664) raportează că LLaMA-2-70B (130 GB) are nevoie de peste 26 de secunde pentru tragere la 5 GB/s, plus ~84 de secunde pentru încărcare pe 8 GPU-uri, față de ~100 ms generarea unui token. Acele cifre sunt citate în acea recenzie, nu măsurate de ea.

Pagina de prețuri RunPod are o secțiune Storage: disc container 0,10 $/GB/lună, disc volum 0,10 $/GB/lună în rulare și 0,20 $/GB/lună inactiv, stocare de rețea 0,07 $/GB/lună sub 1 TB și 0,05 $/GB/lună peste, stocare de rețea de înaltă performanță 0,14 $/GB/lună. Numărul există. Doar că nu stă lângă tarifele serverless per GPU pe care cititorul le compară când îi vine întrebarea în minte și nici în fluxul de configurare a endpointului. O problemă de vizibilitate, nu de secretomanie, și suficientă cât să țină întrebarea în viață doi ani mai târziu.

# 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

Dacă încă nu ți-ai ales un model, clasamentul nostru 2026 al modelelor open-weights dimensionează fiecare opțiune pentru deploy.

Fă deploy: vLLM pe RunPod Serverless, de la cap la coadă

Șase pași de la zero la un endpoint apelabil. Verifică fiecare pas cu procedura vLLM a RunPod (actualizată pe 22 iunie 2026), care nu publică prețuri.

1. Alege modelul. Alege un model open-weights dimensionat pentru GPU-ul tău (vezi tabelul VRAM de mai sus). Dacă e cu acces restricționat pe Hugging Face, generează mai întâi un token de acces.

2. Creează endpointul serverless. În consola RunPod, selectează Serverless, alege șablonul de worker vLLM și alege clasa de GPU.

3. Setează variabilele de mediu care contează.

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

MODEL_NAME greșit înseamnă un 404 la pornire. MAX_MODEL_LEN setat prea sus pentru VRAM-ul tău înseamnă OOM înainte de primul token. GPU_MEMORY_UTILIZATION peste 0,95 nu lasă marjă pentru vârfurile de KV-cache.

1. Setează lucrătorii min/max și timeout-ul de inactivitate. Lucrători minim la 0 îți dă scale-to-zero (și cold start-uri). Lucrători minim la 1 elimină cold start-urile, dar facturează continuu. Secțiunea despre cold start de mai jos lucrează acest compromis.

2. Atașează volumul de rețea pe care l-ai decis în secțiunea despre greutățile modelului sau acceptă calea încorporării în imagine. Dacă sari peste asta, fiecare cold start re-descarcă checkpointul.

3. Trimite prima cerere. Citește ID-ul endpointului din consolă și confirmă că se întorc tokeni.

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

Dacă cântărești motorul de serving în sine, am comparat vLLM cu SGLang pe throughput și latență.

Cum apelezi endpointul din aplicația ta?

Fiecare platformă din lista scurtă vorbește un API compatibil OpenAI. Un singur snippet Python funcționează peste tot. Schimbarea providerului e o modificare de base_url, nu o rescriere. Asta reframulează „care provider" dintr-o decizie de lock-in într-una de configurare.

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

Dacă fiecare provider vorbește dialectul OpenAI, „care provider serverless GPU" încetează să mai fie o decizie de arhitectură și devine o singură linie de configurare.

Odată ce ai mai multe endpointuri, comparația noastră de gateway-uri LLM acoperă rutarea și failoverul. Pentru un setup mai ușor, un proxy LiteLLM adaugă reîncercări și logare.

Ce cold start vei vedea de fapt?

Pentru un model de 7B pe GPU serverless, așteaptă-te la 10-30 de secunde la un cold start adevărat (pornirea containerului plus încărcarea greutăților plus inițializarea motorului), pe baza rapoartelor practicienilor. Documentația vendorilor citează 1-5 secunde doar pentru pornirea containerului. Diferența dintre acele numere e checkpointul tău traversând rețeaua.

Pagina de produs RunPod susține cold start-uri FlashBoot sub 200ms (o afirmație de vendor, nu o măsurătoare). Un practician din r/LLMDevs raportează: „cold starts in my experience aren't great... I would say ~ 10 - 30 s", adăugând „most of my experience revolves around diffusion models though." Ambele sunt adevărate. Măsoară lucruri diferite.

Numărul de cold start e de fapt trei numere suprapuse:

1. Pornirea containerului. Documentația Modal: „Containers boot in about one second." Cloud Run: instanțele cu drivere preinstalate „start in approximately 5 seconds."

2. Încărcarea greutăților. Partea pe care nimeni nu o promovează. O recenzie TU München din 2024 a ServerlessLLM (arXiv 2411.15664) pune LLaMA-2-70B la peste 26 de secunde tragerea plus ~84 de secunde încărcarea pe 8 GPU-uri.

3. Inițializarea motorului. Captura de graf și warm-up-ul vLLM. Logesh Umapathi a măsurat Qwen3.6-27B-FP8 pe un A100-80GB coborând de la 460s bază la 219s cu eager mode, până la ~70s cu vLLM sleep mode plus snapshot-uri GPU Modal. Asta înseamnă 6,5x, publicat pe 17 mai 2026.

Interpretarea noastră a datelor publicate: cifrele vendorilor cronometrează containerul. Cifrele practicienilor cronometrează întreaga cerere. Între acele două cronometre stau 80 GB de greutăți traversând rețeaua. Coloana Tip e ideea.

Ce poți face: vLLM sleep mode, snapshot-uri GPU și ajustarea ferestrei de scaledown. Idle-ul implicit Modal e de 60 de secunde (configurabil 2s-20min). Un lucrător cald elimină cold start-urile, dar facturează ca always-on.

# 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-ul serverless e mai ieftin decât un GPU always-on?

GPU-ul serverless e mai ieftin când GPU-ul tău stă inactiv mare parte din zi. La 3.000 de cereri/zi cu o medie de 2 secunde fiecare pe un A100 80GB, serverless costă aproximativ 4,17 $/zi față de 65,28 $/zi pentru un GPU închiriat care rulează 24/7. Punctul de încrucișare e o chestiune de ciclu de utilizare, nu de volum.

Presupuneri (ale noastre, enunțate ca să le poți rula din nou): A100 80GB la 2,50 $/oră pe Modal, 2 secunde timp GPU mediu per cerere, GPU închiriat la 2,72 $/oră pe RunPod non-stop, API de tokeni găzduit la 0,40 $/1M tokeni (un tarif publicat de gamă medie) și ~1.000 de tokeni per cerere.

Încrucișarea cade pe la 47.000 de cereri/zi. Sub asta, serverless câștigă. Un API de tokeni găzduit le bate pe ambele la volum mic cu un model de tip commodity. Pragul de rentabilitate nu ține de câte cereri primești. Ține de câte ore își petrece GPU-ul făcând nimic.

Analiza BentoML din august 2024 încadrează bine acest compromis, deși exemplele ei de prețuri sunt din era GPT-3.5-turbo și au doi ani vechime.

Pentru cât costă un API de tokeni găzduit la volumul tău, vezi comparația noastră de prețuri API LLM. Ca să tai costul per cerere pe partea de inferență, prompt caching economisește de obicei 30-60% pe context repetat.

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

Când GPU-ul serverless e alegerea greșită

• Trafic ridicat susținut. Peste ~47.000 de cereri/zi la aceste tarife, ciclul de utilizare se inversează și un GPU închiriat e mai ieftin per cerere.
• SLO-uri stricte sub-secundă pe cale rece. Niciun truc de snapshot nu face prima cerere instantanee. Ține un lucrător cald sau închiriază mașina.
• Modele de 70B+ care au nevoie de mai multe GPU-uri. Un GPU per instanță pe Cloud Run încheie acea conversație.
• Rezidență strictă a datelor. Șase regiuni L4 sunt tot meniul pe Cloud Run.
• Economie per cerere care pierde în fața unui slot de lucrător pe care deja îl plătești. Dacă ai marjă GPU liberă, adăugarea inferenței nu costă nimic în plus.

Dacă GPU-ul tău e ocupat șaisprezece ore pe zi, serverless e opțiunea scumpă, și oricine îți spune contrariul vinde serverless.

Pentru calea local-first, vezi ghidul nostru de instrumente LLM locale.

Despre autor

Mert Batur este co-fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri de voce/SDR pentru clienți B2B. El scrie despre stackul de instrumente LLM pe care echipa Techsy îl folosește efectiv în producție. Conectează-te pe LinkedIn.

Întrebări frecvente

Ce este un GPU serverless?

O platformă serverless GPU rulează containerul modelului tău pe hardware partajat, scalează la zero între cereri și facturează doar compute-ul activ. Primești un endpoint de inferență fără să gestionezi o instanță GPU persistentă. Compromisul e întârzierea de cold start la pornire.

Cât costă să rulezi un LLM pe un GPU serverless?

Un A100 80GB rulează cu 2,25 $/oră pe Beam, 2,50 $/oră pe Modal, 2,72 $/oră pe RunPod (verificat pe 2026-07-30). Factura ta depinde de ciclul de utilizare: 3.000 de cereri/zi a câte 2s fiecare costă ~4 $/zi pe Modal. Stocarea adaugă 0,09 $/GiB/lună, cu 1 TiB gratuit.

Plătesc pentru stocarea greutăților modelului?

Da, dar e ieftin. Modal taxează 0,09 $/GiB/lună cu 1 TiB/lună gratuit, deci un checkpoint de 80 GB nu costă nimic. Pagina de prețuri RunPod listează stocarea de rețea la 0,07 $/GB/lună sub 1 TB, adică vreo 5,60 $/lună pentru aceiași 80 GB.

Modelul meu se re-descarcă la fiecare cerere?

Doar dacă nimic nu e în cache. Greutățile de pe un volum persistent sau încorporate în imagine supraviețuiesc cold start-urilor. Îndrepți cache-ul Hugging Face către stocare efemeră și un model de 130 GB se re-descarcă la fiecare pornire. Ăsta e modul de eșec de evitat.

Cât durează cold start-ul pentru un model de 7B?

Așteaptă-te la 10-30 de secunde la un cold start adevărat, conform rapoartelor practicienilor (r/LLMDevs, dec 2024). Containerul pornește în 1-5s (documentația Modal, Cloud Run). Restul e încărcarea greutăților și inițializarea motorului. Cu snapshot-uri și sleep mode, Umapathi a măsurat ~70s pentru un model de 27B, coborât de la 460s.

Pot rula un model de 70B pe GPU serverless?

De obicei nu. Un model de 70B la FP16 are nevoie de ~140 GB VRAM. Cloud Run permite un GPU per instanță (maximum 96 GB). Ți-ar trebui cuantizare FP8 ca să încapă pe o singură placă de 80 GB sau o platformă multi-GPU. Cele mai multe suprafețe serverless plafonază la un GPU.

GPU-ul serverless e mai ieftin decât închirierea unui GPU 24/7?

Sub ~47.000 de cereri/zi (la 2s/cerere pe un A100 80GB), da. Serverless facturează doar secundele active; un GPU închiriat facturează 24 de ore indiferent. Peste acel prag, GPU-ul închiriat câștigă. Un API de tokeni găzduit le bate pe ambele la volum mic. Vezi tabelul de rentabilitate de mai sus.

Pot face deploy la un LLM pe GPU serverless gratuit?

Modal oferă 30 $/lună credite gratuite (Starter). Beam oferă 30 $/lună. Creditul GCP de 300 $ pentru conturi noi acoperă utilizarea GPU pe Cloud Run. Suficient pentru prototipare, nu pentru trafic de producție. Nicio platformă nu oferă un tier gratuit permanent pentru inferență GPU.

Ce provideri serverless GPU sunt disponibili în Europa?

Cloud Run servește GPU-uri L4 în europe-west1 (Belgia) și europe-west4 (Olanda). Modal documentează selecția de regiuni EU (eu-west, eu-north, eu-south) tarifate la 1,5-1,75x din tarifele de bază. RunPod numește centre de date europene, inclusiv EU-NL-1 și EU-FR-1. Fixează regiunea explicit; niciunul nu alege implicit UE.

Am nevoie de Docker ca să fac deploy la un LLM pe GPU serverless?

Nu întotdeauna. RunPod oferă șabloane de worker vLLM pre-construite care sar peste Docker. Modal construiește containere dintr-o definiție de imagine Python în cod. Pentru dependențe personalizate vei scrie un Dockerfile. Pentru serving vLLM standard, calea pre-construită funcționează în câteva minute.

Concluzie

Cinci platforme, cinci unități de facturare, un singur tabel normalizat. Decizia e mai simplă decât o prezintă paginile vendorilor:

• Alege GPU-ul după VRAM, nu după brand.
• Pune greutățile pe un volum, nu în imagine, doar dacă nu schimbi niciodată modelele.
• Așteaptă-te la cold start-uri de 10-30 de secunde și planifică în jurul lor.
• Sub ~47.000 de cereri/zi, scale-to-zero câștigă la cost.
• Motorul de serving din spatele endpointului e interschimbabil; base_url e o singură linie.

Ai un endpoint apelabil. Mai departe: ce stă în fața lui când ai nevoie de rutare și failover? Comparația noastră de gateway-uri LLM răspunde la asta. Sau discută cu noi despre setup-ul tău.