Technology · Discipline

LLM fine-tuning

A full-parameter fine-tune of a 0.6B model on registry-generated data, finished in minutes, measured on a frozen set against a baseline that tied it.

Capabilities modelFull-parameter fine-tune of a 0.6B dense modelOne NVIDIA Blackwell GPU
From a panel of authors to one small model
panel members write intents for every toolone quarantined
42,000tokens of tool schema it took off every turn
  • 17.6 GiBpeak memory for the recipe on one GPU
  • 12cells in the ladder across 0.36B, 0.6B and 1.7B models
  • 4model families on the authoring panel
  • 2–14 minfor one training run

A model rebuilt the way an index is

Capabilities model: my agents were carrying the whole tool schema on every turn. I wanted a small model that holds the tool catalog in its weights and answers one discovery call. Tools change weekly, so retraining had to take minutes. I chose a full-parameter fine-tune of a 0.6-billion-parameter open-weight base model over adapters, because at 0.6B a full fine-tune is fast enough that the usual case for adapters disappears. Because training takes minutes, I rebuild the model the way I rebuild an index.

New dataFine-tuneQuantize, byte-identical on re-runQuality gatesNew model
Calibration uses 512 seeded samples from the run's own training data, and the stop token is written into all four files that declare it at save time.

The stop token had silently been setting the length of the returned tool list. I also withdrew my earlier finding that the defect had no effect: that test had changed a file the server does not read stop tokens from.

Training data from many voices

The data comes from the tool registry. A panel of frontier and local models writes intents for every tool in four kinds. Each panel member gets a weighted share of every tool's quota for every kind, so no tool's data comes from a single voice.

RephrasedHard negativesMulti-toolBuried askMember 1
Member 2 · sandbox
Member 3
Member 4 · sandbox
Member 5
Member writes its share
Member that searched the workspace: now run from an empty sandbox with answer-only prompts
Shares illustrative. A token-level canary proves each constrained member is constrained before any of its output is used.

An authoring gate that polices its own authors

The authoring gate is the part I would reuse anywhere. A panel model can satisfy every structural check and still defeat the panel by templating instead of writing. Vocabulary variety is measured as type-token ratio against the registry's human-written seed intents at equal sample sizes, because type-token ratio falls with length alone and an absolute floor punishes the member that wrote the most.

Most a member may do
Name the tool it was told not to15%Echo the seed phrasing10%Duplicate its own queries5%
The member it caught · entries

336 entries quarantined. It handed back its brief verbatim and wrote "Perform the action." across tools, passing every structural check.

Stubs and vocabulary variety are scored too; members under 12 examples are reported, not judged; any failure refuses the whole run.

A frozen split with no leakage

Leakage is defined on the training and evaluation pair, using the same similarity machinery that flags "cold" queries, and pruning repeats until nothing changes. The training system prompt is the same text the server sends, so the model trains on exactly the context it is served with.

Corpus · 2,909 examples
2,784 training125 held out
Evaluation set · no overlap with the corpus 469 queries
Stratified by target set and kind; every tool in both halves, at least 61 training examples per tool.

A recipe chosen from a ladder

The recipe I settled on is learning rate 3.0e-5 for eight epochs on a cosine schedule with 3 percent warmup. It uses batch 8 with four-step gradient accumulation, AdamW (0.9, 0.95, weight decay 0.01), gradient clipping at 1.0, BF16 autocast over FP32 master weights and gradient checkpointing. I chose it from a ladder of model sizes and several epoch and learning-rate settings. The ladder showed that bringing up the serving engine for scoring cost more wall-clock time than training, which told me where turnaround time actually goes, and I kept its confounds visible: the 1.7B cell used a recipe tuned on 0.6B and BF16 master weights.

One training run · seconds
Three epochs149 sEight epochs812 s
Recall at 5 · 469 queries over 42 tools
Fine-tuned model0.955Best classical baseline0.949

The strongest classical baseline tied the model, and I report the tie.

This is single-GPU full fine-tuning from 0.36B to 1.7B parameters, with no preference tuning and no multi-node training. The full account is in A hundred tokens instead of forty-two thousand and The baseline that tied us.