Der vollstandige Leitfaden zu LoRA / QLoRA Fine-Tuning: Mit Consumer-GPUs ein massgeschneidertes LLM erstellen

I. Das Dilemma des vollstandigen Fine-Tunings: Warum wir parametereffizientes Fine-Tuning benotigen

Wenn Sie ein vortrainiertes Large Language Model (LLM) dazu bringen mochten, domainspezifisches Wissen oder Verhalten zu erlernen, ist der naheliegendste Ansatz das vollstandige Fine-Tuning (Full Fine-tuning): Alle Parameter werden aufgetaut und auf neuen Daten weitertrainiert. Diese Methode ist einfach und effektiv, stosst aber in der LLM-Ara auf drei schwer uberwindbare Hurden:

Speicherwand: Vollstandiges Fine-Tuning erfordert, dass Modellgewichte, Gradienten und Optimizer-Zustande (AdamW benotigt zwei zusatzliche Momentum-Puffer) gleichzeitig im GPU-Speicher gehalten werden. Am Beispiel von LLaMA-2-7B: Die FP16-Gewichte belegen 14 GB, die Gradienten 14 GB und die AdamW-Optimizer-Zustande 28 GB -- allein die Trainingszustande benotigen uber 56 GB GPU-Speicher und uberschreiten damit die Kapazitat jeder Consumer-GPU. Ein 70B-Modell benotigt mindestens 560 GB und damit 8 A100-80GB-GPUs.

Speicherplatzwand: Vollstandiges Fine-Tuning erzeugt einen vollstandigen Checkpoint in der gleichen Grosse wie das Originalmodell. Bei 10 Downstream-Aufgaben mussen 10 vollstandige 70B-Modelle gespeichert werden (jeweils 140 GB), insgesamt 1,4 TB. Fur Unternehmen, die mehrere Kunden oder Aufgaben bedienen mussen, ist dies unpraktisch.

Lebenslanges-Lernen-Wand: Vollstandiges Fine-Tuning fuhrt leicht dazu, dass das Modell sich zu stark an neue Daten anpasst und das wahrend des Pre-Trainings erlernte allgemeine Wissen vergisst. Dieses Problem ist bei kleinen Datensatzen besonders gravierend -- wenn man ein 70B-Modell mit einigen tausend Datensatzen fine-tuned, erhalt man oft keine „verbesserte Version", sondern eine „beschadigte Version".

Diese Schwierigkeiten haben die Forschungsrichtung des parametereffizienten Fine-Tunings (Parameter-Efficient Fine-Tuning, PEFT) hervorgebracht^[10]: Ist es moglich, nur eine ausserst geringe Anzahl von Parametern zu trainieren und das Modell dennoch neue Aufgaben erlernen zu lassen? Die Ubersichtsarbeit von Lialin et al.^[13] hat diese Entwicklung systematisch aufgearbeitet -- von den Adapter Layers im Jahr 2019 bis hin zu LoRA im Jahr 2022 haben PEFT-Methoden einen uberraschend guten Kompromiss zwischen Speichereffizienz und Trainingsqualitat gefunden.

II. Das Kernprinzip von LoRA: Die elegante Mathematik der Low-Rank-Zerlegung

2.1 Kernidee: Gewichtsaktualisierungen sind niedrigrangig

2021 schlugen Edward Hu et al. von Microsoft Research LoRA (Low-Rank Adaptation)^[1] vor, dessen Kernhypothese ausserst elegant ist: Die Gewichtsaktualisierungsmatrix ΔW wahrend des Fine-Tunings hat einen sehr niedrigen „intrinsischen Rang" (intrinsic rank) -- selbst wenn ΔW eine riesige Matrix ist (z. B. 4096 x 4096), lasst sich ihre effektive Information durch zwei Matrizen darstellen, die wesentlich kleiner sind als die ursprunglichen Dimensionen.

Dies ist keine unbegrundete Annahme. Aghajanyan et al. haben in ihrer Forschung von 2021^[9] theoretisch bewiesen, dass vortrainierte Sprachmodelle eine extrem niedrige intrinsische Dimensionalitat (Intrinsic Dimensionality) besitzen. Konkret fanden sie heraus, dass die intrinsische Dimensionalitat von RoBERTa-Large (355M Parameter) nur etwa 200 betragt -- das bedeutet, dass fur das Fine-Tuning dieses Modells nur 200 Freiheitsgrade angepasst werden mussen, um uber 90 % der Leistung eines vollstandigen Fine-Tunings zu erreichen. Diese Erkenntnis lieferte eine solide theoretische Grundlage fur LoRA.

2.2 Mathematische Formel: Low-Rank-Zerlegung

Die mathematische Darstellung von LoRA ist ausserst pragnant. Fur eine Gewichtsmatrix W₀ ∈ R^{d x k} im vortrainierten Modell lernt das vollstandige Fine-Tuning ein Update ΔW ∈ R^{d x k}, sodass das neue Gewicht lautet:

# Vollstandiges Fine-Tuning
W = W₀ + ΔW       # ΔW hat d x k trainierbare Parameter

# LoRA: ΔW wird in das Produkt zweier Low-Rank-Matrizen zerlegt
W = W₀ + B @ A     # B ∈ R^{d x r}, A ∈ R^{r x k}
                    # Trainierbare Parameter = d*r + r*k = r*(d+k)
                    # Wenn r << min(d, k), wird die Parameteranzahl drastisch reduziert

# Konkretes Beispiel: Attention-Layer von LLaMA-7B
# d = k = 4096, Vollstandiges Fine-Tuning: 4096 x 4096 = 16.777.216 Parameter
# LoRA (r=16): 4096 x 16 + 16 x 4096 = 131.072 Parameter
# Kompressionsrate: 128-fach!

# Forward Pass
# h = W₀ @ x + (B @ A) @ x * (alpha / r)
# wobei alpha/r der Skalierungsfaktor ist, der die Starke des LoRA-Updates steuert

Zentrale Designentscheidungen beim Training:

• Einfrieren von W₀: Die ursprunglichen vortrainierten Gewichte bleiben vollstandig unverandert, Gradienten mussen nicht berechnet werden, was erheblich Speicher spart
• Initialisierung: A wird mit Gauss-Zufallswerten initialisiert, B wird als Nullmatrix initialisiert -- dies stellt sicher, dass zu Trainingsbeginn ΔW = B @ A = 0 gilt und das Modell vom vortrainierten Zustand ausgeht
• Skalierungsfaktor alpha/r: alpha ist eine Konstante (typischerweise ein Vielfaches von r), die die Lernrate uber verschiedene Rank-Einstellungen hinweg stabilisiert -- bei zunehmendem r wird der Beitrag jedes Parameters proportional verdunnt
• Keine Inferenzverzogerung: Bei der Inferenz konnen die LoRA-Gewichte zurück in die ursprungliche Matrix integriert werden: W = W₀ + BA, ohne jeglichen zusatzlichen Rechenaufwand

2.3 Die Hyperparameter von LoRA: Rank, Alpha, Target Modules

Die Wirksamkeit von LoRA hangt stark von drei Hyperparametern ab:

Rank r (Rang): Der wichtigste Hyperparameter. Je grosser r, desto starker die Ausdrucksfahigkeit von LoRA, aber auch desto mehr trainierbare Parameter. Die Experimente im Originalpaper zeigen, dass r = 4 bis r = 64 in der Regel die meisten Aufgabenanforderungen abdecken. Praktische Empfehlungen: Einfache Aufgaben (Formatkonvertierung, Stiltransfer) mit r = 8-16; komplexe Aufgaben (Domainwissen, mehrstufiges Reasoning) mit r = 32-64; extrem komplexe Aufgaben konnen r = 128-256 erproben, wobei Overfitting uberwacht werden sollte.

Alpha (Skalierungskoeffizient): Steuert die Starke des LoRA-Updates relativ zu den ursprunglichen Gewichten. Die gangige Praxis ist alpha = 2r (z. B. r=16 mit alpha=32), um eine stabile effektive Lernrate zu gewahrleisten. Manche Forscher empfehlen auch, alpha=16 konstant zu halten, unabhangig von r, und stattdessen die Update-Starke uber die Lernrate zu regulieren.

Target Modules (Zielmodule): Bestimmen, in welche Schichten LoRA injiziert wird. Die ursprunglichen Experimente von Hu et al. zeigten, dass die gleichzeitige Injektion von LoRA in die vier Attention-Projektionsmatrizen Q, K, V und O die besten Ergebnisse liefert^[1]. Neuere praktische Erfahrungen zeigen daruber hinaus, dass die Einbeziehung der MLP-Schichten (gate_proj, up_proj, down_proj) in die Target Modules in der Regel zu einer zusatzlichen Qualitatsverbesserung fuhrt, allerdings auf Kosten einer etwa 2-fachen Erhohung der trainierbaren Parameter.

III. QLoRA: Die doppelte Kompression aus 4-bit-Quantisierung und LoRA

LoRA hat die Anzahl der trainierbaren Parameter bereits drastisch reduziert, doch die eingefrorenen Gewichte mussen weiterhin in den GPU-Speicher geladen werden. Die eingefrorenen Gewichte von LLaMA-7B belegen in FP16 14 GB -- das uberschreitet immer noch den sicheren Bereich der kostenlosen Google Colab T4 (16 GB). 2023 losten Tim Dettmers et al. dieses Problem mit QLoRA^[2]: Das eingefrorene Basismodell wird auf 4-bit quantisiert, und darauf wird ein LoRA-Adapter mit 16-bit-Prazision fur das Fine-Tuning injiziert.

QLoRA wurde auf der NeurIPS 2023 als Oral angenommen -- die hochste Akzeptanzstufe dieser Top-Konferenz -- und bewies in der Arbeit: Mit QLoRA fine-getunte Modelle zeigen qualitativ keinen statistisch signifikanten Unterschied zum Full-Precision Full Fine-Tuning. Das bedeutet, dass Sie mit 1/4 des Speichers nahezu identische Fine-Tuning-Ergebnisse erzielen konnen.

3.1 NF4: Ein massgeschneidertes Quantisierungsformat fur Normalverteilungen

QLoRA fuhrt einen vollig neuen Datentyp ein: NormalFloat4 (NF4). Die zentrale Erkenntnis ist: Die Gewichtsverteilungen vortrainierter neuronaler Netze nahern sich einer um Null zentrierten Normalverteilung an. Dementsprechend sollten die Quantisierungspunkte (Quantile) der Normalverteilung entsprechen und nicht der traditionellen Gleichverteilung.

NF4 funktioniert folgendermassen: Es werden die 16 gleichwahrscheinlichen Quantile der Standardnormalverteilung N(0,1) berechnet und jedes Gewicht auf das nachste Quantil abgebildet. Dies stellt sicher, dass jedes Quantisierungsintervall ungefahr die gleiche Anzahl von Gewichtswerten enthalt, wodurch die Informationserhaltung maximiert wird. Experimente zeigen, dass der Quantisierungsfehler von NF4 um 10-30 % niedriger ist als bei herkommlichem INT4 oder FP4.

3.2 Doppelte Quantisierung (Double Quantization)

Die Quantisierung selbst erfordert die zusatzliche Speicherung von „Quantisierungskonstanten" (Quantization Constants) -- je 64 Gewichte teilen sich einen FP32-Skalierungsfaktor. Bei grossen Modellen ist der Speicheraufwand fur diese Konstanten nicht vernachlassigbar: Pro Parameter fallen im Durchschnitt zusatzlich 0,5 Bit an.

Die doppelte Quantisierung von QLoRA quantisiert diese Quantisierungskonstanten ihrerseits erneut: FP32-Konstanten werden auf FP8 komprimiert, wodurch der zusatzliche Aufwand von 0,5 bit/param auf 0,127 bit/param sinkt. Bei einem 65B-Modell spart dies etwa 3 GB GPU-Speicher.

3.3 Paged Optimizers

