Training

A training run is one TOML config, submitted with flash train. Flash runs the job on managed infrastructure, supervises it, and streams checkpoints and logs back to you. The config and run lifecycle follow; the configuration reference lists every field.

Pick a base model

Flash trains a LoRA adapter on top of a supported base model. List base model ids and their parameter sizes (Supported models covers algorithms, reasoning, and pricing):

flash models list

Set your choice at the top of the config:

model = "Qwen/Qwen3.5-4B"
seed = 42

Flash resolves the supported base-model revision internally so trained adapters remain compatible with managed serving. seed controls deterministic training order and defaults to 42.

Choose a training algorithm

algorithm = "sft"

algorithm = "grpo"

algorithm = "opd"

sft: supervised fine-tuning, when you already have the answers. The model imitates the prompt/answer pairs in your environment’s dataset.
grpo: reinforcement learning, when there’s no fixed answer to copy. Your environment’s reward scores each completion.
opd: on-policy distillation, when a stronger model already does the task. A managed teacher, GLM 5.2 by default or another selected with teacher_model, grades your model’s own completions token by token. Training pulls your model toward that teacher without using answers or a reward as the training signal. Warm-start from an SFT adapter (init_from_adapter) for best results; a cold OPD run tends to underperform SFT. Text-only OPD supports single- and multi-turn environments, but not tool-calling ones. Image-bearing OPD is single-turn only and needs a vision-capable teacher. Teacher access is managed and teacher tokens are not billed to you.

All three are driven by the same environment, and algorithm defaults to sft when omitted. See how Flash works for the difference, or Examples for worked configs and results on real tasks.

Check the teacher before OPD

OPD pulls your model toward the teacher, so the teacher’s competence on your task roughly sets the ceiling. Evaluate the teacher before the run; Flash does not automate this comparison. The managed aliases are training-only: Flash resolves teacher_model inside the run and exposes no endpoint you can call yourself. Evaluate the same public model through its own provider or your evaluation harness, then use the matching alias in your config. The coding agent following the scaffolded TRAINING.md can do this for you.

Keep a held-out split outside training, then run both the selected teacher and your current model on it.
Compare their scores, then read several trajectories from both. A score alone can hide a teacher that reaches the right answer for the wrong reason.
Confirm that the teacher clearly wins and that your environment rewards the behavior you want to transfer.

What you find	Next step
The teacher clearly outperforms your model, and the scores match what you see	Use OPD
The teacher is no better than your model	Use GRPO or train on curated answers with SFT
The teacher looks better, but the environment does not reward the improvement	Fix the environment, then repeat the held-out evaluation

The environment score does not drive OPD’s token-level updates. It tells you whether the behavior you care about improved, so a broken evaluation leaves you unable to judge the run.

Bound reasoning before long rollouts

If the teacher over-reasons in the held-out evaluation or OPD rollouts hit the length limit, put a hard, specific budget in the environment’s system prompt:

Reason in at most two or three sentences, then act.
Once you have started, do not reconsider.

Avoid a vague instruction such as “be brief.” It can shorten the typical response while making the longest responses even longer. Re-run the held-out evaluation after changing the prompt. See Troubleshooting if rollouts still fail to terminate.

Anatomy of a config

project = "<project-uuid>"           # required, from `flash projects list`
model = "Qwen/Qwen3.5-4B"
algorithm = "sft"
seed = 42
# thinking = true                     # opt into reasoning mode

[environment]
id = "your-org/your-project/your-env"

[train]
epochs = 3                            # passes over retained rows; ignored below, max_steps wins
max_examples = 1000                   # sft keeps the first n rows before seeded shuffle
max_steps = 100                       # exact update horizon; drop it to derive from epochs
save_at_steps = [25, 50, 100]         # mandatory saves; requires positive max_steps
lora_rank = 32
# learning_rate = 1e-4
# batch_size = 8                      # sft only; grpo/opd reject it
# prompts_per_step = 64               # grpo/opd only: prompts per optimizer update
# group_size = 8                      # grpo: completions per prompt (2, 4, or 8)
# max_completion_tokens = 512         # grpo/opd: generated tokens per rollout turn
# max_context_tokens = 4096           # total context cap, including sft
# lora_alpha = 64                     # defaults to 2 x lora_rank; set to depart from that
# init_from_adapter = "<source-run-id>" # any algorithm; omit lora_rank/lora_alpha (inherited)
# teacher_model = "glm-5.2"           # opd: managed teacher
# structured_outputs = '{"type":"object","properties":{"answer":{"type":"string"}},"required":["answer"]}'

[gpu]
# count = 4                           # omit to auto-size; set it to cap the cards

[wandb]
# project = "my-project"              # optional weights & biases logging

There are no [sft], [grpo], or [opd] tables. Every knob lives under [train], and one the run’s algorithm cannot consume - group_size on SFT, teacher_model on GRPO - is rejected at submit rather than silently ignored. See knobs are scoped by algorithm.

To force every GRPO or OPD rollout into valid JSON, a regex, or a fixed choice set, so your reward scores content instead of formatting, set structured_outputs. See the Structured outputs guide.

Control the update horizon and checkpoints

For SFT, GRPO, and OPD, a positive train.max_steps is the exact number of optimizer updates, and epochs no longer affects the horizon. If max_steps is absent or non-positive, Flash derives the update count from epochs, retained examples, the optimizer batch (batch_size for SFT, prompts_per_step for GRPO and OPD), and the recipe. A GRPO or OPD config that sets neither is refused rather than derived, since nothing measures the prompt pool - see GRPO and OPD need a stated horizon. Use train.save_at_steps when specific checkpoint boundaries matter:

