Chain runs into a pipeline

init-from relay training, —then automatic post-processing, export and eval

sf submit my-sft --profile h200:8
sf submit my-dpo --profile h200:8 --init-from run/<SFT_RUN_ID>/checkpoint

Post-training is rarely one step: SFT for the base, then DPO or GRPO alignment, then export and evaluation. --init-from is how a stage starts from the previous one’s artifact.

Every run’s checkpoint is registered automatically, the next stage references it by run id, and the lineage stays queryable end to end — so six months later “what was this trained from” has an answer that does not depend on anyone’s memory.

Start from the previous stage: —init-from

# Stage 1: SFT
sf submit my-sft --profile h200:8
# → on success the artifact is registered as run/<SFT_RUN_ID>/checkpoint

# Stage 2: DPO starting from the SFT artifact
sf submit my-dpo --profile h200:8 \
  --init-from run/<SFT_RUN_ID>/checkpoint

# Pin a specific step's checkpoint
sf submit my-grpo --profile h200:8 \
  --init-from "run/<DPO_RUN_ID>/checkpoint@step=120"

The server resolves the reference, verifies the artifact exists and its ownership, and injects the actual path into the job. The Lineage view in the console job details shows the entire chain.

Run automatically after training succeeds: —then

sf submit my-grpo --profile h200:8 --then export --then eval

After training succeeds, the platform automatically submits the post-processing jobs (seconds to minutes — no extra RayCluster cold start to pay for).

Export to HuggingFace format: sf export

sf export my-grpo \
  --checkpoint <checkpoint path from the artifact registry> \
  --checkpoint-format nemo-dcp \
  --push-repo myorg/my-model        # optional: push to HF Hub (requires a linked HF account)

--checkpoint-format supports nemo-dcp / nemo-megatron / verl-fsdp / verl-megatron / huggingface. When pushing to the Hub, the server injects the current user’s HF token (see HuggingFace Integration); the repo name is validated against injection.

Framework-native evaluation: sf eval

Runs the framework-native evaluation entry point declared by the recipe:

# NeMo-RL: evaluate an HF model
sf eval my-grpo --model /shared/hf_export/my-model
# NeMo-RL: explicit evaluation config
sf eval my-grpo --model Qwen/Qwen3.5-9B --eval-config configs/eval/gsm8k.yaml

# verl SFT: report validation samples back to the training run
sf eval my-verl-sft --run-id <TRAIN_RUN_ID> --step 200 --data data/val.parquet

sf eval is framework-native evaluation (reusing the training framework’s inference path); for standard benchmarks comparable across models (GSM8K / MMLU / C-Eval…) use sf bench, whose scores are ingested into the unified dashboard. See Benchmarks.

Cleanup: sf clean

sf clean my-old-exp        # interactive confirmation
sf clean my-old-exp -y     # skip confirmation

Deletes the experiment’s checkpoints and logs on the cluster — irrecoverable. Job records and metrics are retained on the platform.

A complete pipeline example

# 1. SFT as the base
sf new sft-qwen95 --method nemo-rl/sft
sf submit sft-qwen95 --profile h200:8
# 2. GRPO alignment (chained to the SFT artifact, auto-export after training)
sf new grpo-qwen95 --method nemo-rl/grpo
sf submit grpo-qwen95 --profile h200:8 \
  --init-from run/<SFT_RUN>/checkpoint --then export
# 3. Standard benchmark verification
sf bench run bench-qwen95 -m run:<GRPO_RUN> --suites gsm8k,mmlu
# 4. Chat with it in the Playground
sf serve start run:<GRPO_RUN> --gpus 1