Calcolatore VRAM

La velocità è una stima basata sulla larghezza di banda per la decodifica a flusso singolo, non un benchmark. L'elaborazione del prompt è limitata dal calcolo e si comporta diversamente.

Come leggere l'analisi in tre parti

Quasi ogni discussione online sulla compatibilità di memoria dimentica uno dei tre fattori. La dimensione del download sulla scheda del modello è uno. Gli altri due esistono solo quando il modello è caricato e risponde, ovvero quando l'esaurimento della memoria diventa un problema.

Prendiamo Llama 3.1 8B in Q4_K_M con un contesto di 8K, una richiesta alla volta, cache F16. È la configurazione locale più comune, ed ecco ogni suo byte:

weights  = 8.03e9 params x 4.85 bits / 8      = 4.87e9 bytes = 4.53 GB
kv       = 2 x 32 layers x 8 kv-heads x 128 dim
           x 8192 tokens x 2 bytes             = 1.07e9 bytes = 1.00 GB
overhead = 0.65 + 0.08 x (4.53 + 1.00)                        = 1.09 GB
                                                                -------
total                                                            6.63 GB

I pesi sono l'unica parte verificabile. Sono pura aritmetica: numero di parametri per bit per peso, diviso otto. Nulla del carico di lavoro li modifica. Se non considerassi gli altri due fattori, concluderesti che un modello da 8B a 4 bit richiede 4,5 GB e entra comodamente in una scheda da 6 GB. Non è così.

La KV cache è la parte variabile. Ogni token nel contesto ha un vettore chiave e valore memorizzato per ogni strato, così il modello può fare riferimento al passato senza ricalcolarlo. Questo rende la generazione veloce ed è il motivo per cui la cache non è opzionale. Scala linearmente con il contesto e con le richieste simultanee, ed è determinata dal layout dell'attention piuttosto che dal numero di parametri. Qui costa esattamente 0,125 GB ogni 1024 token, un valore contenuto perché Llama 3.1 usa otto key-value heads per trentadue query heads.

L'overhead di runtime è la parte che nessuno calcola ma che tutti incontrano. Kernel compilati, contesto CUDA o Metal, buffer di attivazione e logit, l'allocatore che non riesce a impacchettare i blocchi perfettamente e il working set del sampler. Questo calcolatore lo modella come 0,65 GB fissi più l'8% di tutto il resto. È un'approssimazione voluta, ma la logica è corretta: l'overhead non svanisce sui modelli piccoli e non rimane costante su quelli grandi.

Una nota sulle unità di misura, fonte di confusione. Ogni GB in questa pagina è calcolato dividendo per 1024 alla terza potenza, quindi tecnicamente è un gibibyte. È la stessa unità riportata dal driver della GPU, motivo per cui una scheda venduta come 24 GB ne mostra circa 24564 MiB. I file dei modelli su Hugging Face sono solitamente elencati in gigabyte decimali, quindi un download da 5,0 GB appare qui come circa 4,65 GB. Il divario è di circa il 7% ed è a tuo favore.

Scegliere un livello di quantizzazione

La quantizzazione memorizza ogni peso in meno bit. Un modello rilasciato in BF16 occupa due byte per parametro; una quantizzazione a 4 bit ne occupa poco più di mezzo. Nient'altro cambia nel modello, motivo per cui la quantizzazione è la leva principale per determinare se un modello può essere ospitato.

Ecco un modello, Llama 3.3 70B, a ogni livello offerto da questo calcolatore. I pesi rappresentano il file su disco; le altre due colonne indicano l'ingombro totale caricato, inclusi cache e overhead, con un singolo stream e cache F16.

Ci sono tre aspetti in questa tabella su cui vale la pena soffermarsi. Primo, il conteggio nominale dei bit è una menzogna a tuo favore e contro di esso. Q4_K_M non è 4 bit per peso, ma 4,85, perché i formati K-quant mantengono i tensor di attention e embedding a una precisione maggiore dove il danno è più grave. Q2_K ha una media di 3,35 bit per lo stesso motivo. Se dimensioni un modello come parametri per quattro diviso otto, sottostimerai di circa un quinto.