Wahrend des Trainings kann der Spitzenspeicherbedarf der Gradientenberechnung die verfugbare GPU-Kapazitat kurzfristig uberschreiten -- insbesondere bei der Verarbeitung langer Sequenzen. QLoRA nutzt den automatischen Seitenmigrationsmechanismus von NVIDIA Unified Memory: Wenn der GPU-Speicher nicht ausreicht, werden Optimizer-Zustande vorubergehend in den CPU-Speicher verschoben und bei Bedarf zuruckmigriert. Dies verhindert Out-of-Memory-Absturze auf Kosten einer geringfugigen Geschwindigkeitseinbusse.

3.4 Speichervergleich

Die Tabelle zeigt deutlich die bahnbrechende Bedeutung von QLoRA: Das Fine-Tuning eines 65B-Modells, das zuvor 8 A100-GPUs erforderte, kann nun mit einer einzigen 48-GB-A6000 durchgefuhrt werden. Und das Fine-Tuning eines 7B-Modells lasst sich sogar auf der kostenlosen Google Colab T4 (16 GB) ausfuhren. Damit erhalten individuelle Entwickler und kleine Teams erstmals die Moglichkeit, grosse Sprachmodelle zu fine-tunen.

IV. DoRA und VeRA: Die Evolution von LoRA

4.1 DoRA: Weight-Decomposed Low-Rank Adaptation

LoRA liefert in den meisten Szenarien hervorragende Ergebnisse, doch bei bestimmten Aufgaben, die eine gleichzeitige erhebliche Anpassung von Gewichts-„Richtung" und „Grosse" erfordern, besteht weiterhin eine Lucke zum vollstandigen Fine-Tuning. 2024 veroffentlichten Liu et al. auf der ICML DoRA (Weight-Decomposed Low-Rank Adaptation)^[3], das eine elegante Verbesserung vorschlagt.

Die Kernidee von DoRA ist: Die Gewichtsmatrix wird in die Komponenten Grosse (Magnitude) und Richtung (Direction) zerlegt, dann wird nur auf die Richtungskomponente ein LoRA-Update angewendet, wahrend die Grossenkomponente unabhangig gelernt wird:

# Gewichtsaktualisierung beim vollstandigen Fine-Tuning
W' = W₀ + ΔW

# Gewichtszerlegung bei DoRA
# 1. W wird in Magnitude m und Direction V zerlegt
#    W = m * (V / ||V||_c)   # ||V||_c ist die L2-Norm pro Zeile
#
# 2. Nur auf die Richtung V wird ein LoRA-Update angewendet
#    V' = V + BA             # BA ist das Standard-LoRA-Low-Rank-Update
#
# 3. Magnitude m als unabhangiger lernbarer Parameter
#    W' = m' * ((V + BA) / ||V + BA||_c)

# Zusatzliche Parameteranzahl von DoRA im Vergleich zu LoRA: nur d Magnitude-Parameter
# Fur eine 4096-dimensionale Schicht sind das nur 4096 Parameter (vernachlassigbar)

Die DoRA-Arbeit zeigt durch Analyse der Gradientenaktualisierungsmuster beim vollstandigen Fine-Tuning: Vollstandiges Fine-Tuning tendiert dazu, Richtung und Grosse gleichzeitig erheblich anzupassen, wahrend Standard-LoRA dazu neigt, beide zu koppeln und keine unabhangige Steuerung zu ermoglichen. Die Zerlegung von DoRA ermoglicht es dem Low-Rank-Update, das Verhalten des vollstandigen Fine-Tunings praziser zu simulieren. Experimentelle Ergebnisse: Bei Commonsense Reasoning, Visual Instruction Tuning und anderen Aufgaben ubertrifft DoRA LoRA bei gleichem Rank durchgehend und nahert sich in einigen Aufgaben sogar der Leistung des vollstandigen Fine-Tunings.

4.2 VeRA: Auf der Suche nach ultimativer Parametereffizienz

Wenn die Richtung von LoRA lautet „mit weniger Parametern eine Leistung nahe dem vollstandigen Fine-Tuning zu erzielen", dann treibt VeRA (Vector-based Random Matrix Adaptation)^[12] diese Idee bis zum Aussersten.

VeRA funktioniert wie folgt: Die A- und B-Matrizen von LoRA werden eingefroren (mit gemeinsam genutzten Zufallsmatrizen initialisiert), und nur zwei diagonale Skalierungsvektoren d und b werden trainiert. Das bedeutet, dass verschiedene Schichten dieselbe zufallige Projektion teilen und die trainierbaren Parameter nur d + k Vektorelemente umfassen -- uber 10-mal weniger als LoRA.

VeRA wurde auf der ICLR 2024 veroffentlicht und erreichte auf dem GLUE-Benchmark mit nur 1/10 der LoRA-Parameter eine vergleichbare Leistung. Bei komplexeren generativen Aufgaben bleibt die Leistung von VeRA jedoch hinter LoRA zuruck, weshalb es derzeit eher als Option fur extrem ressourcenbeschrankte Szenarien geeignet ist.

V. PEFT-Gesamtubersicht: Vergleich von Adapter, Prefix-Tuning und Prompt Tuning

LoRA ist nicht die einzige parametereffiziente Fine-Tuning-Methode. Das Verstandnis des gesamten PEFT-Okosystems^[7] hilft, in verschiedenen Szenarien die optimale Wahl zu treffen.

5.1 Adapter Layers (2019)

Der von Houlsby et al. bei Google vorgeschlagene Adapter^[4] war der Vorreiter von PEFT. Der Ansatz besteht darin, nach jeder Subschicht (Attention, FFN) der Transformer-Architektur ein kleines Bottleneck-Netzwerk einzufugen: Erst wird die Dimension reduziert, dann eine nichtlineare Aktivierung angewendet, dann wieder erhoht. Die trainierbaren Parameter betragen etwa 0,5-8 % des Originalmodells. Der Nachteil ist eine zusatzliche Inferenzverzogerung (die Gewichte konnen nicht zurück in das Originalmodell integriert werden), weshalb Adapter im LLM-Bereich zunehmend von LoRA abgelost werden. Allerdings haben Folgearbeiten wie LLaMA-Adapter^[11] mit dem Zero-init-Attention-Mechanismus die einzigartigen Vorteile der Adapter-Architektur bei Vision-Language-Aufgaben demonstriert.

