Fine-tuning LoRA та QLoRA на практиці — коли, як і скільки

Коли компанія вирішує провести fine-tuning, найчастіше перше питання звучить: «яку відеокарту купити?». Це питання, задане зарано. Перш ніж дійти до обладнання та бюджету, варто зрозуміти, що LoRA та QLoRA насправді роблять і чому змінюють усю економіку цього підходу.

Повний fine-tuning модифікує всі ваги моделі. Для моделі 7B це кілька десятків мільярдів параметрів, кожен з яких зберігається як число з плаваючою комою. Таке навчання потребує від 40 GB VRAM і вище та практично недоступне без кластера GPU.

LoRA (Low-Rank Adaptation) розбиває оновлення ваг на дві значно менші матриці низького рангу. Замість модифікації всієї матриці ваг W (наприклад, 4096 × 4096), тренуються дві матриці A і B розміром 4096 × r та r × 4096, де r — гіперпараметр від 4 до 64. Під час інференсу адаптер просто додається до оригінальних ваг або завантажується окремо. Оригінальна модель залишається незмінною.

QLoRA додає квантизацію: оригінальна модель завантажується з точністю 4-bit (NF4), що вчетверо зменшує її обсяг у VRAM. Адаптери LoRA тренуються в 16-bit, тому градієнт обчислюється з вищою точністю. Отримана модель трохи повільніша при інференсі у квантизованій версії, але в багатьох завданнях різниця якості порівняно з повним fine-tuning є незначною.

Межа між LoRA та QLoRA проста: якщо VRAM є обмежувальним фактором, починайте з QLoRA.

Цифри передбачають batch size 1-4 з gradient checkpointing. Для порівняння: RTX 4090 з 24 GB VRAM підтримує QLoRA на моделях до 13B зручно, LoRA на 7B без квантизації, а повний fine-tuning 7B — лише з агресивним gradient checkpointing і малим батчем, що подовжує тренування.

Окреме питання — self-hosting готового адаптера. Після тренування адаптер LoRA — це файл розміром кільканадцять мегабайт, який накладається на базову модель. Для самого інференсу достатньо стільки VRAM, скільки займає базова модель, без тренувального навантаження.

Найпоширеніша помилка — зібрати тисячу випадкових прикладів замість трьохсот точних. Кілька перевірених принципів:

Мінімальні пороги. Менше 200 пар вхід-вихід fine-tuning рідко дає стабільний ефект. Діапазон 300-800 прикладів хорошої якості достатньо для вузьких завдань (класифікація, екстракція, генерація у визначеному шаблоні). Для ширшої зміни поведінки: від 1000 і вище.

Hold-out з самого початку. Виділіть 10-20% даних як тестовий набір ще до початку тренування. Ніколи не використовуйте ці пари для навчання чи вибору гіперпараметрів. Це єдиний показник, якому можна довіряти при ухваленні рішення про впровадження.

Узгодженість важливіша за різноманітність. Якщо ви тренуєте модель для генерації звітів у конкретному форматі, кожен приклад має дотримуватися цього формату. Кілька винятків у тренувальних даних можуть «навчити» модель, що формат є опціональним.

Персональні дані. Якщо пари тренування містять PII, діє RODO і, ймовірно, DPIA. Після тренування видалення конкретних даних з ваг технічно складне, що ускладнює реалізацію права на забуття у спосіб, неможливий при RAG. Рекомендуємо анонімізацію перед тренуванням або архітектуру, в якій тренувальні дані не залишають вашої інфраструктури.

Нижче шаблон, який ми використовуємо в Cashcrown при виробничих впровадженнях.

1. Базова оцінка. Перш ніж почати тренування, виміряйте, як базова модель справляється з вашим завданням на тестовому наборі даних. Це точка відліку, без якої ви не знатимете, чи покращив щось fine-tuning.

2. Підготовка даних. Уніфікований формат (наприклад, системна інструкція + вхід + вихід у форматі Alpaca або ChatML), анонімізація PII, перевірка узгодженості міток щонайменше двома людьми.

3. Тренування LoRA або QLoRA. Популярний стек: transformers + peft + bitsandbytes (для QLoRA) + trl (trainer). Ключові гіперпараметри: ранг r (почніть з 16), alpha (зазвичай 2×r), learning rate (1e-4 до 3e-4), кількість епох (3-5 для малих наборів). Логуйте кожен запуск у файл із датою, базовою моделлю та контрольною сумою даних.

