Supervised Fine-Tuning (SFT) for LLMs: A Complete Guide

Supervised fine-tuning (SFT) takes a pre-trained language model and adapts it to a particular task or behaviour by training on a curated set of instruction-response pairs. The base model arrives already able to generate coherent text — that competence comes from its original training over a large corpus. What SFT adds is direction: how to answer instructions, which format to hold to, what tone to carry, and how to apply domain knowledge in a structured way.

It is the workhorse of fine-tuning because it covers the widest span of practical needs. A model that must return structured JSON, follow a support script, or draft reports in a house style usually starts with SFT. The same goes for domain adaptation — training over technical documentation, legal text or medical literature teaches both the vocabulary and the reasoning patterns of that field.

SFT is not the pre-training that built the model. Pre-training learns general language from massive unlabelled corpora through next-token prediction; SFT bends that general capability toward specific behaviour using labelled examples. Most production projects begin with SFT and, where needed, add a second stage of preference optimization — DPO or a relative — to sharpen output quality further.

SFT fits whenever you hold a set of input-output examples that show the behaviour you want. That covers a wide stretch of practice. Want the model answering questions about your product documentation? SFT over question-answer pairs drawn from that documentation is the natural move. Want it writing code the way your team does — your conventions, your internal libraries, your documentation patterns? SFT over examples of that code gets you there.

It is equally the tool for reliable output format. Base models produce variable formats; an SFT-tuned model can be taught to always return JSON with particular keys, always open with a summary, always answer within a word budget. Complex formats are stubbornly hard to force through prompting alone — SFT holds them well.

Where SFT earns less is in shaping subtle quality preferences rather than explicit behaviour. Once the question becomes "is this a good answer" rather than "is this the right format," preference optimization — DPO and its family — is the better instrument. SFT learns from positive examples only; preference methods learn from the contrast between better and worse. Strong pipelines run SFT first to fix behaviour, then preference optimization to refine quality.

The standard SFT dataset on Vidman AI is a JSONL file in which every line is a JSON object carrying three fields: instruction, input, and output. The instruction holds the task description or system prompt. The input holds the example's specific input — empty where the instruction is self-contained. The output holds the response the model should learn to produce.

A customer-service example might carry an instruction like "You are a customer service assistant for a software company. Answer the customer's question helpfully and concisely," an input with the customer's actual question, and an output with the ideal reply. A code-generation example might describe the function in the instruction, put the signature and context in the input, and place the correct implementation in the output.

Quality outweighs quantity by a wide margin. The model replicates whatever patterns sit in the training data — errors, inconsistencies and stylistic drift included. Audit before uploading: consistency of output format, sane length distribution, coverage of the input range production will actually see, and no personally identifiable information or other sensitive material. Vidman AI validates format at upload and previews sampled rows so structural problems surface before training starts. A curated 1,000-example set routinely beats a sloppy 10,000.

The upload interface with format validation in action:

After upload, individual rows can be previewed to confirm the structure:

The first real decision in an SFT run is the adapter type, and it drives memory consumption, training speed, and final quality. The three common options are LoRA, QLoRA, and full fine-tuning.

LoRA (Low-Rank Adaptation) is the sensible default. It freezes the base weights and appends small trainable low-rank matrices to the attention and feed-forward layers; the base never changes, so training needs far less memory than a full fine-tune while landing close to full-tune quality on many tasks. With moderate memory available, it is the quality-efficiency balance.

QLoRA stacks quantization underneath: the base loads in 4-bit (NF4), and LoRA adapters train at higher precision on top. Memory drops roughly 50 to 70 percent versus standard LoRA, which puts large models within reach of much smaller compute. The cost is modest quality loss from quantization — more visible on some tasks than others. When memory is the binding constraint, QLoRA is the pick.

Full fine-tuning updates every parameter — no adapters, nothing frozen. It tends to produce the strongest results, particularly on large datasets and tasks demanding deep behavioural change, at roughly four times the model size in memory for bf16. It suits teams with a large, high-quality dataset and the memory to match. The further options on Vidman AI — AdaLoRA, LoHa, BOFT, ReFT — are more specialised, worth exploring once a LoRA or QLoRA baseline exists.

The settings that most often decide an SFT run's outcome are learning rate, batch size, epochs, sequence length, warmup ratio, and weight decay. Knowing what each steers — and where to start — is most of efficient experimentation.

