LLM Fine-Tuning: Methoden, Frameworks & Schritt-für-Schritt-Code [2026]

Ein LLM feinabzustimmen bedeutet, ein vortrainiertes Modell auf Ihren spezifischen Daten weiterzutrainieren, sodass es Ihre Aufgabe besser erfüllt als jede Eingabeaufforderung. Die Einstiegshürde ist gefallen: QLoRA + Unsloth erlauben heute das Fine-Tuning eines 8-Milliarden-Parameter-Modells auf einer 12-GB-Consumer-GPU für unter 1 € in Cloud-Kosten.

Dieser Leitfaden deckt die gesamte Reise ab -- wann Sie feinabstimmen sollten (vs. RAG oder Prompt Engineering), welche Methode und welches Framework Sie wählen sollten, wie Sie Ihren Datensatz vorbereiten, eine Copy-Paste-Llama-3-Anleitung, reale Kostenszenarien und Deployment.

Fine-Tuning auf einen Blick

Bevor Sie sich auf etwas festlegen, hier das schnelle Gesamtbild:

Jetzt schauen wir uns an, ob Fine-Tuning tatsächlich der richtige Ansatz für Ihr Projekt ist.

Wann sollten Sie ein LLM feinabstimmen? (vs. RAG vs. Prompt Engineering)

Das ist die Frage, die die meisten Entwickler überspringen -- und es kostet sie Wochen verschwendeter Arbeit. Fine-Tuning ist mächtig, aber nicht immer das richtige Werkzeug. Hier ist ein Framework zur Entscheidung.

Die Entscheidung hängt davon ab, was Sie ändern möchten. Hier sind reale Szenarien:

Wenn Sie den richtigen KI-Stack für Ihr SaaS wählen, ist dieses Entscheidungs-Framework Schritt eins. Viele Teams bauen komplexe RAG-Pipelines, wenn ein 500-Beispiel-Fine-Tune konsistentere Ergebnisse mit geringerer Latenz liefern würde.

Fazit: Stimmen Sie fein ab, wenn Sie das Modell konsistent anders verhalten lassen müssen, nicht nur andere Dinge wissen. Wenn Sie nur neues Wissen benötigen, ist RAG günstiger und einfacher zu pflegen. Wenn Sie beides benötigen, wählen Sie den Hybrid-Ansatz.

Wie funktioniert LLM Fine-Tuning? Full vs. LoRA vs. QLoRA

Es gibt drei Hauptansätze, die sich erheblich in Hardwareanforderungen, Kosten und Qualität unterscheiden. Das Verständnis der Trade-offs bewahrt Sie vor Über- oder Unterinvestitionen.

Full Fine-Tuning (Wenn das Budget keine Rolle spielt)

Full Fine-Tuning aktualisiert jeden Parameter im Modell. Es liefert die bestmöglichen Ergebnisse, erfordert aber enorme Ressourcen -- ungefähr 100+ GB VRAM für ein 7-B-Modell (Sie müssen Modell, Optimiererzustände und Gradienten gleichzeitig speichern). Das ist H100-Cluster-Territorium. Außer wenn Sie bei einem gut finanzierten Labor arbeiten, überspringen Sie dies.

LoRA: Die PEFT-Revolution

LoRA (Low-Rank Adaptation) friert das Basismodell ein und fügt kleine trainierbare Matrizen namens Adapter hinzu. Anstatt eine massive Gewichtsmatrix W direkt zu aktualisieren, zerlegt LoRA das Update in zwei kleine Matrizen A und B, wobei Rang r viel kleiner ist als die Modelldimension. Das Ergebnis: Sie trainieren ungefähr 1–2 % der ursprünglichen Parameter und behalten dabei 98–99 % der Qualität des vollständigen Fine-Tunings.

Die Hugging Face peft-Bibliothek ist die Standard-Implementierung. LoRA-Adapter sind typischerweise 50–200 MB -- winzig im Vergleich zum vollständigen Modell.

QLoRA: Fine-Tuning für jeden

QLoRA geht einen Schritt weiter als LoRA. Es lädt das Basismodell in 4-Bit-Präzision mit einem speziellen Datentyp namens NormalFloat4 (NF4), und wendet dann LoRA-Adapter darauf an. Die 4-Bit-Quantisierung reduziert den VRAM-Verbrauch um weitere ~25 % im Vergleich zu Standard-LoRA, bei nahezu identischer Qualität.

