Microsoft developer releases gputaskman GPU task manager
Scott Hanselman’s open-source gputaskman maps per-process GPU memory, activity and LLM buffer estimates across Windows, Linux, WSL and macOS.
Microsoft vice president Scott Hanselman has released gputaskman, an open-source terminal GPU task manager for Windows, Linux, Windows Subsystem for Linux and Apple Silicon macOS. The project is designed to answer a more useful question than a single utilisation percentage: which processes are using GPU memory, what work is taking place, and where are an AI model's weights and KV cache sitting? 1
The dashboard combines per-process VRAM readings with GPU engine activity and runtime information. It can connect processes to loaded runtimes, model files and LLM buffer details, including estimates for weights and KV cache where supporting evidence exists. The project warns that visibility depends on the operating system, GPU, driver and runtime, so the output is not a universal inventory of everything inside a graphics card. 1
That caveat matters. gputaskman distinguishes measurements from classifications and estimates, and explicitly warns that finding a CUDA or PyTorch DLL does not prove which model is loaded or being used. A mapped file does not necessarily prove that a model is resident on the GPU or actively running. The repository describes the software as early and experimental rather than a finished replacement for Windows Task Manager. 1
The project supports Windows systems with NVIDIA or AMD GPUs, native Linux with NVIDIA, AMD and limited Intel support, WSL, and Apple Silicon Macs. Its repository also lists terminal commands for running a live interface or requesting a one-off JSON snapshot, giving developers a way to inspect GPU usage without opening a heavyweight graphical monitor. 1
Our opinion
gputaskman is interesting because it tries to connect the numbers GPU monitors show with the software actually responsible for them. That makes it potentially useful for developers running local AI workloads, especially when a vague “VRAM full” reading is not enough to explain a slowdown. Its experimental status and platform-specific gaps mean the output should be treated as a debugging aid, not an unquestionable source of model identity. The project is worth watching precisely because it is trying to make those limits visible rather than hiding them behind a neat-looking percentage. 1