# JupyterLab NVdashboard puts GPU counters inside the notebook

> NVDashboard is a JupyterLab extension that charts GPU utilization, memory, PCIe and NVLink throughput next to your notebook, and adds a GPU Accel menu that switches pandas and scikit-learn work onto the GPU. It is useful when you are already inside JupyterLab, and it says little about anything outside it.

**rapidsai/jupyterlab-nvdashboard** — A JupyterLab extension for displaying dashboards of GPU usage.

- Repository: https://github.com/rapidsai/jupyterlab-nvdashboard
- Stars: 680 · Forks: 89
- Language: TypeScript
- License: BSD-3-Clause
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/rapidsai-jupyterlab-nvdashboard

## A telemetry panel for the notebook you are already in

NVDashboard is a JupyterLab extension whose job is to show what the GPU is doing while you work. The supported metrics are listed plainly: GPU-compute utilization, GPU-memory consumption, PCIe throughput and NVLink throughput. That last pair matters on multi-GPU boxes, since NVLink traffic is the only signal in this list that distinguishes a fast interconnect from a slow one.

The interesting decision is placement. Rather than sending counters to a separate monitoring agent and opening a different browser tab, the extension runs as a JupyterLab extension and renders its charts inside the lab interface, in the same window as the notebook that produced the workload. The README frames the goal as visualizing system hardware metrics within the same interactive environment used for development, which is also the clearest statement of the audience: individual engineers debugging or profiling a GPU workload, not a platform team watching a cluster.

The project is published by rapidsai, the NVIDIA organization behind RAPIDS, and the Python package metadata carries an NVIDIA copyright line with a BSD-3-Clause identifier. The package is published under the name jupyterlab_nvdashboard, and the TypeScript sources live in src with the Python side in the jupyterlab_nvdashboard directory.

## The Python side polls NVIDIA counters with nvidia-ml-py

The dependency list in pyproject.toml shows how the numbers reach the browser. The runtime requirements are jupyterlab>=4.0.0, nvidia-ml-py>=12, psutil and tornado. nvidia-ml-py is the NVML binding, so the extension reads GPU state through the NVIDIA Management Library rather than by parsing nvidia-smi output. psutil covers the general system side, and tornado is the web stack JupyterLab itself is built on, which is what lets the server extension push data to the browser.

The build system is equally informative. The pyproject.toml requires hatchling together with jupyter-builder, hatch-jupyter-builder and hatch-nodejs-version, so the Python wheel is built around the same frontend that jupyter-builder packages into the lab extension. The repository layout matches: package.json holds the TypeScript build scripts and the file list that ships style and schema assets, while schema/ holds JSON schemas used to configure the extension from the JupyterLab settings editor.

The result is a two-sided extension. A Python server component reads the counters and serves them, and a TypeScript client renders the charts and hosts the toolbar controls. That split explains the troubleshooting advice later in this article: the two halves can be installed separately and can fail separately.

## Installing with conda or pip, and picking the right channel

Two installation paths are documented. Conda releases are published first to the rapidsai channel and land on conda-forge shortly after, and the project also publishes a nightly channel. The conda commands are:

```bash
# nightly version
conda install -c rapidsai-nightly -c conda-forge jupyterlab-nvdashboard

# stable version
conda install -c rapidsai -c conda-forge jupyterlab-nvdashboard
```

The PyPI path is shorter, and the nightly variant pulls from the rapidsai-wheels-nightly index:

```bash
# nightly version
pip install --extra-index-url https://pypi.anaconda.org/rapidsai-wheels-nightly/simple 'jupyterlab-nvdashboard>=0.14.0a0'

# stable version
pip install jupyterlab-nvdashboard
```

Two details deserve attention. The nightly pin uses a prerelease floor of 0.14.0a0, which is what lets pip pick up prerelease builds of a package whose latest stable line is lower. And the conda-forge-only variant exists as a separate documented command, which matters for environments where the rapidsai channel is not reachable.

