GPU cloud per inference LLM self-hosted: Scaleway, Lambda Labs e RunPod a confronto per PMI italiane

A metà febbraio 2026 ho dedicato tre settimane della mia sandbox personale al confronto operativo di tre provider GPU cloud per un use case specifico: inference di Llama 4 70B quantizzato a 4 bit, volume di circa 8 milioni di token al giorno, latenza p95 target sotto i 4 secondi per chunk da 1.024 token. Ho girato lo stesso workload identico - stessa image Docker, stesso modello quantized, stessi benchmark - su Scaleway, Lambda Labs e RunPod, registrando costi orari effettivi, latenza osservata, stabilità delle istanze, qualità del support quando qualcosa si rompeva. Il risultato operativo non è quello che mi aspettavo leggendo i pricing ufficiali: il provider "più economico sulla carta" è finito terzo in costo effettivo sul workload reale, mentre il provider "più caro sulla carta" è finito secondo grazie a performance che ha compensato il prezzo orario. Per chi sta valutando self-hosting di LLM medi e grandi nel 2026 - cioè da Llama 3 70B in su, verso Mistral Large, Llama 4 70B - la scelta del provider GPU ha impatto superiore al 40% sul costo totale operativo, e la checklist che uso per prendere la decisione è stratificata su sei dimensioni che non sempre il marketing dei provider rende trasparenti.

Perché Hetzner, OVH, Contabo non bastano per LLM medi?

I provider europei generalisti che uso regolarmente per VPS di dominio business - Hetzner, OVH, Contabo, Digital Ocean - offrono GPU limitate nel 2026. Hetzner ha opzioni con GPU consumer (RTX 4000/5000) adatte a workload leggeri (modelli 7B-13B); OVH offre alcune H100 ma con availability molto limitata; Contabo non ha GPU in catalog; Digital Ocean ha un'offerta GPU Droplet con H100 ma con pricing elevato. Per workload che richiedono A100 80GB o H100 80GB in modo continuativo - che è quello che serve per inference di modelli 70B+ con context ragionevole - questi provider generalisti non sono competitivi in disponibilità o prezzo.

I provider GPU-specializzati hanno invece il modello di business costruito attorno al workload AI. Scaleway è il player europeo con offerta H100 DGX seriously competitive e conformità GDPR nativa. Lambda Labs è il riferimento US-based con le migliori performance raw ma data residency fuori UE. RunPod è il provider di spot instance più aggressivo, perfetto per batch non latency-critical ma con reliability inferiore per carichi continuativi. Sono tre modelli di business diversi, e la scelta tra loro è una scelta sui trade-off, non sulla qualità.

Prima verifica: conformità GDPR e data residency

La prima domanda che faccio quando un cliente PMI valuta self-hosting di LLM è: i dati che vuoi processare sono soggetti a vincoli di residenza europea? Se sono dati personali di utenti italiani, la risposta è quasi sempre sì - il GDPR permette trasferimento extra-UE solo sotto condizioni specifiche (adequacy decision, SCC, BCR), e per il workload AI le Standard Contractual Clauses con un provider US non sono banali da gestire. In più, dal 2 agosto 2026 l'AI Act entra in fase di enforcement pieno e introduce requisiti di transparency e risk assessment che si aggiungono al GDPR esistente.

Per workload con dati personali italiani Scaleway è praticamente l'unica opzione europea seria dei tre. I data center sono a Parigi (EU-FR-PAR), Amsterdam (EU-NL-AMS), e Varsavia (EU-PL-WAW); la governance è francese (CNIL come regulator principale), il data processing agreement è GDPR-native senza side clause. Lambda Labs e RunPod hanno compliance US-based e non sono percorribili senza complicazioni se i dati sono personali europei.

Per workload con dati non-personali - documentazione tecnica pubblica, codice open source, analisi di corpora generici - la conformità GDPR non è vincolo e Lambda Labs e RunPod diventano valutabili alla pari di Scaleway.

Seconda verifica: GPU disponibile per il tuo workload

Le GPU rilevanti nel 2026 sono essenzialmente tre: A100 80GB (ancora diffusa, buon rapporto performance/prezzo), H100 80GB (frontier per modelli 70B+), H200 141GB (ancora scarsa, solo per workload che richiedono context molto lungo). Le GPU consumer (RTX 4090/5090) vanno bene per modelli piccoli (7B-13B) ma non per volumi seri.

