AMD GPU Monitor 2.11.0

AMD GPU Monitor 2.11.0: Process Age, AI Model Servers and GPU Clocks on Linux

AMD GPU Monitor version 2.11.0 is now available. The new release adds an AGE column to the process table, showing how long every program using the GPU has been running. Together with the improvements made since version 2.9.0, the monitor can now also detect local AI model servers, display GPU and memory clock speeds, and measure GPU time for individual graphics applications.

AMD GPU Monitor remains a single Python file for Linux systems with AMD Radeon graphics cards. It needs no additional packages and reads its information directly from the Linux kernel, the AMDGPU driver and the hardware monitoring interfaces.

This article explains what has changed, why the changes are useful, and what a real monitoring screen from an AMD Radeon RX 7900 XTX running a large language model reveals, especially through the new AGE column.

The main changes since version 2.9.0 are:

• Process age: a new AGE column shows how long each GPU process has been running.
• AI model servers: Ollama, llama.cpp, vLLM and other inference servers are detected automatically, together with the models they serve.
• GPU clock speeds: the shader clock and the memory clock are displayed with historical averages.
• GPU time per process: the live view shows how much GPU time each graphics application uses.
• More reliable warnings: messages now report only what the kernel data actually supports.

New in Version 2.11.0: How Long Each GPU Process Has Been Running

The most visible change in AMD GPU Monitor 2.11.0 is the new AGE column, placed directly after the process ID in the process table. It shows how long each program using the AMD Radeon GPU has been running.

The value comes from the start time that the Linux kernel records for every process, so it is exact for all programs, including ROCm workloads such as Ollama and llama.cpp. This is an important difference from some other per-process figures, which depend on counters that not every kernel or GPU exposes.

To keep the display readable, the age is shown in progressively coarser units: 45s for seconds, 12m for minutes, 3h05m for hours and 7d02h for days. The value never takes more than seven characters, so in the live view the age of a long-running program changes rarely and the table does not jump.

Knowing how long a process has been running helps in several ways:

• Detecting memory leaks: a program that has been running for days and holds a large amount of VRAM is the classic sign of slowly growing memory usage.
• Recognising restarts: a restarted program appears with a new PID and a small age.
• Grouping related processes: programs started at the same time, such as the parts of a desktop session, share the same age.
• Confirming fixes: a program that has run for a week with little VRAM shows that a memory problem has really been solved.

The JSON output now includes each process's exact start time and age in seconds for scripting. On narrow terminal windows, the description column is hidden first, so the memory usage bars always keep enough space.

Detect Ollama, llama.cpp, vLLM and Other Local AI Model Servers

A new MODEL SERVERS section lists the local AI inference servers running on the computer and the models they serve. Earlier versions could only report Ollama at its default address.

AMD GPU Monitor 2.11.0 recognises the following servers:

• Ollama.
• llama.cpp, including llama-server and llamafile.
• vLLM and SGLang.
• LM Studio.
• KoboldCpp and LocalAI.
• Text Generation Inference.

Each server is found through its process, and its listening port is read from the system, so servers configured on non-default ports are also detected. For Ollama, the monitor shows the total size of each loaded model and how much of it is stored on the GPU. This shows immediately whether a large language model fits into VRAM or runs mostly on the CPU.

If a server does not respond, refuses the connection, returns an HTTP error or sends an unexpected reply, the monitor reports this explicitly instead of hiding the server. Ollama's internal llama.cpp process is recognised as part of Ollama, so each model is listed only once. Without elevated privileges, servers belonging to other users are shown without their port.

AMD Radeon GPU Clock Speeds and GPU Time per Process

The hardware section now displays the GPU shader clock and the video memory clock, together with the same one-minute, five-minute and fifteen-minute averages as the other sensors. Clock speeds help show whether the graphics card is boosting, idling or holding back under load.

In the live view, a new GPU% column shows how much GPU shader time each application used since the previous refresh. The values come from the per-process engine counters of the AMDGPU driver, so for graphics, Vulkan and OpenGL applications they are real measurements rather than estimates.

Two details are important when reading this column:

• The first frame shows a dash: GPU time is measured between two refreshes, so values appear from the second refresh onwards.
• ROCm processes show n/a: ROCm sends work to the GPU through queues that the kernel does not account for individual processes, so on consumer Radeon cards no monitoring tool can measure ROCm GPU time per process. The overall GPU utilisation still includes this work.

More Reliable Warnings and Readings

Several warnings and messages have been reworked so that they claim only what the kernel data actually shows. This reduces false alarms and makes data problems visible instead of hiding them.

• Eviction trend: the live view now compares each GPU client with itself between refreshes, so an application that starts with memory already placed outside VRAM is no longer mistaken for memory being pushed out.
• Impossible readings: if the kernel reports more VRAM in use than the card actually has, the display remains limited to the card's capacity, but a warning explains the discrepancy.
• Missing statistics: GPU clients that provide no usable memory statistics are now counted and reported.
• Less repetition: the message naming the largest graphics-memory user has been removed, because the sorted process table already shows it.

Smaller Improvements

• New name: the script is now called amd_gpu_monitor.py, and the name is used in the help text, version information, error messages and JSON output.
• Project information: a short line at the bottom of every view, in the help text and in the version output shows the author and the project links.
• Any terminal: characters that a terminal cannot display are printed as question marks instead of stopping the program, and plain ASCII drawing can be selected with PYTHONIOENCODING=ascii.
• Debugging: the environment variable AMD_GPU_MONITOR_DEBUG shows the full error details when something goes wrong.

