- LoRA: Trains a small set of adapter weights on top of the frozen base model.
- Full fine-tuning: Updates every weight in the base model.
Choose a method
Use LoRA when:- You’re starting a new fine-tune: LoRA gets you a working model fastest and at the lowest cost.
- You want to ship multiple adapters from the same base: Adapters are small and can be swapped on a single hosted base model.
- You’re tuning style, format, or domain vocabulary: These are the kinds of updates that LoRA handles best.
- The base behavior needs a substantial change: A model that doesn’t know the task you’re training for may need every weight updated, not only an adapter.
- LoRA results plateau below your target: Try increasing
lora_randlora_alphafirst, and if quality still falls short, switch to full fine-tuning.
Set the method on your job
Thelora parameter defaults to True. Pass lora=False (or --no-lora on the CLI) to run a full fine-tune instead. Everything else about the job stays the same.
LoRA settings
For the parameters that tune LoRA itself (lora_r, lora_alpha, lora_dropout, lora_trainable_modules), see the fine-tuning API reference.
Default target modules
When you don’t setlora_trainable_modules, it defaults to all-linear, which applies LoRA to the modules listed for each model in the tables below. To customize, pass a comma-separated list of module names instead.
Each module you list must appear in the model’s allow-list. Whitespace around module names is ignored, but a non-empty value that parses to no modules (for example "," or " , ") is rejected.
Target MoE expert layers
On mixture-of-experts (MoE) models, you can apply LoRA to the expert feed-forward projections instead of the attention projections. Setlora_trainable_modules to the expert modules w_up, w_gate, and w_down (or w_up and w_down on gateless models such as Nemotron). Together uses a compact shared-factor adapter layout across experts, so the adapter stays small even on very large models.
Use expert targeting when your task depends on the model’s domain knowledge (the feed-forward experts) rather than its attention patterns. For example, adapting an MoE base to a new domain or task family.
- Mixtral:
mistralai/Mixtral-8x7B-Instruct-v0.1. - DeepSeek / Kimi:
deepseek-ai/DeepSeek-V3.1,moonshotai/Kimi-K2.6,moonshotai/Kimi-K2.7-Code. - Nemotron (gateless,
w_upandw_downonly):nvidia/Nemotron-3-Nano-Omni-30B-A3B-Reasoning-BF16,nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-BF16.
What to expect from full fine-tuning
- Supported models: Full fine-tuning is available for a subset of the models that support LoRA. Large mixture-of-experts models, long-context variants, and some vision-language models are LoRA-only. See supported models for the per-model breakdown.
- Smaller batch sizes: Because full fine-tuning updates every weight, it carries a larger memory footprint, so the maximum batch size for a given model is generally smaller than the LoRA equivalent.
- Higher cost: Full fine-tuning trains every parameter rather than the 0.1% to 1% a LoRA job touches, so it consumes more compute and costs more. See pricing for details.
supports_full_training from the model limits endpoint. When it’s False, the model is LoRA-only, and passing lora=False returns a validation error.
Continue training from a checkpoint
Instead of starting from a base model, you can have a new job start from a previously completed job by passingfrom_checkpoint. The quickstart covers the accepted formats. When the previous job is a LoRA job, the new job handles its adapter in one of two ways:
- Continue it: The new job picks up the same adapter and keeps training it. The result is still a single adapter on the original base model.
- Merge it: Together folds the adapter into the base model, producing a standalone set of weights, and the new job trains on those instead. The original adapter is no longer a separate, swappable artifact.
The LoRA settings (
lora_r, lora_alpha, lora_dropout, and lora_trainable_modules) define the adapter’s shape, so an adapter can only continue training when all four match the previous job. To guarantee a continuation, omit the training type and the LoRA settings on the new job, so it inherits all of them from the previous job. Any value you set that differs from the previous job triggers a merge instead.
The new job produces a checkpoint based on its own training type. A full fine-tune outputs full model weights (--checkpoint-type default). A LoRA job outputs an adapter plus merged weights (--checkpoint-type adapter or merged on tg fine-tuning download). The merged weights contain everything trained so far, including any parent adapter that was merged along the way. See Choose a checkpoint type for the SDK equivalents and what each artifact contains.
In two cases the adapter can’t be merged, so the platform rejects the new job at creation unless the LoRA settings match the previous job exactly:
- The previous job started from a Hugging Face model: The rejection error names the settings that differ.
- The base model supports LoRA training only: These models never produce full weights, so there is nothing to merge the adapter into.
Serve your model
How you deploy depends on the method:- LoRA: After the job completes, deploy the merged model on a dedicated endpoint. See deployment.
- Full fine-tuning: The job produces a complete model rather than a compact adapter. Deploy it on a dedicated endpoint, or download the weights for local use. See deployment.