nemo-automodel-recipe-development

Start from the closest existing recipe under nemo_automodel/recipes/, then update the model, dataset, optimizer, loss, LR scheduler, step scheduler, and checkpoint builders. Add an example YAML under examples/, register a recipe alias only if adding a new recipe class, and validate with a CPU-compatible unit test and automodel <config.yaml>.

The _target_ key specifies a fully qualified Python callable, and all sibling keys in that section are passed as keyword arguments to it. For example, _target_: torch.optim.AdamW with lr: 2.0e-5 calls torch.optim.AdamW(lr=2e-5). Nested values can be overridden from the CLI with flags like --optimizer.lr.

Set step_scheduler.val_check_interval for validation cadence and step_scheduler.checkpoint_interval for save cadence. The validation_dataset key builds the validation dataloader, restore_from.path resumes from a checkpoint, and checkpoints default to consolidated safetensors for Hugging Face ecosystem compatibility.

Yes. VLM recipes use NeMoAutoModelForImageTextToText with a processor section instead of a tokenizer, living in recipes/vlm/finetune.py. Diffusion recipes use NeMoAutoDiffusionPipeline with a parallel_scheme config and support only DDP and FSDP2 strategies.

The most common cause is global_batch_size not being divisible by local_batch_size * dp_size * grad_accumulation_steps. Verify the batch size math is consistent across all distributed dimensions before launching training.

Do not use it for standalone distributed strategy selection, cluster launcher configuration, or model architecture onboarding. It covers only how those choices appear inside an AutoModel recipe YAML, not infrastructure setup outside the recipe context.