Jak dostrajać LLM: Metody, Frameworki i Kod Krok po Kroku [2026]

Dostrajanie LLM (ang. fine-tuning) polega na wzięciu wstępnie wytrenowanego modelu i przeszkoleniu go na własnych, specyficznych danych, aby wykonywał Twoje zadania lepiej, niż byłoby to możliwe przy użyciu samych promptów. Bariera wejścia drastycznie spadła: QLoRA + Unsloth pozwalają obecnie na dostrajanie modelu z 8 miliardami parametrów na konsumenckiej karcie GPU z 12 GB pamięci VRAM za mniej niż 1 USD kosztów chmurowych.

Ten przewodnik obejmuje kompletną ścieżkę: kiedy warto dostrajać model (w przeciwieństwie do RAG czy inżynierii promptów), jaką metodę i framework wybrać, jak przygotować zestaw danych, gotowy do skopiowania przykład z Llama 3, realne scenariusze kosztowe oraz proces wdrażania.

Dostrajanie w skrócie

Zanim podejmiesz decyzję, oto szybki przegląd:

Sprawdźmy teraz, czy dostrajanie jest rzeczywiście właściwym ruchem dla Twojego projektu.

Kiedy należy dostrajać LLM? (vs. RAG vs. Inżynieria Promptów)

To pytanie, które większość programistów pomija, co kosztuje ich tygodnie zmarnowanego wysiłku. Dostrajanie jest potężne, ale nie zawsze jest właściwym narzędziem. Oto ramy decyzyjne.

Decyzja sprowadza się do tego, co chcesz zmienić. Oto realne scenariusze:

Jeśli wybierasz odpowiedni stos AI dla swojego SaaS, ta rama decyzyjna jest pierwszym krokiem. Wiele zespołów buduje złożone potoki RAG, podczas gdy dostrajanie na 500 przykładach dałoby im bardziej spójne rezultaty przy mniejszym opóźnieniu.

Werdykt: Dostrajaj, gdy potrzebujesz, aby model konsekwentnie zachowywał się inaczej, a nie tylko wiedział inne rzeczy. Jeśli potrzebujesz tylko nowej wiedzy, RAG jest tańszy i łatwiejszy w utrzymaniu. Jeśli potrzebujesz obu tych elementów, wybierz podejście hybrydowe.

Jak działa dostrajanie LLM? Pełne vs. LoRA vs. QLoRA

Istnieją trzy główne podejścia, które znacznie różnią się wymaganiami sprzętowymi, kosztami i jakością. Zrozumienie kompromisów uchroni Cię przed nadmiernymi inwestycjami lub niedostarczeniem rezultatów.

Pełne dostrajanie (Gdy budżet nie gra roli)

Pełne dostrajanie aktualizuje każdy parametr w modelu. Daje najlepsze możliwe rezultaty, ale wymaga ogromnych zasobów – około 100+ GB VRAM dla modelu 7B (musisz jednocześnie przechowywać model, stany optymalizatora i gradienty). To teren dla klastrów H100. Jeśli nie pracujesz w dobrze finansowanym laboratorium, odpuść sobie to.

LoRA: Rewolucja PEFT

LoRA (Low-Rank Adaptation) zamraża model bazowy i dodaje małe, trenowalne macierze zwane adapterami. Zamiast bezpośrednio aktualizować ogromną macierz wag W, LoRA rozkłada aktualizację na dwie małe macierze A i B, gdzie rząd r jest znacznie mniejszy niż wymiar modelu. Efekt? Trenujesz około 1-2% oryginalnych parametrów, zachowując 98-99% jakości pełnego dostrajania.

Standardową implementacją jest biblioteka peft od Hugging Face. Adaptery LoRA mają zazwyczaj 50-200 MB, co jest niczym w porównaniu do pełnego modelu.

QLoRA: Dostrajanie dla każdego

QLoRA idzie o krok dalej niż LoRA. Ładuje model bazowy w precyzji 4-bitowej, używając specjalnego typu danych NormalFloat4 (NF4), a następnie nakłada na niego adaptery LoRA. 4-bitowa kwantyzacja zmniejsza zużycie VRAM o kolejne ~25% w porównaniu do standardowego LoRA, zachowując niemal identyczną jakość.

