Can You Turn an SLM Into an LLM? How to Fine-Tune a Small Language Model (Student Guide 2026)
Can fine-tuning turn a small language model into an LLM? Not quite, but it can make an SLM beat an LLM on your task. This student guide covers SLMs vs LLMs, LoRA, QLoRA, distillation and RAG, and real results from Google, NVIDIA, DeepSeek and Predibase. It also includes a 7-stage pipeline, tested Hugging Face code and a ByteMuni experiment comparing four fine-tuning methods.

A question we hear a lot from students: "If I fine-tune a small language model enough, can I turn it into an LLM?"
The honest answer is no, but you can get something better. Fine-tuning doesn't make a model bigger; the number of parameters stays the same. What it can do is make a small model match or even beat a large model on the one job you care about, while running on a laptop, a phone or a cheap server. That's not a consolation prize. It's exactly why companies from Google to NVIDIA are betting on small language models (SLMs) in 2026.
This guide shows you how to fine-tune a small language model, step by step, in plain English. You'll learn what SLMs are, how fine-tuning, LoRA, QLoRA and distillation work, when to use RAG instead, and what real companies and researchers have achieved. We also ran our own experiment: we pre-trained a small model on ByteMuni's articles, then fine-tuned it four different ways on a real task, so you can see the actual numbers for accuracy, trainable parameters and "catastrophic forgetting". Finally, there's tested code for fine-tuning a real open model with Hugging Face.
Short answer. You can't turn an SLM into an LLM, but you can make it perform like one on a specific task. Use fine-tuning (often with LoRA or QLoRA) to teach a skill, format or style; distillation to transfer a big model's ability into a small one; and RAG to give it facts it doesn't know. Most real systems combine them.
What is a small language model (SLM)?
A small language model is a language model compact enough to run on everyday hardware, such as a laptop, a phone or a single modest GPU. There's no official cut-off, but a 2025 NVIDIA Research paper defines an SLM as a model that "can fit onto a common consumer electronic device" and responds fast enough for one user, noting that most models under 10 billion parameters qualify. Hugging Face's overview describes SLMs as typically ranging from about 1 million to 10 billion parameters.
Large language models (LLMs), by contrast, run to hundreds of billions of parameters (or more) and usually live in data centres behind an API.
| Small language model (SLM) | Large language model (LLM) | |
|---|---|---|
| Typical size | Millions to about 10 billion parameters | Tens to hundreds of billions (or more) |
| Where it runs | Laptop, phone, single GPU, edge device | Data-centre GPU clusters, usually via API |
| Strengths | Fast, cheap, private, works offline, easy to fine-tune | Broad knowledge, strong reasoning across many topics |
| Weaknesses | Narrower knowledge, weaker on complex open-ended tasks | Expensive, slower, data leaves your device, harder to customise |
| Examples | Gemma 3 270M, Llama 3.2 1B, Qwen2.5 1.5B, SmolLM2 1.7B, Phi-3-mini 3.8B | GPT, Claude, Gemini (frontier versions) |
How small models are made small
Model makers use three main techniques, and students will see all three in job interviews:
Knowledge distillation: a small "student" model is trained to imitate a large "teacher" model's outputs.
Pruning: removing weights or whole parts of the network that contribute least.
Quantization: storing each weight with fewer bits, for example 4-bit integers instead of 16- or 32-bit floating-point numbers, which shrinks memory use dramatically.
And, increasingly, better data: Microsoft's Phi-3 report describes phi-3-mini, a 3.8-billion-parameter model trained on 3.3 trillion tokens, which scores 69% on MMLU and "rivals that of models such as Mixtral 8x7B and GPT-3.5," while being "small enough to be deployed on a phone."

