---

name: training-config description: "Plan StarVLA training, co-training, YAML overrides, DeepSpeed launches, checkpoints, and safe validation." disable-model-invocation: true metadata: disco-role: operating license: NOASSERTION

StarVLA training-config

Use this sub-skill when the user needs a safe StarVLA training or co-training launch plan, wants to edit an OmegaConf YAML, needs to reason about CLI dotlist overrides, or is debugging trainer/checkpoint behavior before running a GPU job.

Start here

1. Identify the intended entry point:
   • VLA-only policy training: starVLA/training/train_starvla.py.
   • VLA + VLM co-training: starVLA/training/train_starvla_cotrain.py.
   • VLM-only tuning: starVLA/training/train_starvlm.py.
2. Read the base YAML and apply command-line overrides as KEY=VALUE dotlist items after the YAML.
3. Plan the accelerate launch command without running it. Use scripts/plan_training_command.py for a safe dry-run command plan.
4. Check output layout: StarVLA sets output_dir = run_root_dir/run_id, writes checkpoints under checkpoints/, and writes final weights under final_model/.
5. For common failures, use references/troubleshooting.md before escalating to environment or model-family debugging.

References

• Configuration reference: YAML sections, OmegaConf precedence, Accelerate/DeepSpeed configs, checkpoint directories.
• Training workflows: entry-point choice, launch anatomy, W&B-disable hints, safe validation, reference-only source launchers.
• Trainer API: TrainerUtils, learning-rate groups, freeze_modules, dotlist normalization, checkpoint save/reload behavior.
• Troubleshooting: bad override syntax, horizon/data mismatch, dataset statistics, W&B, distributed, DeepSpeed/GPU, and flash-attn issues.

Route elsewhere

• Model architecture family, framework registry names, action heads, and checkpoint/model compatibility: model-frameworks.
• Dataset registry creation, LeRobot layout, data_mix, dataset_py, modality JSON, and data indices: data-integration.
• Benchmark evaluation after a checkpoint exists: benchmark-evaluation.
• Serving checkpoints or policy-server config overrides: policy-deployment.
• Cross-cutting install/backend failures: root troubleshooting.

Operating rules

• Do not launch training unless the user explicitly asks for execution and the required backend is prepared. Training entry points use CUDA autocast and common recipes assume GPUs plus Accelerate/DeepSpeed.
• Prefer explicit KEY=VALUE overrides, for example framework.name=QwenGR00T and trainer.freeze_modules=. Avoid bare flags when the intended value is empty.
• Do not copy source run_*.sh launchers as-is. Treat them as reference-only because they set site-specific NCCL interfaces, GPU counts, data/model paths, and W&B identities.