Complete Guide to Supervised Fine-Tuning (SFT) for LLMs

Supervised fine-tuning (SFT) is the process of adapting a pre-trained language model to a specific task or behavioral style by training it on a curated dataset of instruction-response pairs. The pre-trained model already knows how to generate coherent text from its initial training on a large corpus. SFT teaches it how to respond appropriately to instructions, follow specific formatting requirements, adopt a particular tone, or apply domain knowledge in a structured way.

In practice, SFT is the most common fine-tuning method because it addresses the widest range of practical requirements. If you need a model to respond in a specific format (say, producing structured JSON, following a particular customer service script, or generating reports in a specific style), SFT is typically the right starting point. It is also the standard approach for domain adaptation: training on a corpus of technical documentation, legal text, or medical literature teaches the model both vocabulary and reasoning patterns specific to that domain.

SFT is distinct from the pre-training that created the base model. Pre-training uses next-token prediction on massive unlabeled corpora to build a model's general language understanding. SFT takes that general capability and shapes it toward specific behaviors using labeled examples. Most production fine-tuning projects start with SFT and then optionally add a second stage of preference optimization, DPO or a similar method, to refine output quality further.

SFT is the right choice when you have a collection of input-output examples that represent the behavior you want the model to exhibit. This covers a broad range of practical scenarios. If you want the model to answer questions about your product documentation, SFT on a dataset of question-answer pairs drawn from that documentation is the natural approach. If you want the model to write code in your team's style, following specific conventions, using your internal libraries, and matching your documentation patterns, SFT on examples of that code is the way to get there.

SFT is also appropriate when you need the model to adopt a specific output format reliably. Base models will generate output in variable formats. An SFT-tuned model can be taught to always produce JSON with particular keys, always start responses with a summary, or always answer in a specific number of words. Formatting consistency is surprisingly hard to achieve through prompting alone for complex formats, but SFT handles it well.

Where SFT is less effective is in situations where you want to shape the model toward subtle quality preferences rather than explicit behaviors. If the question is not "does the model produce the right format" but "does the model produce a good answer," preference optimization methods like DPO are more suitable. SFT teaches from positive examples only. Preference methods teach from the contrast between better and worse outputs. Many successful pipelines use SFT first to establish correct behavior and then apply preference optimization to refine quality.

The standard SFT dataset format on BIOS uses JSONL files where each line is a JSON object with three fields: instruction, input, and output. The instruction field contains the task description or system prompt. The input field contains the specific input for this example, which may be empty for tasks where the instruction itself is self-contained. The output field contains the desired response that the model should learn to produce.

For a customer service application, an example might have an instruction like "You are a customer service assistant for a software company. Answer the customer's question helpfully and concisely," an input containing the customer's actual question, and an output containing the ideal response. For a code generation task, the instruction might describe the function to write, the input might contain the signature and any relevant context, and the output would be the correct implementation.

Dataset quality matters enormously in SFT. The model will learn to replicate patterns in your training data, including errors, inconsistencies, and stylistic variations you did not intend. Before uploading, audit your dataset for: consistency in output format, appropriate length distribution, coverage of the full range of inputs your production system will encounter, and absence of personally identifiable information or other sensitive content. BIOS validates dataset format at upload time and provides a preview of sampled examples so you can spot formatting issues before training begins. A well-curated dataset of 1,000 examples will typically outperform a poorly curated dataset of 10,000.

Here is the BIOS dataset upload interface showing format validation in action:

After uploading, you can preview individual rows from your dataset to confirm the structure looks correct:

When configuring an SFT run on BIOS, one of the first decisions is which adapter type to use. This choice primarily affects memory consumption, training speed, and final model quality. The three most common options are LoRA, QLoRA, and full fine-tuning.

LoRA (Low-Rank Adaptation) is the best starting point for most SFT projects. It freezes the base model's weights and adds small trainable low-rank matrices to the attention and feed-forward layers. The base model weights never change, so LoRA training requires substantially less memory than full fine-tuning while achieving quality close to full fine-tuning on many tasks. LoRA is appropriate when you have moderate memory available and want a good balance of quality and efficiency.