To właśnie sprawia, że dostrajanie staje się dostępne. Model 7B, który do pełnego dostrajania potrzebuje 100+ GB, zmieści się w 12 GB dzięki QLoRA.

Werdykt: Dla 90% programistów QLoRA jest właściwym wyborem. Różnica w jakości w porównaniu do pełnego dostrajania jest pomijalna dla większości zadań, a oszczędności sprzętowe są ogromne. Zacznij od tego i skaluj w górę tylko wtedy, gdy Twoje metryki ewaluacyjne tego wymagają.

Jaki framework do dostrajania wybrać w 2026 roku?

Wybór frameworku ma większe znaczenie, niż大多数人 zdaje sobie sprawę. Odpowiedni wybór oszczędza godziny konfiguracji i znacząco przyspiesza trening. Oto porównanie czterech głównych opcji.

Oto szybka rekomendacja:

• Pierwsze dostrajanie? Użyj Unsloth. Najszybszy trening, najłatwiejsza konfiguracja, darmowe notatniki Colab do natychmiastowego startu.
• Potrzebujesz Web UI bez kodowania? Użyj LLaMA-Factory. Jego interfejs LLaMA-Board pozwala konfigurować i uruchamiać trening z poziomu przeglądarki.
• Robisz alignment (RLHF, DPO, GRPO)? Użyj TRL. To standard Hugging Face do treningu opartego na preferencjach, a wersja v0.15.0 (marzec 2026) dodała natywne wsparcie dla GRPO.
• Uruchamiasz potoki produkcyjne na wielu GPU? Użyj Axolotl. Konfiguracje oparte na YAML sprawiają, że eksperymenty są reprodukowalne i audytowalne.

Jedna przydatna sztuczka: Unsloth i LLaMA-Factory można łączyć. LLaMA-Factory obsługuje Unsloth jako backend treningowy, dając Ci wygodę GUI wraz z optymalizacjami szybkości Unsloth. Zespoły budujące agentów AI wykorzystujących dostrajane modele często zaczynają od Unsloth dla szybkiej iteracji, a następnie przechodzą do Axolotl dla reprodukowalności w produkcji.

Jak przygotować zestaw danych do dostrajania?

Jakość danych jest najważniejszym czynnikiem sukcesu w dostrajaniu. Dobrze dobrany zestaw 500 przykładów prawie zawsze pokona szumny zestaw 10 000 przykładów.

Formaty danych

Dwa dominujące formaty to chat (kompatybilny z OpenAI) i instruction (styl Alpaca). Oto jak wyglądają one w formacie JSONL:

Format chat (zalecany dla większości przypadków):

{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "I ordered a laptop 3 days ago (order #4821) and it still says processing."}, {"role": "assistant", "content": "I can see order #4821 is currently in our warehouse being prepared for shipment. Laptops typically ship within 3-5 business days. You should receive a tracking number by tomorrow. Would you like me to flag this for priority processing?"}]}
{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "Can I return my keyboard? Order #3019, bought it last week."}, {"role": "assistant", "content": "Absolutely! Order #3019 is within our 30-day return window. I'll email you a prepaid return label right now. Once we receive the keyboard, your refund will process within 2-3 business days."}]}
{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "My monitor arrived cracked. Order #5573."}, {"role": "assistant", "content": "I'm sorry about that! For order #5573, I'm initiating an immediate replacement shipment -- no need to return the damaged unit. The new monitor will ship today with express delivery. You'll get a tracking email within the hour."}]}

Format instruction (styl Alpaca):

{"instruction": "Summarize the following customer complaint in one sentence.", "input": "I've been waiting 2 weeks for my refund and nobody responds to my emails. This is the worst customer service I've ever experienced.", "output": "Customer is frustrated by a 2-week delay in receiving their refund and lack of email response from support."}
{"instruction": "Classify the sentiment of this review.", "input": "The product works fine but shipping took forever.", "output": "Mixed (positive product, negative shipping)"}