Das macht Fine-Tuning zugänglich. Ein 7-B-Modell, das für vollständiges Fine-Tuning 100+ GB benötigt, passt mit QLoRA in 12 GB.

Fazit: Für 90 % der Entwickler ist QLoRA die richtige Wahl. Der Qualitätsunterschied zum vollständigen Fine-Tuning ist für die meisten Aufgaben vernachlässigbar, und die Hardwareersparnis ist enorm. Beginnen Sie dort und skalieren Sie nur hoch, wenn Ihre Evaluierungsmetriken es verlangen.

Welches Fine-Tuning-Framework sollten Sie 2026 verwenden?

Die Wahl eines Frameworks ist wichtiger als die meisten Leute erkennen. Das richtige spart Stunden bei der Einrichtung und beschleunigt das Training erheblich. Hier ist ein Vergleich der vier wichtigsten Optionen.

Hier die schnelle Empfehlung:

• Erstes Fine-Tuning? Verwenden Sie Unsloth. Schnellstes Training, einfachste Einrichtung, kostenlose Colab-Notebooks für den sofortigen Einstieg.
• Web-UI ohne Code? Verwenden Sie LLaMA-Factory. Sein LLaMA-Board-GUI ermöglicht das Konfigurieren und Starten des Trainings über einen Browser.
• Alignment (RLHF, DPO, GRPO)? Verwenden Sie TRL. Es ist der Hugging-Face-Standard für präferenzbasiertes Training, und v0.15.0 (März 2026) hat native GRPO-Unterstützung hinzugefügt.
• Produktions-Pipelines auf Multi-GPU? Verwenden Sie Axolotl. YAML-basierte Konfigurationen machen Experimente reproduzierbar und nachvollziehbar.

Ein nützlicher Trick: Unsloth und LLaMA-Factory können kombiniert werden. LLaMA-Factory unterstützt Unsloth als Training-Backend und bietet damit die GUI-Bequemlichkeit mit Unsloths Geschwindigkeitsoptimierungen.

Wie bereiten Sie einen Fine-Tuning-Datensatz vor?

Datenqualität ist der wichtigste einzelne Faktor für den Fine-Tuning-Erfolg. Ein gut kuratierter 500-Beispiel-Datensatz übertrifft fast immer einen verrauschten 10.000-Beispiel-Datensatz.

Datensatzformate

Die beiden dominanten Formate sind Chat (OpenAI-kompatibel) und Instruction (Alpaca-Stil). So sieht jedes im JSONL-Format aus:

Chat-Format (für die meisten Anwendungsfälle empfohlen):

{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "I ordered a laptop 3 days ago (order #4821) and it still says processing."}, {"role": "assistant", "content": "I can see order #4821 is currently in our warehouse being prepared for shipment. Laptops typically ship within 3-5 business days. You should receive a tracking number by tomorrow. Would you like me to flag this for priority processing?"}]}
{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "Can I return my keyboard? Order #3019, bought it last week."}, {"role": "assistant", "content": "Absolutely! Order #3019 is within our 30-day return window. I'll email you a prepaid return label right now. Once we receive the keyboard, your refund will process within 2-3 business days."}]}
{"messages": [{"role": "system", "content": "You are a customer support agent for Acme Inc. Be helpful, concise, and always reference the user's order number."}, {"role": "user", "content": "My monitor arrived cracked. Order #5573."}, {"role": "assistant", "content": "I'm sorry about that! For order #5573, I'm initiating an immediate replacement shipment -- no need to return the damaged unit. The new monitor will ship today with express delivery. You'll get a tracking email within the hour."}]}

Instruction-Format (Alpaca-Stil):

{"instruction": "Summarize the following customer complaint in one sentence.", "input": "I've been waiting 2 weeks for my refund and nobody responds to my emails. This is the worst customer service I've ever experienced.", "output": "Customer is frustrated by a 2-week delay in receiving their refund and lack of email response from support."}
{"instruction": "Classify the sentiment of this review.", "input": "The product works fine but shipping took forever.", "output": "Mixed (positive product, negative shipping)"}

Richtlinien zur Datensatzgröße

Wie viele Daten brauchen Sie tatsächlich? Es hängt von der Aufgabenkomplexität ab:

