Fine-Tunes & Variants

A single base model spawns a whole family: a customer-support fine-tune, a coding fine-tune, a couple of LoRA adapters, and an int8 quantization for serving. Stored naively that is many full copies. Because each variant shares most of its structure with the base, this is where dits dedup pays off hardest — a fine-tune mostly references the base's existing chunks.

See Getting Started for setup, and Chunking for why shared structure means shared storage.

Organize the family

Two common layouts. Use a branch per variant in one repo when they descend from a shared base, or keep one repo per variant if their lifecycles diverge. Branches keep the relationship explicit and dedup naturally across the whole repository.

cd models/llama-8b
dits init

# Commit the base weights first
dits add model.safetensors
dits commit -m "base: llama-8b release weights"

# Branch off the base for each variant
dits branch ft-customer
dits checkout ft-customer

Commit a fine-tune

On the variant branch, drop in the fine-tuned weights and commit. Most chunks are identical to the base, so the new commit stores only the parts the fine-tune actually moved.

# Replace weights with the fine-tuned output, then:
dits add model.safetensors
dits commit -m "ft-customer: 3 epochs on support transcripts"

dits log
dits diff main ft-customer

LoRA adapters fit the same pattern: commit the small adapter files on their own branch. Tag a variant when it ships so you can find it later.

dits add adapter_model.safetensors
dits commit -m "lora-rank16: customer tone adapter"
dits tag v1-customer-lora

Derivable variants

Some variants are deterministic functions of another artifact: an int8 quantization is computable from the fp16 weights, and a merged LoRA is computable from base plus adapter. Storing these in full is redundant when the recipe could regenerate them.

Related

• Versioning Checkpoints
• Versioning Datasets
• Similarity Dedup
• CLI Reference (shared engine)