GPUtaskman connects per-process GPU memory and activity with evidence about loaded runtimes and models. The MIT-licensed shanselman/gputaskman repository was created on November 3, 2026. Its documentation describes experimental software with a useful distinction: device and process counters are measurements, while model classifications and GGUF-derived memory breakdowns are estimates.
For developers investigating a model run's memory use, that distinction affects how to read the output. A process loading a PyTorch or CUDA library does not identify its model or prove it is training. Even a mapped model file does not prove the model is resident on the GPU, the README cautions. This account covers the supplied documentation inspected on November 9, 2026. MrKeyoor did not run the monitor or verify its display on GPU hardware.
Missing counters depend on the backend
The platform documentation describes Windows, Linux, WSL and Apple Silicon macOS support, with visibility dependent on the GPU and driver configuration. On native NVIDIA Linux, the tool reads process memory and activity through NVIDIA's Management Library, or NVML. On native NVIDIA Linux, Spill and Paged stay blank because the backend lacks the corresponding Windows memory counters.
For scripts consuming that NVIDIA backend's output, unavailable Spill, commit and Paged counters become JSON null, rather than a measured zero. Those blank fields therefore do not establish that a process used no memory of that kind. Native AMD Linux differs: GPU-accessible system RAM, called GTT, can populate Spill, subject to attribution limits. On an integrated GPU detected as an APU, the documentation says GTT is normal GPU memory and is not flagged as spill. Paged remains blank because there is no commit counter. When the AMD backend cannot establish exclusive ownership of memory, process VRAM and Spill are unavailable and the bytes remain unattributed.
Under WSL, per-process GPU load is unavailable for Linux processes, and per-process VRAM depends on matching information from the Windows host. The matching documentation distinguishes a matched size from a guessed owner. A measured memory size does not by itself establish which Linux process owns it.
Containers add another attribution problem. NVML supplies host process IDs, while a container sees its own process IDs. GPUtaskman pairs unresolved IDs with container processes that have CUDA's library mapped. Its documented matching scheme uses ? when NVML lists more compute processes than the container contains, such as when another container shares the GPU. Check that marker before assigning a memory total to a specific job.
Reported checks leave hardware gaps
The maintainer's reported checks include NVIDIA workloads in a GPU container. In that NVIDIA discussion, the README says bare-metal Linux is covered by tests but has not been run on hardware. These are project-reported results, not MrKeyoor measurements. The limitation concerns the NVIDIA path: the documentation separately reports an AMD bare-metal Linux check, while noting that its stricter memory-attribution rules have unit-test coverage only and have not yet been validated on AMD hardware.
Before using a reading to explain a job's memory use, check the backend, whether the counter is available and how the process owner was assigned. GPUtaskman's documentation provides those distinctions; this documentation review does not establish their accuracy on a reader's GPU, operating system or workload.