# Dresaj avansat de dragoni: QLoRA, DPO si cuantizare
Ember zboara si asculta comenzi. Aceasta lectie este scoala avansata de zbor: antrenarea unor dragoni *mai mari* pe acelasi hardware (QLoRA), predarea *judecatii* in loc de imitatie (DPO) si micsorarea modelului antrenat pentru deploy rapid (cuantizare + GGUF). Aceste trei tehnici sunt cele care despart experimentele de weekend de modelele pe care le rulezi in fiecare zi.
## QLoRA: antrenare peste categoria ta de greutate
Ai folosit deja incarcarea pe 4-bit in lectia 5 pe calea PC — acela *era* QLoRA. Acum hai sa-l folosim deliberat, pentru scopul lui adevarat: **antrenarea modelelor care altfel nu incap.**
Ideea: comprimi ponderile de baza inghetate la precizie de 4 biti (format NF4), pastrezi adapterele LoRA pe 16-bit. Baza pierde o farama de calitate din compresie, dar pentru ca adapterele — partea care invata — raman la precizie completa, rezultatele finale ajung remarcabil de aproape de LoRA complet.
Din tabelul lectiei 3, QLoRA e ceea ce deblocheaza plafonul fiecarei masini:
- **RTX 4090 (24 GB):** 14B confortabil, 32B la limita (context scurt, batch 1, gradient checkpointing — asteapta-te la o lupta).
- **M3 Ultra (96 GB):** 32B cu spatiu de rezerva; 70B e posibil daca accepti antrenari peste noapte.
Cand ar trebui Ember sa avanseze de la 4B? Doar cand evaluarea o spune: daca v3+ continua sa esueze la *substanta* (rationament slab in raspunsuri complexe) in timp ce formatul si tonul sunt solide, acela e simptomul "model de baza prea mic" din lectia 6 — sari la Qwen3-8B sau 14B si ruleaza din nou acelasi pipeline. Nimic altceva nu se schimba; asta e frumusetea configurarii.
Pro Tip
Scalarea de la 4B la 8B cam dubleaza timpul de antrenare si memoria — de obicei merita. 14B → 32B le dubleaza din nou pentru un salt de calitate mai mic pe sarcini simple. Lasa scorurile de test sa justifice fiecare salt, nu laudele cu marimea modelului.
## DPO: predarea gustului, nu doar a trucurilor
Fine-tuning-ul supervizat (tot ce am facut pana acum) ii arata modelului raspunsuri *bune*. **DPO — Direct Preference Optimization** — ii arata *perechi*: pentru acelasi prompt, un raspuns **ales** (chosen) si unul **respins** (rejected). Modelul invata *directia* preferintelor tale: ce face un raspuns mai bun decat altul.
```json
{"prompt": "Customer: You people are useless! Where is my package?!",
"chosen": "I understand the frustration — let's fix this properly. [calm, structured answer with next step]",
"rejected": "We apologize for any inconvenience caused. Your satisfaction is important to us. [corporate mush, no next step]"}
```
Concept
SFT invata "iata cum arata un raspuns bun". DPO invata "intre aceste doua raspunsuri plauzibile, prefera genul acesta". Straluceste exact acolo unde SFT atinge un platou: judecata subtila de stil, dezescaladarea, alegerea conciziei, evitarea limbajului de lemn corporatist — lucruri greu de demonstrat, dar usor de comparat.
Ordinea retetei conteaza: **intotdeauna SFT intai, apoi DPO deasupra** — tipic 100–500 de perechi de preferinte, cu un learning rate mai mic (~5e-6). Cele mai bune raspunsuri respinse nu sunt oameni de paie; sunt iesirile reale, plauzibile-dar-cu-defecte, ale *propriului tau model* din rundele de evaluare. Pe calea PC, asta e `DPOTrainer` din `trl` cu aceeasi configurare Unsloth; pe Mac, `mlx-lm` vine cu suport pentru preference training (verifica `mlx_lm.lora --help` pentru flag-urile curente — ecosistemul se misca repede).
Nota sincera
DPO e un condiment, nu o masa. Pe un model mic cu un SFT solid, 200 de perechi bune ascut vizibil judecata de ton. DPO nu poate salva un SFT prost, iar exagerarea (prea multe epoci, learning rate prea mare) produce un model care e ciudat cu incredere. Daca ai o singura seara, petrece-o pe date SFT mai bune.
## Cuantizarea: micsorarea dragonului pentru zborul zilnic
Precizia de antrenare si precizia de servire sunt jocuri diferite. Odata ce Ember e final, il vei vrea **mic si rapid** pentru uz zilnic. Aceea e cuantizarea la inferenta, iar formatul universal pentru ea este **GGUF** — formatul pe care il vorbesc Ollama, LM Studio si llama.cpp.
Pipeline-ul, pe oricare dintre masini:
Primul pas e merge-ul — contopirea adapterelor in ponderile de baza, ca sa obtii un singur model de sine statator:
```bash
# Mac (MLX)
mlx_lm.fuse --model Qwen/Qwen3-4B-Instruct \
--adapter-path adapters/ember-v3 --save-path ember-merged
```
```python
# PC (Unsloth) — can even save GGUF directly:
model.save_pretrained_merged("ember-merged", tokenizer)
model.save_pretrained_gguf("ember-gguf", tokenizer, quantization_method="q4_k_m")
```
**Q4_K_M** este punctul dulce implicit al comunitatii: ~4.5 biti per pondere, pierdere de calitate abia masurabila pe majoritatea sarcinilor, marime taiata de ~4× fata de 16-bit. Foloseste Q8_0 cand vrei aproape-fara-pierderi si ai memoria; coboara sub Q4 doar daca esti disperat dupa memorie.
Incearca
Ia cel mai bun Ember al tau, fa merge, converteste, cuantizeaza la Q4_K_M — apoi ruleaza setul de test din lectia 6 pe modelul cuantizat. Compara scorurile cu versiunea necuantizata. Sa vezi (numeric!) ca Q4_K_M abia ti-a miscat metricile e felul in care castigi increderea de a face deploy mic.
Checkpoint
Stii cand QLoRA deblocheaza baze mai mari, cand DPO adauga judecata peste SFT si cum merge → GGUF → Q4_K_M transforma un artefact de antrenare intr-un fisier de model gata de deploy. A mai ramas un singur lucru: eliberarea dragonului tau in lume.