nvtop: Monitor NVIDIA, AMD, and Intel GPUs on Linux

nvtop is an htop-style GPU monitor for Linux. Install it with your package manager and run it with no arguments:

sudo apt install nvtop
nvtop

You get a full-screen ncurses view: a utilization and memory bar per GPU at the top, scrolling line plots in the middle, and a sortable list of the processes using the GPU at the bottom. It works across NVIDIA, AMD, and Intel cards from the same binary, which is the whole point. nvidia-smi covers NVIDIA only; nvtop reads NVIDIA via the proprietary driver, AMD via amdgpu, and Intel via i915/Xe, so one tool answers "what is on the GPU right now" regardless of vendor.

The thing to know up front: nvtop is read-mostly. It shows you live state and lets you sort and signal processes, but it does not change clocks, fan curves, or power limits. For "what is pinning my GPU and can I kill it", it is the fastest answer on Linux. For tuning, you still reach for the vendor tools.

Install nvtop

It is packaged on every mainstream distro, so you rarely build from source.

# Debian / Ubuntu (20.04+)
sudo apt install nvtop

# Fedora (36+)
sudo dnf install nvtop

# Arch
sudo pacman -S nvtop

On older Ubuntu where the repo version lags, the maintainer's PPA has newer builds:

sudo add-apt-repository ppa:quentiumyt/nvtop
sudo apt install nvtop

No NVIDIA-specific setup is needed beyond having the driver installed. nvtop links against the driver libraries it finds at runtime, so a box with both an AMD and an NVIDIA card shows both in one view.

Read the nvtop screen

Launch it bare:

nvtop

The layout, top to bottom:

• Device header per GPU: name, the utilization bar (GPU compute), the memory bar (VRAM used vs total), temperature, power draw, and fan speed where the driver exposes them. ENC and DEC percentage meters appear next to the utilization bar only while the video encoder or decoder is actually in use, and auto-hide after a period of inactivity.
• Line plots in the middle: a rolling history of the chosen metric (utilization or memory) per GPU, so a spike is visible as a spike, not just a number that already moved.
• Process list at the bottom: PID, user, the GPU it is on, the type (Graphics or Compute), GPU memory used by that process, and the command. This is the part you came for when a GPU is at 100% and you need to know what is holding it.

Memory sizes are reported in multiples of 1024 (1 KiB = 1024 bytes), matching how the drivers report VRAM, so the totals line up with nvidia-smi.

Sort the process list and signal a process

The process list is interactive. The keys that matter day to day:

The usual workflow when a GPU is saturated: press F6, pick GPU memory or utilization, press - to put the heaviest consumer at the top, highlight it, then F9 to send it a signal. F9 opens a signal picker rather than blindly sending SIGKILL, so you can send SIGTERM first and let the process clean up. That is friendlier than kill -9 <pid> against a training job mid-checkpoint.

Change the refresh rate

The default refresh is fine for eyeballing, but for catching short spikes or for a calmer display you set the delay explicitly. The flag is -d (or --delay), and the unit is tenths of a second, not seconds:

nvtop -d 5    # refresh every 0.5s
nvtop -d 20   # refresh every 2s

So -d 10 is one update per second. The man page is explicit about it: "Delay between updates, in tenths of seconds (delay * 0.1s)." It trips people up because most monitors take the delay in whole seconds. A faster refresh (-d 2 for 0.2s) catches brief encode/decode bursts; a slower one (-d 50 for 5s) is easier to read on a shared dashboard.

A couple of other flags worth knowing:

nvtop -C     # monochrome, for terminals with a broken palette
nvtop -p     # collapse to a single bar plot (max across all GPUs)
nvtop -f     # show temperature in Fahrenheit
nvtop -E -1  # keep the ENC/DEC meters always visible

-E sets the encode/decode auto-hide timer in seconds (default 30); pass a negative value to pin those meters on permanently. Settings you change live in the F2 setup window can be persisted with F12, which writes a config file under ~/.config/nvtop/ (XDG-respecting), reloaded on the next launch. Let F12 manage that file rather than hand-editing it.

nvtop vs nvidia-smi vs other monitors

nvtop is not the only GPU monitor, and it is not always the right one.

Reach for nvtop when you have mixed hardware, or you just want the htop reflex (run it, read it, kill the offender) without remembering vendor-specific commands. Reach for nvidia-smi when you are on pure NVIDIA and need to change something (set a power limit, lock clocks, query a specific field for a script) or want a one-shot snapshot you can pipe. The two are complementary, not competing; I keep nvtop open in a pane and use nvidia-smi for scripting and tuning.

Caveats and when not to use it

• Some fields show N/A. That is the driver, not nvtop. Pre-Kepler NVIDIA hardware (NVML drops some queries on older cards), or an AMD card on an old kernel, expose fewer metrics than nvtop can display.
• Driver coverage varies. On NVIDIA, nvtop loads libnvml.so from the proprietary driver, so the nouveau open-source stack is not supported; switch to the proprietary driver. On AMD, the legacy radeon driver works but exposes far fewer metrics than amdgpu, and the per-process list specifically needs the fdinfo interface that landed in kernel 5.14, so on older kernels the process view can come up empty even with amdgpu. Intel exposes the same fdinfo per-process interface only from kernel 5.19 (i915/Xe), so a pre-5.19 kernel shows Intel utilization but no process list.
• It does not log. nvtop is an interactive viewer with no built-in CSV or time-series export. For monitoring over time, feed Prometheus with DCGM exporter (NVIDIA) or scrape nvidia-smi --query-gpu=... --format=csv -l, and use nvtop for the live look.
• It does not tune. No clock, fan, or power control. That is nvidia-smi, nvidia-settings, or the AMD equivalents.
• macOS and Windows. nvtop is Linux-first (it reads Linux driver interfaces). Apple Silicon support exists but is limited; on Windows there is no native build.

For watching CPU-side I/O and per-process system load alongside the GPU, I run iotop for disk I/O and pidstat for per-process CPU and memory in adjacent panes; together with nvtop that covers most "why is this box busy" questions without leaving the terminal.

See also

• Watch per-process disk I/O with iotop: the disk-side companion to nvtop when a job is I/O-bound rather than GPU-bound
• Per-process CPU, memory, and I/O stats with pidstat: sampling-based process metrics that pair well with a live GPU view
• See bandwidth by connection with iftop and watch raw throughput with nload: the network-side live monitors for when a job is pulling data, not crunching it
• External: nvtop on GitHub, the source of truth for supported vendors and build instructions.

FAQ