Fine-tuning LoRA i QLoRA w praktyce — kiedy, jak i ile

Kiedy firma decyduje się na fine-tuning, najczęściej pierwsze pytanie brzmi: „jaką kartę kupić?”. To pytanie zadane za wcześnie. Zanim dojdzie do sprzętu i budżetu, warto zrozumieć, co LoRA i QLoRA rzeczywiście robią i dlaczego zmieniają całą ekonomię tego podejścia.

Pełny fine-tuning modyfikuje wszystkie wagi modelu. Dla modelu 7B to kilkanaście miliardów parametrów, każdy zapisany jako liczba zmiennoprzecinkowa. Taki trening wymaga od 40 GB VRAM wzwyż i jest praktycznie niedostępny bez klastra GPU.

LoRA (Low-Rank Adaptation) rozbija aktualizację wag na dwie znacznie mniejsze macierze o niskiej randze. Zamiast modyfikować całą macierz wag W (np. 4096 × 4096), trenuje dwie macierze A i B o rozmiarze 4096 × r i r × 4096, gdzie r to hiperparametr od 4 do 64. Podczas inferencji adapter jest po prostu dodawany do oryginalnych wag lub ładowany osobno. Oryginalny model pozostaje niezmieniony.

QLoRA dodaje kwantyzację: oryginalny model jest ładowany w precyzji 4-bit (NF4), co czterokrotnie zmniejsza jego zajętość w VRAM. Adaptery LoRA trenują się w 16-bit, więc gradient liczymy w wyższej precyzji. Wynikowy model jest trochę wolniejszy przy inferencji w wersji skwantyzowanej, ale w wielu zadaniach różnica jakości względem pełnego fine-tuningu jest marginalna.

Granica między LoRA a QLoRA jest prosta: jeśli VRAM jest czynnikiem ograniczającym, zacznij od QLoRA.

Liczby zakładają batch size 1-4 z gradient checkpointing. Dla porównania: RTX 4090 z 24 GB VRAM obsługuje QLoRA na modelach do 13B wygodnie, LoRA na 7B bez kwantyzacji, a pełny fine-tuning 7B tylko z agresywnym gradient checkpointing i małym batchem, co wydłuża trening.

Osobne zagadnienie to self-hosting gotowego adaptera. Po wytrenowaniu adapter LoRA to kilkanaście megabajtów pliku, który nakłada się na bazowy model. Do samej inferencji wystarczy tyle VRAM, ile zajmuje model bazowy, bez narzutu treningowego.

Najczęstszy błąd to zebranie tysiąca byle jakich przykładów zamiast trzystu precyzyjnych. Kilka sprawdzonych zasad:

Minimalne progi. Poniżej 200 par wejście-wyjście fine-tuning rzadko daje stabilny efekt. Przedział 300-800 przykładów dobrej jakości wystarczy dla wąskich zadań (klasyfikacja, ekstrakcja, generacja w określonym szablonie). Dla szerszej zmiany zachowania: od 1000 wzwyż.

Hold-out od początku. Wydziel 10-20% danych jako zbiór testowy jeszcze przed rozpoczęciem treningu. Nigdy nie używaj tych par do uczenia ani do wyboru hiperparametrów. To jedyna miara, której można ufać przy decyzji o wdrożeniu.

Spójność ważniejsza od różnorodności. Jeśli trenujesz model do generowania raportów w konkretnym formacie, każdy przykład powinien przestrzegać tego formatu. Kilkanaście wyjątków w danych treningowych potrafi „nauczyć” model, że format jest opcjonalny.

Dane osobowe. Jeśli pary treningowe zawierają PII, obowiązuje RODO i prawdopodobnie DPIA. Po treningu usunięcie konkretnych danych z wag jest technicznie trudne, co komplikuje realizację prawa do bycia zapomnianym w sposób niemożliwy przy RAG. Zalecamy anonimizację przed treningiem lub architekturę, w której dane treningowe nie opuszczają Waszej infrastruktury.

Poniżej wzorzec, który stosujemy w Cashcrown przy wdrożeniach produkcyjnych.

1. Ewaluacja bazowa. Zanim zaczniesz trenować, zmierz, jak model bazowy radzi sobie z Waszym zadaniem na zbiorze hold-out. To punkt odniesienia, bez którego nie wiesz, czy fine-tuning cokolwiek poprawił.

2. Przygotowanie danych. Ujednolicony format (np. instrukcja systemowa + wejście + wyjście w formacie Alpaca lub ChatML), anonimizacja PII, weryfikacja spójności etykiet przez co najmniej dwie osoby.

3. Trening LoRA lub QLoRA. Popularny stack: transformers + peft + bitsandbytes (dla QLoRA) + trl (trainer). Kluczowe hiperparametry: ranga r (zacznij od 16), alpha (zazwyczaj 2×r), learning rate (1e-4 do 3e-4), liczba epok (3-5 dla małych zbiorów). Loguj każdy run do pliku z datą, modelem bazowym i checksum danych.