[train]
max_steps = 100
save_at_steps = [25, 50, 100]

The list must be strictly increasing and positive, requires positive max_steps, and cannot contain a step beyond it. It suppresses save_every, and every requested save is mandatory. Without save_at_steps, periodic save_every uploads block training while attempted but remain best-effort after bounded retries. For SFT, max_examples = N retains the first N rows in file order before the seeded shuffle. SFT also honors max_context_tokens for the rendered sequence.

Warm-start safely

init_from_adapter continues a source adapter in a new run, and it works between every pair of algorithms. SFT, GRPO, and OPD each read a source adapter produced by any of the three, including same-algorithm continuation:

algorithm = "grpo"   # or "sft", or "opd"

[train]
init_from_adapter = "<source-run-id>"   # from an sft, grpo, or opd run

The source can be a finished run or a saved RUN_ID/step-N checkpoint from flash runs checkpoint. Common shapes:

Warm start	Why
`sft` → `grpo`	Teach the format first, then optimize past it with reward
`sft` → `opd`	Recommended: a cold OPD run tends to underperform SFT
`sft` → `sft`	Keep training the same adapter on more data
`grpo` → `grpo`	Extend a reinforcement-learning run

Keep the same base model across the lineage. The source adapter’s LoRA rank and alpha are authoritative, so omit both lora_rank and lora_alpha - setting either alongside init_from_adapter is rejected, as is a source rank above the model’s serving cap. --dry-run and a real submit both resolve the source rank for you; local --cost may warn and estimate with defaults instead. A warm-started SFT run inherits its source’s base-model pin instead of resolving its own, so the continued adapter stays deployable when the base model’s upstream tip moves. Use --dry-run to resolve and validate the source adapter before submission.

Infrastructure is managed

You choose the model, algorithm, environment, and training settings. Flash picks the cheapest validated GPU shape that fits by default, while [gpu] can constrain class, provider, and card count. Run flash gpus for active class names, VRAM, and estimated hourly rates. See GPU configuration and Multi-GPU runs for the exact pinning, preference, fallback, and auto-sizing rules. Storage remains managed.

flash train config.toml --gpus 4

Validate before you submit

--dry-run runs the same submit-time checks as a real run, including warm-start resolution, and flags any [train] keys your CLI version does not recognize. It does not start paid training or allocate a training GPU:

flash train config.toml --dry-run

For SFT, dry-run obtains the same static estimate used by --cost, without starting paid training or allocating a training GPU. Use --cost separately for the pre-flight estimate; see Cost and billing.

Submit the run

flash train config.toml

By default flash train follows the logs until the run finishes; --background submits and returns immediately. --set overrides a config value and --config deep-merges another TOML file, both repeatable. See Training for every flag.

# override values at submit time
flash train config.toml --set train.epochs=3 --set train.lora_rank=16

Cost and billing

Review the estimate before submitting:

flash train config.toml --cost

GRPO and OPD estimate locally. SFT returns a static packaged-dataset estimate synchronously through the control plane. Successful runs bill at the accepted quote; cancellations are prorated and capped at that quote. See Cost and billing.

Monitor a run

Ctrl-C during flash train detaches you. The run keeps going on Freesolo.

flash runs list                # all your runs: state, cost, model
flash runs status <run-id> --json  # one status and cost JSON object
flash runs status <run-id> --follow --json  # changed statuses as JSON Lines
flash runs log <run-id>              # print the full log snapshot
flash runs log <run-id> --follow     # stream logs until completion
flash runs cancel <run-id>     # cancel a run

Reading logs from a retried run

A run that was retried has more than one worker attempt, and their logs are different runs of your job. flash runs log names the attempt each section came from, and marks heartbeats from a worker that has been superseded or torn down:

[superseded attempt=0; worker torn down]

Untagged heartbeats are the live attempt. This matters when you skim to the last heartbeat to check progress - without the tag, a dead worker’s final lines look like current progress. Log artifacts are kept even when the attempt they belong to cannot be identified, so a lookup failure never costs you the output.

After training

When a run reaches done, serve it with flash models deploy and talk to it with flash models chat.

Deploy or export a run you want to keep. Freesolo’s managed storage garbage-collects a run’s checkpoints and final adapter about 7 days after its last activity when the run was never deployed. A deployed run, or one that another run warm-started from, is kept. Exporting copies the adapter into a HuggingFace repo you own.

Get started

Flash

Reference

Pick a base model

Choose a training algorithm

Check the teacher before OPD

Bound reasoning before long rollouts

Anatomy of a config

Control the update horizon and checkpoints

Warm-start safely

Infrastructure is managed

Validate before you submit

Submit the run

Cost and billing

Monitor a run

Reading logs from a retried run

After training

Next steps

Deploy & chat

Configuration reference

​Pick a base model

​Choose a training algorithm

​Check the teacher before OPD

​Bound reasoning before long rollouts

​Anatomy of a config

​Control the update horizon and checkpoints

​Warm-start safely

​Infrastructure is managed

​Validate before you submit

​Submit the run

​Cost and billing

​Monitor a run

​Reading logs from a retried run

​After training

​Next steps

Deploy & chat

Configuration reference

Pick a base model

Choose a training algorithm

Check the teacher before OPD

Bound reasoning before long rollouts

Anatomy of a config

Control the update horizon and checkpoints

Warm-start safely

Infrastructure is managed

Validate before you submit

Submit the run

Cost and billing

Monitor a run

Reading logs from a retried run

After training

Next steps