Menu

Fine-tuning models: Unsloth AI and why you should use it

11 min read Manuel

Taking a pre-trained language model and adapting it to your own task has become the most common operation in applied AI. No longer research: everyday engineering. This article explains what fine-tuning is, how Unsloth AI came about, what makes it technologically different from the open-source alternatives, and when it makes sense to use it instead of Axolotl, LLaMA-Factory or TRL.

What fine-tuning is

A language model like Llama, Qwen or Gemma is pre-trained on hundreds of billions of tokens. It recognises the structure of language, but it knows nothing about your specific domain: the format of your logs, the tone of your documentation, the conventions of your code.

Fine-tuning updates the model’s weights on a smaller, targeted dataset. Pre-training teaches it to speak; fine-tuning teaches it to speak *about your problem*.

  PRE-TRAINING                    FINE-TUNING
  ┌─────────────────┐             ┌─────────────────┐
  │  Miliardi di    │             │  Migliaia di    │
  │  token generici │ ──────────► │  esempi dominio │
  │  (libri, web)   │             │  (tuoi dati)    │
  └─────────────────┘             └─────────────────┘
         │                                │
         ▼                                ▼
  Modello base                     Modello specializzato
  "sa parlare"                     "sa parlare di te"

There are three families of methods, ordered by computational cost:

  • Full fine-tuning: updates all the weights. Maximum flexibility, maximum cost. Dozens of GB of VRAM are needed even for small models.

  • LoRA (Low-Rank Adaptation): freezes the original weights and trains only small low-rank matrices. About 90% of the parameters stay frozen; the cost drops by an order of magnitude.

  • QLoRA: LoRA with the base model quantised to 4 bits. The base model takes up a quarter of the space; on a 24 GB GPU it lets you train 13B models that would not otherwise fit.

Unsloth focuses on LoRA and QLoRA, recently extending to full fine-tuning and reinforcement learning (DPO, GRPO).

The story of Unsloth

Unsloth started in 2023 as an open-source project by Daniel and Michael Han, two Australian brothers. Daniel had worked as a machine learning engineer at NVIDIA, where he had focused on optimising computational algorithms; his Y Combinator profile also reports that he found and fixed more than 20 bugs in open-source models such as Gemma, Llama, Mistral and Phi.

The idea is simple and starts from an observation that anyone who has trained models knows well: most of the training time is not spent doing useful mathematics, but switching GPU memory on and off for operations that can be rewritten more efficiently.

  2023 ─────────────────────────────────────────────────────────
        │  Progetto open-source nato in Australia
        │  "Rendere il fine-tuning su una sola GPU accessibile"
        │
  2024 ─────────────────────────────────────────────────────────
        │  Y Combinator Summer 2024 (batch S24)
        │  Seed round da ~$500K (YC, GitHub Accelerator, Microsoft M12)
        │  Daniel pubblica bug report dettagliati su Llama, Gemma, Mistral
        │
  2025 ─────────────────────────────────────────────────────────
        │  Febbraio: GRPO + integrazione vLLM (training e inference
        │            sulla stessa GPU)
        │  Agosto: supporto per gpt-oss 20B e 120B il giorno della
        │          release (QLoRA su ~14 GB di VRAM)
        │  Dicembre: padding-free training, sequence packing,
        │             supporto preliminare multi-GPU (DDP)
        │  "3x più veloce, -30% VRAM" rispetto alla release precedente
        │
  2026 ─────────────────────────────────────────────────────────
        │  Febbraio: MoE training support, embedding model support,
        │            ultra-long context RL. Oltre 50K stelle GitHub.
        │  Marzo: Unsloth Studio, interfaccia desktop e web
        │  "2-5x più veloce, -70-80% VRAM" vs training standard HF

Today Unsloth reports over 10 million monthly downloads on Hugging Face, adoption by teams such as Canva, LinkedIn and NVIDIA, and more than 500 supported model variants.

How it works: the technical difference

Most fine-tuning frameworks — Axolotl, LLaMA-Factory, TRL — are wrappers over PyTorch and Hugging Face Transformers. They add configuration, training methods, dataset management, but the underlying computation is that of PyTorch with autograd.

Unsloth does something different: it rewrites the heaviest kernels of the training loop in hand-written Triton code.

The problem Unsloth solves

When you train a model, 70-80% of the time is spent in a handful of operations:

  • attention (and its inverse in the backward pass)
  • rotary position embeddings (RoPE)
  • RMS normalization
  • cross-entropy loss
  • GELU and other activation functions

