sparkDash: a multi-unit monitoring dashboard for NVIDIA DGX Spark

What sparkDash solves, and for whom

A DGX Spark is a single desk-side box with a GB10 chip, a 128 GB LPDDR5X unified memory pool and roughly 273 GB/s of bandwidth, according to the README. Once you own more than one, the usual workflow breaks: you SSH into each machine, run nvidia-smi, tail a server log, and try to remember which unit is running which model. sparkDash puts those readings into one page and keeps a shared Overview alongside a tabbed detail page per unit.

The audience is narrow on purpose. This is a tool for the person who owns the hardware. The README describes adding, editing, reordering and removing units from the UI with no process restart, which is the behaviour you want when you are physically near the machines and experimenting. It is not a fleet platform. There is no mention of users, roles, alerting or long-term storage, and the frontend history retention is a build-time constant (VITE_HISTORY_HOURS, default 8).

The non-Spark support widens the audience slightly. Any Linux machine with a dedicated NVIDIA GPU can be added as a dedicated GPU host and polled over SSH with nvidia-smi. For those units the dashboard separates RAM from VRAM, which a Spark does not need because its memory is unified. That distinction is the clearest signal of who the project is written for: people who mix one or more Sparks with ordinary GPU workstations.

How the collector, WebSocket and history store fit together

The architecture is a Node process plus a Vite-built frontend. The server owns collectors for GPU, CPU, network, storage, LLM and bandwidth, each with its own poll interval in .env.example (POLL_INTERVAL_GPU=2000, POLL_INTERVAL_CPU=2000, POLL_INTERVAL_NETWORK=2000, POLL_INTERVAL_STORAGE=5000, POLL_INTERVAL_LLM=2000, POLL_INTERVAL_BANDWIDTH=1000). Metrics reach the browser over WebSocket, and the frontend keeps a central history store so sparklines survive tab switches.

Local readings come from sysfs, proc and nvidia-smi. Remote units are polled over SSH, with either key or password authentication, and SSH_CONTROL_PERSIST_SECONDS=60 lets the server reuse an authenticated transport instead of reconnecting for every poll. That is a sensible default for a dashboard that polls every two seconds, though it also means a stale multiplexed connection can outlive a network change until the control persist window expires.

The Docker layout explains why the container is privileged. docker-compose.yml mounts /proc, /sys and / as read-only host paths, sets pid: host so nvidia-smi compute-apps can see GPU processes, and uses network_mode: host so local LLM probes can reach servers bound to 127.0.0.1, such as ds4-server started with the default --host 127.0.0.1. Without host networking, bridge NAT cannot reach the host loopback. That combination is coherent, but it is also why the security posture matters more here than in a typical web app.

Installing sparkDash and adding your first unit

The README presents Docker as the primary path: a single privileged container for host metrics, with prod and dev Compose files. package.json exposes docker:up, docker:dev, docker:prod and docker:rebuild scripts. The compose file builds for linux/arm64, which matches the GB10 platform. The Dockerfile uses public.ecr.aws/docker/library/node:22-bookworm-slim rather than Docker Hub, and the comment explains why: docker.io often resolves to IPv6, and Sparks with no IPv6 route fail against auth.docker.io.

Start by copying the environment template. PORT defaults to 5555, BIND_HOST defaults to 127.0.0.1, and LLM_PORT defaults to 8888.

cp .env.example .env
docker compose up -d

After the container starts, open http://127.0.0.1:5555 in a browser. You should see the Overview page. The README screenshot shows multiple DGX Spark units with GPU metrics and LLM status on that page.

For development without the production image, the package scripts run the server and the Vite client together. The server uses node --watch, so edits under server/ reload without a rebuild.

npm install
npm run dev

Adding a unit happens in the UI, not in a config file edit. The README states you can add, edit, reorder or remove Sparks from the interface with no process restart. Each unit needs an address and SSH credentials; passwords are encrypted with AES-256-GCM and the README says they never appear in sparks.json or in API responses. For remote units with key authentication, the compose file mounts a private key, and .env.example notes that the mounted key must be mode 600 on the host. If the key is not a default OpenSSH filename, set SSH_IDENTITY_FILE to its path inside the container.

LLM probing, benchmarks and the ComfyUI and Hermes add-ons

The LLM card is where sparkDash goes past generic GPU monitoring. It auto-detects llama.cpp, vLLM, sglang, ds4-server, EXL3 or q27, reports live decode and prefill tokens per second, and distinguishes cached from uncached prefill on ds4, llama.cpp, SGLang and q27. Several LLM servers on different ports can be monitored at once, each with its own panel and independent backend detection.

Two benchmark modes are documented. Decode runs multi-concurrency streaming decode and offers a prompt type picker (Structured, Prose, Code, JSON) with a lab protocol of temperature 0 and thinking off. Prefill sweeps context sizes from 1k to 300k, computes prefill tok/s as prompt_tokens divided by TTFT, and uses a unique prefix per size so prefix caching does not inflate later runs. The release notes for version 1.8.6 state that timeouts scale with size, up to 45 minutes. That is a long-running operation to trigger from a dashboard, and it is worth knowing before you click it on a unit you are also using for inference.

