DEV Community

Cover image for gputaskman v0.4.1: See Which Processes Are Actually Using Your GPU
Sh Raj
Sh Raj

Posted on

gputaskman v0.4.1: See Which Processes Are Actually Using Your GPU

#ai #opensource #linux #python

gputaskman v0.4.1: See Which Processes Are Actually Using Your GPU

When a GPU shows 90% memory usage, the number alone does not tell you what is happening. Is it an LLM's weights? A growing KV cache? A browser tab? A desktop compositor? A training process that is quietly spilling into system RAM?

gputaskman is an open-source terminal GPU task manager that tries to answer those questions by connecting device counters, per-process memory, GPU engine activity, runtime evidence and model metadata.

The timing is interesting: the project published v0.4.1 on November 13, 2026, with updates for Intel GPU activity on Windows, custom model-path detection, Snapdragon/Foundry Local model identification, and Qualcomm shared-memory reporting. The repository is still experimental, but this release makes it worth a closer look.

gputaskman live GPU overview showing processes, memory buckets and LLM details

What it shows

The project's goal is to be an htop-like view into the GPU rather than another simple "memory used" meter.

Depending on the operating system, driver and hardware, it can show:

  • Per-process GPU memory and activity
  • Dedicated VRAM versus GPU-accessible system memory
  • GPU engine activity such as graphics, compute, copy and video
  • Device load, temperature, power, clocks and PCIe information where available
  • Runtime and model evidence for supported AI workloads
  • Estimated LLM weights and KV-cache breakdowns when the required model metadata is available
  • System RAM and CPU context alongside GPU processes

This is useful when you run local inference, training, fine-tuning, video workloads, graphics applications or several GPU-heavy applications at once.

Install it

The easiest route is the isolated Python tool installation:

uv tool install gputaskman
gputaskman
Enter fullscreen mode Exit fullscreen mode

Or use pipx:

pipx install gputaskman
gputaskman
Enter fullscreen mode Exit fullscreen mode

The project requires Python 3.11 or later and a supported GPU/driver configuration. Both installers keep the application in an isolated environment. The shorter command, gtm, is also available.

Upgrade with:

uv tool upgrade gputaskman
Enter fullscreen mode Exit fullscreen mode

Windows users who do not have Python can download the portable ZIP from the GitHub Releases page. The project publishes separate x64 and ARM64 builds; keep the extracted _internal folder beside the executable.

Useful commands

The live terminal interface is the normal starting point:

gputaskman
Enter fullscreen mode Exit fullscreen mode

For scripts and comparisons, use one-shot output:

# One text snapshot
gputaskman --once

# One JSON snapshot
gputaskman --json
Enter fullscreen mode Exit fullscreen mode

You can compare two snapshots to see what changed after starting a model or increasing its context length:

gputaskman --json > before.json

# Start a model or send it a request, then capture again
gputaskman --json > after.json

gputaskman diff before.json after.json
Enter fullscreen mode Exit fullscreen mode

For a longer workload, record a session:

gputaskman record --duration 300 -o session.jsonl
Enter fullscreen mode Exit fullscreen mode

That records one JSON snapshot per second for five minutes. It is useful for watching memory changes during model loading, inference, training or a game session.

Why the model and KV-cache view matters

A local LLM can use GPU memory for several different things:

  • Weights: the model parameters loaded for inference.
  • KV cache: attention keys and values retained for the current context.
  • Compute buffers: temporary memory used by the runtime.
  • Other allocations: graphics, browser rendering, desktop composition and unrelated GPU processes.

A single VRAM percentage hides those differences. gputaskman attempts to combine measurements with runtime logs, process arguments, mapped files and GGUF metadata to give a more useful explanation.

gputaskman compositor process view

There is an important distinction: the device and process counters are measurements, while some model classifications and GGUF-derived memory breakdowns are estimates. The project does not dump raw VRAM or enumerate every texture in a game. A mapped model file is evidence that a process opened or referenced it, not proof that the model is currently resident on the GPU.

That evidence-first approach is a good thing. GPU monitoring becomes misleading when a tool presents guesses as measured facts.

Platform support

The project supports several platform combinations, but not every counter is available everywhere:

Platform Current scope
Windows NVIDIA and AMD telemetry, plus Intel WDDM activity
Linux NVIDIA, AMD and Intel support through the documented driver interfaces
WSL NVIDIA support and Windows host counters where available
macOS Apple Silicon support, with unified-memory and Metal-specific limitations

On Apple Silicon, memory is shared between CPU and GPU rather than split into dedicated VRAM in the same way as a discrete graphics card. Some counters such as temperature, power, spill and engine breakdown are not available through the same interfaces. The project also notes that there is no portable macOS download yet.

Always check the platform-specific documentation before comparing numbers across machines.

What changed in v0.4.1?

The November 13 release adds several practical improvements:

  • Detect custom model-path arguments with explicit provenance.
  • Report Intel GPU activity from Windows WDDM counters.
  • Show NVIDIA GPUs running in TCC mode, with hardware testing still needed.
  • Keep Intel integrated WDDM memory out of dedicated VRAM totals.
  • Identify loaded Foundry Local models on Snapdragon.
  • Report Qualcomm GPU memory as shared RAM.
  • Read the Windows GPU driver version from Plug and Play data.
  • Handle recording I/O failures more cleanly.

These changes matter because GPU visibility is not one API call. Windows, Linux, WSL and macOS expose different counters and different levels of process attribution.

How it compares with existing tools

  • Task Manager is convenient for a quick overview, but it does not provide the same model-oriented breakdown.
  • nvidia-smi is excellent for NVIDIA device and process information, but it does not attempt to explain all of the runtime and model context shown by gputaskman.
  • nvtop is a useful cross-platform terminal monitor, especially for live GPU usage.
  • Vendor utilities can expose device-specific metrics, but the experience varies by hardware.

I would use gputaskman when I need to understand a local AI workload or compare before-and-after memory usage. I would still keep vendor tools available when I need to validate a low-level counter.

Maturity and licence

The repository explicitly calls itself early, experimental software. Hardware and driver coverage can differ, and some classifications are estimates. It is licensed under MIT.

Treat it as an observability aid, not as a source of forensic certainty. If a number looks surprising, compare it with the operating system, vendor utilities and the runtime's own logs.

Project links

GitHub logo 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).

gputaskman

An htop for what's inside your GPU, not just how full it is.

Windows with NVIDIA/AMD telemetry and Intel WDDM activity, plus Linux and WSL support (NVIDIA everywhere, AMD and Intel on native Linux; see Linux and WSL) and macOS on Apple Silicon (see macOS). A terminal UI that connects per-process GPU memory and engine activity with loaded runtimes, model files, and LLM buffer breakdowns.

Task Manager says "15 GB used." This tries to answer: by what? Model weights? KV cache Your browser? The desktop compositor? And why is so much GPU memory in system RAM?

Scope: local GPU workloads, not cloud services. Decision models, vision, speech, LLM inference training/fine-tuning (including Unsloth), graphics, and video all belong here. Visibility varies process memory and engine activity are measured; identifying individual models and their work requires supporting evidence. A PyTorch/CUDA DLL alone cannot identify a model or prove training,…

View on GitHub

No verified maintainer video or X post was found in this run, so I have used the project's own screenshots and release notes instead of inserting unrelated media.

If you run local models, which metric do you wish your current GPU monitor explained better: KV cache, shared memory, per-process usage, or GPU engine activity?

Written by Sh Raj. Find more engineering notes on GitHub, connect on LinkedIn, and watch practical developer tutorials on StackShade.

Top comments (0)