Everyone looking at siltide already has something. This says where each of them is the better choice, and what siltide adds, with no benchmark numbers because no benchmark has been run.
The driver's own tool
Choose nvidia-smi when: It is on every NVIDIA host already, needs nothing installed, and is the authority on what the driver thinks.
siltide adds: It reports one vendor, one host, and one moment. siltide reads fifteen vendors, correlates processes to pods and Slurm jobs, keeps a rewindable history, and serves the same data as JSON and Prometheus metrics.
Use nvidia-smi when you want the driver's own words about one machine. siltide does not replace it and reads from the same library it does.
A terminal graph for GPUs
Choose nvtop when: A live graph per device, multi-vendor, and comfortable to leave open.
siltide adds: siltide adds where the work came from: the pod, the namespace, the workload, the Slurm job, and a history you can scrub back through after the fact rather than only watching forward.
If you want a live chart and nothing else, nvtop is smaller and does exactly that.
A one-line summary
Choose gpustat when: Short, scriptable, and unmistakable at a glance.
siltide adds: siltide --status prints one line too, and --once --json prints the whole snapshot for a script. What it adds is everything behind that line when the line looks wrong.
For a prompt or a cron line, either works; gpustat is a smaller dependency.
An interactive NVIDIA monitor
Choose nvitop when: Rich per-process detail on NVIDIA, with actions such as killing a process.
siltide adds: siltide is read-only by design and covers fifteen vendors rather than one, with an API, metrics and an agent interface on the same data.
If you want to act on processes from the monitor, nvitop does that and siltide deliberately does not.
GPU metrics for Prometheus
Choose DCGM exporter when: The reference way to get NVIDIA metrics into Prometheus at scale, maintained by the vendor.
siltide adds: siltide exports Prometheus metrics too, across every vendor it supports, and is a terminal interface first: the same binary is what you open during an incident.
In a cluster already standardised on DCGM, keep it. siltide can read the devices beside it without conflicting.
Nothing here is a claim about speed or memory against another tool. Comparing those properly means the same fleet, the same window and the same definition of started, and that has not been done.