Skip to navigation

Customization Job Reference

View as Markdown

Use this page when you need field-level details for customization job specifications, the complete API schema, or integration options.

For concepts, see Customization Job overview.

Key Fields

A customization job is submitted with a backend-specific spec (AutomodelJobInput for the automodel backend, UnslothJobInput for the unsloth backend). Both specs share the same top-level envelope, but several field names differ between backends. The table below lists the common envelope; for the full per-backend field list, see Training Configuration.

FieldRequiredDescription
nameNoName for this customization job. Auto-generated if not provided
workspaceYesWorkspace where the job runs. Determines which datasets and models are authorized for the job. Passed to jobs.create(), not part of the spec
spec.modelYesBase Model Entity to fine-tune. Automodel takes a string (workspace/name); Unsloth takes an object ({"name": "workspace/name", ...})
spec.datasetYesTraining data filesets. Automodel uses {"training": "...", "validation": "..."}; Unsloth uses {"path": "..."}
spec.trainingYesTraining method and hyperparameters (see Training Configuration)
spec.training.training_typeNoTraining method. Automodel: sft or distillation. Unsloth: sft. Defaults to sft
spec.training.finetuning_typeNoAdapter regime. Automodel: lora, lora_merged, or all_weights. Unsloth: lora or all_weights. Defaults to lora
spec.training.loraNoLoRA configuration ({"rank": 16, "alpha": 32, ...}). Auto-filled with defaults for LoRA regimes
spec.outputNoOutput artifact configuration ({"name": "..."}). Auto-generated if not provided
spec.integrationsNoOptional W&B / MLflow tracking configuration (see below)
spec.deployment_configNoAuto-deploy the trained model. Pass a string to reference an existing config by name, or an object with inline NIM deployment parameters (e.g., {"lora_enabled": true}). Omit to skip deployment. A referenced config that names no model (neither model_entity_id nor model_spec.model_name) is an unbound template: its engine and executor settings are copied onto a config for the trained model at deploy time, so it works for full-weight training, whose output model does not exist at submit time. For a LoRA job, the deployment is created against the base model with lora_enabled: true, and the adapter is served from it. The RL backend accepts the same field — see GRPO and Reward Environments

Deployment config validation

All three backends (automodel, unsloth, RL) resolve a referenced deployment_config at submit time and reject it before any GPU time is spent. A job fails to submit when:

  • The string reference does not resolve to a deployment config.
  • The job trains a standalone LoRA adapter and the referenced config has lora_enabled: false — the deployment could never load the adapter.
  • The job trains a standalone LoRA adapter and the referenced config names a model other than the job’s base model. The adapter is served from its base model’s deployment, so the config has to target that base.
  • The job registers a new model entity (all_weights, or a LoRA job with a merged save method) and the referenced config names a different model. The output entity does not have to exist yet — a config may point forward at the model the run will produce, which is what Studio creates up front. Retraining is fine for the same reason.
  • The config sets tool_call_config.tool_call_plugin and the caller lacks the models.tool-call-plugin.set permission.

A merged save (lora_merged, or unsloth’s merged_16bit / merged_4bit) folds the adapter into the base weights and produces a standalone model, so the LoRA-specific rules above do not apply to it.

Two config shapes are therefore valid ahead of a model that does not exist yet:

  • A forward reference — the config names the model the run will produce. Creating it up front means a bad engine or image is rejected in milliseconds at submit instead of after a training run, and the deployment can start the moment training ends. One config per run.
  • An unbound template — a config with neither model_entity_id nor model_spec.model_name. It carries only engine and executor settings, is accepted by any job, and is bound to the trained model at deploy time. Use this to share settings across runs.

Complete API Reference

For generated REST API details, see the Customizer API Reference and search for AutomodelJobInput or UnslothJobInput.


Weights & Biases Integration

Both backends accept the same integrations object on the job spec. Add a wandb block to request W&B tracking; the training runtime activates it when the required credentials are available.

import os
from nemo_helix_plugin.client.client import NemoClient
from nemo_customizer.sdk import Customization
from nemo_automodel_plugin.schema import AutomodelJobInput
client = NemoClient(base_url=os.environ.get("NHX_BASE_URL", "http://localhost:8080"), workspace="default")
customization = Customization.from_client(client)
spec = AutomodelJobInput(
model="default/qwen3-1.7b",
dataset={"training": "default/my-dataset"},
training={"training_type": "sft", "finetuning_type": "lora"},
schedule={"epochs": 3},
integrations={
"wandb": {
"project": "my-finetuning-project",
"entity": "my-team",
"tags": ["fine-tuning", "qwen"],
"api_key_secret": "my-wandb-key",
}
},
)
job = customization.automodel.jobs.create(spec=spec, workspace="default", name="my-job")

The api_key_secret field references a stored secret containing your WANDB_API_KEY. Use the secret name (e.g., "my-wandb-key") to resolve it from the request workspace. To create the secret, see Weights & Biases Keys.

FieldDescription
projectW&B project name. Defaults to output.name if not set
entityW&B entity (team or username)
tagsList of tags for filtering runs
api_key_secretReference to a secret containing WANDB_API_KEY
nameW&B run name. Defaults to the job ID if not provided
notesNotes or description for the run
base_urlBase URL for self-hosted W&B servers (e.g., https://wandb.mycompany.com). Omit to use W&B cloud

To view your training metrics in W&B after the job starts, see ft-tut-metrics-wandb.


MLflow Integration

Add an mlflow block to the same integrations object to request MLflow tracking:

spec = AutomodelJobInput(
model="default/qwen3-1.7b",
dataset={"training": "default/my-dataset"},
training={"training_type": "sft", "finetuning_type": "lora"},
schedule={"epochs": 3},
integrations={
"mlflow": {
"experiment_name": "qwen-finetuning",
"tracking_uri": "http://mlflow.example.com:5000",
}
},
)
job = customization.automodel.jobs.create(spec=spec, workspace="default", name="my-job")
FieldDescription
experiment_nameMLflow experiment name. Defaults to output.name if not set
tracking_uriThe MLflow tracking server URI. Can also be set via MLFLOW_TRACKING_URI
nameMLflow run name. Defaults to the job ID if not provided
tagsKey-value pairs for filtering runs (e.g., {"team": "nlp", "task": "sft"})
descriptionDescription for the MLflow run

Next Steps