How do I calculate the VRAM a self-hosted LLM needs?

Three terms. Model weights are parameters multiplied by bytes per parameter — a 70B model at FP16 is about 140GB, at INT8 about 70GB, at INT4 about 35GB. The KV cache is 2 (one key, one value) x layers x KV heads x head dimension x bytes per element, per token, and that whole figure is multiplied again by your context length and by the number of sequences in flight. Then subtract 10-20% for CUDA context, activations, fragmentation and the runtime itself. Weights are a fixed cost you pay once; the KV cache is the term that scales with traffic, and it is the one that decides your concurrency ceiling.

Why does grouped-query attention matter so much for concurrency?

Because the KV cache scales with the number of KV heads, not attention heads. A model with 64 attention heads but only 8 KV heads — standard grouped-query attention in current open-weight models — has an eight-times smaller KV cache than the equivalent multi-head model, which translates almost one-for-one into eight times the concurrent sequences on identical hardware. This is why a modern 70B model can serve more simultaneous users than an older 13B model in some configurations. If you are sizing hardware from a parameter count alone you will get the answer badly wrong; enter the KV head count from the model's config file.

When is self-hosting actually cheaper than paying per token?

Only at high, sustained utilisation. A rented GPU bills every hour whether or not a request arrives, so your effective cost per million tokens is the hourly rate divided by the tokens you actually generate in that hour. At full saturation the economics are often excellent; at 20% duty cycle your real cost per million tokens is five times the headline figure and almost always loses to an API. The break-even throughput shown by this calculator is the number of tokens per second you must sustain, on average and not at peak, for self-hosting to beat the API rate you entered. If your traffic is bursty, compare against that average rather than your peak.

Calcolatore VRAM e concorrenza LLM | Dimensionamento della cache KV a token da $/1 milione

LLM VRAM e calcolatore di concorrenza

✓ Ultima verifica: 23-07-2026· Fonte: configurazioni del modello pubblicate + tariffe di noleggio GPU pubbliche· segnalare il cambiamento →

Ogni decisione di self-hosting inizia con la stessa domanda e quasi nessuno risponde correttamente: quante persone può effettivamente servire questa GPU contemporaneamente e quanto costa realmente un milione di token una volta che l'hardware fattura ogni ora, indipendentemente dal fatto che lo si utilizzi o meno.

I pesi sono la parte facile. L'adattamento del modello è un calcolo su una riga e non dice quasi nulla. Ciò che decide se puoi servire otto o ottanta utenti è la cache KV, una memoria che si adatta alla lunghezza del contesto E con ogni sequenza simultanea in volo. Questo strumento dimensiona entrambi, quindi converte la capacità risultante in un costo per milione di token che puoi trattenere a fronte di una fattura API.

Adattare il modello non è la stessa cosa che servirlo

Il consiglio che trovi ovunque è che un modello 70B su INT4 necessita di circa 35 GB, quindi può stare su una singola scheda da 80 GB con spazio libero. Questo è vero ed è quasi inutile, perché descrive un modello seduto inattivo. Nel momento in cui arrivano le richieste, ogni sequenza in volo alloca la propria cache KV: due tensori per strato, dimensionati in termini di teste KV per dimensione testa, mantenuti per ogni token nel contesto di quella sequenza. A 80 livelli, 8 KV head, 128 dimensioni e FP16 ovvero 327.680 byte per token - un terzo di megabyte - che in un contesto 8K sono circa 2,7 GB per richiesta simultanea. I 45 GB di spazio che sembravano così comodi corrispondono a circa una dozzina di utenti e il tredicesimo viene messo in coda. La pianificazione della capacità per l'inferenza è la pianificazione della cache KV; i pesi stabiliscono semplicemente la quota di iscrizione.

Il conteggio dei KV è il numero che si muove effettivamente