4. Ewaluacja na hold-out. Dla klasyfikacji: F1 per klasa, confusion matrix. Dla generacji: ROUGE-L, BERTScore i, jeśli możliwe, ocena ludzka próbki 50-100 przykładów. Porównaj z wartością bazową z kroku 1.

5. Decyzja człowieka. To nie jest etap automatyczny. Ktoś z odpowiedzialnością za produkt przegląda wyniki i decyduje, czy adapter idzie do wdrożenia. Przy systemach wysokiego ryzyka (AI Act, Załącznik III) ten krok wymaga dokumentacji.

6. Wdrożenie adaptera. Adapter LoRA można serwować przez Ollama (GGUF + adapter), vLLM (native PEFT) lub jako oddzielny kontener z modelem bazowym i wczytanym adapterem. Po wdrożeniu monitoruj dryft. Jeśli rozkład zapytań zmienia się znacząco względem danych treningowych, metryki na hold-out przestają być miarodajne.

TCO fine-tuningu to nie tylko czas GPU.

Pełne wdrożenie od zera do produkcji rzadko zajmuje mniej niż 3-4 tygodnie. Projekty z czystymi, gotowymi danymi mogą zejść do 2 tygodni. Projekty wymagające pełnego przygotowania danych od zera przekraczają 6 tygodni.

Porównaj z migracją z API na własny model: kalkulacja progu opłacalności jest podobna i warto ją zrobić zanim zaangażujesz zasoby.

Fine-tuning zmienia jak model się zachowuje, nie co model wie. To rozróżnienie z artykułu kiedy fine-tuning ma sens warto powtórzyć w kontekście LoRA i QLoRA.

Adapter wytrenowany na przykładach z 2024 roku nie będzie znał przepisów z 2026 roku. Model po fine-tuningu nadal halucynuje fakty, których nie ma w wagach. To zadanie dla RAG, nie dla adaptera. Najlepsze architektury produkcyjne, które widzimy, łączą lekki fine-tuning (styl, format) z RAG (świeże fakty przy każdym wywołaniu). Szczegóły tego wzorca opisuje artykuł RAG czy fine-tuning.

Fine-tuning nie jest też mechanizmem bezpieczeństwa. Adapter nie zastąpi guardrails, nie eliminuje prompt injection i nie ogranicza modelu do określonej domeny w sposób niezawodny. Bezpieczeństwo buduje się warstwowo, poza wagami modelu. Szerzej o sprzęcie i środowisku lokalnym pisze artykuł lokalne LLM: jaki sprzęt i GPU.

LoRA trenuje małe macierze adapterów przy zachowaniu modelu bazowego w pełnej precyzji (bf16 lub fp16). QLoRA dodatkowo kwantyzuje model bazowy do 4-bit NF4 przed treningiem, co redukuje zajętość VRAM o kolejne 50-60%. Jakość wynikowego adaptera jest zbliżona dla większości zadań klasyfikacyjnych i generacyjnych; różnica widoczna jest przy bardzo długich sekwencjach lub wymaganiu wysokiej precyzji numerycznej.

Dla wąskiego zadania (klasyfikacja, ekstrakcja, generacja w stałym szablonie) realistyczne minimum to 300-500 par dobrej jakości z wydzielonym hold-out 10-20%. Poniżej 200 par ryzyko niestabilnego treningu lub overfittingu jest wysokie. Dla szerszych zmian zachowania modelu (zmiana tonu, obsługa wielu intencji) potrzebujesz od 1000 par wzwyż. Jakość etykiet ważniejsza od samej liczby.

Na laptopie bez dedykowanego GPU: nie. QLoRA na modelu 7B wymaga karty graficznej z poniżej 12 GB VRAM (np. RTX 3080/3090/4080/4090) lub dostępu do instancji chmurowej. Na laptopie z zintegrowaną grafiką trening jest technicznie możliwy na procesorze, ale zajmuje kilka dni zamiast kilku godzin i zwykle nie jest praktyczny. Alternatywą jest chmura obliczeniowa: RunPod, Lambda Labs, Google Colab Pro.

Adapter LoRA to plik kilkunastu megabajtów (zestaw macierzy), który nakłada się na model bazowy. W praktyce: skonwertuj do formatu GGUF z wbudowanym adapterem (llama.cpp + --lora) lub użyj vLLM z natywną obsługą PEFT. Model bazowy ładujesz raz, adapter zamieniasz bez restartu w niektórych frameworkach. Konieczne jest wersjonowanie zarówno adaptera, jak i modelu bazowego, na którym był trenowany — niezgodność wersji daje trudne do debugowania błędy.

Gdy problemem jest dostęp do świeżej wiedzy faktograficznej — to zadanie dla RAG, nie fine-tuningu. Gdy danych treningowych jest mniej niż 200 par lub ich jakość jest niska. Gdy aktualizujesz bazę wiedzy częściej niż raz na kwartał, bo każda zmiana wymagałaby retreningu. Gdy nie masz zasobów na ewaluację i utrzymanie kolejnych wersji adaptera. W tych przypadkach dobór modelu AI i RAG to tańszy i szybszy start.