1. 50–100 Beispiele -- Proof of Concept, genug um zu testen, ob Fine-Tuning hilft
2. 500–1.000 Beispiele -- nützlich für die meisten Einzelaufgaben (Klassifikation, Extraktion, Formatierung)
3. 5.000–10.000 Beispiele -- produktionsreife Ergebnisse für komplexe Aufgaben
4. 10.000+ Beispiele -- abnehmende Renditen, es sei denn, Ihre Aufgabe hat eine hohe Variabilität

Checkliste für Datenqualität

Validieren Sie Ihren Datensatz vor dem Training anhand dieser Kriterien:

• Konsistente Formatierung in allen Beispielen (gleicher System-Prompt, gleiche Ausgabestruktur)
• Diverse Beispiele, die Randfälle und Fehlermodi abdecken
• Keine Widersprüche (lehren Sie das Modell nicht, auf dasselbe Eingabemuster sowohl „ja" als auch „nein" zu sagen)
• Ausgewogene Verteilung der Ausgabetypen (bei Klassifikation nicht 90 % der Beispiele in einer Klasse)
• Duplikate und nahezu doppelte Einträge entfernen

Profi-Tipp: Verwenden Sie GPT-4 oder Claude, um anfängliche synthetische Trainingsdaten zu generieren, und verfeinern Sie diese dann durch menschliche Überprüfung. 500 hochwertige synthetische Beispiele übertreffen oft 5.000 verrauschte echte Beispiele. Metas Fine-Tuning-Leitfaden empfiehlt diesen Ansatz für den Bootstrap von Datensätzen.

Schritt für Schritt: Llama 3 8B mit QLoRA und Unsloth feinabstimmen

Hier ist die vollständige Anleitung. Jeder Codeblock ist kopierbereit -- Sie können dies in einem kostenlosen Google Colab-Notebook oder auf einem beliebigen Rechner mit 12+ GB VRAM ausführen.

Schritt 1: Unsloth installieren

pip install unsloth

Das war's. Unsloth verwaltet alle Abhängigkeiten (transformers, peft, trl, bitsandbytes) automatisch.

Schritt 2: Basismodell in 4-Bit laden

from unsloth import FastLanguageModel

# Llama 3.1 8B in 4-Bit-Quantisierung laden
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Meta-Llama-3.1-8B-bnb-4bit",
    max_seq_length=2048,
    load_in_4bit=True,
)

Dies lädt das 4-Bit quantisierte Modell (~4 GB) herunter und in den GPU-Speicher. Auf einer RTX 3060 (12 GB) haben Sie reichlich Spielraum für das Training.

Schritt 3: LoRA-Adapter konfigurieren

# LoRA-Adapter zum Modell hinzufügen
model = FastLanguageModel.get_peft_model(
    model,
    r=16,                # LoRA-Rang -- 16 ist der Sweet Spot für die meisten Aufgaben
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                     "gate_proj", "up_proj", "down_proj"],
    lora_alpha=16,       # Skalierungsfaktor (normalerweise gleich r)
    lora_dropout=0,      # Unsloth ist für 0 Dropout optimiert
    bias="none",
)

Mit r=16 trainieren Sie ungefähr 40 Millionen Parameter von 8 Milliarden -- weniger als 0,5 % des Modells. Das ist die Magie von LoRA.

Schritt 4: Datensatz laden

from datasets import load_dataset

# JSONL-Datensatz von Hugging Face Hub oder lokaler Datei laden
dataset = load_dataset("json", data_files="train.jsonl", split="train")

# In Chat-Vorlage formatieren
def format_chat(example):
    text = tokenizer.apply_chat_template(
        example["messages"],
        tokenize=False,
        add_generation_prompt=False,
    )
    return {"text": text}

dataset = dataset.map(format_chat)

Dies nimmt das JSONL-Chat-Format aus dem vorherigen Abschnitt und wendet Llama 3s Chat-Vorlage an. Der Tokenizer übernimmt alle speziellen Token (<|begin_of_text|>, <|eot_id|>, etc.).

Schritt 5: Training konfigurieren und starten

from trl import SFTTrainer
from transformers import TrainingArguments
from unsloth import is_bfloat16_supported