Secondo, i rendimenti diminuiscono drasticamente man mano che si scende. Passare da BF16 a Q8_0 dimezza il modello senza costi misurabili. Passare da Q8_0 a Q4_K_M lo dimezza quasi di nuovo con una perdita di qualità che la maggior parte delle persone non nota nell'uso comune. Passare da Q4_K_M a Q3_K_M fa risparmiare 7,8 GB, ma inizia a manifestarsi con un peggiore rispetto delle istruzioni, codice più debole e più errori aritmetici. Al di sotto di questo livello, stai scambiando capacità con spazio in un modo che noterai.

Terzo, il danno derivante da una quantizzazione aggressiva non è distribuito uniformemente tra le dimensioni dei modelli. Un 70B a Q2_K è ancora un modello utilizzabile, perché c'è un'enorme ridondanza da distruggere. Un 3B a Q2_K produce spesso output errati. La regola empirica che sopravvive al contatto con la pratica: preferisci un modello più grande a una quantizzazione inferiore fino a circa 4 bit, e preferisci un modello più piccolo a 4 bit o superiore al di sotto di tale soglia. Un 70B a Q4_K_M supera un 32B a Q8_0 nella maggior parte dei compiti; un 70B a IQ2_XXS solitamente non lo fa.

Un caso speciale che vale la pena conoscere. Alcuni modelli sono pubblicati nativamente in un formato a basso bit anziché essere quantizzati successivamente. gpt-oss viene distribuito in MXFP4 a 4,25 bit per peso e, poiché l'addestramento ne ha tenuto conto, la qualità non è paragonabile a una compressione a 4 bit di una release BF16. Ecco perché il calcolatore offre MXFP4 solo per i modelli che lo utilizzano nativamente e perché gpt-oss 120B occupa 63,4 GB invece dei 250 GB che un modello da 117B richiederebbe a piena precisione.

Perché la context length è una decisione hardware

Le persone trattano la context length come un flag di funzionalità: la model card dice 128K, quindi impostala a 128K. Non è un flag di funzionalità, è un'allocazione di memoria e, su alcune architetture, è la singola voce più grande nel budget. Ecco quattro modelli a Q4_K_M, single stream, cache F16, con l'impronta totale caricata a quattro diverse context length.

Llama 3.1 8B quadruplica le dimensioni tra 2K e 128K, da 5,8 GB a 22,8 GB, che è la differenza tra l'essere eseguibile su quasi tutto e il non entrare in una scheda da 24 GB. Command R 35B è il caso estremo: parte più piccolo di Qwen3 32B a 2K e finisce per essere quasi quattro volte più grande a 128K, perché utilizza full multi-head attention con 64 key-value heads e richiede 1,25 GB di cache per 1024 token. Gemma 3 27B si muove a malapena, perché cinque strati su sei prestano attenzione solo a una finestra di 1024 token e quindi smettono di crescere quasi immediatamente.

La conseguenza pratica è che la context length che configuri dovrebbe essere quella che utilizzi effettivamente, non il massimo supportato dal modello. Se i tuoi prompt sono di 3000 token e le tue risposte di 800, impostare 32K spreca memoria che avresti potuto dedicare a una quantizzazione migliore. Llama 3.1 8B a Q4_K_M su una scheda da 24 GB può gestire un contesto di 64K, ma non di 128K, perché 128K richiede 22,8 GB e la scheda ne lascia solo circa 22,3 GB dopo che il display e il driver hanno preso la loro parte. Ridurre la cache a Q8 ti permette di farcela. Nient'altro deve cambiare.

È importante anche quale runtime utilizzi. llama.cpp alloca la cache per la context size che passi e nient'altro, quindi un contesto piccolo restituisce effettivamente la memoria. vLLM invece richiede una frazione della scheda in anticipo e gestisce un pool paginato al suo interno, quindi nvidia-smi mostrerà la scheda quasi piena indipendentemente da ciò che imposti. Il numero fornito da questo calcolatore è il working set necessario, che si mappa direttamente sul comportamento di llama.cpp e sul pool che vLLM deve essere in grado di allocare.

La cache è decisa dall'architettura, non dalla dimensione

Il fatto più utile sulla KV cache è che il numero di parametri la predice a malapena. Ciò che la predice è quante key-value heads mantiene un modello, quanto è ampia ciascuna, quanti strati ha e se fa qualcosa di ingegnoso. Ecco il costo della cache per 1024 token per modelli che coprono tre ordini di grandezza nel numero di parametri.