L'attenzione alle query raggruppate è il motivo per cui i moderni modelli open-weight sono utilizzabili e viene regolarmente trascurata da chiunque dimensioni l'hardware in base al conteggio dei parametri. Un modello con 64 teste di attenzione e 8 teste KV memorizza un ottavo della cache di un design multi-testa equivalente, che si converte quasi linearmente in otto volte la concorrenza sulla stessa carta. Prova il preset multi-head 13B sopra rispetto al preset 70B: il modello più piccolo è spesso quello che esaurisce per primo la memoria, il che non è intuitivo finché non vedi dove vanno i byte. Dimezzare la precisione KV a FP8 raddoppia nuovamente la concorrenza con un costo di precisione modesto. Questi due switch spostano la capacità molto di più rispetto all’acquisto di una carta più grande e non costano nulla.

L'utilizzo decide l'economia, non l'hardware

Il tavolo finale è quello che conclude onestamente la maggior parte dei progetti di self-hosting. Un H100 noleggiato costa gli stessi $ 2,50 l'ora alle 3 del mattino senza traffico come nelle ore di punta, quindi il costo reale per milione di token è il numero principale diviso per il ciclo di lavoro medio. Servi con un utilizzo del 20% e pagherai cinque volte quello che suggerisce la cifra ottimistica del calcolatore - e rispetto alle tariffe API delle materie prime per un modello piccolo, non si avvicina. Il self-hosting vince su volumi sostenuti, saturi e prevedibili, su carichi di lavoro con vincoli di residenza dei dati o di latenza che un'API non può soddisfare e su modelli che nessuno vende per token. Perde in caso di traffico intenso, e perde in silenzio, perché la fattura è piatta e la capacità sprecata non viene mai visualizzata come voce di riga. Confronta la conclusione con il Calcolatore LLM e API self-hosted, valuta l'hardware stesso con il file Calcolatore dei costi di inferenza della GPU, e se la risposta è marginale, guarda a modello più piccolo distillato O memorizzazione nella cache tempestiva prima di acquistare un rack.

Come funziona questa calcolatrice

I pesi sono parametri × byte per parametro. La cache KV per token è 2 × livelli × teste KV × dimensione testa × byte KV; moltiplicato per la lunghezza del contesto che fornisce la memoria contenuta in ciascuna sequenza simultanea. La memoria utilizzabile corrisponde alla VRAM totale delle GPU meno una percentuale di sovraccarico di runtime e ciò che rimane dopo che i pesi vengono divisi per la cifra per sequenza per fornire il tetto di concorrenza. Il costo per milione di token è la fattura oraria della GPU divisa per i token effettivamente generati in un'ora, motivo per cui la tabella di utilizzo è importante quanto quella della memoria.

Domande frequenti

Come posso calcolare la VRAM necessaria per un LLM self-hosted?

Tre termini: pesi del modello (parametri × byte per parametro), cache KV (2 × livelli × teste KV × dimensione testa × byte, per token, per lunghezza del contesto, per sequenze simultanee) e sovraccarico del 10-20% per contesto CUDA, attivazioni e frammentazione. I pesi rappresentano una quota di iscrizione fissa; la cache KV è il termine che si adatta al traffico e imposta il limite massimo di concorrenza.

Perché l'attenzione alle query raggruppate è così importante per la concorrenza?

Perché la cache KV si adatta alle teste KV, non alle teste dell'attenzione. Un modello con 64 teste di attenzione ma 8 teste KV ha una cache otto volte più piccola dell'equivalente multi-testa, che converte quasi uno a uno in otto volte le sequenze simultanee sulla stessa scheda. Dimensioni dal file di configurazione del modello, non dal conteggio dei parametri.

Quando il self-hosting è effettivamente più economico del pagamento per token?

Solo in caso di utilizzo elevato e prolungato. Una GPU noleggiata fattura ogni ora indipendentemente dall'arrivo o meno di una richiesta, quindi con un ciclo di lavoro del 20% il costo reale per milione di token è cinque volte la cifra principale. Il throughput di pareggio riportato sopra corrisponde ai token al secondo che devi sostenere in media, non al picco, affinché l'hosting autonomo superi la velocità API inserita.