Stormlog gives PyTorch and TensorFlow teams real-time GPU memory visibility, leak detection, diagnostics, and exportable timelines across CLI, Python API, and Textual TUI workflows.
Framework coverage
Stormlog stays useful whether you start from a one-off CLI session, instrument a Python training loop, or hand teammates a TUI and exported artifacts for follow-up diagnosis.
Profile live training runs, investigate artifact captures, and iterate without switching between disconnected tools.
Use Stormlog from the command line, inside Python, or through the interactive TUI depending on how your team works.
Ship JSON, CSV, and HTML artifacts into debugging reviews, CI pipelines, or offline analysis without re-running experiments.
Why Stormlog
The goal is not just to collect numbers. Stormlog helps teams see GPU memory as it shifts, isolate signals worth acting on, and move from guesswork to repeatable workflow.
Live visibility
Track allocation, peak usage, and reserved memory in one place instead of stitching together shell commands and printouts.
Follow GPU allocation as it changes mid-epoch, not after the crash report lands.
Apply warning and critical limits so risky runs surface immediately instead of after hours of wasted compute.
Inspect platform info, live tracking, exports, and diagnostics without opening a browser.
Actionable diagnostics
Move from vague symptoms to concrete signals you can act on, including suspicious allocation growth and distributed anomalies.
Identify suspicious growth patterns and isolate where memory starts drifting run over run.
Load exported snapshots and compare them later to trace distributed or intermittent issues with context intact.
Generate timeline plots and HTML artifacts to show how memory behaved across the full workload.
Flexible workflows
Adopt the profiler incrementally, from quick CLI sessions to deeper instrumentation in Python-heavy training code.
Start monitoring or diagnostics sessions from the terminal without reworking your whole training loop.
Use decorators, context managers, and programmatic sessions when you need tighter profiling control.
Prepare and test profiling routines before moving them onto production GPU infrastructure.
Spot issues faster
Stormlog turns raw allocation data into signals your team can review. Load artifacts, compare suspicious runs, filter by anomaly reason, and export proof for later triage.
Investigate distributed runs with rank-aware diagnostics
Review artifacts from prior sessions without reproducing the entire failure
Move from symptoms to concrete next steps with exportable traces
Workflow
The page story stays cinematic, but the workflow is practical: integrate Stormlog, watch a run live, capture useful evidence, and apply fixes before the next training cycle wastes more GPU time.
Step 1
Add Stormlog to the workload you care about, from lightweight decorators to deeper session-based profiling.
from stormlog import profile
@profile(track_tensors=True, detect_leaks=True)
def train_epoch(model, dataloader):
for batch in dataloader:
loss = model(batch)
loss.backward()Step 2
Launch the TUI or a CLI session to watch allocation, peak memory, and alerts while the training run is alive.
$ stormlog monitor --pid 12345
┌─ Live GPU Memory ──────────────────────┐
│ Allocated 16.2 / 24.5 GB │
│ Peak 19.8 / 24.5 GB │
│ Alerts None │
└────────────────────────────────────────┘Step 3
Inspect spikes, suspicious growth, and anomaly indicators before the next restart cycle begins.
[WARN] suspicious growth detected
tensor: grad_cache
change: +128MB over 50 iterations
signal: growth beyond thresholdStep 4
Ship artifacts into CI, review threads, or follow-up debugging sessions instead of relying on memory alone.
$ stormlog export --format json --output run.json
$ stormlog export --format html --output run.html
✓ timeline written
✓ diagnostics artifact savedStep 5
Use the evidence to fix leaks, stabilize batch sizes, and avoid repeat OOM failures in future runs.
Before: OOM at batch_size=64
After: stable at batch_size=96
Memory savings: 2.1 GB (-26%)
✓ 50 epochs completed
✓ zero OOM interruptionsTUI showcase
The TUI is where Stormlog’s workflows become tangible: quick start guidance, monitoring controls, visualization exports, diagnostics, and CLI-driven actions in a single interface.
Active frame
Quick start
Orient new users with platform details, keyboard shortcuts, and a fast path into every Stormlog surface.
Proof of value
Stormlog is most useful when a run is already going sideways. Drag the divider to compare guesswork against a workflow with live monitoring, anomaly signals, and exported evidence.
$ stormlog monitor --pid 12345
Allocated 16.2 / 24.5 GiB
Peak 19.8 / 24.5 GiB
✓ live alerts enabled
[WARN] suspicious growth detected
signal: grad_cache +128MB
reason: repeated growth over threshold
✓ export diagnostics artifact
After the fix
batch_size = 96 ✓ stable
memory saved = 2.1 GiB
zero OOM interruptions across 50 epochs
$ python train.py
Epoch 9/50... training
Epoch 10/50... training
RuntimeError: CUDA out of memory while allocating 2.4 GiB
$ nvidia-smi
| 23476 MiB / 24564 MiB |
Which tensor grew? Which step spiked? What changed since the last run?
Fallback strategy
batch_size = 64 → OOM
batch_size = 32 → unstable
batch_size = 16 → slow but survives
Open source proof
This landing page is intentionally not padded with generic testimonials. Stormlog’s proof is the public codebase, the published package, the documentation footprint, and the maintainers who keep the project moving.
Installation, architecture, examples, and TUI guidance are already part of the public workflow.
Stormlog is developed in the open, with code, issue tracking, and contribution paths visible to contributors.
The current published package remains available on PyPI while the rename transition to Stormlog stays explicit.
Ready to debug with context?
Use the docs to get started, inspect the repository, or install the current PyPI package while the Stormlog rename rolls forward.