These operations are implemented in PyTorch with elementary operations that create and destroy intermediate tensors. Every operation reads and writes VRAM. The mathematical computation is minimal; the movement of data is huge.

  PYTORCH STANDARD                    UNSLOTH (TRITON)
  ┌──────────────────────┐           ┌──────────────────────┐
  │  x ──► [read VRAM]   │           │  x ──► [register]    │
  │      [compute]       │           │      [compute]       │
  │  [write VRAM]        │           │      [compute]       │
  │      │               │           │      [write VRAM]    │
  │      ▼               │           │                      │
  │  y ──► [read VRAM]   │           │  Un solo kernel,     │
  │      [compute]       │           │  un solo passaggio   │
  │  [write VRAM]        │           │  sulla memoria       │
  │      │               │           │                      │
  │      ▼               │           └──────────────────────┘
  │  ...                 │
  └──────────────────────┘

A single replacement Triton kernel for the whole sequence means: a single pass from VRAM instead of five, and the intermediate values stay in the GPU registers. VRAM is freed afterwards instead of being held from tensor to tensor.

Why it does not lose accuracy

One point that sets Unsloth apart from other optimisations (e.g. Mixed Precision Training): it introduces no numerical approximations. The mathematics is identical to that of standard PyTorch; only the implementation is different.

Hugging Face itself has verified that the accuracy degradation is 0% compared to standard QLoRA. This is not true for all memory optimisations: some techniques (e.g. aggressive gradient checkpointing or low-bit quantisation) introduce measurable losses. Unsloth avoids this trade-off.

What it supports today

  • Methods: LoRA, QLoRA, full fine-tuning, DPO, GRPO, KTO, ORPO, continued pre-training, pretraining

  • Precision: FP8 training (since late 2025), BF16, FP16
  • Models: 500+ variants — Gemma, Qwen, DeepSeek, Llama, Mistral, gpt-oss, and many others

  • Hardware: NVIDIA (CUDA), AMD (ROCm), Intel GPU
  • Context: up to 342,733 tokens on an 80 GB GPU (vs 28,454 with standard Transformers)

  • Multi-GPU: preliminary DDP (Distributed Data Parallel) support, FSDP — 2026 saw the first releases, but it is not yet at the level of Axolotl or LLaMA-Factory

The comparison with the competitors

Four open-source projects dominate local fine-tuning in 2026. All are free and Apache 2.0. They differ in where they spend their engineering effort.

Summary table

UnslothAxolotlLLaMA-FactoryTRL
GitHub stars (2026)53.9K11.4K68.4K
Main methodTriton kernelsParallelism compositionWeb UI + coverage
LoRA / QLoRA✓✓✓
Full fine-tuning✓✓✓
DPO / GRPO / RL✓✓✓
Mature multi-GPUPartial (DDP)✓ (DeepSpeed, FSDP)✓ (DeepSpeed, FSDP)
YAML config✗ (Python)✓ (extensive)✓
Web UI✗ (separate Studio)✗✓ (LlamaBoard)
VRAM saving (claim)40-80%VariesVaries
Speedup (claim)2-5x1-1.5x1-1.2x

VRAM and speed: real numbers

Measurement on Llama 3.1 8B, QLoRA, batch 1, context 1024, RTX 4090 (24 GB VRAM):

FrameworkVRAM usedTokens/sec
Baseline (HF + PEFT)18 GB1,200
Unsloth11 GB3,400
Axolotl16 GB1,500
LLaMA-Factory17 GB1,400

On a single GPU the gap is clear: Unsloth uses less memory and trains more than twice as fast as the baseline. The advantage shrinks on multi-GPU, where the parallelism strategies of Axolotl and LLaMA-Factory (DeepSpeed ZeRO, FSDP, tensor parallelism) make the difference.

Axolotl: configurable flexibility

Axolotl is the most configurable of the four frameworks. Everything is defined in a YAML file: parallelism strategies (FSDP2, DeepSpeed ZeRO, tensor parallelism, context parallelism, expert parallelism), training methods, quantisation, and dataset management.

Its strong point is mature multi-GPU. If you have to train on 8 H100s and compose DeepSpeed ZeRO Stage 3 with FSDP and tensor parallelism, Axolotl already has the configuration ready. On 8 H100s with Llama 3.1 8B, Axolotl reaches contexts of 129,024 tokens, although per-GPU efficiency drops to 15%.

The price is speed on a single GPU: Axolotl does not rewrite kernels, so it sits at the times of standard PyTorch with the wrapper overhead.

When to choose it: multi-GPU, complex configurations, research where the configuration file is the artefact you version and reproduce.

LLaMA-Factory: coverage and the web UI

LLaMA-Factory has the widest coverage of models: 100+ LLMs and VLMs, compatibility with architectures the others do not support. It offers a web interface (LlamaBoard) to manage training, evaluation and export without writing code.

It is the most accessible choice for non-specialist teams. The integration with Megatron-Core opens the door to large-scale pre-training, but the learning curve becomes steep.

When to choose it: you want a web UI, you need support for an exotic model or architecture, or you do continued pre-training and not just fine-tuning.

TRL: the Hugging Face ecosystem