Su Scaleway ho disponibilità regolare di H100 80GB nel pool GPU-H100-1-80G e accesso a cluster H100-DGX 8-GPU per workload distribuiti; il time-to-provision medio nella mia esperienza è 2-8 minuti. Su Lambda Labs l'availability H100 è eccellente ma il wait time per on-demand può variare da istantaneo a alcune ore durante i picchi - la loro offerta reserved garantisce disponibilità ma richiede commit a medio termine. Su RunPod le H100 sono disponibili quasi sempre ma come spot instance (rischio eviction) o community cloud (qualità variabile del singolo nodo).

La mia checklist operativa qui chiede tre verifiche: (1) il provider ha la GPU che serve a te, in quantità, in availability continua; (2) il time-to-provision è compatibile con il tuo workflow (per batch notturni 8 minuti va bene, per dev iteration vuoi sotto i 2); (3) il modello di reservation (on-demand, reserved, spot) si sposa con il tuo usage pattern.

Se stai pianificando self-hosting di LLM in un'infrastruttura PMI e vuoi capire quale provider è compatibile con il tuo perimetro di compliance e con il tuo volume, nel mio hub dedicato all'integrazione AI per aziende trovo raccolti gli articoli tecnici con metodologia applicata che uso nei progetti di consulenza infrastruttura.

Terza verifica: costi effettivi sul tuo workload

I pricing ufficiali non sono confrontabili direttamente. Scaleway pubblica pricing per hour di GPU istanza; Lambda Labs pubblica pricing per hour diverso per on-demand e reserved; RunPod pubblica pricing per hour con spot molto aggressivo. Ma il costo rilevante non è €/ora, è €/milione di token, perché è lì che paghi la inference effettiva del tuo workload.

Sul benchmark che ho fatto (Llama 4 70B quantizzato 4-bit, 8M token/giorno, Q1 2026) i costi effettivi sono stati approssimativamente: Scaleway €0,95 per milione di token output, Lambda Labs €0,78, RunPod on-demand €0,68, RunPod spot €0,42 ma con eviction rate del 18% che richiede retry logic con conseguente aumento del costo effettivo al €0,58. Le oscillazioni sono grosse e dipendono dal tuo workload specifico - throughput sostenuto, bursty, batch, ogni pattern ha il suo sweet spot. Il solo modo di avere numeri affidabili per la tua decisione è girare un benchmark reale - non synthetic - per almeno due settimane su ogni provider candidato.

Il hidden cost che non appare nei pricing ma pesa seriamente è il costo di egress dati: se estrai risultati da 50 GB al giorno dal provider al tuo server, alcuni provider ti addebitano egress mentre altri lo includono. Scaleway include egress EU, addebita verso USA. Lambda Labs include tutto. RunPod addebita egress oltre una soglia generosa ma documentata. Per workload con output grandi (tipicamente image generation o document processing), l'egress può rappresentare il 15-30% del costo totale.

Quarta verifica: affidabilità e stability operativa

Un provider con GPU economiche ma uptime irregolare ti costa più di uno con GPU più care ma stabili. Nella mia esperienza Scaleway ha avuto uptime SLA-conforming stabile (99,9%+) sulle istanze H100 dedicate; le istanze shared o spot equivalenti sono meno affidabili ma più economiche. Lambda Labs ha avuto uptime simile ma qualche episodio di degradation temporanea durante peak demand - le sessioni che avevo aperto sono rimaste, ma il provision di nuove istanze ha avuto latenza. RunPod ha avuto uptime variabile per natura - le spot instance sono eviction-prone by design, le community cloud dipendono dalla qualità del singolo nodo operator.

Per workload production-critical - dove un'ora di downtime ha costo business - la scelta tende verso Scaleway dedicated. Per workload batch dove l'eviction si può gestire con retry, RunPod spot è imbattibile. Per workload di sviluppo/sperimentazione con sessioni medio-lunghe, Lambda Labs bilancia bene.

Quinta verifica: tooling e developer experience

Un provider con documentazione chiara, API mature, management console ragionevole accorcia il tempo dev e riduce errori operativi. Scaleway ha API REST pulite, Terraform provider ufficiale maintained, console web ottima per billing visibility; l'onboarding richiede 2-3 ore per un sistemista esperto. Lambda Labs ha API più limitata ma un'esperienza developer-first che rende molto veloce il provisioning di istanze standalone; per workflow CI/CD integration l'API è adeguata ma meno ricca. RunPod ha console con più complessità operativa (per scegliere tra community e secure cloud, tra spot e on-demand, tra diversi tier di storage); la learning curve è più ripida ma la flessibilità è superiore.

