Leitfaden zu KI-Fähigkeiten & Fine-Tuning
Ein vollständiger Leitfaden, um KI-Modellen neue Fähigkeiten beizubringen: Supervised Fine-Tuning (SFT), LoRA/QLoRA, RLHF, DPO, GRPO, Modell-Distillation, Modell-Merging und Evaluierung. Vom Konzept bis zur Produktion — mit funktionierendem Code in jedem Schritt.
Die Fine-Tuning-Landschaft
Das Pretraining verleiht einem Modell ein breites Weltwissen, aber nur eine Fähigkeit: das nächste Token vorherzusagen. Das Modell hat Wikipedia, Code, Bücher und das Web gesehen — aber es weiß nicht, hilfreich zu sein, Anweisungen zu folgen oder gefährliche Anfragen abzulehnen. Fine-Tuning ist der Prozess, diese Verhaltensweisen nach dem Pretraining beizubringen.
Die Branche hat sich auf eine standardisierte Trainingsleiter geeinigt, der alle großen Spitzenmodelle (GPT-4o, Claude Opus 4.6, Llama 4, Gemini 2.5) folgen. Jede Stufe baut auf der vorherigen auf — man kann SFT nicht überspringen und direkt zu RLHF springen.
Die Trainingsleiter
graph LR A[Raw Text Corpus] -->|Pretraining cross-entropy| B[Base Model] B -->|Supervised Fine-Tuning| C[Instruction-Following Model] C -->|RLHF / DPO / GRPO| D[Aligned Model] D -->|Evaluation & Red-teaming| E[Production Model]
Pretraining
Selbstüberwachte Vorhersage des nächsten Tokens auf riesigen Korpora. Kodiert Weltwissen.
SFT
Supervised Fine-Tuning auf Anweisungs-Antwort-Paaren. Bringt dem Modell bei, hilfreich zu sein.
Präferenz-Alignment
RLHF, DPO oder GRPO auf menschlichen Präferenzdaten. Macht Ausgaben sicher und bevorzugt.
Evaluierung
Automatisierte Benchmarks + Red-Teaming. Regressionen vor dem Ausliefern erkennen.
Supervised Fine-Tuning (SFT)
SFT trainiert das Modell, Assistenten-Token aus einem Gesprächskontext vorherzusagen. Das entscheidende Detail ist das Loss Masking: Der Kreuzentropie-Verlust wird nur auf Assistenten-Token berechnet, nicht auf den System-Prompt oder die Nutzer-Turns. Das verhindert, dass das Modell die Nutzerseite des Gesprächs „lernt“.
Datenformate
Drei Formate dominieren die SFT-Landschaft. ChatML hat sich aufgrund seiner eindeutigen Spezial-Token am weitesten durchgesetzt.
<|im_start|>system You are a helpful AI assistant specialized in European AI regulation. <|im_end|> <|im_start|>user What are the key obligations under the EU AI Act for high-risk systems? <|im_end|> <|im_start|>assistant High-risk AI systems under the EU AI Act (in force August 2024) must comply with... <|im_end|>
Wichtige Hyperparameter
| Parameter | Typischer Wert | Hinweise |
|---|---|---|
| Learning rate | 2e-5 | Niedriger als beim Pretraining; Cosinus-Abfall |
| Epochs | 2–3 | Mehr Epochen → Overfitting bei kleinen Datensätzen |
| Batch size (effective) | 64–128 | Gradientenakkumulation bei wenig GPU-Speicher verwenden |
| Warmup ratio | 0.1 | 10 % der Schritte für das LR-Warmup |
| Max sequence length | 2048–8192 | An Ihr Inferenz-Kontextfenster anpassen |
SFT mit dem SFTTrainer von trl
from transformers import AutoModelForCausalLM, AutoTokenizer
from trl import SFTConfig, SFTTrainer
from datasets import load_dataset
import torch
model_name = "meta-llama/Llama-4-Scout-17B-16E-Instruct" # 2026: Llama 4 Scout replaces Llama 3.1 8B
model = AutoModelForCausalLM.from_pretrained(
model_name, torch_dtype=torch.bfloat16, device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained(model_name)
dataset = load_dataset("HuggingFaceH4/ultrachat_200k", split="train_sft")
sft_config = SFTConfig(
output_dir="./sft-llama-4-scout",
num_train_epochs=3,
per_device_train_batch_size=2,
gradient_accumulation_steps=8,
learning_rate=2e-5,
lr_scheduler_type="cosine",
warmup_ratio=0.1,
logging_steps=10,
save_strategy="epoch",
bf16=True,
)
trainer = SFTTrainer(
model=model,
args=sft_config,
train_dataset=dataset,
processing_class=tokenizer,
)
trainer.train()
trainer.save_model()Parametereffizientes Fine-Tuning: LoRA
Vollständiges Fine-Tuning verändert alle ~7 Milliarden Parameter eines 7B-Modells. In bfloat16 sind das 14 GB allein für die Parameterspeicherung, plus Gradienten und Optimiererzustände. LoRA (Low-Rank Adaptation, Hu et al. 2021) nutzt eine zentrale empirische Beobachtung: Gewichtsänderungen während des Fine-Tunings sind von niedrigem Rang.
Statt ein vollständiges Gewichts-Update ΔW ∈ ℝ^(d×k) zu lernen, lernt LoRA zwei kleine Matrizen: A ∈ ℝ^(d×r) und B ∈ ℝ^(r×k) mit r ≪ min(d, k). Bei der Inferenz wird der Adapter zurückgefaltet: W′ = W + αAB/r. Nach dem Merge entsteht kein Inferenz-Overhead.
LoRA mit PEFT
from peft import LoraConfig, TaskType, get_peft_model
config = LoraConfig(
task_type=TaskType.CAUSAL_LM,
r=16,
lora_alpha=32,
lora_dropout=0.05,
target_modules=[
"q_proj", "k_proj", "v_proj", "o_proj",
"gate_proj", "up_proj", "down_proj",
],
bias="none",
)
model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: 83,886,080 || all params: 8,030,261,248 || trainable%: 1.044
# After training, merge adapter back into the base weights
merged = model.merge_and_unload()
merged.save_pretrained("./my-lora-merged")Vergleich LoRA vs. vollständiges Fine-Tuning
| Methode | Trainierbare Parameter | GPU-RAM (8B) | Qualität | Trainingsgeschwindigkeit |
|---|---|---|---|---|
| Full Fine-Tuning | 7B (100%) | ~80 GB | Beste | Langsamste |
| LoRA r=4 | ~21M (0.3%) | ~16 GB | Gut | Schnell |
| LoRA r=16 | ~83M (1.0%) | ~18 GB | Sehr gut | Schnell |
| LoRA r=64 | ~335M (4.1%) | ~24 GB | Nahe vollständigem FT | Moderat |
QLoRA: 4-Bit-Fine-Tuning
Selbst mit LoRA benötigt das in bfloat16 geladene Basismodell 16 GB für ein 8B-Modell — jenseits der Budgets von Consumer-GPUs. QLoRA (Dettmers et al. 2023) löst das, indem es das eingefrorene Basismodell auf 4-Bit-NormalFloat (NF4) quantisiert und die LoRA-Adapter in bfloat16-Präzision trainiert.
NF4-Quantisierung
NormalFloat4 ist informationstheoretisch optimal für normalverteilte Gewichte neuronaler Netze. Geringerer Fehler als int4 oder fp4.
Paged Optimizers
Optimiererzustände werden automatisch in den CPU-RAM ausgelagert, wenn der GPU-Speicher voll wird, und verhindern so OOM-Abstürze während des Trainings.
Doppelte Quantisierung
Quantisiert die Quantisierungskonstanten selbst und spart so zusätzliche ~0,5 Bit pro Parameter.
Hardware-Anforderungen
| Modell | FP16-VRAM | QLoRA-VRAM | Mindest-GPU |
|---|---|---|---|
| Llama 4 Scout (17B) | 34 GB | 10 GB | RTX 4090 24GB |
| Llama 4 Maverick (70B-class) | 140 GB | 40 GB | 2× A100 40GB |
| Llama 4 Behemoth (frontier) | 800+ GB | ~200 GB | 8× H100 80GB |
QLoRA mit bitsandbytes
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
import torch
bnb_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.bfloat16,
bnb_4bit_use_double_quant=True,
)
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Llama-4-Maverick-17B-128E-Instruct", # 2026: Llama 4 Maverick replaces Llama 3.1 70B
quantization_config=bnb_config,
device_map="auto",
)
# Now apply LoRA to the 4-bit model — same LoraConfig + get_peft_model as beforeAlignment: RLHF
Reinforcement Learning from Human Feedback (RLHF) war der Durchbruch, der GPT-3 in InstructGPT und schließlich in GPT-4o verwandelte. Es richtet das Modellverhalten an menschlichen Präferenzen aus — nicht nur das Befolgen von Anweisungen, sondern Ausgaben, die wirklich bevorzugt, sicher und hilfreich sind.
Die dreistufige Pipeline
SFT-Warmup
Das Basismodell auf einem kuratierten Satz hochwertiger, anweisungsbefolgender Demonstrationen feinabstimmen. Dies erzeugt die Ausgangspolicy, die RLHF verbessern wird.
Training des Reward-Modells
Einen Klassifikator auf paarweisen menschlichen Präferenzen trainieren: Welche von zwei Vervollständigungen (y_w, y_l) zum selben Prompt ist besser? Verlust: log σ(r(x, y_w) − r(x, y_l)).
PPO-Optimierung
Proximal Policy Optimization einsetzen, um den Wert des Reward-Modells zu maximieren und dabei nahe an der SFT-Policy zu bleiben (die KL-Divergenz-Strafe verhindert Reward Hacking).
RLHF-Pipeline-Diagramm
graph LR A[Base Model] -->|SFT on demos| B[SFT Model] B -->|Sample completions| C[Completion Pairs] C -->|Human labelers rank| D[Preference Dataset] D -->|Train| E[Reward Model] B -->|Initialize policy| F[Policy Model] F -->|Rollout + PPO| G[RL Optimization] E -->|Score rollouts| G G -->|Converged| H[RLHF Model]
Alignment: DPO & GRPO
DPO (Direct Preference Optimization) (Rafailov et al. 2023) eliminiert das Reward-Modell vollständig. Es zeigte mathematisch, dass die optimale RLHF-Policy direkt als Funktion der Präferenzdaten ausgedrückt werden kann, und reduziert so eine dreistufige Pipeline auf einen einzigen Fine-Tuning-Schritt.
Der DPO-Verlust optimiert die Policy direkt auf Präferenzpaaren (Prompt, chosen, rejected) und nutzt das SFT-Modell als eingefrorene Referenz. Kein PPO, kein Reward-Modell, keine separate Erhebung von RM-Trainingsdaten.
DPO mit dem DPOTrainer von trl
from trl import DPOConfig, DPOTrainer
from datasets import load_dataset
# Dataset needs: prompt, chosen, rejected columns
dataset = load_dataset("HuggingFaceH4/ultrafeedback_binarized", split="train_prefs")
dpo_config = DPOConfig(
output_dir="./dpo-output",
num_train_epochs=3,
per_device_train_batch_size=2,
gradient_accumulation_steps=8,
learning_rate=5e-7, # much smaller than SFT lr
beta=0.1, # KL penalty coefficient
bf16=True,
)
trainer = DPOTrainer(
model=sft_model, # your SFT fine-tuned model
ref_model=sft_ref_model, # frozen reference
args=dpo_config,
train_dataset=dataset,
processing_class=tokenizer,
)
trainer.train()GRPO: der Ansatz von DeepSeek
Group Relative Policy Optimization (GRPO) (verwendet in DeepSeek-R1) eliminiert das Referenzmodell. Für jeden Prompt werden mehrere Ausgaben gesampelt und der Gruppenmittelwert der Belohnung als Baseline für die Vorteilsschätzung genutzt. Das ist günstiger als PPO (kein Value-Modell) und besser für Reasoning-Aufgaben geeignet, bei denen sich die Korrektheit programmatisch verifizieren lässt.
Vergleich der Alignment-Methoden
| Methode | Rechenaufwand | Stabilität | Datenanforderungen | Hinweise |
|---|---|---|---|---|
| RLHF (PPO) | Sehr hoch | Niedrig | Menschliche Rankings | 4 Modelle im Speicher; Risiko von Reward Hacking |
| DPO | Niedrig | Hoch | Präferenzpaare | Kein Reward-Modell; einfachere Pipeline |
| GRPO | Mittel | Mittel | Rollout-Samples | Kein Referenzmodell; gut für Reasoning |
| SimPO | Niedrig | Hoch | Präferenzpaare | Kein Referenzmodell; durchschnittliche Log-Prob-Belohnung |
Modell-Distillation
Knowledge Distillation trainiert ein kleines „Schüler“-Modell, ein großes „Lehrer“-Modell nachzuahmen. Die zentrale Erkenntnis ist, dass der Lehrer weiche Wahrscheinlichkeitsverteilungen über das Vokabular (Logits) liefert statt One-Hot-Labels. Diese weichen Ziele kodieren weit mehr Information — sie verraten, welche Token semantisch der korrekten Antwort ähneln, und geben dem Schüler ein reichhaltigeres Trainingssignal.
Der kombinierte Verlust: L = α × L_CE(harte Labels) + (1 − α) × L_KL(Schüler-Logits ‖ Lehrer-Logits). Die Temperaturskalierung T > 1 glättet die Verteilung des Lehrers, verteilt die Wahrscheinlichkeitsmasse auf mehr Token und macht die weichen Labels noch informativer.
Distillation-Pipeline
graph TB A["Large Teacher (70B)"] -->|"Generate on training data"| B[Soft Logits] C[Input Prompt] --> A C --> D["Small Student (7B)"] B -->|KL Loss| D E[Ground Truth] -->|CE Loss| D D -->|Both losses| F[Distilled Student]
Antwort-Distillation
Der Schüler imitiert die Ausgaben des Lehrers — Lehrer-Vervollständigungen erzeugen, den Schüler trainieren, sie zu reproduzieren. Von DeepSeek-R1-Distill genutzt, um Reasoning-Traces zu übertragen.
Feature-Distillation
Zwischenrepräsentationen (Hidden States, Attention-Muster) zwischen Lehrer- und Schülerschichten abgleichen. Überträgt strukturelles Wissen, nicht nur Oberflächenausgaben.
Spekulatives Decoding
Ein kleines Entwurfsmodell schlägt Token-Sequenzen vor; das große Modell verifiziert sie parallel. Erreicht eine 2- bis 4-fache Inferenzbeschleunigung ohne Qualitätsverlust.
On-Policy-Distillation
Der Schüler erzeugt Token; der Lehrer bewertet sie. Vermeidet Exposure Bias (Verteilungsabweichung zwischen Training und Test), der bei Offline-Distillation häufig ist.
- Phi-3 / Phi-4 (Microsoft): aus GPT-4 auf kuratierten synthetischen Daten distilliert
- Gemma 2 (Google): aus Gemini Ultra distilliert; das 9B erreicht weit größere Modelle
- DeepSeek-R1-Distill: Reasoning-Traces aus R1 in 7B-/14B-Qwen2.5-Modelle distilliert
Modell-Merging
Modell-Merging kombiniert mehrere feinabgestimmte Checkpoints zu einem einzigen Modell ohne jegliches zusätzliche Training. Es ist günstig, schnell und überraschend wirksam, um spezialisierte Fähigkeiten — Code, Mathematik, Anweisungsbefolgung — in einem einzigen einsatzfähigen Modell zu vereinen. Gemergte Modelle erscheinen häufig an der Spitze des HuggingFace Open LLM Leaderboard.
Glatte Interpolation zwischen zwei Modell-Checkpoints im Gewichtsraum. Behandelt Gewichte als Punkte auf einer Hypersphäre. Am besten geeignet, um zwei eng verwandte Modelle zu mischen.
ΔW = W_FT − W_base für jedes feinabgestimmte Modell berechnen, dann die Deltas addieren. Erlaubt es, Fähigkeiten zu komponieren oder unerwünschte Verhaltensweisen zu subtrahieren.
Löst Konflikte zwischen Modellen: Parameter mit geringer Magnitude beschneiden, für jedes Gewicht das dominante Vorzeichen wählen, dann mergen. Bewältigt 3 oder mehr Modelle sauber.
Verwirft Fine-Tuning-Gewichts-Deltas zufällig (mit Wahrscheinlichkeit p) und skaliert die Überlebenden neu, um die Norm zu erhalten. Reduziert Interferenzen zwischen Modellen.
MergeKit-Konfiguration (TIES)
# mergekit config.yaml
models:
- model: meta-llama/Llama-4-Scout-17B-16E
parameters:
weight: 0.4
- model: ./llama-4-scout-code-finetuned
parameters:
weight: 0.3
- model: ./llama-4-scout-math-finetuned
parameters:
weight: 0.3
merge_method: ties
base_model: meta-llama/Llama-4-Scout-17B-16E
parameters:
density: 0.7
normalize: truemergekit-yaml config.yaml ./merged-model --cuda
Datensatz-Vorbereitung
Die Datensatzqualität ist der mit Abstand wichtigste Faktor für den Erfolg des Fine-Tunings — wichtiger als die Modellarchitektur, die Trainingsdauer oder die Wahl des Optimierers. Ein schlecht kuratierter Datensatz garantiert schlechte Ergebnisse, unabhängig von allem anderen.
Von Experten verfasste Beispiele; höchstes Signal-Rausch-Verhältnis. Für kritische Verhaltensweisen verwendet.
Synthetische Generierung mit Spitzenmodellen. Gut, um die Domänenabdeckung im großen Maßstab anzustoßen.
Seed-Anweisungen zu schwierigeren, vielfältigeren Varianten weiterentwickeln. Verwendet in WizardLM und OpenHermes.
Erfordert aggressive Qualitätsfilterung: Deduplizierung, Längenfilter, Perplexitätsfilter, Sicherheitsfilter.
ShareGPT-Datenformat
{
"conversations": [
{"from": "system", "value": "You are an expert in EU AI regulation."},
{"from": "human", "value": "Explain the risk categories in the EU AI Act."},
{"from": "gpt", "value": "The EU AI Act categorizes AI systems into four risk levels..."}
]
}Synthetische Datengenerierung im großen Maßstab
from openai import OpenAI # or use Mistral/Llama locally
client = OpenAI()
def generate_training_example(topic: str, difficulty: str) -> dict:
prompt = (
f"Generate a challenging {difficulty}-level question about {topic} "
"and a comprehensive expert answer."
)
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}],
temperature=0.8,
)
content = response.choices[0].message.content
# Parse and structure output (question/answer split)...
return {"instruction": topic, "response": content}Empfohlene Verteilung der Anweisungsvielfalt
Evaluierung & Iteration
Die Fine-Tuning-Schleife lautet: trainieren → auf einem Holdout evaluieren → Fehlermodi diagnostizieren → Daten verbessern → erneut trainieren. Eine gute Evaluierung ist es, die aus Versuch und Irrtum eine systematische Verbesserung macht.
MT-Bench
Allgemeine QualitätMulti-Turn-Benchmark mit 80 Fragen über 8 Kategorien (Schreiben, Mathematik, Coding usw.). GPT-4 bewertet jede Antwort mit 1–10.
AlpacaEval
AnweisungsbefolgungGewinnrate Ihres Modells gegenüber einem Referenzmodell (GPT-4o), bewertet durch GPT-4o. Schnelle automatisierte Bewertung der Anweisungsbefolgung.
IFEval
FormatkonformitätGenauigkeit der Anweisungsbefolgung bei verifizierbaren Vorgaben (z. B. „in weniger als 100 Wörtern antworten“). Strikte und lockere Bewertungsvarianten.
HumanEval / MBPP
CodegenerierungCodegenerierungs-Benchmarks. Pass@k-Metrik: Anteil der in k Versuchen gelösten Probleme. Ausführbare Testfälle als Ground Truth.
Das LLM-as-Judge-Muster
import json
from openai import OpenAI
client = OpenAI()
def evaluate_response(question: str, answer: str, judge_model: str = "gpt-4o") -> dict:
prompt = f"""Rate the following AI assistant response on a scale of 1-10.
Question: {question}
Answer: {answer}
Evaluate: helpfulness (1-10), factuality (1-10), safety (1-10).
Return JSON: {{"helpfulness": N, "factuality": N, "safety": N, "rationale": "..."}}"""
response = client.chat.completions.create(
model=judge_model,
messages=[{"role": "user", "content": prompt}],
response_format={"type": "json_object"},
)
return json.loads(response.choices[0].message.content)- Längen-Bias: LLM-Judges bevorzugen tendenziell längere Antworten, unabhängig von der Qualität. Kalibrieren Sie Ihren Judge.
- Sycophancy: Modelle bewerten ihre eigenen Ausgaben höher. Verwenden Sie ein anderes Modell als Judge oder eine menschliche Validierung.
- Kontamination: Benchmark-Daten im Trainingsset überhöhen die Werte. Prüfen Sie stets die Überlappung.
- Einzelmetrik-Fallen: Das Optimieren einer Metrik verschlechtert oft andere. Verfolgen Sie eine ausgewogene Scorecard.
Vorlage zur Experiment-Nachverfolgung
| Run | Basismodell | Methode | Datensatz | MT-Bench | AlpacaEval Win% | Hinweise |
|---|---|---|---|---|---|---|
| v1 | Llama-4-Scout | SFT | UltraChat 200K | 7.4 | 70% | Baseline |
| v2 | Llama-4-Scout | SFT+DPO | + UltraFeedback | 8.0 | 76% | +DPO verbesserte die Sicherheit |
| v3 | Llama-4-Scout | SFT+DPO (r=16) | + UltraFeedback | 8.1 | 77% | LoRA r=16 vs. vollständiges FT |
Wann Fine-Tuning vs. RAG vs. Prompt-Engineering
Fine-Tuning ist mächtig, aber nicht immer das richtige Werkzeug. Die Entscheidung hängt davon ab, was Sie ändern wollen: Wissen, Verhalten, Format oder Präferenzen. Die falsche Wahl kostet Wochen an Engineering und Rechenleistung.
| Szenario | Beste Vorgehensweise | Warum |
|---|---|---|
| Antworten in Unternehmensdokumenten verankern | RAG | Wissen kann sich ändern; FT lässt sich nicht leicht aktualisieren |
| Konsistenten Ton/Stil wünschen | SFT | Ton ist Format, nicht Wissen |
| Verwendung domänenspezifischer Terminologie | SFT + wenig Daten | Standardverhalten kostengünstig ändern |
| Bestimmte Ausgabeformate handhaben | SFT | Schema-Einhaltung ist eine erlernte Fähigkeit |
| Schädliche Ausgaben reduzieren | DPO / RLHF | Präferenz-Alignment zielt direkt darauf ab |
| Reasoning-Fähigkeiten benötigen | GRPO oder aus R1 distillieren | Reasoning-Muster sind trainierbar |
| Neues Faktenwissen hinzufügen | RAG (nicht FT) | FT memoriert, kann keine Quellen zitieren |
| API-Kosten im großen Maßstab senken | Kleines Modell feinabstimmen | Qualität großer Modelle bei enger Aufgabe erreichen |
| Prototyp / schnelles Experiment | Zuerst Prompt-Engineering | Keine Trainingskosten; Konzept zuerst validieren |
Die LLM-Treppe
Beginnen Sie ganz unten. Steigen Sie nur auf, wenn die aktuelle Stufe wirklich unzureichend ist — jede Stufe fügt Kosten, Komplexität und Latenz hinzu.
Fine-Tuning, wenn
- Konsistenter Ton/Format im großen Maßstab
- Domänenjargon muss Standard sein
- Bestimmtes Ausgabeschema erforderlich
- API-Kosten bei enger Aufgabe senken
- Präferenz-/Sicherheits-Alignment nötig
RAG verwenden, wenn
- Wissen sich häufig ändert
- Antworten Zitate/Quellen benötigen
- Private/proprietäre Wissensbasis
- Großer Dokumentenkorpus (>1M Token)
- Aktualisierung ohne erneutes Training nötig
Fine-Tuning vermeiden, wenn
- Neues Faktenwissen hinzufügen (RAG verwenden)
- Schnelle Prototyp- oder PoC-Phase
- Sehr kleiner Datensatz (<100 Beispiele)
- Kein GPU-Budget verfügbar
- Prompting erreicht das Ziel bereits
Bauen Sie Ihr individuelles KI-Modell
Ob Sie einen domänenspezifischen Assistenten, präferenzausgerichtete Modelle oder distillierte Produktionsdeployments benötigen — unser Team hat sie gebaut und ausgeliefert. Sprechen wir über Ihren Anwendungsfall.