Wytyczne dotyczące rozmiaru zestawu danych

Ile danych naprawdę potrzebujesz? To zależy od złożoności zadania:

1. 50-100 przykładów, proof of concept, wystarczy, aby przetestować, czy dostrajanie pomaga
2. 500-1000 przykładów, przydatne dla większości pojedynczych zadań (klasyfikacja, ekstrakcja, formatowanie)
3. 5000-10 000 przykładów, wyniki jakości produkcyjnej dla złożonych zadań
4. 10 000+ przykładów, malejące zwroty, chyba że Twoje zadanie charakteryzuje się wysoką zmiennością

Lista kontrolna jakości danych

Przed treningiem zweryfikuj swój zestaw danych pod kątem tych kryteriów:

• Spójne formatowanie we wszystkich przykładach (ten sam system prompt, ta sama struktura wyjścia)
• Różnorodne przykłady obejmujące przypadki brzegowe i tryby awaryjne
• Brak sprzeczności (nie ucz modelu, aby mówił zarówno „tak”, jak i „nie” na ten sam wzorzec wejściowy)
• Zbalansowany rozkład typów wyjść (przy klasyfikacji nie miej 90% przykładów w jednej klasie)
• Usuń duplikaty lub near-duplikaty

Wskazówka pro: Użyj GPT-4 lub Claude do wygenerowania początkowych syntetycznych danych treningowych, a następnie dopracuj je ludzkim przeglądem. 500 wysokiej jakości syntetycznych przykładów często przewyższa 5000 szumnych rzeczywistych przykładów. Przewodnik Meta dotyczący dostrajania rekomenduje to podejście do bootstrapowania zestawów danych.

Krok po kroku: Dostrajanie Llama 3 8B z QLoRA i Unsloth

Oto kompletny przewodnik. Każdy blok kodu jest gotowy do skopiowania i wklejenia, możesz go uruchomić w darmowym notatniku Google Colab lub na dowolnej maszynie z 12+ GB VRAM.

Krok 1: Instalacja Unsloth

pip install unsloth

To wszystko. Unsloth automatycznie obsługuje wszystkie zależności (transformers, peft, trl, bitsandbytes).

Krok 2: Załaduj model bazowy w 4-bitach

from unsloth import FastLanguageModel

# Load Llama 3.1 8B in 4-bit quantization
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Meta-Llama-3.1-8B-bnb-4bit",
    max_seq_length=2048,
    load_in_4bit=True,
)

To pobiera 4-bitowy skwantyzowany model (~4 GB) i ładuje go do pamięci GPU. Na RTX 3060 (12 GB) będziesz mieć sporo zapasu na trening.

Krok 3: Konfiguracja adapterów LoRA

# Add LoRA adapters to the model
model = FastLanguageModel.get_peft_model(
    model,
    r=16,                # LoRA rank -- 16 is the sweet spot for most tasks
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                     "gate_proj", "up_proj", "down_proj"],
    lora_alpha=16,       # Scaling factor (usually equal to r)
    lora_dropout=0,      # Unsloth optimizes for 0 dropout
    bias="none",
)

Przy r=16 trenujesz około 40 milionów parametrów z 8 miliardów, czyli mniej niż 0,5% modelu. Na tym polega magia LoRA.

Krok 4: Załaduj swój zestaw danych

from datasets import load_dataset

# Load your JSONL dataset from Hugging Face Hub or local file
dataset = load_dataset("json", data_files="train.jsonl", split="train")

# Format into chat template
def format_chat(example):
    text = tokenizer.apply_chat_template(
        example["messages"],
        tokenize=False,
        add_generation_prompt=False,
    )
    return {"text": text}

dataset = dataset.map(format_chat)

To przyjmuje format JSONL chat z poprzedniej sekcji i stosuje szablon chatu Llama 3. Tokenizer obsługuje wszystkie specjalne tokeny (<|begin_of_text|>, <|eot_id|> itp.).

Krok 5: Konfiguracja i uruchomienie treningu

