Skip to main content
Recipes are pre-built workflows for training and evaluating models. Run them on Adaptive’s compute infrastructure.

​
Run a recipe

job = adaptive.jobs.run(
    recipe_key="sft",
    num_gpus=1,
    args={
        "model_to_train": "llama-3.1-8b-instruct",
        "output_model_key": "my-model-v1",
        "dataset": "my-training-data",
        "epochs": 3,
        "data_seed": 42,
    },
)
ParameterTypeRequiredDescription
recipe_keystrYesRecipe identifier (see below)
num_gpusintYesNumber of GPUs to use
argsdictNoRecipe-specific arguments (defaults to empty)

​
Common training arguments

ArgumentTypeDefaultDescription
data_seedint42Seed for dataset shuffling. Set for reproducible training runs.
checkpoint_frequencyfloat0.2Fraction of total training steps between saves. 0.2 = save every 20% of training (5 checkpoints per run).
All training recipes (sft, preference_rlhf, metric_rlhf, rl) support both arguments. Evaluation recipes use neither.
checkpoint_frequency is a fraction of total steps, not an absolute step count. checkpoint_frequency=0.1 saves every 10% of training; it is not “every 10 steps.” Disk usage scales linearly with frequency × model size × run length — a 70B model checkpointed every 10% of a long run uses meaningful storage.

​
Built-in recipes

Training:
RecipeKeyUse when
Supervised fine-tuningsftYou have high-quality completions
RL on preferencespreference_rlhfYou have preferred/rejected pairs
RL on metricsmetric_rlhfYou have completion-level scores
RL with graderrlCriteria can be expressed in natural language
Evaluation:
RecipeKeyUse when
Evaluate with graderevalComparing model performance
Optimization:
RecipeKeyUse when
Speculative decoding alignmentspecdec_alignmentYou want to accelerate inference with a draft model

​
Run an evaluation

adaptive.jobs.run(
    recipe_key="eval",
    num_gpus=2,
    args={
        "dataset": "eval-prompts",
        "models_to_evaluate": ["model-a", "model-b"],
        "graders": ["quality-judge"],
    },
)
Results appear as evaluation artifacts with score tables and per-sample interactions. Evaluations use Graders to score completions.

​
Resume an interrupted run

Resume picks up from the last saved checkpoint and keeps the same job ID — it does not fork a new run. Resume from the Runs tab in the UI, or re-launch the job with resume enabled.Resume is step-level, not epoch-level. Multi-stage runs (currently preference_rlhf, which orchestrates DPO / PPO / GRPO under one recipe) track each stage’s progress independently — resume picks up at the active stage’s last checkpoint, not the first stage.

​
Promote a checkpoint

Any saved checkpoint can be promoted to a standalone model in the project registry. See Promoted checkpoints on the Models page for the full workflow, including the LoRA-backbone footgun.For custom recipes, see Custom Recipes.See SDK Reference for all job methods.