Can fine-tuning turn an SLM into an LLM?
No, and it's worth understanding why, because it changes how you plan a project.
An LLM's broad knowledge comes from pre-training: next-token prediction on trillions of tokens, which stores general knowledge in billions of parameters. (ByteMuni's guide to how ChatGPT and Claude are built explains this stage in detail.) Fine-tuning works on top of that with a much smaller dataset. It's very good at teaching a skill, format, tone or narrow domain, but it can't pour general world knowledge into a model that doesn't have room for it.
Think of it like this. An SLM is a bright first-year student; an LLM is a professor who has read the whole library. Coaching (fine-tuning) can turn the student into the best person in the college at one thing, say, sorting customer complaints or answering questions about your hostel rules. It won't give them the professor's knowledge of everything.
So instead of "SLM to LLM", the useful goal is "SLM that beats an LLM on my task". There are four ways to get there:
| Approach | What it changes | Best for |
|---|---|---|
| Fine-tuning (full or LoRA/QLoRA) | The model's behaviour on a task | Classification, extraction, fixed formats, tone, domain language |
| Knowledge distillation | Trains a small model on a big model's outputs | Copying a skill such as reasoning or summarising into a cheaper model |
| RAG (retrieval-augmented generation) | What information the model sees at answer time | Fresh or private facts, documents, policies |
| Continued pre-training | Adds domain knowledge with raw text | Large amounts of specialist text (medical, legal, a regional language) |
Real-world proof: small fine-tuned models beating big ones
This isn't theory. Here's what researchers and companies have reported:
LoRA Land (Predibase, 2024): researchers fine-tuned 310 models (10 base models across 31 tasks) using 4-bit LoRA. They report that the fine-tuned models "outperform base models by 34 points and GPT-4 by 10 points on average" on those specific tasks, and they served 25 fine-tuned Mistral-7B adapters from a single 80 GB A100 GPU.
Google's Gemma 3 270M (August 2025): Google built a 270-million-parameter model specifically to be fine-tuned. It says the INT4-quantized model used just 0.75% of a Pixel 9 Pro's battery for 25 conversations. Google also highlights how Adaptive ML fine-tuned a Gemma 3 4B model for SK Telecom's multilingual content moderation, and the specialised model "exceeded the performance of much larger proprietary models" on that task.
DeepSeek-R1 distilled models (2025): DeepSeek distilled its large reasoning model into small models. Its 1.5-billion-parameter distilled model (based on Qwen2.5) scores 28.9% on AIME 2024 and 83.9% on MATH-500, and is described as outperforming GPT-4o (May 2024 version) on maths benchmarks.
QLoRA (2023): the QLoRA authors fine-tuned a 65-billion-parameter model on a single 48 GB GPU. Their Guanaco model reached 99.3% of ChatGPT's performance level on the Vicuna benchmark after 24 hours of fine-tuning on one GPU, though the authors themselves warn that chatbot benchmarks of that era weren't fully trustworthy.
NVIDIA Research (2025): the paper Small Language Models are the Future of Agentic AI argues that serving a 7B SLM is 10 to 30 times cheaper than a 70 to 175B LLM, and estimates that 40% to 70% of the LLM calls in three open-source agent frameworks could be handled by specialised SLMs.
The pattern is consistent: for a narrow, well-defined task, a small fine-tuned model can rival or beat a general giant, at a fraction of the cost.
What is fine-tuning? (and the main types)
Fine-tuning means taking a pre-trained model and training it further on a smaller, task-specific dataset, so its parameters adjust to your job. It's a form of transfer learning: the model reuses everything it learned during pre-training instead of starting from zero.
| Type | What's trained | Typical use |
|---|---|---|
| Full fine-tuning | Every parameter | Maximum adaptation when you have lots of data and GPU memory |
| Parameter-efficient fine-tuning (PEFT) | A small number of new or selected parameters (LoRA, QLoRA, adapters, prompt tuning) | Most student and startup projects; cheap and safe |
| Instruction tuning / supervised fine-tuning (SFT) | Example prompts paired with ideal responses | Teaching a model to follow instructions or a format |
| Domain adaptation | Model trained on text from one field | Legal, medical, finance, regional languages |
| Preference tuning (RLHF, DPO) | Model learns which answers people prefer | Making answers more helpful, polite or safe |
A common confusion: some tutorials list few-shot learning as a type of fine-tuning. It isn't. Few-shot prompting puts examples in the prompt and changes no weights at all. It's often the right first step, but it's prompting, not training.
How LoRA works (the trick that made fine-tuning cheap)
Full fine-tuning updates every weight in the model, which needs a lot of GPU memory, and you end up with a full copy of the model for every task.
LoRA (Low-Rank Adaptation), published by Microsoft researchers in 2021, keeps the original weights frozen and adds two small matrices, A and B, next to selected weight matrices. Their product is a small "correction" added to the original output:
output = W·x + (alpha / r) · B·(A·x)
^frozen ^small trainable correction (rank r)
If a weight matrix is 4,096 × 4,096 (about 16.8 million numbers), a rank-8 LoRA adds just 8 × 4,096 + 4,096 × 8 = 65,536 trainable numbers, about 0.4% of the size. The LoRA paper reports that, for GPT-3 175B, LoRA can reduce trainable parameters "by 10,000 times" and GPU memory "by 3 times," with no extra delay at inference time, because the adapter can be merged back into the weights.
The bonus: a LoRA adapter is a small file. You can keep one base model and swap adapters for different tasks, which is exactly how LoRA Land served 25 models from one GPU.
QLoRA goes one step further: it loads the frozen base model in 4-bit precision and trains LoRA adapters on top. That's what lets students fine-tune multi-billion-parameter models on a single consumer or free cloud GPU.

