NVTOP: an htop-style monitor for GPUs and accelerators on Linux

What NVTOP solves, and who it is for

NVTOP stands for Neat Videocard TOP. The README describes it as a (h)top like task monitor for GPUs and accelerators that can handle multiple GPUs and print information about them in an htop-familiar way. That framing is the whole product: instead of one vendor tool per card, you get a single ncurses interface listing devices and the processes using them.

The audience is people who already live in a terminal. If you run training jobs, inference servers or graphics workloads on Linux and want to know which process holds GPU memory, which card is hot, or how much PCIe traffic a job generates, NVTOP is aimed at you. It is not a profiler and not a scheduler. It reports what the driver and vendor libraries expose.

Vendor coverage is unusually wide for a single C program: AMD (amdgpu and, with limited metrics, the legacy radeon driver), Apple M1 and M2 (limited, and only when building for Apple), Huawei Ascend, Intel i915 and Xe, NVIDIA via NVML, Qualcomm Adreno via the msm driver, Broadcom VideoCore, Rockchip, MetaX, Enflame, Iluvatar CoreX and Tenstorrent. The breadth is the selling point, and also the source of most of its rough edges, because each backend has different capabilities and different kernel requirements.

How NVTOP gets its numbers: vendor libraries plus kernel fdinfo

There is no single data path. NVTOP composes its view from two kinds of source, and understanding the split explains most of its behaviour.

Device-level metrics come from vendor libraries or driver interfaces. NVIDIA is queried through NVML; the README notes that NVML does not support some queries for GPUs older than the Kepler microarchitecture, and that anything from GeForce 600, GeForce 800M and later should work. Iluvatar CoreX goes through the ixML library, which NVTOP dynamically loads from /usr/local/corex/lib, /usr/local/corex/lib64, or the default dynamic loader search path, using an NVML-compatible API surface for device, power, PCIe, clock, temperature, memory and process data. Ascend uses the DCMI API (version 6.0.0), and the README is explicit that DCMI exposes limited APIs, missing PCIe generation, tx/rx throughput and max power draw. MetaX uses MXSML, Enflame uses EFML, Tenstorrent uses the tt-kmd kernel driver.

Per-process attribution on AMD, Intel and Adreno comes from the kernel's fdinfo interface instead. That is why kernel versions appear in the support matrix: AMD introduced fdinfo in kernel 5.14, Intel in 5.19, and msm in 6.0. Below those versions NVTOP can still show the device, but not which processes are using it.

Intel adds a permissions wrinkle. The README states that Intel requires CAP_PERFMON or CAP_SYS_ADMIN to access total memory usage and an accurate GPU frequency, and suggests running sudo setcap cap_perfmon=ep $(which nvtop) or running nvtop as root. That is a real privilege decision, not a formality: a setcap binary keeps the capability across invocations, while running as root widens what a terminal UI can touch.

Installing NVTOP on Ubuntu, Debian, Fedora or from source

The README documents distribution packages before it documents building. Ubuntu and Debian have packages for Impish (21.10) and Debian buster and more recent; Fedora, Red Hat and CentOS, OpenSUSE, Arch Linux and Gentoo each have their own section, and there are also AppImage, Snap and Conda-forge routes. The fastest path on a Debian-derived system is the package manager, which also pulls the runtime libraries.

sudo apt install nvtop

After installation the manpage is the reference for options, and the built-in help lists command line arguments.

man nvtop
nvtop --help

If your distribution's package is missing or too old, the repository builds with CMake. The build dependencies listed in the Dockerfile are build-essential, libncurses5-dev, libncursesw5-dev, libssl-dev, pkg-config, libdrm-dev, libgtest-dev, libudev-dev and python3-venv, with a recent CMake installed through a Python virtual environment. The Dockerfile itself performs the canonical build sequence.

mkdir -p build && cd build
cmake ..
make -j
sudo make install

Once running, press F2 to open the setup window. The Chart section lets you choose which metrics are plotted, including GPU and memory utilization, temperature, power, clocks, and the PCIe RX / TX load, described in the README as receive and transmit throughput as a percentage of maximum link bandwidth. Press F12 to save preferences so they load on the next run. If you prefer containers, the repository's Dockerfile is built as docker build . -t nvtop and run as docker run --rm -it --gpus all --pid host nvtop, with the entrypoint set to /usr/local/bin/nvtop; the --pid host flag is what lets it see host processes.

Where NVTOP stops being the right tool

