Distribuire un LLM su GPU serverless: 5 piattaforme, prezzi reali, cold start senza filtri

Distribuire un LLM su GPU serverless: 5 piattaforme, prezzi reali, cold start senza filtri

RunPod chiede 2,72 $/ora per una A100 80GB. Il tuo endpoint riceve dodici richieste prima di pranzo. Per le altre 23 ore quella GPU resta ferma, ma continua a fatturare. Distribuisci un LLM su una GPU serverless e paghi solo mentre una richiesta è in esecuzione. Cinque piattaforme fanno esattamente questo. E fatturano in cinque unità diverse. Nessuno le normalizza.

Una GPU ferma costa esattamente quanto una impegnata.

Punti chiave

• Le GPU serverless fatturano solo mentre una richiesta è in esecuzione e tra una e l'altra scalano a zero.
• Su Cloud Run c'è una GPU per istanza; i modelli 70B richiedono più GPU, quindi il serverless di solito non può ospitarli.
• I pesi del modello stanno nell'immagine, su un volume di rete, oppure vengono riscaricati a ogni cold start.
• Il cold start è fatto di tre fasi: avvio del container, caricamento dei pesi, inizializzazione del motore. Solo la prima è veloce.
• Sotto le 47.000 richieste al giorno circa, lo scale-to-zero conviene più di una GPU in affitto 24/7.

Cosa significa davvero 'GPU serverless' per un LLM?

