Scott Hanselman's gputaskman Tracks Per-Process VRAM and LLM Usage on Windows, Linux and WSL

What gputaskman is​

Neowin first reported the tool on November 6. The project's GitHub repository describes it as a GPU task manager for Windows, Linux, and WSL, with per-process VRAM, GPU activity and LLM model and KV-cache insights. Hanselman pitches it as an "htop" for what's inside your GPU, not just how full it is.

The tool is a terminal UI. It links per-process GPU memory and engine activity to loaded runtimes, model files and LLM buffer breakdowns.

The tool is new, and it's moving fast. GitHub release tags v0.1.0, v0.2.0 and v0.3.0 all appeared on November 3. Based on the project's release notes, Linux and WSL support arrived in v0.2.0 and AMD support in v0.3.0. Hanselman also posted publicly that he was building a GPU Taskman to get insights to where my GPU memory is going.

The AMD support came through a community pull request. A Copilot triage bot working on Hanselman's behalf commented on that PR. It fixed a temperature-scaling bug that made AMD SMI readings roughly 1000 times too low, and it noted that the PR was also exercised on a Radeon 860M.

What it shows​

Per the README, the tool has four main areas:

• Device view: VRAM usage, GPU activity, memory activity, PCIe traffic, temperature, power, video-engine clock and history charts.
• Process view: local GPU memory, GPU-accessible system RAM, estimated non-resident commit and engine activity. It also detects runtimes such as CUDA, HIP, Vulkan, Direct3D, ggml and ONNX Runtime.
• Model inspector: which model a process appears to hold, how it was identified, its architecture, quantization, layer count, weights, estimated KV-cache cost and buffer sizes from compatible load logs.
• Server hints: friendly Ollama or LM Studio model names, plus context size, busy slots and throughput when available.

Measured numbers versus educated guesses​

This is the most important point for anyone reading the output. The README separates measured counters from inferred details.

• Measured: On Windows, the graphics kernel supplies per-process memory and engine counters. NVML or AMD libraries supply device metrics.
• Inferred: Candidate models come from command lines, mapped files, GGUF headers, local server APIs and runtime logs.
• Not claimed: A loaded GPU DLL doesn't prove a process is using the GPU. A mapped model file doesn't prove the model is sitting in VRAM. The tool doesn't dump VRAM, and it can't identify individual game textures, tensors or kernels. For that, the README points to PIX, Nsight or runtime-specific instrumentation.

The README gives a worked example on an RTX 4080 SUPER, using Docker Model Runner's llama-server (Vulkan) with gemma-3-270m. Raising context from 4096 to 32768 produced an estimated 504 MB of extra KV cache, but measured dedicated memory grew by only 83 MB. The README attributes the gap partly to Gemma 3's sliding-window attention, and it calls the estimate an upper bound. This is one machine and one model, not a benchmark.

Gotchas in the Windows numbers​

• Spill is GPU-accessible system RAM. On its own, it doesn't prove that VRAM overflowed.
• Paged is an estimate, calculated as committed memory minus local and non-local usage. It isn't an eviction trace or a pagefile measurement.
• Double-counting: The same shared surface can be charged to an application, csrss.exe and dwm.exe. Summing process rows can therefore overstate usage, and the adapter total remains the reference. The README prefers the "Local Usage" and "Non Local Usage" counters to reduce this.
• Missing values show as N/A in the UI and null in JSON. They mean "not available," not "zero."

The README also addresses nvidia-smi. On GeForce cards under WDDM, Windows manages GPU memory, and NVML may report per-process memory as N/A. Windows counters can still attribute usage across Direct3D, Vulkan, OpenGL and CUDA.

Getting it running on Windows​

There are two routes.

Portable download (no Python needed)

