Skip to content
Utlyze
Book a Call

Tiny models · Post one

The 47-hour day: training a small model to replace a big one

Three always-on loops kept one 27-billion-parameter model busy for 47.02 hours in a single day. What we measured, the small model we are training to take the job, and the four things that have to be true before it ships.

August 28, 2026local AI · model distillation · LoRA fine-tuning · Qwen3

James Brady · Claude Fable 5 · Claude Opus 5

  • 47.02 hModel time in one dayThree always-on loops, one model
  • 195.9%Of a 24-hour dayOversubscribed about two to one
  • 2,921Items got through58.0 seconds each on average
  • 71Attempts that hit the ceilingOf 84 tried; twelve succeeded

You keep the human work. We build the rest.

Every number below was read on 27 August 2026, Denver time, from files our own systems wrote for themselves. Nothing was started, stopped, or changed to produce it.

Figure 1

Three loops, one model, and a day that is not long enough

Model time against the length of a dayModel time in hours for three loops across the same 24-hour window: 22.18, 22.12 and 2.73, totalling 47.02, which is 195.9% of a 24-hour day.One day — 24 hPast the end of the day22.18 h22.12 h2.73 hhours of model time01224364847.02 hof model time in one day195.9%of a 24-hour day
  • Measured model time
  • Session fact capture
Each block is one loop's model time, laid end to end across a two-day axis. The day runs out where the dashed line falls; everything to the right of it is work the calendar has no room for.SourceUtlyze internal instrumentation for the 24-hour window 26 August 18:43 to 27 August 18:43 (America/Denver): per-loop request timers around each model call, the extraction impact baseline, the teacher comparative run, and the LoRA training run log.

The short version

We run a memory system for our AI fleet. It reads our working notes and session transcripts and turns them into a searchable map of facts and the connections between them. The reading is done by a large open-weight model on one machine in our Mac Studio fleet: 27.3 billion parameters, 17.74 GB on disk, 20.32 GB of graphics memory while it is loaded.

In the last 24 hours, three of our always-on loops kept that model busy for 47.02 hours.

A day has 24 hours. The three loops call the same model at the same time, so their busy time adds up past a calendar day. The model is oversubscribed about two to one. It got through 2,921 items in that window, averaging 58.0 seconds each.

The traffic jam has a price. Of the 84 attempts to save facts from a finished work session, 71 hit a two-minute ceiling and came back with nothing. Twelve succeeded. We spent 2.41 hours of model time in one day producing nothing, because the model was already busy with the other two loops.

When one expensive worker repeats the same narrow task thousands of times a day, you train a cheap worker to do it and keep the expensive one on the bench. That is what we are doing.

What we measured

Figure 2

What each loop took out of the day

Share of a 24-hour day held by each loopKnowledge extraction one at a time held 92.4% of the day across 1,410 items. Knowledge extraction in batches of ten held 92.1% across 1,427 items. Session fact capture held 11.4%, keeping 12 of 84 attempts.One full dayKnowledge extraction, one at a time1,410 items · 55.7 s mean, 24.0 s median92.4%Knowledge extraction, batches of ten1,427 items · 54.4 s mean, 48.1 s median92.1%Session fact capture12 kept of 84 tried · 91.6 s mean11.4%
  • Knowledge extraction
  • Session fact capture
The same three loops as shares of a single day. Two of them each held the model for most of the day on their own, which is why their totals add past one.SourceUtlyze internal instrumentation for the 24-hour window 26 August 18:43 to 27 August 18:43 (America/Denver): per-loop request timers around each model call, the extraction impact baseline, the teacher comparative run, and the LoRA training run log.

The 24-hour window is 26 August 18:43 to 27 August 18:43, Denver time.

LoopItems doneModel timeShare of the daySeconds per item
Knowledge extraction, one at a time1,41022.18 h92.4%55.7 mean, 24.0 median
Knowledge extraction, batches of ten1,42722.12 h92.1%54.4 mean, 48.1 median
Session fact capture12 kept of 84 tried2.73 h11.4%91.6 mean on the 12 that worked
Total2,92147.02 h195.9%58.0

The method

The big model has been doing this job for weeks, and it wrote down its work. Every extraction is a question and an answer: raw text in, structured result out. That log is a training set that already exists.

Two large models produced pairs for us, 25,270 between them. After removing malformed entries, over-length entries, and duplicates, 14,457 unique pairs remain. Most of the removal was overlap: 10,554 of the second model's pairs described work the first had already done. We split the rest into 13,657 for training, 400 for validation, and 400 held back as an exam the student never sees.

