Webapp08.7.202615 Min. Lesezeitvon David Paci

Fine-Tuning mit QLoRA: Praxis-Guide für Consumer-GPUs

Inhaltsverzeichnis

Die eine Frage, die alles entscheidet
Prompt Engineering, RAG, Fine-Tuning: Der Vergleich
Wann Fine-Tuning sich lohnt – und wann nicht
Was du an Hardware brauchst
Trainingsdaten: Hier wird es ernst
Wie QLoRA funktioniert – und warum es alles verändert hat
Schritt für Schritt: QLoRA-Training mit Unsloth
Das Modell evaluieren
Häufige Fehler und wie du sie vermeidest
Deployment: Vom Training in die Produktion
Weiterführende Ressourcen
WEBSE-Lexikon: Fachbegriffe einfach erklärt

1. Die eine Frage, die alles entscheidet

Frontier-Modelle (GPT-4, Claude) mietest du über eine API. Du schickst Anfragen hin, bekommst Antworten zurück. Prompt Engineering und RAG funktionieren hier genauso. Fine-Tuning ist eingeschränkt oder gar nicht möglich, und wenn, dann auf der Infrastruktur des Anbieters, nach seinen Regeln und Preisen.

Open-Source-Modelle (Llama, Mistral, Qwen) lädst du herunter und betreibst sie auf eigener Hardware. Alle drei Ansätze funktionieren, inklusive vollem Fine-Tuning. Das Modell gehört dir, die Daten bleiben bei dir, du kontrollierst alles. Dieser Guide handelt von diesem Weg.

Die Debatte um das „beste" open source LLM ist meistens die falsche Diskussion. Jedes Basismodell ist im Werkszustand für spezifische Unternehmensprozesse weitgehend unbrauchbar. Der Hebel liegt nicht in der Wahl des Modells, sondern in der Anpassungs-Architektur.

Die gesamte strategische Einordnung lässt sich auf eine Frage reduzieren: Was fehlt dem Modell eigentlich – Wissen oder Verhalten?

Fehlt dem Modell Wissen über deine Firmendaten, Produkte oder Prozesse, ist RAG die Antwort. Fehlt dem Modell das richtige Verhalten – Tonalität, Ausgabeformat, Fachjargon – sind Prompt Engineering oder Fine-Tuning die Werkzeuge. Die Unterscheidung klingt banal, aber wer sie nicht trifft, baut Systeme, die am falschen Problem arbeiten.

2. Prompt Engineering, RAG, Fine-Tuning: Der Vergleich

Prompt Engineering: Verhalten steuern ohne das Modell zu ändern

Prompt Engineering ist der einfachste und billigste Einstieg. Du schreibst einen System-Prompt, der dem Modell sagt, wie es sich verhalten soll, gibst ihm Beispiele (Few-Shot), strukturierst die Eingabe – und iterierst. Keine Infrastruktur, keine Trainingsdaten, keine GPU nötig.

Was es kann: Tonalität verändern, Ausgabeformate vorgeben, Rollen zuweisen, Kontext mitgeben, einfache Verhaltensanpassungen.

Was es nicht kann: Dem Modell neues Wissen beibringen, das nicht in seinem Training enthalten war. Komplexe Ausgabeformate erzwingen, die das Modell bei langen Kontexten vergisst. Latenz reduzieren.

Kosten: Nahezu null. Die einzige Investition ist deine Zeit.

Wann einsetzen: Immer als erstes. Prompt Engineering ist die Baseline. Wer nicht hier anfängt und das Maximum herausholt, überspringt die Grundlagen und verbrennt Budget mit aufwändigeren Methoden, die vielleicht gar nicht nötig gewesen wären.

RAG: Wissen dynamisch bereitstellen

RAG löst das Wissensproblem, ohne das Modell anzufassen. Deine Dokumente – Verträge, Produktkataloge, Handbücher, interne Wikis – werden in einen durchsuchbaren Index überführt (typischerweise ein Vektorspeicher). Bei jeder Anfrage sucht das System zuerst die relevanten Passagen aus dem Index und reicht sie dem Modell als Kontext mit. Das Modell antwortet dann auf Basis dieser Informationen.

Was es kann: Dem Modell aktuelles, firmeneigenes Wissen bereitstellen, ohne dass das Modell neu trainiert werden muss. Wissen aktualisieren heißt Index updaten, nicht Retraining.

Was es nicht kann: Das Modell dazu bringen, sich grundlegend anders zu verhalten. RAG füttert Wissen, es ändert nicht die Art, wie das Modell antwortet.

Kosten: Moderat. Du brauchst eine Embedding-Pipeline (die Dokumente in Vektoren umwandelt), einen Vektorspeicher und die Infrastruktur, um beides zu betreiben und aktuell zu halten.

Kehrseite: Der vorgelagerte Suchschritt erhöht die Latenz. Und die Antwortqualität steht und fällt mit der Qualität des Retrievals. Wenn die Suche die falsche Passage liefert, antwortet das Modell überzeugend falsch.

Datenschutz: Wenn der gesamte Stack selbst gehostet ist, bleiben alle Daten lokal. Kein Dokument verlässt den eigenen Server.

Wann einsetzen: Wenn das Modell Zugriff auf firmeninternes, sich änderndes Wissen braucht. Dokumenten-Q&A, interner Helpdesk, Vertragsanalyse, Produktberatung.

Fine-Tuning: Das Modell selbst verändern

Fine-Tuning greift am tiefsten ein. Du trainierst das Modell auf eigenen Daten nach, und es verändert seine Gewichte – es lernt neue Muster, Verhaltensweisen, Formate. Im Gegensatz zu RAG wird das Wissen nicht zur Laufzeit bereitgestellt, sondern ist nach dem Training Teil des Modells.

Was es kann: Konsistente, komplexe Ausgabeformate erzwingen, die kein Prompt zuverlässig erzeugt. Domänenspezifischen Fachjargon verinnerlichen. Das Modell auf eine bestimmte Persona oder einen Kommunikationsstil festlegen. Latenz-optimierte Inferenz ohne Retrieval-Schritt. Air-Gapped-Betrieb komplett offline, ohne externe Abhängigkeiten.

Was es nicht gut kann: Als flexibler Wissensspeicher dienen. Jede Wissensänderung erfordert Retraining. Fine-Tuning ist kein Ersatz für RAG, wenn es um dynamisches, sich häufig änderndes Wissen geht.