Leggi insieme la riga superiore e quella inferiore. Un modello da 671B ha una cache più piccola di uno da 35B, e un modello da 3,8B ha una cache quattro volte e mezza più grande di uno da 27B. Phi-3.5 mini a un contesto completo di 128K richiede 54,8 GB in totale, di cui solo 2,2 GB sono pesi. Questo è un modello che le persone descrivono come minuscolo che richiede più memoria di un 32B.

Quattro meccanismi spiegano l'intera tabella. La grouped-query attention condivide una key-value head tra diverse query heads, che è lo standard industriale attuale e tipicamente riduce la cache da quattro a otto volte. La sliding-window attention fornisce alla maggior parte degli strati una finestra fissa, così la loro cache smette di crescere oltre essa, motivo per cui Gemma 3 e gpt-oss si appiattiscono. La multi-head latent attention, utilizzata da DeepSeek, comprime chiavi e valori in un singolo vettore da 576 elementi per token per strato invece di memorizzarli per intero. E la semplice multi-head attention, ancora utilizzata da release più vecchie come Command R e Phi-3.5, non fa nulla di tutto ciò e paga per ogni head.

Se desideri la versione lunga di questa argomentazione con le derivazioni, è scritta separatamente in perché il numero di parametri è un cattivo predittore della VRAM.

Quando la quantizzazione della KV cache ne vale la pena

La cache può essere quantizzata proprio come i pesi. F16 spende 2 byte per elemento memorizzato; l'opzione Q8 qui ha una media di 1,06 byte e Q4 una media di 0,56, con l'overhead derivante dalle scale per blocco. Ogni runtime serio la supporta: llama.cpp la espone come cache-type-k e cache-type-v, vLLM come flag kv-cache-dtype.

La domanda non è mai se risparmia memoria. È se il risparmio sia abbastanza grande da contare, e ciò dipende interamente da quanta parte della tua impronta è cache in primo luogo. A un contesto di 32K con pesi Q4_K_M:

Command R guadagna 20,3 GB da un singolo flag, che è la differenza tra aver bisogno di due schede da 48 GB e averne bisogno di una. Llama 3.3 70B guadagna 5,1 GB dallo stesso flag, perché la grouped-query attention rendeva già la sua cache piccola. Il modello vale in generale: la quantizzazione KV è trasformativa sui modelli multi-head a contesto lungo e marginale sui modelli grouped-query a contesto breve. Controlla il segmento KV cache nella ripartizione sopra prima di utilizzarlo. Se quella barra è una sottile striscia, il flag non ti salverà.

Il costo è reale ma limitato. La cache Q8 è quasi gratuita in termini di qualità e vale la pena abilitarla per impostazione predefinita su qualsiasi carico di lavoro a contesto lungo. La cache Q4 degrada esattamente ciò per cui serve il contesto lungo: il richiamo preciso di fatti specifici sepolti in profondità nell'input. Il riassunto e la chat a risposta aperta lo tollerano bene; il recupero su un lungo documento, le ricerche needle-in-haystack e il ragionamento su codice multi-file no. C'è anche un'asimmetria che vale la pena conoscere, ovvero che le chiavi sono più sensibili alla quantizzazione rispetto ai valori, quindi se il tuo runtime ti permette di impostarli separatamente, una cache delle chiavi Q8 con una cache dei valori Q4 è solitamente migliore di Q4 su entrambi.

Una regola che non ti porterà fuori strada: quantizza prima i pesi, poi la cache. I pesi Q4_K_M con una cache F16 battono i pesi Q6_K con una cache Q4 a parità di dimensione totale, in quasi tutti i casi, perché la quantizzazione dei pesi è stata studiata e ottimizzata molto più a fondo rispetto alla quantizzazione della cache.

Due schede da 24 GB non sono una scheda da 48 GB

Suddividere un modello tra più GPU è possibile e, per i modelli di grandi dimensioni, è l'unica strada economicamente sostenibile. Tuttavia, il calcolo non è una semplice addizione e la differenza emerge in due ambiti: capacità utilizzabile e velocità di decodifica.

Per quanto riguarda la capacità, una singola scheda perde una parte della memoria a causa del driver, dell'output video e della frammentazione dell'allocatore. Questo calcolatore stima che circa il 93% sia utilizzabile su una scheda consumer e il 95% su una scheda workstation o datacenter senza display collegato. Una configurazione multi-scheda perde di più, circa il 90%, poiché ogni scheda gestisce il proprio contesto di runtime e la propria copia dei buffer di attivazione, e perché la suddivisione dei layer non è quasi mai uniforme. Due RTX 4090 offrono quindi circa 43,2 GB di spazio di lavoro, mentre una singola RTX 6000 Ada, con gli stessi 48 GB nominali, ne offre 45,6 GB.

