DocsTrainingSubmit a training job (SDK)
Training

Submit a training job (SDK)

Submit a federated training job from Python with one rt_submit() call — define a model, ship shards, watch it run.

30-second tour

Five lines of Python. Two configs, a model class, and the submit call:

i
Don't have the SDK installed yet? Run through Install the SDK first — it covers pip install, bucket provisioning, and a sanity check.

Define your model

A standard nn.Module with a num_classes kwarg in __init__ and a forward(B, 3, H, W) -> logits. The SDK extracts the class source verbatim and ships it as model_def.py.

model.py
!
Keep all import statements in the same cell / file as the class. Source extraction grabs the surrounding scope; imports outside that cell don't travel with the class.

For overrides (custom executor, persistor, dataloader), see Custom training classes.

Describe training + federation

Anything the typed fields don't cover (mixup, weight decay, custom schedulers, …) goes into TrainingConfig.extra. See the training config reference for the full field surface.

Submit

rt_submit() blocks while it uploads your shards (multipart for ≥10 MB files, 5 concurrent parts); for a 30-shard dataset of ~200 MB each, expect a minute or two. Returns a thin Job handle with .id, .dashboard_url, and lifecycle helpers.

Track progress

The SDK hands off to the dashboard once submission completes — open job.dashboard_url to watch the FL round counter, browse the workspace, and download the final model.

Prefer Python? sdk.jobs.get(job.id) polls state; sdk.storage.list("jobs/<name>/") walks the bucket; sdk.storage.presign_get(key) gets a download URL for any artifact. See Track jobs & download results for the patterns and the Job lifecycle deep-dive for the state transitions.

How it works — what rt_submit() does

The call is "thin" by design — every action it takes you could do yourself with boto3 + an HTTP POST. The SDK just standardizes the layout.

  • Renders the three FL configs + model_def.py, custom_client_executor.py, custom_persistor.py from source extraction.
  • Writes them to s3://<your-bucket>/jobs/<slug>/ alongside requirements.txt.
  • Streams each shard zip directly (multipart for files ≥ 10 MB, 5 concurrent parts).
  • Calls POST /api/tasks with the five S3 paths; the platform reads them, fans out workers, kicks off Round 0.
  • Returns a Job handle with the dashboard URL for tracking.

What's next