Model Training & Fine-Tuning

Adapt a model when adaptation is the right answer, and say when it is not

Fine-tuning teaches a model form, not facts; we baseline against prompting and retrieval first, then adapt only where a real gap survives.

  • Open-weight and frontier
  • Turkish, Arabic, low-resource
  • On-premise or your cloud
  1. Baseline frozen Serious prompt plus competent retrieval
  2. Pick the rung LoRA, full SFT, DPO or continued pre-train
  3. Build the dataset Dedup, decontaminate, licence, label
  4. Train Sharded, checkpointed, seeded, resumable
  5. Regression test Scored on the tasks you did not train on
Many engagements stop at the first two steps, and that is the cheapest outcome available.

Method

A weight change, not a knowledge transplant

If the complaint is that the model does not know last quarter's policy, retrieval is cheaper and easier to audit. If it will not hold your schema, your tone or your language, that is a weights problem. We settle which before a GPU hour is booked.

  • Frozen model baselined with prompting and retrieval
  • Adapt only where the gap survives on a held-out set
  • Every run ships a regression suite and a rollback point

Adaptation

The ladder, bottom rung first

Prompting, retrieval, LoRA, full fine-tuning, preference optimisation, continued pre-training. Cost and lock-in rise at each rung, so we stop at the first that clears your bar.

  • LoRA
  • QLoRA
  • full SFT
  • DPO / ORPO

Efficiency

<1%

Trainable parameters under a typical LoRA configuration

Memory

3–4×

Typical reduction from 4-bit QLoRA against bf16 full fine-tuning

Languages

Low-resource and domain languages

Turkish and Arabic are under-represented in most base models, and it shows in the tokenizer first: the same sentence can cost two to three times the tokens it does in English.

  • tokenizer ext
  • in-language corpora
  • native evals
  • morphology

Data

Data is the whole job

Most of an engagement is dataset work: licence review, near-duplicate removal, decontamination against every benchmark you will report, and agreement measured, not assumed.

  • MinHash dedup
  • decontam
  • provenance
  • IAA scoring

Training

  • PyTorch
  • FSDP
  • DeepSpeed ZeRO
  • Megatron-LM
  • TRL
  • Axolotl

Adaptation

  • LoRA
  • QLoRA
  • PEFT
  • DPO / ORPO
  • RLHF
  • Distillation

Data

  • MinHash dedup
  • Decontamination
  • DVC
  • HF Datasets
  • SentencePiece

Evaluation

  • lm-eval-harness
  • Held-out benchmarks
  • Regression suites
  • Native-speaker sets

Infrastructure

  • Kubernetes
  • Slurm
  • Ray
  • MLflow
  • Weights & Biases

Who we do this for

  • Teams needing a strict output contract
  • Regulated institutions, own estate
  • Government language programmes
  • Products with one high-volume task
  • Universities and research groups

Three ways in. Stop after any of them.

2–3 weeks

Fine-tuning feasibility review

We baseline the frozen model, build the held-out evaluation set, audit the data and report whether training is justified at all.

Baseline comparison, held-out evaluation set, written go or no-go

6–14 weeks

Adaptation programme

Dataset curation, training runs, evaluation and regression testing, delivered with the pipeline that produced them.

Curated datasets, adapters or merged checkpoints, training pipeline, model card

Ongoing

Model stewardship

Re-training as your data and the base models move, benchmark maintenance, contamination re-checks and migration to better bases.

Re-training runs, refreshed benchmarks, migration plan

Questions

When the knowledge changes weekly, when you have fewer than a few hundred good examples, when nobody has written down what a correct answer looks like, or when you have not yet tried a serious prompt and a decent retrieval pipeline. A fine-tune also pins you to a base model that will be superseded.

For style, format or a narrow classification boundary, a few thousand carefully written examples usually beat a few hundred thousand scraped ones. Preference optimisation needs paired comparisons. Continued pre-training for a language is a different order of magnitude, measured in billions of tokens.

No. It makes the model more like your data. Reasoning ability comes from the base model and its pre-training compute. What adaptation reliably buys is consistency, format adherence, domain vocabulary, language coverage and an equivalent result from a smaller, cheaper model. For raw capability, change base models.

Talk to someone who has built this

Send us the constraint you are actually up against — budget, latency, regulator, deadline.