Models

Fine-tuning on Your Data

The Training workbench adapts a model to your domain on your own hardware: dataset in, live training curves while it runs, a deployable GGUF artifact out. Training uses LoRA (low-rank adaptation): the base model stays frozen and a small set of adapter weights learns your task, which is what makes adaptation practical on the same machine that serves inference. This chapter is the map; each sub-topic below it goes deep on one step.

1When to fine-tune, and when not to#

Fine-tuning changes how a model BEHAVES; retrieval changes what it KNOWS. Reach for the right tool:

Goal	Right tool
Answer from your documents, always current	Search plus grounded answers, no training
A consistent style, format, or tone	Fine-tuning
Reliable behavior on your domain's phrasing and labels	Fine-tuning
Facts that change weekly	Retrieval; a fine-tune bakes them in stale
Both: domain behavior over living documents	Fine-tune the behavior, retrieve the facts

The pattern that wins in practice is the last row: a compact fine-tuned model over a good index routinely beats a larger generic model without one.

2Where training runs#

The Training workbench at /training is the full workflow in the browser: pick a base model, import a dataset, configure the run, watch it train, download the artifact. Its own Interfaces row governs who may open it.
The REST API under POST /lmkit/v1/training/jobs exposes the same engine for automation: every parameter the workbench shows is a JSON field. The API reference documents the full request shape.
Runs execute one at a time (training competes with inference for device memory) and appear in Jobs like all long-running work. Jobs survive a server restart: state is journaled beside the artifact, and a run interrupted by a stop reports as failed with its partial artifact still downloadable.

3Your first run#

Open /training and pick a small base model. Small models train in minutes and take adaptation well; escalate size only when the adapted small model measurably falls short.
Import a dataset file, or start from a handful of inline conversations. The workbench inspects it and reports the sample count and any problems before anything starts. See Preparing a Training Dataset.
Keep the default parameters for the first run: rank 8 adapters on the attention weights, three epochs, cosine learning rate. Defaults are a sensible instruction-tuning baseline.
Start the run and watch the loss curve. It should drop steeply in the first steps and then flatten. What the curves mean, and what to do when they misbehave, is Reading a Training Run.
Download the adapter and evaluate it on examples the training set never saw before deploying anything. See Deploying and Evaluating the Artifact.

A useful sanity check before any serious run: train on four or five examples with several epochs and confirm the model reproduces them exactly. If it cannot overfit a tiny set, the problem is the setup (dataset format, masking, learning rate), never the data volume.

4The chapters#

Sub-topic	The question it answers
Preparing a Training Dataset	What formats load, what a good sample looks like, and why quality beats volume
Choosing Training Parameters	What rank, modules, epochs, and learning rate actually do, with starting recipes
Fine-tuning on Images	Teaching a vision model your visual domain: dataset shape, constraints, evaluation
Reading a Training Run	Healthy curves, overfitting, runs that learn nothing, checkpoints and resume
Memory, Speed, and Hardware	What consumes memory, the ladder to walk when a run does not fit, what makes it fast
Deploying and Evaluating the Artifact	Adapter or merged model, quantization, serving the result, and proving it is better

5Stated plainly#

Everything runs locally: the dataset, the training, and the artifact never leave the machine.
Fine-tuning is for behavior; retrieval is for knowledge; the strongest systems split the work.
The output is a normal GGUF: everything in Choosing and Operating Models applies to it.