LLM Calcolatore VRAM per Auto-Hosting
Auto-ospitare un LLM significa eseguire l'inferenza su hardware controllato dall'operatore anziché tramite un'API di terze parti, il che cambia il profilo di costi, controllo dei dati e privacy. Se un modello possa essere eseguito o meno dipende dalla memoria.
Calcolatore di Compatibilità LLM
Il calcolatore stima la VRAM o memoria unificata necessaria per eseguire un modello in locale, basandosi sul modello, la sua precisione, la lunghezza del contesto e l'hardware di destinazione. Restituisce se una configurazione è compatibile, la suddivisione della memoria tra pesi, cache KV e overhead, e i modelli che una determinata GPU o Mac può eseguire. I formati di quantizzazione e le larghezze di precisione seguono la documentazione di Hugging Face Transformers. 1
Consulta la nostra metodologia di calcolo VRAM per LLM auto-ospitati per tutti i calcoli alla base di queste stime.
Hardware per l'auto-hosting: GPU e Apple Silicon
Due numeri decidono l'hardware. La capacità è il gate di compatibilità, e la decodifica è vincolata alla larghezza di banda della memoria, quindi i token al secondo scalano approssimativamente con i GB/s della scheda.
Le righe sopra campionano ciascuna fascia. Il calcolatore include 34 schede in totale, aggiungendo A100, L40S, RTX A6000, AMD Radeon RX 7900 XTX e la linea AMD Instinct. Su 24 a 32 GB, un modello da 70B richiede una quantizzazione pesante più un contesto breve, oppure due schede. Un modello da 671B richiede 640 GB (8×80 GB) come minimo standard. La RTX PRO 6000 è la migliore scheda singola di classe workstation, e il suo prezzo di mercato è salito a circa $13.000 entro metà 2026 da un MSRP di $8.565.2
Apple Silicon e memoria unificata: Su Apple Silicon, la CPU e la GPU condividono un unico pool di memoria, e la GPU indirizza circa il 75% della RAM totale per impostazione predefinita tramite Metal's recommendedMaxWorkingSetSize, un po' meno sui Mac più piccoli. Il limite è aumentabile con sudo sysctl iogpu.wired_limit_mb=, lasciando da 8 a 16 GB per macOS. 3 4 Un Mac da 128 GB espone circa 96 GB alla GPU. L'M3 Ultra, fino a 512 GB, espone circa 384 GB, sufficienti per un modello di classe 400B a 4-bit con margine KV su un singolo dispositivo senza il costo di replicazione multi-GPU. 5 Quel percorso a dispositivo singolo per modelli grandi è il vantaggio di Apple, sebbene AMD Strix Halo (128 GB) e NVIDIA DGX Spark (128 GB) offrano ora anche ampia memoria unificata a basso costo. 6
Motori di serving LLM
La scelta del motore di serving si divide per carico di lavoro piuttosto che per un unico strumento migliore. I motori di serving in produzione usano attenzione paginata e batching continuo per molti utenti concorrenti su GPU da datacenter, mentre i runtime local-first mirano a un singolo utente su desktop, laptop o singola GPU. Il divario appare sotto carico. A 64 richieste concorrenti, vLLM ha servito circa 44 volte più token al secondo rispetto a llama.cpp, il cui tempo al primo token ha superato i 3 minuti. Per un utente singolo i due sono paragonabili. 7
Il calcolatore modella otto motori tra i due schieramenti:
All'interno del livello di produzione, RadixAttention di SGLang riutilizza i prefissi tra richieste, TensorRT-LLM congela il suo budget di attivazione quando il motore viene compilato, e LMDeploy serve W4A16 e MXFP4 in modo economicamente efficiente per InternLM, Qwen e DeepSeek. 8 Sul lato locale, ExLlamaV2 con TabbyAPI regola una larghezza media di bit frazionaria per riempire esattamente una scheda, e MLX usa la memoria unificata Apple così la RAM totale è il budget. Hugging Face TGI è l'unica uscita. È passato alla modalità di manutenzione a dicembre 2025 e il suo repository GitHub è stato archiviato (sola lettura) il 21 marzo 2026, con gli utenti indirizzati a vLLM, SGLang e llama.cpp. 9 10
La maggior parte delle persone incontra questi motori attraverso app per utenti finali che li incorporano. Ollama, LM Studio e AnythingLLM girano tutti su llama.cpp (LM Studio anche su MLX), aggiungendo modelli a comando singolo, un'API localhost compatibile con OpenAI e, per AnythingLLM, RAG su documenti PDF e codebase. Per stelle GitHub come stima approssimativa di adozione al 07-11-2026, Ollama ha 175.925 e vLLM 85.979, entrambi open source, e AnythingLLM 63.120. Le 5.053 di LM Studio provengono dal suo repo CLI open-source (lmstudio-ai/lms) anziché dall'app closed-source, quindi sottostimano l'adozione reale su desktop. 11 12 13 14
Un componente interattivo mappa questi strumenti ai casi d'uso. Integrazioni e ampia compatibilità vanno a Ollama, sviluppatori e alte prestazioni a vLLM, applicazioni RAG locali a AnythingLLM, e sperimentazione adatta ai principianti a LM Studio.
Modelli linguistici di grandi dimensioni open-source
I modelli a pesi aperti pubblicano la loro architettura e i file dei pesi, così chiunque può scaricarli, modificarli ed eseguirli, di solito da Hugging Face. La frontiera auto-ospitabile di metà 2026 è andata ben oltre l'era di Qwen2.5 e Llama-3:
Le colonne totali e attivi sono la distinzione portante. I parametri totali decidono la memoria e il numero di GPU, e i parametri attivi decidono il calcolo. DeepSeek-V4-Flash e GLM-5.2 sono arrivati come pesi aperti nel 2026, Gemma 4 ha ri-licenziato la famiglia sotto Apache 2.0, e GPT-OSS distribuisce esperti MoE in MXFP4 nativo. 15 16 17 18 19
I flagship proprietari (OpenAI GPT-5.6, Google Gemini 3.1 Pro, Anthropic Claude Opus 4.8, xAI Grok 4.5) non possono essere scaricati o auto-ospitati; sono solo API, di solito dietro un endpoint compatibile con OpenAI. Un deployment solo locale rinuncia a ciò che quei modelli fanno meglio su un determinato compito. 20 21 22
Quantizzazione e dimensionamento MoE
La quantizzazione nel 2026 riguarda meno l'arrotondamento dei pesi dopo l'addestramento e più i checkpoint che vengono distribuiti a basso bit per progettazione, insieme a scelte architetturali che riducono la cache prima che la quantizzazione entri in gioco.
Checkpoint nativi a basso bit: I modelli aperti di frontiera sono sempre più distribuiti con consapevolezza della quantizzazione. GPT-OSS distribuisce i suoi esperti MoE in MXFP4 (E2M1 con una scala condivisa a 8 bit, 4.25 bit per parametro), così il 120B occupa circa 63 GB, una GPU da 80 GB, mentre una stima ingenua in BF16 richiederebbe circa 234 GB su tre GPU. DeepSeek-V3 e R1 sono distribuiti nativamente in FP8 a circa 1 byte per parametro. I pesi dovrebbero essere dimensionati sul dtype effettivo del checkpoint, non sul conteggio dei parametri. 23 24
La trappola dei bit effettivi GGUF: I file GGUF mescolano la precisione, con scale FP16 per blocco e tensori di embedding e output non quantizzati, quindi il nome è un minimo piuttosto che la dimensione effettiva. Q4_K_M è circa 4.9 bit effettivi (0.61 byte per parametro), non 4.0. Q8_0 è 8.5 bit (1.06 byte per parametro), non 8.0. Un calcolatore basato sul numero di bit sottostima i pesi di circa il 20% a Q4 e del 6% a Q8. Gli IQ-quant come IQ4_XS (circa 4.25 bit) ora eguagliano la qualità Q4_K_M con una dimensione inferiore. 25
Quantizzazione della cache KV: Abbassare il dtype KV scala l'intera cache linearmente ed è indipendente dalla precisione dei pesi. FP8 (e4m3) KV la dimezza (Llama-3-8B a 128k, batch 1, da 16.0 GiB BF16 a 8.0 GiB FP8) con qualità sostanzialmente gratuita. INT4 la riduce a un quarto ma richiede una valutazione. In vLLM è un flag (--kv-cache-dtype fp8). 26
L'attenzione come risparmio di memoria: L'attenzione latente multi-testa (MLA, usata da DeepSeek) memorizza nella cache un singolo latente condiviso a basso rango (circa 576 elementi per token per layer) invece di chiavi e valori per testa, circa 30 volte più piccolo della lettura nominale a 128 teste. È ciò che permette a un modello da 671B di servire un contesto di 128k con circa 8.6 GiB di KV. L'attenzione a finestra scorrevole e locale-globale (Gemma 2 e 3, GPT-OSS, Llama 4) limita la maggior parte dei layer a una finestra fissa invece che al contesto completo, riducendo la KV a contesto lungo di un fattore da 10 a 40 volte rispetto a una stima ingenua tutto-globale. Questi sono fissi per famiglia di architettura, non parametri regolabili. 27
Offloading e sharding: Quando i pesi superano la memoria della GPU, l'offloading sposta le parti inattive, come gli esperti MoE non utilizzati, tra la memoria GPU e la RAM di sistema più lenta, scambiando token al secondo per la capacità di essere eseguito. 28 Lo sharding divide un modello su più dispositivi o livelli di memoria, che è come un modello da 671B si distribuisce su un nodo da 8 GPU. Entrambi estendono la portata dell'hardware fisso a un costo di larghezza di banda.
Vantaggi e compromessi dell'auto-hosting
Il caso a favore dell'auto-hosting è il controllo dei dati, il costo a volume e la libertà di configurazione. Il caso contrario è il costo dell'hardware, l'onere operativo e il divario con i modelli proprietari.
Residenza dei dati e conformità: Il trasferimento transfrontaliero dei dati è il fattore trainante della conformità. Sotto il GDPR, l'invio di dati personali al di fuori dell'UE può attivare salvaguardie legali, obblighi contrattuali o restrizioni. L'EU IA Act aggiunge un secondo livello, ma è in fase di introduzione graduale piuttosto che pienamente in vigore. A metà 2026, i divieti (applicabili dal 2 febbraio 2025) e gli obblighi per i modelli di IA per uso generale (GPAI) (dal 2 agosto 2025) sono già in vigore, mentre i requisiti ad alto rischio relativi a gestione del rischio, auditabilità e governance sono rinviati, al 2 dicembre 2027 per i sistemi ad alto rischio autonomi dell'Allegato III e al 2 agosto 2028 per i sistemi integrati dell'Allegato I secondo il pacchetto Digital Omnibus 2025-26. 29 30 31 Eseguire l'inferenza nella giurisdizione, su una rete controllata, mantiene i dati sensibili fuori dalle mani di terze parti, che è il caso dell'IA sovrana per finanza, sanità e settore pubblico.
Costo e controllo: L'auto-hosting parte costoso, con GPU consumer o un piccolo server, ma l'inferenza locale può ridurre le tariffe API ricorrenti per team che generano alti volumi di richieste. Elimina anche il vendor lock-in e i limiti imposti sulla finestra di contesto, le impostazioni di inferenza e l'integrazione, e dà accesso diretto ai pesi per il fine-tuning su dati privati.
I compromessi: La memoria della GPU è il limite vincolante, e alcuni carichi di lavoro richiedono ancora da 16 a 48 GB di VRAM, fuori dalla portata dei team più piccoli. Il deployment aggiunge gestione delle dipendenze, risoluzione dei problemi CUDA e kernel, monitoraggio e aggiornamenti che un provider cloud gestirebbe altrimenti. Le prestazioni sono responsabilità dell'operatore, dal batching e sharding all'utilizzo dell'hardware. E i modelli proprietari più forti rimangono solo API, quindi un deployment locale accetta un divario di capacità sui compiti in cui sono leader.
Metodologia di calcolo VRAM per LLM auto-ospitati
L'impronta di memoria di un modello è la somma di quattro termini che sono calcolati indipendentemente e sommati, non una singola cifra scalata sul conteggio dei parametri:
VRAM_total = Weights + KV cache + Activations + Overhead
L'errore di stima più comune riduce gli ultimi tre termini a un margine fisso del 20% sui pesi. Questo è vicino per una dimensione di modello e sbagliato per le altre, perché i tre termini scalano in modo diverso. 32
Pesi: La memoria dei pesi è parametri per byte-per-parametro. BF16 e FP16 memorizzano 2.0 byte per parametro, e FP8 e INT8 memorizzano circa 1.0. La trappola è il 4-bit, che non è 0.5 byte per parametro. Il vero INT4 raggruppato (GPTQ, AWQ) arriva a 0.52–0.55, e GGUF Q4_K_M è circa 0.61 byte per parametro (4.9 bit effettivi, non 4.0). GGUF Q8_0 è 8.5 bit (1.06 byte per parametro), non 8.0. Assumere 0.5 sottostima un modello da 70B di circa 8 GB, il che ribalta un verdetto di compatibilità. 33
Mixture-of-experts dimensiona ogni esperto, non quelli attivi: Tutti i pesi degli esperti rimangono residenti in VRAM anche se solo alcuni si attivano per token. Mixtral-8x7B richiede circa 28 GB a Q4 per gli interi 46.7B parametri, non i 13B attivi. I parametri totali determinano la memoria e il numero di GPU, e i parametri attivi determinano il calcolo. Un calcolatore che dimensiona sui parametri attivi fa falsamente rientrare grandi modelli MoE.
Cache KV: La cache chiave-valore è 2 x n_layers x n_kv_heads x head_dim x seq_len x batch x bytes_per_element. La maggior parte dei modelli attuali usa l'attenzione a query raggruppate (GQA), dove molte teste di query condividono poche teste KV, quindi vengono memorizzate nella cache n_kv_heads coppie, il che riduce la cache di 4 volte (Llama-3-8B) a 8 volte (Llama-3-70B) rispetto all'attenzione multi-testa completa. Sia head_dim che n_kv_heads sono letti dal config.json di ciascun modello piuttosto che derivati dalla dimensione nascosta e dal numero di teste, poiché famiglie come Gemma (head_dim 256) e Qwen3 (128) sarebbero altrimenti dimensionate erroneamente di circa 2 volte. La cache cresce linearmente sia con la lunghezza del contesto che con la dimensione del batch, e a contesto lungo rivaleggia o supera i pesi. Llama-3-8B memorizza nella cache 128 KiB per token, quindi a contesto 128k e batch 1 una cache KV FP16 è di 16.0 GiB, pari ai 16 GB di pesi BF16. Una cache KV FP8 la dimezza. 34
L'overhead è un minimo fisso, non una percentuale: L'overhead del framework è un minimo fisso per GPU (contesto CUDA e kernel, circa 1-2 GB per GPU) più una piccola frazione limitata, non una quota dei pesi. Un fisso 20% sottostima i modelli piccoli, dove il solo contesto CUDA può superare il 20% di un modello da 6 GB, e sovrastima quelli grandi, dove un modello da 140 GB non ha bisogno di 28 GB di contesto. Il minimo a pezzi è il modello accurato, e il 20% fisso funziona come stima rapida. 35
Attivazioni e il motore di serving: Il termine di attivazione è transitorio. Durante la decodifica, un token alla volta, è piccolo e rientra nel minimo di overhead, ma il prefill elabora l'intero prompt in una volta, quindi il suo picco di attivazione scala con la dimensione del batch e la lunghezza del prompt. Il minimo stesso dipende dal motore. I server paginati (vLLM, SGLang) riservano una quota fissa di ciascuna scheda tramite un'impostazione di utilizzo della memoria, circa il 10% al valore predefinito 0.90, e inseriscono i pesi e la KV nel resto. I runtime non paginati (llama.cpp, Ollama) mantengono invece un buffer di calcolo fisso di circa 1-2 GB. Dimensionare entrambi allo stesso modo sbaglia di qualche GB.
Più GPU non si dividono in modo netto: Due schede da 24 GB non sono 48 GB di spazio utilizzabile. Sotto parallelismo tensoriale i pesi e la cache KV si dividono sulle N schede (W/N e KV/N), ma le attivazioni, il contesto CUDA e i buffer di comunicazione NCCL sono replicati su ogni scheda, quindi l'impronta totale è maggiore di una stima a dispositivo singolo dello stesso totale. Quel costo di replicazione è il motivo per cui un 70B che richiede 43 GB di pesi sta su due schede da 24 GB con un contesto breve, e perché il controllo sicuro è il totale per GPU piuttosto che il totale diviso per il numero di GPU.
I quattro termini interagiscono al confine di compatibilità. Una configurazione risulta Compatibile quando la memoria richiesta è al di sotto del 90% di quella utilizzabile, Stretto nel 10% superiore della capacità, e Non compatibile sopra l'utilizzabile. I server paginati trattengono già quel 10% attraverso l'impostazione di utilizzo. Gli esempi seguenti usano Llama-3 su hardware comune, con llama.cpp sulle schede consumer:
A contesto 128k la cache KV eguaglia i pesi, quindi la lunghezza del contesto, non il conteggio dei parametri, decide la compatibilità. L'ultima riga è compatibile perché i pesi Q4 (~405 GB) stanno sotto i 640 GB a contesto 8k. Il vantaggio di MLA è a contesto lungo, dove mantiene la KV di un modello da 671B abbastanza piccola da servire 128k.
Aggiungi come fonte preferitaUlteriori letture
- Quantizzazione LLM: BF16 vs FP8 vs INT4
- Motori di Inferenza LLM: vLLM vs LMDeploy vs SGLang
- Benchmark Concorrenza GPU: H100 vs H200 vs B200 vs MI300X
- Benchmark Multi-GPU: B200 vs H200 vs H100 vs MI300X
- I Migliori 60+ Provider Cloud GPU
- LLM Cloud vs LLM Locali
- Prezzi LLM: I Migliori 15+ Provider Confrontati
- Guida al Fine-Tuning di LLM per Aziende
FAQ
Un LLM auto-ospitato è un modello linguistico di grandi dimensioni utilizzato per applicazioni LLM che viene eseguito interamente su hardware che controlli tu (come il tuo personal computer o server privato) anziché affidarsi a un servizio cloud di terze parti.
Le tecniche includono l'uso di framework come llama.cpp, librerie come Hugging Face transformers, app user-friendly (Ollama, LM Studio), quantizzazione dei modelli (es. GGUF, GPTQ) per ridurre il fabbisogno di risorse, parallelismo dei modelli per distribuire modelli grandi su più dispositivi, e motori di inferenza ottimizzati (come vLLM).
Sì, strumenti come vLLM, Ollama e LM Studio possono eseguire server locali in grado di gestire richieste multiple (spesso concorrenti). È simile a come operano le API cloud, spesso usando il batching per l'efficienza.
No, non hai bisogno di permessi di accesso esterni o chiavi API da un provider per un LLM auto-ospitato. Poiché lo ospiti tu stesso, hai accesso diretto; puoi opzionalmente impostare la tua autenticazione per il tuo server locale se necessario.
Link Esterni
Cita questa ricerca
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{LLM Calcolatore VRAM per Auto-Hosting}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/self-hosted-llm}},
note = {AIMultiple. Consultato il 12 Luglio 2026}
}Collegamenti di riferimento
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.