I trained a small model on fourteen short poems until it wrote like the person who wrote them. Every step is documented. The first six parts are how a language model actually works, for a reader who is new to all of it. The last five are the project: the data, the run, the code, and an honest look at whether it beat a well-written prompt.
1 September 2026·11 parts·114 min in total·aihomelabtraining
I wanted a model that writes the way I write. Not one that knows what I know, which is a different problem with a different answer, but one that produces a paragraph I would have produced: the same cadence, the same habit of conceding the point before somebody else makes it, and the same dryness that never quite becomes a joke.
That is a narrower want than it sounds. Narrowing it is most of the work. A model that sounds like me is one whose output I would not have to rewrite. I have spent enough evenings turning competent, weightless prose into something with a pulse to know that the rewriting is the expensive part.
Voice is a real thing, and it is separable from content. Sentence length, where the commas fall, whether it hedges, how it opens, and what it refuses to claim. Those recur in everything a person writes, independent of the subject, and a property that recurs in every example is exactly what training finds.
What I want is form, which is the half fine-tuning is good at. That is why this is tractable on a card I own rather than a research project. Pointed at knowledge, a small fine-tune produces something fluent, confident, and wrong. Pointed at voice, it is cheap, fast, and startlingly effective, and part seven is the argument for why those two outcomes are so far apart.
I did not train it on my own writing, and that is deliberate. A subtle voice makes the evaluation an argument I would win against myself, conducted by the person least able to be objective about it. So the corpus is fourteen poems by a writer who does not exist, in rhyming couplets, because a rhyme is checkable from across the room and my own cadence is not.
The question is not whether it picks up the surface. The rhyme was always going to transfer. Whether it picks up the habit underneath, opening on its own mistake and closing on what will bite you next, is a property of the argument rather than of the sentences, and nobody tells it to do that. The last part is built around that question.
Every part is written to be read in order, and the first six have no commands in them at all. If you already know how a transformer works, start at part seven. If you write software and remember your linear algebra, skip part two.
The corpus is fourteen short poems by an invented writer, and everything needed to train a model on them is in a repository on GitHub: the poems, the two JSONL files, the three Python scripts that take you from an empty directory to a trained adapter, a requirements file, and the Axolotl config if you would rather drive the run from YAML. Everything here is reproducible against the same bytes I used.
The barrier is lower than it looks, and it is not the mathematics. It is that all of this happens on a Linux box with a graphics card in it, and everything hard about that is ordinary system administration and has nothing to do with models.
You need to be comfortable at a Linux command line. Installing packages, making a virtual environment, editing a file over ssh, leaving a job running in tmux. Part ten writes out every command it used, so you can follow it literally, but a command that fails does so in your environment and not in mine, and reading that error is the part nobody can write down for you.
You need enough Python to read it, not to write it. The three scripts come to a little over three hundred lines between them, and most of that is configuration expressed as function arguments rather than logic. Part nine reads all of it line by line, so what is being asked of you is following an argument list, not writing a training loop.
Half-remembered linear algebra is enough, and part two supplies the rest. What you actually need is to read a shape like [5, 4096] and know what multiplying two grids does. That is the whole of it, the refresher takes six minutes, and nothing later in the series asks for more than that.
You need one NVIDIA card, and it does not have to be a big one. The main track uses about 11 GB and the smaller one about 6 GB, which is a laptop GPU or a free hosted notebook. You do not need the machine I have. If you have no NVIDIA card at all, a rented hour on a cloud GPU is the cheaper path than fighting the toolchain onto hardware that will not take it.
No machine learning background is assumed anywhere in the series. Parts one to six build it from nothing, starting at what a token is. If you have used a chat model and wondered what was underneath it, that is the level this starts from.
Beyond that refresher, no mathematics is needed. No calculus, no statistics, no derivations. Part two names what it leaves out, and part one names the three things it describes rather than derives, which is a shorter list than people expect and none of it changes a decision made later.
The whole machine end to end, in one figure: text becomes tokens, tokens become vectors, a stack of identical blocks transforms them, and the top produces a probability for every possible next word. Start here if any of that is new. Everything after it is one stage of this part, enlarged.
A short refresher: how to read a shape like [5, 4096], one worked example small enough to check by hand, and how to count a model's parameters yourself. Not a mathematics course and it says so. Skip it if you write software and remember your linear algebra.
The stage nobody thinks about, which explains more of the famous stupid failures than anything else in the architecture. Where the vocabulary came from, why rare words shatter into pieces, and the special tokens that a fine-tune gets wrong at its peril.
The only place in the entire architecture where one word can affect another, and therefore the mechanism behind everything context does. The part worth slowing down for. Also why long prompts cost what they do, and what that implies for how you write one.
What surrounds attention: the other half of a block, and two pieces of plumbing that look like footnotes and are the reason a model this deep can be trained at all. Then the cache that actually fills your graphics card, and why a model that loaded fine dies an hour later.
The top of the stack, where a vector becomes an actual word. Softmax, the sampling settings that live outside the model and change its character more than people expect, and how generation knows to stop, which is also one of the commonest ways a fine-tune breaks.
It is real training and it moves the weights permanently. What it moves reliably is form. What it moves badly is fact, and getting those backwards produces a system that is fluent, confident, and wrong. Also the two free things to try first, one of which may be enough.
The part that decides the outcome, and the one most likely to be skipped because none of it looks like machine learning. Turning fourteen poems into a training file, why six are held back, and the hardest question here: what to write on the prompt side when your source material is answers with the questions missing.
The three Python files, read properly: what each block does, which lines decide whether it fits on your card, and which four settings are worth touching. Everything in them is short enough to read, which is the point of not using a framework.
Every command, from a bare virtual machine to a saved adapter. On a single GPU. What the loss curve is and is not telling you, and the four things that went wrong when I did it. A second track runs on about 6 GB if you do not have a big card.
Merging the adapter, serving it, and testing it against six poems it was never shown, compared against both the untouched model and a carefully prompted one. That last comparison is the one most write-ups quietly skip because it can make the whole exercise look unnecessary.