TRL (Transformer Reinforcement Learning) is the official trainer API of Hugging Face for RLHF, DPO, GRPO and PPO. It is not a standalone framework: it is the library the others lean on when they do reinforcement learning.

Its value is standardisation: if you use TRL, the code is portable to other frameworks. If you do research on new alignment methods, TRL is where they are implemented for the first time.

When to choose it: you do research on RLHF, you need tight integration with the Hugging Face ecosystem, or you want maximum portability.

When to use Unsloth

Unsloth is not the best choice in every situation. Here is when it makes sense and when it does not.

Use Unsloth when:

  • You have a single GPU (12-24 GB VRAM): it is the use case it was designed for. The advantage in speed and VRAM is maximal.

  • You do LoRA or QLoRA: the optimisations are more effective on these methods than on full fine-tuning.

  • You want maximum speed: 2-5x faster than the baseline translates into less waiting time and less compute cost (if you use cloud GPUs).

  • You need long contexts: ultra-long context support is native.
  • You have a consumer GPU: it works on RTX 3090, 4090, and on more modest GPUs (3-4 GB) thanks to aggressive quantisation.

Do not use Unsloth when:

  • You need serious multi-GPU: Axolotl and LLaMA-Factory have years of maturity on DeepSpeed, FSDP, tensor parallelism. Unsloth has preliminary DDP and basic FSDP.

  • You need a web UI: LLaMA-Factory has LlamaBoard; Unsloth Studio is a separate and still young product.

  • You do research on new RL methods: TRL has the very first implementation and the greatest integration with Hugging Face.

  • You need declarative YAML configuration: Unsloth is Python-native; your training script is code, not a configuration file.

Practical example: first training

A minimal example to understand the syntax. You train a Qwen2.5-0.5B model on a sample dataset with QLoRA.

# install: pip install unsloth
from unsloth import FastLanguageModel

# 1. Carica il modello base quantizzato a 4 bit
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Qwen2.5-0.5B-Instruct-bnb-4bit",
    max_seq_length=2048,
    load_in_4bit=True,
)

# 2. Configura QLoRA: congela i pesi, allena gli adapter
model = FastLanguageModel.get_peft_model(
    model=model,
    r=16,                # rank delle matrici LoRA
    lora_alpha=16,       # scala del learning rate LoRA
    lora_dropout=0,
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj"
    ],
    bias="none",
)

# 3. Prepara il dataset nel formato instruct
# Il dataset deve avere una colonna "text" nel formato:
# "### Istruzione: ...\n### Risposta: ..."
from datasets import load_dataset
dataset = load_dataset("yahma/alpaca-cleaned", split="train[:1000]")

# 4. Addestra
from trl import SFTTrainer
from transformers import TrainingArguments

trainer = SFTTrainer(
    model=model,
    tokenizer=tokenizer,
    train_dataset=dataset,
    dataset_text_field="text",
    max_seq_length=2048,
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,
        warmup_steps=5,
        max_steps=100,
        learning_rate=2e-4,
        fp16=True,
        logging_steps=1,
        output_dir="outputs",
    ),
)

trainer.train()

# 5. Salva il modello (solo gli adapter, ~100 MB)
model.save_pretrained_gguf("outputs/gguf", tokenizer, quantization_method="q4_k_m")

Three things stand out compared to a standard PyTorch training:

  1. Quantisation is integrated: load_in_4bit=True with no separate steps.
  2. The LoRA configuration is explicit: you choose which layers to adapt with target_modules, not a generic flag.

  3. GGUF export is built-in: the format for local inference with llama.cpp is a command, not a separate converter.

The future: Unsloth Studio and multi-GPU

In March 2026 Unsloth released Unsloth Studio, a desktop and web application that lets you do dataset construction, fine-tuning and local inference without writing code. It was welcomed with interest by the community and reached the front page of Hacker News on launch day.

Multi-GPU support is the current frontier. The December 2025 release introduced DDP and accelerate launch; the team has stated that a fuller release is planned for 2026. As of today, if your training needs more than two GPUs, Unsloth is still keeping pace with Axolotl and LLaMA-Factory, but the gap is narrowing.

Conclusions

Unsloth is not one more fine-tuning framework: it is an optimisation of the underlying machinery that makes fine-tuning on a single GPU more accessible than it was with the others. The numbers on VRAM and speed confirm it, and the absence of accuracy loss removes the doubt that the optimisations sacrifice quality.

The choice depends on the context:

  • Single GPU, LoRA/QLoRA, maximum speed: Unsloth.
  • Multi-GPU, complex configurations: Axolotl.
  • Web UI, exotic model coverage: LLaMA-Factory.
  • RLHF research, portability: TRL.

None of the four is obsolete or superior in absolute terms. They answer different needs, and the ecosystem is richer for it. Unsloth’s value is having shifted the boundary of what is feasible on consumer hardware, and that is a contribution that goes beyond the benchmark.

Sources


TAG: #ai #security #git