How Long Does Fine-Tuning Take?

Published distil labs runs land between roughly six and twelve hours end to end, and the product documentation describes training as typically taking several hours. That window covers the whole pipeline — teacher evaluation, synthetic data generation, student fine-tuning and evaluation — not just the gradient steps.

How long does a distil labs run take end to end?

Several hours, with the reported cases clustering under twelve. The model training guide states plainly that the training process typically takes several hours to complete, which is why the API example in that guide polls status on a loop rather than blocking on a response.

Treat that as a planning figure, not a guarantee. It is a range observed across published runs, and every one of them had a specific student, dataset size and configuration behind it.

What do published runs report?

These are the durations distil labs has written up, with the setup each one used:

Run	Student	Setup	Reported duration
Multi-turn tool calling from traces	Qwen3-1.7B	zai.glm-5 teacher, trace processing then synthgen then finetune	~6 hours
Agent traces to a specialist model	Qwen3-0.6B	~300 seed traces expanded to ~10,000 synthetic examples	Under 12 hours
Classification via the web app	Not stated	Interactive labelling, teacher evaluation, distillation	8–12 hours
Traces to a faster, cheaper model	Not stated	End-to-end platform pipeline	Under 12 hours

For an external reference point at a completely different scale, the QLoRA authors report finetuning their 65B-parameter Guanaco model in 24 hours on a single GPU. A 65B model on one GPU taking a day, and a sub-2B student taking hours on managed infrastructure, are consistent with each other rather than in tension.

Which stage consumes the time?

The gradient updates are rarely the largest slice. A distillation run has three cost centres, and the middle one usually dominates for small students:

1. Teacher evaluation. The teacher answers your test set once. Short relative to the rest, and it is a gate: teacher evaluation tells you whether to spend the remaining hours at all.
2. Synthetic data generation. The teacher is called repeatedly until the target dataset exists. The default generation_target in the config file is 10,000 examples, generated in batches of generation_in_single_call (default 4), with each batch validated and deduplicated.
3. Student fine-tuning and evaluation. Passes over the generated set, then scoring against the held-out test set.

Because stage 2 is bounded by teacher throughput rather than by GPU throughput, a bigger student does not necessarily move the total as much as intuition suggests.

What makes a run faster or slower?

Every one of these is a documented configuration parameter. The direction is what matters; the magnitude depends on your data.

Factor	Default	Effect on wall-clock
generation_target	10,000	More examples means more teacher calls — the biggest single lever
llm_num_parallel_requests	4	Raising it shortens generation; setting it to 1 disables parallelism
num_train_epochs	4	Roughly linear in the fine-tuning stage only
Student size	Llama-3.2-1B-Instruct	Larger students cost more compute per token
use_lora	true	Fewer trainable parameters and no optimizer state for the frozen base
use_qlora	false	Enabling it is documented as slightly slower training
memory_optimized_training	false	Documented as significantly slower; a memory rescue, not a default
rlvr_dataset_size	0.0	Above zero adds a reinforcement learning stage after supervised fine-tuning

The student-size row rests on a well-established relationship rather than on our own measurement: Kaplan et al. showed loss scaling as a power law in model size, dataset size and compute, with compute per training token growing with parameter count. Picking a student from the supported models catalog is therefore also a scheduling decision.

Why can nobody quote you an exact number?

Because “fine-tuning time” is not one quantity, and the honest answer is that wall-clock depends on the run. Four things vary independently:

• What is being counted. Gradient steps alone, or the full pipeline including teacher calls and evaluation.
• Queueing. Managed training runs wait for capacity; that wait is real time but not training time.
• Teacher latency. Generation speed is set by the teacher model and how many requests run in parallel, both of which you choose.
• Data volume. A 10,000-example target and a 1,000-example target are different jobs.

Plan around the reported band, budget for the upper end, and poll status rather than guessing. One practical consequence worth knowing before you start: the vibe-tuning write-up notes that a distillation job cannot be cancelled once launched, so the cheap moment to catch a misconfigured run is the teacher evaluation gate, not hour three. If you do not have hardware of your own, fine-tune an LLM without a GPU covers the managed path these figures come from.