• Learning rate: the one that matters most. LoRA-based SFT typically runs 2e-4 to 1e-4; full fine-tuning wants far smaller, 2e-5 to 5e-6. Too high brings loss spikes or divergence; too low leaves convergence crawling or stalled. Unsure? Open at 1e-4 for LoRA and 1e-5 for full, then let the loss curve arbitrate.
• Batch size: steers stability and speed together. Bigger batches smooth the gradient estimates and are preferable wherever memory allows. The effective batch is per-device batch × gradient-accumulation steps; a common shape is a small per-device batch (4 or 8) accumulating over 4 to 8 steps for an effective 16 to 64.
• Epochs: how many passes over the dataset. Most SFT datasets want 1 to 5. Small datasets sometimes need more to converge; very large ones are often done in 1 to 2, with further epochs courting overfit. Watch validation loss — when it climbs while training loss still falls, stop or cut epochs.
• Sequence length: tokens per training example. Set it to the longest example rounded up to a power of two — 512, 1024, 2048, 4096. Longer sequences cost memory and shrink the effective batch.
• Warmup ratio and weight decay: warmup of 0.03 to 0.1 avoids violent early updates; weight decay of 0.01 to 0.1 adds light regularization.

An SFT job on Vidman AI runs a short, linear path. Open the Datasets section and upload the JSONL file; format is validated on the spot, required fields checked, malformed lines flagged. Preview a random sample to confirm the examples look right before moving on.

In Training, click "New Training Run" and walk the configuration. Pick the base model — the searchable catalog lists architecture, parameter count, and training context. Set the adapter type against your memory and quality budget: LoRA for the baseline, QLoRA to cut memory, full fine-tuning for maximum quality on large datasets.

The wizard carries each step:

Fill the SFT hyperparameters; defaults and inline documentation accompany every field. Name the run something you can recognise later — "llama3-8b-lora-r16-customer-service-v1" beats "run-42" when results are compared across experiments — and tag runs you want to filter by configuration.

Launch, then open Monitoring. Training loss, evaluation loss, learning rate and tokens-per-second stream live. Expect training loss to fall smoothly through the first 10 to 20 percent; if it is flat or rising, stop early, inspect the dataset and learning rate, and relaunch.

Good monitoring catches problems while they are still cheap. The headline signal is the training-loss trajectory: a healthy run drops fast over the first 10 to 20 percent, then keeps easing down more slowly. A curve that plateaus early suggests a learning rate too low or a dataset problem; one that oscillates or climbs suggests a learning rate too high.

The training detail view streams loss curves, the learning-rate schedule, and checkpoint history:

Validation loss matters more for generalization. Healthy runs keep validation tracking training, both descending. The moment validation stalls or climbs while training keeps falling, the model is memorising the training set — stop there, whatever training loss is doing. Checkpoints save at configurable intervals, so the lowest-validation checkpoint is recoverable.

Once training completes, evaluate on a held-out test set with the metrics production actually cares about — exact match or F1 for question answering; for generation, automated scores like ROUGE or BLEU alongside human review of a sample. Distrust any single metric: a model can score well and still fail the qualitative bar that production sets. In the end, running the fine-tune against a diverse spread of real examples from the target domain is the most honest verdict on whether the training worked.

A few recurring mistakes account for most failed or underperforming SFT projects, and catching them early saves real compute. First: training on low-quality data and expecting volume to paper over it. The model reproduces the patterns in the data with uncomfortable fidelity — inconsistencies, formatting errors and factual slips included. Twenty percent of examples with inconsistent formatting yield roughly twenty percent inconsistently formatted output. No shortcut exists around data quality; audit the dataset thoroughly before training.

Second: a learning rate too high for the chosen adapter. LoRA and full fine-tuning occupy different ranges, and a LoRA-appropriate 1e-4 applied to a full fine-tune reliably produces loss spikes or divergence. Match rate to adapter and start conservative — raising a slow rate is easy; recovering from divergence is not.

Third: overfitting, most often on small datasets. Training loss still descending while validation climbs is the signature. The remedies are simple: fewer epochs, more regularization (weight decay, dropout), or a larger dataset. Vidman AI surfaces it immediately — validation loss streams beside training loss.

Fourth: skipping evaluation entirely, trusting training loss as a proxy for quality. Training loss says how tightly the model fits the data, not how well it generalises. Always evaluate on a held-out set, with metrics that mirror production, and add manual review of a sample of outputs.

Vidman AI gives 50% extra on your first wallet top-up. Create the account, fund the wallet, upload a dataset, and run a quick LoRA job on a 7B model: the whole experiment typically costs a few rupees and finishes in minutes.

When longer experiments are on the agenda, add a payment method and fund the wallet from the Billing page. The balance sits on the dashboard, and auto top-up can refill the wallet automatically below a threshold so training never halts mid-run for lack of funds.

As the workload scales, per-second billing compounds: teams running dozens of experiments a week save substantially against hourly platforms, because iterative experimentation — the thing that produces good models — no longer carries a rounding penalty. Experiment more, save more relative to hourly billing, and land on better models.