I got tired of AI tech sounding generic, so one Friday night I sat down at my home lab with one goal. By Sunday night I wanted a fine tuned open source model that actually sounded like me. Not a system prompt trick. Not a RAG pipeline pretending to be personalization. A real fine tuned model with my voice baked into the weights. I pulled it off in a single weekend on a single machine, and in this guide I want to walk you through the exact 48 hour timeline I used so you can fine tune a local LLM in a single weekend home lab too.

Most people will tell you fine tuning is a multi week research project. That is true if you are training a foundation model from scratch. It is not true for what almost every AI engineer actually needs, which is taking an existing open source model and teaching it your data, your voice, or your domain. With a LoRA adapter and the right tooling, you only retrain about half a percent to two percent of the parameters. That changes everything about the timeline. If you understand model quantization and how it speeds up local AI performance, you already have the mental model for why LoRA works so well on consumer hardware.

What does the Friday night setup actually look like?

Friday night is hardware and tooling. Budget two to three hours and no more. If you push past midnight on setup you have already lost the weekend.

The first decision is the GPU. I used an RTX 5090 for my run because Nvidia is still the clear leader for fine tuning thanks to CUDA. AMD is catching up with ROCm and is worth trying if you already have a recent card lying around, but mileage varies. Apple silicon I would avoid for fine tuning specifically. The MLX format does not have ports for most models and even when it does, training is slow. Running models on Apple silicon is great. Fine tuning them is a different story. For a deeper look at what your card can actually handle, the VRAM requirements guide for local AI coding breaks down the numbers honestly.

The second decision is your training framework. For a weekend run I recommend Unsloth if you are on a single GPU, because it gives you the fastest LoRA training with the lowest VRAM footprint. Axolotl is the other strong choice if you want more configuration control or plan to scale to multi GPU later. Pick one, do not try both in the same weekend. Install your CUDA drivers, set up a clean Python environment, pull down the base model you want to fine tune, and verify it loads and inferences correctly. If you cannot get a clean inference by midnight Friday, stop and fix that before going to bed. Do not start training on a broken setup.

How do you collect and engineer the dataset on Saturday morning?

Saturday morning is data. Budget four hours, from roughly 9 AM to 1 PM. This is the step everyone underestimates and it is the single biggest reason fine tuning projects fail.

In my case the raw input was every YouTube transcript from my channel. For your project it might be support logs, internal documentation, code review comments, or product copy. Whatever it is, you need enough of it. For an 8 billion parameter model you are looking at one to two million tokens of raw data minimum. Less than that and the LoRA adapter does not have enough signal to learn your style.

Then comes the painful part, dataset engineering. Raw transcripts are not training data. They are paragraphs of monologue, full of automatic transcription errors, weird spellings, and no structure. Language models do not learn from monologue, they learn from prompt and response pairs that match the chat format you will eventually use at inference time. So I built a small pipeline that runs a local language model over my cleaned transcripts and generates a relevant question for each chunk. If a snippet of mine says I use FastAPI to build Python solutions, the pipeline generates a question like what framework would you recommend for getting started with Python, and pairs it with my actual answer.

Cleaning matters more than people admit. If your transcripts have spelling errors, those errors get baked into the model. The model does not magically self correct bad input data. Garbage in, garbage out applies harder to fine tuning than to almost any other AI workflow.

Need a head start on the local AI tooling around this? Grab my free local AI starter projects to see how I structure data pipelines, RAG retrieval, and local model serving end to end.

What does Saturday afternoon LoRA training look like?

Saturday afternoon is training. Budget three to four hours of wall clock time, plus an hour of buffer for the inevitable parameter mistake.

LoRA stands for low rank adaptation. The short version is you are not retraining all the billions of parameters in the base model. You are training a tiny adapter that injects new behavior into specific layers, usually somewhere between half a percent and one and a half percent of the total parameter count. That is why this fits in a weekend. Full fine tuning of a 27 billion parameter model on consumer hardware is not realistic. LoRA on the same model absolutely is.

