Skip to main content
LLMix

LLM fine-tuning

Custom LLM fine-tuning beyond prompt engineering.

LLMix builds supervised adaptation as an engineering discipline: data-mixture design, continued pretraining where justified, supervised fine-tuning, LoRA and QLoRA, preference optimization, distillation, and held-out regression evaluation.

Fine-tuning is a model-development stage, not a complete product. LLMix combines data design, training, evaluation, and inference preparation so that the resulting behavior is reproducible and testable.

What fine-tuning can and cannot solve

Fine-tuning is the right tool when

  • The behavior must be consistent across thousands of inputs where prompting stays brittle
  • The capability requires internalized domain distinctions, formats, or judgment
  • Latency or cost budgets rule out long few-shot prompts on every request
  • A smaller specialized model should replace a larger general one for a scoped task
  • The model must follow a schema or policy reliably, not just usually

Fine-tuning is the wrong tool when

  • The missing ingredient is knowledge that changes daily (retrieval solves that)
  • No one can produce examples of the target behavior at acceptable quality
  • The task is solved by a clearer prompt and nobody has tried one yet
  • Success cannot be evaluated, so no result could be validated either way

The supervised adaptation toolkit

Method choice is conditional on the signal available and the deployment constraints, not on a universal ranking. These are the stages LLMix selects from and combines.

Continued and domain-adaptive pretraining

Next-token training on a domain corpus before any instruction data. Justified when the domain's language and structure are far from the base model's distribution, and skipped when they are not, because it is the most compute-hungry stage.

Supervised fine-tuning (SFT)

Training on demonstrations of the target behavior. The workhorse stage: it sets format, competence, and tone, and establishes the warm start that preference or reinforcement-learning stages build on.

LoRA and QLoRA

Low-Rank Adaptation trains small adapter matrices instead of all weights, and QLoRA does so over a quantized base. They cut memory and cost sharply and suit most single-capability adaptations. Full-parameter training remains justified when the change is deep or the adapter ceiling shows in evaluation.

Preference optimization after SFT

Direct Preference Optimization (DPO) and related objectives sharpen judgment where experts can rank outputs but not write ideal ones. A natural second stage once SFT competence exists.

Distillation and student models

Training a smaller model on the outputs or scores of a stronger teacher, with filtering so mistakes are not inherited. The standard route to serving-cost reduction for a scoped capability.

Method selection at a glance

Fine-tuning method selection matrix
MethodInput signalPrimary useCompute profileMain failure modesTypical output
CPT / DAPTRaw domain corpusClose a large domain gap before instruction dataHighest: full training over a corpusForgetting general ability, wasted spend when the gap was smallDomain-adapted base checkpoint
Full SFTDemonstrationsDeep behavior change, new formats and policiesHigh: all parametersOverfitting narrow data, regression without mixture balanceFull tuned checkpoint
LoRADemonstrationsScoped capability at low costLow: adapter weights onlyCapacity ceiling on deep changesAdapter weights (mergeable)
QLoRADemonstrationsLoRA-scale training on constrained hardwareLowest: quantized base + adaptersQuantization interactions, same ceiling as LoRAAdapter weights over quantized base
DPOChosen vs rejected pairsSharpen judgment after SFTModerate: policy + frozen referenceJudge bias, style collapsePreference-tuned checkpoint
DistillationTeacher outputs or scoresSmaller model for a scoped taskModerate: student-sized trainingInheriting teacher errors, coverage gapsCompact student model

Selection is conditional: no row dominates the others, and staged combinations (for example LoRA SFT followed by DPO) are the common case. The comparison guide covers the staging logic in depth: SFT vs DPO vs GRPO.

Dataset mixture, provenance, and contamination

Most fine-tuning outcomes are decided by the dataset before the first training step. LLMix treats data work as the primary engineering surface.

  • Mixture design: target-task data balanced against general data so the model gains the capability without losing its baseline behavior
  • Provenance manifests: where every example came from, its license basis, and its transformation history
  • Quality gates: deduplication, agreement checks on labels, and filtering of synthetic data by verifiable criteria
  • Contamination control: held-out and evaluation sets built from independent sources, checked for overlap against the training mixture

A concrete example of the quality bar: for a structured-analysis capability, near-duplicate demonstrations with conflicting labels are worse than fewer examples, because the loss averages the conflict into confident noise. LLMix adjudicates conflicts before training rather than hoping scale washes them out.

Evaluation and regression gates

Every program defines held-out capability evaluation and a regression suite over general behavior before training starts. A tuned model ships only when the capability gain is shown on held-out data and the regression suite shows no unacceptable loss elsewhere. Training-set performance is never the acceptance criterion.

Inference templates, tokenizers, and serving

A checkpoint that works in the trainer and fails in production is a common and avoidable outcome. Programs include the serving side: chat-template and tokenizer consistency between training and inference, adapter merging or deployment as adapters, quantization where scoped, and conversion for the target serving stack with a final evaluation pass on the served artifact itself.

When fine-tuning is not enough

Some capabilities need more than supervised signal: tool use under consequences, long-horizon behavior, or objectives only checkable by execution. Programs then extend from SFT into preference optimization and online reinforcement learning inside executable environments. That path is the complete post-training program, and it reuses everything the fine-tuning stage produced.

Explore the complete post-training program

What a fine-tuning engagement ships

  • Tuned checkpoint or adapters, with tokenizer and template files
  • Versioned datasets with mixture and provenance manifests
  • Training configurations and experiment lineage
  • Held-out capability evaluation and regression report
  • Serving conversion and a model card with known limitations

Fine-tuning questions, answered directly

Scope the fine-tune around one capability.