4. Оцінка на hold-out. Для класифікації: F1 на клас, confusion matrix. Для генерації: ROUGE-L, BERTScore і, якщо можливо, людська оцінка вибірки 50-100 прикладів. Порівняйте з базовим значенням з кроку 1.

5. Рішення людини. Це не автоматичний етап. Хтось, відповідальний за продукт, переглядає результати та вирішує, чи впроваджувати адаптер. Для систем високого ризику (AI Act, Додаток III) цей крок потребує документування.

6. Впровадження адаптера. Адаптер LoRA можна обслуговувати через Ollama (GGUF + adapter), vLLM (native PEFT) або як окремий контейнер з базовою моделлю та завантаженим адаптером. Після впровадження моніторте дрейф. Якщо розподіл запитів значно змінюється відносно тренувальних даних, метрики на hold-out перестають бути показовими.

TCO fine-tuning — це не лише час GPU.

Повне впровадження від початку до продакшену рідко займає менше 3-4 тижнів. Проекти з чистими, готовими даними можуть вкластися у 2 тижні. Проекти, що потребують повної підготовки даних з нуля, перевищують 6 тижнів.

Порівняйте з міграцією з API на власну модель: розрахунок порогу рентабельності схожий, і варто його зробити, перш ніж залучати ресурси.

Fine-tuning змінює як модель поводиться, а не що модель знає. Це розрізнення зі статті коли fine-tuning має сенс варто повторити в контексті LoRA та QLoRA.

Адаптер, натренований на прикладах з 2024 року, не знатиме нормативів 2026 року. Модель після fine-tuning все ще галюцинує факти, яких немає у вагах. Це завдання для RAG, а не для адаптера. Найкращі виробничі архітектури, які ми бачимо, поєднують легкий fine-tuning (стиль, формат) з RAG (свіжі факти при кожному виклику). Деталі цього патерну описує стаття RAG чи fine-tuning.

Fine-tuning також не є механізмом безпеки. Адаптер не замінить guardrails, не усуне prompt injection і не обмежить модель до певної домену надійним чином. Безпеку будують пошарово, поза вагами моделі. Детальніше про обладнання та локальне середовище пише стаття локальні LLM: яке обладнання та GPU.

LoRA тренує невеликі матриці адаптерів, зберігаючи базову модель у повній точності (bf16 або fp16). QLoRA додатково квантизує базову модель до 4-bit NF4 перед тренуванням, що зменшує обсяг VRAM ще на 50-60%. Якість отриманого адаптера близька для більшості завдань класифікації та генерації; різниця помітна при дуже довгих послідовностях або вимозі високої числової точності.

Для вузького завдання (класифікація, екстракція, генерація у фіксованому шаблоні) реалістичний мінімум — 300-500 пар хорошої якості з виділеним hold-out 10-20%. Менше 200 пар — високий ризик нестабільного тренування або перенавчання. Для ширших змін поведінки моделі (зміна тону, обробка багатьох інтентів) потрібно від 1000 пар і більше. Якість міток важливіша за кількість.

На ноутбуці без дискретної відеокарти: ні. QLoRA на моделі 7B потребує відеокарти з менш ніж 12 GB VRAM (наприклад, RTX 3080/3090/4080/4090) або доступу до хмарної інстанції. На ноутбуці з інтегрованою графікою тренування технічно можливе на процесорі, але займе кілька днів замість кількох годин і зазвичай не є практичним. Альтернативою є хмарні обчислення: RunPod, Lambda Labs, Google Colab Pro.

Адаптер LoRA — це файл розміром кільканадцять мегабайт (набір матриць), який накладається на базову модель. На практиці: конвертуйте у формат GGUF з вбудованим адаптером (llama.cpp + --lora) або використовуйте vLLM з нативною підтримкою PEFT. Базову модель завантажуєте один раз, адаптер змінюєте без перезапуску в деяких фреймворках. Необхідне версіонування як адаптера, так і базової моделі, на якій він тренувався — невідповідність версій призводить до складних для дебагу помилок.

Коли проблема полягає у доступі до свіжих фактографічних даних — це завдання для RAG, а не fine-tuning. Коли тренувальних даних менше 200 пар або їхня якість низька. Коли ви оновлюєте базу знань частіше ніж раз на квартал, бо кожна зміна потребуватиме ретренування. Коли немає ресурсів на оцінку та підтримку нових версій адаптера. У цих випадках вибір моделі AI та RAG — дешевший і швидший старт.