How to Fine-Tune Llama 4 on Rented GPUs: 2026 Guide

Fine-tuning Llama 4 breaks the usual VRAM math the moment you open a config file. Most posts on how to fine-tune Llama models still reason like it's dense: parameter count times bytes per parameter, done. Llama 4 is a Mixture-of-Experts model, so that formula lies to you: Scout's 109B parameters and Maverick's 400B parameters all have to sit in GPU memory whether or not a given token routes to them, even though only 17B parameters actually compute per forward pass. Get that wrong and you'll either provision a GPU tier that OOMs on step one, or overpay for hardware you didn't need.

This guide is specifically about how to fine-tune Llama 4 on a rented GPU: which of Scout or Maverick fits your budget, why Unsloth is currently the only framework with native 4-bit QLoRA support for Scout, the exact training config that's actually been tested, and what the job costs end to end. If you're still weighing whether Llama 4 is the right base model at all, our DeepSeek V3.2 vs Llama 4 vs Qwen 3 comparison covers cost-per-token and benchmark tradeoffs across all three. For fine-tuning fundamentals that apply to any model, GRPO, dataset formats, evaluation, see how to fine-tune LLMs in 2026; this post picks up where that one stops and goes deep on Llama 4's specific MoE wrinkle.

How to Fine-Tune Llama 4: Scout vs Maverick, and Which One Fits a Rented GPU

Scout and Maverick are not interchangeable starting points. They differ by more than parameter count, and that difference decides your entire GPU rental budget before you write a line of training code.

Llama 4 Scout has 109B total parameters, 17B active per token, spread across 16 experts, with a 10 million token context window. Llama 4 Maverick has 400B total parameters, also 17B active, spread across 128 experts, with a 1 million token context window (Meta AI). Meta built both as Mixture-of-Experts models on purpose: "MoE architectures are more compute efficient for training and inference and, given a fixed training FLOPs budget, deliver higher quality compared to a dense model" (Meta AI, Llama 4 launch blog).

For a rented-GPU fine-tuning job, that efficiency claim matters for compute, not memory. Compute scales with the 17B active parameters on both models, so a forward pass costs about the same whether you're running Scout or Maverick. Memory scales with the full expert count, so Scout is the model within reach of a single rented GPU and Maverick is not. Meta's own guidance backs this up directly: Maverick "can be run on a single NVIDIA H100 DGX host for easy deployment, or with distributed inference for maximum efficiency" (Meta AI, Llama 4 launch blog). A DGX H100 host packs 8x H100 80GB GPUs, which is the multi-GPU tier this guide sizes Maverick fine-tuning against.

The practical rule: start with Scout unless your task specifically needs Maverick's larger expert pool or its output quality on a benchmark Scout doesn't clear. Most fine-tuning jobs, style adaptation, domain-specific instruction following, structured output, don't need 128 experts to succeed.

Choosing the Right GPU and VRAM Budget for LoRA vs QLoRA vs Full Fine-Tuning

The short answer: QLoRA on a single 80GB H100 covers Scout for almost every real fine-tuning job, and full fine-tuning of either model is rarely worth renting for. Everything below explains why.

