GitHub’s Releases page labels gputaskman v0.3.5 “Latest.” The project monitors local GPU activity by device and process, with additional runtime and model details where supported. Its documentation separates measured counters from estimates, so a model label or memory breakdown is not the same as a direct measurement. (Releases; project documentation)

What changed after v0.3.0

The release notes show that the project has gained platform support and monitoring options since v0.3.0. They list Apple Silicon macOS and native Linux AMD support in v0.3.1, an optional slim view and recovery after Windows adapter changes in v0.3.4, and Linux Intel GPU support plus JSON session recording in v0.3.5. GitHub labels v0.3.5 “Latest.”

What the readings tell you

The device view can report GPU memory and activity, with other telemetry such as temperature, power, clocks and PCIe traffic available on supported hardware and drivers. The process view can show GPU memory, GPU-accessible system memory and engine activity by process. The project also documents runtime and model inspection, live terminal display, one-shot text or JSON output, snapshot comparisons and JSONL session recording. (Project documentation)

The distinction between counters and model details matters when you are tracking an AI workload. The project describes device and process counters as measurements; classifications and GGUF-derived breakdowns, including estimates for model weights and KV cache, are estimates. A PyTorch/CUDA DLL alone does not identify a model or establish that it is training. A mapped model file does not establish that the model is resident on the GPU or active. Some values can also be unavailable or unattributable, depending on the platform and operating mode.

Practical rule: Treat a process counter as a measured reading; treat model classifications and GGUF-derived breakdowns as estimates.

A missing counter is not a measured zero. For example, the project says per-process VRAM is unavailable in WSL when host interop is disabled. On Apple Silicon, CPU and GPU share unified memory, so the tool cannot report a separate VRAM pool as it can for a discrete GPU. Its scope is local GPU workloads; CPU-only, NPU-only and cloud workloads are outside it. (Project documentation)

Which installation path fits your system

On 64-bit Windows 10 or 11, the project documents NVIDIA or AMD GPUs with a current WDDM driver. Portable Windows builds are available for x64 and ARM64. They are unsigned; the documented setup is to extract the whole archive, keep _internal beside gputaskman.exe, then launch the executable from PowerShell or Windows Terminal. Those portable builds do not require Python.

For a Python-based installation, the project documents uv tool install gputaskman or pipx install gputaskman, followed by gputaskman; Python 3.11 or later is required for this route. Linux builds are documented for x64 and ARM64. NVIDIA support is documented across Linux and WSL, while AMD and Intel support is documented for native Linux.

On macOS, support is for Apple Silicon, and the project directs users to run it from a clone rather than a portable download. (Project documentation)

For a quick read, gputaskman --once prints a snapshot and gputaskman --json outputs JSON. The project also documents gputaskman record for periodic JSONL snapshots and gputaskman diff to compare two JSON snapshots.

What the reported RTX 4060 run showed

Tom’s Hardware reported testing v0.3.0 on an RTX 4060 Laptop GPU. After finding no tasks initially using the discrete GPU, it started Unigine Valley and described live GPU-load, VRAM-use, temperature and related charts. That account is specific to its v0.3.0 run; the Releases page now labels v0.3.5 “Latest.”