The student is Qwen3-1.7B, 4-bit, fine-tuned with LoRA. LoRA means we do not retrain the model. We train a small set of extra weights that sit alongside it and steer it: in this run 0.289% of the parameters, 4.98 million out of 1.72 billion. That is why this fits on a desk instead of a data centre.

The run is in progress. Validation loss started at 1.605 and reached 0.491 by iteration 300 of a planned 6,900. That means the model is learning the shape of the answer. Whether the answers are good enough to keep is a separate question, and the exam settles it.

The bet is that a small model is enough when the task is narrow and the output format is fixed. A 2026 study that LoRA-fine-tuned models from 270M to 8B parameters on merchant-information extraction found quality scales log-linearly with diminishing returns above roughly a billion parameters, with a 4B model landing within 0.35 F1 points of the 8B at half the size. We have not verified that on our own data. The exam will say if it is wrong for us.

Qwen3.5-4B is the next candidate. Both take the same 400-pair exam. The winner ships behind a canary gate, and the 27-billion-parameter model stays loaded as the fallback.

What that would save, and what has to be true first

Figure 3

Measured today, beside two projections

Model time per day, measured against two projectionsMeasured model time per day is 47.02 h, 195.9% of a day. Projected at five seconds an item it would be 4.06 h, 16.9% of a day, 11.59x less. Projected at ten seconds an item it would be 8.11 h, 33.8% of a day, 5.80x less.24 h — one day47.02 h195.9% of the dayMeasured today4.06 h16.9% of the dayStudent at 5 s an item11.59x less8.11 h33.8% of the dayStudent at 10 s an item5.80x less
  • Measured
  • Projected, on an unmeasured speed
The left column is measured. The two on the right are arithmetic from a per-item speed nobody has observed yet, which is why they are drawn in a different colour from the measurement they are compared with.SourceArithmetic projection printed in full in this note, computed from two measured inputs (2,921 items per day and 169,289 measured seconds per day) and a hypothetical per-item student speed the note states is unmeasured.

This is a projection. Here is the formula.

projected_seconds_per_day = items_per_day x student_seconds_per_item
saved_seconds_per_day     = measured_seconds_per_day - projected_seconds_per_day
ratio                     = measured / projected

Both inputs are measured: items_per_day = 2,921 and measured_seconds_per_day = 169,289.

Measured todayStudent at 5 s/itemStudent at 10 s/item
Model time per day47.02 h4.06 h8.11 h
Share of a 24-hour day195.9%16.9%33.8%
Freed per day—42.97 h38.91 h
Times less model time—11.59x5.80x

Four things have to be true for that table to hold. None is settled.

What we will report back

Post two is the actuals against the numbers above: uncontended serving speed on a free card, the 400-pair exam scored for both candidates, agreement with the teacher, and the measured model time per day after the switch, set beside the 4.06 and 8.11 hours projected here. If the student misses, we will publish the miss with the same numbers attached.

After that the method has two more places to go: the capture extraction that times out 71 times a day, and drift adjudication. It fits any loop where a large model repeats one narrow job thousands of times and writes down what it did.

The open-source part

We will release the pipeline: the harvest pattern that turns a running loop's logs into training pairs, the dataset builder that deduplicates and splits them, the training recipe, and the exam harness that scores a candidate against held-out teacher answers. You can run it on your own data.

The 14,457 pairs stay private. They are distilled from our internal operations and they encode how we work. Keeping them back costs you nothing, because the pairs were never the transferable part. Your teacher writes your pairs from your loops, on your machine, and the small model you get is shaped by your job rather than ours. The machinery is what travels, and we will link it from post two.

Contributors

  • James Brady

    Direction · Design direction · Review · Publish decision

  • Claude Fable 5AI

    Lead orchestration · Evidence assembly · Final edit

  • Claude Opus 5AI

    Measurement analysis · Drafting · Data figures and visual design · Publication

How this note was made

  • James BradySet the program in motion — train a small local model on the collected pairs — and demanded the honest answer on whether the data sufficed. Ordered the measurement study, the post, and its publication.
  • Claude Fable 5Audited the raw 25,270 pairs down to 14,457 unique, launched the first training run, dispatched and checked every agent below, and attached the published study citation.
  • Claude Opus 5Measured the baseline read-only — 47.02 hours of model time in a 24-hour day across 2,921 items, cross-checked two ways. Drafted the post and softened four claims it could not source. Conformed it to the site and published it through the merge queue with a 105-number integrity proof.