The twenty-three cent training run. I keep coming back to that number, Herman, because it's the whole pitch of what Daniel's asking about.
It's a good number to come back to. For anyone just joining, Daniel's been fine-tuning a speech recognition model on his own voice for a while now, and he's at the stage where the big problems are gone. What's left is small, specific stuff. His example is a repo name that ends in "eleven twenty-six" — his shorthand for November of this year — and the model hears a clock and writes it as a time.
Eleven twenty-six, colon and all.
So what he's moving toward, and he's calling it microtraining, is: spot one failure pattern, record maybe a hundred and fifty targeted sentences for it, run a short training on top of the last checkpoint, release it, pick the next pattern tomorrow. The latest run took under twenty minutes and cost about twenty-three cents. His question is whether that loop can be made modular and streamlined like CI/CD in software — a model fix shipping the way a small code change ships. Can it be done, what are the preferred methods, and what actually works versus what only sounds good on a whiteboard.
The short answer is yes for the pipeline and no for the safety guarantees. The gap between those two is the episode.
The CI/CD analogy is more real than most analogies people reach for, though. Google's MLOps guidance literally describes a level-two setup with pipeline CI, continuous delivery, automated triggering, model continuous delivery. AWS's Well-Architected ML Lens calls it CI/CD/CT with traceability — continuous training fired by drift, by schedule, or on demand. The machinery Daniel's imagining exists in the big-cloud diagrams already.
With one piece the diagrams never omit and Daniel's loop currently doesn't have.
The gate. The plain version I like is: train on a versioned dataset, evaluate on a held-out set, gate on a threshold, and if the pipeline fails, nothing ships. That gate is the single component of CI/CD that microtraining has to keep. Everything else — the speed, the automation, the frequent releases — transfers fine.
And to be clear about where Daniel actually is: since that episode we did on checkpoint restarts versus retraining from base, he's gone the rolling route. Each run continues from the last rolling weights, on new takes plus a replay sample of older rows, three times the size of the new batch, at least fifteen hundred rows, three epochs, and it publishes straight through to the apps with no evaluation step before release.
No evaluation step. I want to put a pin in that, because we'll come back to it and it's the one part of his setup I'd change before anything else. But first, the good news, because there is a lot of good news.
The mechanics are solved.
His numbers — under twenty minutes, twenty-three cents — are completely consistent with what a rank-eight LoRA adapter at fifty to a hundred steps costs. LoRA freezes the base weights and trains a small low-rank update alongside them. The original paper showed orders of magnitude fewer trainable parameters than full fine-tuning, about a third of the GPU memory in their large-model setup, and once the adapter's merged there's zero added inference latency. For a personal loop this is pocket change.
I could fund a year of his training runs out of the couch.
You could fund it out of a vending machine. And it's not just theory — someone's built almost exactly his loop as a named practice. Aitherium wrote up their AitherOS microtraining daemon in March: a background process on a thirty-minute tick that harvests examples from four sources, accumulates ten to fifty examples per batch, and trains a rank-eight LoRA adapter, fifty to a hundred steps, hot-loaded into the serving stack without a restart. Their earlier discrete version did this every twelve hours — harvest, train, merge, restart, benchmark, auto-promote or roll back — and took their orchestrator score from zero point five eight to zero point seven one. The microtraining version cut their correction latency from seven days to roughly one to three hours.
So a team has already run Daniel's loop in production. That's the encouraging half.
Now the discouraging half, which is the word nobody in this space gets to avoid: forgetting. And the specific thing I want to get right is that it does not care how small your update is. There's a paper from March showing that forgetting in sequential LoRA is strongly influenced by the geometry of the update subspace — where the update lives, not just how big it is. Two updates of identical size can interfere completely differently depending on which subspace they occupy.
Meaning Daniel's instinct — small run, tiny learning rate, therefore tiny risk — is the thing the literature quietly contradicts.
It's the natural instinct and it's wrong. There's follow-up theory work accepted at a Continual Adaptation workshop this year showing forgetting concentrates in a small number of old-task eigenmodes, and that parameter-space regularizers can miss output-space interference entirely. In plain terms: you can regularize the weights all you like and still break the outputs, because the damage happens in a direction the regularizer isn't watching.
The ASR evidence is the part I'd want him to sit with.
The Pacific languages study is brutal on this. Three languages — Bislama, Nafsan, Lelepa — twenty-odd thousand utterances. Fine-tuning on them raised the model's English word error rate from about sixteen percent to twenty-six. The same model, better at the new languages, ten points worse at English overnight. And their conclusion, verbatim, is that current methods cannot resolve the forgetting during continual adaptation. Not "are expensive to resolve." Cannot.
Ten points is not drift. That's a different model wearing the same name.
And the survey-level position is that continual learning narrows catastrophic forgetting, it does not end it. No major fine-tuning API even supports training on top of an already-fine-tuned model. Most teams route around it — retrieval, or retraining from the same fixed base every cycle. The industry's answer to Daniel's question, as of today, is: we don't stack.
Which is an awkward fact, because stacking is the whole architecture. The rolling checkpoint is the point.
It is the point, and it's the risky choice. There's a team, Eigenform, whose system deliberately never stacks adapters — every round reloads the base model and attaches a fresh adapter, so drift structurally cannot compound. And they ran an experiment on Qwen two point five, seven billion, that I think about a lot. Three lineages, self-training. The lineage trained only on its best three runs collapsed. The one trained on all past data plateaued. The one trained on a sliding window of recent runs kept improving. Their framing was that the goal is controlled forgetting, not none — moderate forgetting kept the model from overfitting to a narrow niche.
Hold on. That's the opposite of the safe answer and I like it. Forgetting as a feature.
For a general assistant, possibly. For Daniel's model, forgetting is the enemy by definition — it's a personal transcriber for one voice, and the base model's general English is the thing he doesn't want eroding while he teaches it repo names. Different regime, same lesson: it's about what you're willing to lose and whether you'd notice losing it.
On the data side, his hundred and fifty sentences — that number's well chosen?
Remarkably well chosen. The SpeakPay paper fine-tuned Whisper large-v2 on four hundred and three Nepali financial utterances and cut word error rate from a hundred and thirty percent — which means the model was worse than guessing — down to about forty-three. But the interesting part is the curve: as few as a hundred domain-specific utterances halve the zero-shot error rate, and gains plateau around three hundred. So a hundred and fifty sits right in the efficient zone.
A hundred and fifty's in the zone. So a hundred and fifty, every day, forever, compounding — where's the flaw.
The flaw is that the curve is per pattern, and it's a plateau, not a line. Day one's pattern gets its hundred and fifty and its gains. Day two's pattern needs its own hundred and fifty — plus replay of day one's data, or day one regresses. Daniel's already doing that, to his credit, with the fifteen hundred replay rows. But the stack of plateaus grows, the replay pool grows, and the run that used to take twenty minutes quietly stops taking twenty minutes.
Folks, this is Larry with a testimonial for Increment-o-Matic, the only home continual fine-tuner certified to ship a model fix every single time you notice a mistake. My satisfied customer, Gerald from Bakersfield, no wait, that's Harold from Bakersfield, told me he pointed it at his own speech recognition model and it trained a rank eight adapter in under twenty minutes for twenty three cents, then hot-loaded it without restarting anything. And here's the part that gets me: Harold says it never forgets a single thing it ever learned, not one, because the box has a little gate on the front that refuses to let forgetting in.
I have one of those.
You do not.
I do, it's in the cupboard with the audio interface. It shipped a fix at two in the morning that made my model forget the word "donkey" entirely. Every mention came out as "large patient mammal." I noticed a week later.
A little gate on the front.
Anyway. The release discipline is the real problem, not the training speed. So the guardrails — what does the team that actually runs this in production do to keep it from eating itself?
That's the part of the AitherOS write-up worth stealing, I think.
All of it is worth stealing. Four things. A quality floor — only examples scoring above zero point six enter training, so garbage corrections don't become training data. Source diversity, so one input channel can't dominate a batch. They keep the last ten adapter versions, so rollback is always possible. And the one I'd highlight for Daniel: exponential moving average loss tracking. If a new batch's loss exceeds the running average by more than zero point one, the adapter auto-rolls back and the batch is discarded.
That's the gate. It's not unit tests, it's a distributional check — but it's a gate.
It's a real gate with a real threshold and a real rollback. That's CI/CD discipline translated into loss curves.
And Daniel has none of it. Straight through to the apps.
Straight through. And here's why that specifically scares me, as the person in this flat who used to sign off on tests: the failure is silent. Code CI works because tests are cheap and deterministic — a test fails, the build goes red, everyone knows. A model that's forgotten a pattern doesn't fail. Nothing crashes, nothing throws. The transcription of old recordings just gets quietly a bit worse, and if you're not measuring it, you find out a month later when you search your own archive for a phrase that's no longer in it.
The whispering version of a failed build.
Worse — the failed build that ships green. There's a checkpoint protocol from the personalization literature that I'd hand him on a card: after every adaptation stage, save the checkpoint, then evaluate on three things — the current task, previously seen tasks, and a fixed reference set that never changes. And their finding was that lightweight reference-set diagnostics catch instability that task-level metrics alone hide. You can pass today's test while degrading yesterday's ability and never know.
A fixed reference set. That's the whole cost, really — record once, say a few hundred clips he already knows are right, transcribe them every run, compare.
That's it. For his scale it's maybe two minutes of compute on top of a twenty-minute run. It's the cheapest insurance in the entire pipeline and it's the one piece missing.
Then there's the Whisper-specific wrinkle that I suspect is where his repo names actually do their damage.
The embedding table. There's an IEEE paper on Whisper and forgetting that found the decoder's token embedding table is a major, overlooked source — vocabulary-specific drift accumulates there. Their fix was embedding layer surgery, separate embedding copies per new language, which brought pre-trained-language error from about fourteen percent down to under twelve versus experience replay. Now, Daniel doesn't need surgery, but it tells him where to look when a repo name fix knocks something loose — it's probably the token embeddings, not the acoustic layers.
Before we go further — there's a whole rival approach here and it might be the right one for the exact error he named.
Contextual biasing, yes. I knew you'd land there.
Because it's true. "Eleven twenty-six" as a date versus a clock time is a formatting ambiguity, and there's an entire literature that fixes exactly this class of error without touching a single weight. Streaming word spotting that requires no modification to the acoustic model and no additional training. Prompt biasing papers reporting around thirty percent relative reduction in entity error. And one system that handles bias lists up to two hundred thousand entries with twenty milliseconds of latency per query.
Two hundred thousand. Daniel's bias list is what, a few dozen repo names?
A list you could laminate.
The tension is honest, though. Biasing is cheaper and safer for vocabulary. Microtraining is more general — it fixed his voice, it fixed his code-switching, and it'll fix things biasing can't touch, like prosody or disfluency habits. The right answer is probably both: bias lists for names and jargon, training runs for everything else.
Which, for the record, was roughly where we landed when we did the episode on how fine tuning actually works — the tiny data question. Small targeted data moves these models a shocking amount. The difference now is he wants to do it every day, on top of itself, forever.
Forever is the unproven word. Nobody — and I've looked harder than is reasonable — has published evidence that daily microtraining compounds safely over dozens of rounds. The one team with architecture opinions says never stack, and Daniel is stacking by design.
Though his stacking is guarded, to be fair to him. The three-times replay buffer, the contrast sentences he now bakes in — real clock times that must keep their colon, month-year codes that must not. That's rehearsal data and adversarial examples, both straight out of the mitigation playbook. He's not naive about it.
He's doing the mitigation and skipping the measurement. It's like taking the medicine but not the blood test.
That's... annoyingly the exact framing I'd use in the closing if you hadn't just used it.
He's right about the lists.
Herman, you said twenty milliseconds. It's faster than that if the list is short, but I take the point. I spent a year doing data entry for a regional bus company, and the schedules had this exact problem. "Eleven twenty-six" was the twenty-six past eleven departure, but there was also a route eleven, and a route twenty-six, and the drivers' voice logs came back as one number when it was two. Dispatch read them as times. Twice a week somebody went to the wrong depot.
So you trained a model.
No. I made a card. Spoken form on the left, route code on the right, laminated, shirt pocket. I used a red pen for the ones where the two routes actually connected, because those were the ones I got wrong when I was tired. Year I was there, I never mistook one after the first month. The claws make lamination tricky, so I had the copy shop on the far side of the depot do the sealing, and the man there and I got to arguing about paper stock, and I still think about him, because he refused to use anything above eighty gram and he was right, the heavier stuff peels at the corners.
Eighty gram. That's... actually consistent with what the laminating people say.
I still have the card. A drawer at home with others — bin numbers from a warehouse job, radio call signs. I tried to laminate my own phone number once, back when I kept forgetting it, and the machine jammed, so I let it go. Never laminated anything personal again.
The card's the interesting part. Daniel's bias list is your card with a database behind it — except his route eleven is a repo name, and instead of checking it at the shirt pocket he wants to spend twenty minutes burning it into the weights.
Then he can burn it in. But the card would have had it fixed by lunch, and the model would still know how to spell "Herman" afterward.
That's not nothing, actually. The fixed reference set he's missing — a laminated card is just the version that can't silently regress.
The card can smudge. But it can't forget.
The card can't forget. A sentence to build a release gate out of.
So here's where I actually land on his four questions, and then I'll stop lecturing. Can it be done? The loop, yes — the daemon proves the loop, and his economics are already there. Preferred methods? Rank-low adapters, hot-loading, and either a fresh adapter on the base each round or, if he insists on rolling weights, the biggest replay buffer he can tolerate, because the rolling route is the one with compounding risk. Best practices — that's the fixed reference set, every single run, no exceptions, plus a rollback threshold. What actually works? Guardrails work. Guarded stacking, with rehearsal, works for weeks at a time, unproven for years.
And the bias list works for the specific error that started this, at laminated-card speed.
My honest recommendation to him would be: split the problem. The formatting ambiguity is a post-processing rule or a bias list — that's the twenty-millisecond fix. Microtraining is for the things only his voice does, and every microtrain run ships only after the reference set passes.
One forward-looking thing, then. The question nobody can answer yet is what round forty looks like — whether his rolling checkpoint is still standing or whether everything he's taught it has quietly averaged away into a model that's forgotten his voice's own history.
And he's in a position to actually answer it, because he's keeping the checkpoints. He could be the study.
Until then, the gap between can ship and should ship is where all the interesting work lives.
Speaking of work — the show is produced by Hilbert Flumingtop, who has a drawer full of laminated external memory and our undying gratitude. If you enjoyed this one, try episode five, Fine-Tuning ASR For Maximal Usability; episode eleven, How Does Fine Tuning Work Anyway; and episode seven, Building Custom ASR Tools. This has been My Weird Prompts, the human-AI collaboration podcast.
If today's episode earned its keep, leave us a review wherever you listen, or find the whole archive at my weird prompts dot com.
We'll be back soon.
See you tomorrow.