On my 5090, training a medium sized model took two to three hours of actual training time. The first run almost never works. You will set a learning rate too high, pick the wrong rank for the LoRA matrices, or forget to disable thinking mode on a reasoning model. Plan for one bad run. The second run usually lands. If you are training a 27 billion parameter model, expect to need at least 14 GB of VRAM and probably more depending on quantization. Do not try to offload parameters to system RAM as a workaround. People talk about it as a party trick, but it grinds training to a halt and often fails outright. You want your data and weights resident in dedicated GPU memory.

While the training run is going, do not sit there watching the loss curve. Walk away. Make dinner. The whole point of a weekend timeline is that you have other things planned for Saturday night.

How do you evaluate the model on Sunday morning?

Sunday morning is evaluation. Budget two hours.

This is the step almost every hobbyist skips and then regrets. You need a small evaluation set of prompts where you know what a good answer looks like. Run them against the base model and against your fine tuned model side by side. If the fine tuned version is not noticeably better on your target style or domain, something is wrong upstream. Almost always the problem is in dataset engineering, not in the training loop itself. I have had painful runs where I realized I had transformed transcripts into the wrong chat format, and the only way I caught it was through evaluation.

A good test for a persona fine tune is to ask a question the base model answers in a generic, overlong, philosophical way. When I asked the vanilla Qwen 3.5 model how I stay up to date with AI tools, it spent twelve seconds thinking and produced a poetic non answer about flow and stillness. My fine tuned version answered in two sentences, in my actual voice, describing my real workflow with AI agents and saved notes. That is the signal you want, brevity, voice, and direct answers that match how you actually communicate.

If evaluation fails, you have a choice. Either go back to dataset engineering and re run training Sunday afternoon, or accept what you have and ship it. Do not start a third run unless you have a clear hypothesis about what to fix.

How do you export to GGUF and deploy Sunday night?

Sunday night is export and deployment. Budget two hours.

The training output is a LoRA adapter that you merge into the base model weights. From there you export to GGUF, which is the format that Ollama, LM Studio, and most consumer local AI tooling actually run. GGUF is also where you apply final quantization, typically to four or five bit, so the model fits comfortably in your inference VRAM budget without losing meaningful quality.

Once you have a GGUF file, deployment is genuinely easy. Drop it into your Ollama models directory, register it with a Modelfile, and load it. My fine tuned 27 billion parameter Qwen 3.5 came out around 18 GB on disk in GGUF format and ran cleanly on the same machine I trained it on. If you want a smoother local serving setup, the Ollama local development guide covers how to run quantized models efficiently for day to day use. And if you eventually want to combine this fine tuned persona model with retrieval over fresh data like recent articles or changing facts, building an AI knowledge base walks through the RAG side of that pairing.

A practical pattern I like is to bake stable knowledge and voice into the fine tuned model and use RAG for anything that changes often. Laws, policies, or core domain knowledge that has been stable for years go into fine tuning. News, recent product changes, and live data go into retrieval. This combination outperforms either approach alone.

Why is this skill worth a weekend of your time?

Almost nobody knows how to fine tune properly. That is the honest truth. Most AI platforms that claim to train on your data are just injecting your information into a system prompt. That is fine for a lot of use cases, but it is not the same thing, and you can feel the difference the moment you talk to a real fine tuned model. It does not need elaborate prompting to behave correctly. The behavior is in the weights.

Learning this pipeline forces you to be a multi disciplinary AI engineer. You touch data engineering when you build the cleaning and pair generation pipeline. You touch ML engineering when you tune LoRA hyperparameters. You touch infrastructure when you wrangle CUDA, VRAM, and quantization. You touch product thinking when you decide what to fine tune versus what to leave to RAG. That combination is rare, and that is exactly why it is valuable.

If you want to keep going from here, the next step is watching the full walkthrough on YouTube where I show the actual home lab, the data pipeline, and the side by side outputs from my fine tuned model: https://www.youtube.com/watch?v=v7qMjy_RxOs. And if you want to learn alongside other AI engineers building local AI systems, working through real fine tuning and RAG projects together, join the community at https://aiengineer.community/join. One weekend is all it takes to stop being someone who reads about fine tuning and become someone who has actually shipped a fine tuned model.