5.2 Prefix-Tuning (2021)

Das von Li und Liang vorgeschlagene Prefix-Tuning^[6] fugt vor dem Attention-Input jeder Schicht eine lernbare Sequenz „virtueller Token" (Prefix) hinzu. Diese Prefixe entsprechen keinem realen Text, sondern sind direkt optimierte kontinuierliche Vektoren. Die Anzahl trainierbarer Parameter ist ausserst gering (nur etwa 0,1 %), allerdings belegen sie zusatzliche Sequenzlange, und die Stabilitat bei generativen Aufgaben ist geringer als bei LoRA.

5.3 Prompt Tuning (2021)

Das von Lester et al. vorgeschlagene Prompt Tuning^[5] ist eine vereinfachte Version des Prefix-Tunings: Es werden nur lernbare Soft Tokens vor der Eingabe-Embedding-Schicht hinzugefugt, ohne dass irgendwelche Zwischenschichten des Modells beruhrt werden. Die trainierbaren Parameter sind minimal (nur Embedding-Dimension x Prefix-Lange), doch die Leistung bei kleinen Modellen ist schwacher, und es werden Modelle mit 10B+ Parametern benotigt, um mit dem vollstandigen Fine-Tuning mithalten zu konnen.

5.4 Methodenvergleich

Die Tabelle zeigt deutlich: Die Methoden der LoRA-Familie erreichen das beste Gleichgewicht zwischen Inferenzeffizienz, Multi-Task-Flexibilitat und Fine-Tuning-Qualitat -- das ist der Grund, warum sie sich 2024-2026 als De-facto-Standard fur LLM Fine-Tuning etabliert haben.

VI. Hands-on Lab 1: QLoRA Instruction Fine-Tuning eines LLM (kostenlose Colab-GPU)

Nach der Theorie folgt nun die Praxis. Wir werden auf einer kostenlosen Google Colab T4 GPU (16 GB) TinyLlama-1.1B mittels QLoRA einem Instruction Fine-Tuning unterziehen, damit es lernt, Fragen strukturiert zu beantworten.

Offnen Sie Google Colab, wahlen Sie „Laufzeit > Laufzeittyp andern > T4 GPU", erstellen Sie ein neues Notebook und fugen Sie den folgenden Code der Reihe nach ein:

6.1 Step 1 — Abhangigkeiten installieren

!pip install -q transformers peft bitsandbytes datasets trl accelerate

import torch
print(f"PyTorch-Version: {torch.__version__}")
print(f"CUDA verfugbar: {torch.cuda.is_available()}")
if torch.cuda.is_available():
    print(f"GPU: {torch.cuda.get_device_name(0)}")
    print(f"GPU-Speicher: {torch.cuda.get_device_properties(0).total_mem / 1024**3:.1f} GB")

6.2 Step 2 — Basismodell mit 4-bit-Quantisierung laden

from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig

# ★ Der Kern von QLoRA: 4-bit-NF4-Quantisierungskonfiguration ★
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,                      # 4-bit-Quantisierung aktivieren
    bnb_4bit_quant_type="nf4",             # NF4-Format (empfohlen fur QLoRA)
    bnb_4bit_compute_dtype=torch.float16,   # Berechnung in FP16
    bnb_4bit_use_double_quant=True,         # Doppelte Quantisierung (spart weiteren Speicher)
)

model_name = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

print("Lade 4-bit-quantisiertes Modell...")
tokenizer = AutoTokenizer.from_pretrained(model_name)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right"

model = AutoModelForCausalLM.from_pretrained(
    model_name,
    quantization_config=bnb_config,
    device_map="auto",
    torch_dtype=torch.float16,
)

# Speicherstatistik
mem_gb = torch.cuda.memory_allocated() / 1024**3
print(f"4-bit-Modell geladen, GPU-Speicher: {mem_gb:.2f} GB")
print(f"(FP16 wurde ursprunglich ca. {1.1*2:.1f} GB benotigen, 4-bit nur ca. {mem_gb:.1f} GB)")

6.3 Step 3 — Baseline-Test vor dem Fine-Tuning

def generate_response(model, tokenizer, prompt, max_new_tokens=150):
    """Hilfsfunktion zur Antwortgenerierung"""
    messages = [{"role": "user", "content": prompt}]
    text = tokenizer.apply_chat_template(
        messages, tokenize=False, add_generation_prompt=True
    )
    inputs = tokenizer(text, return_tensors="pt").to(model.device)
    with torch.no_grad():
        outputs = model.generate(
            **inputs,
            max_new_tokens=max_new_tokens,
            do_sample=True,
            temperature=0.7,
            top_p=0.9,
        )
    response = tokenizer.decode(outputs[0], skip_special_tokens=True)
    return response

# Test-Prompts
test_prompts = [
    "What is LoRA in the context of machine learning?",
    "Explain the difference between fine-tuning and transfer learning.",
    "How can small companies use LLMs effectively?",
]

print("=" * 60)
print("  Modellantworten vor dem Fine-Tuning (Baseline)")
print("=" * 60)
for prompt in test_prompts:
    response = generate_response(model, tokenizer, prompt)
    print(f"\nQ: {prompt}")
    print(f"A: {response[-300:]}")
    print("-" * 60)

6.4 Step 4 — LoRA-Konfiguration festlegen und Adapter injizieren

from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training, TaskType

# Modell fur k-bit-Training vorbereiten (Gradient Checkpointing etc. aktivieren)
model = prepare_model_for_kbit_training(model)

# ★ LoRA-Hyperparameter-Einstellungen ★
lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,                          # Rang: 16 ist ein gangiger Kompromiss
    lora_alpha=32,                 # Skalierungsfaktor: 2 * r
    lora_dropout=0.05,             # Dropout fur leichte Regularisierung
    target_modules=[               # LoRA in alle Attention-Schichten + MLP injizieren
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj",
    ],
    bias="none",                   # Bias nicht trainieren
)

# LoRA-Adapter injizieren
model = get_peft_model(model, lora_config)