trainer = SFTTrainer(
    model=model,
    train_dataset=dataset,
    dataset_text_field="text",
    max_seq_length=2048,
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,    # Effektive Batch-Größe = 8
        warmup_steps=5,
        max_steps=60,                     # Je nach Datensatzgröße anpassen
        learning_rate=2e-4,               # Standard für QLoRA
        fp16=not is_bfloat16_supported(),
        bf16=is_bfloat16_supported(),
        logging_steps=1,
        output_dir="outputs",
        seed=42,
    ),
)

# Training starten
trainer.train()

Wichtige Hyperparameter zum Verstehen:

• Lernrate (2e-4): Der Standard für QLoRA. Senken Sie (2e-5), wenn das Modell allgemeine Fähigkeiten vergisst.
• Batch-Größe (2) x Gradientenakkumulation (4): Effektive Batch-Größe von 8. Erhöhen Sie gradient_accumulation, wenn Ihrer GPU der Speicher ausgeht.
• max_steps (60): Für 500 Beispiele sind das ungefähr 1 Epoche. Beginnen Sie mit 1–3 Epochen und beobachten Sie den Validierungsverlust.
• Rang r (16): Niedriger (4–8) für einfache Aufgaben, höher (32–64) für komplexe Aufgaben. 16 ist ein sicherer Standard.

Schritt 6: Speichern und testen

# LoRA-Adapter speichern (klein -- ~50-200 MB)
model.save_pretrained("my-fine-tuned-model")
tokenizer.save_pretrained("my-fine-tuned-model")

# Schneller Inferenztest
FastLanguageModel.for_inference(model)
inputs = tokenizer(
    [tokenizer.apply_chat_template(
        [{"role": "user", "content": "I need to return order #7742"}],
        tokenize=False,
        add_generation_prompt=True,
    )],
    return_tensors="pt",
).to("cuda")

outputs = model.generate(**inputs, max_new_tokens=256)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Das ist die gesamte Pipeline. Auf einer RTX 4090 mit Unsloth dauert das Training von 500 Beispielen ungefähr 15–30 Minuten. Auf einem kostenlosen Colab T4 rechnen Sie mit 1–2 Stunden.

Was ist mit API-basiertem Fine-Tuning? (OpenAI, Google, Mistral)

Nicht jeder möchte GPUs verwalten. API-Anbieter ermöglichen Fine-Tuning über einen einfachen Upload-und-Trainings-Workflow. Hier ist ein Vergleich zu lokalem Betrieb.

Wann API-Fine-Tuning sinnvoll ist: Sie müssen schnell iterieren, Ihr Datensatz ist klein, Sie möchten keine Infrastruktur verwalten, oder Sie benötigen speziell ein geschlossenes Modell wie GPT-4o.

Wann lokales Fine-Tuning gewinnt: Datenschutz ist wichtig (Gesundheitswesen, Finanzen, Recht), Sie trainieren häufig, Sie möchten die Gewichte besitzen und exportieren, oder Sie optimieren für Kosten im großen Maßstab.

Fazit: API-Fine-Tuning ist der schnellste Weg zu einem Proof of Concept. Lokales Fine-Tuning ist der günstigste Weg zur Produktion. Die meisten Teams prototypisieren über eine API und wechseln dann zu lokalem Unsloth, wenn sie den Ansatz validiert haben.

Wie viel kostet das Fine-Tuning eines LLM?

Das Narrativ "Fine-Tuning ist teuer" steckt noch in 2023. Hier sind die tatsächlichen Kosten heute.

Die Kostenkurve flacht schnell ab. Ein Startup, das ein 8-B-Modell auf RunPod feinabstimmt, gibt weniger fürs Training aus als für eine Tasse Kaffee. Selbst das 70-B-Produktionsszenario liegt unter 30 € -- das ist ein Monatsbudget für das Mittagessen eines Junior-Entwicklers.

Cloud-GPU-Anbieter, die Sie vergleichen sollten: RunPod (beste Spot-Preise), Lambda (zuverlässige On-Demand-H100s), Vast.ai (günstigste, aber variable Qualität) und Modal (serverlos, sekundengenau abgerechnet).

Das obige Diagramm zeigt, warum QLoRA das Spiel verändert hat. Ein 7-B-Modell, das für vollständiges Fine-Tuning einen Multi-GPU-Cluster benötigte, passt jetzt auf eine Laptop-GPU. Das 70-B-Modell fällt von "nur Cloud" auf eine einzelne A100.