Real AMD Radeon RX 7900 XTX Output: Reading the Monitor Screen

The screenshot above shows the first frame of the live view on an AMD Radeon RX 7900 XTX running a large language model through Ollama. The header lists the whole RX 7900 family because that is how the Linux PCI database names the chip; with 24 GiB of VRAM, the card is an RX 7900 XTX.

The graphics card is almost full: 21.4 GiB of its 24.0 GiB of VRAM is in use. Of this, 20.1 GiB belongs to the ROCm compute workload and 1.3 GiB to graphics and the driver, leaving 2.6 GiB, or 11%, available.

Because this is the first frame, the historical averages cover "0:00 of 15:00 min", so all four columns show the same values and the GPU% column shows a dash. Both fill in as the monitor keeps running.

Busy, but not working at full power

The GPU is busy 99% of the time, yet it draws only 163 W, half of its 327 W power limit, while the shader clock runs at 2933 MHz. The MODEL SERVERS section suggests the likely reason: the qwen3:235b model is 145.9 GiB in size, and only 19.3 GiB of it, about 13%, is stored on the GPU. Most of the model runs on the CPU, which is consistent with a GPU that always has work to do but is never fully loaded.

Plenty of thermal headroom

All sensors are well below their limits:

• Edge temperature: 63 °C, with a limit of 100 °C.
• Hotspot temperature: 76 °C, with a limit of 110 °C.
• Memory temperature: 64 °C, with a limit of 108 °C.
• Power consumption: 163 W, with a limit of 327 W.

Desktop memory placed outside VRAM

The status section reports 1.0 GiB of graphics memory as evicted: it prefers VRAM but is currently placed elsewhere. Almost all of it, 991 MiB, belongs to gnome-shell. Values marked with ≈ are estimates, because the kernel's exact counter was unusable for those processes.

What the AGE Column Reveals About the System

Read together with the memory figures, the AGE column turns this single screen into a short history of the computer. The processes fall into five groups:

• 8d04h: gnome-shell, Xwayland, xdg-desktop-portal, gsd-xsettings and mutter-x11-frames, with about 1.1 GiB in VRAM and 1.0 GiB evicted.
• 6d21h: firefox, with about 33 MiB in VRAM.
• 5d04h: nautilus, with about 189 MiB in VRAM and 56 MiB evicted.
• 1d01h: llama-server, with 20.1 GiB in VRAM.
• 34m: gnome-system-monitor, with 55 MiB in VRAM.

The desktop session is eight days old

Five processes share exactly the same age of 8 days and 4 hours. They were started together when the user logged in, so they form a single desktop session. Without the AGE column, these processes would look like unrelated entries in the table.

The AI model was loaded after the desktop

The llama-server process, which holds the language model, has been running for only one day, a week after the desktop session started. Loading a 20 GiB model onto a graphics card that already contained the desktop forced the driver to make room. This is the likely source of the 991 MiB of evicted gnome-shell memory. Evicted buffers return to VRAM only when they are used again, so a long-running desktop can keep them outside VRAM for days; logging out and back in resets them.

Firefox is no longer leaking VRAM

With GPU rendering enabled, Firefox previously grew to almost 3 GiB of VRAM within about a week. With GPU rendering switched off, this Firefox process has been running for 6 days and 21 hours and uses only about 33 MiB. Without the age, a small number could simply mean a recent restart; with the age, it shows that the change has really solved the problem.

Nautilus is worth watching

The file manager has been running for 5 days and holds about 245 MiB in total, which is more than expected for a file manager. A single screen cannot prove a memory leak, but if VRAM becomes scarce, restarting nautilus is the easiest way to recover some memory.

Newly started programs are measured exactly

The system monitor, started 34 minutes ago, shows an exact VRAM figure, while long-running and active programs carry the estimate mark. This is consistent with a kernel counter that becomes unreliable in long-lived GPU clients. It is not caused by age alone, however: the small, mostly idle helper processes of the desktop session are eight days old and are still measured exactly.

To confirm whether a process's memory really grows, compare screens taken several days apart or keep the live view running and watch the process row over time.

How to Update and Run AMD GPU Monitor 2.11.0

The source code and technical documentation are available on GitHub:

AMD GPU Monitor — GitHub repository

To download the latest version, run:

curl -O https://raw.githubusercontent.com/luxs-code/amd_gpu_monitor/main/amd_gpu_monitor.py

To start the monitor with a refresh interval of one second, run the following command from the directory containing the script:

sudo python3 amd_gpu_monitor.py -r 1

To check which version is installed, run python3 amd_gpu_monitor.py --version. AMD GPU Monitor requires Linux, an AMD GPU using the AMDGPU driver and Python 3.7 or newer. Elevated privileges are recommended to see all processes and model servers.

Conclusion: Better AMD Radeon GPU Monitoring with Version 2.11.0

AMD GPU Monitor 2.11.0 adds context that raw hardware counters cannot provide on their own. The AGE column shows how long each process has been running, which makes memory leaks, restarts and related processes easy to recognise. Model server detection connects VRAM usage with the AI models responsible for it, while clock speeds and per-process GPU time complete the picture of how the AMD Radeon graphics card is being used.

The real RX 7900 XTX example shows how much a single screen can now explain: when the desktop session started, when the language model was loaded, why desktop memory was moved out of VRAM, and that an earlier Firefox memory problem has been solved.

Visit AMD GPU Monitor on GitHub to download version 2.11.0, read the documentation, and monitor AMD Radeon GPU usage, VRAM and AI model servers on Linux.

Published: 2026-10-25 13:13:15