# Statistik der trainierbaren Parameter anzeigen
model.print_trainable_parameters()
# Erwartete Ausgabe: trainable params: ~8.4M || all params: ~1.1B || trainable%: ~0.77%

6.5 Step 5 — Instruction-Fine-Tuning-Datensatz laden und verarbeiten

from datasets import load_dataset

# Instruction-Fine-Tuning-Datensatz im Alpaca-Format laden
dataset = load_dataset("tatsu-lab/alpaca", split="train")

# Nur die ersten 2000 Eintraege fur die Demonstration verwenden (fur vollstandiges Training alle 52K empfohlen)
dataset = dataset.select(range(2000))

print(f"Datensatzgrosse: {len(dataset)} Eintraege")
print(f"Spalten: {dataset.column_names}")
print(f"\nBeispiel:")
print(f"  instruction: {dataset[0]['instruction'][:100]}...")
print(f"  input: {dataset[0]['input'][:100]}")
print(f"  output: {dataset[0]['output'][:100]}...")

# In Chat-Template formatieren
def format_alpaca(example):
    """Alpaca-Format in TinyLlama Chat Template konvertieren"""
    if example["input"].strip():
        user_msg = f"{example['instruction']}\n\nInput: {example['input']}"
    else:
        user_msg = example["instruction"]

    messages = [
        {"role": "user", "content": user_msg},
        {"role": "assistant", "content": example["output"]},
    ]
    text = tokenizer.apply_chat_template(
        messages, tokenize=False, add_generation_prompt=False
    )
    return {"text": text}

dataset = dataset.map(format_alpaca, remove_columns=dataset.column_names)
print(f"\nFormatiertes Beispiel:")
print(dataset[0]["text"][:300])

6.6 Step 6 — QLoRA Fine-Tuning-Training starten

from trl import SFTTrainer, SFTConfig

# ★ Trainingskonfiguration ★
training_args = SFTConfig(
    output_dir="./qlora-tinyllama-alpaca",
    num_train_epochs=1,                # 1 Epoche fur die Demonstration
    per_device_train_batch_size=4,     # Batch-Grosse fur T4 16 GB
    gradient_accumulation_steps=4,     # Effektive Batch-Grosse = 16
    learning_rate=2e-4,                # Empfohlene Lernrate fur LoRA
    lr_scheduler_type="cosine",        # Cosine-Abnahme
    warmup_ratio=0.05,                 # 5 % Warmup
    logging_steps=10,                  # Alle 10 Schritte protokollieren
    save_strategy="epoch",            # Nach jeder Epoche speichern
    fp16=True,                         # Mixed-Precision-Training
    optim="paged_adamw_8bit",         # QLoRA Paged 8-bit Optimizer
    max_seq_length=512,               # Maximale Sequenzlange
    dataset_text_field="text",        # Textfeld im Datensatz
    report_to="none",                 # In Colab wandb deaktivieren
)

# SFT Trainer erstellen
trainer = SFTTrainer(
    model=model,
    args=training_args,
    train_dataset=dataset,
    processing_class=tokenizer,
)

# Training starten
print("QLoRA Fine-Tuning-Training wird gestartet...")
print(f"  Trainierbare Parameter: {sum(p.numel() for p in model.parameters() if p.requires_grad):,}")
print(f"  Trainingsbeispiele: {len(dataset)}")
print(f"  Effektive Batch-Grosse: {4 * 4}")
print(f"  Gesamte Trainingsschritte: {len(dataset) // (4*4)}")

train_result = trainer.train()

# Trainingsergebnis
print(f"\nTraining abgeschlossen!")
print(f"  Trainingsverlust: {train_result.training_loss:.4f}")
print(f"  Trainingszeit: {train_result.metrics['train_runtime']:.0f} Sekunden")
print(f"  GPU-Spitzenspeicher: {torch.cuda.max_memory_allocated() / 1024**3:.2f} GB")

6.7 Step 7 — Vergleich der Ergebnisse nach dem Fine-Tuning

# LoRA-Adapter speichern (nur Adapter-Gewichte, ca. 33 MB)
trainer.save_model("./qlora-tinyllama-alpaca/final")
print(f"LoRA-Adapter gespeichert (nur Adapter-Gewichte)")

# Test nach dem Fine-Tuning -- gleiche Prompts verwenden
print("=" * 60)
print("  Modellantworten nach dem Fine-Tuning")
print("=" * 60)
for prompt in test_prompts:
    response = generate_response(model, tokenizer, prompt)
    print(f"\nQ: {prompt}")
    print(f"A: {response[-300:]}")
    print("-" * 60)

# Zusatzlicher Test: Instruction-Following-Fahigkeit
extra_prompts = [
    "List three advantages of using LoRA for LLM fine-tuning.",
    "Write a short Python function that calculates the factorial of a number.",
]
print("\n" + "=" * 60)
print("  Zusatzlicher Instruction-Following-Test")
print("=" * 60)
for prompt in extra_prompts:
    response = generate_response(model, tokenizer, prompt, max_new_tokens=200)
    print(f"\nQ: {prompt}")
    print(f"A: {response[-400:]}")
    print("-" * 60)

import os
adapter_size = sum(
    os.path.getsize(os.path.join("./qlora-tinyllama-alpaca/final", f))
    for f in os.listdir("./qlora-tinyllama-alpaca/final")
    if os.path.isfile(os.path.join("./qlora-tinyllama-alpaca/final", f))
)
print(f"\n Adapter-Dateigrosse: {adapter_size / 1024**2:.1f} MB")
print(f"(Vollstandiges Modell FP16: ~{1.1*2*1024:.0f} MB, Kompressionsrate: {1.1*2*1024 / (adapter_size/1024**2):.0f}x)")

VII. Hands-on Lab 2: LoRA Adapter Merging und Inferenz

In Lab 1 haben wir den LoRA-Adapter trainiert und gespeichert. Fur den produktiven Einsatz mochten Sie den Adapter in der Regel zurück in das Basismodell integrieren -- so wird fur die Inferenz die PEFT-Bibliothek nicht benotigt, und die Geschwindigkeit ist hoher. Dieses Lab demonstriert den vollstandigen Ablauf von Adapter-Laden, Merging, Geschwindigkeitsvergleich und Export.