Fazit: Sie können ein produktionsqualitatives 8-B-Modell für unter 1 € feinabstimmen. Die Kostenbarriere für Fine-Tuning ist verschwunden. Die eigentlichen Kosten sind die Zeit für die Datensatzvorbereitung.

Wie evaluieren Sie ein feinabgestimmtes Modell?

Training ist nur die Hälfte der Arbeit. Ohne ordnungsgemäße Evaluierung können Sie nicht sagen, ob Ihr feinabgestimmtes Modell tatsächlich besser geworden ist -- oder ob es nur Ihre Trainingsdaten auswendig gelernt hat.

Automatisierte Metriken

Verfolgen Sie diese während und nach dem Training:

• Training-Loss / Perplexität: Sollte stetig abnehmen und dann stagnieren. Wenn er nahezu null sinkt, überfitten Sie.
• Aufgabenspezifische Metriken: Genauigkeit (Klassifikation), BLEU/ROUGE (Zusammenfassung), exakte Übereinstimmung (Extraktion), F1 (Multi-Label). Wählen Sie die Metrik, die zu Ihrer Aufgabe passt.

Menschliche Evaluierung

Zahlen erfassen nicht alles. Für generative Aufgaben:

• A/B-Testing: Zeigen Sie Basismodell- vs. feinabgestimmte Ausgabe nebeneinander. Lassen Sie 3–5 Bewerter die bessere Antwort aus 50+ Beispielen auswählen. Verfolgen Sie die Gewinnrate.
• Likert-Skala-Bewertung: Bewerten Sie Ausgaben nach Relevanz (1–5), Genauigkeit (1–5) und Ton (1–5). Berechnen Sie die durchschnittliche Verbesserung gegenüber dem Basismodell.

Prüfung auf katastrophales Vergessen

Dies ist das, was die meisten Entwickler überspringen. Nach dem Fine-Tuning führen Sie Ihr Modell auf einem allgemeinen Benchmark wie MMLU oder HellaSwag aus. Wenn die Scores um mehr als 2–3 Punkte sinken, hat Ihr Modell zu viel allgemeines Wissen verloren. Die Lösung: Lernrate senken, Epochen reduzieren oder zu LoRA wechseln (das die Basisgewichte einfriert).

Praktische Regel: Halten Sie immer 10–20 % Ihres Datensatzes als Testsatz zurück. Evaluieren Sie niemals auf Trainingsdaten -- das sagt nichts über die reale Leistung aus.

Wie deployen Sie ein feinabgestimmtes Modell?

Das Training ist abgeschlossen. Jetzt müssen Sie es bereitstellen. Die meisten Anleitungen überspringen diesen Teil vollständig.

Schritt 1: LoRA-Adapter zusammenführen

Wenn Sie LoRA oder QLoRA verwendet haben, führen Sie die Adapter für die Inferenz wieder in das Basismodell ein:

# Adapter in Basismodell zusammenführen
model.merge_and_unload()
model.save_pretrained("merged-model")
tokenizer.save_pretrained("merged-model")

Schritt 2: Deployment-Pfad wählen

Lokale Entwicklung und Tests -- Ollama:

# In GGUF-Format konvertieren (natives Ollama-Format)
python llama.cpp/convert_hf_to_gguf.py merged-model --outfile model.gguf --outtype q4_k_m

# Ollama-Modell erstellen
ollama create my-fine-tuned-model -f Modelfile
ollama run my-fine-tuned-model

Produktionsbereitstellung -- vLLM:

# OpenAI-kompatiblen API-Server starten
python -m vllm.entrypoints.openai.api_server \
    --model merged-model \
    --host 0.0.0.0 \
    --port 8000

Serverlos (ohne Infrastruktur): Laden Sie Ihr Modell auf Together AI, Fireworks oder Modal hoch. Sie erhalten einen API-Endpunkt ohne Serververwaltung. Die Kosten skalieren mit der Nutzung.

Erweitert: Multi-Adapter-Serving

Hier ist ein Muster, das mehr Teams nutzen sollten: Ein Basismodell im Speicher halten und LoRA-Adapter pro Anfrage wechseln. Sie könnten einen Kundensupport-Adapter, einen Code-Review-Adapter und einen Zusammenfassungs-Adapter betreiben -- alles von einer einzelnen GPU. vLLM unterstützt dies nativ mit dem --enable-lora-Flag.

