Unsloth: fine-tuning within reach

The video is in Italian; this page is the written version in English.

Unsloth is not a model and not an interface: it is the engine that makes training feasible on modest hardware. It hand-rewrites the heaviest parts of the process, and the result — without quality loss — is roughly double the speed at a fraction of the memory.

Translated: fine-tuning moves from “needs a datacentre” to “fits on a gaming GPU or a free cloud notebook”.

Before you start: do you actually need it?

Worth repeating what the fine-tuning lesson said, because this is the most expensive mistake around.

You want to…	Need fine-tuning?
Teach a style, a tone, a format	yes, that is its job
Teach facts, documents, updatable data	no, you need RAG
Improve on a repetitive, well-defined task	probably yes
Add knowledge that changes over time	never

The distinction in one line: fine-tuning changes how the model answers, RAG changes what it knows. Confusing them costs months.

How it works in practice

The path is always the same. Prepare a set of examples in instruction-response format; choose a base model; train a LoRA adapter — so without touching the original weights, as in the dedicated lesson; test it; export.

The step that closes the loop is the export: the trained model is converted to GGUF and loaded into Ollama, where it becomes a model like any other, callable by name.

Where you win and where you lose

The decisive factor is not machine power, it is the data. Five hundred well-written, consistent examples beat five thousand scraped ones. If you want a certain tone, every single example must have that tone: exceptions teach the model that exceptions are allowed.

The pitfall to know is overfitting: the model memorises instead of generalising, and you spot it because it does beautifully on training examples and poorly on everything else. Avoid it by holding out a slice of data for checking and stopping early, without overdoing the epochs.

A realistic note on scale: fine-tuning is within reach, but it is not instant. Preparing the data takes longer than the training itself, and that is the part no tutorial mentions.

The dataset: where it is actually won

Everything else — hardware, parameters, training duration — matters less than example quality. It is the part tutorials dismiss in two lines and the one that takes most of the real time.

Rule	Why
Absolute consistency in style	Exceptions teach that exceptions are allowed
Variety across cases	All-similar examples produce a fragile model
Include the hard cases	With only easy examples, the model folds on real ones
Quality over quantity	500 curated examples beat 5,000 scraped

The most frequent mistake is the first: examples are gathered from different sources with different tones, hoping the model will average them. It does not average: it learns that any tone is acceptable and picks one at random.

A practical way to start: write twenty perfect examples by hand, the ones that represent exactly what you want, and use them as the reference for generating or selecting more.

How to tell whether it worked

Once training ends you need the answer to one question: is it better than before? Three measures, all necessary.

First, on examples never seen, held out from training from the start. Second, against the base model: same examples, answers side by side — if there is no visible difference, the fine-tuning did nothing. Third, on generic tasks outside the domain, to notice what the model lost along the way.

The third is the one people skip and the one that hurts: it is easy to end up with a model excellent at its task and useless at everything else.

And a realistic note: preparing the data takes longer than the training itself. Budget three rounds before you have something usable.

The full path, step by step

Worth seeing the whole loop, because the training part — the one everyone talks about — is the shortest.

1. DATA       instruction/response pairs, consistent and verified
              (60-70% of the real time is here)
   ↓
2. TRAIN      LoRA/QLoRA on top of a base model
              (the minutes you see in tutorials)
   ↓
3. EVALUATE   held-out examples + comparison with the base + regressions
   ↓
4. EXPORT     adapter merged into the model, converted to GGUF
   ↓
5. USE        imported into Ollama, it becomes a model like any other

The step that closes the loop is the fourth: without exporting you are left with an adapter that lives only in the training environment. Converted, the model is called by name like any other, and from then on everything you know about local models applies to yours too.

Where it runs and where it does not

A practical point that saves half-days: you need an NVIDIA GPU. On Apple Silicon this library does not run — for fine-tuning on a Mac there is a different route, based on Apple’s framework.

Situation	Feasible?
8-12 GB NVIDIA GPU	Yes, models up to 7-8B with QLoRA
24 GB NVIDIA GPU	Yes, comfortably, larger models too
Free cloud notebook	Yes, within session time limits
Apple Silicon	No, use the MLX-based alternative
CPU only	No

The free cloud notebook is the fastest way to find out whether this path makes sense before buying anything: try it with a hundred examples, look at the result, and only then decide whether the problem really warranted fine-tuning or a better prompt would have done.

In short

Concept	In one line
What it is	The engine that makes fine-tuning feasible on ordinary hardware
The gain	Roughly double speed and far less memory, same quality
The path	Data → LoRA → test → export to GGUF → Ollama
Decisive factor	Quality and consistency of examples, not the machine
The trap	Overfitting: great on examples, poor on everything else
Dataset	Consistency and variety matter more than volume or hardware
Evaluation	Fresh examples, base comparison, and a regression check
The full loop	Data, training, evaluation, export, use in Ollama
Where it runs	Needs an NVIDIA GPU: on Apple Silicon use the MLX alternative