LLM Calcolatore VRAM per il self-hosting

Il self-hosting di 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. Il fatto che un modello possa girare dipende interamente dalla memoria.

Calcolatore di compatibilità LLM

Il calcolatore stima la VRAM o la memoria unificata necessaria a un modello per girare in locale, in base al modello, alla precisione, alla lunghezza del contesto e all'hardware di destinazione. Indica se una configurazione è compatibile, la suddivisione della memoria tra pesi, cache KV e overhead, e i modelli che una determinata GPU o un Mac possono eseguire. I formati di quantizzazione e le larghezze di precisione seguono la documentazione Transformers di Hugging Face. ¹

Consulta la nostra metodologia di calcolo della VRAM per LLM self-hosted per tutti i calcoli alla base di queste stime.

Hardware per il self-hosting: GPU e Apple Silicon

Due numeri decidono l'hardware. La capacità è il criterio di compatibilità, e la decodifica è limitata dalla larghezza di banda della memoria, quindi i token al secondo scalano approssimativamente con i GB/s della scheda.

Le righe sopra rappresentano un campione di ogni fascia. Il calcolatore include in tutto 34 schede, aggiungendo A100, L40S, RTX A6000, AMD Radeon RX 7900 XTX e la linea AMD Instinct. Su 24–32 GB, un modello da 70B richiede una quantizzazione pesante e 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 prezzo di listino di $8.565.²

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 il recommendedMaxWorkingSetSize di Metal, un po' meno sui Mac più piccoli. Il limite può essere alzato 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, ne espone circa 384 GB, sufficienti per un modello di classe 400B a 4 bit con margine per la KV su un singolo dispositivo, senza il costo di replica multi-GPU. ⁵ Questo percorso a dispositivo singolo per i modelli di grandi dimensioni è il vantaggio di Apple, anche se AMD Strix Halo (128 GB) e NVIDIA DGX Spark (128 GB) ora offrono anche grandi memorie unificate a basso costo. ⁶

Motori di serving LLM

La scelta del motore di serving dipende dal carico di lavoro piuttosto che da un unico strumento migliore. I motori di serving di produzione usano attenzione paginata e batching continuo per molti utenti concorrenti su GPU da datacenter, mentre i runtime local-first puntano a un singolo utente su desktop, laptop o una sola GPU. Il divario emerge sotto carico. Con 64 richieste concorrenti, vLLM ha servito circa 44 volte più token al secondo di llama.cpp, il cui tempo al primo token ha superato i 3 minuti. Per un singolo utente i due sono comparabili. ⁷

Il calcolatore modella otto motori nei due schieramenti:

All'interno del livello production, RadixAttention di SGLang riutilizza i prefissi tra richieste, TensorRT-LLM blocca il proprio budget di attivazione alla build del motore e LMDeploy serve W4A16 e MXFP4 in modo efficiente in termini di costi per InternLM, Qwen e DeepSeek. ⁸ Sul fronte locale, ExLlamaV2 con TabbyAPI regola una larghezza media di bit frazionaria per riempire esattamente una scheda, e MLX usa la memoria unificata di Apple, quindi la RAM totale è il budget. Hugging Face TGI è l'unica uscita di scena. È passata in modalità 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 tramite app per utenti finali che li integrano. Ollama, LM Studio e AnythingLLM girano tutti su llama.cpp (LM Studio anche su MLX), aggiungendo modelli con un solo comando, un'OpenAI-compatibile API localhost e, per AnythingLLM, RAG su documenti PDF e codebase. In base alle stelle GitHub, come indicatore approssimativo di adozione al 2026-07-11, Ollama ha 175.925 stelle e vLLM 85.979, entrambi open source, mentre AnythingLLM 63.120. Il dato di LM Studio, 5.053, proviene dal suo repository CLI open source (lmstudio-ai/lms) e non dall'app closed source, quindi sottostima l'adozione reale su desktop. ^{11 12 13 14}