from trl import SFTTrainer
from transformers import TrainingArguments
from unsloth import is_bfloat16_supported

trainer = SFTTrainer(
    model=model,
    train_dataset=dataset,
    dataset_text_field="text",
    max_seq_length=2048,
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,    # Effective batch size = 8
        warmup_steps=5,
        max_steps=60,                     # Adjust based on dataset size
        learning_rate=2e-4,               # Standard for QLoRA
        fp16=not is_bfloat16_supported(),
        bf16=is_bfloat16_supported(),
        logging_steps=1,
        output_dir="outputs",
        seed=42,
    ),
)

# Start training
trainer.train()

Kluczowe hiperparametry do zrozumienia:

• Learning rate (2e-4): Standard dla QLoRA. Zmniejsz do 2e-5, jeśli zauważysz, że model zapomina ogólne zdolności.
• Batch size (2) x akumulacja gradientów (4): Efektywny rozmiar batcha wynoszący 8. Zwiększ gradient_accumulation, jeśli GPU zabraknie pamięci.
• max_steps (60): Dla 500 przykładów to około 1 epoka. Zacznij od 1-3 epok i obserwuj loss walidacyjny.
• Rank r (16): Niższy (4-8) dla prostych zadań, wyższy (32-64) dla złożonych. 16 to bezpieczny domyślny wybór.

Krok 6: Zapisz i przetestuj

# Save the LoRA adapters (small -- ~50-200 MB)
model.save_pretrained("my-fine-tuned-model")
tokenizer.save_pretrained("my-fine-tuned-model")

# Quick inference test
FastLanguageModel.for_inference(model)
inputs = tokenizer(
    [tokenizer.apply_chat_template(
        [{"role": "user", "content": "I need to return order #7742"}],
        tokenize=False,
        add_generation_prompt=True,
    )],
    return_tensors="pt",
).to("cuda")

outputs = model.generate(**inputs, max_new_tokens=256)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

To cały potok. Na RTX 4090 z Unsloth trening 500 przykładów zajmuje około 15-30 minut. Na darmowym Colab T4 spodziewaj się 1-2 godzin.

A co z dostrajaniem opartym na API? (OpenAI, Google, Mistral)

Nie każdy chce zarządzać GPU. Dostawcy API pozwalają na dostrajanie poprzez prosty proces upload-i-trenuj. Oto jak wypada to w porównaniu do samodzielnego uruchamiania.

Kiedy dostrajanie przez API ma sens: Musisz szybko iterować, Twój zestaw danych jest mały, nie chcesz zarządzać infrastrukturą lub konkretnie potrzebujesz modelu zamkniętego, takiego jak GPT-4o.

Kiedy lokalne dostrajanie wygrywa: Liczy się prywatność danych (ochrona zdrowia, finanse, prawo), trenujesz często, chcesz posiadać i eksportować wagi lub optymalizujesz koszty w skali.

Werdykt: Dostrajanie przez API to najszybsza droga do proof of concept. Lokalne dostrajanie to najtańsza droga do produkcji. Większość zespołów prototypuje na API, a następnie przechodzi na lokalny Unsloth, gdy zweryfikują podejście.

Ile kosztuje dostrajanie LLM?

Narracja „dostrajanie jest drogie” utknęła w 2023 roku. Oto, ile to naprawdę kosztuje dzisiaj.

Krzywa kosztów szybko się wypłaszcza. Startup dostrajający model 8B na RunPod wydaje na trening mniej niż na jedną filiżankę kawy. Nawet scenariusz produkcyjny 70B mieści się poniżej 30 USD – to równowartość miesięcznego budżetu junior developera na codzienne obiady.

Dostawcy chmurowych GPU wartych porównania: RunPod (najlepsze ceny spot), Lambda (niezawodne H100 on-demand), Vast.ai (najtańsze, ale zmienna jakość) oraz Modal (serverless, płatność za sekundę).