Kosten: Hoch (relativ gesehen). Du brauchst eine GPU, kuratierte Trainingsdaten und Zeit für Training und Evaluation. Aber dank QLoRA ist „hoch" heute eine 12-GB-Consumer-GPU und ein Nachmittag, nicht mehr ein A100-Cluster und Wochen.

Wann einsetzen: Wenn Prompts an ihre Grenzen stoßen. Wenn das Modell sich strukturell anders verhalten soll, nicht nur anderes wissen.

Die Kombination ist oft die Antwort

Die drei Ansätze schließen sich nicht aus. Die stabilsten Enterprise-Systeme nutzen die Kombination: Ein feingetuntes Modell, das über eine RAG-Architektur mit Live-Daten arbeitet, übertrifft oft beide Techniken einzeln. Das feingetunte Modell liefert konsistentes Verhalten und Format, RAG liefert aktuelles Wissen.

Die Merkregel:

Wissen fehlt → RAG
Verhalten fehlt → Prompt Engineering
Stil, Format, Offline-Betrieb → Fine-Tuning

3. Wann Fine-Tuning sich lohnt – und wann nicht

Klare Signale für Fine-Tuning

Striktes Ausgabeformat: Dein System braucht JSON in einem exakten Schema, und das Modell weicht trotz detaillierter Prompts immer wieder ab. Bei langen Kontexten vergisst es Teile der Formatierungsanweisungen. Fine-Tuning bringt das Format in die Gewichte – es wird zur Standardausgabe, nicht zur Sonderanforderung.

Domänenspezifische Sprache: Das Modell soll in juristischem, medizinischem oder branchenspezifischem Jargon antworten – nicht nur gelegentlich, sondern durchgängig und korrekt. Ein System-Prompt kann das annähern, aber ein feingetuntes Modell trifft den Ton konsistenter.

Latenz-kritische Anwendungen: Jeder RAG-Retrieval-Schritt kostet Zeit. Wenn die Antwort in unter einer Sekunde stehen muss, ist ein Modell ohne Retrieval-Abhängigkeit im Vorteil.

Offline- und Air-Gapped-Betrieb: Kein Internet, kein API-Zugang, kein externer Vektorspeicher. Das Modell muss alles mitbringen, was es braucht. Für regulierte Umgebungen (Verteidigung, Gesundheitswesen, kritische Infrastruktur) oft eine harte Anforderung.

Persona und Ton: Das Modell soll sich über alle Interaktionen hinweg konsistent verhalten – gleiche Persönlichkeit, gleicher Kommunikationsstil, gleiche Tiefe. Prompt Engineering kann das, aber bei langen, wechselnden Kontexten driftet es.

Klare Signale gegen Fine-Tuning

Ein guter System-Prompt reicht: Wenn Prompt Engineering das gewünschte Verhalten zuverlässig erzeugt, ist Fine-Tuning unnötige Komplexität. Immer erst die einfachere Lösung maximal ausreizen.

Das Problem ist Wissen, nicht Verhalten: Wenn das Modell nicht weiß, was in deinen Verträgen steht, ist RAG die Lösung, nicht Fine-Tuning. Wissen per Fine-Tuning einzutrainieren ist statisch, teuer und bei jeder Änderung sofort veraltet.

Zu wenig Trainingsdaten: Unter 200 bis 300 sauberen Beispielen kann Fine-Tuning das Modellverhalten nicht sinnvoll verschieben. Das Modell lernt die Beispiele auswendig, statt zu generalisieren. Ab 500 Beispielen wird es für einfache Format-Aufgaben interessant, ab 3.000 für echte Domänenadaption.

4. Was du an Hardware brauchst

Es gibt drei Methoden, ein Modell zu fine-tunen. Sie unterscheiden sich radikal im Ressourcenbedarf.

Full Fine-Tuning

Alle Parameter werden aktualisiert. Das ist die gründlichste, aber auch die teuerste Methode. Für ein 7B-Modell in bf16 sind allein die Gewichte 14 GB groß. Dazu kommen Optimizer-States (bei AdamW 8 Bytes pro Parameter), Gradienten und Aktivierungen. In der Praxis brauchst du 48 GB VRAM aufwärts – das ist eine NVIDIA A6000 oder ein Multi-GPU-Setup. Für die meisten lokalen Szenarien unrealistisch, und auch nur dann gerechtfertigt, wenn der Domänenshift extrem und das Dataset sehr groß ist (Zehntausende Beispiele).

Die Zahl vor dem „B" steht für Milliarden Parameter – die internen Stellschrauben des Modells. Ein 8B-Modell hat 8 Milliarden davon. Je mehr Parameter, desto leistungsfähiger, aber auch desto mehr Grafikspeicher braucht es. QLoRA komprimiert das Basismodell auf ein Viertel seiner ursprünglichen Größe, weshalb ein 8B-Modell, das unkomprimiert 16 GB belegen würde, beim Training nur noch rund 7 GB braucht.

LoRA

Nur die kleinen Adapter-Matrizen werden trainiert, die Basisgewichte bleiben eingefroren. Das senkt den VRAM-Bedarf auf 16 bis 24 GB für 7B/8B-Modelle. Eine RTX 4090 (24 GB) oder RTX 5090 reicht komfortabel.

QLoRA (die Empfehlung für Consumer-Hardware)

QLoRA kombiniert LoRA mit 4-Bit-Quantisierung des Basismodells. Das Ergebnis ist beeindruckend: Ein 8B-Modell mit QLoRA und einer Sequenzlänge von 2048 Token peaked bei 6,6 GB VRAM. Eine RTX 4070 Ti mit 12 GB hat damit reichlich Puffer.

Für die Einordnung: Die Qualitätsdifferenz zwischen QLoRA und Full LoRA liegt bei 1 bis 3 Prozent auf Standard-Benchmarks. Unsloth's optimierte 4-Bit-Implementierung reduziert den Perplexity-Unterschied auf 0,02 Punkte gegenüber 8-Bit – effektiv verlustfrei für die meisten Downstream-Tasks.

Übersicht VRAM-Bedarf (QLoRA, Sequenzlänge 2048, Batch Size 1):

7B–8B-Modell: ~7 GB → RTX 4070 Ti (12 GB) reicht
13B-Modell: ~10 GB → RTX 4080 (16 GB) reicht
70B-Modell: ~40 GB → Dual RTX 4090 oder Cloud (A100/H100)