Offnen Sie ein neues Google Colab, wahlen Sie T4 GPU und fugen Sie den folgenden Code der Reihe nach ein:

7.1 Step 1 — Abhangigkeiten installieren und Basismodell laden

!pip install -q transformers peft bitsandbytes accelerate

import torch
import time
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

# Diesmal wird das Basismodell in FP16 geladen (Merging erfordert Full-Precision-Gewichte)
print("Lade FP16-Basismodell...")
tokenizer = AutoTokenizer.from_pretrained(model_name)
tokenizer.pad_token = tokenizer.eos_token

base_model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.float16,
    device_map="auto",
)

mem_base = torch.cuda.memory_allocated() / 1024**3
print(f"Basismodell geladen, GPU-Speicher: {mem_base:.2f} GB")

7.2 Step 2 — Trainierten LoRA-Adapter laden

from peft import PeftModel

# ★ LoRA-Gewichte aus gespeichertem Adapter laden ★
# Wenn Sie Lab 1 durchgefuhrt haben, konnen Sie den lokalen Pfad direkt verwenden
# adapter_path = "./qlora-tinyllama-alpaca/final"

# Damit Lab 2 unabhangig ausfuhrbar ist, zeigen wir hier, wie man vom HuggingFace Hub ladt
# Sie konnen dies durch den Pfad Ihres eigenen trainierten Adapters ersetzen
# Im Folgenden verwenden wir einen offentlichen LoRA-Adapter als Demonstration

# Methode A: Aus lokalem Pfad laden (in Lab 1 trainiert)
# model_with_adapter = PeftModel.from_pretrained(base_model, "./qlora-tinyllama-alpaca/final")

# Methode B: Fur die unabhangige Ausfuhrbarkeit erstellen wir direkt einen LoRA-Adapter als Demonstration
from peft import LoraConfig, get_peft_model, TaskType

lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,
    lora_alpha=32,
    lora_dropout=0.0,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    bias="none",
)

model_with_adapter = get_peft_model(base_model, lora_config)
model_with_adapter.print_trainable_parameters()

mem_adapter = torch.cuda.memory_allocated() / 1024**3
print(f"\nModell mit Adapter, GPU-Speicher: {mem_adapter:.2f} GB")
print(f"Zusatzlicher Adapter-Speicher: {(mem_adapter - mem_base)*1024:.1f} MB")

7.3 Step 3 — Adapter in das Basismodell integrieren

# ★ LoRA-Adapter in das Basismodell integrieren ★
print("Integriere LoRA-Adapter...")

# merge_and_unload() fuhrt Folgendes durch:
# 1. Berechnung von W_merged = W_base + B @ A * (alpha/r)
# 2. Ergebnis wird in die ursprungliche Gewichtsmatrix geschrieben
# 3. Alle LoRA-bezogenen Schichten werden entfernt
merged_model = model_with_adapter.merge_and_unload()

mem_merged = torch.cuda.memory_allocated() / 1024**3
print(f"Integration abgeschlossen, GPU-Speicher: {mem_merged:.2f} GB")
print(f"Modelltyp nach Integration: {type(merged_model).__name__}")
print(f"(Hinweis: Nach der Integration wird die PEFT-Bibliothek fur die Inferenz nicht mehr benotigt)")

7.4 Step 4 — Inferenzgeschwindigkeit vergleichen: Adapter vs. integriert

def benchmark_inference(model, tokenizer, prompt, n_runs=10, max_new_tokens=100):
    """Inferenzlatenz messen"""
    messages = [{"role": "user", "content": prompt}]
    text = tokenizer.apply_chat_template(
        messages, tokenize=False, add_generation_prompt=True
    )
    inputs = tokenizer(text, return_tensors="pt").to(model.device)

    # Aufwarmen
    with torch.no_grad():
        _ = model.generate(**inputs, max_new_tokens=10)

    # Eigentliche Messung
    latencies = []
    for _ in range(n_runs):
        torch.cuda.synchronize()
        start = time.perf_counter()
        with torch.no_grad():
            outputs = model.generate(
                **inputs, max_new_tokens=max_new_tokens,
                do_sample=False,  # Deterministische Generierung fur bessere Vergleichbarkeit
            )
        torch.cuda.synchronize()
        latencies.append(time.perf_counter() - start)

    tokens_generated = outputs.shape[1] - inputs["input_ids"].shape[1]
    avg_latency = sum(latencies) / len(latencies)
    tokens_per_sec = tokens_generated / avg_latency
    return avg_latency, tokens_per_sec, tokens_generated

prompt = "Explain the key benefits of parameter-efficient fine-tuning for large language models."

# Modell mit Adapter neu laden fur den Geschwindigkeitsvergleich
print("Lade Modell mit Adapter fur Geschwindigkeitsvergleich neu...")
base_model_2 = AutoModelForCausalLM.from_pretrained(
    model_name, torch_dtype=torch.float16, device_map="auto"
)
adapter_model_2 = get_peft_model(base_model_2, lora_config)

print("\nTeste Inferenzgeschwindigkeit mit Adapter...")
adapter_latency, adapter_tps, n_tokens = benchmark_inference(
    adapter_model_2, tokenizer, prompt
)

# Speicher freigeben
del adapter_model_2, base_model_2
torch.cuda.empty_cache()

print("Teste Inferenzgeschwindigkeit des integrierten Modells...")
merged_latency, merged_tps, _ = benchmark_inference(
    merged_model, tokenizer, prompt
)

print(f"\n{'='*60}")
print(f"  Inferenzgeschwindigkeit-Vergleich ({n_tokens} Tokens generiert)")
print(f"{'='*60}")
print(f"{'Methode':<20} {'Latenz(s)':>10} {'Tokens/s':>12} {'Rel. Geschw.':>10}")
print(f"{'-'*60}")
print(f"{'Mit Adapter':<20} {adapter_latency:>10.3f} {adapter_tps:>12.1f} {'1.00x':>10}")
speedup = adapter_latency / merged_latency
print(f"{'Integriert':<20} {merged_latency:>10.3f} {merged_tps:>12.1f} {f'{speedup:.2f}x':>10}")
print(f"{'='*60}")
print(f"\nBeschleunigung nach Integration: {speedup:.2f}x")
print(f"(Beschleunigung durch Wegfall der zusatzlichen Matrixmultiplikation und Forward-Hook-Overhead von LoRA)")

