Skip to main content
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):
Set your choice at the top of the config:
model_revision pins the base model to one Hugging Face revision. Empty or omitted uses the default, and a run that sets it cannot be deployed. seed controls deterministic training order and defaults to 42.

​
Choose a training algorithm

  • 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. OPD supports single- and multi-turn environments, but not tool-calling ones. 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.
  1. Keep a held-out split outside training, then run both the selected teacher and your current model on it.
  2. 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.
  3. Confirm that the teacher clearly wins and that your environment rewards the behavior you want to transfer.
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:
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

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:
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 GRPO or OPD run. The source can be a finished SFT run or a saved checkpoint. Its LoRA rank and alpha are authoritative, so omit both lora_rank and lora_alpha - setting either alongside init_from_adapter is rejected. --dry-run and a real submit both resolve the source rank for you; local --cost may warn and estimate with defaults instead. If you set model_revision, the source and target revisions must match exactly. Use --dry-run to resolve and validate the source.

​
Infrastructure is managed

You choose the model, algorithm, environment, and training settings. Flash selects suitable infrastructure by default. For controlled runs, [gpu] can pin an active validated GPU class from flash gpus, and that pin also applies to retries and cost estimates. Storage remains managed. A run can occupy more than one card. Omit both [gpu] type and [gpu] count and Flash auto-sizes onto the smallest shape it fits on. [gpu] count (or --gpus N) caps the card count at N, a ceiling that never escalates, while [gpu] type alone pins one card of that exact class. Either way an oversized run is rejected at preflight rather than spread across more cards. See Multi-GPU runs.

​
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 allocates no training GPU. On GRPO, OPD, and an already-profiled SFT config it charges nothing; an uncached SFT config starts a separately billed profile run:
Use --cost separately for the pre-flight estimate.

​
Submit the run

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.

​
Cost and billing

Before submitting, Flash checks your org’s prepaid balance against the pre-flight estimate. A successful run bills at the quoted Flash cost. A run cancelled after training starts is prorated from that quote by the share of the work it completed, and never exceeds it. Setup time is reported but not billed. Preview the estimate before you submit:
GRPO and OPD quote locally from the catalog. SFT is priced from a measured workload profile: the first --cost, --dry-run, or train for a config starts a short, separately billed profile run that tokenizes the exact dataset, and the exact quote is available once it reports done. See Cost and billing for what affects cost, how to read the preview output, and how cancellations are repriced.

​
Monitor a run

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

​
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.

​
Next steps

Deploy & chat

Serve a finished run and talk to it.

Configuration reference

Every field you can set in a training config.