Quel divario di 2,4 GB è determinante nei casi reali. Llama 3.3 70B in formato Q4_K_M con un contesto di 8K richiede 46,4 GB, quindi non rientra in nessuna delle due configurazioni. Passando la cache a Q8 si scende a 45,1 GB, che entra nella singola scheda da 48 GB ma non nella coppia. Per farlo girare su due 4090 è necessario passare anche ai pesi Q4_0, arrivando a 42,5 GB. Stessa memoria nominale, due compromessi in più.

Sulla velocità, l'aspettativa comune è che due schede siano due volte più veloci. Per la decodifica single-stream non è così, e spesso sono più lente di quanto sarebbe una singola scheda se il modello vi entrasse. La suddivisione predefinita in llama.cpp e nella maggior parte delle configurazioni a nodo singolo è il pipeline parallelism: i layer da 0 a 39 risiedono sulla prima scheda, da 40 a 79 sulla seconda. La generazione di un token attraversa tutti gli ottanta layer in ordine, quindi solo una GPU lavora effettivamente in ogni momento mentre l'altra attende, con l'aggiunta di un trasferimento dello hidden-state via PCIe al confine. Hai acquistato capacità, non throughput. Questo calcolatore modella ciò come un calo dell'efficienza di banda da 0,75 su una singola scheda a 0,6 su una configurazione divisa, il che porta due RTX 4090 a circa 13 token al secondo su un modello 70B e una singola RTX 6000 Ada a circa 16, nonostante la coppia abbia una banda grezza per scheda superiore.

Il tensor parallelism, utilizzato da vLLM e TensorRT-LLM, è l'alternativa: ogni layer viene suddiviso tra tutte le schede che lavorano simultaneamente. Questo scala effettivamente la velocità di decodifica, ma richiede un'operazione di all-reduce tra le schede per ogni layer, necessitando quindi di NVLink o almeno di linee PCIe x16 complete per ogni scheda. Su una scheda madre consumer che esegue la seconda scheda a x4, il tensor parallelism può essere più lento del pipeline parallelism. Richiede inoltre che il numero di attention heads sia divisibile per il numero di schede, motivo per cui le configurazioni a tre schede sono problematiche.

In sintesi: aggiungi schede per far girare un modello che altrimenti non potresti eseguire, non per velocizzare un modello che già funziona. Se devi scegliere tra una scheda grande e due piccole allo stesso prezzo, la scheda singola vince per semplicità, consumo energetico, capacità utilizzabile e latenza single-stream. Le schede multiple vincono quando gestisci richieste concorrenti, dove il batching mantiene ogni scheda occupata.

Cosa succede quando si esegue l'offload alla RAM di sistema

Se un modello non entra, llama.cpp e Ollama manterranno alcuni layer nella RAM di sistema eseguendoli sulla CPU. Funziona. È anche il punto in cui molti concludono che il proprio hardware sia guasto, perché la velocità non degrada in modo graduale.

Il motivo è che la decodifica è limitata dalla banda di memoria, non dalla potenza di calcolo. Per produrre un token, il runtime legge ogni peso attivo e l'intera cache una volta. Per Llama 3.3 70B in Q4_K_M con un contesto di 8K, si tratta di circa 45,5 GB di letture per token. Dividi questo valore per la banda della memoria in cui risiede e otterrai il limite massimo prima ancora che avvenga qualsiasi calcolo.

Una RTX 4090 legge a 1008 GB/s. Una DDR5 dual-channel in un tipico desktop legge a circa 90 GB/s. È una differenza di undici volte, ed è tutto qui. Se il modello 70B entrasse interamente nella 4090, decodificherebbe a circa 17 token al secondo. Non entra: 22,3 GB dei 46,4 GB sono residenti, quindi il 52% della lettura di ogni token proviene dalla RAM di sistema a un nono della velocità. Il risultato è di circa 2,6 token al secondo. Hai mantenuto il 48% del modello sul dispositivo veloce e perso l'84% della velocità.