Keine lokale GPU? Cloud-Instanzen auf RunPod, Lambda oder Vast.ai mit A100 oder H100 eliminieren die Hardware-Frage. Preise schwanken stark – vor dem Provisionieren vergleichen.

5. Trainingsdaten: Hier wird es ernst

Der häufigste Grund für ein gescheitertes Fine-Tuning ist nicht die falsche Hyperparameter-Konfiguration. Es sind schlechte Trainingsdaten.

Wie viele Beispiele brauchst du?

Das hängt von der Aufgabe ab:

Einfache Formatierung oder Klassifikation: 500 bis 1.000 Beispiele reichen oft für messbare Verbesserungen.
Domänenadaption (das Modell soll juristisch, medizinisch oder branchenspezifisch antworten): 3.000 bis 10.000 Beispiele.
Ab 10.000 Beispielen setzen Diminishing Returns ein – es sei denn, die Domäne ist außergewöhnlich breit.

Der entscheidende Punkt: 200 handkuratierte Beispiele schlagen 2.000 gescrapte. Die Investition in Datenqualität – saubere Instruktionen, konsistente Antworten, keine Formatierungsbrüche – zahlt sich stärker aus als jedes Hyperparameter-Tuning.

Die drei gängigen Datenformate

ChatML ist das Standardformat für Chat-Modelle und die empfohlene Wahl für Instruction-Following und konversationelles Fine-Tuning. Jede Nachricht hat eine explizite Rolle (system, user, assistant) und ist durch Token-Grenzen markiert:

{
  "messages": [
    {"role": "system", "content": "Du bist ein Experte für Arbeitsrecht."},
    {"role": "user", "content": "Was ist bei einer Kündigung zu beachten?"},
    {"role": "assistant", "content": "Bei einer Kündigung sind folgende Punkte..."}
  ]
}

ShareGPT speichert Konversationen als Liste von Turns mit from- und value-Feldern. Verbreitet für Community-Datasets auf Hugging Face.

Alpaca ist die einfachste Option für Single-Turn-Tasks: instruction, input, output. Gut für Klassifikation und einfache Frage-Antwort-Szenarien.

Typische Fehler bei den Trainingsdaten

Overfitting bei zu wenig Daten: Bei unter 500 Beispielen memoriert das Modell die Trainingsbeispiele, statt daraus zu generalisieren. Es gibt die Trainingsbeispiele fast wörtlich wieder, versagt aber bei neuen Eingaben.

Label Leakage: Informationen, die eigentlich in der Antwort stehen sollten, tauchen bereits in der Instruktion auf. Das bläht die Evaluationsmetriken auf, produziert aber ein Modell, das in der Praxis versagt.

Inkonsistente Formatierung: Manche Antworten sind Markdown, andere Plain Text, manche haben Bullet Points, andere Fließtext. Das Modell lernt Formatierungsrauschen statt des eigentlichen Zielverhaltens.

Dataset-Pipeline: Rohdaten in ChatML verwandeln

Die folgende Python-Funktion nimmt CSV- oder JSON-Rohdaten entgegen, entfernt Duplikate per SHA-256-Hash, filtert nach Textlänge und erstellt einen Train/Validation-Split:

import json
import hashlib
import random
from pathlib import Path

def load_raw_data(filepath):
    """Lädt Rohdaten aus CSV oder JSON."""
    path = Path(filepath)
    if path.suffix == ".json":
        with open(path, encoding="utf-8") as f:
            return json.load(f)
    elif path.suffix == ".csv":
        import csv
        with open(path, encoding="utf-8-sig") as f:
            return list(csv.DictReader(f))
    raise ValueError(f"Format nicht unterstützt: {path.suffix}")

def to_chatml(record, system_prompt="You are a helpful domain expert."):
    """Konvertiert einen Datensatz mit 'instruction' und 'response' nach ChatML."""
    return {
        "messages": [
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": record["instruction"].strip()},
            {"role": "assistant", "content": record["response"].strip()},
        ]
    }

def deduplicate(records):
    """Entfernt exakte Duplikate per SHA-256-Hash über instruction + response."""
    seen = set()
    unique = []
    for r in records:
        key = hashlib.sha256(
            (r["instruction"] + r["response"]).encode()
        ).hexdigest()
        if key not in seen:
            seen.add(key)
            unique.append(r)
    return unique

def filter_by_length(records, min_chars=50, max_chars=4000):
    """Entfernt zu kurze oder zu lange Antworten."""
    return [r for r in records
            if min_chars <= len(r.get("response", "")) <= max_chars]

def prepare_dataset(input_path, output_dir, val_ratio=0.1,
                    system_prompt="You are a helpful domain expert."):
    """Komplette Pipeline: Laden, Deduplizieren, Filtern, Splitten, Speichern."""
    random.seed(42)
    raw = load_raw_data(input_path)
    print(f"Geladen: {len(raw)} Datensätze")

    raw = deduplicate(raw)
    print(f"Nach Deduplizierung: {len(raw)}")

    raw = filter_by_length(raw)
    print(f"Nach Längenfilter: {len(raw)}")

    random.shuffle(raw)
    split_idx = int(len(raw) * (1 - val_ratio))
    train = [to_chatml(r, system_prompt) for r in raw[:split_idx]]
    val = [to_chatml(r, system_prompt) for r in raw[split_idx:]]

    out = Path(output_dir)
    out.mkdir(parents=True, exist_ok=True)
    for name, data in [("train.json", train), ("val.json", val)]:
        with open(out / name, "w", encoding="utf-8") as f:
            json.dump(data, f, ensure_ascii=False)
    print(f"Train: {len(train)}, Validation: {len(val)}")

# Beispielaufruf
prepare_dataset("raw_data.json", "./dataset")

Der 90/10-Split (90 % Training, 10 % Validation) ist der Standard. Der Validierungssplit wird nicht zum Training genutzt, sondern zur Überwachung, ob das Modell generalisiert oder nur auswendig lernt.

6. Wie QLoRA funktioniert – und warum es alles verändert hat

Bis vor wenigen Jahren war Fine-Tuning ein Privileg für Teams mit Cloud-Budgets. QLoRA hat das komplett verändert. Um zu verstehen warum, muss man kurz verstehen, was beim Fine-Tuning technisch passiert.

Full Fine-Tuning: Alle Gewichte anfassen

