nvitop: an interactive NVIDIA GPU process viewer with a Python API
An interactive NVIDIA-GPU process viewer and beyond, the one-stop solution for GPU process management.
At a glance
- What is it?
- nvitop replaces repeated nvidia-smi calls with a curses monitor, a CUDA device selection tool and a Python API for building your own GPU tooling. It installs from PyPI or conda-forge and runs on Linux and Windows.
- Who is it for?
- Adopt nvitop if you run shared NVIDIA GPU hosts and want an interactive view of processes, their parent tree and their environment without parsing nvidia-smi output. Skip it if you need a long-running metrics pipeline, since that is what the separate nvitop-exporter and Grafana dashboard cover, or if you cannot install nvidia-ml-py against a working driver.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem nvitop solves on a shared GPU box
On a machine with several NVIDIA cards and several people using them, the default answer to "who is using GPU 3" is nvidia-smi, run again and again. It prints a snapshot. It does not update, it does not tell you which Python process owns a context, and it does not show the parent process that launched it. nvitop is built for that gap. The README describes it as an interactive NVIDIA device and process monitoring tool with a continuously updating interface, and it names the audience directly: deep learning researchers, developers and system administrators who share GPU hardware. The package is not only a top-like screen. It also ships nvisel, a CUDA device selection tool, and a set of APIs for writing your own monitoring code. That combination is the reason to look at it rather than a shell loop around nvidia-smi.
How nvitop reads GPU state: NVML bindings instead of parsing nvidia-smi
The mechanism matters more than the interface. According to the README, nvitop queries device status through the NVML Python bindings (the nvidia-ml-py package) rather than running nvidia-smi and parsing its text. That removes a subprocess per refresh and removes the parsing layer that breaks when the driver changes its output format. The README also states that nvitop supports sparse queries and caches results with TTLCache from cachetools, so a screen that shows ten fields does not necessarily issue ten NVML calls per tick. Information gathering runs on multiple threads, which is what keeps the interface responsive to keyboard and mouse input while device data is being collected. Rendering uses the curses library rather than print with ANSI escape codes, which is why the layout holds together as a full-screen application. The dependency list in pyproject.toml is short: nvidia-ml-py, psutil, plus colorama and windows-curses on Windows. psutil is what backs the host-level view, and the README notes the Host class is inherited from psutil.
Installing nvitop and running the monitor for the first time
The README lists pip and conda-forge as the two installation routes, and the package requires Python 3.8 or later. Install it into the environment you already use for GPU work so the interpreter can reach the same driver and devices.
pip install --upgrade nvitopAfter that, running nvitop with no arguments opens the monitor mode, a full-screen curses interface that refreshes device and process state continuously. The README shows the same entry point in its Dockerfile, which ends with an ENTRYPOINT that runs the package as a module.
nvitopIf you prefer conda, the README links the conda-forge channel, so the equivalent install is a conda install of the nvitop package. For a one-off look at device and process status without the interactive screen, the README documents a snapshot path under the "More than a Monitor" section, and the examples/take-snapshots directory in the repository shows the API call. The monitor itself supports process sorting, filtering, a tree view of GPU processes and their parents, an environment variable screen and a help screen, all reachable from keybindings documented in the README.
nvisel and the API: nvitop as a library, not just a screen
The most underused part of the package is the one that does not look like a monitor. nvisel is a CUDA visible devices selection tool aimed at deep learning researchers: instead of exporting CUDA_VISIBLE_DEVICES by hand after reading a status table, you pick devices through the tool. The README also points to a set of low-level APIs covering Device, Process and Host, with the Host class inherited from psutil, and to full API references hosted on Read the Docs. The examples directory in the repository is organized around that use: collector-background, collector-csv, collector-tensorboard, ml-framework-callbacks, monitor-colored, monitor-minimal, monitor-web, select-devices-api and take-snapshots. That layout tells you the intended progression. Start with the interactive binary, then move to a collector when you want the same numbers in a file, a TensorBoard run or a web page. The nvitop-exporter subdirectory is a separate component that feeds a Grafana dashboard, which is the path to long-term metrics rather than a terminal session.
Where nvitop is the wrong tool, and how it differs from nvtop
nvitop is a terminal application. If you close the terminal, the view is gone. There is no built-in retention, no alerting and no historical query, and the README does not document rollback or a server mode for the monitor itself. The Grafana path exists, but it runs through nvitop-exporter, a distinct piece of software with its own deployment. If your actual need is a time series you can query next week, nvitop alone will not give it to you. The natural comparison is nvtop, a C application that the README itself uses as a benchmark for the asynchronous, multi-threaded design. The difference in approach is the ecosystem around the tool: nvtop is a standalone binary, while nvitop is a Python package that also exposes Device, Process and Host objects, which is why you can call it from a training script or a callback. The README makes a similar distinction against gpustat and py3nvml on interactivity, against nvidia-htop on the parsing approach, and against gpustat again on sparse queries with cachetools. Those are claims about design, not measured results, and the README does not publish comparison numbers.
Maintenance, licensing and what an upgrade actually costs
The repository is not archived, and the last push was on 2026-07-27. Releases are frequent enough to plan around: v1.7.1 on 2026-07-10, v1.7.0 on 2026-05-16 and v1.6.2 on 2026-01-27. The licence is where teams should read carefully. The README badge and the pyproject.toml license field both point to Apache-2.0, but pyproject.toml states the license as "Apache-2.0 AND GPL-3.0-only", and the classifiers list both the Apache and GPLv3 entries. The repository carries both a LICENSE and a COPYING file, and the README has a copyright notice section. That combination is not a single permissive licence, and the metadata alone does not explain which parts fall under which terms. Treat the dual declaration as something to confirm with whoever handles licensing at your organisation before you redistribute the package or vendor it into a product. Upgrading is otherwise cheap: the runtime dependency set is small and the version pins on nvidia-ml-py are explicit in requirements.txt, so a dependency resolver will tell you quickly whether an upgrade conflicts with the driver bindings you already have.
Docker and remote sessions: practical limits
The repository ships a Dockerfile, and it is instructive about what the project assumes. It builds on ubuntu:latest, fails the build if the base image is not Ubuntu, installs python3-dev, python3-venv and locales, sets LC_ALL to C.UTF-8, creates a virtual environment at /venv, installs nvitop from the copied source tree and sets the entrypoint to /venv/bin/python3 -m nvitop. The locale line is not incidental. nvitop draws box characters and bar charts, and a container without a UTF-8 locale will not render them correctly. The README also has dedicated subsections for Docker users and SSH users, which is a sign that the terminal environment is the usual source of trouble rather than the GPU query path. If you run it over SSH, expect the interface to depend on the terminal emulator and the locale on the remote side, and check the README's SSH section before filing anything as a bug.
Editorial conclusion
Adopt nvitop if you run shared NVIDIA GPU hosts and want an interactive view of processes, their parent tree and their environment without parsing nvidia-smi output. Skip it if you need a long-running metrics pipeline, since that is what the separate nvitop-exporter and Grafana dashboard cover, or if you cannot install nvidia-ml-py against a working driver. Before rolling it out, verify that pip install nvitop resolves nvidia-ml-py within the pinned range and that the monitor renders correctly in whatever terminal your users actually connect with; the README documents Linux and Windows support but not every terminal and locale combination.
Frequently asked questions
What is the nvitop command?
Running nvitop with no arguments starts monitor mode, the interactive curses interface that continuously updates NVIDIA device and process status. The same package also provides the nvisel device selection tool and a Python API.
What are the differences between nvitop and nvtop?
Both are interactive GPU monitors, but nvitop is a Python package that queries device status through the NVML Python bindings and exposes Device, Process and Host APIs, while nvtop is a standalone C application. The README cites nvtop when describing nvitop's multi-threaded, asynchronous information gathering.
How do I install nvitop?
The README lists pip and conda-forge. With pip, install the nvitop package into the environment you use for GPU work; it requires Python 3.8 or later and pulls in nvidia-ml-py and psutil.
How do I use nvitop?
Start with the nvitop command for the interactive monitor, which supports sorting, filtering, a process tree view and an environment variable screen through documented keybindings. For programmatic use, the README points to the API references and the examples directory, including the take-snapshots and collector examples.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/xuehaipan-nvitop)