Lo stesso principio si applica a ogni scala. Llama 3.1 8B legge 5,9 GB per token; su una 4090 sono circa 127 token al secondo, mentre interamente su CPU con 90 GB/s di RAM sono circa 11. Qwen3 32B in Q4_K_M richiede 22,8 GB, quindi su una RTX 5080 da 16 GB circa il 65{}imane residente e la stima scende da circa 33 token al secondo a circa 8.

Due dettagli rendono l'esperienza reale peggiore di quanto suggeriscano questi numeri. L'elaborazione del prompt sui layer CPU è limitata dal calcolo piuttosto che dalla banda, quindi un prompt lungo può richiedere minuti prima che appaia il primo token, anche se la velocità di streaming successiva sembra tollerabile. Inoltre, l'offloading non è gratuito nemmeno sul lato GPU, poiché il runtime necessita comunque di buffer di lavoro per i layer che ospita.

Quando l'offloading è la scelta giusta: lavori in batch che non richiedono attesa immediata, modelli in cui un paio di token al secondo sono sufficienti e casi in cui solo pochi layer eccedono la memoria. Un offload del 10% costa molto meno di uno del 50%. Quando è la scelta sbagliata: qualsiasi attività interattiva. Un modello più piccolo con una buona quantizzazione sarà quasi sempre preferibile a uno più grande che arranca tra i tuoi DIMM; se hai bisogno delle capacità del modello più grande, chiamarlo tramite API è più veloce ed economico che forzare il tuo desktop.

Apple Silicon e memoria unificata

Apple Silicon non ha una VRAM separata. CPU e GPU condividono un unico pool di LPDDR sullo stesso package, il che significa che un Mac con 128 GB di memoria può caricare un modello che nessuna GPU consumer sul mercato può gestire. È un vantaggio reale ed è il motivo per cui i Mac sono comuni negli ambienti di inferenza locale. Comporta però due precisazioni che si scoprono spesso tardi.

La prima è che non hai a disposizione l'intero quantitativo. macOS riserva memoria per tutte le altre attività del sistema e limita ciò che la GPU può allocare; questo calcolatore stima che circa il 75{}ia disponibile per un modello, quindi 128 GB di memoria unificata diventano circa 96 GB di budget e un Mac mini da 16 GB ne offre circa 12. Il limite può essere alzato con l'impostazione iogpu wired limit, ma spingerlo vicino al totale fisico rischia di causare swapping di sistema, e lo swapping di un modello è peggio che non caricarlo affatto.

La seconda è la banda. La memoria unificata è ampia, ma non quanto una GDDR. Un M4 Max legge a circa 546 GB/s contro i 1008 GB/s di una RTX 4090 e i 1792 GB/s di una RTX 5090; l'M4 base in un Mac mini legge a circa 120 GB/s, un terzo di quanto gestisce una RTX 3060 di cinque anni fa. Su Llama 3.1 8B in Q4_K_M, ciò si traduce in circa 60 token al secondo su un M4 Max, circa 13 su un Mac mini M4 base e circa 45 sulla RTX 3060. Capacità e velocità sono acquisti separati: Apple vende molta capacità per dollaro e relativamente poca velocità.

L'elaborazione del prompt è l'aspetto più critico. La decodifica è limitata dalla banda, dove Apple è solo leggermente indietro; il prefill è limitato dal calcolo, dove il divario rispetto a una moderna scheda NVIDIA con tensor core dedicati è molto più ampio. Un documento da 30.000 token incollato in una chat su un Mac può richiedere un tempo notevole prima che inizi lo streaming, anche se poi lo streaming stesso appare fluido. Se il tuo carico di lavoro prevede prompt lunghi e risposte brevi, questo è il dato da testare prima dell'acquisto.

Dove un Mac vince nettamente è nella fascia intermedia, irraggiungibile dalle schede discrete a prezzi ragionevoli. Llama 3.3 70B in Q4_K_M entra comodamente in un M4 Max da 128 GB a circa 8 token al secondo, e un M2 Ultra da 192 GB lo esegue a circa 11, potendo inoltre ospitare modelli che richiedono ben oltre 100 GB. Ottenere lo stesso risultato con hardware NVIDIA richiede diverse schede, una scheda madre con le linee PCIe necessarie e un alimentatore adeguato. Usa MLX invece di un backend generico quando possibile, poiché è scritto per questo modello di memoria e supera costantemente le alternative sulla stessa macchina.

Servire più di una persona alla volta