Python support is not open ended. The metadata requires Python 3.12 or newer and lists classifiers for 3.12, 3.13 and 3.14, so an environment still on 3.10 or 3.11 is out of scope for the current line.

## The GPU Accel menu swaps CPU pandas for cuDF pandas

The feature that goes beyond telemetry is the GPU accelerator activator. A button in the notebook toolbar opens a GPU Accel menu listing the available accelerators, and selecting one switches execution to the GPU without changing any code. For pandas workloads the acceleration comes from cuDF pandas, and for scikit-learn, UMAP or HDBSCAN it comes from cuML accel.

The mechanism is a toggle rather than a configuration file. A check mark marks the active accelerator, and the number beside GPU Accel shows how many are selected. Selecting a checked entry turns it off, and Clear All disables everything. The menu also offers Select All to enable every accelerator that is available.

Availability is conditional. Accelerators appear only when the corresponding dependency is installed in the notebook's environment: cuDF for pandas acceleration and cuML for scikit-learn acceleration. That is the honest limit of the feature. On a machine without cuDF installed, the menu has nothing to offer, and the documentation is explicit that the accelerator list is derived from what is present in the environment rather than from what the hardware could support.

The activation also has a cost. The instructions tell you to restart the kernel when prompted so the change takes effect, which means the switch is not live for a running cell and that in-progress state is lost at the moment of the toggle.

## Brushing and synced tooltips turn four counters into a comparison

Two chart interactions are documented, and they are what separate this from a pair of static readouts. The first is brushing: clicking and dragging selects a time range on a time series chart so you can inspect past activity in detail rather than only the current window. On a chart covering a long training run, that turns a summary line into a zoomable record of when utilization dropped.

The second is synced tooltips. On pages with several charts, the tooltips align at the same timestamp so that metrics can be compared at one moment rather than at whatever moment each chart happened to be hovered. That pairing is well matched to the metric set, because the interesting questions are cross-metric ones: was the memory spike accompanied by a drop in compute utilization, and did PCIe traffic fall while NVLink traffic rose, which would suggest a workload moved between devices.

The presentation follows JupyterLab's light and dark themes, so the charts stay readable in either. That is a small detail in isolation, but it matters for a panel that sits permanently in the workspace next to a notebook, where a mismatched background is the kind of thing people end up ignoring.

## Version 4 of the extension means JupyterLab 4 and nothing older

The compatibility statement is short and strict: JupyterLab-nvdashboard v4 is designed exclusively for JupyterLab v4 and later versions. The package metadata agrees, requiring jupyterlab>=4.0.0 and classifying the project under JupyterLab :: Extensions :: Prebuilt. There is no compatibility layer for JupyterLab 3 in this line, so an environment that cannot move to JupyterLab 4 has no supported path here.

The release history shows how quickly this moves. v0.13.0 landed on 2025-03-03, v0.14.0 on 2026-06-11 and v0.15.0 on 2026-06-25, and the source tree is already at version 0.16.0 in package.json. The last push was on 2026-10-15, so the repository is being worked on. The gap between the newest tagged release and the current source version is the practical detail for a platform team: the version in the tree is ahead of the version you can install.

Licensing is BSD-3-Clause, the same identifier carried in the SPDX header of pyproject.toml, with the LICENSE file listed among the package data. That is a permissive license with no runtime fee and no per-user obligation, though it does carry the usual attribution and warranty clauses.

## A missing dashboard usually means one half of the extension failed

The troubleshooting section exists because the extension has two halves, and the symptom tells you which one broke. If the frontend appears but does nothing, the server extension is the suspect, and you list server extensions with:

```bash
jupyter server extension list
```

If the server extension is installed and enabled but the frontend still does not show up, check the frontend side instead:

```bash
jupyter labextension list
```

The logic is worth remembering because it saves reinstalling. A server extension that is present but disabled will leave you with a visible panel and no data, while a missing frontend means there is nothing to look at in the first place.