Powyższy wykres pokazuje, dlaczego QLoRA zmieniło zasady gry. Model 7B, który do pełnego dostrajania wymagał klastra wieloprocesorowego, mieści się teraz na GPU w laptopie. Model 70B spada z kategorii „tylko chmura” do pojedynczego A100.

Werdykt: Możesz dostrajać model 8B jakości produkcyjnej za mniej niż 1 USD. Bariera kosztowa dostrajania zniknęła. Prawdziwym kosztem jest czas przygotowania danych.

Jak ewaluować dostrajany model?

Trening to tylko połowa pracy. Bez odpowiedniej ewaluacji nie powiesz, czy Twój dostrajany model faktycznie się poprawił, czy po prostu zapamiętał dane treningowe.

Metryki automatyczne

Śledź je podczas i po treningu:

• Loss treningowy / perplexity: Powinien stopniowo maleć, a następnie ustabilizować się. Jeśli spadnie do zera, następuje overfitting.
• Metryki specyficzne dla zadania: Accuracy (klasyfikacja), BLEU/ROUGE (sumaryzacja), exact match (ekstrakcja), F1 (multi-label). Wybierz metrykę pasującą do Twojego zadania.

Ewaluacja ludzka

Liczby nie oddają wszystkiego. Dla zadań generatywnych:

• Testy A/B: Pokaż wyjście modelu bazowego i dostrajanego obok siebie. Poproś 3-5 ewaluatorów o wybranie lepszej odpowiedzi na 50+ przykładach. Śledź wskaźnik wygranych.
• Ocena w skali Likerta: Oceń odpowiedzi pod kątem trafności (1-5), dokładności (1-5) i tonu (1-5). Oblicz średnią poprawę względem modelu bazowego.

Sprawdzenie katastroficznego zapominania

To krok, który większość programistów pomija. Po dostrajaniu uruchom model na ogólnym benchmarku, takim jak MMLU lub HellaSwag. Jeśli wyniki spadną o więcej niż 2-3 punkty, Twój model stracił zbyt dużo wiedzy ogólnej. Rozwiązanie: zmniejsz learning rate, skróć liczbę epok lub przejdź na LoRA (które zamraża wagi bazowe).

Zasada praktyczna: Zawsze wydzielaj 10-20% swojego zestawu danych jako zbiór testowy. Nigdy nie ewaluuj na danych treningowych – to nic nie mówi o wydajności w świecie rzeczywistym.

Jak wdrożyć dostrajany model?

Trening zakończony. Teraz musisz go udostępnić. Większość przewodników całkowicie pomija tę część.

Krok 1: Scal adaptery LoRA

Jeśli używałeś LoRA lub QLoRA, scal adaptery z powrotem do modelu bazowego dla inferencji:

# Merge adapters into base model
model.merge_and_unload()
model.save_pretrained("merged-model")
tokenizer.save_pretrained("merged-model")

Krok 2: Wybierz ścieżkę wdrożenia

Lokalny rozwój i testy, Ollama:

# Convert to GGUF format (Ollama's native format)
python llama.cpp/convert_hf_to_gguf.py merged-model --outfile model.gguf --outtype q4_k_m

# Create an Ollama model
ollama create my-fine-tuned-model -f Modelfile
ollama run my-fine-tuned-model

Serwisowanie produkcyjne, vLLM:

# Start an OpenAI-compatible API server
python -m vllm.entrypoints.openai.api_server \
    --model merged-model \
    --host 0.0.0.0 \
    --port 8000

Serverless (zero infrastruktury): Prześlij swój model do Together AI, Fireworks lub Modal. Otrzymujesz endpoint API bez zarządzania serwerami. Koszt skaluje się z użyciem.

Zaawansowane: Serwisowanie wielu adapterów

Oto wzorzec, z którego powinno korzystać więcej zespołów: utrzymuj jeden model bazowy załadowany w pamięci i wymieniaj adaptery LoRA per żądanie. Możesz obsługiwać adapter wsparcia klienta, adapter review kodu i adapter sumaryzacji, wszystko z jednego GPU. vLLM obsługuje to natywnie z flagą --enable-lora.

