Ein 70B-Modell auf einer Karte fine-tunen.

Was tatsächlich passt

LoRA friert das Modell ein und trainiert neben jeder Gewichtsmatrix ein kleines Paar Low-Rank-Matrizen. QLoRA geht weiter und hält die eingefrorenen Gewichte in 4-Bit. Was Sie im Speicher vorhalten müssen, ändert sich dadurch vollständig.

Warum vollständiges Fine-Tuning das nicht tut

Vollständiges Fine-Tuning in BF16 braucht etwa 16 Byte pro Parameter: 2 für das Gewicht, 2 für seinen Gradienten und 8 für Adams zwei Momente in FP32, dazu die Master-Kopie. Das ist ein fester Multiplikator, und er ist brutal.

Dies sind Größenordnungen mit einem moderaten Puffer für Aktivierungen — genug, um eine Maschine auszuwählen, nicht genug, um einen bestimmten Lauf zu versprechen. Sequenzlänge und Batch-Größe verändern die QLoRA-Spalte erheblich; die Spalte für vollständiges Fine-Tuning bewegt sich kaum, da sie von den festen 16 Byte pro Parameter dominiert wird.

Modell für Modell

Der günstigste Knoten in unserem Katalog, der jedes Modell mit QLoRA trainieren kann, zusammen mit der Maschine, die Sie für das Serving des Ergebnisses bräuchten.

Training braucht Speicher; Serving braucht Speicher und Bandbreite. Häufig ist die richtige Karte fürs Training eine günstige mit viel Speicher, während die richtige Karte fürs Serving eine teure, schnelle ist — und da hier beides monatlich abgerechnet wird, ist es oft günstiger, beide auf getrennten Maschinen zu betreiben, als bei einer Karte Kompromisse einzugehen.

Durchführung

Axolotl ist als eines der Images im Konfigurator vorinstalliert. Dies ist ein vollständiger Lauf auf einer einzelnen Karte, ausgehend von einer leeren Maschine.

$ mkdir -p /scratch/ft && cd /scratch/ft
$ cat > qlora.yml <<'YAML'
base_model: meta-llama/Llama-3.3-70B-Instruct
load_in_4bit: true
adapter: qlora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_linear: true

sequence_len: 2048
sample_packing: true
gradient_checkpointing: true
micro_batch_size: 1
gradient_accumulation_steps: 16
num_epochs: 2
learning_rate: 0.0001
optimizer: paged_adamw_8bit
bf16: true

datasets:
  - path: /scratch/ft/data.jsonl
    type: chat_template
output_dir: /scratch/ft/out
YAML

$ docker run --rm --gpus all --ipc=host --shm-size=16g \
    -v /scratch/ft:/workspace -v /scratch/models:/root/.cache/huggingface \
    -e HF_TOKEN="$HF_TOKEN" \
    axolotlai/axolotl:main-latest \
    axolotl train /workspace/qlora.yml

$ nvidia-smi dmon -s um

# If memory sits just under the card's total, you are one long batch
# away from an out-of-memory error four hours into the run.
# Lower sequence_len or micro_batch_size now, not then.

Die Einstellungen, auf die es ankommt

Was ein Monat kostet

Der Grund, warum monatliche Abrechnung beim Training mehr zählt als beim Serving: Ein Fine-Tuning-Projekt ist nicht ein einzelner Lauf. Es ist ein erster Lauf, der an einem Datenfehler scheitert, ein zweiter, der overfittet, ein dritter, der funktioniert, und dann noch fünf weitere mit unterschiedlichen Rängen.

Vergleichen Sie das mit stündlicher Abrechnung über ein ganzes Projekt statt über einen einzelnen Lauf: Der Break-even-Guide rechnet das durch. Eine Maschine, die drei Wochen lang existiert, während Sie iterieren, ist genau der Fall, in dem eine Abrechnung nach Verbrauch mehr kostet als eine feste Laufzeit.

Wo LoRA nicht mehr funktioniert

Es ist eine sehr gute Technik mit einer echten Grenze, und es lohnt sich, vor jeder Anmietung zu wissen, auf welcher Seite dieser Grenze man steht.

Für alles andere — einen Tonfall, ein Format, ein Schema, ein Fachgebiet, das das Basismodell schon halb kennt — erreicht QLoRA auf einer einzelnen Karte den Großteil der Qualität für einen Bruchteil der Maschine. Das ist der Kompromiss, und bei den Modellen, die die meisten Leute tatsächlich fine-tunen, ist es ein guter.