7.5 Step 5 — Integriertes Modell exportieren

# ★ Das integrierte Modell im Standard-HuggingFace-Format speichern ★
save_path = "./tinyllama-merged-model"

print(f"Speichere integriertes Modell nach {save_path}...")
merged_model.save_pretrained(save_path)
tokenizer.save_pretrained(save_path)

# Dateigrosse berechnen
import os
total_size = 0
for root, dirs, files in os.walk(save_path):
    for f in files:
        fpath = os.path.join(root, f)
        total_size += os.path.getsize(fpath)

print(f"Dateigrosse des integrierten Modells: {total_size / 1024**3:.2f} GB")
print(f"\nGespeicherte Dateien:")
for f in sorted(os.listdir(save_path)):
    fsize = os.path.getsize(os.path.join(save_path, f))
    print(f"  {f}: {fsize / 1024**2:.1f} MB")

# Verifizierung: Integriertes Modell von Festplatte laden
print("\nVerifizierung: Integriertes Modell wird von Festplatte geladen...")
verified_model = AutoModelForCausalLM.from_pretrained(
    save_path, torch_dtype=torch.float16, device_map="auto"
)
verified_tokenizer = AutoTokenizer.from_pretrained(save_path)

messages = [{"role": "user", "content": "What is LoRA?"}]
text = verified_tokenizer.apply_chat_template(
    messages, tokenize=False, add_generation_prompt=True
)
inputs = verified_tokenizer(text, return_tensors="pt").to(verified_model.device)
with torch.no_grad():
    outputs = verified_model.generate(**inputs, max_new_tokens=100, do_sample=False)
response = verified_tokenizer.decode(outputs[0], skip_special_tokens=True)
print(f"\nVerifizierungsergebnis der Inferenz:")
print(f"Q: What is LoRA?")
print(f"A: {response[-300:]}")

print(f"\nExport des integrierten Modells abgeschlossen!")
print(f"Dieses Modell kann direkt mit transformers geladen werden, ohne die PEFT-Bibliothek.")
print(f"Es kann auch mit llama.cpp in das GGUF-Format konvertiert werden, um auf der CPU zu laufen.")

VIII. Entscheidungsframework: Wann LoRA vs. vollstandiges Fine-Tuning vs. Prompt Engineering

Bei einem neuen LLM-Anwendungsszenario stellt sich die Frage: Prompt Engineering, LoRA Fine-Tuning oder vollstandiges Fine-Tuning? Dies ist eine Entscheidung, vor der jedes KI-Engineering-Team steht. Im Folgenden ein strukturiertes Entscheidungsframework:

Entscheidungspfad:

• Zunachst Prompt Engineering versuchen: Wenn die Aufgabe durch sorgfaltig gestaltete Prompts + Few-shot Examples geloest werden kann, ist kein Fine-Tuning erforderlich. RAG (Retrieval-Augmented Generation) kann ebenfalls Domainwissen injizieren, ohne Fine-Tuning
• Wenn Prompts nicht ausreichen, LoRA/QLoRA verwenden: Wenn Sie mochten, dass das Modell ein bestimmtes Ausgabeformat, einen Tonfall, Fachterminologie erlernt, oder wenn Sie das Modellverhalten grundlegend verandern mussen (z. B. ein allgemeines Modell in einen Code-Assistenten verwandeln), ist LoRA die beste Wahl
• Wenn LoRA nicht ausreicht, vollstandiges Fine-Tuning in Betracht ziehen: Nur in ausserst seltenen Szenarien -- beispielsweise um Sprachfahigkeiten fur eine ressourcenarme Sprache aufzubauen oder die Wissensbasis des Modells grundlegend zu verandern -- ist vollstandiges Fine-Tuning erforderlich. Selbst in diesen Fallen wird empfohlen, zunachst mit LoRA eine Machbarkeitsstudie durchzufuhren

IX. Enterprise Best Practices: LoRA Fine-Tuning in der Praxis

9.1 Datenqualitat > Datenmenge

Die haufigste Ursache fur Misserfolge beim LoRA Fine-Tuning sind nicht falsche Hyperparameter, sondern unzureichende Trainingsdatenqualitat. 1.000 manuell ausgewahlte, konsistent formatierte Instruktionen mit guter Abdeckung von Randfallen ubertreffen in der Regel 100.000 maschinell generierte Datensatze niedriger Qualitat. Es wird empfohlen, 80 % der Zeit in die Datenvorbereitung zu investieren: klare Instruktionsvorlagen definieren, Qualitatskontrollprozesse etablieren und konsistente Ausgabeformate sicherstellen.

9.2 Hyperparameter-Suchstrategie

Fur die meisten Aufgaben ist die folgende Konfiguration ein zuverlassiger Ausgangspunkt:

# Empfohlene Hyperparameter-Ausgangskonfiguration fur LoRA Fine-Tuning
recommended_config = {
    "r": 16,                    # Bei 16 beginnen, bei Bedarf erhohen
    "lora_alpha": 32,           # 2 * r
    "lora_dropout": 0.05,       # Bei kleinen Datensatzen 0.1
    "target_modules": "all",    # In alle linearen Schichten injizieren
    "learning_rate": 2e-4,      # Standard-Lernrate fur LoRA
    "lr_scheduler": "cosine",   # Cosine-Abnahme
    "warmup_ratio": 0.03,       # 3 % Warmup
    "num_epochs": 3,            # 3 Epochen, mit Early Stopping
    "batch_size": 16,           # Durch Gradient Accumulation erreicht
    "max_seq_length": 2048,     # Je nach Aufgabe anpassen
    "weight_decay": 0.01,       # Leichte Regularisierung
}