Gotowy do implementacji? Zobacz nasze Najlepsze Narzędzia i Platformy do Dostrajania LLM [wkrótce] dla głębszego porównania opcji wdrożeniowych.

Jakie są najczęstsze błędy w dostrajaniu?

Po pomocy zespołom w debugowaniu dziesiątek procesów dostrajania, te błędy pojawiają się wciąż na nowo.

1. Overfitting na małych zestawach danych. Trenujesz przez 10 epok na 200 przykładach, loss treningowy spada do zera, a model papuguje Twoje dane treningowe słowo w słowo. Rozwiązanie: max 1-3 epoki, użyj zbioru walidacyjnego i obserwuj lukę między lossem treningowym a ewaluacyjnym.

2. Katastroficzne zapominanie. Model świetnie radzi sobie z Twoim konkretnym zadaniem, ale nie potrafi już prowadzić podstawowej rozmowy. Rozwiązanie: użyj LoRA/QLoRA (zamraża wagi bazowe), utrzymuj niskie learning rate (2e-5 dla pełnego dostrajania, 2e-4 dla QLoRA) i ewaluuj na ogólnych benchmarkach przed wdrożeniem.

3. Śmieciowa jakość danych. Niespójne formatowanie, sprzeczności między przykładami lub duplikaty. Model uczy się szumu. Rozwiązanie: oczyść dane przed treningiem. Zawsze. Poświęć więcej czasu na kurację danych niż na strojenie hiperparametrów.

4. Zaczynanie od zbyt dużego modelu. Zespoły skaczą na 70B, bo „większe jest lepsze”, a potem nie stać ich na koszty GPU. Rozwiązanie: zacznij od 8B. Jeśli 8B z dobrymi danymi nie rozwiąże Twojego zadania, 70B z tymi samymi danymi prawdopodobnie też nie. Najpierw zwiększ jakość danych, potem rozmiar modelu.

5. Brak potoku ewaluacji. Trening bez wydzielonego zbioru testowego, a następnie wdrożenie oparte na „wyczuciu”. Rozwiązanie: podziel dane 80/10/10 (train/val/test) zanim zaczniesz. Porównuj z modelem bazowym na każdym przykładzie testowym.

6. Zbyt wysoki learning rate. Niszczy wstępnie wytrenowaną wiedzę w pierwszych kilku krokach. Model generuje bełkot. Rozwiązanie: zacznij od 2e-4 dla QLoRA, 2e-5 dla pełnego dostrajania. Jeśli jakość wyjść spada, zmniejsz wartość.

Jak Techsy podchodzi do dostrajania LLM

W Techsy stosujemy ścisłą ścieżkę eskalacji dla każdego projektu AI: najpierw inżynieria promptów, potem RAG, a dostrajanie tylko wtedy, gdy dane证明ują, że jest potrzebne. Większość projektów klienckich tak naprawdę nie wymaga dostrajania – dobrze skonstruowane prompty lub potok RAG rozwiązują problem przy niższych kosztach i złożoności.

Gdy dostrajanie jest właściwym wyborem, oto nasz proces:

1. Audyt zestawu danych, Przeglądamy dane klienta pod kątem jakości, pokrycia i formatowania. Jeśli nie mamy wystarczającej liczby przykładów, pomagamy zbudować syntetyczny zestaw danych przy użyciu GPT-4 lub Claude z ludzkim przeglądem.
2. Wybór frameworku, Unsloth + QLoRA dla 90% projektów startupowych. Axolotl dla klientów potrzebujących reprodukowalnych, wieloprocesorowych potoków produkcyjnych.
3. Trening i ewaluacja, Zawsze trenujemy z wydzielonym zbiorem testowym i benchmarkujemy względem modelu bazowego. Jeśli dostrajany model nie mierzyalnie poprawia docelowej metryki, nie wdrażamy go.
4. Wdrożenie, vLLM do serwisowania produkcyjnego, wzorce multi-adapter, gdy klienci potrzebują wielu wyspecjalizowanych modeli z jednego GPU.