Inference health is read from Prometheus /metrics for vLLM and q27: KV cache percentage, run and wait queue, TTFT, E2E and ITL p95, preemptions, prefix cache and MTP accept. The README notes that q27 FIFO-queues, so its Requests tile reads "N run" without a wait gauge. ComfyUI monitoring is opt-in per unit via comfyMonitoring (default off) and comfyPort (default 8188), and it tracks jobs and queue rather than duplicating GPU bars. Hermes Agent monitoring is also opt-in per unit and runs a background update check every 10 minutes, with one-click or batch hermes update.

Where sparkDash is the wrong tool

The most concrete limitation is stated in .env.example itself. Non-loopback startup fails closed because this release does not authenticate direct LAN clients, and the file tells you to keep BIND_HOST=127.0.0.1 and use docs/REMOTE-ACCESS.md instead. There is a SPARKDASH_ALLOW_OPEN_REMOTE flag whose default is 1, with the comment that setting it to 0 makes the server fail closed without SPARKDASH_TOKEN. Read that as the project telling you the remote path is not yet a normal multi-user deployment.

The container privileges are the second constraint. network_mode: host, privileged: true, pid: host and a read-only mount of / give the dashboard broad visibility into the host. That is what makes the metrics accurate, and it also means the dashboard process should be treated with the same care as root access to the machines it watches. If your security model forbids privileged containers on GPU hosts, sparkDash does not offer a reduced-privilege mode in the configuration files shown.

Retention is the third. The frontend history window is fixed at build time through VITE_HISTORY_HOURS, defaulting to 8, and the Dockerfile comment says to rebuild after changing it. There is no described backend time-series database, so sparkDash is not a substitute for Prometheus plus Grafana if you need months of history or alerting. It reads Prometheus metrics from LLM servers; it does not store them.

How it differs from a general Prometheus and Grafana stack

The honest alternative for someone monitoring GPU hosts is node_exporter plus DCGM exporter scraped by Prometheus and drawn in Grafana. The difference in approach is structural. That stack is pull-based, stores everything in a time-series database, and treats alerting and long retention as first-class. sparkDash is push-based over WebSocket to a browser, keeps history in the frontend, and treats the browser window as the product.

What you get in exchange is LLM awareness that a generic exporter does not have. Detecting llama.cpp, vLLM, sglang, ds4-server, EXL3 or q27, separating cached from uncached prefill, running a context sweep from 1k to 300k with a unique prefix per size, and reading KV cache, preemptions and MTP accept from /metrics are all specific to the inference-server workflow. A Prometheus stack can scrape the same /metrics endpoint, but you would be writing the dashboards and the benchmark harness yourself.

The other difference is unit management. Adding a Spark, reordering tabs, or marking a unit as head, worker or standalone happens in the UI here. In a Prometheus deployment the equivalent is editing scrape configs and reloading. Neither is better in the abstract; they suit different operating styles. If you already run Prometheus for the rest of your infrastructure, sparkDash is an additional surface rather than a replacement, and you should decide whether you want two places to look.

Licence, maintenance and upgrade cost

sparkDash is MIT licensed, and the repository contains a LICENSE file at the top level. MIT is permissive: you can use, modify and redistribute the code, including in commercial settings, provided the copyright notice and permission notice are preserved. That is a statement about the licence text, not legal advice for your situation; if you plan to redistribute a modified version, read the LICENSE file yourself.

The repository is not archived, and the last push was on 2026-09-16, one day before the date used for this assessment, so the codebase is being changed. The version in package.json is 1.8.6, and the README points to CHANGELOG.md for full history. Two merge summaries sit at the repository root, PR-INTEGRATION-SUMMARY-2026-09-06.md and SPARKDASH-REMEDIATION-MERGE-SUMMARY-2026-09-07.md, which suggests active integration and remediation work in early September 2026.

Upgrade cost is mostly a rebuild. The Dockerfile bakes VITE_HISTORY_HOURS into the frontend, so changing the retention window requires docker compose build --build-arg VITE_HISTORY_HOURS=4 or an edit to the compose environment, followed by a rebuild. The compose file mounts ./server into the container and runs node --watch, so server-side edits apply on reload, but frontend changes need npm run build. The Dockerfile also notes npm flakiness inside Docker and wraps npm ci and npm prune in retry fallbacks, so a failed first build is expected behaviour rather than a broken checkout.

Editorial conclusion

sparkDash fits a small lab or a single operator running two to a handful of DGX Spark units who wants one page for GPU, unified memory and LLM throughput, and who accepts that the dashboard is a privileged container with host network access and no built-in authentication. It is the wrong tool if you need a multi-tenant monitoring service, long-term metric retention, or alerting: the README describes no auth layer, no alerting, and a frontend history window measured in hours. Before adopting it, run docker compose up -d, confirm the Overview page lists your units, and check the BIND_HOST and SPARKDASH_ALLOW_OPEN_REMOTE values in your .env against the security section of the README.

Frequently asked questions

Official sources

1. License: MIT
2. MiaAI-Lab/sparkDash on GitHub
3. Project website
4. README
5. Releases