Every few months, someone walks into a conversation with us asking how much it would cost to "train their own model". It is a fair question, and the honest answer surprises people: for almost every Nigerian team, the realistic, achievable goal is not training a model from scratch at all. It is taking a capable open model that already exists and teaching it your specific task, your data, your tone. That is a much smaller, much cheaper, and genuinely doable project — and it is what this guide is really about.
Training a foundation model from nothing — the kind of thing that produces a base 7B or 13B model in the first place — needs enormous clusters of GPUs running for weeks, and budgets that simply do not make sense for a local business. So we set that aside entirely. What we are doing instead is fine-tuning: adapting an existing open model to your needs. If you want the hardware-first version of this story, our guide on fine-tuning small LLMs locally in Nigeria pairs well with this one, and the deeper mechanics of how the training actually works live in our LoRA and QLoRA deep dive.
Setting Expectations Before You Spend a Naira
The single most important thing to internalise is the difference between training and fine-tuning, because it changes everything about budget and scope.
- Training from scratch — building a model's knowledge from zero. Needs huge multi-GPU clusters, months of compute, and a research team. Not realistic locally, and almost never necessary.
- Fine-tuning — taking an open model that already understands language and nudging it towards your task: your customer-support style, your product catalogue, your internal documents. Doable on a single good workstation.
When a Nigerian business says it wants to "train a small model", what it almost always wants — and what it should want — is the second thing. A well fine-tuned 7B model that knows your business cold is far more useful to you than a generic giant. The rest of this guide walks the pipeline as five clear stages. Read it once before you start so you know where the real work hides.
Stage 1: The Dataset — The Make-or-Break Part
If there is one place teams underestimate the effort, it is here. The quality and structure of your data matter more than your GPU, your framework, and your hyperparameters combined. A small, clean, well-targeted dataset will beat a large, messy one every single time. Most of a successful fine-tuning project is, frankly, data work — and the good news is that this stage barely touches a GPU at all.
Collecting and preparing the data is ordinary workstation work: CPU, RAM and storage, the sort of thing any decent office machine handles. The discipline is what counts.
- Collect — gather real examples of the task you want the model to do: support tickets and their resolutions, documents and their summaries, questions and good answers.
- Clean — strip out noise, fix encoding mess, remove anything broken or irrelevant. Garbage in, garbage out is not a cliché here, it is the law.
- De-duplicate — repeated examples quietly skew the model towards whatever is over-represented. Remove near-duplicates.
- Format — turn everything into consistent input-output examples: a prompt and the response you want the model to learn. Consistency of format matters as much as content.
- Hold some back — set aside a test set the model never sees during training. Without it, you cannot honestly tell whether you improved anything.
A few hundred to a few thousand clean, well-formatted examples is often plenty for a focused task. Resist the urge to chase volume. The team that spends three weeks on data and three hours on training usually wins; the team that does the reverse usually starts over.
Stage 2: The Hardware
With a dataset in hand, the hardware question becomes refreshingly simple. For fine-tuning a 7B model with QLoRA — the memory-efficient method most local teams use — a single 24GB GPU is the sweet spot. A used RTX 3090 or RTX 4090 sits right in that band and is the workhorse of choice. Our guide to how much GPU VRAM you need in 2026 explains why 24GB is the line that matters, and the used GPU market comparison covers the 3090-versus-4090 buying decision in Naira terms.
Scale up from there and the choices branch:
- Single 24GB card — fine-tunes a 7B model with QLoRA comfortably. The realistic starting point for most teams.
- Larger or faster runs — bigger models, or faster turnaround, push you towards multi-GPU workstations or short-term cloud GPU rental.
- The buy-versus-rent decision — if you will fine-tune occasionally, renting cloud compute for the run can be cheaper than owning. If you fine-tune regularly and value keeping data in-house, owning a workstation pays for itself.
That last point deserves real thought rather than a reflex, and we weighed it properly in on-premise AI compute versus cloud for Nigerian businesses. For a team building a dedicated rig, the AI training workstation guide covers the full build around that 24GB card.
Stage 3: The Training Run
This is the stage everyone pictures when they imagine "training", and it is genuinely the shortest part. You pick a tool, configure it, start it, and watch.
- Choose a framework — tools like Axolotl, Unsloth, or PEFT-based scripts handle the heavy lifting. They are built for exactly this and save you writing training loops by hand.
- Configure LoRA or QLoRA settings — set the adapter rank, learning rate, and number of passes over your data. Sensible defaults from the tool's documentation are a fine starting point.
- Run and monitor the loss — a falling loss curve means the model is learning. A flat or rising one means something is off in your data or settings.
- Save checkpoints — write the model's progress to disk at regular intervals, not just at the end.
A run takes hours rather than minutes or weeks — and this is where a uniquely Nigerian risk appears. A NEPA cut halfway through a six-hour run wastes the whole thing if you have nothing to fall back on. Two safeguards make this a non-issue: a UPS big enough to ride out short outages or shut down gracefully, and frequent checkpointing so a lost run resumes from the last saved point rather than from zero. Treat both as mandatory, not optional. Power, not compute, is the thing most likely to cost you a day's work here.
Stage 4: Evaluation
Now the held-out test set you wisely set aside earns its keep. Run your fine-tuned model against those unseen examples and ask two honest questions: did it actually get better at the target task, and did it break anything it used to do well? It is entirely possible to make a model brilliant at your task and useless at everything else — over-fitting is real, and the only way to catch it is to test.
When results disappoint, there is a strong instinct to start fiddling with hyperparameters. Resist it. In practice, dataset fixes beat hyperparameter tuning almost every time. If the model is confused, your examples are probably inconsistent or thin in the area where it struggles. Go back to Stage 1, improve the data, and run again. Iteration between data and evaluation is the loop that produces a genuinely good model.
Stage 5: Deployment
A trained model that sits on a hard drive helps no one. The final stage is serving it for real use. Pleasingly, what you produced is small: QLoRA fine-tuning yields a compact adapter that loads on top of the original base model rather than a whole new multi-gigabyte model. You keep the base model once and swap lightweight adapters as needed.
- Serve locally with an inference engine — load the base model plus your adapter behind a fast serving layer. Our vLLM serving hardware guide covers doing this for multiple users at once.
- Expose it as an internal API — so your applications and team call the model over your own network, keeping every request and every piece of data inside the building.
That in-house serving point is not a footnote. For many Nigerian businesses, the whole reason to fine-tune locally is privacy — customer data, internal documents and proprietary processes never leave your premises. Owning the dataset, the training and the deployment end to end is the privacy story, and it is a strong one.
Frequently Asked Questions
Do I really need a 24GB GPU, or can I start smaller? For QLoRA fine-tuning of a 7B model, 24GB is the comfortable, reliable line, which is why the used RTX 3090 and 4090 are the standard recommendation. You can experiment on less for very small models, but 24GB saves you from constant memory headaches and is the figure to plan around.
How long does a fine-tuning run actually take? It depends on your dataset size, model and settings, so we will not quote a fixed number that would mislead you. The useful framing is hours, not minutes and not weeks — long enough that a power cut mid-run is a real risk, which is exactly why a UPS and frequent checkpointing matter.
My fine-tuned model is not better than the original. What now? Nine times out of ten the answer is in your data, not your hyperparameters. Check your examples for inconsistency, duplication or gaps in the area where the model struggles, fix the dataset, and run again. Dataset work is where the real gains hide.
The One Thing to Remember
If you take away a single idea, let it be this: for a Nigerian team, fine-tuning a small model is genuinely achievable — and the dataset is the hard part, not the hardware. With one 24GB card, a clean and well-targeted dataset, a UPS to outlast NEPA, and a bit of patience, you can produce a model that knows your business better than any general-purpose giant ever will. The GPU is the easy decision. The data is where you earn the result.
If you are ready to build the workstation for it, our configurator lets you spec a 24GB training rig from the card outwards, and our team is happy to talk through the dataset, the buy-versus-rent question, and your deployment plan — just get in touch.