Wdrożyliśmy dostrajane modele dla startupów, których nie było stać na budżety enterprise GPU – QLoRA na RunPod utrzymuje koszty poniżej 30 USD nawet dla modeli 70B.

Potrzebujesz pomocy w dostrajaniu LLM do Twojego przypadku użycia? Pomagamy zespołom przejść od surowych danych do wdrożonego modelu. Umów bezpłatną konsultację

Często zadawane pytania dotyczące dostrajania LLM

Czym jest dostrajanie LLM?

Dostrajanie LLM to proces trenowania wstępnie wytrenowanego modelu językowego na własnych danych specyficznych dla zadania, aby lepiej wykonywał to zadanie. W zasadzie uczysz model nowych zachowań, formatów lub ekspertyzy domenowej, której ogólne prompty nie są w stanie osiągnąć w sposób niezawodny.

Kiedy należy dostrajać, a kiedy używać RAG?

Dostrajaj, gdy potrzebujesz, aby model zachowywał się inaczej – spójny format wyjścia, język specyficzny dla domeny, określony ton. Używaj RAG, gdy model musi wiedzieć inne rzeczy, zwłaszcza jeśli ta wiedza zmienia się często. W wielu systemach produkcyjnych najlepsze rezultaty daje podejście hybrydowe.

Ile kosztuje dostrajanie LLM?

Od 0 do 540 USD w zależności od skali. Większość indywidualnych deweloperów wydaje mniej niż 1 USD, używając QLoRA na RunPod RTX 4090 (0,34 USD/godz.). Model produkcyjny 70B na A100 kosztuje 17-27 USD. Pełne dostrajanie na klastrach H100 to wydatek 270-540 USD. Dostrajanie przez API (OpenAI) kosztuje 3-25 USD za 1000 przykładów.

Czy mogę dostrajać LLM na swoim laptopie?

Tak, jeśli Twój laptop ma GPU z 12+ GB VRAM. Laptopowe GPU RTX 3060 obsługuje modele 8B z QLoRA. Maci z Apple Silicon i 16+ GB zunifikowanej pamięci również mogą dostrajać przez MLX, choć jest to wolniejsze niż CUDA. Dla większych modeli będziesz potrzebować chmurowych GPU.

Jaka jest różnica między LoRA a QLoRA?

Obie metody dodają małe, trenowalne warstwy adapterów, zamrażając model bazowy. Różnica: QLoRA dodatkowo kwantyzuje model bazowy do precyzji 4-bitowej (typ danych NF4), zmniejszając zużycie VRAM o ~25% w porównaniu do standardowego LoRA. Jakość jest niemal identyczna, QLoRA osiąga 97-99% jakości pełnego dostrajania.

Ile przykładów treningowych potrzebuję?

To zależy od złożoności zadania. 50-100 przykładów wystarczy na proof of concept. 500-1000 przykładów daje użyteczne rezultaty dla większości pojedynczych zadań. 5000-10 000 przykładów dostarcza jakość produkcyjną dla złożonych zadań. Powyżej 10 000 następują malejące zwroty, chyba że zadanie ma ekstremalnie wysoką zmienność.

Jaki model bazowy dostrajać w 2026 roku?

Llama 3.x do zadań ogólnych (najlepszy stosunek jakości do rozmiaru). Mistral do języków europejskich i efektywnej inferencji. Qwen 2.5 do zadań wielojęzycznych i kodowania. Phi-4, gdy potrzebujesz najmniejszego możliwego footprintu. Gemma 2 do integracji z ekosystemem Google.

Czym jest GRPO i dlaczego ma znaczenie?

GRPO (Group Relative Policy Optimization), wprowadzone przez DeepSeek, to następca RLHF w treningu alignmentu. Kluczowa zaleta: nie wymaga trenowania osobnego modelu nagrody, co przecina koszty obliczeniowe mniej więcej o połowę. TRL v0.15.0 obsługuje GRPO natywnie, czyniąc go dostępnym dla każdego korzystającego z ekosystemu Hugging Face.

Jak zapobiec katastroficznemu zapominaniu?

