Реалізація LoRA-адаптації LLM для мобільного застосунку

Реалізація LoRA-адаптації LLM для мобільного додатку

Full fine-tuning Llama 3 8B вимагає 80 ГБ GPU-пам'яті та кілька днів навчання. LoRA (Low-Rank Adaptation) досягає порівнянної якості, заморозивши оригінальні ваги та навчаючи тільки малі матриці-адаптери. На практиці — A100 40GB замість кластерів, години замість днів, та 50–300 МБ адаптер замість 16 ГБ чекпоінта.

Як LoRA працює технічно

Оригінальна матриця ваг W розміром d × k не змінюється. Замість неї навчаються дві матриці: A розміром d × r та B розміром r × k, де r — ранг адаптації (гіперпараметр, зазвичай 8–64). При інференсі: W_new = W + α * (A × B), де α — коефіцієнт масштабування.

Ключові гіперпараметри:

• r (rank) — чим вищий, тим більше параметрів навчається і тим дорожча адаптація. r=16 — розумний старт
• lora_alpha — зазвичай 2r або r. Контролює "силу" адаптації при слиянні ваг
• target_modules — які шари адаптувати. Для трансформерів: q_proj, v_proj, k_proj, o_proj та опціонально gate_proj, up_proj, down_proj
• lora_dropout — регуляризація, 0.05–0.1 для малих датасетів

Навчання: Unsloth + Hugging Face PEFT

Unsloth прискорює LoRA-навчання на 2–5x порівняно з чистим PEFT через користувацькі CUDA-ядра:

from unsloth import FastLanguageModel
import torch

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Meta-Llama-3.1-8B-Instruct",
    max_seq_length=2048,
    dtype=torch.float16,
    load_in_4bit=True  # QLoRA: 4-бітна квантизація + LoRA
)

model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    target_modules=["q_proj", "v_proj", "k_proj", "o_proj",
                    "gate_proj", "up_proj", "down_proj"],
    lora_alpha=32,
    lora_dropout=0.05,
    bias="none",
    use_gradient_checkpointing="unsloth"
)

QLoRA — LoRA поверх 4-бітної квантизації базової моделі. Llama 3 8B у 4-bit займає ~5 ГБ VRAM замість 16 ГБ у fp16. Мінімальний GPU для QLoRA навчання — RTX 3090 (24 ГБ) або орендований A100 на RunPod/Lambda Labs.

Деплой адаптера: серверний vs on-device

Після навчання адаптер зберігається окремо від базової моделі. Два шляхи інтеграції з мобільним додатком:

Серверний деплой через vLLM або Ollama. Базова модель на сервері, адаптер застосовується при ініціалізації або у runtime. Мобільний додаток працює через API-ендпоінт — жодного вантажу моделі на пристрої.

# vLLM з LoRA адаптером
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --enable-lora \
  --lora-modules my-adapter=/path/to/lora/adapter

On-device через llama.cpp / Core ML. Можливо тільки для малих моделей зі слиянням ваг (merge + GGUF). Для мобільних реально: Llama 3.2 3B або Phi-3.5-mini 3.8B з LoRA-адаптером, слитим в GGUF Q4_K_M. Остаточний розмір моделі — 2–3 ГБ, укладається в можливості iPhone 14+ та Galaxy S23+.

# Слиання ваг перед експортом у GGUF
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./merged-model")
# Далі: llama.cpp convert + quantize → .gguf файл

На iOS такий GGUF запускається через llama.swift або через MLModel (конвертуйте в Core ML через coremltools). На Android — llama.cpp через JNI або MediaPipe LLM Inference API для Gemma-моделей.

Типові помилки при LoRA-адаптації

Неправильний target_modules. Якщо адаптувати тільки q_proj, v_proj, пропустивши gate_proj та up_proj в MLP-блоках — ефект буде слабким. Для instruction-following задач важливо адаптувати всі проекційні шари.

Занадто малий датасет. LoRA зі 100 прикладами переобучиться швидше, ніж покращиться. Для доменної адаптації потрібно мінімум 300–500 різноманітних прикладів.

База не заморожена при слиянні. Після merge_and_unload() перевірте, що оригінальні ваги не змінилися порівняно з базовою моделлю — це сигналізує про правильну роботу LoRA.

Орієнтири за часом

Підготовка тренувального датасету — 1–2 тижні. Налаштування середовища (RunPod + Unsloth) та запуск навчання — 1–2 дні. Конвертація та тестування адаптера — 2–3 дні. Інтеграція серверного API в мобільний додаток — 2–4 дні. Повний цикл — від 2 до 4 тижнів.