Why gpulse

The Problem

"GPU monitoring is stuck in 2015."

Most ML engineers monitor GPUs with nvidia-smi — a text-only tool that hasn't fundamentally changed in a decade. When a 72-hour training run crashes at 3am because of an out-of-memory error, you find out after the fact. There's no prediction, no early warning, and no cross-vendor visibility.

We built gpulse because we were tired of losing training runs.

Why Rust

"Performance is a feature."

gpulse is written entirely in Rust. Not because it's trendy — because GPU monitoring must be invisible. A monitoring tool that consumes CPU cycles or leaks memory defeats its own purpose.

What Rust gives us:

• • Zero-cost abstractions — monitor at 60fps with <1% CPU overhead
• • Memory safety without garbage collection — no GC pauses, no memory leaks in the monitor itself
• • Fearless concurrency — safely collect metrics from multiple GPUs in parallel
• • Single binary deployment — no runtime dependencies, no Python, no Docker
• • 136,000 lines of safe Rust with zero unsafe in user-facing code paths

Why Security Matters

"Your GPU data stays on your machine."

gpulse collects zero telemetry. There are no analytics, no crash reports, no phone-home connections. Every byte of GPU data stays on your local machine.

When we build fleet monitoring (Pro tier), the architecture is outbound-only — your GPU nodes push metrics, nothing listens for inbound connections. The agent runs as an unprivileged user with only GPU access. Binary integrity is verified with Ed25519 signatures.

We don't believe monitoring tools should be attack surfaces.

Engineering Philosophy

"Built like infrastructure."

• • 524 tests covering every view mode, widget, and interaction
• • 4 independent code reviews before every release — security is not an afterthought
• • 30+ GPU metrics per device — VRAM, utilization, temperature, power, clocks, ECC, PCIe, per-process attribution, memory bandwidth, and more
• • 4 GPU vendors — Apple Silicon (Metal/IOKit), NVIDIA (NVML), AMD (ROCm), Intel (Level Zero) from a single binary
• • 3 leak detection algorithms — linear trend analysis, spike detection, and composite scoring running in real-time with OOM countdown
• • 7 view modes — Grid, Detail, List, Predict, Compare, Topology, Fleet — each purpose-built for a different monitoring task

Every commit goes through automated testing. Every release is stripped, signed, and checksummed. We treat a monitoring tool with the same rigor as the infrastructure it watches.

The Vision

"One tool. Every GPU. Zero surprises."

Today, gpulse monitors local GPUs with predictive OOM detection. Tomorrow, it monitors your fleet — from a single Mac Studio to a thousand H100s across AWS, Azure, and GCP.

We're building the tool we wish existed when we started training models.

By the Numbers