Una piattaforma di GPU serverless esegue il tuo container di inferenza su hardware GPU condiviso, lo avvia quando arriva una richiesta e scala a zero quando il traffico si ferma. Paghi al secondo (o al minuto, o all'ora, a seconda del vendor) solo finché il container è attivo. Niente fattura per l'inattività. Niente istanze riservate.

L'unità di fatturazione cambia da vendor a vendor, ed è per questo che la prossima sezione normalizza tutto in $/GPU-ora.

Due vincoli colgono di sorpresa. Primo, Google Cloud Run consente al massimo una GPU per istanza. Questo limita il tuo tetto di VRAM a una singola scheda. Secondo, "serverless" non significa stato persistente. Non esiste alcun processo di lunga durata che mantiene i pesi in RAM tra una richiesta e l'altra. Quando il container muore, tutto ciò che è in memoria muore con lui. Questo singolo fatto determina la scelta dello storage nella sezione sui pesi del modello qui sotto.

Serverless non significa nessun server. Significa nessun server tra le tue richieste, ed è esattamente lì che i pesi del tuo modello spariscono.

Quale piattaforma GPU serverless scegliere? (prezzi 2026 a confronto)

Non vendiamo nessuna di queste piattaforme e non incassiamo ricavi di affiliazione da alcuna. Dei sette articoli in competizione per questa query e le sue varianti vicine, quattro sono pubblicati da un'azienda che vende GPU serverless. Questa tabella no.

Tutte le tariffe sono lette dalle pagine prezzi dei vendor stessi il 30-07-2026. Le tariffe cambiano; ricontrolla prima di impegnarti.

I conti della normalizzazione, mostrati una volta sola così puoi verificarli: la A100 80GB di Modal a $0,000694/s moltiplicato per 3600 secondi fa $2,4984/ora. Beam: $0,000625 per 3600 fa $2,25/ora. Baseten: $0,06667/min per 60 fa $4,00/ora. Quel divario di 1,8x tra Beam e Baseten per la stessa A100 è reale, e si nasconde in bella vista perché nessuno pubblica la stessa unità.

Tre avvertenze. La pagina prezzi di Beam dichiara esplicitamente di non fatturare lo spin-up del server né il caricamento dell'immagine del container. Le FAQ sui prezzi di Baseten rispondono a "Si paga il tempo di inattività su Baseten?" con "No, il tempo di inattività non si paga", e poi aggiungono che il tempo fatturabile è "il tempo in cui il tuo modello è in fase di deploy attivo, scaling in su o in giù, o sta generando previsioni", quindi il contatore copre più del solo tempo di previsione, che è la parte per cui vale la pena fare il budget. RunPod pubblica tariffe orarie e nessuna cifra sui cold start nella sua pagina prezzi.

Se Modal è la tua scelta, abbiamo scritto a parte una guida completa a Modal.

Il tuo modello ci sta? VRAM, limiti a una GPU e quote

Puoi eseguire un modello 70B su una GPU serverless? Di solito no. In FP16, un 70B richiede circa 140 GB di VRAM. Cloud Run ha un tetto di una GPU per istanza (96 GB al massimo sulla RTX PRO 6000). I conti non tornano senza quantizzazione (FP8/GGUF) o una piattaforma multi-GPU.

La quota predefinita di Cloud Run è di 3 GPU L4 per region per progetto (la RTX PRO 6000 viene concessa separatamente, come 3.000 milliGPU), distribuita su sei region L4: asia-southeast1, asia-south1, europe-west1, europe-west4, us-central1, us-east4. Questa è la metà Cloud Run della risposta sulla residenza dei dati per chiunque chieda delle GPU serverless in Europa; Modal e RunPod documentano le proprie region UE, e le FAQ hanno il resto.

La guida a Cloud Run su dev.to di Ismaili Simba (aprile 2025) riporta che la richiesta di quota "può richiedere un po' di tempo (fino a 5 giorni lavorativi) per essere approvata" e che "le GPU L4 disponibili su Cloud Run hanno un limite di 16GB di RAM." Metti in conto quel ritardo.

Per il dimensionamento VRAM modello per modello, vedi la nostra guida ai requisiti VRAM.

Dove stanno i pesi del tuo modello (e quanto costa)?

Un thread di Reddit del novembre 2024 che, quando abbiamo controllato il 30-07-2026, era ancora al quinto posto su Google per questa identica query, chiede testualmente:

"Non sono riuscito a trovare la tariffa per lo storage del modello da 80 gb… Qual è l'alternativa se non voglio scaricare il modello a ogni chiamata API (pod provisionato alla chiamata e poi chiuso)? … Perché queste piattaforme non elencano il costo dello storage dei modelli?"

Tre risposte a punteggio basso, nessuna delle quali è una risposta. Quando abbiamo fatto questa ricerca il 30-07-2026, i primi dieci risultati includevano ancora quel thread di due anni fa che chiede quanto costa lo storage dei modelli. Nessuno nel thread ha risposto. Entrambe le piattaforme pubblicano la tariffa. Su Modal è $0,09 per GiB al mese con il primo TiB gratuito, quindi quel checkpoint da 80 GB fattura $0,00. Su RunPod è $0,07 per GB al mese per lo storage di rete sotto 1 TB, il che porta lo stesso checkpoint a circa $5,60 al mese.

La terza riga è la modalità di fallimento. Una review della TU München del 2024 su ServerlessLLM (arXiv 2411.15664) riporta che LLaMA-2-70B (130 GB) richiede oltre 26 secondi per il pull a 5 GB/s, più circa 84 secondi per il caricamento su 8 GPU, contro una generazione di token di circa 100 ms. Quelle cifre sono citate in quella review, non misurate da essa.

La pagina prezzi di RunPod ha una sezione Storage: disco del container $0,10/GB/mese, disco del volume $0,10/GB/mese in esecuzione e $0,20/GB/mese inattivo, storage di rete $0,07/GB/mese sotto 1 TB e $0,05/GB/mese sopra, storage di rete ad alte prestazioni $0,14/GB/mese. Il numero esiste. Semplicemente non sta accanto alle tariffe serverless per GPU che un lettore sta confrontando quando la domanda gli viene in mente, né nel flusso di configurazione dell'endpoint. Un problema di reperibilità, non di segretezza, e sufficiente a tenere viva la domanda due anni dopo.

# 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

Se non hai ancora scelto un modello, la nostra rassegna 2026 degli open-weights dimensiona ogni opzione per il deploy.

Fai il deploy: vLLM su RunPod Serverless, da cima a fondo

Sei passi da zero a un endpoint chiamabile. Verifica ciascuno con la procedura vLLM di RunPod (aggiornata al 22 giugno 2026), che non pubblica prezzi.

1. Scegli il modello. Scegli un modello open-weights dimensionato per la tua GPU (vedi la tabella VRAM sopra). Se è gated su Hugging Face, genera prima un token di accesso.

2. Crea l'endpoint serverless. Nella console di RunPod, seleziona Serverless, scegli il template worker vLLM e seleziona il tuo tier di GPU.

3. Imposta le variabili d'ambiente che contano.

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

MODEL_NAME sbagliato significa un 404 all'avvio. MAX_MODEL_LEN troppo alto per la tua VRAM significa OOM prima del primo token. GPU_MEMORY_UTILIZATION sopra 0,95 non lascia margine per i picchi della KV-cache.

1. Imposta worker min/max e timeout di inattività. Worker minimi a 0 ti dà lo scale-to-zero (e i cold start). Worker minimi a 1 elimina i cold start ma fattura in continuo. La sezione sui cold start qui sotto analizza quel compromesso.

2. Collega il volume di rete che hai deciso nella sezione sui pesi del modello, oppure accetta la strada dell'incorporazione nell'immagine. Se salti questo passo, ogni cold start riscarica il checkpoint.

3. Lancia la prima richiesta. Leggi l'ID dell'endpoint dalla console e conferma che tornino dei token.

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

Se stai valutando il motore di serving in sé, abbiamo messo a confronto vLLM e SGLang su throughput e latenza.

Come chiami l'endpoint dalla tua app?

Ogni piattaforma nella rosa parla un'API compatibile con OpenAI. Uno snippet Python funziona ovunque. Cambiare provider è una modifica al base_url, non una riscrittura. Questo trasforma "quale provider" da una decisione di lock-in a una decisione di configurazione.

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

Se ogni provider parla il dialetto di OpenAI, "quale provider di GPU serverless" smette di essere una decisione architetturale e diventa una riga di configurazione.

Una volta che hai più endpoint, il nostro confronto sugli LLM gateway copre routing e failover. Per un setup più leggero, un proxy LiteLLM aggiunge retry e logging.

Che cold start vedrai davvero?

Per un modello 7B su GPU serverless, aspettati da 10 a 30 secondi su un vero cold start (avvio del container più caricamento dei pesi più inizializzazione del motore), secondo i report dei practitioner. Le doc dei vendor citano da 1 a 5 secondi per il solo avvio del container. Il divario tra quei numeri è il tuo checkpoint che attraversa una rete.

La pagina prodotto di RunPod dichiara cold start FlashBoot sotto i 200ms (una dichiarazione del vendor, non una misurazione). Un practitioner su r/LLMDevs riporta: "i cold start nella mia esperienza non sono granché… direi circa 10 - 30 s", aggiungendo "però la maggior parte della mia esperienza ruota attorno ai modelli di diffusione." Entrambe le cose sono vere. Misurano cose diverse.

Il numero del cold start è tre numeri impilati:

1. Avvio del container. Le doc di Modal: "I container si avviano in circa un secondo." Cloud Run: le istanze con driver preinstallati "si avviano in circa 5 secondi."

2. Caricamento dei pesi. La parte che nessuno pubblicizza. Una review della TU München del 2024 su ServerlessLLM (arXiv 2411.15664) colloca LLaMA-2-70B a oltre 26 secondi per il pull più circa 84 secondi per il caricamento su 8 GPU.

3. Inizializzazione del motore. Graph capture e warm-up di vLLM. Logesh Umapathi ha misurato Qwen3.6-27B-FP8 su una A100-80GB passare da una baseline di 460s a 219s con la modalità eager, fino a circa 70s con la sleep mode di vLLM più gli snapshot GPU di Modal. È un fattore 6,5x, pubblicato il 17 maggio 2026.

La nostra interpretazione dei dati pubblicati: le cifre dei vendor cronometrano il container. Le cifre dei practitioner cronometrano l'intera richiesta. Tra quei due cronometri ci stanno 80 GB di pesi che attraversano una rete. La colonna Tipo è il punto.

Cosa fare: sleep mode di vLLM, snapshot della GPU e regolazione della finestra di scaledown. L'inattività predefinita di Modal è 60 secondi (configurabile 2s-20min). Un worker caldo elimina i cold start ma fattura come sempre attivo.

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

La GPU serverless costa meno di una GPU sempre accesa?

La GPU serverless costa meno quando la tua GPU resta ferma per gran parte della giornata. A 3.000 richieste/giorno con una media di 2 secondi ciascuna su una A100 80GB, il serverless costa circa $4,17/giorno contro $65,28/giorno per una GPU in affitto attiva 24/7. Il punto di incrocio è una questione di duty cycle, non di volume.

Ipotesi (le nostre, dichiarate così puoi rifarle): A100 80GB a $2,50/ora di Modal, 2 secondi di tempo GPU medio per richiesta, GPU in affitto a $2,72/ora di RunPod 24 ore su 24, API token in hosting a $0,40/1M token (una tariffa pubblicata di fascia media) e circa 1.000 token per richiesta.

L'incrocio cade intorno alle 47.000 richieste/giorno. Sotto quella soglia, vince il serverless. Un'API token in hosting batte entrambe a basso volume con un modello commodity. Il break-even non dipende da quante richieste ricevi. Dipende da quante ore la tua GPU passa a non fare niente.

L'analisi di BentoML dell'agosto 2024 inquadra bene questo compromesso, anche se i suoi esempi di prezzo sono dell'era GPT-3.5-turbo e vecchi di due anni.

Per quanto costa un'API token in hosting al tuo volume, vedi il nostro confronto sui prezzi delle API LLM. Per tagliare il costo per richiesta sul lato inferenza, il prompt caching di solito fa risparmiare il 30-60% sul contesto ripetuto.

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

Quando la GPU serverless è la scelta sbagliata

• Traffico alto e sostenuto. Oltre le ~47.000 richieste/giorno a queste tariffe, il duty cycle si inverte e una GPU in affitto costa meno per richiesta.
• SLO rigidi sotto il secondo su un percorso freddo. Nessun trucco di snapshot rende istantanea una prima richiesta. Tieni un worker caldo o affitta la macchina.
• Modelli 70B+ che richiedono più GPU. Una GPU per istanza su Cloud Run chiude quel discorso.
• Residenza dei dati rigorosa. Sei region L4 sono l'intero menu su Cloud Run.
• Economia per richiesta che perde contro uno slot worker che stai già pagando. Se hai margine GPU inutilizzato, aggiungere inferenza non costa nulla in più.

Se la tua GPU è impegnata sedici ore al giorno, il serverless è l'opzione costosa e chiunque ti dica il contrario sta vendendo serverless.

Per la strada local-first, vedi la nostra guida agli strumenti per LLM in locale.

Domande frequenti

Cos'è una GPU serverless?

Una piattaforma di GPU serverless esegue il container del tuo modello su hardware condiviso, scala a zero tra le richieste e fattura solo il calcolo attivo. Ottieni un endpoint di inferenza senza gestire un'istanza GPU persistente. Il compromesso è un ritardo di cold start allo spin-up.

Quanto costa eseguire un LLM su una GPU serverless?

Una A100 80GB costa $2,25/ora su Beam, $2,50/ora su Modal, $2,72/ora su RunPod (verificato il 30-07-2026). La tua fattura dipende dal duty cycle: 3.000 richieste/giorno a 2s ciascuna costano circa $4/giorno su Modal. Lo storage aggiunge $0,09/GiB/mese, con 1 TiB gratis.

Pago lo storage dei pesi del modello?

Sì, ma costa poco. Modal applica $0,09/GiB/mese con 1 TiB/mese gratis, quindi un checkpoint da 80 GB non costa nulla. La pagina prezzi di RunPod elenca lo storage di rete a $0,07/GB/mese sotto 1 TB, circa $5,60/mese per gli stessi 80 GB.

Il mio modello viene riscaricato a ogni richiesta?

Solo se niente è in cache. I pesi su un volume persistente o incorporati nell'immagine sopravvivono ai cold start. Punta la cache di Hugging Face sullo storage effimero e un modello da 130 GB si riscarica a ogni spin-up. Quella è la modalità di fallimento da evitare.

Quanto dura il cold start per un modello 7B?

Aspettati 10-30 secondi su un vero cold start, secondo i report dei practitioner (r/LLMDevs, dic 2024). Il container si avvia in 1-5s (doc Modal, Cloud Run). Il resto è caricamento dei pesi e inizializzazione del motore. Con snapshot e sleep mode, Umapathi ha misurato circa 70s per un modello 27B, in calo da 460s.

Posso eseguire un modello 70B su GPU serverless?

Di solito no. Un modello 70B in FP16 richiede circa 140 GB di VRAM. Cloud Run consente una GPU per istanza (96 GB al massimo). Ti servirebbe la quantizzazione FP8 per stare su una singola scheda da 80 GB, o una piattaforma multi-GPU. La maggior parte delle superfici serverless ha un tetto di una GPU.

La GPU serverless costa meno che affittare una GPU 24/7?

Sotto le ~47.000 richieste/giorno (a 2s/richiesta su una A100 80GB), sì. Il serverless fattura solo i secondi attivi; una GPU in affitto fattura 24 ore comunque. Sopra quella soglia, vince la GPU in affitto. Un'API token in hosting batte entrambe a basso volume. Vedi la tabella di break-even sopra.

Posso distribuire un LLM su GPU serverless gratis?

Modal dà $30/mese di crediti gratuiti (Starter). Beam dà $30/mese. I $300 di credito per nuovi account di GCP coprono l'uso delle GPU su Cloud Run. Abbastanza per prototipare, non per traffico di produzione. Nessuna piattaforma offre un free tier permanente per l'inferenza GPU.

Quali provider di GPU serverless sono disponibili in Europa?

Cloud Run serve GPU L4 in europe-west1 (Belgio) e europe-west4 (Paesi Bassi). Modal documenta la selezione delle region UE (eu-west, eu-north, eu-south) a prezzi di 1,5-1,75x le tariffe base. RunPod nomina data center europei tra cui EU-NL-1 e EU-FR-1. Fissa la region in modo esplicito; nessuna di esse ha l'UE come default.

Mi serve Docker per distribuire un LLM su GPU serverless?

Non sempre. RunPod offre template worker vLLM precostruiti che saltano Docker. Modal costruisce container da una definizione di immagine Python nel codice. Per dipendenze personalizzate scriverai un Dockerfile. Per il serving vLLM standard, la strada precostruita funziona in pochi minuti.

Conclusione

Cinque piattaforme, cinque unità di fatturazione, una tabella normalizzata. La decisione è più semplice di quanto le pagine dei vendor la facciano sembrare:

• Scegli la GPU in base alla VRAM, non alla marca.
• Metti i pesi su un volume, non nell'immagine, a meno che non cambi mai modello.
• Aspettati cold start di 10-30 secondi e pianifica di conseguenza.
• Sotto le ~47.000 richieste/giorno, lo scale-to-zero vince sul costo.
• Il motore di serving dietro l'endpoint è intercambiabile; il base_url è una riga.

Hai un endpoint chiamabile. Prossimo passo: cosa ci sta davanti quando ti servono routing e failover? Il nostro confronto sugli LLM gateway risponde a questo. Oppure parla della tua configurazione con noi.