Dashboard (UI)

gpu-train ships a local, Research Commons-branded dashboard: a single view over your infra, jobs, providers, and cost. It reads the same registry and SQLite state as the Python API, so anything you launch from code shows up here and vice-versa.

Run it#

pip install "gpu-train[server]"
gpu-train serve            # opens http://127.0.0.1:8780

Flags: --host (default 127.0.0.1), --port (default 8780), --no-browser, --token (bring your own), --no-auth (disable the token). The prebuilt UI is bundled into the wheel, so no Node.js is required to use it.

Logging in (bearer token)#

By default serve prints a token, persists it to ~/.gpu-train/server_token (chmod 600), and opens the browser at /#token=…:

gpu-train dashboard token: 3f2a…c91

The dashboard captures the token from the URL, stores it in localStorage, and sends Authorization: Bearer <token> on every API call (downloads and the log WebSocket use a ?token= query param). If you open the dashboard without the fragment, an Authentication required prompt lets you paste the token; use sign out to clear it. Provide your own token with --token / GPU_TRAIN_SERVER_TOKEN, or run --no-auth for the open, loopback-only mode.

Pages#

Overview#

One unified view of the control plane:

• KPIs — runs and total cost over the last 30 days, instances running now, and W&B status.
• Infrastructure — every provider with a live status dot (ready / needs credential / coming soon).
• Control-plane defaults — runtime, auto-terminate, idle timeout, etc.
• Recent runs and a 30-day cost report.

The header has a + New run button available on every page.

Start a new run#

A dialog to launch from the browser — pick a provider (only connected ones are offered), then a GPU preset card (model + VRAM, narrowed to that provider via /v1/gpus) and a count, an entrypoint, project dir, and runtime. For cloud runs it also exposes min VRAM, disk, and region alongside an optional price cap. It submits to the control plane and opens the live run view. See GPU selection & VRAM.

Runs & Run detail#

The full job list, and a per-run detail view with live streaming logs (over a WebSocket), status, cost, exit code, a kill button, and a deep-link into the run's Weights & Biases page.

It also has a Metrics panel: native SVG charts of everything your script logged with gpu_train.log({...}), polled live while the run is active. Charts are grouped by namespace (train / eval / stability / performance) into collapsible sections, with panel controls for the x-axis (step vs. wall-clock time), EMA smoothing, log-scale, and a hover crosshair. When the run is W&B-tracked, a Load from W&B button pulls the run's history via the W&B Public API and overlays it (dashed) on the local series. See Metrics & monitoring.

Providers & integrations#

Every provider with status badges and an inline Connect form. Enter API keys (RunPod/Vast.ai), a GCP service-account JSON + project/zone, or a Colab tunnel endpoint — right in the UI. Keys are saved to the local credential store (chmod 600), shown back masked, and can be disconnected. Providers configured via environment variables are shown read-only. There's also a Weights & Biases card, a Hugging Face card, Amazon S3 / Google Cloud Storage cards (credentials for checkpoint/log sinks), and a Colab bootstrap cell viewer.

Cost#

Spend broken down per day and per provider over a configurable window.

HTTP API#

The dashboard is a thin client over a small JSON API (handy for scripting):

All API routes except the static shell, /health, and /api require the bearer token (Authorization: Bearer <token>, or ?token= for downloads/WebSocket) unless started with --no-auth. Credential reads are always masked; environment-sourced credentials cannot be overwritten or deleted via the API. See Credentials & secrets and Security.