Un componente interattivo di panorama mappa questi strumenti ai casi d'uso. Le integrazioni e l'ampia compatibilità vanno a Ollama, lo sviluppo e le alte prestazioni a vLLM, le applicazioni RAG locali ad AnythingLLM e la sperimentazione adatta ai principianti a LM Studio.

Modelli linguistici di grandi dimensioni open source

I modelli open-weight pubblicano la propria architettura e i file dei pesi, quindi chiunque può scaricarli, modificarli ed eseguirli, in genere da Hugging Face. La frontiera dei modelli self-hostabili di metà 2026 è ormai ben oltre l'era di Qwen2.5 e Llama-3:

Le colonne dei parametri totali e attivi sono la distinzione fondamentale. I parametri totali determinano la memoria e il numero di GPU, mentre i parametri attivi determinano il calcolo. DeepSeek-V4-Flash e GLM-5.2 sono arrivati come open weights nel 2026, Gemma 4 ha rilicenziato la famiglia sotto Apache 2.0 e GPT-OSS distribuisce esperti MoE in MXFP4 nativo. ^{15 16 17 18 19}

I modelli di punta proprietari (OpenAI GPT-5.6, Google Gemini 3.1 Pro, Anthropic Claude Opus 4.8, xAI Grok 4.5) non possono essere scaricati né auto-ospitati; sono disponibili solo via API, di solito dietro un endpoint compatibile con OpenAI. Una distribuzione solo locale rinuncia a ciò che quei modelli fanno meglio in un determinato task. ^{20 21 22}

Quantizzazione e dimensionamento MoE

Nel 2026 la quantizzazione riguarda meno l'arrotondamento dei pesi dopo l'addestramento e più i checkpoint che nascono a basso bit per progettazione, insieme a scelte architetturali che riducono la cache prima ancora che entri in gioco la quantizzazione.

Checkpoint nativi a basso bit: I modelli open di frontiera sono sempre più quantization-aware. GPT-OSS distribuisce i suoi esperti MoE in MXFP4 (E2M1 con scala condivisa a 8 bit, 4.25 bit per parametro), quindi il modello da 120B sta in circa 63 GB, una 80 GB GPU, mentre una stima ingenua in BF16 richiederebbe circa 234 GB su tre GPU. DeepSeek-V3 e R1 distribuiscono FP8 nativo a circa 1 byte per parametro. I pesi andrebbero dimensionati in base al dtype effettivo del checkpoint, non al numero di parametri. ^{23 24}

La trappola dei bit effettivi nei GGUF: I file GGUF mescolano precisioni, con scale FP16 per blocco e tensori di embedding e output non quantizzati, quindi il nome è un limite inferiore, non 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à di Q4_K_M con una dimensione inferiore. ²⁵

Quantizzazione della cache KV: Ridurre il dtype della KV riduce linearmente l'intera cache ed è indipendente dalla precisione dei pesi. La KV in FP8 (e4m3) la dimezza (Llama-3-8B a 128k, batch 1, da 16.0 GiB in BF16 a 8.0 GiB in FP8) con una qualità sostanzialmente gratuita. INT4 la riduce a un quarto ma richiede una valutazione. In vLLM è un solo flag (--kv-cache-dtype fp8). ²⁶

Attenzione come risparmio di memoria: L'attenzione latente multi-testa (MLA, usata da DeepSeek) memorizza nella cache un unico latente condiviso a basso rango (circa 576 elementi per token per livello) invece di chiavi e valori per ogni testa, risultando circa 30 volte più piccola della lettura nominale a 128 teste. È questo che consente 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 livelli a una finestra fissa invece che all'intero contesto, riducendo la KV a contesto lungo da 10 a 40 volte rispetto a una stima ingenua completamente globale. Queste caratteristiche sono fisse per famiglia di architettura, non parametri regolabili. ²⁷