Il tooling secondario che conta è l'integrazione con orchestratori LLM-specific: vLLM, TGI (Text Generation Inference di Hugging Face), Ollama. Tutti e tre i provider permettono il deploy via container Docker standard, quindi il porting di un workload tra provider è tipicamente questione di ore, non settimane - un vantaggio significativo contro il lock-in.

Sesta verifica: support e response time

Quando qualcosa si rompe alle 23:00 di un venerdì, il support del provider fa la differenza tra un incident gestito in un'ora e uno che si trascina fino a lunedì mattina. Scaleway ha support via ticket con response time documentato (nella mia esperienza 2-6 ore per tier standard, sotto l'ora per tier enterprise) e support in inglese e francese. Lambda Labs ha community support robusto su Discord e support ticket con response time variabile; per enterprise customer (non PMI tipiche) c'è support dedicato più responsive. RunPod è primarily self-service, con Discord community attivo ma support ticket che può richiedere giorni; per workload critical non lo sceglierei su questa dimensione.

Sicurezza operativa sulle istanze GPU cloud

Un aspetto troppo spesso trascurato è la security posture dell'istanza GPU. Una GPU cloud public-facing con ollama serve aperto sulla porta 11434 verso Internet è un invito aperto a crypto mining non autorizzato, denial-of-wallet su inference costosa, esfiltrazione di prompt e output. La checklist che applico per ogni provisioning di istanza GPU è rigorosa: (1) firewall iptables/nftables che espone solo la porta SSH (22) e opzionalmente una porta di management privata tramite VPN; (2) ollama e servizi di inference sempre in bind su 127.0.0.1, accessibili solo tramite reverse proxy o tunnel SSH; (3) API key di autenticazione applicativa obbligatoria su ogni endpoint anche se localhost; (4) rate limiting a livello di reverse proxy per prevenire denial-of-wallet; (5) monitoring del consumo GPU con alert se l'utilizzo eccede soglie tipiche del tuo workload - un'anomalia di utilization è spesso il primo segnale di compromissione.

Un provider che non permette configurazione firewall granulare è automaticamente inadatto per workload production; tutti e tre i provider analizzati permettono configurazione network adeguata, ma il default setup varia - su RunPod in particolare il default di alcune template community lascia porte aperte che andrebbero chiuse.

Cosa scelgo nella mia pipeline e perché

Il default che propongo a clienti PMI italiane con dati personali europei è Scaleway - conformità GDPR out-of-the-box, availability H100 buona, costi accettabili, support serio. Il premium di €0,17 per milione di token rispetto a Lambda Labs è assorbito dall'azzeramento del problema di cross-border data transfer che altrimenti richiederebbe SCC e DPIA specifici.

Per workload batch non-personali dove il costo è driver primario e la eviction è gestibile con retry, integro RunPod spot come second tier - tipicamente per rigenerazione di embedding batch notturni su documenti tecnici pubblici. La architecture ibrida con Scaleway per workload mission-critical e RunPod per batch di riempimento è quella che nel mio modeling di costo tipico riduce il totale operativo del 25-35% rispetto a usare un solo provider.

Per workload R&D che richiede flessibilità massima e dove un giorno di downtime è accettabile, Lambda Labs è il mio default per la developer experience superiore. Cambia il use case, cambia il provider ottimale.

Il report Deloitte "State of AI in the Enterprise 2026" del 21 gennaio 2026 osserva che il 83% delle aziende considera ormai strategica la sovereign AI - una categoria che include la scelta di provider GPU compatibili con i requisiti di data residency nazionali. Per le PMI italiane questo è rilevante: la scelta del provider GPU non è solo questione di costo o performance, è parte di una strategia di sovranità digitale che va decisa al momento dell'architettura, non quando il primo audit GDPR arriva a picchiare sulla porta.

Se la tua azienda sta valutando self-hosting di LLM e vuoi una qualificazione rapida di quale provider GPU è compatibile con il tuo perimetro di compliance e con i tuoi volumi previsti, il modulo di preventivo gratuito ti risponde in sette domande - circa due minuti - e ti dice se il tuo scenario rientra nel mio ambito o ti indirizzo verso figure più adatte. Per il lavoro preliminare sull'infrastruttura di base che ospiterà l'integrazione ibrida VPS+GPU cloud, trovi un inquadramento operativo nel mio articolo su migrazione sicura VPS unmanaged zero downtime e sulle strategie di backup VPS avanzate. La scelta del provider GPU è una decisione architetturale che influenza tutto il resto: la sbagli una volta e paghi il costo per dodici mesi. La fai bene e diventa enabler silenzioso di un workload AI sostenibile.