MoE VRAM math is the trap that catches teams sizing Llama 4 for the first time. All expert weights, 109B for Scout, 400B for Maverick, must sit in GPU memory regardless of quantization or LoRA method, even though only 17B parameters are active per token. QLoRA reduces the loaded-weights bill by quantizing the base model, it does not reduce the total-expert-count bill (Spheron's LLM VRAM calculator for Llama 4). That single fact rules out several intuitive setups:

The weights-only figures come from our LLM VRAM calculator for Llama 4; add headroom for optimizer states, gradients, and activations on top for any method other than QLoRA, which is why the gap between LoRA and QLoRA's realistic minimum tier is so wide. For the general full/LoRA/QLoRA VRAM formulas this table specializes for MoE, see GPU VRAM requirements to fine-tune LLMs.

Why QLoRA Is the Practical Default for Llama 4 Scout's MoE Weights

QLoRA quantizes Scout's frozen base to 4-bit precision, dropping resident weights from roughly 218 GB at FP16 to roughly 55 GB, small enough to leave headroom on a single 80GB card for LoRA adapters, optimizer states, gradients, and activations. Unsloth's tested configuration runs this on a single 80GB A100: 4-bit QLoRA applied across all linear layers (Q, K, V, O, gate, up, and down projections), LoRA rank 32, batch size 1, with sequences padded to max length to simulate long-context workloads (Unsloth).

That last detail, padding to max length, matters more for Scout than it would for a dense model. Unsloth's Llama 4 Scout fine-tuning runs 1.5x faster, uses 50%+ less VRAM, and supports up to 8x longer context length than a standard Hugging Face plus Flash Attention 2 setup (Unsloth). If your fine-tuning task involves long documents or multi-turn conversation history, that context headroom is the difference between fitting your real data and truncating it. A single H100 on Spheron is the GPU tier this config targets; an 80GB A100 works the same way if that's what's available.

Maverick (400B) Full and LoRA Fine-Tuning: When It's Actually Worth Renting a Multi-GPU Node

Maverick's 200 GB INT4 weight footprint rules out a single GPU outright. QLoRA on Maverick needs a minimum of 4x H100 80GB (320 GB) to hold the quantized base with room for adapters and optimizer state; LoRA against a BF16 base pushes past 800 GB and needs a full 8x H100 node, the same DGX-class configuration Meta recommends for serving Maverick in production. Full fine-tuning, unquantized weights plus AdamW's two extra copies of every trainable parameter, is not a job most teams should rent a node for; the VRAM bill scales past what even an 8x H100 node comfortably holds once you add gradients and activations.

Rent the multi-GPU node only after you've verified LoRA on Scout doesn't already solve your task. That's rare, but it happens: tasks that need Maverick's 128-expert routing behavior, or benchmark performance Scout can't reach, are legitimate reasons to scale up. When you get there, expert-parallel training becomes relevant because Maverick's expert count is high enough that naive data parallelism wastes GPU memory holding duplicate expert copies on every card. Our MoE fine-tuning guide covering expert parallelism and MoE-LoRA walks through that setup for models in Maverick's weight class.

How to Fine-Tune Llama 4: Environment Setup on a Rented GPU Instance

Provisioning is the fast part. Spin up an H100 instance, SSH in, and install your training stack; the Spheron docs cover provisioning and networking if you're setting up a multi-GPU cluster for the first time.

pip install unsloth
pip install --upgrade transformers trl peft accelerate bitsandbytes

Why Unsloth Is Currently the Only Framework With Native 4-Bit QLoRA for Llama 4

This is worth stating plainly because it changes which framework you pick: "QLoRA fine-tuning for Llama 4 Scout in 4-bit precision is currently only supported by Unsloth. All other frameworks do not yet support 4-bit finetuning for Llama 4" (Unsloth). Without that native support, a standard Hugging Face plus PEFT plus bitsandbytes stack typically needs 300GB+ VRAM and runs into out-of-memory errors on Scout, because the quantization path isn't wired into the MoE layer loading the way Unsloth's is.

Loading the model in Unsloth looks like this:

from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Llama-4-Scout-17B-16E-Instruct",
    max_seq_length=8192,
    load_in_4bit=True,
    dtype=None,
)

model = FastLanguageModel.get_peft_model(
    model,
    r=32,
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj",
    ],
    lora_alpha=32,
    lora_dropout=0,
    bias="none",
    use_gradient_checkpointing="unsloth",
)

Meta's official model ID is meta-llama/Llama-4-Scout-17B-16E-Instruct (Hugging Face); Unsloth mirrors it with pre-quantized weights under the unsloth/ namespace, which is what the load call above pulls. Framework support here moves fast, so re-check Axolotl and TorchTune's docs before you commit a multi-day job to this assumption; it was accurate as of this guide's publish date.

Axolotl as the Multi-GPU Alternative for Full Fine-Tuning or LoRA on Maverick

Axolotl added Llama 4 support, including a linearized variant built for training (Axolotl on GitHub). Axolotl's broader training method support, full fine-tuning, LoRA, QLoRA, GPTQ, QAT, preference tuning (DPO, IPO, KTO, ORPO), and GRPO, extends across its supported model family, Llama 4 included (Axolotl on GitHub). It's the right tool once you're past a single GPU: Maverick's 4x or 8x H100 QLoRA and LoRA runs need FSDP-style sharding across cards, which Axolotl handles through its YAML config rather than requiring you to hand-write distributed training code.

base_model: meta-llama/Llama-4-Maverick-17B-128E-Instruct
load_in_4bit: true
adapter: qlora
lora_r: 16
lora_target_modules:
  - q_proj
  - k_proj
  - v_proj
  - o_proj
fsdp:
  - full_shard
  - auto_wrap
fsdp_config:
  fsdp_transformer_layer_cls_to_wrap: Llama4TextDecoderLayer

accelerate launch -m axolotl.cli.train maverick_qlora.yaml

For a full side-by-side on speed, VRAM, and multi-GPU behavior between the two, see our Axolotl vs Unsloth vs TorchTune comparison.

Dataset Prep and Training Script Walkthrough

Formatting Data for Llama 4's Chat Template

Llama 4 Scout and Maverick expect instruction-tuning data in the same role-based chat format as other Llama chat models: a list of {"role": ..., "content": ...} turns run through the tokenizer's chat template before training. Format your raw examples as JSONL, one conversation per line, then apply the template rather than hand-building prompt strings:

def format_example(example):
    messages = [
        {"role": "system", "content": example["system"]},
        {"role": "user", "content": example["instruction"]},
        {"role": "assistant", "content": example["response"]},
    ]
    return tokenizer.apply_chat_template(messages, tokenize=False)

The same dataset-size guidance that applies to any LoRA or QLoRA job applies here: 500 to 10,000 high-quality, deduplicated examples is the range that produces noticeable improvements without wasting compute on redundant data. Our fine-tuning fundamentals guide covers data quality and cleaning in more depth if you're building a dataset from scratch.

Unsloth QLoRA Config for Llama-4-Scout-17B-16E-Instruct (Rank, Batch Size, Target Modules)