Beim klassischen Full Fine-Tuning werden alle Parameter des Modells aktualisiert. Für ein 8B-Modell in bf16 (2 Bytes pro Parameter) sind das 16 GB allein für die Gewichte. Dazu kommen Gradienten (nochmal 16 GB) und die Optimizer-States von AdamW (32 GB – zwei Zustände à 4 Bytes pro Parameter). In Summe: über 60 GB VRAM. Dafür braucht man eine A100 oder mehrere Consumer-GPUs.

Full Fine-Tuning hat zudem das höchste Risiko für Catastrophic Forgetting: Das Modell vergisst allgemeines Wissen, während es sich auf die Domäne spezialisiert.

LoRA: Nur die relevanten Teile trainieren

LoRA (Low-Rank Adaptation) friert die gesamten Basisgewichte ein und injiziert in jede relevante Schicht zwei kleine Matrizen: A (Dimension r × d_in) und B (Dimension d_out × r). Statt die gesamte Gewichtsmatrix W zu aktualisieren, wird nur das Produkt B·A trainiert, wobei der Rang r bewusst klein gehalten wird (typischerweise 8 bis 64).

Das reduziert die trainierbaren Parameter auf rund 0,4 % des Gesamtmodells. Weniger zu trainierende Parameter bedeuten weniger VRAM für Gradienten und Optimizer-States.

QLoRA: LoRA plus 4-Bit-Quantisierung

QLoRA geht einen Schritt weiter und kombiniert LoRA mit drei Optimierungen:

4-Bit NormalFloat (NF4): Die eingefrorenen Basisgewichte werden nicht in 16 Bit, sondern in 4 Bit gespeichert. Das reduziert den Speicherbedarf für die Gewichte um den Faktor 4.
Paged Optimizers: Wenn der GPU-Speicher während des Trainings knapp wird, lagern die Optimizer-States automatisch auf die CPU aus. Das verhindert Out-of-Memory-Crashes.
Double Quantization: Selbst die Quantisierungskonstanten werden quantisiert. Ein kleiner, aber spürbarer zusätzlicher Speichergewinn.

Die LoRA-Adapter selbst rechnen weiterhin in bf16 oder fp16 – nur die eingefrorenen Basisgewichte sind quantisiert. Das Training geschieht also in voller Präzision, nur die „Bibliothek im Hintergrund" ist komprimiert.

Die wichtigsten Hyperparameter im Überblick

Rank (r): Bestimmt die Kapazität der Adapter. Niedrigerer Rank = weniger trainierbare Parameter, weniger VRAM, schnelleres Training – aber auch weniger Anpassungsfähigkeit. Orientierung:

Rank 8: Einfache Format- und Stilanpassungen
Rank 16–32: Moderate Domänenshifts, die gängigste Wahl
Rank 64: Substanzielle Wissensinjektionen oder komplexe Verhaltensänderungen

Alpha: Ein Skalierungsfaktor, der bestimmt, wie stark die LoRA-Adapter die Ausgabe beeinflussen. Übliche Wahl: das Doppelte des Ranks (Alpha 32 bei Rank 16). Das Verhältnis Alpha/Rank wirkt als effektiver Multiplikator auf die Lernrate.

Target Modules: Welche Schichten LoRA-Adapter bekommen. Standard ist, alle Projektionsmatrizen der Attention-Schicht (q_proj, k_proj, v_proj, o_proj) plus die Feed-Forward-Layer (gate_proj, up_proj, down_proj) zu instrumentieren. Mehr Target Modules = mehr Anpassungsfähigkeit, aber auch mehr VRAM.

Lernrate (Learning Rate): Wie stark die Gewichte pro Trainingsschritt angepasst werden. Für QLoRA hat sich 2e-4 als guter Startwert etabliert. Bei instabilem Training auf 1e-4 reduzieren, bei zu langsamer Konvergenz auf 3e-4 erhöhen.

Epochen: Wie oft das Modell den gesamten Trainingsdatensatz durchläuft. 1 bis 3 Epochen bei großen Datasets (5.000+), 3 bis 5 bei kleineren. Mehr Epochen erhöhen das Overfitting-Risiko.

7. Schritt für Schritt: QLoRA-Training mit Unsloth

1. Software-Stack aufsetzen

Der aktuelle Stack (Stand Mitte 2026) besteht aus Python 3.11+, PyTorch 2.5+, CUDA 12.x und dem Hugging Face-Ökosystem. Unsloth liefert die optimierten Trainings-Kernels. Die Versionen zu pinnen ist wichtig für Reproduzierbarkeit.

conda create -n finetune python=3.11 -y
conda activate finetune

# PyTorch mit CUDA-Unterstützung installieren
# Die richtige Index-URL hängt von deiner CUDA-Version ab:
# https://pytorch.org/get-started/locally
pip install torch==2.5.1 --index-url https://download.pytorch.org/whl/cu124

# Unsloth und Hugging-Face-Stack
pip install "unsloth>=2025.3,<2026.0"
pip install transformers==4.48.0 datasets==3.2.0 peft==0.14.0 trl==0.14.0
pip install bitsandbytes==0.45.0

# Monitoring und Tokenizer-Support
pip install wandb tensorboard sentencepiece protobuf

# Prüfen, ob CUDA erkannt wird
python -c "import torch; print(f'CUDA: {torch.cuda.is_available()}, GPU: {torch.cuda.get_device_name(0)}')"

Was die Pakete machen: unsloth patcht Hugging-Face-Internals mit Triton-Kernels für schnelleres Training bei weniger Speicher. bitsandbytes liefert die 4-Bit-Quantisierung und den paged_adamw_8bit-Optimizer. peft ist die Hugging-Face-Bibliothek für LoRA. trl enthält den SFTTrainer für Supervised Fine-Tuning. wandb oder tensorboard dienen der Trainingsüberwachung (optional, aber empfohlen).

2. Basismodell wählen

Für Consumer-Hardware ist die 7B/8B-Klasse der Sweet Spot. Die Modelle, die sich 2026 am besten für QLoRA-Fine-Tuning eignen:

Llama 3.1 8B: Metas Flaggschiff in der 8B-Klasse. Llama Community License (für die meisten kommerziellen Anwendungen nutzbar; aktuelle Bedingungen auf ai.meta.com/llama/license prüfen). Gated Model auf Hugging Face – du musst die Lizenz akzeptieren und dich mit huggingface-cli login authentifizieren.
Mistral 7B v0.3: Apache 2.0, also völlig frei kommerziell nutzbar. Stark bei Reasoning und Code.
Qwen 2.5 7B: Apache 2.0. Besonders stark bei multilingualen Aufgaben.