Tutto quanto sopra presuppone una richiesta alla volta. Nel momento in cui metti il modello dietro un endpoint utilizzato da altri, i pesi rimangono condivisi ma ogni richiesta concorrente porta con sé la propria KV cache. Questo trasforma la cache da elemento secondario a costo dominante. Llama 3.1 8B in Q4_K_M con contesto 8K, a concorrenza crescente:

A sedici utenti concorrenti, la cache è più grande del modello. A trentadue, un modello 8B richiede più memoria di quanto ne richieda un 70B per un singolo utente. Questo è il dato che sorprende i team che hanno fatto prototipazione su un laptop e poi si sono chiesti perché il server sia andato in crash con otto persone collegate.

Il lato positivo è che la concorrenza è dove le GPU smettono di essere sprecate. La decodifica single-stream lascia la maggior parte della potenza di calcolo inattiva in attesa della memoria; il batching ammortizza una lettura dei pesi su molte sequenze, quindi il throughput totale cresce molto più velocemente dell'uso della memoria. Questo è anche il caso in cui una paged cache si rivela utile, poiché vLLM alloca la cache in blocchi man mano che le sequenze crescono, invece di riservare lo scenario peggiore per ogni slot. Se stai dimensionando un server, fallo in base alla cache per la tua concorrenza reale e la tua lunghezza mediana del prompt, non per il contesto massimo moltiplicato per il numero massimo di utenti.

Errori comuni nel dimensionamento di una GPU

Domande che le persone pongono realmente

Quanta VRAM serve per eseguire un modello da 7B o 8B?

Circa 6,6 GB a Q4_K_M con un contesto di 8K, che entra in una scheda da 8 GB con un po' di margine. A BF16 lo stesso modello richiede 17,9 GB e necessita di una scheda da 24 GB. Se si desidera il contesto completo da 128K, si sale a 22,8 GB, quindi qui il contesto conta quanto la precisione.

Perché il mio modello da 8 GB si rifiuta di caricarsi su una scheda da 8 GB?

Tre motivi si sommano. Il driver e il desktop hanno già occupato circa il 7 percento della scheda, la KV cache viene allocata sopra i pesi e il runtime richiede circa 0,65 GB di contesto e spazio kernel prima di eseguire qualsiasi operazione. La dimensione del file è l'unico numero che non include nulla di tutto ciò.

Una scheda da 24 GB può eseguire un modello da 70B?

Non solo nella VRAM. Llama 3.3 70B richiede 46,4 GB a Q4_K_M e 8K, e anche a IQ2_XXS con un contesto di 2K richiede comunque 22,5 GB a fronte di circa 22,3 GB disponibili. È possibile fare offload sulla RAM di sistema e ottenere un paio di token al secondo, oppure eseguire un 32B e ottenerne trenta.

Q4_K_M è davvero sufficiente?

Per quasi tutto, sì, ed è il valore predefinito per una buona ragione. Memorizza 4,85 bit per peso invece di 4 fissi, mantenendo i tensori di attention e embedding a una precisione maggiore. Il divario misurabile rispetto a Q8_0 è piccolo e il risparmio di memoria è quasi la metà. Scendi al di sotto solo quando l'alternativa è non eseguire affatto il modello.

Un modello più grande a bassa precisione è migliore di uno più piccolo ad alta precisione?

Fino a circa 4 bit, sì. Un 70B a Q4_K_M batte un 32B a Q8_0 nella maggior parte dei compiti con un ingombro simile. Sotto i 3 bit l'ordine si inverte per i modelli piccoli e medi, perché c'è meno ridondanza da sacrificare. I modelli molto grandi tollerano i formati a 2 bit molto meglio di quelli piccoli.

Perché la KV cache su un modello da 3,8B è più grande di quella su uno da 27B?

Perché Phi-3.5 mini utilizza una multi-head attention completa con 32 key-value heads, a 0,375 GB per 1024 token, mentre Gemma 3 27B assegna a cinque strati su sei una finestra scorrevole di 1024 token. A 128K si tratta di 48 GB contro 10,4 GB. La dimensione della cache segue il layout dell'attention, non il numero di parametri.

Dovrei quantizzare la KV cache?

Abilita Q8 ogni volta che il contesto è lungo; è quasi gratuito. Scegli Q4 solo quando la cache rappresenta una parte consistente del tuo ingombro e il carico di lavoro non richiede un richiamo intensivo. Su Command R 35B a 32K, Q8 risparmia 20,3 GB. Su Llama 3.3 70B con lo stesso contesto risparmia 5,1 GB, perché la grouped-query attention ha già fatto il lavoro.

