LoRA and QLoRA: tuning on a single GPU

Начнём с числа, которое отрезвляет. Модель на 7 миллиардов параметров в fp16 занимает 14 ГБ — по 2 байта на параметр. Кажется, что 24-гигабайтной карты хватит для обучения. Не хватит. Полный fine-tune с оптимизатором AdamW хранит для каждого обучаемого параметра: сам вес (2 байта), градиент (2 байта) и два момента оптимизатора в fp32 (8 байт), плюс обычно fp32-копию весов (4 байта). Итого порядка 16 байт на параметр — около 112 ГБ для 7B ещё до активаций. Это территория нескольких A100, недоступная одиночке.

LoRA разрубает узел: базовые веса замораживаются — для них не нужны ни градиенты, ни состояния оптимизатора. Обучаются только маленькие адаптеры. Для 7B с rank 16 на проекциях внимания и MLP это порядка 40 миллионов параметров — около 0,5% модели. Память: 14 ГБ замороженной базы плюс менее гигабайта на адаптеры с их градиентами и оптимизатором. С gradient checkpointing обучение помещается в 24 ГБ.

QLoRA делает последний шаг: замороженную базу можно хранить не в fp16, а в 4 битах — около 3,5–4 ГБ для 7B. Обучение 7–8B влезает в бесплатный Colab с T4 на 16 ГБ, а авторы статьи QLoRA дообучали 65B на одной карте в 48 ГБ. Так тюнинг перестал требовать кластера.

Идея LoRA: вместо изменения матрицы весов W целиком учим её низкоранговую поправку. Обновлённый слой считает W·x + (alpha/r)·B·A·x, где A — матрица r×k, B — матрица d×r, а rank r много меньше размерностей слоя. A инициализируется случайно, B — нулями: в момент старта поправка равна нулю, и модель в точности совпадает с базовой — обучение начинается из стабильной точки.

Главные ручки. Rank r (типично 8–64) — ёмкость поправки: больше rank — больше выразительность и больше параметров. На практике отдача быстро насыщается: r=16 — разумный старт, r=64 редко даёт заметный прирост на узких задачах. Alpha — множитель масштаба: эффективная сила адаптера пропорциональна alpha/r; распространённая практика — alpha, равное r или 2r (например, r=16, alpha=32), и подбор learning rate вместо перебора alpha. target_modules — на какие слои вешать адаптеры: минимум — проекции внимания q_proj, k_proj, v_proj, o_proj; авторы QLoRA показали, что покрытие всех линейных слоёв (включая gate/up/down_proj в MLP) влияет на качество сильнее, чем повышение rank. В peft это одна строка: target_modules="all-linear".

Режим обучения тоже свой: learning rate 1e-4–2e-4 — на порядок выше, чем при полном fine-tune, 1–3 эпохи, lora_dropout 0,05. Больше трёх эпох на малом датасете — почти всегда переобучение.

QLoRA — это LoRA поверх базы, сжатой до 4 бит, плюс три инженерных приёма из статьи.

Первый — тип данных NF4 (NormalFloat4). Веса обученных сетей распределены примерно нормально, а обычная 4-битная сетка (int4, fp4) расставляет уровни равномерно и тратит их на редкие хвосты. NF4 расставляет 16 уровней по квантилям нормального распределения — каждый уровень покрывает равную вероятностную массу, и точность на реальных весах выше при тех же 4 битах.

Второй — double quantization: веса квантуются блоками, у каждого блока своя константа масштаба в fp32; при блоке в 64 веса эти константы сами занимают заметную память, поэтому их квантуют вторым проходом. Экономия — около 0,37 бита на параметр, примерно 0,3 ГБ на 7B: немного, но именно эти сотни мегабайт часто решают, влезет ли обучение в карту.

Третий — paged optimizers: состояния оптимизатора при пиках памяти (длинные последовательности) выгружаются в RAM через unified memory, спасая от внезапных OOM.

Важно понимать механику: 4-битными веса только хранятся. При каждом умножении блок деквантуется в bf16 на лету, и вся арифметика идёт в bf16 (bnb_4bit_compute_dtype). Отсюда цена: QLoRA на 30–40% медленнее fp16-LoRA. По качеству статья показывает паритет с 16-битным fine-tune на их бенчмарках — компромисс почти всегда в пользу памяти.

Собираем всё в минимальный рабочий скрипт для одной карты:

import torch
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
from peft import LoraConfig
from trl import SFTConfig, SFTTrainer

bnb = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,
)
model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen2.5-7B-Instruct", quantization_config=bnb, device_map="auto"
)

peft_config = LoraConfig(
    r=16, lora_alpha=32, lora_dropout=0.05,
    target_modules="all-linear", task_type="CAUSAL_LM",
)

trainer = SFTTrainer(
    model=model,
    train_dataset=ds,
    peft_config=peft_config,
    args=SFTConfig(
        num_train_epochs=2, learning_rate=2e-4,
        per_device_train_batch_size=2, gradient_accumulation_steps=8,
        gradient_checkpointing=True, bf16=True, logging_steps=10,
    ),
)
trainer.train()
trainer.save_model("out/adapter")  # адаптер — десятки мегабайт, не гигабайты

Эффективный batch size здесь 16 (2 × 8 шагов аккумуляции) — стабильный минимум для SFT. Следите за кривой loss: здоровый прогон — быстрое падение в начале и плавное выполаживание; loss около нуля — признак дубликатов или утечки eval-данных в train. Сохранённый адаптер подключается к базе через PeftModel.from_pretrained и весит десятки мегабайт — базу копировать не нужно.

Если скорость критична, посмотрите Unsloth: оптимизированные ядра дают ускорение примерно вдвое и заметную экономию VRAM на тех же конфигурациях при совместимом API.