Unsloth stellt vorab quantisierte Versionen auf Hugging Face bereit (z.B. unsloth/Meta-Llama-3.1-8B-Instruct-bnb-4bit), die den Download beschleunigen und sicherstellen, dass die Quantisierung korrekt konfiguriert ist.

3. Training konfigurieren und starten

Das folgende Skript zeigt einen kompletten QLoRA-Trainingslauf mit Unsloth und dem SFTTrainer aus der trl-Bibliothek:

from unsloth import FastLanguageModel
from trl import SFTTrainer
from transformers import TrainingArguments
from datasets import load_dataset

# ---------- Konfiguration ----------
max_seq_length = 2048  # Maximale Sequenzlänge (Kontextfenster fürs Training)
model_name = "unsloth/Meta-Llama-3.1-8B-Instruct-bnb-4bit"

# ---------- Modell laden ----------
# load_in_4bit=True aktiviert die QLoRA-Quantisierung
# dtype=None wählt automatisch: bf16 auf Ampere+ GPUs, fp16 auf älteren
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name=model_name,
    max_seq_length=max_seq_length,
    dtype=None,
    load_in_4bit=True,
)

# ---------- LoRA-Adapter konfigurieren ----------
model = FastLanguageModel.get_peft_model(
    model,
    r=16,              # Rank: 8-64, je nach Komplexität der Aufgabe
    lora_alpha=32,      # Skalierungsfaktor, üblicherweise 2x Rank
    target_modules=[    # Welche Schichten LoRA-Adapter bekommen
        "q_proj", "k_proj", "v_proj", "o_proj",  # Attention
        "gate_proj", "up_proj", "down_proj",       # Feed-Forward
    ],
    lora_dropout=0.05,  # Dropout zur Regularisierung
    bias="none",
    use_gradient_checkpointing="unsloth",  # Unsloths optimiertes Checkpointing
)

# ---------- Dataset laden und formatieren ----------
dataset = load_dataset("json", data_files={
    "train": "./dataset/train.json",
    "validation": "./dataset/val.json",
})

def format_chat(example):
    """Wandelt ChatML-Messages in den vom Tokenizer erwarteten String um."""
    return {"text": tokenizer.apply_chat_template(
        example["messages"], tokenize=False, add_generation_prompt=False
    )}

dataset = dataset.map(format_chat, remove_columns=["messages"])

# ---------- Training-Parameter ----------
training_args = TrainingArguments(
    output_dir="./output",
    per_device_train_batch_size=4,       # Pro GPU verarbeitete Beispiele
    gradient_accumulation_steps=4,       # Effektive Batch Size = 4 × 4 = 16
    warmup_steps=50,                     # Langsamer Start der Lernrate
    num_train_epochs=3,                  # Anzahl Durchläufe durch die Daten
    learning_rate=2e-4,                  # Lernrate (Standard für QLoRA)
    bf16=True,                           # bf16-Precision (auf Ampere+ GPUs)
    logging_steps=10,                    # Alle 10 Schritte loggen
    save_strategy="steps",
    save_steps=100,                      # Alle 100 Schritte Checkpoint speichern
    save_total_limit=3,                  # Maximal 3 Checkpoints behalten
    eval_strategy="steps",
    eval_steps=100,                      # Alle 100 Schritte evaluieren
    load_best_model_at_end=True,         # Am Ende den besten Checkpoint laden
    metric_for_best_model="eval_loss",   # "Best" = niedrigster Validation Loss
    optim="paged_adamw_8bit",            # Speichersparender Optimizer
    lr_scheduler_type="cosine",          # Cosine-Lernratenabfall
    seed=42,                             # Reproduzierbarkeit
    report_to=[],                        # Kein externes Logging (für WandB: ["wandb"])
)

# ---------- Trainer initialisieren ----------
trainer = SFTTrainer(
    model=model,
    tokenizer=tokenizer,
    train_dataset=dataset["train"],
    eval_dataset=dataset["validation"],
    args=training_args,
    dataset_text_field="text",
    max_seq_length=max_seq_length,
    packing=True,  # Kurze Beispiele werden zusammengepackt für Effizienz
)

# ---------- Training starten ----------
trainer.train()

# ---------- Checkpoint speichern ----------
trainer.save_model("./output/final_checkpoint")
tokenizer.save_pretrained("./output/final_checkpoint")
print("Training abgeschlossen. Checkpoint gespeichert.")

Hinweis zu report_to: Wenn du ["wandb"] einträgst, werden Trainingsmetriken und Loss-Kurven an die Server von Weights & Biases übertragen – hilfreich fürs Monitoring, aber nicht für sensible oder proprietäre Daten. Für vollständig lokales Tracking: ["tensorboard"] verwenden.

Trainingszeiten als Orientierung

Die tatsächliche Trainingszeit hängt von GPU, Dataset-Größe und Konfiguration ab. Richtwerte für 5.000 Beispiele mit obiger Konfiguration:

RTX 4090 (24 GB): 1 bis 2 Stunden für 3 Epochen
RTX 4070 Ti (12 GB): 2 bis 4 Stunden (kleinere Batches, mehr Gradient Accumulation)
Cloud A100 (40 GB): Unter 1 Stunde

4. Adapter mergen und exportieren

Nach dem Training existieren die LoRA-Adapter als separate Dateien neben dem Basismodell. Für den produktiven Einsatz müssen sie in das Basismodell gemergt (zusammengeführt) werden. Optional – und für lokalen Betrieb empfohlen – kann das Ergebnis als GGUF-Datei exportiert werden, die direkt mit Ollama oder llama.cpp läuft.

import torch
from unsloth import FastLanguageModel

# Modell in 16-Bit laden (NICHT 4-Bit!) für verlustfreien Merge
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="./output/final_checkpoint",
    max_seq_length=2048,
    dtype=torch.bfloat16,
    load_in_4bit=False,  # Muss False sein für lossless Merge
)

# LoRA-Gewichte in das Basismodell mergen
model.save_pretrained_merged(
    "./output/merged_model",
    tokenizer,
    save_method="merged_16bit",  # Volle Präzision
)

# GGUF-Export für Ollama / llama.cpp
model.save_pretrained_gguf(
    "./output/gguf_model",
    tokenizer,
    quantization_method="q4_k_m",  # Bester Kompromiss Größe/Qualität
)

print("Modell gemergt und als GGUF exportiert.")