Our experiment: we fine-tune a small language model four ways
To make this concrete, we ran a real experiment on a CPU, with no GPU.
The setup:
Pre-training our "SLM". We pre-trained a small GPT-style model (2,221,824 parameters) on 80% of the sentences from 12 ByteMuni articles. Validation perplexity fell to 89 in about 4.5 minutes.
The task. Classify a sentence as Cyber Security or AI/ML, using the category of the article it came from. That's the kind of job a news site, help desk or email router does every day.
The test. 197 sentences (50 Cyber, 147 AI) that the model never saw, in pre-training or fine-tuning.
Four methods, each run three times with different random seeds, using 32, 128 and all 810 labelled training sentences:
From scratch: the same model with random weights, no pre-training.
Linear probe: freeze the pre-trained model, train only a tiny classifier on top (386 parameters).
LoRA: freeze the model, add rank-4 LoRA adapters to the attention and feed-forward layers, plus the classifier.
Full fine-tuning: update every parameter.
Because the test set is three times more AI than Cyber, we report balanced accuracy (the average of the accuracy on each class). A lazy model that labels everything "AI" would score 75% plain accuracy but only 50% balanced accuracy.

The results
| Method | Parameters trained | Balanced accuracy, 32 examples | 128 examples | 810 examples |
|---|---|---|---|---|
| From scratch (no pre-training) | 2,222,210 (100%) | 54.6% | 65.5% | 81.5% |
| Linear probe | 386 (0.02%) | 68.4% | 76.4% | 81.1% |
| LoRA (rank 4) | 49,538 (2.2%) | 71.1% | 73.5% | 82.9% |
| Full fine-tuning | 2,222,210 (100%) | 67.8% | 74.3% | 82.7% |
Mean of three runs each. Differences of a point or two are within the run-to-run spread.
What we learned:
1. Pre-training matters most when labelled data is scarce. With only 32 labelled sentences, the model trained from scratch was barely better than a coin flip (54.6%), while every pre-trained method scored 68% to 71%. That's transfer learning in action: the pre-trained model already "knows" which words go together, so it needs far fewer examples to learn the task. With all 810 examples, the from-scratch model caught up, because our task is fairly easy (topic words such as "exploit" or "attention" give it away) and our tiny base model knew relatively little. With a real pre-trained SLM, which has seen trillions of tokens, the gap is usually much larger and lasts longer.
2. LoRA matched full fine-tuning while training 2.2% of the weights. At 810 examples, LoRA scored 82.9% against full fine-tuning's 82.7%. That's the same pattern the LoRA and LoRA Land papers report at much larger scale, and it's why LoRA is the default choice in 2026.
3. Even 386 parameters can go a long way. The linear probe, which trains only a tiny classifier on top of the frozen model, was the best method at 128 examples. It plateaued as data grew, because it can't change how the model represents text. A quick probe is a great first baseline.
4. Full fine-tuning changes the original model for good. LoRA doesn't. We measured the model's language-modelling perplexity on held-out text before and after fine-tuning (lower is better). Full fine-tuning on all 810 examples pushed it from 89.3 to about 114, so the model got worse at its original job. This is catastrophic forgetting. With the LoRA adapter switched on, perplexity rose too (to about 116), because the adapter was trained for classification, not text. But with the adapter switched off, the model was exactly the original, at 89.3. That's LoRA's real superpower: the base model is never damaged, so one model can carry many swappable skills.
5. Results vary from run to run. The same method with a different random seed moved by up to 5 points with 32 examples. Always run more than once, and report the average and spread before you claim one method is better.
Our experiment's limits: our "SLM" has 2.2 million parameters (real SLMs have hundreds of millions to billions), the task has only two classes and the test set is 197 sentences. The trends match published research, but the exact numbers apply to this setup only.
Fine-tuning vs RAG vs prompting: which should you use?
Before you fine-tune anything, check whether you need to. Here's a practical way to decide:
| Your problem | Start with | Why |
|---|---|---|
| The model needs facts it doesn't know (your syllabus, policies, product catalogue) | RAG | Facts change; updating documents is easier than retraining |
| The model knows enough but answers in the wrong format or tone | Prompting, then fine-tuning | A few examples in the prompt may fix it; fine-tune if not |
| You need a narrow, repeatable task done cheaply at scale (classify, extract, route) | Fine-tune an SLM | Small, fast and accurate, with no per-call API cost |
| You need a big model's skill in a small, cheap model | Distillation | Train the SLM on the big model's high-quality outputs |
| You need fresh facts and a specialised style | RAG + fine-tuning | Most production systems combine both |
The rule of thumb many teams use: RAG for knowledge, fine-tuning for behaviour. ByteMuni's comparison of RAG, CAG and KAG covers the retrieval side in depth, and our generative AI with LangChain guide shows how to build a RAG app.
How to fine-tune a small language model: the pipeline, step by step
The CeADAR research group at University College Dublin, in its 2024 guide The Ultimate Guide to Fine-Tuning LLMs from Basics to Breakthroughs, describes a seven-stage fine-tuning pipeline. Here it is in student-friendly terms:

Stage 1: Prepare your dataset
This is where most projects succeed or fail. "Garbage in, garbage out" applies more strongly to fine-tuning than to almost anything else.
Format: for chat-style models, each example is a prompt and the ideal response. For classification, each example is a text and a label.
Quality over quantity: a few hundred to a few thousand clean, consistent, representative examples usually beat tens of thousands of noisy ones.
Split your data into training, validation and test sets before you start, and make sure there's no overlap. Overlap ("data leakage") makes results look far better than they really are.
Check balance. If 90% of your examples are one class, the model may learn to always guess it. Our experiment used class weights and balanced accuracy for exactly this reason.
Remove personal data you don't need, and make sure you have the right to use the data.
Stage 2: Choose your base model
Pick the smallest model that could plausibly do the job, then go up only if needed. Good 2025–2026 starting points include SmolLM2 (135M, 360M, 1.7B), Gemma 3 270M, Llama 3.2 1B, Qwen2.5 0.5B–1.5B and Phi-3-mini 3.8B. Choose an instruction-tuned ("instruct") version for chat-style tasks, check the licence (some require accepting terms) and check that it supports your language.
Stage 3: Set up your training environment
You don't need an expensive computer:
Free options: Google Colab or Kaggle notebooks with a free GPU are enough for LoRA on models up to roughly 1 to 3 billion parameters, and QLoRA can stretch further.
Libraries: Hugging Face
transformers,peft(LoRA),trl(supervised fine-tuning),datasetsand, for 4-bit QLoRA,bitsandbytes. Tools such as Unsloth and Axolotl wrap these for faster training.Rough memory guide: in 16-bit, each parameter needs 2 bytes just to load, so a 1B model needs about 2 GB before training overhead; in 4-bit, about 0.5 bytes per parameter. Full fine-tuning needs several times more memory than LoRA because it stores gradients and optimiser states for every weight.
Stage 4: Fine-tune (full, LoRA or QLoRA)
Start with LoRA. Typical starting settings are a rank r of 8 to 16, lora_alpha of 16 to 32, a learning rate around 1e-4 to 2e-4, and 1 to 3 epochs. Watch the validation loss: if training loss keeps falling while validation loss rises, you're overfitting, so stop earlier or add data.
Stage 5: Evaluate
Evaluate on your untouched test set, using metrics that fit the task: accuracy or F1 for classification, exact match for extraction, and human review or an LLM judge for open-ended answers. Always compare against baselines: the base model with a good prompt, and, if you can, a large model through an API. If fine-tuning doesn't beat a well-prompted base model, you don't need it.
Stage 6: Deploy
Merge the LoRA adapter into the base model (or serve adapters separately), optionally quantize it, and run it with tools such as Ollama, llama.cpp or vLLM, or on-device frameworks for phones.
Stage 7: Monitor and maintain
Real-world inputs drift. Log mistakes, collect new examples and retrain periodically. Keep your test set fixed so you can tell whether each new version is genuinely better.
Hands-on: fine-tune a small language model with Hugging Face and LoRA
Here's a complete, minimal recipe for supervised fine-tuning with LoRA using Hugging Face's TRL library. It uses SmolLM2-360M-Instruct, which is small enough for a free Colab GPU.
How we tested it: we checked this exact recipe end to end with TRL 1.17, PEFT 0.21 and Transformers 5.22 in November 2026, on a tiny local model of the same architecture type, because our workspace can't download models from the Hugging Face Hub. On your machine, it will download SmolLM2 (about 720 MB) on the first run.
1. Install the libraries
pip install -U transformers trl peft datasets accelerate
2. Prepare your data as a JSONL file, one example per line, in the prompt-completion format. Here's an IT help-desk router for a college:
{"prompt": [{"role": "user", "content": "My hostel Wi-Fi keeps disconnecting every 10 minutes."}], "completion": [{"role": "assistant", "content": "Category: Network | Priority: Medium"}]}
{"prompt": [{"role": "user", "content": "I can't log in to the exam portal and my exam starts in 30 minutes!"}], "completion": [{"role": "assistant", "content": "Category: Accounts | Priority: Urgent"}]}
3. Fine-tune with LoRA
from datasets import load_dataset
from peft import LoraConfig
from trl import SFTTrainer, SFTConfig
dataset = load_dataset("json", data_files={"train": "train.jsonl", "test": "test.jsonl"})
lora = LoraConfig(
r=16, lora_alpha=32, lora_dropout=0.05,
target_modules="all-linear", # add adapters to every linear layer
task_type="CAUSAL_LM",
)
args = SFTConfig(
output_dir="smollm2-helpdesk-lora",
num_train_epochs=3,
per_device_train_batch_size=8,
learning_rate=2e-4,
max_length=512,
eval_strategy="epoch",
logging_steps=10,
)
trainer = SFTTrainer(
model="HuggingFaceTB/SmolLM2-360M-Instruct",
args=args,
train_dataset=dataset["train"],
eval_dataset=dataset["test"],
peft_config=lora,
)
trainer.model.print_trainable_parameters() # shows how few weights LoRA trains
trainer.train()
trainer.save_model("smollm2-helpdesk-lora") # saves only the small adapter
With the prompt-completion format, TRL counts the loss only on the completion, so the model learns to produce answers rather than to repeat questions.
4. Use it
from transformers import pipeline
pipe = pipeline("text-generation", model="smollm2-helpdesk-lora")
msg = [{"role": "user", "content": "The projector in Lab 3 shows no signal."}]
print(pipe(msg, max_new_tokens=20)[0]["generated_text"][-1]["content"])
To make a standalone model, load the adapter with PEFT and call merge_and_unload(), then save it. For bigger models on a free GPU, add 4-bit loading (QLoRA) with bitsandbytes.
Common mistakes when you fine-tune a small language model
Fine-tuning when you needed RAG. If the problem is missing facts, fine-tuning on documents usually produces confident hallucinations. Use RAG for facts.
Too little or messy data. A few hundred clean examples beat thousands of inconsistent ones. Look at your data before training.
Overfitting. Too many epochs on a small dataset makes the model memorise. Watch validation loss and stop early.
Catastrophic forgetting. Full fine-tuning on a narrow task can damage general ability. Our experiment measured this: full fine-tuning raised the original model's perplexity from 89.3 to about 114, while LoRA left the base model untouched once the adapter was switched off. That makes LoRA the safer default.
Data leakage. If test examples (or near-duplicates) appear in training, your scores are fake. Split first, and deduplicate.
No baseline. Always compare against the base model with a good prompt. Sometimes prompting is enough.
Ignoring licences and privacy. Check the model's licence and don't train on personal data you don't have the right to use.
Student project ideas
These are realistic first projects with clear datasets you can build yourself:
| Project | Task type | Why an SLM fits |
|---|---|---|
| College help-desk ticket router | Classification | Fast, cheap, runs on the college server, student data stays private |
| Resume-to-JSON extractor for the placement cell | Structured extraction | Fixed output format is ideal for fine-tuning |
| Hindi, Tamil or Bengali FAQ answerer | Instruction tuning + RAG | Small multilingual base model plus your own documents |
| Phishing-SMS detector | Classification | Can run on a phone, offline |
| Code-review comment classifier | Classification | Fine-tune on your team's past review labels |
| Lecture-notes summariser | Summarisation (distillation) | Train on summaries generated and checked from a larger model |
To get interview-ready on these topics, see ByteMuni's generative AI interview questions for 2026 and our list of 40 AI terms every student should know.
Our take
The "SLM versus LLM" debate is really a question about using the right tool. A frontier LLM is an incredible generalist, but most real business tasks are narrow: sort this ticket, extract these fields, answer from these documents. For those, a fine-tuned small model is often faster, cheaper, more private and, as LoRA Land, Gemma and our own experiment show, just as accurate or better.
For students, this is also the most practical way into AI engineering. You can't train GPT on a laptop, but you can fine-tune a 360-million-parameter model on a free GPU this weekend, measure it honestly against a baseline and put a working project on your GitHub. That's exactly the kind of evidence interviewers look for in 2026.
Sources
Hugging Face community blog: Small Language Models (SLM): A Comprehensive Overview (February 2025)
Hu et al. (Microsoft): LoRA: Low-Rank Adaptation of Large Language Models (2021)
Predibase: LoRA Land: 310 Fine-tuned LLMs that Rival GPT-4 (2024)
NVIDIA Research: Small Language Models are the Future of Agentic AI (2025)
Google Developers Blog: Introducing Gemma 3 270M (August 14, 2025)
OpenRouter: DeepSeek R1 Distill Qwen 1.5B model card and benchmarks
Frequently asked questions
Can I turn a small language model into a large language model by fine-tuning?
No. Fine-tuning doesn't change a model's size or give it broad new knowledge. It can, however, make a small language model match or beat a large model on one specific task. To add facts, use RAG. To transfer a large model's skill, use knowledge distillation.
How do you fine-tune a small language model?
Prepare a clean dataset of examples and choose a small instruction-tuned base model. Add LoRA adapters with Hugging Face's PEFT library and train for one to three epochs with TRL's SFTTrainer. Evaluate on held-out data against a prompted baseline, then merge and deploy the model.
What is the difference between LoRA and QLoRA?
LoRA freezes the original model and trains small low-rank matrices added to selected layers, so only a tiny fraction of parameters change. QLoRA does the same but loads the frozen base model in 4-bit precision, cutting memory use further so larger models fit on a single consumer GPU.
How much data do I need to fine-tune an SLM?
It depends on the task. A few hundred to a few thousand high-quality, consistent examples is a common starting point for classification, extraction or formatting tasks, and quality matters more than quantity. In our experiment, with only 32 labelled examples, pre-trained models scored 68% to 71% balanced accuracy while a model trained from scratch managed 55%.
Can I fine-tune a small language model for free?
Yes. Free GPU notebooks such as Google Colab or Kaggle can fine-tune models of up to about 1 to 3 billion parameters with LoRA, and QLoRA can handle somewhat larger ones. Open models such as SmolLM2, Gemma 3 and Qwen2.5 are free to download, subject to their licences.
Should I use fine-tuning or RAG?
Use RAG when the model needs facts it doesn't know, such as your documents or recent information. Use fine-tuning when the model needs to behave differently, such as following a format, tone or narrow task. Many production systems combine both.



