Fact-check note: Reviewed September 4, 2026. This guide replaces universal hardware and gain claims with an evaluation-first, versioned workflow.

Fine-tuning updates model parameters using task or preference data. It is not the default fix for every limitation. Compare a frozen model, prompt and context changes, retrieval, deterministic tools, and fine-tuning on the same held-out evaluation. Use retrieval when knowledge must remain current, attributable, or access controlled; consider supervised fine-tuning for stable behavior, format, convention, or task patterns supported by representative examples.

1. Define the decision and baseline

Record the exact base model and license, task, users, prohibited uses, baseline, dataset rights, quality and safety thresholds, budget, deployment environment, rollback, and stopping rule. A lower training loss is not proof of better production behavior.

2. Build lawful, representative data

Before collection, assess authorization, terms, copyright and license, privacy and consent, confidentiality, retention and deletion, jurisdiction, and security. Scraping techniques do not make collection lawful. Define the target distribution, annotation guide, reviewer qualifications, disagreement handling, provenance, exclusions, and sensitive-data controls.

Split by the real generalization unit—such as user, document, organization, or time—before augmentation or near-duplicate generation. Deduplicate across splits and keep the test set inaccessible to training and tuning. Synthetic data can expand coverage but may reproduce model errors; label its provenance and evaluate it separately.

3. Choose a method

MethodWhat changesWhat to validate
Full fine-tuningAll selected parametersCompute, stability, regression, forgetting, serving footprint
LoRALow-rank adapters while base weights remain frozenTarget modules, rank, scaling, compatibility, merged versus separate serving
QLoRAAdapters trained through a frozen quantized baseQuantization, numerical stability, hardware support, quality, serving format
Optimized kernelsTraining computation, not the learning objectiveHardware/dtype support, numerical differences, determinism, fallback

4. Size and freeze the environment

Memory depends on parameter count, precision, optimizer state, trainable parameters, sequence length, batch and accumulation, checkpointing, and distributed strategy. Run a representative batch and record peak accelerator and host memory, throughput, stability, and projected cost. Pin model, dataset, tokenizer, framework, adapters, drivers, runtime, and container or lockfile.

5. Train reproducibly

  1. Normalize the schema and validate tokenization, truncation, masking, and labels.
  2. Set seeds where supported, but document nondeterministic operations rather than promising identical runs.
  3. Log configuration, code revision, data version, checkpoints, loss, learning rate, memory, runtime, and failures.
  4. Use validation data for model selection and reserve the test set for final assessment.
  5. Stop when prespecified quality, safety, cost, or overfitting criteria are breached.

6. Evaluate beyond average quality

Compare with the frozen baseline on representative, rare, multilingual, accessibility, adversarial, privacy, and high-consequence cases. Measure task success, factuality, formatting, calibration where meaningful, refusal behavior, memorization and leakage, subgroup performance, latency, cost, and human-review burden. Inspect failures; do not infer a unique cause from the shape of a loss curve.

7. Deploy as a governed change

Package the adapter with its exact base-model dependency and evaluation record. Use staged exposure, monitoring, rate and permission limits, fallback, rollback, incident response, and re-evaluation triggers for changes in data, model, prompt, tools, or population. Fine-tuning does not replace retrieval, validation, policy controls, or human review.

Design metrics with LLM evaluation metrics, manage releases through AI model management, and compare alternatives using prompt engineering.