LLM locale fuori VRAM? Vedi pesi vs KV cache con gputaskman

Il tuo modello locale si è caricato senza problemi ieri, oggi va in crash al caricamento o striscia, e l'unica cosa che hai cambiato era la lunghezza del contesto. Un colpevole comune è la KV cache, e uno strumento da terminale gratuito chiamato gputaskman può mostrartelo invece di lasciarti tirare a indovinare.

Un tipico monitor GPU ti dice quanto è piena la VRAM. Questo è il "cosa", non il "perché". Il README di gputaskman (verificato il 5 novembre 2026) si definisce "Un htop per ciò che c'è dentro la tua GPU, non solo per quanto è piena." È un progetto sperimentale e precoce, con licenza MIT, quindi trattalo come una lente utile, non come un verdetto.

Cosa riempie davvero la tua VRAM#

Pensa alla VRAM come a una valigia. Ci finiscono tre cose:

• Pesi: il modello stesso. Dimensione fissa per un dato modello e quantizzazione.
• KV cache: la memoria a breve termine del modello della tua conversazione. Cresce man mano che cresce il contesto.
• Buffer di calcolo: spazio di lavoro temporaneo di cui il runtime ha bisogno mentre lavora.

Quando le persone dicono "il modello non ci sta", spesso intendono che i pesi ci stanno ma la cache che hai richiesto in aggiunta no. Questa distinzione decide la soluzione, ed è esattamente ciò che un monitor ordinario nasconde.

Installa gputaskman e guarda per processo#

Il README elenca tre modi per iniziare: uno ZIP portatile per Windows, un clone eseguito con uv run --locked gputaskman, oppure pip dentro un ambiente virtuale Python 3.11+. Le piattaforme, come le descrive il README:

