Submit via UI wizard · Docs

Before you start

Open Submit job under Training in the sidebar. You need a storage bucket first; without one the page sends you to your profile to create it.

Pick	Use it when	Where it takes you
New workspace → Start wizard	You start a new job	Step 1. The wizard generates the configs and scripts for you
From existing workspace → Browse bucket	The job folder is already in your bucket, from an earlier run or the SDK	Step 6, Validate
Saved drafts → Resume	You left a wizard unfinished in this browser	The step you left

Step	On the page	What you do
1 · Name	Name your training run	Name the job; it becomes the folder jobs/<name>/
2 · Training	Hyperparameters	Set the values every worker receives
3 · Federation	Federation	Rounds and timeouts
4 · Model	Your model	Where your model class and training function live
5 · Advanced	Review the generated files	Optional: edit the configs, then build the workspace
6 · Validate	Check your workspace	Upload model_def.py and your shard zips
7 · Launch	Choose your workers	Pick a GPU type, check the price, launch

Each step ends with a Continue to … button. The header has Back, Drafts and Discard.

Steps 1–4: name, training, federation, model

1. Name

Type a name such as food101-finetune. The wizard lowercases it, turns spaces into dashes and keeps only letters, digits, - and _. It shows the result and the workspace folder, jobs/<name>/. A name needs at least one letter or digit.

2. Training

Name and value pairs sent to every worker each round; your training function reads them. Add, remove or rename any of them, in the Fields view or as JSON.

Name	Default
local_epochs	2
batch_size	32
learning_rate	0.001

Numbers stay numbers, and a value that starts with [ or { is read as JSON. The platform sets data_root, adapter_module, train_fn, validate_fn and out_dir_name itself, so don’t use those names.

3. Federation

Field	Default	What it does
Rounds	5	How many times the server sends out the model, collects the updates and averages them
Minimum workers per round	1	Set for you at launch from your worker count: every worker for one or two, two thirds rounded up above that. The value here only matters if you run the generated config yourself
Wait for stragglers	10 s	How long the server keeps waiting for the other workers once the minimum has reported
Heartbeat timeout	600 s	How long a worker may stay silent before the server treats it as lost
Training timeout	0 s	The longest a worker may train in one round. 0 means no limit

Revert to defaults puts all five back.

4. Model

Field	Default	What it is
Model class	model_def.FLModelWrapper	Import path of your model class, as module.ClassName
Adapter module	model_def	The file in scripts/ that holds the class and the training function, without .py
Training function	fl_train_model	The function in that file each worker calls every round

If you start from the model_def.py template, keep the defaults. Then either Continue to Advanced to review the generated files, or Skip Advanced to build the workspace with them as they are and go straight to step 6.

Step 5: Advanced (optional)

The three config files open in editors, filled in from steps 2–4. The two Python scripts are shown read-only.

File	What it holds
config_fed_client.json	What every worker runs: the executor and your step 2 hyperparameters
config_fed_server.json	The training loop: rounds, how updates are averaged, how the model is saved
meta.json	The job name and the minimum number of workers

Build workspace and continue writes the workspace to your bucket:

your bucket

jobs/<name>/
├── scripts/
│   ├── custom_client_executor.py
│   ├── custom_persistor.py
│   └── model_def_wrapper_template.py   ← your starting model_def.py
├── configs/
│   ├── config_fed_client.json
│   ├── config_fed_server.json
│   └── meta.json
├── requirements/
│   └── requirements.txt
├── shards/                             ← your zips, in step 6
└── model/                              ← optional checkpoint, in step 6

model_def_wrapper_template.py is a starter model_def.py with your hyperparameters filled in. Save it as model_def.py, add your model and training function, and upload it in step 6. How to write it: Port a centralized recipe to FL.

Step 6: Validate

Five cards, one per folder. Each shows Needs files, a file count or Empty; Upload or Browse opens that folder, where you can add files.

Card	What goes in	Required
Scripts	Your model_def.py, next to the generated executor and persistor	Yes
Configs	The three generated JSON files	Yes, built in step 5
Requirements	requirements.txt: pip packages installed on every worker	Yes, built in step 5
Dataset Shards	One .zip per worker. The number of zips is the number of workers	Yes
Base Model	One .pt checkpoint to start from	No

Continue to Launch unlocks once Scripts, Configs, Requirements and Dataset Shards each hold a file. A few problems show up later, so check them yourself:

A missing model_def.py gets a red warning here but doesn’t block you.
Only .zip files count as shards. The card says how many workers that means.
More than one .pt in Base Model is rejected when you launch.

How to split and zip your data: Dataset format & sharding.

Step 7: Launch

You pick a GPU type, not single machines. The job gets one worker of that type per shard, the cheapest free ones. Prices are per worker per hour.

Search GPUs, Filters, sort by price or by VRAM, and refresh. The list also refreshes itself every 20 seconds.
Available lists GPU types with free workers, All every type. Only my machines keeps the GPUs you own.
Each card shows the price, VRAM × GPUs per worker, vCPU and RAM, and how many are free. It greys out when it falls below your filters or every worker is busy.

Filters

All optional. Nothing is picked for you; a filter only greys out GPU types that fall short.

Filter	What it sets
GPU memory	Free memory on the GPU your job uses, per worker. Other GPUs in the same machine don’t add to it
Disk, RAM	Free disk and system memory per worker
NVLink between GPUs	Only multi-GPU workers whose cards are linked by NVLink
Central server RAM, disk	Minimums for the server that coordinates your workers
Dedicated central server	No other job shares the central server with yours
Size by model memory	Say how much GPU memory your model needs and see priced setups that fit. Use this applies one

While you drag, the modal counts how many idle workers and central servers still match. Active filters show as chips above the grid. What to set for your model: Choosing hardware.

Price and balance

The Summary shows the GPU you picked, its price per worker and the Total per hour, billed while the job runs. Under it, your balance and how many hours it covers at that rate; Top up adds funds. Launch training job unlocks when the GPU type you picked has a free worker for every shard and your balance hasn’t run out.

When nothing fits

Order GPUs asks a provider to reserve GPUs in your name. You launch on them later from My orders.
If no central server meets your minimums, the page says so and offers Order a central server. One reserved for you shows as Reserved for you, and your jobs use it first. See Central servers.

After launch

An overlay follows the launch and ends on Job launched with the job name and id. View live status opens the job page; Submit another job starts a new wizard.

note

The job starts as PENDING while the workers start, turns RUNNING when they have joined, and ends FINISHED or FAILED. Rounds, logs and the trained model: Track jobs & download results.

Drafts

The wizard saves a draft each time you press Continue or Skip Advanced. Drafts live in this browser; another browser or device won’t see them.
A draft keeps the job name and the step you reached. Steps 2–4 return to their defaults when you resume, so check them again; configs you already built load from your bucket.
Resume from Saved drafts on the first page or from Drafts in the wizard header. The trash icon deletes one.
Discard deletes the current draft and returns to the first page. Launching removes the draft too.

PreviousOverview Next Choosing hardware