QLoRA adds quantization on top of LoRA: the base model is loaded in 4-bit quantized form (using the NF4 quantization format), and LoRA adapters are trained in higher precision on top. This reduces memory requirements by roughly 50 to 70 percent compared to standard LoRA, making it possible to fine-tune large models on significantly less compute. The tradeoff is modest quality degradation from quantization, which matters more for some tasks than others. QLoRA is the right choice when memory is the primary constraint.

Full fine-tuning updates every parameter in the model with no adapters and no freezing. It typically produces the highest quality results, especially for large datasets and tasks requiring significant behavioral change, but it requires substantially more memory, approximately four times the model size in memory for bf16 training. Full fine-tuning is most appropriate when you have a large, high-quality dataset and the memory resources to support it. Other adapter options available on BIOS (AdaLoRA, LoHa, BOFT, ReFT) are more specialized and worth exploring once you have a baseline with LoRA or QLoRA.

The hyperparameters that most commonly determine SFT outcome quality are learning rate, batch size, number of training epochs, sequence length, warmup ratio, and weight decay. Understanding what each controls and what range to start in is essential for efficient experimentation.

• Learning rate: the most important hyperparameter. For LoRA-based SFT, typical values range from 2e-4 to 1e-4. For full fine-tuning, use smaller values: 2e-5 to 5e-6. Too high a learning rate causes loss spikes or divergence; too low means slow convergence or getting stuck. If you are unsure, start at 1e-4 for LoRA and 1e-5 for full fine-tuning and adjust based on the loss curve.
• Batch size: affects both training stability and speed. Larger batch sizes produce smoother gradient estimates and are generally preferable when memory allows. In practice, the effective batch size is the per-device batch size multiplied by the gradient accumulation steps. A common configuration is a small per-device batch (4 or 8) with gradient accumulation over 4 to 8 steps, giving an effective batch size of 16 to 64.
• Training epochs: control how many passes through the dataset are performed. For most SFT datasets, 1 to 5 epochs is appropriate. With very small datasets, you may need more epochs to achieve convergence. With very large datasets, 1 to 2 epochs is often sufficient and additional epochs risk overfitting. Watch the validation loss: if it starts increasing while training loss continues to decrease, you have overfit and should stop or reduce epochs.
• Sequence length: determines how many tokens are processed in each training example. Set this to the maximum length of your examples, rounded up to a power of two. Common values are 512, 1024, 2048, or 4096. Longer sequences require more memory and reduce the effective batch size.
• Warmup ratio and weight decay: a warmup ratio of 0.03 to 0.1 helps avoid large early updates that can destabilize training. Weight decay of 0.01 to 0.1 provides light regularization.

Running an SFT job on BIOS follows a straightforward workflow. Start by navigating to the Datasets section and uploading your JSONL file. BIOS will validate the format immediately, checking for required fields and flagging malformed lines. Use the preview to inspect a random sample of your examples and confirm they look correct before proceeding.

In the Training section, click "New Training Run" and work through the configuration. Select your base model. BIOS provides a searchable list of all 250+ supported models with details on architecture, parameter count, and training context. Set the adapter type based on your memory and quality requirements: LoRA for a good baseline, QLoRA if you want to reduce memory usage, full fine-tuning for maximum quality on large datasets.

The BIOS training wizard walks you through each configuration step:

Configure the SFT-specific hyperparameters in the form. BIOS provides default values and inline documentation for each field. Name your run with something descriptive. "llama3-8b-lora-r16-customer-service-v1" is much easier to work with than "run-42" when you are comparing results across experiments. Add tags if you are running multiple experiments and want to filter by configuration category.

Launch the job and navigate to the Monitoring tab to watch training progress. The dashboard streams training loss, evaluation loss, learning rate, and tokens-per-second in real time. Check that the training loss is decreasing smoothly in the first 10 to 20 percent of training. If the loss is flat or increasing, stop the run early, check your dataset and learning rate, and relaunch.

