Runs

Three run types share one runner contract, one config format and one validation path:

task index ─▶ [ rollout generation ] ─▶ [ training ] ─▶ [ evaluation ]
                  difficulty filter      checkpoints     held-out score

A run is one .env config copied from a template. It launches by hand or through the agent plugin; both paths call the same runner and the same checks.

cp scripts/train/_template.env scripts/train/configs/my_run.env

PREFLIGHT_ONLY=1 bash scripts/train/train.sh scripts/train/configs/my_run.env   # validate
bash scripts/train/train.sh scripts/train/configs/my_run.env                    # launch

Each guide is written to the same shape — Prerequisites → Setup → Check → Run → Output → Dashboard → Cleanup — so the page tells you what it needs, what it writes, and which run type reads that output next. Running the Pipeline is the same material in run order, across all three at once.

Startup sequence

A train run comes up in this order: vLLM serves the policy, the in-process proxy fronts it, and verl drives the RL loop while the agent rolls out across tasks in Harbor sandboxes.

1. Config: the runner sources scripts/lib/site.env and your config, applies the model preset, and resolves the scaffold and backend.
2. Validation: nine classes of fatal assertion. The run stops here on any ✗.
3. venv: built once by scripts/setup_env.sh, or reused via VENV_PATH.
4. Ray: the cluster comes up and waits for NNODES nodes to join.
5. vLLM: verl launches DP × TP replicas. CUDA-graph capture on a 30B MoE (TP=4) is ~10–20 min before the first replica registers.
6. In-process proxy: started by the verl agent loop. It advertises a per-session URL per trial (no standalone LiteLLM, no fixed port).
7. verl loop: generate rollouts → run trials in Harbor → reward → update → checkpoint every SAVE_FREQ steps.

Where to go next

The three run types, each a full walkthrough:

• Training: optimize a policy on a task index
• Evaluation: score a checkpoint on a held-out set
• Rollout Generation: sample without training, to measure difficulty

What applies to a run once it is up:

• Scaling Up: multi-node, fully-async, VeOmni/MoE, partial rollout, R3
• Sandbox Backends: Kubernetes vs Docker sandboxes
• Model Serving: the agent → in-process proxy → vLLM chain and its health checks
• Results & Artifacts: logs, checkpoints, trajectories
• Run Validation: the nine assertion classes every launch runs first