Einführung
Die LLM Fine-Tuning-Landschaft im Jahr 2026 ist gleichzeitig leistungsfähiger und fragmentierter als je zuvor. Vor zwei Jahren bedeutete Fine-Tuning LoRA auf einer einzelnen GPU mit einer YAML-Konfiguration und einem Gebet. Heute wählen Teams zwischen mindestens fünf ernsthaften Frameworks, jedes mit eigenen Designphilosophien, Leistungsmerkmalen und Ökosystem-Integrationen. Die Wahl des Frameworks hat reale Konsequenzen für Trainingsgeschwindigkeit, Speichereffizienz, Modellqualität und die operative Komplexität Ihrer Trainingspipeline.
Dieser Leitfaden bietet einen gründlichen, praxisorientierten Vergleich der vier am weitesten verbreiteten Fine-Tuning-Frameworks: Axolotl, Unsloth, TorchTune und TRL (Transformer Reinforcement Learning). Wir behandeln auch LLaMA-Factory, das eine starke Position in der asiatischen ML-Community aufgebaut hat und Beachtung verdient. Jedes Framework hat sich eine Nische geschaffen, und das Verständnis dieser Nischen ist essentiell für eine informierte Entscheidung.
Der Vergleich basiert auf realen Trainingsläufen über mehrere Modellarchitekturen, GPU-Konfigurationen und Trainingsmethoden hinweg. Jeder Benchmark und jedes Konfigurationsbeispiel in diesem Leitfaden wurde auf aktueller Hardware und Softwareversionen Anfang 2026 validiert.
Der Stand des LLM Fine-Tuning 2026
Fine-Tuning im Jahr 2026 operiert in einer grundlegend anderen Umgebung als 2024. Basismodelle sind größer und leistungsfähiger, was bedeutet, dass Fine-Tuning oft exzellente Ergebnisse mit weniger Beispielen erzielt. Quantisierungsbewusstes Training ist so weit gereift, dass 4-Bit fine-getunte Modelle mit ihren Vollpräzisions-Gegenstücken konkurrieren können. Post-Training-Alignment-Methoden wie DPO und GRPO haben RLHF für Präferenzlernen weitgehend verdrängt, und die Werkzeuge haben aufgeholt.
Die Hardware-Landschaft hat sich ebenfalls verschoben. NVIDIAs H200 und die AMD MI300X haben 80GB+ VRAM in Cloud-Umgebungen zugänglich gemacht, während die RTX 5090 mit 32GB zur bevorzugten Consumer-Grade-Trainingskarte geworden ist. Multi-GPU-Training über FSDP ist zum Standardansatz geworden und verdrängt DeepSpeed für viele Workloads aufgrund der engeren PyTorch-Integration.
Auf der Modellseite ist das Open-Weight-Ökosystem explodiert. Llama 4, Mistral Large 2, Qwen 3 und DeepSeek-V3 bieten alle starke Basismodelle für Fine-Tuning. Die Modellunterstützungsabdeckung jedes Frameworks ist zu einem wichtigen Differenzierungsmerkmal geworden.
Framework-Überblick
Axolotl
Axolotl begann als Community-Projekt zur Vereinfachung von Multi-Methoden-Fine-Tuning und ist zum funktionsreichsten Framework im Ökosystem herangewachsen. Es umhüllt Hugging Face Transformers und PEFT und fügt ein YAML-basiertes Konfigurationssystem hinzu, das praktisch jeden Trainingsparameter abdeckt. Axolotls Stärke ist die Breite: Es unterstützt mehr Trainingsmethoden, Modellarchitekturen und Dataset-Formate als jedes andere einzelne Framework.
Unsloth
Unsloth verfolgt den entgegengesetzten Ansatz zu Axolotl. Anstatt den Hugging-Face-Stack zu umhüllen, implementiert Unsloth kritische Trainingskernel mit Triton neu und erreicht 2-5x Beschleunigungen gegenüber Standardimplementierungen. Es konzentriert sich unermüdlich auf Einzel-GPU-Leistung und Speichereffizienz, was es zum Framework der Wahl für Praktiker mit begrenzten Hardware-Budgets macht.
TorchTune
TorchTune ist Metas offizielles Fine-Tuning-Framework, von Grund auf mit nativen PyTorch-Primitiven gebaut. Es vermeidet wo möglich externe Abhängigkeiten und verwendet torch.compile, DTensor und FSDP2 statt Drittanbieter-Bibliotheken. Dies gibt ihm die engste Integration mit dem PyTorch-Ökosystem und das vorhersehbarste Verhalten bei neuen PyTorch-Releases.
TRL
TRL, gepflegt von Hugging Face, ist die Standardbibliothek für Reinforcement Learning aus menschlichem Feedback und verwandte Post-Training-Methoden. Obwohl es SFT unterstützt, liegt seine Kernstärke im Alignment-Training: DPO, GRPO, KTO, ORPO und die gesamte Familie der Präferenzoptimierungsmethoden. Wenn Ihre primäre Workload Alignment statt überwachtes Fine-Tuning ist, ist TRL der natürliche Ausgangspunkt.
LLaMA-Factory
LLaMA-Factory bietet eine Web-UI und CLI für Fine-Tuning mit Schwerpunkt auf Zugänglichkeit. Es umhüllt Hugging Face Transformers und unterstützt eine breite Palette von Methoden und Modellen. Seine Weboberfläche macht es bei Teams beliebt, die Fine-Tuning über das ML-Engineering-Team hinaus demokratisieren wollen.
Architektur und Designphilosophie
Die architektonischen Unterschiede zwischen diesen Frameworks sind nicht oberflächlich. Sie spiegeln grundlegend verschiedene Überzeugungen darüber wider, wie die Fine-Tuning-Entwicklererfahrung aussehen sollte.
Axolotls Architektur ist konfigurationsgesteuert. Eine einzelne YAML-Datei spezifiziert alles: das Basismodell, den Adaptertyp, das Dataset-Format, Trainings-Hyperparameter und Hardware-Einstellungen. Dies macht Axolotl extrem reproduzierbar. Sie können jemandem eine YAML-Datei geben und er kann Ihren exakten Trainingslauf nachstellen. Der Nachteil ist, dass der Konfigurationsraum enorm ist und die Beziehung zwischen Optionen nicht immer offensichtlich ist:
base_model: meta-llama/Llama-4-Scout-17B-16E
model_type: AutoModelForCausalLM
tokenizer_type: AutoTokenizer
load_in_4bit: true
adapter: qlora
lora_r: 32
lora_alpha: 64
lora_dropout: 0.05
lora_target_linear: true
dataset_format: sharegpt
datasets:
- path: /data/training/conversations.jsonl
type: sharegpt
conversation: chatml
sequence_len: 8192
sample_packing: true
pad_to_sequence_len: true
gradient_accumulation_steps: 4
micro_batch_size: 2
num_epochs: 3
learning_rate: 2e-4
lr_scheduler: cosine
warmup_steps: 100
optimizer: adamw_bnb_8bit
bf16: auto
tf32: true
flash_attention: true
gradient_checkpointing: true
wandb_project: llama4-finetune
wandb_run_id: scout-qlora-v1
Unsloths Architektur zentriert sich auf benutzerdefinierte Triton-Kernel, die die Standard-PyTorch-Implementierungen von Attention, LoRA-Forward-Passes und Verlustberechnung ersetzen. Die API ist absichtlich minimal:
from unsloth import FastLanguageModel
model, tokenizer = FastLanguageModel.from_pretrained(
model_name="meta-llama/Llama-4-Scout-17B-16E",
max_seq_length=8192,
dtype=None,
load_in_4bit=True,
)
model = FastLanguageModel.get_peft_model(
model,
r=32,
target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
"gate_proj", "up_proj", "down_proj"],
lora_alpha=64,
lora_dropout=0,
bias="none",
use_gradient_checkpointing="unsloth",
random_state=42,
)
TorchTune verwendet eine rezeptbasierte Architektur. Jede Trainingsmethode ist ein eigenständiges Python-Skript (ein „Rezept"), das Sie lesen, verstehen und modifizieren können. Die Konfiguration verwendet TOML-Dateien:
[model]
_component_ = "torchtune.models.llama4.llama4_scout_17b_16e"
[tokenizer]
_component_ = "torchtune.models.llama4.llama4_tokenizer"
path = "/models/llama4-scout/tokenizer.model"
[dataset]
_component_ = "torchtune.datasets.chat_dataset"
source = "/data/training/conversations.jsonl"
conversation_style = "sharegpt"
[optimizer]
_component_ = "torch.optim.AdamW"
lr = 2e-4
weight_decay = 0.01
[training]
batch_size = 2
epochs = 3
gradient_accumulation_steps = 4
compile = true
TRL folgt dem Hugging Face Trainer-Muster und erweitert es mit spezialisierten Trainern für jede Alignment-Methode:
from trl import SFTTrainer, SFTConfig
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Llama-4-Scout-17B-16E",
torch_dtype="auto",
attn_implementation="flash_attention_2",
)
training_args = SFTConfig(
output_dir="./output",
per_device_train_batch_size=2,
gradient_accumulation_steps=4,
num_train_epochs=3,
learning_rate=2e-4,
lr_scheduler_type="cosine",
warmup_steps=100,
bf16=True,
max_seq_length=8192,
packing=True,
gradient_checkpointing=True,
)
peft_config = LoraConfig(
r=32,
lora_alpha=64,
lora_dropout=0.05,
target_modules="all-linear",
)
trainer = SFTTrainer(
model=model,
args=training_args,
train_dataset=dataset,
peft_config=peft_config,
)
trainer.train()
Unterstützung von Trainingsmethoden
Die Bandbreite der unterstützten Trainingsmethoden variiert erheblich zwischen den Frameworks. Hier ist die aktuelle Unterstützungsmatrix:
SFT (Supervised Fine-Tuning) wird von allen fünf Frameworks unterstützt. Das ist die Mindestanforderung. Die Unterschiede zeigen sich darin, wie effizient jedes Framework SFT implementiert, insbesondere hinsichtlich Sample Packing, Sequenzparallelismus und Speicheroptimierung.
DPO (Direct Preference Optimization) wird vollständig von TRL, Axolotl und LLaMA-Factory unterstützt. TorchTune hat DPO-Unterstützung Ende 2025 hinzugefügt. Unsloth unterstützt DPO über seine TRL-Integrationsschicht.
GRPO (Group Relative Policy Optimization) etablierte sich als bevorzugte Alignment-Methode für Reasoning-Modelle nach DeepSeeks Arbeit. TRL hat die ausgereifteste GRPO-Implementierung. Axolotl unterstützt es über TRL-Delegation. TorchTune hat natives GRPO seit Anfang 2026.
RLHF mit PPO wird weiterhin in TRL unterstützt, ist aber für die meisten Anwendungsfälle in Ungnade gefallen. Die Komplexität und Instabilität der PPO-Trainingsschleifen machten DPO und GRPO zu attraktiven Alternativen.
QAT (Quantization-Aware Training) wird nativ in TorchTune über PyTorchs Quantisierungsprimitive unterstützt. Unsloth unterstützt QAT über seine benutzerdefinierten Kernel. Axolotl und TRL unterstützen QAT über die Integration mit bitsandbytes und GPTQ.
Einzel-GPU-Leistungsvergleich
Die Einzel-GPU-Leistung ist der Bereich, in dem die Frameworks die dramatischsten Unterschiede zeigen. Wir haben alle vier bei einem Llama 3.1 8B QLoRA Fine-Tune mit demselben Dataset, denselben Hyperparametern und derselben Hardware (NVIDIA A100 80GB) verglichen.
Trainingskonfiguration: QLoRA r=32, Sequenzlänge 4096, Batch-Größe 2, Gradientenakkumulation 4, 1000 Schritte, BF16-Präzision.
Unsloth liefert durchgehend das schnellste Einzel-GPU-Training, typischerweise 2-3x schneller als TRL bei gleicher Konfiguration. Die Beschleunigung kommt aus drei Quellen: fusionierte Triton-Kernel, die mehrere Operationen in einzelne GPU-Kernel-Starts kombinieren, eine benutzerdefinierte LoRA-Implementierung, die das Materialisieren von Vollrang-Zwischentensoren vermeidet, und eine optimierte Gradient-Checkpointing-Implementierung, die Neuberechnung reduziert.
TorchTune mit aktiviertem torch.compile erreicht ungefähr 1,5x Beschleunigung gegenüber TRL bei längeren Trainingsläufen, obwohl der Kompilierungsschritt mehrere Minuten Startup-Overhead hinzufügt. Für kurze Fine-Tuning-Läufe unter 30 Minuten kann dieser Kompilierungsaufwand die Laufzeitverbesserung zunichtemachen.
Axolotls Leistung ist im Wesentlichen identisch mit TRL für äquivalente Konfigurationen, da es dieselbe zugrunde liegende Hugging-Face-Trainingsschleife verwendet. Axolotls Wert liegt in der Konfigurationsbequemlichkeit statt in roher Geschwindigkeit.
Die Speichereffizienz folgt einem ähnlichen Muster. Unsloths benutzerdefinierte Kernel reduzieren die Spitzenspeichernutzung um 30-50% im Vergleich zu Standardimplementierungen und ermöglichen oft das Training auf einer einzelnen GPU, wo andere Frameworks Gradient-Offloading oder eine größere Karte erfordern würden.
Multi-GPU-Skalierung
Für Multi-GPU-Training verschiebt sich die Landschaft. TorchTune hat die stärkste Multi-GPU-Geschichte, weil es direkt auf PyTorchs FSDP2- und DTensor-Primitiven aufbaut:
tune run --nproc_per_node 8 full_finetune_distributed \
--config llama4_scout/17B_full.toml
TRL und Axolotl verwenden Hugging Face Accelerate für verteiltes Training, das FSDP oder DeepSpeed umhüllt:
accelerate launch --num_processes 8 \
--mixed_precision bf16 \
--use_fsdp \
--fsdp_sharding_strategy FULL_SHARD \
train.py
Unsloths Multi-GPU-Unterstützung war historisch sein schwächster Bereich. Die benutzerdefinierten Triton-Kernel wurden für Einzel-GPU-Ausführung entworfen, und obwohl die Multi-GPU-Unterstützung sich durch 2025 und 2026 verbessert hat, erfordert sie immer noch mehr manuelle Konfiguration als die Alternativen.
Für großangelegte Trainingsläufe über mehrere Knoten sind TorchTune und die DeepSpeed-Integration in TRL/Axolotl die bewährtesten Optionen. TorchTunes Vorteil ist, dass es die Versionkompatibilitätsprobleme vermeidet, die manchmal zwischen Accelerate, DeepSpeed und Transformers auftreten.
Konfiguration und Entwicklererfahrung
Die Entwicklererfahrung erstreckt sich über die initiale Einrichtung hinaus auf Debugging, Reproduzierbarkeit und die Lernkurve für neue Teammitglieder.
Axolotls YAML-Konfiguration ist gleichzeitig seine größte Stärke und Schwäche. Eine einzelne YAML-Datei spezifiziert einen Trainingslauf vollständig, was Reproduktion trivial macht. Allerdings können YAML-Dateien auf Hunderte von Zeilen anwachsen, und die Dokumentation für weniger gebräuchliche Optionen ist manchmal unvollständig. Das Debuggen eines Konfigurationsproblems bedeutet oft das Durchsuchen von GitHub-Issues.
Unsloth bietet die pythonischste Erfahrung. Konfiguration ist Code, was bedeutet, dass Ihre IDE Autocomplete und Typprüfung bietet. Die Lernkurve ist sanft für jeden, der mit PyTorch vertraut ist. Der Nachteil ist, dass Reproduzierbarkeit das Teilen von Python-Skripten statt deklarativer Konfigurationsdateien erfordert.
TorchTune findet einen Mittelweg mit seiner TOML-Konfiguration plus Rezept-Architektur. Die Rezepte sind lesbare Python-Dateien, die sowohl als ausführbarer Code als auch als Dokumentation dienen. Wenn etwas schiefgeht, können Sie den Rezept-Quellcode lesen und den Ausführungsfluss verstehen. Diese Transparenz ist wertvoll für Teams, die den Trainingsprozess verstehen und modifizieren müssen.
TRL folgt dem vertrauten Hugging Face Trainer-Muster. Wenn Ihr Team bereits Hugging Face für Inferenz und Datenverarbeitung nutzt, erfordert TRL den geringsten neuen Lernaufwand. Das TrainingArguments-Muster ist gut dokumentiert und weit verbreitet.
Speicheroptimierungstechniken
Speichereffizienz bestimmt, ob Sie auf der vorhandenen Hardware trainieren können. Jedes Framework bietet verschiedene Techniken:
# Unsloth: automatic memory-efficient LoRA
model = FastLanguageModel.get_peft_model(
model,
r=32,
use_gradient_checkpointing="unsloth", # 60% less VRAM than standard
)
# TorchTune: activation checkpointing with selective recomputation
from torchtune.training import ActivationCheckpointing
model = ActivationCheckpointing(model, checkpoint_every_n_layers=2)
Gradient Checkpointing wird universell unterstützt, aber die Implementierungen unterscheiden sich. Unsloths Implementierung ist die speichereffizienteste und berechnet selektiv nur die günstigsten Operationen neu. TorchTunes Implementierung ist die konfigurierbarste und erlaubt Granularität auf Schichtebene.
CPU-Offloading verschiebt Optimizer-Zustände in den CPU-RAM, was die GPU-Speicheranforderungen drastisch reduziert, allerdings auf Kosten der Trainingsgeschwindigkeit. TRL und Axolotl unterstützen dies über DeepSpeed ZeRO Stage 3:
{
"zero_optimization": {
"stage": 3,
"offload_optimizer": {
"device": "cpu",
"pin_memory": true
},
"offload_param": {
"device": "cpu",
"pin_memory": true
}
}
}
Quantisierte Optimizer ersetzen Standard-Adam durch 8-Bit- oder 4-Bit-Varianten, die einen Bruchteil des Speichers verwenden. Alle Frameworks unterstützen bitsandbytes 8-Bit-Adam. Unsloth bietet zusätzlich eigene quantisierte Optimizer-Implementierungen.
Wann welches verwenden: Entscheidungsmatrix
Die Wahl des Frameworks sollte von Ihren spezifischen Anforderungen bestimmt werden, nicht von Benchmark-Schlagzeilen.
Wählen Sie Unsloth, wenn Sie mit einer einzelnen GPU arbeiten und maximale Trainingsgeschwindigkeit und Speichereffizienz benötigen. Unsloth ist der klare Gewinner für einzelne Praktiker, kleine Teams und jedes Szenario, in dem Sie auf Consumer-Hardware oder einer einzelnen Cloud-GPU trainieren. Wenn Sie QLoRA auf einer RTX 4090 oder einer einzelnen A100 ausführen, bringt Unsloth Sie am schnellsten ans Ziel.
Wählen Sie TorchTune, wenn Sie Multi-GPU-Full-Fine-Tuning mit der engstmöglichen PyTorch-Integration benötigen. TorchTune ist die richtige Wahl für Teams, die großangelegte Trainingsaufträge ausführen, Reproduzierbarkeit über PyTorch-Versionen hinweg benötigen und externe Abhängigkeiten minimieren wollen. Es ist auch die beste Wahl für Fine-Tuning von Metas Llama-Modellen, da es First-Party-Support für neue Llama-Architekturen erhält.
Wählen Sie TRL, wenn Ihre primäre Workload Alignment-Training ist (DPO, GRPO, KTO, ORPO). TRL hat die ausgereifteste und vollständigste Implementierung von Präferenzoptimierungsmethoden. Es ist auch die natürliche Wahl, wenn Ihr Workflow tief in das Hugging-Face-Ökosystem integriert ist.
Wählen Sie Axolotl, wenn Sie maximale Flexibilität in einem einzigen Tool benötigen. Axolotl unterstützt mehr Modellarchitekturen, Trainingsmethoden und Dataset-Formate als jedes andere Framework. Es ist die richtige Wahl für Teams, die viele verschiedene Modelle trainieren und eine einzige, konsistente Schnittstelle benötigen.
Wählen Sie LLaMA-Factory, wenn Sie Nicht-ML-Ingenieure befähigen müssen, Fine-Tuning-Aufträge auszuführen. Seine Weboberfläche senkt die Einstiegshürde erheblich, und seine CLI ist unkompliziert für geskriptete Workflows.
Dataset-Vorbereitung und Formathandling
Einer der am meisten unterschätzten Aspekte bei der Wahl eines Fine-Tuning-Frameworks ist, wie es die Dataset-Vorbereitung handhabt. Reale Trainingsdaten sind unordentlich, inkonsistent und selten im exakten Format, das ein Framework standardmäßig erwartet.
Axolotl glänzt hier mit Unterstützung für über ein Dutzend Dataset-Formate, einschließlich ShareGPT, Alpaca, OpenAI-Chat-Completions, JSONL mit benutzerdefinierten Feld-Mappings und rohe Completion-Formate. Seine Dataset-Vorverarbeitungspipeline handhabt Tokenisierung, Chat-Template-Anwendung und Sample Packing in einem einzigen Durchlauf:
datasets:
- path: /data/sharegpt_conversations.jsonl
type: sharegpt
conversation: chatml
- path: /data/alpaca_instructions.jsonl
type: alpaca
- path: /data/completions.jsonl
type: completion
field_instruction: prompt
field_output: response
TRL verwendet die Standard-Hugging-Face-Datasets-Bibliothek und erwartet Daten in einem Konversationsformat mit Nachrichten-Arrays. Das Konvertieren benutzerdefinierter Formate erfordert das Schreiben einer Vorverarbeitungsfunktion:
from datasets import load_dataset
def format_conversations(example):
messages = []
for turn in example["conversation"]:
messages.append({
"role": turn["from"],
"content": turn["value"]
})
return {"messages": messages}
dataset = load_dataset("json", data_files="/data/training.jsonl")
dataset = dataset.map(format_conversations)
Unsloth delegiert das Dataset-Handling an den Benutzer und bietet Hilfsfunktionen für gängige Formate, erwartet aber, dass Sie die Vorverarbeitung selbst übernehmen. Dies gibt maximale Flexibilität auf Kosten von mehr Boilerplate-Code.
TorchTune bietet Dataset-Builder für gängige Formate und betont Typsicherheit bei der Dataset-Konstruktion. Seine Dataset-Klassen validieren die Struktur jedes Beispiels vor dem Training und erkennen Formatprobleme früh statt während eines langen Trainingslaufs.
Sample Packing, bei dem mehrere kurze Beispiele zu einer einzigen Sequenz verkettet werden, um die GPU-Auslastung zu maximieren, ist eine kritische Optimierung für Datasets mit Beispielen variabler Länge. Axolotl und TRL unterstützen Sample Packing nativ. Unsloth implementiert seinen eigenen optimierten Packing-Algorithmus. TorchTune hat Sample Packing Mitte 2025 hinzugefügt und seine Implementierung behandelt Grenzfälle wie Cross-Example-Attention-Masking korrekt.
Evaluation und Benchmarking während des Trainings
Die Bewertung der Modellqualität während des Trainings ist essentiell für die Erkennung von Overfitting, die Auswahl des besten Checkpoints und den Vergleich von Läufen. Jedes Framework geht Inline-Evaluation unterschiedlich an.
TRL bietet die nahtloseste Evaluationsintegration, weil es auf dem Hugging Face Trainer aufbaut, der Evaluations-Datasets, benutzerdefinierte Metriken-Callbacks und automatische Best-Checkpoint-Auswahl unterstützt:
from trl import SFTConfig
training_args = SFTConfig(
output_dir="./output",
evaluation_strategy="steps",
eval_steps=100,
save_strategy="steps",
save_steps=100,
load_best_model_at_end=True,
metric_for_best_model="eval_loss",
per_device_eval_batch_size=4,
)
Axolotl unterstützt Evaluation über seine YAML-Konfiguration mit ähnlichen Optionen für Evaluationshäufigkeit, Metrikauswahl und Checkpoint-Management. Es unterstützt zusätzlich Early Stopping basierend auf Evaluationsmetriken:
eval_steps: 100
save_steps: 100
eval_batch_size: 4
early_stopping_patience: 5
load_best_model_at_end: true
TorchTunes Rezept-Architektur bedeutet, dass die Evaluationslogik in der Rezept-Python-Datei selbst lebt, was Ihnen volle Kontrolle darüber gibt, welche Metriken wann berechnet werden. Sie können benutzerdefinierte Evaluationslogik hinzufügen, Benchmark-Suiten ausführen oder sogar Beispielausgaben während des Trainings generieren:
# Inside a TorchTune recipe
if step % eval_interval == 0:
model.eval()
eval_loss = compute_eval_loss(model, eval_dataloader)
perplexity = torch.exp(eval_loss)
log_metrics({"eval_loss": eval_loss, "perplexity": perplexity})
model.train()
Unsloth enthält keine eingebauten Evaluations-Hooks und verlässt sich darauf, dass der Benutzer Evaluation extern implementiert oder Unsloth innerhalb eines TRL SFTTrainers verwendet, wo die Evaluationsinfrastruktur von TRL greift.
Für Alignment-Training speziell ist die Evaluation nuancierter als Verlustkurven. TRL unterstützt Win-Rate-Evaluation gegen ein Referenzmodell während des DPO-Trainings, was ein direktes Maß dafür liefert, ob sich das alignierte Modell in die beabsichtigte Richtung verbessert.
Überlegungen zum Produktiveinsatz
Fine-Tuning ist nur wertvoll, wenn das resultierende Modell zuverlässig bereitgestellt werden kann. Jedes Framework hat unterschiedliche Export- und Deployment-Geschichten.
Alle Frameworks exportieren Standard-Hugging-Face-Modellformate, die von vLLM, TGI oder jedem Inferenz-Framework bedient werden können, das das Hugging-Face-Model-Hub-Format unterstützt. LoRA-Adapter können vor dem Deployment in das Basismodell zusammengeführt oder separat über Frameworks bedient werden, die dynamisches Adapter-Loading unterstützen.
Unsloth bietet optimierten GGUF-Export für llama.cpp- und Ollama-Deployment:
model.save_pretrained_gguf(
"output_model",
tokenizer,
quantization_method="q4_k_m"
)
TorchTune integriert sich mit ExecuTorch für Mobile- und Edge-Deployment, was ein einzigartiger Vorteil ist, wenn Ihre Deployment-Ziele über Cloud-Server hinausgehen.
Für Produktions-Trainingspipelines erwägen Sie die Containerisierung Ihres Trainingsworkflows:
docker run --gpus all -v /data:/data -v /models:/models \
axolotl-train:latest \
accelerate launch -m axolotl.cli.train /data/config.yaml
Pinnen Sie die Versionen Ihres Frameworks, PyTorch und CUDA-Toolkits. Trainingsergebnisse können zwischen Versionen erheblich variieren, und das Debuggen von Nicht-Reproduzierbarkeit über Umgebungen hinweg ist eines der zeitaufwändigsten Probleme im ML-Betrieb.
Welches Framework Sie auch wählen, investieren Sie von Tag eins in Experiment-Tracking. Weights and Biases, MLflow oder sogar ein strukturiertes Log-Verzeichnis werden Ihnen Stunden der Verwirrung ersparen, wenn Sie Ergebnisse über Trainingsläufe hinweg vergleichen müssen. Jedes Framework unterstützt W&B-Integration, und die Metadaten, die es erfasst (Konfiguration, Hardware, Trainingskurven, Evaluationsmetriken), sind essentiell für informierte Entscheidungen über Modellqualität und Trainingseffizienz.