Welche Quantisierungsstufe wählen? Die drei gängigen GGUF-Optionen für ein 8B-Modell:

Q4_K_M (~4,5 Bits pro Gewicht, ~4,9 GB): Bestes Verhältnis aus Dateigröße und Qualität. Für die meisten Anwendungen die richtige Wahl.
Q5_K_M (~5,5 Bits, ~5,7 GB): Etwas höhere Genauigkeit, moderater Größenzuwachs.
Q8_0 (8 Bits, ~8,5 GB): Fast volle Qualität, doppelte Dateigröße gegenüber Q4_K_M. Sinnvoll, wenn Speicher kein Problem ist.

8. Das Modell evaluieren

Ein Fine-Tuning ohne Evaluation ist Blindflug. Du weißt nicht, ob das Modell tatsächlich besser geworden ist – oder ob du nur Geld und Strom verbrannt hast.

Quantitative Evaluation

Validation Loss / Perplexity: Während des Trainings wird der Loss auf dem Validierungsset gemessen. Sinkender Validation Loss = das Modell generalisiert. Steigender Validation Loss bei sinkendem Training Loss = Overfitting.

Taskspezifische Metriken: Für Klassifikation zählen F1 und Exact Match. Für Generierungsaufgaben sind BLEU und ROUGE gängige Metriken, aber sie messen nur N-Gram-Überlappung und korrelieren schwach mit menschlicher Qualitätseinschätzung. Besser: LLM-as-Judge (ein starkes Modell bewertet die Ausgaben des feingetunten Modells) oder menschliche Bewertung.

Der entscheidende Vergleich: Das feingetunte Modell muss gegen das Basismodell mit optimierten Prompts antreten, nicht gegen das Basismodell ohne Prompts. Wenn das Fine-Tuned-Modell nur marginal besser abschneidet als das Basismodell mit einem guten System-Prompt, war das Fine-Tuning nicht gerechtfertigt.

Qualitative Evaluation: Side-by-Side-Vergleich

Identische Prompts durch beide Modelle jagen und die Ergebnisse nebeneinanderlegen. Das folgende Skript lädt die Modelle sequenziell (nicht gleichzeitig), um OOM auf Consumer-GPUs zu vermeiden:

import torch
from unsloth import FastLanguageModel

def run_inference(model, tokenizer, messages, device="cuda"):
    """Tokenisiert, generiert, und decodiert nur die neuen Tokens."""
    inputs = tokenizer.apply_chat_template(
        messages, tokenize=True,
        return_tensors="pt", add_generation_prompt=True,
    ).to(device)
    with torch.no_grad():
        output = model.generate(
            input_ids=inputs,
            max_new_tokens=256,
            pad_token_id=tokenizer.eos_token_id,
        )
    return tokenizer.decode(output[0][inputs.shape[-1]:],
                            skip_special_tokens=True)

# Test-Prompts: Abgestimmt auf deine Domäne
test_prompts = [
    "Erkläre den Unterschied zwischen LoRA und Full Fine-Tuning.",
    "Erstelle eine Zusammenfassung des Q3-Compliance-Berichts.",
    "Welche Fristen gelten bei einer ordentlichen Kündigung?",
]

# Modelle nacheinander laden und testen
for model_path, label in [
    ("unsloth/Meta-Llama-3.1-8B-Instruct-bnb-4bit", "BASISMODELL"),
    ("./output/final_checkpoint", "FINE-TUNED"),
]:
    model, tokenizer = FastLanguageModel.from_pretrained(
        model_name=model_path, max_seq_length=2048, load_in_4bit=True,
    )
    FastLanguageModel.for_inference(model)

    for prompt in test_prompts:
        result = run_inference(model, tokenizer,
                               [{"role": "user", "content": prompt}])
        print(f"\n{'='*50}")
        print(f"{label} | Prompt: {prompt}")
        print(f"Antwort: {result}")

    # VRAM freigeben vor dem nächsten Modell
    del model
    torch.cuda.empty_cache()

Red-Teaming nicht vergessen

Neben den positiven Tests (macht das Modell, was es soll?) ist Red-Teaming kritisch:

Regression prüfen: Kann das Modell allgemeine Wissensfragen noch beantworten, die das Basismodell konnte?
Halluzinationen suchen: Hat das Modell durch Overfitting angefangen, Dinge zu erfinden?
Edge Cases testen: Wie reagiert das Modell auf Eingaben an den Grenzen der Domäne?

9. Häufige Fehler und wie du sie vermeidest

Loss konvergiert nicht

Die häufigste Ursache ist eine zu hohe Lernrate. Bei QLoRA mit 2e-4 starten und bei instabilem Verlauf auf 1e-4 reduzieren. Die zweithäufigste Ursache: kaputte ChatML-Templates im Dataset. Wenn die Token-Grenzen nicht stimmen, trainiert das Modell auf Müll-Tokens.

Catastrophic Forgetting (Modell verliert Allgemeinwissen)

Das Modell performt in der Domäne, aber versagt bei allgemeinen Fragen, die das Basismodell beantworten konnte. Gegenmaßnahmen: Epochen reduzieren, Lernrate senken, LoRA-Rank verringern. Am wirkungsvollsten: 5 bis 10 Prozent allgemeine Instruction-Following-Daten ins Trainingsset mischen. Das zwingt das Modell, seine allgemeinen Fähigkeiten beizubehalten.

Overfitting (Training Loss ↓, Validation Loss ↑)

Die klassische Falle: Das Modell lernt die Trainingsbeispiele auswendig, statt zu generalisieren. Erkennbar daran, dass der Training Loss gegen null geht, während der Validation Loss steigt. Gegenmaßnahmen: Epochen reduzieren, Dropout erhöhen, Dataset erweitern. Bei unter 1.000 Beispielen reichen fast immer 1 bis 3 Epochen.

CUDA Out of Memory (OOM)

Die GPU hat nicht genug Speicher. Lösungen in dieser Reihenfolge:

Batch Size reduzieren (z.B. von 4 auf 2)
Gradient Accumulation Steps erhöhen, um die effektive Batch Size zu halten
Gradient Checkpointing aktivieren (in obiger Konfiguration bereits aktiv)
Sequenzlänge reduzieren (z.B. von 2048 auf 1024)
LoRA-Rank reduzieren (z.B. von 16 auf 8)

Hyperparameter-Tuning: Pragmatisch statt erschöpfend