Unsloth's tested reference point is rank 32, batch size 1, all seven linear layer types targeted (Q, K, V, O, gate, up, down), with gradient accumulation to reach an effective batch size that keeps training stable:

from trl import SFTTrainer, SFTConfig

trainer = SFTTrainer(
    model=model,
    tokenizer=tokenizer,
    train_dataset=dataset,
    args=SFTConfig(
        per_device_train_batch_size=1,
        gradient_accumulation_steps=8,
        warmup_steps=10,
        num_train_epochs=3,
        learning_rate=2e-4,
        logging_steps=10,
        optim="adamw_8bit",
        output_dir="outputs",
    ),
)
trainer.train()

optim="adamw_8bit" keeps optimizer state VRAM proportional to the LoRA adapter, not the frozen 4-bit base, which is what leaves room on an 80GB card for a reasonable sequence length. Batch size 1 with gradient accumulation is deliberate here, not a limitation: it's Unsloth's tested setting for Scout, and pushing batch size higher on a single-GPU QLoRA run usually costs you context length before it buys meaningful throughput.

Cost Estimate: Training Time x Hourly GPU Price

A QLoRA fine-tuning job on Scout, a few thousand examples over a handful of epochs, typically costs tens of dollars on a rented H100, not hundreds. The two inputs are training wall-clock time and the hourly GPU rate, and the rate moves with live availability more than the time does.

On Spheron's live GPU offers as of this post, on-demand (dedicated) H100 pricing per GPU runs from $2.65/hr for H100 PCIe up to $5.01/hr for H100 SXM5; spot pricing on the same hardware starts around $2.20/hr, with the tradeoff that a spot instance can be reclaimed without notice, which is fine for an unattended overnight QLoRA run with checkpointing but riskier for a single long training pass you can't afford to lose. An 80GB A100, the card Unsloth actually tested Scout QLoRA on, is listed from $1.43/hr on Spheron's pricing page.

Pricing fluctuates based on GPU availability. The prices above are based on 13 Aug 2026 and may have changed. Check current GPU pricing → for live rates.

Rather than guess at wall-clock hours by hand, run your actual dataset size and model against Spheron's training cost calculator: it turns model size, dataset size, and GPU choice into a wall-clock and dollar estimate using live pricing. As a rough planning number, a 5,000-example dataset over three epochs on a single H100 PCIe with the Unsloth config above typically lands in the 8 to 16 hour range, which puts total compute cost in the $20 to $45 band at current on-demand rates, cheaper still on spot. For the broader question of when renting GPUs beats a hosted fine-tuning API on cost, see LLM fine-tuning cost: API vs renting your own GPUs.

Common Mistakes Fine-Tuning Llama 4 on Rented Hardware

• Sizing VRAM off the 17B active parameter count instead of the full expert count. This is the single most common Llama 4 mistake: 17B active parameters describes compute, not memory. Size your GPU tier off 109B (Scout) or 400B (Maverick) total parameters at your chosen precision, not the active count.
• Assuming a standard HF plus PEFT plus bitsandbytes stack will QLoRA Scout the way it does other models. It won't, currently; you'll hit 300GB+ VRAM requirements and OOM. Use Unsloth for single-GPU QLoRA on Scout until another framework ships native support.
• Applying attention-only LoRA to a task that actually needs router adaptation. Standard LoRA targeting Q, K, V, O layers leaves the expert routing behavior frozen. If your task needs the model to route differently, not just respond differently, you need MoE-aware adapters like MoELoRA, covered in our MoE fine-tuning guide.
• Skipping the license naming requirement before distributing a checkpoint. The Llama 4 Community License lets you fine-tune and commercially deploy royalty-free, but if you distribute a fine-tuned model or its outputs, the resulting model's name must start with "Llama," and you must display "Built with Llama" if you distribute a product built on it. A separate license from Meta is required only if your product or service exceeds 700 million monthly active users (Meta, Llama 4 Community License).
• Renting a multi-GPU Maverick node before testing whether Scout LoRA already solves the task. Scout QLoRA on a single H100 costs a fraction of a Maverick node. Confirm Scout can't hit your quality bar before you provision 4x or 8x H100.
• Running a long QLoRA job on spot without a checkpoint strategy. Spot instances can be reclaimed without notice. Set save_steps low enough that a preemption mid-run costs you minutes, not hours of progress.

Deploying the Fine-Tuned Model for Inference

Once training finishes, merge the LoRA adapter into the base weights and serve with vLLM:

model = model.merge_and_unload()
model.save_pretrained("llama-4-scout-merged")
tokenizer.save_pretrained("llama-4-scout-merged")

vllm serve llama-4-scout-merged --tensor-parallel-size 1 --dtype bfloat16

For the full deployment walkthrough, GPU sizing for inference specifically (which differs from training VRAM math), vLLM flags, and tensor-parallel configuration for both Scout and Maverick, see deploying Llama 4 Scout and Maverick on GPU cloud with vLLM.

Once your Scout QLoRA config is dialed in, the same H100 tier that trained it can serve it. Check live rates before you provision.

H100 GPU pricing →