Offloading e sharding: Quando i pesi superano la memoria della GPU, l'offloading sposta le parti inattive, come gli esperti MoE non usati, tra la memoria della GPU e la più lenta RAM di sistema, scambiando token al secondo con la possibilità di eseguire il modello. ²⁸ Lo sharding suddivide un modello su più dispositivi o livelli di memoria, ed è così che un modello da 671B si estende su un nodo con 8 GPU. Entrambi estendono la portata dell'hardware fisso al costo della larghezza di banda.

Vantaggi e compromessi del self-hosting

Gli argomenti a favore del self-hosting sono il controllo dei dati, il costo su volumi elevati e la libertà di configurazione. Gli argomenti contrari sono il costo dell'hardware, l'onere operativo e il divario rispetto ai modelli proprietari.

Residenza dei dati e conformità: Il trasferimento transfrontaliero dei dati è il fattore chiave della conformità. In base al GDPR, l'invio di dati personali fuori dall'UE può far scattare garanzie legali, obblighi contrattuali o restrizioni. L'IA Act dell'UE 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 su gestione del rischio, verificabilità e governance sono rinviati al 2 dicembre 2027 per i sistemi autonomi ad alto rischio dell'Allegato III e al 2 agosto 2028 per i sistemi integrati dell'Allegato I, in base al pacchetto Digital Omnibus 2025-26. ^{29 30 31} Eseguire l'inferenza nella giurisdizione di competenza, su una rete controllata, tiene i dati sensibili fuori dalle mani di terzi: è il caso d'uso dell'IA sovrana per finanza, sanità e settore pubblico.

Costi e controllo: Il self-hosting parte con costi elevati, con GPU consumer o un piccolo server, ma l'inferenza locale può ridurre i costi ricorrenti delle API fee per i team che generano volumi elevati di richieste. Elimina inoltre il lock-in del fornitore e i limiti imposti su finestra di contesto, impostazioni di inferenza e 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. La distribuzione aggiunge gestione delle dipendenze, risoluzione dei problemi di CUDA e dei kernel, monitoraggio e aggiornamenti che altrimenti gestirebbe un provider cloud. Le prestazioni sono responsabilità dell'operatore, dal batching e lo sharding all'utilizzo dell'hardware. E i modelli proprietari più forti restano disponibili solo via API, quindi una distribuzione locale accetta un divario di capacità nei task in cui sono leader.

Metodologia di calcolo della VRAM per LLM self-hosted

L'impronta di memoria di un modello è la somma di quattro termini calcolati indipendentemente e poi sommati, non un singolo valore ricavato dal numero di parametri:

VRAM_total = Weights + KV cache + Activations + Overhead

L'errore di stima più comune comprime gli ultimi tre termini in un ricarico fisso del 20% sui pesi. Questo è corretto per una dimensione di modello e sbagliato per le altre, perché i tre termini scalano in modo diverso. ³²

Pesi: La memoria dei pesi è data da parametri per byte per parametro. BF16 e FP16 memorizzano 2.0 byte per parametro, mentre FP8 e INT8 ne memorizzano circa 1.0. La trappola è il 4-bit, che non corrisponde a 0.5 byte per parametro. I veri INT4 raggruppati (GPTQ, AWQ) si attestano tra 0.52 e 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, ribaltando il giudizio di compatibilità. ²⁵