A related failure mode comes from the accelerator side rather than the dashboard. If cuDF or cuML is not installed in the environment that JupyterLab is serving, the GPU Accel menu stays sparse or empty, and no amount of reinstalling the extension changes that. The dependency has to exist in the kernel's environment.

For contributors, the README points at a CONTRIBUTING.md file, and the repository ships the usual machinery for a JupyterLab extension: a pre-commit configuration, eslint and prettier configs, a jest config, a conda recipe directory and a dependencies.yaml file that generates the dependency lists in pyproject.toml.

## Where this stops and external GPU monitoring starts

The alternative to NVDashboard is not another Jupyter extension but a different shape of tool: a monitoring process that runs alongside the notebook server and watches the same NVIDIA counters from outside JupyterLab, reporting to a time series store or a dashboard you open separately.

The difference in approach is mostly about reach and persistence. NVDashboard reads the counters inside the notebook server process, on the machine that is running the notebooks, so its telemetry is inherently scoped to that host and that session. Nothing in the documentation describes exporting the collected history, storing it beyond the browser session, or querying it later. The charts are for looking at now, and for brushing back through what happened while you watched. An external monitor can keep a machine's history over days and can watch a host you are not logged into.

In the other direction, the external approach cannot give you the GPU Accel toggle, and it cannot put a chart next to the cell that caused the spike. For a single developer on a GPU workstation, that immediacy is the reason to install this. For a team running many machines, it is not a replacement.

One more boundary is worth stating plainly: the metric list is compute utilization, memory consumption, PCIe throughput and NVLink throughput. There is no temperature, no power, no clock and no per-process attribution in the documented set, so a dashboard built on this extension will not answer questions about thermal throttling or which of your processes took the memory.

## Conclusion

Adopt NVDashboard if your work already happens in a JupyterLab 4 environment on an NVIDIA machine and you want GPU telemetry beside the code that caused it, plus a quick way to move pandas and scikit-learn onto the GPU without editing a single line. Do not adopt it as a fleet monitoring system, since the project covers a single notebook server and documents no export, no historical storage and no server metrics. Before installing, verify that your environment satisfies the Python 3.12 floor and jupyterlab>=4.0.0, check that nvidia-ml-py can read the counters of your GPU on that host, and confirm that the kernel restart the GPU Accel toggle asks for will not discard running cell state.

## FAQ

### How do I install jupyterlab-nvdashboard?

The project documents both conda and pip installs. For conda use `conda install -c rapidsai -c conda-forge jupyterlab-nvdashboard`, and for pip use `pip install jupyterlab-nvdashboard`. A nightly conda channel and a nightly pip index are also documented.

### Which JupyterLab versions does jupyterlab-nvdashboard support?

Version 4 of the extension is designed exclusively for JupyterLab v4 and later, and the package metadata requires jupyterlab>=4.0.0 with Python 3.12 or newer. There is no documented support for JupyterLab 3.

### Why does the GPU Accel menu not list cuDF pandas?

Accelerators are listed only when the matching dependency is installed in the notebook environment, with cuDF needed for pandas acceleration and cuML for scikit-learn acceleration. Install the library in the environment the kernel runs in and restart the kernel when the extension prompts you.

### The dashboard shows but no charts appear, what should I check?

The troubleshooting notes say to check that the server extension is enabled using `jupyter server extension list`. If the server extension is fine but the frontend is missing, list labextensions with `jupyter labextension list`.

## Sources

- [Issues](https://github.com/rapidsai/jupyterlab-nvdashboard/issues)
- [License: BSD-3-Clause](https://github.com/rapidsai/jupyterlab-nvdashboard/blob/main/LICENSE)
- [rapidsai/jupyterlab-nvdashboard on GitHub](https://github.com/rapidsai/jupyterlab-nvdashboard)
- [README](https://github.com/rapidsai/jupyterlab-nvdashboard/blob/main/README.md)
- [Releases](https://github.com/rapidsai/jupyterlab-nvdashboard/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rapidsai-jupyterlab-nvdashboard