Effective monitoring during SFT training lets you catch problems early and make informed decisions about whether to continue or stop a run. The most important metric to watch is the training loss trajectory. In a healthy run, training loss decreases quickly in the first 10 to 20 percent of training and then continues decreasing more gradually. A loss curve that plateaus early may indicate too low a learning rate or a dataset problem. A loss curve that oscillates wildly or increases may indicate too high a learning rate.

The BIOS training detail view shows your loss curves, learning rate schedule, and checkpoint history in real time:

Validation loss is equally important and more informative for assessing generalization. Healthy runs show validation loss tracking closely with training loss, both decreasing through training. When validation loss stops decreasing or starts increasing while training loss continues to fall, the model is overfitting to the training set. This is the signal to stop training, even if training loss is still improving. BIOS saves checkpoints at configurable intervals, so you can recover the checkpoint from the point where validation loss was lowest.

After training completes, evaluate your model on a held-out test set using the same metrics you care about in production. For question-answering tasks, this might be exact match or F1 against reference answers. For generation tasks, you may need to use a combination of automated metrics like ROUGE or BLEU and human evaluation of a sample of outputs. Be skeptical of single-metric evaluation. A model can score well on an automated metric while still failing to meet qualitative standards that matter in production. Running your fine-tuned model against a diverse set of real-world examples from your target domain is ultimately the most reliable way to assess whether the training succeeded.

Several recurring mistakes cause SFT projects to underperform or fail outright, and recognizing them early saves significant compute and time. The most common mistake is training on low-quality data with the expectation that volume will compensate. Models learn the patterns present in your data with remarkable fidelity, including inconsistencies, formatting errors, and factual inaccuracies. If 20 percent of your training examples have inconsistent output formatting, the fine-tuned model will produce inconsistently formatted outputs roughly 20 percent of the time. There is no shortcut around data quality. Audit your dataset thoroughly before training.

The second most common mistake is using too high a learning rate for the chosen adapter type. LoRA and full fine-tuning have different optimal learning rate ranges, and using a LoRA-appropriate learning rate (1e-4) for full fine-tuning will often cause loss spikes or divergence. Always match your learning rate to your adapter type and start conservative. It is easier to increase a learning rate that converges slowly than to recover from one that causes divergence.

Overfitting is another frequent issue, particularly with small datasets. If your training loss continues decreasing while validation loss starts increasing, you have overfit. The fix is straightforward: reduce the number of epochs, increase regularization (weight decay, dropout), or expand your dataset. BIOS makes this easy to detect because validation loss is streamed in real time alongside training loss.

Finally, many teams skip the evaluation step entirely, relying on training loss as a proxy for model quality. Training loss tells you how well the model fits the training data, not how well it generalizes to new inputs. Always evaluate on a held-out test set using metrics that reflect your production requirements, and supplement automated metrics with manual review of a sample of outputs.

Ready to run your first SFT job? Begin by creating an account. Every new account receives a $10 welcome credit, which is enough to run several short training experiments on smaller models without entering payment information. Once your workspace is provisioned, navigate to the Datasets page and upload your JSONL file. BIOS validates the format immediately and provides a preview so you can confirm the data looks correct.

Next, navigate to Training and click New Training Run. The seven-step configuration wizard guides you through model selection, adapter choice, hyperparameter configuration, and dataset assignment. Start with a small model (7B or 8B parameters) and LoRA as the adapter type for your first experiment. Use the default hyperparameters BIOS provides. They are tuned for common SFT scenarios and give you a reliable baseline. Name your run descriptively so you can identify it later when comparing results.

Launch the job and watch the metrics stream in real time on the training detail page. Check that the loss is decreasing smoothly in the first few hundred steps. If everything looks healthy, let the run complete and then evaluate the checkpoint on your test data. From there, you can iterate: adjust hyperparameters, try a different adapter type, or scale up to a larger model. Since jobs are billed by the second, each experiment costs only what it actually uses.