Was sind die häufigsten Fine-Tuning-Fehler?

Nach der Fehlersuche in Dutzenden von Fine-Tuning-Runs sind das die Fehler, die immer wieder auftauchen.

1. Overfitting auf kleine Datensätze. Sie trainieren für 10 Epochen auf 200 Beispielen, der Trainingsverlust nähert sich null, und das Modell gibt Ihre Trainingsdaten wörtlich wieder. Lösung: maximal 1–3 Epochen, Validierungssatz verwenden und auf die Lücke zwischen Trainings- und Eval-Verlust achten.

2. Katastrophales Vergessen. Das Modell beherrscht Ihre spezifische Aufgabe, kann aber keine normale Unterhaltung mehr führen. Lösung: LoRA/QLoRA verwenden (friert Basisgewichte ein), Lernraten niedrig halten (2e-5 für Full Fine-Tuning, 2e-4 für QLoRA) und allgemeine Benchmarks vor dem Deployment evaluieren.

3. Schlechte Datenqualität. Inkonsistente Formatierung, Widersprüche zwischen Beispielen oder Duplikate. Das Modell lernt das Rauschen. Lösung: Daten vor dem Training bereinigen. Immer. Verbringen Sie mehr Zeit mit der Datenkuratierung als mit der Hyperparameter-Abstimmung.

4. Mit einem zu großen Modell beginnen. Teams springen zu 70B, weil "größer besser ist", und können sich dann die GPU-Kosten nicht leisten. Lösung: Mit 8B beginnen. Wenn 8B mit guten Daten Ihre Aufgabe nicht lösen kann, wird 70B mit denselben Daten es wahrscheinlich auch nicht. Zuerst die Datenqualität skalieren, dann die Modellgröße.

5. Keine Evaluierungs-Pipeline. Training ohne gehaltenen Testsatz, dann Deployment basierend auf dem Bauchgefühl. Lösung: Teilen Sie Ihre Daten 80/10/10 (Train/Val/Test) auf, bevor Sie beginnen. Vergleichen Sie mit dem Basismodell bei jedem Testbeispiel.

6. Zu hohe Lernrate. Zerstört das vortrainierte Wissen in den ersten Schritten. Das Modell gibt Kauderwelsch aus. Lösung: Bei 2e-4 für QLoRA und 2e-5 für Full Fine-Tuning beginnen. Wenn Ausgaben sich verschlechtern, weiter senken.

So geht Techsy bei LLM Fine-Tuning vor

Bei Techsy folgen wir für jedes KI-Projekt einem strikten Eskalationspfad: zuerst Prompt Engineering, dann RAG, Fine-Tuning nur wenn die Daten es beweisen. Die meisten Kundenprojekte erfordern tatsächlich kein Fine-Tuning -- gut durchdachte Prompts oder eine RAG-Pipeline lösen das Problem bei geringeren Kosten und Komplexität.

Wenn Fine-Tuning der richtige Ansatz ist, läuft unser Prozess so ab:

1. Datensatz-Audit -- Wir überprüfen die Kundendaten auf Qualität, Abdeckung und Formatierung. Wenn nicht genügend Beispiele vorhanden sind, helfen wir beim Aufbau eines synthetischen Datensatzes mit GPT-4 oder Claude und menschlicher Überprüfung.
2. Framework-Auswahl -- Unsloth + QLoRA für 90 % der Startup-Projekte. Axolotl für Kunden, die reproduzierbare Multi-GPU-Produktions-Pipelines benötigen.
3. Training und Evaluierung -- Wir trainieren immer mit einem gehaltenen Testsatz und benchmarken gegen das Basismodell. Wenn das feinabgestimmte Modell die Zielmetrik nicht messbar verbessert, deployen wir es nicht.
4. Deployment -- vLLM für Produktionsbereitstellung, Multi-Adapter-Muster wenn Kunden mehrere spezialisierte Modelle von einer einzigen GPU benötigen.

Wir haben feinabgestimmte Modelle für Startups ausgeliefert, die sich kein Enterprise-GPU-Budget leisten konnten -- QLoRA auf RunPod hält die Kosten selbst für 70-B-Modelle unter 30 €.