• Windows 10/11 a 64 bit con GPU NVIDIA o AMD (ZIP x64 e ARM64 nella pagina Releases);
• Linux e WSL con GPU NVIDIA (glibc 2.35+; WSL può leggere i contatori dell'host Windows);
• macOS su Apple Silicon solo da un clone del sorgente, nessuna build portatile.

Gli ZIP per Windows non sono firmati. Scaricali solo dalla pagina Releases del repository ufficiale, github.com/shanselman/gputaskman. Copia i comandi esatti dal README: il progetto è giovane e le opzioni possono cambiare.

Una volta in esecuzione, due viste contano per questo problema:

1. Vista dispositivo: uso della VRAM, attività della GPU, PCIe, temperatura, potenza, clock e grafici storici. Utile per "qualcosa ha avuto un picco?"
2. Vista processo: memoria GPU locale per processo, RAM di sistema accessibile alla GPU, attività del motore e runtime rilevato (CUDA, HIP, Vulkan, Direct3D, ggml, ONNX Runtime).

Nella vista processo, trova il tuo server di modelli (per Ollama, il suo runner integrato). Poi controlla il resto della lista. Se un browser o un gioco occupa qualche gigabyte, hai trovato la risposta senza toccare il modello.

Pesi, KV cache, buffer: da dove vengono i numeri#

L'ispettore del modello mostra architettura, quantizzazione e dimensioni dei buffer quando disponibili. Un avvertimento è importante: secondo il README, pesi, KV cache e buffer di calcolo provengono dai log di caricamento del runtime quando è abilitata una registrazione compatibile. Per llama.cpp, avvia il tuo llama-server con il logging (--log-file server.log -lv 4; il README dice che serve il livello 4 per le dimensioni dei buffer). Per Ollama, gputaskman usa server.log di Ollama se disponibile. Altrimenti sono stime dai metadati GGUF e dalla dimensione del contesto, assumendo un posizionamento in stile llama.cpp. La contabilità KV per modello all'interno di un singolo processo non è ancora supportata.

Quindi leggi una suddivisione stimata come "all'incirca", e una suddivisione basata sui log come "ciò che ha riportato il runtime". Per Ollama il README dice che i runner integrati vengono rilevati, i blob GGUF sono nominati dai manifest di Ollama, e server.log viene usato quando disponibile. Il supporto a LM Studio è parziale: i modelli sono nominati dalla sua cartella e sondati tramite la sua API locale, ma questo è stato testato con risposte fittizie, non end to end.

Puoi anche salvare due snapshot come JSON e confrontarli con il comando diff. È un modo pulito per rispondere a "cosa è cambiato quando sono passato da un contesto di 4K a 16K?": prendi uno snapshot, cambia l'impostazione, ricarica, prendine un altro.

Quale manopola girare#

Leggere la suddivisione ti dà una decisione, non solo un'immagine.

I pesi sono la fetta grande. Passa a una quantizzazione più piccola o a un modello più piccolo. Questa è l'unica leva che riduce i pesi. Se vuoi la matematica della memoria che ci sta dietro, vedi Un modello da 125B può girare su una GPU da 16 GB?

La KV cache è la fetta grande. Accorcia il contesto. In Ollama puoi provarlo direttamente nella sessione:

ollama run <your-model>
>>> /set parameter num_ctx 8192

8192 è solo un valore di esempio; scegli quello che serve davvero al tuo compito (comando secondo la documentazione di Ollama, verificata il 5 novembre 2026).

Se in seguito noti una strana lentezza nell'elaborazione del prompt con una cache quantizzata in llama.cpp, questa correzione per la KV cache q5_1 è la prossima tappa. Per capire cosa contiene in primo luogo una finestra di contesto, leggi Cos'è una finestra di contesto?

Un altro processo è la fetta grande. Chiudilo, oppure eseguilo sulla GPU integrata. Nulla del modello deve cambiare.

Se non funziona#

• La suddivisione sembra sbagliata. Controlla se è una stima (nessun log di caricamento compatibile). Con llama.cpp, avvia il tuo llama-server con --log-file server.log -lv 4 e ricarica il modello. Con Ollama, gputaskman usa server.log se esiste; un'etichetta di stima lì è normale.
• LM Studio mostra meno dettagli. Il supporto è parziale, come sopra.
• Nessuna GPU NVIDIA o AMD. Lo strumento copre solo i carichi di lavoro GPU locali; i carichi solo CPU, solo NPU e cloud sono fuori ambito.
• macOS. Esegui da un clone del sorgente; non c'è una build portatile.

Quando un modello ospitato è la soluzione più semplice#

Supponi di aver bisogno di un contesto lungo per un compito, come riassumere un grande documento, e la tua GPU riesce a contenere il modello solo con uno corto. Puoi continuare a ottimizzare, oppure togliere la VRAM dall'equazione. Per compiti del genere CheapTokens offre DeepSeek-V4-Flash: contesto da 380K, fino a 32.768 token di output per risposta, un unico prezzo a qualsiasi ora del giorno, tramite un'API compatibile con OpenAI. GLM-5.3-Flash ha un contesto da 390K e fino a 8.192 token di output.

La chiamata è nel solito formato OpenAI (metti la tua chiave in una variabile d'ambiente):

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize this document: ..."}]}'

I dettagli di configurazione sono nella documentazione. Una regola pratica per decidere: se un compito continua a richiedere più contesto o un modello più grande di quanto la tua scheda contenga, e la vista processo mostra che la tua VRAM è già ben utilizzata, manda quel compito all'API e tieni i lavori piccoli e veloci in locale. Eseguire DeepSeek in locale o usare un'API? approfondisce il compromesso.

Supponi di riassumere 100 grandi documenti, ciascuno da 60.000 token di input e 1.000 token di output (ben dentro la finestra da 380K). Ecco quanto costa oggi:

Su questi numeri, $0.001 per documento è il prezzo live per una chiamata del genere, e in totale, contando insieme input e output, risulta inferiore a OpenRouter.