Il dimensionamento dei mixture-of-experts considera tutti gli esperti, non solo quelli attivi: Tutti i pesi degli esperti restano residenti in VRAM anche se solo alcuni si attivano per token. Mixtral-8x7B richiede circa 28 GB a Q4 per tutti i 46.7B parametri, non per i 13B attivi. I parametri totali determinano la memoria e il numero di GPU, mentre i parametri attivi determinano il calcolo. Un calcolatore che dimensiona sui parametri attivi fa erroneamente risultare compatibili 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), in cui molte teste di query condividono poche teste KV, quindi vengono memorizzate coppie n_kv_heads, riducendo la cache di 4 volte (Llama-3-8B) fino a 8 volte (Llama-3-70B) rispetto all'attenzione multi-testa completa. Sia head_dim sia n_kv_heads vengono letti dal config.json di ciascun modello, non derivati dalla dimensione nascosta e dal numero di teste, poiché famiglie come Gemma (head_dim 256) e Qwen3 (128) verrebbero altrimenti dimensionate erroneamente di circa 2 volte. La cache cresce linearmente sia con la lunghezza del contesto sia con la dimensione del batch, e con contesti lunghi eguaglia o supera i pesi. Llama-3-8B memorizza 128 KiB per token, quindi a un contesto di 128k e batch 1 una cache KV FP16 è di 16.0 GiB, pari ai 16 GB di pesi in BF16. Una cache KV in FP8 la dimezza. ³³

L'overhead è un valore minimo, non una percentuale: L'overhead del framework è un valore minimo fisso per ogni GPU (contesto CUDA e kernel, circa 1-2 GB per GPU) più una piccola frazione limitata, non una quota dei pesi. Un 20% fisso 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 valore minimo a tratti è il modello accurato, e il 20% fisso funziona come stima rapida. ³⁴

Attivazioni e motore di serving: Il termine delle attivazioni è transitorio. Durante la decodifica, un token alla volta, è piccolo e rientra nel valore 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 valore minimo stesso dipende dal motore. I server paginati (vLLM, SGLang) riservano una quota fissa di ogni scheda tramite un'impostazione di utilizzo della memoria, circa il 10% al valore predefinito di 0.90, e fanno entrare pesi e 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 comporta un errore di qualche GB.

Le GPU multiple non si dividono in modo netto: Due schede da 24 GB non equivalgono a 48 GB di spazio utilizzabile. Con il parallelismo tensoriale i pesi e la cache KV si suddividono tra le N schede (W/N e KV/N), ma le attivazioni, il contesto CUDA e i buffer di comunicazione NCCL vengono replicati su ogni scheda, quindi l'impronta complessiva è maggiore di una stima a dispositivo singolo con lo stesso totale. Questa tassa di replica è il motivo per cui un modello da 70B che richiede 43 GB di pesi entra in due schede da 24 GB con un contesto breve, e per cui il controllo sicuro è il totale per singola 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 è pari o inferiore al 90% di quella utilizzabile, al limite nel 10% superiore della capacità e non compatibile sopra la memoria utilizzabile. I server paginati trattengono già quel 10% tramite l'impostazione di utilizzo. Gli esempi seguenti usano Llama-3 su hardware comune, con llama.cpp sulle schede consumer:

Con un contesto di 128k, la cache KV eguaglia i pesi, quindi è la lunghezza del contesto, non il numero di parametri, a decidere la compatibilità. L'ultima riga è compatibile perché i pesi Q4 (~405 GB) stanno sotto 640 GB con un contesto di 8k. Il vantaggio di MLA emerge nei contesti lunghi, dove mantiene la KV di un modello da 671B abbastanza piccola da servire 128k.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Ulteriori letture

• LLM Quantizzazione: BF16 vs FP8 vs INT4
• Motori di inferenza LLM: vLLM vs LMDeploy vs SGLang
• Benchmark di concorrenza GPU: H100 vs H200 vs B200 vs MI300X
• Benchmark multi-GPU: B200 vs H200 vs H100 vs MI300X
• I migliori 60+ provider di GPU cloud
• Cloud LLM vs LLM locali
• Prezzi LLM: i migliori 15+ provider a confronto
• Guida al fine-tuning di LLM per le aziende

FAQ

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 il self-hosting}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/self-hosted-llm}},
  note   = {AIMultiple. Consultato il 31 agosto 2026}
}

Registro delle modifiche

3 aggiornamenti