Benötigen Sie Hilfe beim Fine-Tuning eines LLM für Ihren Anwendungsfall? Wir helfen Teams, von Rohdaten zum deployten Modell zu gelangen. Kostenlose Beratung erhalten

Häufig gestellte Fragen zum LLM Fine-Tuning

Was ist LLM Fine-Tuning?

LLM Fine-Tuning ist der Prozess, ein vortrainiertes Sprachmodell auf Ihren eigenen aufgabenspezifischen Daten zu trainieren, damit es diese Aufgabe besser ausführt. Sie lehren das Modell im Wesentlichen neue Verhaltensweisen, Formate oder Domänenexpertise, die durch generisches Prompting nicht zuverlässig erreicht werden können.

Wann sollte ich feinabstimmen statt RAG zu verwenden?

Stimmen Sie fein ab, wenn das Modell sich anders verhalten soll -- konsistentes Ausgabeformat, domänenspezifische Sprache, bestimmter Ton. Verwenden Sie RAG, wenn das Modell andere Dinge wissen muss, besonders wenn dieses Wissen sich häufig ändert. Für viele Produktionssysteme funktioniert ein Hybridansatz am besten.

Wie viel kostet das Fine-Tuning eines LLM?

Zwischen 0 € und 540 € je nach Skalierung. Die meisten einzelnen Entwickler geben unter 1 € aus, wenn sie QLoRA auf einem RunPod RTX 4090 (0,34 $/Std.) verwenden. Ein 70-B-Produktionsmodell auf einem A100 kostet 17–27 €. Vollständiges Fine-Tuning auf H100-Clustern kostet 270–540 €. API-Fine-Tuning (OpenAI) kostet 3–25 € für 1.000 Beispiele.

Kann ich ein LLM auf meinem Laptop feinabstimmen?

Ja, wenn Ihr Laptop eine GPU mit 12+ GB VRAM hat. Eine RTX-3060-Laptop-GPU verarbeitet 8-B-Modelle mit QLoRA. Apple-Silicon-Macs mit 16+ GB Unified Memory können auch über MLX feinabstimmen, wenn auch langsamer als CUDA. Für größere Modelle benötigen Sie Cloud-GPUs.

Was ist der Unterschied zwischen LoRA und QLoRA?

Beide fügen kleine trainierbare Adapter-Schichten hinzu und frieren das Basismodell ein. Der Unterschied: QLoRA quantisiert außerdem das Basismodell auf 4-Bit-Präzision (NF4-Datentyp), was den VRAM-Verbrauch um ~25 % im Vergleich zu Standard-LoRA reduziert. Die Qualität ist nahezu identisch -- QLoRA erreicht 97–99 % der vollständigen Fine-Tuning-Qualität.

Wie viele Trainingsbeispiele benötige ich?

Es hängt von der Aufgabenkomplexität ab. 50–100 Beispiele sind genug für einen Proof of Concept. 500–1.000 Beispiele liefern nützliche Ergebnisse für die meisten Einzelaufgaben. 5.000–10.000 Beispiele liefern Produktionsqualität für komplexe Aufgaben. Über 10.000 haben Sie abnehmende Renditen, es sei denn, die Aufgabe hat eine extrem hohe Variabilität.

Welches Basismodell sollte ich 2026 feinabstimmen?

Llama 3.x für allgemeine Aufgaben (bestes Qualitäts-/Größenverhältnis). Mistral für europäische Sprachen und effiziente Inferenz. Qwen 2.5 für mehrsprachige und Code-Aufgaben. Phi-4 wenn Sie den kleinstmöglichen Footprint benötigen. Gemma 2 für Google-Ökosystem-Integration.

Was ist GRPO und warum ist es wichtig?

GRPO (Group Relative Policy Optimization), eingeführt von DeepSeek, ist ein Nachfolger von RLHF für Alignment-Training. Der wesentliche Vorteil: Es erfordert kein separates Reward-Modell-Training, was die Rechenkosten ungefähr halbiert. TRL v0.15.0 unterstützt GRPO nativ, was es für alle, die das Hugging-Face-Ökosystem nutzen, zugänglich macht.

Wie verhindere ich katastrophales Vergessen?

