← Resources
By Jordan Malik
— Staff Engineer, Inference
·
· GUIDE
Quando ospitare gli LLM in proprio conviene davvero rispetto a un'API
Ospitare un LLM in proprio conviene rispetto a un'API solo oltre un volume di token che dipende interamente dall'utilizzo della GPU: non esiste un unico punto di pareggio. Questa guida illustra i conti reali, perché batching e quantizzazione sono decisivi, il costo operativo nascosto e perché l'approccio ibrido è di solito la risposta giusta.
Non esiste un unico punto di pareggio
La risposta onesta alla domanda «quando conviene l'auto-hosting?» è un intervallo condizionato dall'utilizzo, non un numero. Ecco perché le stime pubblicate divergono di ordini di grandezza: partono da prezzi della GPU, tassi di utilizzo e API di confronto diversi.
La regola utile: l'auto-hosting tende a battere le API premium già con un volume sostenuto relativamente modesto (qualche milione di token al mese su una GPU ben sfruttata), ma battere le API economiche richiede molto di più (da decine a centinaia di milioni al mese). Un ordine di grandezza comune si colloca attorno a qualche milione di token al giorno, in modo sostenuto. Al di sotto, un'API vince quasi sempre.
I conti della GPU
Fare auto-hosting significa noleggiare o possedere una GPU, e quel costo fisso è ciò che il volume di token deve «riempire». Una H100 on demand costa circa 1,50–3,00 $/ora sui cloud specializzati (di più sugli hyperscaler), quindi una H100 dedicata 24/7 si aggira sull'ordine dei 1.000–5.000 $ al mese a seconda del livello del fornitore.
Quella quota mensile è fissa, che tu la usi o no: ecco perché il costo per milione di token è basso solo ad alto utilizzo. Ben sfruttato, un modello di medie dimensioni può scendere ben al di sotto di un dollaro per milione di token; al 10% di carico, il costo reale per token sale di circa dieci volte, abbastanza da rendere l'auto-hosting più costoso di un'API premium. Una GPU inattiva è il modo più rapido per perdere l'argomento del costo.
Batching e quantizzazione sono decisivi
Due leve spostano il punto di pareggio più di qualsiasi altra cosa. Il batching continuo (grazie ai server di inferenza moderni) è il motore economico: servire molte richieste contemporaneamente sulla stessa GPU può ridurre drasticamente il costo per token; passare da una richiesta alla volta a batch di grandi dimensioni può migliorare il throughput di ordini di grandezza. Il traffico irregolare e a bassa concorrenza non riempie i batch e rende diverse volte peggio rispetto al picco, motivo per cui i carichi di lavoro a raffica si auto-ospitano male.
[La quantizzazione](/articles/llm-quantization-explained-gguf) è l'altra leva: FP8 raddoppia all'incirca il throughput con una perdita di qualità minima, e INT4 può triplicarlo all'incirca, riducendo il modello quanto basta per farlo entrare in una GPU più piccola ed economica. Insieme, batching e quantizzazione possono far variare il costo per token di diversi fattori.
Il costo nascosto: le operazioni
La bolletta della GPU non è tutta la bolletta. Le operazioni aggiungono abitualmente diverse volte il costo lordo dell'hardware: un ingegnere MLOps comporta uno stipendio a sei cifre, e ogni ciclo di aggiornamento del modello — riquantizzazione, test, nuovo deployment — richiede settimane di lavoro. I modelli open-weight «gratuiti» possono nascondere centinaia di migliaia di dollari all'anno in ingegneria, una volta che si conteggiano il server di inferenza, la gestione di driver e CUDA, l'autoscaling e il monitoraggio.
È questa la voce che affonda i conti ingenui dell'auto-hosting. Il costo per token da scheda tecnica presuppone che la GPU si gestisca da sola; nella realtà, qualcuno deve tenerla in funzione, e quella persona non è gratis.
Quando l'API vince nettamente (e i fattori non legati al costo)
Un'API è la scelta giusta per volumi bassi o irregolari, traffico imprevedibile, team senza MLOps interni e qualsiasi esigenza di modelli di qualità frontier che non si riesce a eseguire in proprio. Secondo una stima, un'API è la scelta migliore per la grande maggioranza dei casi d'uso, e i prezzi delle API continuano a scendere, il che spinge il punto di pareggio dell'auto-hosting sempre più in alto nel tempo.
Due fattori esulano completamente dai conti del costo: latenza e privacy. L'auto-hosting vince per la residenza dei dati, i carichi di lavoro regolamentati e una latenza prevedibile in regione, a prescindere dall'economia dei token; vedi la nostra [guida sull'on-premise](/articles/on-premise-ai-for-enterprise). Questi fattori possono giustificare l'auto-hosting anche quando i conti del puro costo non lo fanno.
Instradare per economia con osFoundry
La risposta pragmatica è ibrida: instradare per criteri economici, non per ideologia. I volumi alti e costanti spettano all'inferenza locale o propria, dove riempire i batch di una GPU abbassa il costo per token. I carichi di volume medio e prevedibili si adattano a un endpoint GPU dedicato: un throughput che sfrutta bene l'utilizzo, senza possedere hardware né sostenere l'intero moltiplicatore operativo. Il traffico irregolare, basso o imprevedibile, e tutto ciò che richiede qualità frontier, rimane su API BYOK a pagamento per token.
osFoundry gestisce automaticamente le leve che spostano davvero il punto di pareggio — quantizzazione, batching e routing per livello — e consente allo stesso carico di lavoro di girare in locale, su un endpoint dedicato o tramite un'API BYOK. Così catturi i risparmi dove l'auto-hosting vince senza dover gestire tu stesso CUDA, l'autoscaling o i conti del ciclo di utilizzo. (La nostra [analisi dei costi BYOK](/articles/byok-vs-managed-ai-cost-breakdown) copre il lato API dell'equazione.)
Frequently asked questions
- A quale volume di token l'auto-hosting diventa più economico di un'API?
- Dipende dall'utilizzo, quindi non esiste un unico numero. In linea di massima, l'auto-hosting può battere le API premium con qualche milione di token al mese su una GPU ben sfruttata, ma battere le API economiche richiede da decine a centinaia di milioni al mese. Una soglia indicativa comune è qualche milione di token al giorno, in modo sostenuto; al di sotto, di solito vince un'API.
- Quanto costa tenere una H100 al mese?
- Una H100 on demand costa circa 1,50–3,00 $/ora sui cloud GPU specializzati (di più sugli hyperscaler), quindi un'istanza dedicata 24/7 si aggira intorno ai 1.000–5.000 $ al mese a seconda del livello del fornitore. Quel costo fisso è ciò che il volume di token deve coprire perché l'auto-hosting convenga.
- Perché l'utilizzo della GPU fa la differenza nell'economia dell'auto-hosting?
- Perché la GPU costa lo stesso, sia che sia occupata sia che sia inattiva. Ben sfruttata, il costo per milione di token può scendere sotto un dollaro; a basso carico (diciamo il 10%), il costo reale per token sale di circa dieci volte, rendendo spesso l'auto-hosting più costoso di un'API premium. Una GPU inattiva è puro spreco: l'utilizzo è la singola variabile più importante.
- L'auto-hosting è più economico di un'API economica, come un piccolo modello ospitato?
- Di solito solo a volumi molto elevati. Le API economiche hanno prezzi aggressivi, quindi batterle con l'auto-hosting richiede in genere da decine a centinaia di milioni di token al mese con buon utilizzo. Contro le API premium, l'incrocio avviene molto prima. Confronta con l'API specifica che useresti altrimenti, non con una tariffa generica.
- Quanto riduce la quantizzazione il costo dell'auto-hosting?
- Sostanzialmente. FP8 raddoppia all'incirca il throughput con una perdita di qualità minima, e INT4 può triplicarlo all'incirca, riducendo il modello per farlo entrare in una GPU più piccola ed economica. Su un modello grande, questo può dimezzare o più il costo per milione di token: la quantizzazione è una delle leve di costo a maggior impatto per l'auto-hosting.
- Quali costi nascosti comporta ospitare un LLM in proprio?
- Le operazioni. Oltre alla bolletta della GPU, si paga l'ingegneria MLOps (uno stipendio a sei cifre), i cicli di aggiornamento del modello (settimane di lavoro ciascuno) e il server di inferenza, la gestione dei driver, l'autoscaling e il monitoraggio. Queste voci aggiungono abitualmente diverse volte il costo lordo dell'hardware e sono proprio ciò che la maggior parte dei calcoli di pareggio ingenui tralascia.
- Posso combinare auto-hosting e API per ottimizzare i costi?
- Sì: l'approccio ibrido è di solito il più intelligente. Esegui i volumi alti e costanti su inferenza locale o propria, i carichi di volume medio e prevedibili su un endpoint dedicato, e il traffico irregolare o a basso volume (più tutto ciò che richiede qualità frontier) su un'API a pagamento per token. Instradare per economia cattura i risparmi dell'auto-hosting senza pagare GPU inattive nei lavori a raffica.
Sources