Skip to main content
The probe and the CLI capture GPU and system telemetry. The SDK adds what only your code knows: where the run is, and what it is training. Without it a stall shows up in the hardware but cannot be lined up against a step.

Before you start

  • Training already reporting — see Setup
  • Python 3.9 or newer

1. Install the SDK

Install it into the same environment as your training script.

2. Add the calls

Call init once after the process group is up, then mark progress as the run proceeds.
train.py
Call warpscale.init() after dist.init_process_group(). The emitter is elected inside init, so calling it earlier leaves every rank a non-emitter and the SDK silently inactive for the whole run.
Passing model= derives param_count from the module. That, with flops_per_token, is what the MFU panels are computed from — leave both out and those panels stay empty.

A complete example

The snippet above is the shape. Below is a script that runs as-is: a small GPT trained with DDP on two GPUs, on synthetic tokens, so there is no dataset to fetch first.
train.py
Launch it the same way as any other run:

3. Verify

The SDK is inert unless it is running under the CLI — it looks for the WS_RUN_ID that warpscale run sets.
Two checks:
  • Run your script without the CLI. The SDK logs WS_RUN_ID not set — not running under 'warpscale run'; warpscale inactive at INFO and does nothing else. That is the expected inactive path.
  • Run it with the CLI. Step and epoch progress appear on the run at https://<your-organization-host>/runs.

Troubleshooting

The SDK is inactive. Confirm the run is launched through warpscale run --, and that warpscale.init() is called after dist.init_process_group().
Progress is emitted by rank 0 only. If rank 0 exits or is restarted mid-run, reporting stops with it.
MFU needs param_count and flops_per_token. Pass model= to derive the first, and flops_per_token= for the second.