What does an LLM fine-tuning service include?
Fine-tuning is useful when you can name the behavior you want to change and measure it on examples the model has not trained on. I start with a base-model result on that held-out set. Then I prepare the training data, run a small adapter-based fine-tune, and compare the new model with the baseline. If the result does not improve the task, the training run is not a success just because its loss went down.
The handoff is a runnable model and the information needed to reproduce it: the base model, training configuration, data format, evaluation method, chat template and inference settings. Deployment can use an adapter, a merged model or a GGUF, depending on where you plan to run it.
| Stage | What we check or deliver |
|---|---|
| Scope | The task, a success measure, usable data and the target hardware |
| Baseline | The open model's answers on a held-out set before training |
| Training | A documented LoRA or QLoRA run, with the dataset split and configuration |
| Evaluation | The same held-out questions, plus manual review of failure cases |
| Deployment | Model files, tokenizer and chat template tested in the intended runtime |
Can I inspect a real open-model fine-tuning example?
I fine-tuned gpt-oss-20b and Qwen3-14B for STEM questions with Unsloth and QLoRA. The published dataset split was 4,260 training examples and 474 evaluation examples. The gpt-oss run used LoRA rank 32, alpha 64, a 1e-4 learning rate and an RTX 5090 with 32 GB of VRAM. Its recorded evaluation loss was 0.837. That loss describes the held-out training objective; it is not an accuracy score or a claim that the model beats its base version on every task.
The models are available as LoRA adapters, merged 16-bit weights and GGUF files. That is the delivery choice in concrete form:
| Format | Use it when | gpt-oss-20b example |
|---|---|---|
| LoRA adapter | You already have the base model and want a small training artifact | About 61 MB |
| Merged weights | You want a self-contained model for a serving stack such as Transformers or vLLM | About 41 GB |
| GGUF | You want a local model for Ollama or llama.cpp | 15.8 GB at Q4_K_M |
The full gpt-oss walkthrough shows the training settings, export calls and Ollama Modelfile. It also documents a practical failure: a fine-tuned model can load successfully and still produce bad output when its inference chat template does not match training.
These public artifacts let you inspect my work before a call: the dataset split and settings, the released model formats, and the deployment failure I found. For a custom LLM fine-tuning project, I would define the success test around your task and data rather than reuse a result from this STEM example.
What data do I need to scope your fine-tuning project?
Send a small, representative sample of inputs and the answers you expect. Include difficult examples, the output format, whether the data may be used for training, and the hardware or API you want to serve from. If you already have a baseline model, send its failures too. I can then recommend whether to fine-tune, use retrieval, or first improve the prompt and evaluation set.
There is no useful fixed dataset size, schedule or price before that review. A clean set of examples with a clear pass condition is more valuable than a large pile of unexamined text. The quote should cover data work, evaluation and deployment testing as well as GPU time.
How will the fine-tuned LLM run after training?
An adapter checkpoint is small because it does not include the base weights. A GGUF is much larger because it is a runnable model. Export format also changes the deployment path: a model that answers correctly in the training notebook still needs to be checked in its final runtime. I test the tokenizer, chat template, stop tokens and a sample of expected outputs after export. Unsloth's GGUF guide documents why template mismatches can produce repeated or incoherent answers.
Frequently asked questions
When should I fine-tune an LLM instead of using RAG?
Fine-tuning changes how a model responds to a task; retrieval gives it current or private facts at request time. If the main problem is missing knowledge in your documents, start with retrieval. If the problem is a repeatable output format, domain-specific behavior or a task the base model handles poorly, test a fine-tune against a held-out set.
What data do you need to fine-tune a model?
Start with representative input-output examples, permission to use them, and a separate set that can measure the result. The required number depends on the task and the quality of the examples; I review a sample before recommending a model or training run.
Can the fine-tuned model run locally?
Often. I have published LoRA adapters, merged models and GGUF files for gpt-oss-20b and Qwen3-14B. The right format depends on the hardware and serving stack; a GGUF is useful for Ollama or llama.cpp, while a merged model may fit a Transformers or vLLM deployment.
How much does LLM fine-tuning cost?
I quote after seeing the task, a data sample, the evaluation target and the deployment constraints. Data preparation and testing can take more work than the training run, so a model name alone is not enough for a useful estimate.
How long does it take to fine-tune a custom LLM?
The training run is only one part of the schedule. I need to review the examples, define a held-out evaluation set, run a baseline, train, inspect failures and test the exported model in its final runtime. I can estimate the timeline after seeing the data and deployment target.
Will a fine-tuned LLM be more accurate than the base model?
Only a comparison on examples the model did not train on can show that for your task. I record the base-model result first and evaluate the fine-tuned model on the same held-out set. A lower training loss alone does not prove better answers.