1. Download the ZIP that matches your hardware from the project's Releases page: x64 for Intel and AMD PCs, or ARM64 for native Windows ARM64. They are separate builds, not a universal executable.
2. Extract the entire ZIP. Keep the _internal folder next to gputaskman.exe.
3. Open Windows Terminal or PowerShell in that folder and run .\gputaskman.exe. Use --once for a text snapshot or --json for JSON.
4. You need a supported GPU with a current WDDM driver. No Python, uv, CUDA Toolkit or model download is required.

The builds are currently unsigned, and there is no installer. Each ZIP ships with a .zip.sha256 companion file for integrity checks. Verify the hash before running an unsigned executable.

From source

1. Install Git and uv. The README suggests winget install --id Git.Git --exact and winget install --id astral-sh.uv --exact.
2. Open a new PowerShell window so both tools are on PATH.
3. Run git clone [GitHub - shanselman/gputaskman: A GPU task manager for Windows, Linux, and WSL: per-process VRAM, GPU activity, and LLM model/KV-cache insights (Windows AMD and NVIDIA). · GitHub](https://github.com/shanselman/gputaskman.git), then cd gputaskman, then uv run --locked gputaskman.
4. The first run needs internet access. No administrator session or API key is needed.

If you'd rather use pip, the README documents a virtual-environment route for Python 3.11 or newer.

Comparing before and after

Run gputaskman --json to save one snapshot, change something, and save another. Then run gputaskman diff before.json after.json. The README suggests taking the second snapshot after the model has answered one request. CUDA and Vulkan can allocate lazily, and allocators keep freed memory cached, so changes can show up late. The diff compares measured counters only. Estimates and runtime-reported buffers are listed separately.

Quick troubleshooting (from the README)

Platform differences​

• Windows: The README lists live checks on an RTX 4080 SUPER and an RTX Spark N1X on Windows ARM64. It also lists an AMD check on a Radeon 860M, on Windows 11 Enterprise build 26300 with AMD driver 32.0.22050.1003. In that AMD check, WDDM supplied per-process VRAM and AMD ADL supplied utilization, clocks and power. Temperature, memory-activity and PCIe readings were unavailable. Vulkan and ROCm workloads weren't tested on that machine.
• Linux: The release builds need glibc 2.35 or newer and an NVIDIA driver. Per-process memory and load come from NVML. Spill and Paged are blank, because Linux has no WDDM-style counters. Other users' processes need sudo. The README says bare-metal Linux is covered by tests but hasn't been run on hardware. A live container check was done on Vast.ai.
• WSL: Windows owns the GPU, so Linux can't see its own processes' VRAM. With interop enabled, the tool starts a PowerShell process to read Windows counters. The WSL VM total is exact. Per-process ownership inside the VM is matched, marked *, or guessed, marked ?. With --no-host or interop off, per-process VRAM shows as n/a. Other Hyper-V VMs or Windows Sandbox can make that row ambiguous.
• macOS (Apple Silicon): It runs from a clone only, with no portable download yet. Metal gives one GPU time per process, with no 3D, compute, copy or video split. Spill, paged, clocks, power and temperature aren't available.

How reliable is it?​

Neowin's reviewer ran the Windows version and said it mostly worked as expected. One quirk was a GPU temperature reading that sometimes stuck on one value. That is a single reviewer's impression, and the project says plainly that it is early software.

Treat the model and memory breakdowns as a well-informed starting point, not ground truth. The README itself warns that the estimates assume llama.cpp-style placement, and that partial offload, KV quantization and multiple models in one process can change the result.

For admins, there are two cautions. The project is a personal GitHub repo with unsigned binaries, so check hashes and your own software policy before deploying it. The README also says the tool reads local process metadata, model headers, load logs and local server responses, and that it doesn't send telemetry. That claim is the project's own, so verify it if your environment requires it.

Why it matters​

Local AI has made GPU memory a contested resource. A browser, the desktop compositor, a game and a model server can all compete for it. Task Manager's single number makes that contention hard to diagnose. gputaskman won't replace profilers like PIX or Nsight. If it keeps its measured-versus-estimated discipline, though, it could become a handy first stop when a model won't fit or a game stutters next to an LLM server.