VADIS GPU Benchmark Dashboard

Devices

One card per GPU that has uploaded results. Click a card to show/hide it everywhere below — this is the fastest way to isolate or compare specific devices. The device badge is the actual compute backend measured at runtime (torch.cuda/mps/cpu), not just the GPU label, so a run that silently fell back to CPU is flagged here instead of reading as a real GPU result.

Real-time camera capacity

One row per (GPU, workload, stream count) run, grouped by device. "Passes" means the worst-performing stream stayed at or above the real-time bar for that workload.

Stream-count scaling

Per-stream FPS as concurrent camera streams increase, one chart per workload, one line per GPU.

Detection confidence vs. concurrent streams

Model-native detection/classification confidence (a quality proxy, not a formal accuracy benchmark) as concurrent streams increase — shows whether pushing more streams onto one GPU degrades output quality, not just speed.

Resource usage & latency

Single-stream baseline per (GPU, workload): CPU, RAM, disk read throughput, cold-start time, and end-to-end capture-to-result latency.

GPU power & compute engines

Single-stream baseline per (GPU, workload). NVDEC/NVENC panels are NVIDIA-only (video decode/encode engine utilization); ANE/CPU package power panels are Apple-Silicon-only (via powermetrics) — each disappears automatically on hosts that can't report it.

Phase 0a — CLIP inference rate sensitivity

Context AUC vs. simulated CLIP inference rate. Lower isn't just "acceptable" here — running faster than the recommended point measurably hurts accuracy.

Phase 0b — compute vs. bandwidth roofline

CLIP-B/16 throughput vs. batch size, one line per GPU tested. A flat-ish line = compute-bound; a line that keeps climbing with batch size = bandwidth-bound (batching pays off).

Table view (accessibility / raw data)