Ein Sweep über drei Lernraten (1e-4, 2e-4, 3e-4) auf 10 Prozent der Trainingsdaten (1 Epoche) identifiziert die richtige Größenordnung schnell und günstig. Wenn die Ergebnisse danach immer noch schlecht sind: Mehr und bessere Trainingsdaten bringen nachweislich mehr als weiteres Hyperparameter-Tuning. Die Datenqualität ist fast immer der größere Hebel.

10. Deployment: Vom Training in die Produktion

Das exportierte GGUF-Modell ist ein einzelnes File. Um es produktiv einzusetzen, gibt es zwei bewährte Wege.

Lokale Inferenz mit Ollama

Ollama ist ein Open-Source-Tool, das LLMs lokal auf Mac, Windows und Linux ausführbar macht. Es funktioniert wie Docker für KI-Modelle: Download, Konfiguration und Ausführung in einem Befehl. Ein GGUF-Modell importierst du so:

# Modelfile erstellen
cat > Modelfile << 'EOF'
FROM ./output/gguf_model/unsloth.Q4_K_M.gguf
PARAMETER temperature 0.7
PARAMETER top_p 0.9
SYSTEM "Du bist ein Experte für [deine Domäne]."
EOF

# Modell importieren
ollama create mein-modell -f Modelfile

# Modell starten
ollama run mein-modell

Danach läuft das Modell lokal und ist über http://localhost:11434 per REST-API erreichbar – kompatibel mit dem OpenAI-API-Format. Das heißt: Bestehende Anwendungen, die gegen die OpenAI-API gebaut sind, können mit minimalem Aufwand auf das lokale Modell umgestellt werden.

REST-API für Anwendungs-Integration

Für die Integration in eigene Systeme bietet Ollama eine OpenAI-kompatible API. Alternativ kannst du llama-cpp-python mit dem eingebauten OpenAI-kompatiblen Server nutzen:

pip install llama-cpp-python[server]
python -m llama_cpp.server --model ./output/gguf_model/unsloth.Q4_K_M.gguf --port 8000

Retraining-Pipeline

Ein einmaliges Fine-Tuning ist selten das Ende. Für kontinuierliche Verbesserung lohnt sich eine Retraining-Pipeline, die anspringt, wenn neue gelabelte Daten einen Schwellwert überschreiten (z.B. 500 neue Beispiele) oder die Evaluationsscores unter eine definierte Baseline fallen.

11. Weiterführende Ressourcen

Unsloth – Open-Source-Framework für optimiertes Fine-Tuning. GitHub (67k+ Stars), Dokumentation, Free Colab Notebook zum Ausprobieren.
Unsloth Studio – No-Code-UI für Training und Inferenz, läuft lokal auf Mac, Windows und Linux. Für alle, die kein Python schreiben wollen.
Hugging Face – Modelle, Datasets und das Python-Ökosystem (transformers, datasets, peft, trl).
Ollama – Lokale LLM-Inferenz auf Mac, Windows, Linux. OpenAI-kompatible API.
llama.cpp – C/C++-Inferenz-Engine für GGUF-Modelle, die Grundlage von Ollama.
RunPod / Lambda / Vast.ai – Cloud-GPU-Anbieter für Training ohne eigene Hardware.

Icon Lexikon Webse Lexikon Fakten einfach erklärt

WEBSE-Lexikon: Fachbegriffe einfach erklärt