Wenn die Baseline-Leistung nicht ausreicht, passen Sie in folgender Reihenfolge an: (1) Datenqualitat und -vielfalt erhohen; (2) Rank auf 32 oder 64 erhohen; (3) Trainings-Epochen erhohen (Overfitting uberwachen); (4) Lernrate anpassen (Suche von 1e-5 bis 5e-4).

9.3 Multi-Adapter-Serving-Architektur

Ein einzigartiger Vorteil von LoRA ist die Unterstutzung von Multi-Tenant Serving: ein Basismodell + mehrere LoRA-Adapter, wobei jeder Adapter einem Kunden oder einer Aufgabe entspricht. Dies reduziert die GPU-Kosten fur Multi-Task-Deployments erheblich:

• Speichereffizienz: Das Basismodell wird nur einmal geladen (z. B. 14 GB), jeder Adapter belegt nur 30-100 MB. Die Bedienung von 100 Kunden erfordert nur 14 GB + 10 GB = 24 GB, statt 100 x 14 GB = 1,4 TB
• Dynamisches Umschalten: Wahrend der Inferenz wird der entsprechende Adapter dynamisch geladen, die Umschaltlatenz liegt im Millisekundenbereich
• Unabhangige Aktualisierungen: Der Adapter jedes Kunden kann unabhangig trainiert und aktualisiert werden, ohne andere Kunden zu beeinflussen
• Framework-Unterstutzung: Inferenz-Frameworks wie vLLM, LoRAX und S-LoRA unterstutzen nativ das parallele Serving mehrerer LoRA-Adapter

9.4 Haufige Fallstricke vermeiden

• Overfitting-Erkennung: LoRA hat zwar wenige trainierbare Parameter, kann aber bei kleinen Datensatzen dennoch overfitting zeigen. Halten Sie unbedingt ein Validierungsset zuruck, uberwachen Sie den Eval Loss und verwenden Sie Early Stopping
• Tokenizer-Inkompatibilitat: Stellen Sie sicher, dass der Tokenizer beim Fine-Tuning und bei der Inferenz identisch ist. Achten Sie besonders auf die Einstellungen von pad_token und chat_template
• Reihenfolge Quantisierung + Merging: QLoRA-trainierte Adapter mussen vor dem Merging das Basismodell auf FP16/BF16 dequantisieren. Ein direktes merge_and_unload() auf einem 4-bit-Modell fuhrt zu Prazisionsverlust
• Zu hohe Lernrate: Die Lernrate fur LoRA muss in der Regel 5-10x hoher sein als beim vollstandigen Fine-Tuning (da weniger Parameter trainierbar sind), doch wenn sie zu hoch ist (> 5e-4), kann das Training instabil werden
• Vergessensevaluation: Nach dem Fine-Tuning sollte sowohl die Leistung auf der Zielaufgabe als auch auf allgemeinen Benchmarks (wie MMLU, HellaSwag) evaluiert werden, um sicherzustellen, dass das Modell kein vortrainiertes Wissen erheblich vergessen hat

9.5 Unsloth-Beschleunigungsframework

Unsloth^[8] ist ein speziell fur LoRA/QLoRA Fine-Tuning entwickeltes Beschleunigungsframework, das durch manuell geschriebene Backpropagation-Kernel (Umgehung von PyTorch autograd) und intelligentes Speichermanagement eine 2-fache Geschwindigkeitssteigerung und 60 % Speicherreduktion erreicht -- ohne jeglichen Prazisionsverlust. Unsloth ist kompatibel mit dem transformers- und trl-Okosystem von HuggingFace und lasst sich durch einfaches Ersetzen der Modellladefunktion verwenden:

# Ursprungliche HuggingFace-Methode
# model = AutoModelForCausalLM.from_pretrained(...)

# Unsloth-Beschleunigung (eine Zeile ersetzen)
from unsloth import FastLanguageModel
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/tinyllama-chat",
    max_seq_length=2048,
    load_in_4bit=True,        # QLoRA automatisch aktivieren
)

# LoRA-Konfiguration -- identisch mit PEFT
model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                     "gate_proj", "up_proj", "down_proj"],
    lora_dropout=0,
)

# Der anschliessende Trainingsablauf ist vollstandig identisch mit Standard HuggingFace TRL

Unsloth bietet daruber hinaus Modellexportfunktionen, darunter den direkten Export in das GGUF-Format (fur llama.cpp) oder die Erstellung quantisierter integrierter Modelle, was den Prozess vom Fine-Tuning bis zum Deployment erheblich vereinfacht.

X. Fazit

Das Erscheinen von LoRA hat die Zuganglichkeit des LLM Fine-Tunings grundlegend verandert. Vor LoRA erforderte das Fine-Tuning eines 70B-Modells 8 A100-GPUs und ein Rechenbudget von mehreren tausend Dollar; nach LoRA kann die gleiche Arbeit auf einer einzigen Consumer-GPU durchgefuhrt werden. QLoRA hat die Einstiegshurde weiter auf das kostenlose Google Colab gesenkt. Und Folgearbeiten wie DoRA und VeRA verschieben die Obergrenze der Parametereffizienz kontinuierlich nach oben.

Doch Technologie ist nur ein Werkzeug. Was die Ergebnisse des Fine-Tunings wirklich bestimmt, ist das tiefe Verstandnis des Geschaftsszenarios, die strenge Kontrolle der Datenqualitat und die systematische Evaluation des Modellverhaltens. Ein 7B-Modell, das mit 1.000 sorgfaltig ausgewahlten Datensatzen + LoRA fine-getuned wurde, ubertrifft in spezifischen Geschaftsszenarien oft ein allgemeines 70B-Modell.

LoRA ermoglicht es jeder Organisation, ihr eigenes massgeschneidertes LLM zu besitzen -- die Frage ist nicht mehr „ob es moglich ist", sondern „wie es am effektivsten umgesetzt werden kann". Das Verstandnis der LoRA-Prinzipien, die Beherrschung der QLoRA-Implementierung und der Aufbau eines systematischen Evaluationsprozesses sind unverzichtbare Kompetenzen fur jedes KI-Engineering-Team im Jahr 2026.