The first limitation is the one users hit most: no GPU to monitor. Every backend in NVTOP depends on something outside the program being present and recent enough. On AMD, if your kernel is older than 5.14, device metrics may appear while the process list stays empty. On Intel, the same applies below 5.19, and memory totals and frequency can be wrong without CAP_PERFMON. On Adreno, below kernel 6.0 there is no fdinfo, so per-process data is absent. NVTOP cannot compensate for a driver that does not expose the interface.

The second limitation is uneven depth across vendors. The README itself flags the gaps: radeon provides limited metrics compared to amdgpu; Ascend's DCMI is missing PCIe generation, tx/rx throughput and max power draw; Apple support is described as still being worked on, with bugs and limitations, and is only available when building for Apple, where it is also the only supported vendor. VideoCore needs the linux-rpi 6.12.y kernel or above on non-Raspberry Pi OS systems and the /dev/vcio device. Several backends are described as tested on exactly one board or card, such as Atlas 800 (910B), Raspberry Pi 4B, Orange Pi 5 Plus, MXC500, and Enflame S60, L300 and L600. A single tested configuration is not a support guarantee for your hardware.

Third, NVTOP is read-only observability. It does not cap power, set clocks, kill processes or schedule work. If a job is starving another job of GPU memory, NVTOP will show you the memory column; it will not fix the contention. And it is not a Windows tool. The README's installation sections are Linux distributions plus Apple builds, with a WSL2 section, so Windows users are expected to run it inside WSL2 rather than natively.

NVTOP against nvitop and btop

The most direct comparison is nvitop, which is the other name people search alongside this one. The difference is scope and runtime. NVTOP is a C program with a CMake build and a set of vendor backends covering AMD, Apple, Huawei, Intel, NVIDIA, Qualcomm and several accelerator vendors. nvitop is a Python tool, and the README's vendor list shows NVTOP's reach extends well past NVIDIA hardware. If your fleet is mixed, or if your accelerators are Ascend, MetaX, Enflame, Iluvatar or Tenstorrent, NVTOP is the one with a backend for them. If your environment is NVIDIA-only and Python tooling is easier to distribute than a compiled binary with driver dependencies, nvitop is the lighter operational fit. The README does not attempt a feature-by-feature comparison, so treat the choice as a question of which vendors you actually have.

btop is a different category. It is a system monitor with a GPU panel, and the comparison people search for is really about whether a general system monitor is enough. NVTOP's answer is process-level GPU attribution across multiple devices and vendors, which is a narrower and deeper job. If you need CPU, memory, disk and network in one view, btop covers more ground; if the question is which process is holding GPU memory on card 3, that is what NVTOP was built to answer. The two are not mutually exclusive, and the README presents NVTOP purely as a GPU and accelerator monitor.

Licence, packaging and the cost of keeping up

The repository carries both a COPYING file and a LICENSE file at the top level, and the README ends with a License section, but the GitHub metadata reports the licence as NOASSERTION, meaning the platform could not classify it automatically. If you plan to redistribute NVTOP or bundle it into a product image, read COPYING and LICENSE directly rather than relying on a classifier. Nothing here is legal advice, and the practical point is simply that the licence text is in the repository for you to read.

Upgrade cost is dominated by the kernel and driver, not by NVTOP itself. The release cadence visible in the repository is modest: 3.3.0 in January 2026, a bugfix 3.3.1 later that month, and 3.3.2 in February 2026, with the last push to the default branch on 2026-09-20. Because per-process support depends on kernel fdinfo versions and device metrics depend on vendor libraries such as NVML, DCMI, ixML, MXSML and EFML, a distribution upgrade that changes your kernel or driver stack can change what NVTOP displays without NVTOP changing at all. The inverse also holds: a new NVTOP release may add a vendor backend that your kernel cannot feed yet.

Distribution packaging is a mixed blessing here. A packaged NVTOP is easy to install and upgrade, but it is built against whatever libraries your distribution ships, which is exactly the constraint that makes a source build attractive when you have a vendor library in a non-standard location, as with Iluvatar CoreX's /usr/local/corex/lib. Building from source gives you control over that discovery; it also means you own the rebuild whenever ncurses, libdrm or a vendor library moves.

Editorial conclusion

Adopt NVTOP if you run Linux workstations or servers with AMD, Intel, NVIDIA or accelerator cards and want process-level GPU visibility in one terminal window. Skip it if you need Windows, or if your kernel predates the fdinfo interfaces (5.14 for amdgpu, 5.19 for i915, 6.0 for msm), where process listings will be empty. Before relying on it, verify that CMake finds your vendor libraries at build time and that nvtop actually lists your devices; the README's Troubleshoot section is the place to start when it does not.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Syllo/nvtop on GitHub