LLM (Large Language Model): Ein großes Sprachmodell. Das ist die KI hinter ChatGPT, Claude und Co. Es wurde auf riesigen Textmengen trainiert und kann deshalb Sprache verstehen und produzieren. Manche LLMs sind nur über das Internet nutzbar (z.B. GPT-4), andere kann man herunterladen und auf dem eigenen Rechner betreiben (z.B. Llama, Mistral).
Parameter und Modellgrößen (7B, 8B, 70B): Das „B" steht für Milliarden (englisch: Billions). Ein 8B-Modell hat 8 Milliarden innere Stellschrauben, die beim Training justiert wurden. Je mehr Parameter, desto leistungsfähiger, aber auch desto hungriger nach Speicher und Rechenpower. 8B ist die Klasse, die heute auf einem normalen Gaming-Rechner läuft. 70B braucht deutlich teurere Hardware oder einen Cloud-Server.
GPU (Grafikkarte): Der Chip in deinem Rechner, der ursprünglich für Spiele und 3D-Grafik gebaut wurde. Weil er massenhaft Berechnungen gleichzeitig ausführen kann, ist er heute auch das Herzstück für KI-Training. Für lokales Fine-Tuning brauchst du eine NVIDIA-Grafikkarte (z.B. aus der RTX-Serie).
VRAM: Der Arbeitsspeicher auf der Grafikkarte. Nicht zu verwechseln mit dem normalen Arbeitsspeicher (RAM) deines Rechners. Beim KI-Training ist VRAM der Engpass: Passt das Modell nicht in den VRAM, läuft das Training nicht. Eine typische Gaming-Grafikkarte hat 8 bis 24 GB VRAM.
CUDA: NVIDIAs Technik, die es erlaubt, allgemeine Berechnungen auf der Grafikkarte auszuführen, nicht nur Grafik. Voraussetzung für jedes lokale KI-Training. Nur NVIDIA-Karten haben CUDA.
Fine-Tuning: Das Nachtrainieren eines fertigen KI-Modells auf eigenen Daten. Statt ein Modell von null aufzubauen (was Millionen kostet), passt man ein bestehendes Modell an den eigenen Betrieb an. Danach kann es z.B. deinen Branchenjargon oder dein gewünschtes Antwortformat.
LoRA (Low-Rank Adaptation): Ein Verfahren, das Fine-Tuning drastisch billiger macht. Statt alle Milliarden Stellschrauben im Modell anzufassen, werden nur winzige Ergänzungen (sogenannte Adapter) trainiert, weniger als ein Prozent des Gesamtmodells. Der Rest bleibt unverändert. Das senkt den Speicherbedarf enorm.
QLoRA (Quantized LoRA): LoRA plus eine zusätzliche Komprimierung des Basismodells. Das Ergebnis: Ein 8-Milliarden-Parameter-Modell lässt sich auf einer Grafikkarte mit 12 GB Speicher trainieren, also auf Consumer-Hardware, die unter 500 Euro kostet. Die Qualitätseinbuße gegenüber der teureren Variante ist minimal.
Quantisierung: Ein Komprimierungsverfahren für KI-Modelle. Die inneren Zahlenwerte des Modells werden mit weniger Nachkommastellen gespeichert (z.B. 4 Bit statt 16 Bit). Das Modell wird kleiner und schneller, bei geringem Qualitätsverlust. Verschiedene Stufen (Q4, Q5, Q8) bieten unterschiedliche Kompromisse zwischen Größe und Genauigkeit.
RAG (Retrieval-Augmented Generation): Eine Technik, bei der die KI vor dem Antworten zuerst in einer Wissensdatenbank nachschlägt, z.B. in deinen Firmendokumenten, Verträgen oder Produktdaten. Das Wissen muss nicht ins Modell eintrainiert werden, sondern bleibt in einer separaten, jederzeit aktualisierbaren Ablage.
Prompt Engineering: Die Kunst, einer KI die richtige Anweisung zu geben. Durch geschickt formulierte Instruktionen lässt sich das Verhalten des Modells steuern, ohne es zu verändern. Der einfachste und billigste Weg, ein KI-Modell an die eigenen Bedürfnisse anzupassen.
Inferenz: Das Modell laufen lassen. Im Unterschied zum Training, bei dem das Modell lernt, nutzt es bei der Inferenz sein vorhandenes Können, um auf eine Eingabe zu antworten. Jede Frage, die du ChatGPT stellst, ist Inferenz.
Token: Die kleinen Textbausteine, in die eine KI Sprache zerlegt. Ein Wort kann ein Token sein, manchmal sind es auch Wortteile oder einzelne Zeichen. Wichtig, weil KI-Kosten oft pro Token berechnet werden und der Speicherbedarf beim Training von der Anzahl der Tokens pro Beispiel abhängt.
Epoche: Ein vollständiger Durchlauf durch alle Trainingsdaten. Wenn du 1.000 Beispiele hast und 3 Epochen trainierst, sieht das Modell jedes Beispiel dreimal. Zu wenige Epochen: Das Modell lernt zu wenig. Zu viele: Es lernt die Beispiele auswendig statt allgemeine Muster.
Batch Size: Wie viele Trainingsbeispiele die KI in einem Schritt gleichzeitig verarbeitet. Größere Batches sind schneller, brauchen aber mehr Grafikspeicher. Ein gängiger Trick (Gradient Accumulation) sammelt die Ergebnisse mehrerer kleiner Batches und rechnet sie zusammen, als wäre es ein großer.
Lernrate (Learning Rate): Wie stark das Modell seine Stellschrauben pro Trainingsschritt verstellt. Zu hoch: Das Modell schießt über das Ziel hinaus und lernt nichts Stabiles. Zu niedrig: Das Training dauert ewig oder kommt nicht voran. Für QLoRA hat sich ein Wert von 0,0002 als guter Startpunkt bewährt.
Overfitting: Das Modell hat die Trainingsbeispiele auswendig gelernt, statt daraus allgemeine Muster abzuleiten. Es gibt auf bekannte Beispiele perfekte Antworten, versagt aber bei neuen Eingaben. Das Risiko steigt, je kleiner der Trainingsdatensatz und je mehr Epochen.
Catastrophic Forgetting: Das Modell vergisst durch das Nachtrainieren, was es vorher konnte. Es wird in der neuen Domäne besser, kann dafür aber plötzlich keine allgemeinen Fragen mehr beantworten. Wird durch niedrigere Lernraten und das Beimischen allgemeiner Trainingsdaten verhindert.
Checkpoint: Ein Zwischenspeicherstand während des Trainings. Wie ein Speicherpunkt in einem Spiel: Wenn etwas schiefgeht, kannst du zum letzten guten Stand zurückkehren, statt von vorn anzufangen.
ChatML: Ein standardisiertes Datenformat für Trainingsdaten. Jede Nachricht hat eine klare Rolle (System, Nutzer, Assistent), damit das Modell lernt, wer spricht und wann es selbst an der Reihe ist.
GGUF: Ein Dateiformat für komprimierte KI-Modelle, das für die lokale Ausführung optimiert ist. Die Datei enthält alles, was nötig ist, um das Modell auf dem eigenen Rechner laufen zu lassen. Ein 8B-Modell in GGUF ist rund 5 GB groß, passt also auf einen USB-Stick.
Ollama: Ein kostenloses Programm, das KI-Modelle auf deinem Rechner ausführt (Mac, Windows, Linux). Es funktioniert wie eine Art App-Store für KI: Modell auswählen, herunterladen, starten. Keine Cloud nötig, keine laufenden Kosten.
Unsloth: Ein Open-Source-Werkzeug, das das Fine-Tuning auf normaler Consumer-Hardware möglich macht. Es optimiert den Trainingsprozess so, dass er bis zu 70 Prozent weniger Grafikspeicher braucht und doppelt so schnell läuft. Kostenlos für eine einzelne Grafikkarte.
Hugging Face: Die zentrale Plattform der Open-Source-KI-Szene. Hier findest du tausende KI-Modelle und Trainingsdatensätze zum freien Download, plus die Software-Bibliotheken, die beim Fine-Tuning unter der Haube arbeiten.
Adapter: Die kleinen Ergänzungen, die LoRA dem Modell hinzufügt. Nach dem Training werden die Adapter in das Basismodell zusammengeführt (gemergt). Das Ergebnis ist ein einzelnes, eigenständiges Modell, das ganz normal eingesetzt werden kann.
Open Source: Software, deren Quellcode offenliegt und die kostenlos genutzt werden darf. Jeder kann nachsehen, was sie tut, sie verändern und ohne Lizenzgebühren einsetzen. Die meisten Tools in diesem Guide sind Open Source.
Air-Gapped / Offline-Betrieb: Ein System, das komplett ohne Internetverbindung arbeitet. Keine Daten verlassen das Haus, keine externen Server werden kontaktiert. Relevant für Branchen mit strengen Datenschutz-Anforderungen (Gesundheitswesen, Verteidigung, kritische Infrastruktur).
REST-API: Eine standardisierte Schnittstelle, über die Programme miteinander kommunizieren. Nach dem Fine-Tuning kann das Modell über eine REST-API angesprochen werden, sodass andere Anwendungen (z.B. ein Chatbot auf der Website oder ein internes Tool) es nutzen können, ohne das Modell direkt einzubinden.

Fragen zu deinem Projekt?

Erzähl uns, woran du arbeitest. Wir schauen es uns an und melden uns.

Projekt besprechen