gputaskman: scoprire chi occupa la VRAM del PC

Per capire quale programma occupa la VRAM, devi guardare la memoria dei singoli processi, non soltanto la percentuale di utilizzo della GPU. gputaskman riunisce questi dati in un’interfaccia da terminale e aggiunge informazioni sui carichi AI locali. Il passaggio decisivo è confrontare lo stesso PC prima e dopo l’apertura di un’applicazione, distinguendo i contatori misurati dalle stime.

Il progetto di Scott Hanselman è open source e ancora sperimentale. Questa guida si basa sulla documentazione verificata l’8 novembre 2026: non è un benchmark né una prova diretta del programma. È pensata per chi vuole individuare il responsabile di un consumo di memoria, prima di cambiare scheda video o reinstallare driver.

Cosa mostra gputaskman e quando è utile

Il repository ufficiale di gputaskman documenta memoria GPU per processo, attività dei motori grafici e riconoscimento di runtime e modelli locali. Non legge il contenuto arbitrario della VRAM e non può elencare tutte le texture di un gioco. Una libreria CUDA caricata o un file di modello aperto sono indizi: da soli non provano che quel modello stia lavorando sulla GPU.

Il caso tipico è un PC sul quale convivono browser, editor, gioco e un server AI. Se il totale della memoria è alto, il monitor aiuta a capire quali processi osservare. Se invece il dubbio riguarda una percentuale di carico elevata, consulta prima la guida su quando la GPU al 100% è normale: memoria occupata e potenza di calcolo utilizzata rispondono a domande diverse.

Come avviarlo su Windows senza installare altri strumenti

Per un normale PC Windows Intel o AMD, il progetto distribuisce un archivio portatile x64 nella sezione Releases del repository. Esiste anche un pacchetto Windows ARM64 separato: scegli l’architettura del computer, non il marchio della scheda video. Il supporto dichiarato su Windows riguarda GPU NVIDIA e AMD con un driver WDDM compatibile.

1. Scarica il pacchetto dalla sezione Releases del repository ufficiale, evitando copie ripubblicate da siti terzi.
2. Estrai l’intero archivio. La cartella _internal deve restare accanto a gputaskman.exe.
3. Apri Windows Terminal o PowerShell nella cartella estratta ed esegui .\gputaskman.exe.
4. Controlla il nome della GPU osservata, soprattutto sui notebook con grafica integrata e dedicata.
5. Premi s per cambiare ordinamento e scegli la VRAM. Con ? puoi consultare la spiegazione dei contatori.

La distribuzione portatile non richiede Python o CUDA Toolkit. Le build risultano non firmate nella documentazione consultata; il progetto pubblica file SHA-256 per controllare l’integrità degli archivi. La corrispondenza dell’hash non equivale a una certificazione di sicurezza. Se il sistema blocca il file, non disattivare antivirus o protezioni per seguire questa guida: usa i contatori integrati di Windows oppure valuta il programma con chi gestisce il PC.

VRAM, Spill e Paged: tre valori da non sommare alla cieca

Il totale della GPU resta il riferimento. Una risorsa condivisa può comparire nella contabilità di più processi. Microsoft spiega questo comportamento nella propria documentazione dei dati GPU di Gestione attività. Perciò una somma delle righe superiore alla memoria della scheda non dimostra da sola un errore hardware o un consumo impossibile.

• Spill: RAM di sistema accessibile alla GPU. Può includere buffer allocati intenzionalmente; il valore da solo non dimostra che la VRAM sia traboccata.
• Paged: stima ricavata da altri contatori. Non misura direttamente il file di paging e non è la prova che Windows abbia appena spostato quei byte fuori dalla memoria video.
• N/A o null: dato non disponibile. Non significa consumo zero e non certifica un guasto.

Anche le dimensioni attribuite a pesi e KV cache di un modello possono essere stime. Sono utili per formulare un’ipotesi, ma vanno tenute separate dalla memoria effettivamente contabilizzata dal sistema.

Il controllo prima e dopo che rende utile la diagnosi

Per ottenere un confronto leggibile, prepara una piccola scheda con GPU, versione del driver, programma, modello eventuale e impostazioni. Poi cambia una sola variabile. La sequenza seguente è una proposta di diagnosi documentale, non un test che dichiariamo di aver eseguito:

1. Con il programma sospetto chiuso, annota il totale della GPU e i processi principali. Puoi salvare una fotografia testuale con .\gputaskman.exe --once.
2. Apri una sola applicazione e ripeti l’operazione che causa il problema. Per un modello AI, attendi anche la prima risposta: alcune allocazioni avvengono soltanto quando inizia il lavoro.
3. Registra quale processo cresce e quanto cambia il totale. Non attribuire l’aumento a un’app soltanto perché compare in cima alla lista.
4. Chiudi normalmente l’applicazione o scarica il modello dalla sua interfaccia, quindi osserva di nuovo. Evita di terminare processi di sistema come dwm.exe.

Il programma permette anche di esportare istantanee JSON e confrontarle con il comando diff documentato nel repository. Prima di condividere un file diagnostico, controlla che non contenga percorsi locali, nomi utente o dettagli dei tuoi progetti.

Se il responsabile è un modello locale che non riesce a caricarsi, prosegui con la guida a LM Studio e memoria insufficiente. Qui l’obiettivo è identificare il processo; la scelta di contesto, quantizzazione e offload è il passo successivo.

Cosa cambia su Linux e WSL

Su Linux nativo il progetto supporta NVIDIA e, con il driver amdgpu, anche AMD. Le build portatili Linux dichiarano glibc 2.35 o successiva. Le metriche effettivamente disponibili dipendono da driver, piattaforma e permessi.

In WSL la lettura è più delicata: il totale della macchina virtuale può essere misurato sul lato Windows, mentre l’associazione della memoria ai singoli processi Linux può essere inferita. I simboli * e ? segnalano questi casi. Senza interoperabilità con l’host alcuni valori per processo diventano indisponibili: non interpretarli come VRAM libera.

Il risultato utile della diagnosi è una relazione ripetibile tra un’operazione, un processo e l’aumento di memoria. Una colonna rossa o un valore alto, isolati dal contesto, non bastano per decidere quale componente sostituire.