Verwenden Sie LoRA oder QLoRA statt vollständigem Fine-Tuning -- sie frieren die Basismodell-Gewichte ein, was allgemeines Wissen bewahrt. Halten Sie Ihre Lernrate niedrig (2e-4 für QLoRA, 2e-5 für Full). Trainieren Sie für so wenige Epochen wie nötig (1–3 reicht normalerweise). Führen Sie nach dem Training Ihr Modell auf allgemeinen Benchmarks (MMLU, HellaSwag) aus, um zu überprüfen, ob es nicht zurückgegangen ist.

Kann ich gleichzeitig feinabstimmen und RAG verwenden?

Absolut, und viele Produktionssysteme tun genau das. Feinabstimmen für Verhaltens- und Formatkonsistenz, dann RAG für aktuelle Wissensabruf verbinden. Das feinabgestimmte Modell nutzt den abgerufenen Kontext besser, weil es die Sprache und Ausgabeanforderungen Ihrer Domäne versteht.

Wie lange dauert Fine-Tuning?

Für die meisten Projekte 30 Minuten bis 8 Stunden. Ein 8-B-Modell mit 500 Beispielen auf Unsloth + RTX 4090 ist in 15–30 Minuten fertig. Derselbe Job auf einem kostenlosen Colab T4 dauert 1–2 Stunden. 70-B-Modelle auf A100s dauern 5–8 Stunden. Vollständiges Fine-Tuning auf Multi-GPU-Setups kann 20–40 Stunden dauern.

Lohnt sich die Fine-Tuning-API von OpenAI?

Für schnelles Prototyping ja. Sie können eine JSONL-Datei hochladen und in 30 Minuten ein feinabgestimmtes GPT-4o-mini haben, ohne GPU-Einrichtung. Für die Produktion ist lokales Fine-Tuning normalerweise besser: Sie besitzen die Gewichte, kontrollieren Ihren Datenschutz, und die Kosten sind bei Scale geringer. Die meisten Teams beginnen mit der API, um den Ansatz zu validieren, und wechseln dann zu lokal.

Fazit

Ein LLM feinabzustimmen ist nicht mehr das schwarze Magic, das es vor zwei Jahren war. Hier sind die wichtigsten Erkenntnisse:

1. Beginnen Sie mit QLoRA + Unsloth -- deckt 90 % der Anwendungsfälle auf Consumer-Hardware ab
2. Gute Daten schlagen ein größeres Modell jedes Mal. Investieren Sie Ihre Energie in Datensatzqualität, nicht in GPU-Upgrades.
3. Die Kostenbarriere ist weg -- feinabstimmen eines 8-B-Modells für unter 1 € auf Cloud-GPUs
4. Immer gegen das Basismodell evaluieren bevor Sie deployen. Wenn es nicht messbar besser ist, shippen Sie es nicht.
5. Zuerst RAG in Betracht ziehen -- feinabstimmen nur wenn das Modell sich anders verhalten soll, nicht nur andere Dinge wissen

Bereit zur Umsetzung? Sehen Sie unsere Best LLM Fine-Tuning Tools & Platforms [demnächst] für einen detaillierten Vergleich von Training-Frameworks und Deployment-Optionen.

Wenn Sie diesen Leitfaden nützlich fanden, schauen Sie sich unsere Anleitung zur Wahl des richtigen KI-Stacks für die umfassenderen Architekturentscheidungen rund um KI-gestützte Produkte an.

Quellen

• Unsloth GitHub Repository -- Fine-Tuning-Framework mit 2–5x Geschwindigkeitsverbesserungen
• Hugging Face TRL Dokumentation -- SFTTrainer, DPO und GRPO-Implementierung
• Hugging Face PEFT Dokumentation -- LoRA und parametereffizientes Fine-Tuning
• QLoRA-Paper (Dettmers et al., 2023) -- 4-Bit NormalFloat-Quantisierungsforschung
• LoRA-Paper (Hu et al., 2021) -- Low-Rank Adaptation großer Sprachmodelle
• OpenAI Fine-Tuning API Dokumentation -- API-basierter Fine-Tuning-Workflow
• RunPod GPU Cloud Preise -- Referenz für Cloud-GPU-Kosten
• vLLM Dokumentation -- Produktions-LLM-Serving
• Meta Llama Fine-Tuning Guide -- Offizielle Llama-Trainingsempfehlungen
• DeepSeekMath Paper (GRPO) -- Group Relative Policy Optimization