Używaj LoRA lub QLoRA zamiast pełnego dostrajania – zamrażają one wagi modelu bazowego, co zachowuje wiedzę ogólną. Utrzymuj niski learning rate (2e-4 dla QLoRA, 2e-5 dla pełnego). Trenuj przez jak najmniej epok (1-3 zazwyczaj wystarcza). Po treningu uruchom model na ogólnych benchmarkach (MMLU, HellaSwag), aby upewnić się, że nie nastąpiła regresja.

Czy można łączyć dostrajanie z RAG?

Absolutnie, a wiele systemów produkcyjnych robi dokładnie to. Dostrajaj pod kątem zachowania i spójności formatu, a następnie podłącz RAG do pozyskiwania aktualnej wiedzy. Dostrajany model lepiej wykorzystuje pobrany kontekst, ponieważ rozumie język i wymagania wyjściowe Twojej domeny.

Ile trwa dostrajanie?

Dla większości projektów od 30 minut do 8 godzin. Model 8B z 500 przykładami na Unsloth + RTX 4090 kończy się w 15-30 minut. To samo zadanie na darmowym Colab T4 zajmuje 1-2 godziny. Modele 70B na A100 zajmują 5-8 godzin. Pełne dostrajanie na setupach wieloprocesorowych może trwać 20-40 godzin.

Czy API dostrajania OpenAI jest warte zachodu?

Do szybkiego prototypowania – tak. Możesz przesłać plik JSONL i mieć dostrajany GPT-4o-mini w 30 minut bez konfiguracji GPU. Do produkcji lokalne dostrajanie jest zwykle lepsze: posiadasz wagi, kontrolujesz prywatność danych, a koszty są niższe w skali. Większość zespołów zaczyna od API, aby zweryfikować podejście, a następnie migruje do lokalnego rozwiązania.

Podsumowanie

Dostrajanie LLM nie jest już czarną magią, jaką było dwa lata temu. Oto kluczowe wnioski:

1. Zacznij od QLoRA + Unsloth, obsługuje to 90% przypadków użycia na sprzęcie konsumenckim
2. Dobre dane biją większy model za każdym razem. Skup wysiłek na jakości zestawu danych, a nie na upgrade'ach GPU.
3. Bariera kosztowa zniknęła, dostrój model 8B za mniej niż 1 USD na chmurowych GPU
4. Zawsze ewaluuj względem modelu bazowego przed wdrożeniem. Jeśli nie jest mierzyalnie lepszy, nie wypuszczaj go.
5. Najpierw rozważ RAG, dostrajaj tylko wtedy, gdy potrzebujesz, aby model zachowywał się inaczej, a nie tylko wiedział inne rzeczy

Gotowy do implementacji? Zobacz nasze Najlepsze Narzędzia i Platformy do Dostrajania LLM [wkrótce] dla szczegółowego porównania frameworków treningowych i opcji wdrożeniowych.

Jeśli ten przewodnik był dla Ciebie przydatny, sprawdź nasz przewodnik po wyborze odpowiedniego stosu AI dla szerszych decyzji architektonicznych wokół produktów opartych na AI.

Źródła

• Repozytorium GitHub Unsloth, framework do dostrajania z 2-5x poprawą szybkości
• Dokumentacja Hugging Face TRL, implementacja SFTTrainer, DPO i GRPO
• Dokumentacja Hugging Face PEFT, LoRA i efektywne parametrycznie dostrajanie
• Artykuł QLoRA (Dettmers et al., 2023) -- badania nad 4-bitową kwantyzacją NormalFloat
• Artykuł LoRA (Hu et al., 2021), adaptacja o niskim rzędzie dużych modeli językowych
• Dokumentacja API Fine-Tuning OpenAI, workflow dostrajania oparty na API
• Cennik Chmury GPU RunPod, referencja kosztów chmurowych GPU
• Dokumentacja vLLM, produkcyjne serwisowanie LLM
• Przewodnik Meta Llama Fine-Tuning, oficjalne rekomendacje treningu Llama
• Artykuł DeepSeekMath (GRPO), Grupowa Relatywna Optymalizacja Polityki