20262025

1. 12 lug

   Aggiunta una sezione sulla metodologia di calcolo della VRAM per LLM self-hosted.

2. 26 gen

   Aggiunta una sezione, Privacy e conformità, a Vantaggi degli LLM self-hosted.

Collegamenti di riferimento

1.

Overview · Hugging Face

2.

RTX 5090 vs RTX PRO 6000 Blackwell: Consumer vs Pro GPU for AI (2026) | Spheron Blog

Spheron

3.

recommendedMaxWorkingSetSize | Apple Developer Documentation

4.

Adjust VRAM/RAM split on Apple Silicon · ggml-org/llama.cpp · Discussion #2182 · GitHub

5.

Apple reveals M3 Ultra, taking Apple silicon to a new extreme - Apple

Apple

6.

Personal AI Supercomputer Powered by Blackwell | NVIDIA DGX Spark

7.

llama.cpp vs. vLLM: Choosing the right local LLM inference engine | Red Hat Developer

Red Hat

8.

vLLM, Ollama, LM Studio, llama.cpp: Choosing the best LLM inference engine in 2026 [ Updated ] | BIZON

BIZON

9.

GitHub - huggingface/text-generation-inference: Large Language Model Text Generation Inference · GitHub

10.

Migrate from Hugging Face TGI to vLLM or SGLang on GPU Cloud: A 2026 Move-Off Guide | Spheron Blog

Spheron

11.

GitHub - lmstudio-ai/lms: LM Studio CLI · GitHub

12.

GitHub - ollama/ollama: Get up and running with Kimi-K2.6, GLM-5.2, MiniMax, DeepSeek, gpt-oss, Qwen, Gemma and other models. · GitHub

13.

GitHub - vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs · GitHub

14.

GitHub - Mintplex-Labs/anything-llm: Stop renting your intelligence. Own it with AnythingLLM. Everything you need for a powerful local-first agent experience · GitHub

15.

DeepSeek V4 Ships 1M Context, Open-Weights

WinBuzzer

16.

Gemma 4: Our most capable open models to date

Google

17.

New Released - Overview - Z.AI DEVELOPER DOCUMENT

Mintlify

18.

Qwen 3.5 to 3.8: Alibaba Open-Weights Guide (2026)

Codersera Blogs

19.

Welcome GPT OSS, the new open-source model family from OpenAI!

Hugging Face

20.

GPT-5.6: Frontier intelligence that scales with your ambition | OpenAI

21.

Introducing Claude Opus 4.8 \ Anthropic

22.

Introducing Grok 4.5 | SpaceXAI

xAI

23.

MXFP4 · Hugging Face

24.

OpenAI gpt-oss LLMs use MXFP4: smaller, faster, cheaper

theregister

25.

Which Quantization Should I Use? A Unified Evaluation of llama.cpp Quantization on Llama-3.1-8B-Instruct

26.

Quantized KV Cache - vLLM

27.

Decoding Multi-Head Latent Attention (Part 1): The KV Cache Memory Bottleneck, Solved.

Vizuara’s Substack

28.

https://arxiv.org/pdf/2312.17238

29.

EU Artificial Intelligence Act | Up-to-date developments and analyses of the EU AI Act

30.

EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes - Gibson Dunn

Gibson Dunn & Crutcher, LLP

31.

EU AI Act Update: Timeline Relief, Targeted Simplification, and New Prohibitions | Inside Privacy

32.

A Practical Guide to LLM Inference at Scale

The Neural Maze

33.

The State of FP8 KV-Cache and Attention Quantization in vLLM | vLLM Blog

vLLM

34.

How LLM Inference Works (Prefill, Decode & the GPU Memory Wall)

Into AI

Ekrem Sarı

Ricercatore IA

Segui

Ekrem è un Ricercatore IA e Data Scientist presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di IA e LLM.

Visualizza il profilo completo

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.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento