# Fortgeschrittenes Drachentraining: QLoRA, DPO und Quantisierung Ember fliegt und befolgt Befehle. Diese Lektion ist die fortgeschrittene Flugschule: *groessere* Drachen auf derselben Hardware trainieren (QLoRA), *Urteilsvermoegen* statt Imitation lehren (DPO), und dein trainiertes Modell fuer schnelles Deployment schrumpfen (Quantisierung + GGUF). Diese drei Techniken trennen Wochenend-Experimente von Modellen, die du jeden Tag laufen laesst. ## QLoRA: Trainieren ueber deiner Gewichtsklasse Du hast 4-bit-Loading bereits in Lektion 5 auf dem PC-Pfad genutzt — das *war* QLoRA. Jetzt setzen wir es bewusst ein, fuer seinen eigentlichen Zweck: **Modelle trainieren, die sonst nicht passen.** Die Idee: Komprimiere die eingefrorenen Basisgewichte auf 4-bit-Praezision (NF4-Format), behalte die LoRA-Adapter in 16-bit. Die Basis verliert durch die Kompression einen Hauch Qualitaet, aber da die Adapter — der Teil, der lernt — in voller Praezision bleiben, landen die Endergebnisse bemerkenswert nah am vollen LoRA. Aus der Tabelle von Lektion 3: QLoRA ist das, was die Obergrenze jeder Maschine freischaltet: - **RTX 4090 (24 GB):** 14B komfortabel, 32B gerade so (kurzer Kontext, Batch 1, Gradient Checkpointing — rechne mit einem Kampf). - **M3 Ultra (96 GB):** 32B mit Luft nach oben; 70B ist moeglich, wenn du Overnight-Laeufe akzeptierst. Wann sollte Ember von 4B upgraden? Nur wenn die Evaluation es sagt: Wenn v3+ weiter an der *Substanz* scheitert (schwaches Reasoning bei komplexen Antworten), waehrend Format und Ton solide sind, ist das das "Basismodell zu klein"-Symptom aus Lektion 6 — spring auf Qwen3-8B oder 14B und fahre dieselbe Pipeline erneut. Sonst aendert sich nichts; das ist die Schoenheit dieses Setups.

Profi-Tipp

Von 4B auf 8B zu skalieren verdoppelt grob Trainingszeit und Speicher — meist lohnt es sich. 14B → 32B verdoppelt es nochmal, fuer einen kleineren Qualitaetssprung bei einfachen Aufgaben. Lass deine Test-Scores jeden Sprung rechtfertigen, nicht das Angeberrecht auf Modellgroesse.
## DPO: Geschmack lehren, nicht nur Tricks Supervised Fine-Tuning (alles bisher) zeigt dem Modell *gute* Antworten. **DPO — Direct Preference Optimization** — zeigt ihm *Paare*: fuer denselben Prompt eine **gewaehlte** Antwort und eine **abgelehnte**. Das Modell lernt die *Richtung* deiner Praeferenzen: was eine Antwort besser macht als eine andere. ```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]"} ```

Konzept

SFT lehrt: "So sieht eine gute Antwort aus". DPO lehrt: "Zwischen diesen zwei plausiblen Antworten bevorzuge diese Art". Es glaenzt genau da, wo SFT ein Plateau erreicht: subtiles Stil-Urteilsvermoegen, Deeskalation, Kuerze waehlen, Corporate-Fueller vermeiden — Dinge, die schwer zu demonstrieren, aber leicht zu vergleichen sind.
Die Reihenfolge des Rezepts zaehlt: **immer zuerst SFT, dann DPO obendrauf** — typischerweise 100–500 Praeferenz-Paare, mit einer niedrigeren Learning Rate (~5e-6). Die besten abgelehnten Antworten sind keine Strohmaenner; es sind die echten, plausibel-aber-fehlerhaften Ausgaben *deines eigenen Modells* aus Evaluationslaeufen. Auf dem PC-Pfad ist das der `DPOTrainer` von `trl` mit demselben Unsloth-Setup; auf dem Mac bringt `mlx-lm` Preference-Training-Support mit (schau mit `mlx_lm.lora --help` nach den aktuellen Flags — das Oekosystem bewegt sich schnell).

Ehrlicher Hinweis

DPO ist ein Gewuerz, keine Mahlzeit. Auf einem kleinen Modell mit solidem SFT schaerfen 200 gute Paare das Ton-Urteilsvermoegen merklich. DPO kann ein schlechtes SFT nicht retten, und es zu uebertreiben (zu viele Epochen, zu hohe Learning Rate) produziert ein Modell, das selbstbewusst seltsam ist. Wenn du nur einen Abend hast, steck ihn in bessere SFT-Daten.
## Quantisierung: Den Drachen fuer den Alltagsflug schrumpfen Trainings-Praezision und Serving-Praezision sind verschiedene Spiele. Sobald Ember final ist, willst du es **klein und schnell** fuer den taeglichen Gebrauch. Das ist Quantisierung zur Inferenzzeit, und das universelle Format dafuer ist **GGUF** — das Format, das Ollama, LM Studio und llama.cpp alle sprechen. Die Pipeline, auf beiden Maschinen: Adapter mergen Basis + LoRA → ein Modell Nach GGUF konvertieren llama.cpp-Convert-Skript Quantisieren Q4_K_M ~8 GB → ~2,5 GB (4B) Servieren Ollama · LM Studio Schritt eins ist das Mergen — deine Adapter in die Basisgewichte einfalten, sodass du ein einzelnes eigenstaendiges Modell bekommst: ```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** ist der Standard-Sweet-Spot der Community: ~4,5 Bits pro Gewicht, Qualitaetsverlust bei den meisten Aufgaben kaum messbar, Groesse ~4× kleiner als 16-bit. Nimm Q8_0, wenn du nahezu verlustfrei willst und den Speicher hast; geh unter Q4 nur, wenn du speicher-verzweifelt bist.

Probier es aus

Nimm dein bestes Ember, merge, konvertiere, quantisiere zu Q4_K_M — und fahre dann dein Test-Set aus Lektion 6 auf dem quantisierten Modell. Vergleiche die Scores mit der unquantisierten Version. (Numerisch!) zu sehen, dass Q4_K_M deine Metriken kaum bewegt hat — so verdienst du dir das Selbstvertrauen, klein zu deployen.

Checkpoint

Du weisst, wann QLoRA groessere Basen freischaltet, wann DPO Urteilsvermoegen auf SFT draufsetzt, und wie Merge → GGUF → Q4_K_M ein Trainingsartefakt in eine deploybare Modelldatei verwandelt. Eine Sache bleibt: deinen Drachen in die Welt entlassen.