Due schede da 24 GB equivalgono a una da 48 GB?

No. Ottieni circa 43,2 GB utilizzabili invece di 45,6, perché ogni scheda porta con sé il proprio contesto di runtime e la suddivisione degli strati non è uniforme. Nemmeno la velocità single-stream migliora, poiché il pipeline parallelism significa che una scheda calcola mentre l'altra attende. Due schede offrono capacità e, in caso di concorrenza, throughput.

Quanto sarà veloce in esecuzione?

Dividi la larghezza di banda della memoria per i byte letti per token. Llama 3.1 8B a Q4_K_M legge 5,9 GB per token, quindi una RTX 4090 a 1008 GB/s arriva a circa 127 token al secondo dopo le perdite di efficienza. Questa stima vale solo per la decodifica. L'elaborazione del prompt è limitata dal calcolo e segue una curva diversa.

Cosa succede davvero se faccio offload sulla RAM di sistema?

La velocità precipita invece di diminuire gradualmente. Llama 3.3 70B con il 48 percento dei suoi strati su una RTX 4090 e il resto in DDR5 decodifica a circa 2,6 token al secondo invece dei 17 che gestirebbe se fosse interamente residente. Un piccolo traboccamento è gestibile; metà modello no.

Un Mac è una buona macchina per l'inferenza locale?

Per capacità in rapporto al prezzo, sì: un M4 Max da 128 GB offre circa 96 GB di budget utilizzabile ed esegue un 70B a circa 8 token al secondo. Per la velocità pura, no: 546 GB/s di larghezza di banda contro 1792 su una RTX 5090, e l'elaborazione del prompt è ancora più lenta. Acquistalo per modelli grandi e per la silenziosità, non per la latenza.

I modelli mixture-of-experts risparmiano memoria?

Risparmiano tempo, non spazio. Qwen3 30B-A3B richiede comunque 20,1 GB perché ogni esperto deve essere residente, ma legge solo circa 3,3B di parametri per token, quindi decodifica diverse volte più velocemente di un 32B denso con lo stesso ingombro. Valuta un modello MoE dal totale per l'adattamento e dai parametri attivi per la velocità.

La flash attention riduce la VRAM?

Rimuove la grande matrice di attention intermedia, che è un risparmio reale durante il prefill su prompt lunghi, e rende l'elaborazione del prompt più veloce. Non riduce la KV cache, che è la parte che cresce con il contesto. Attivala comunque; non aspettarti che i totali su questa pagina cambino.

Perché nvidia-smi mostra la scheda piena quando imposto un contesto piccolo?

Probabilmente stai eseguendo vLLM, che richiede una frazione fissa della scheda all'avvio e gestisce un pool di cache paginata al suo interno. llama.cpp alloca solo ciò che serve per il contesto richiesto. Le cifre qui descrivono il working set, che è ciò che vLLM deve essere in grado di allocare e ciò che llama.cpp riporta direttamente.

Quanta VRAM serve per fare fine-tuning invece di eseguire un modello?

Molta di più, e questo calcolatore non la modella. Un fine-tuning completo mantiene pesi, gradienti e stato dell'ottimizzatore a circa 16 byte per parametro, quindi un modello da 8B arriva a circa 130 GB prima delle attivazioni. QLoRA su una base a 4 bit è molto più vicino all'ingombro dell'inferenza più la memoria di attivazione, motivo per cui è l'unica opzione realistica su una singola scheda consumer.

I modelli vision cambiano i calcoli?

Il vision encoder è incluso nel conteggio dei parametri dei modelli multimodali elencati qui, quindi il dato sui pesi è corretto. Ciò che i totali non catturano è che le immagini vengono espanse in un gran numero di token prima di raggiungere il modello linguistico, quindi poche immagini ad alta risoluzione possono consumare più contesto, e quindi più cache, di una pagina di testo.

Cosa fare se nulla entra?

Riduci prima il contesto, dato che di solito è la concessione meno costosa, poi quantizza la cache a Q8, quindi riduci i pesi di un livello. Se sei ancora corto, un modello più piccolo con una quantizzazione sensata batte uno più grande che arranca sulla RAM di sistema. Oppure chiama gli stessi modelli open-weight tramite l'API gratuita e lascia che sia qualcun altro a possedere l'hardware.