Ludwig: deklaratives Deep Learning per YAML, von LoRA bis Tabellenklassifikation

Was Ludwig ersetzt: Python-Boilerplate durch eine YAML-Datei

Ein Trainingsskript für ein Transformer-Modell besteht üblicherweise aus Tokenizer-Aufbau, Datenkollation, Optimierer, Scheduler, Checkpointing und Evaluationsschleife. Ludwig verlagert diese Teile in eine Konfigurationsdatei. Das README beschreibt das Projekt als deklaratives Framework, das Trainieren, Fine-Tuning und Deployment über YAML und ohne Boilerplate-Python erlaubt. Der Adressat ist damit nicht das Forschungsteam, das eine neue Architektur publizieren will, sondern die Person, die ein vorhandenes Modell auf eigene Daten anpassen muss: Tabellenklassifikation, Textklassifikation, Instruction-Tuning. Die Konfiguration benennt Ein- und Ausgabemerkmale, das Basismodell und den Trainertyp. Wer schon einmal ein Fine-Tuning-Skript geschrieben hat, erkennt die Struktur wieder: input_features, output_features, trainer, backend. Der Unterschied liegt darin, dass diese Struktur validiert wird, statt in imperativem Code zu stehen. Das README nennt Pydantic 2 als Teil des Stacks, was zu diesem Bild passt: Die YAML wird gegen ein Schema geprüft, bevor Trainingscode läuft. Für Teams, die viele ähnliche Modelle mit leicht variierenden Daten trainieren, ist das der eigentliche Gewinn, nicht die eingesparten Zeilen an sich.

Der Mechanismus: Konfiguration, Basismodell, Adapter

Das README zeigt das LLM-Fine-Tuning als Beispiel: model_type: llm, base_model: meta-llama/Llama-3.1-8B, adapter mit type: lora, trainer mit type: finetune und epochs: 3, dazu input_features und output_features vom Typ text. Das Basismodell kommt aus dem Hugging-Face-Hub, was der Grund für den Hinweis auf HUGGING_FACE_HUB_TOKEN ist. Der Trainertyp bestimmt das Verfahren: finetune für überwachtes Fine-Tuning, dpo, kto, orpo oder grpo für Alignment-Verfahren. Der Adaptertyp bestimmt, welche Parameter trainiert werden: lora, dora, vera, oder lora mit init_weights: pissa. Quantisierung ist ein eigener Block: quantization.bits: 4 für bitsandbytes-QLoRA, quantization.backend: torchao für die PyTorch-native Variante mit Quantization-Aware Training. Der Datenfluss ist damit festgelegt: Datensatz und Prompt-Template erzeugen Batches, das Basismodell wird je nach Adapter- und Quantisierungskonfiguration eingefroren oder teilweise trainiert, der Trainer schreibt Checkpoints. Was Ludwig nicht zeigt, ist der Speicherbedarf dieses Pfads. Das README nennt batch_size: 1 mit gradient_accumulation_steps: 16, was auf eine Konfiguration für begrenzten VRAM hindeutet, aber keine Angabe dazu, welche Karte 4-Bit-QLoRA für ein 8B-Modell tatsächlich trägt. Diese Zahl muss man selbst ermitteln.

Installation und erster Lauf: die tatsächlichen Befehle

Die Installation ist in drei Varianten dokumentiert: pip install ludwig für den Kern, pip install ludwig[full] für alle optionalen Abhängigkeiten, pip install ludwig[llm] für ausschließlich LLM-Fine-Tuning. Das README verlangt Python 3.12 oder neuer und verweist für die vollständige Abhängigkeitsmatrix auf CONTRIBUTING.md. Ein Trainingslauf sieht so aus: ludwig train --config model.yaml --dataset my_data.csv. Für das LLM-Beispiel wird der Datensatz über ein Schema-Präfix geladen: ludwig train --config model.yaml --dataset "ludwig://alpaca", wobei vorher HUGGING_FACE_HUB_TOKEN als Umgebungsvariable gesetzt werden muss, weil das Basismodell von meta-llama gated ist. In der ausführlicheren Konfiguration stehen learning_rate: 0.0001, batch_size: 1, gradient_accumulation_steps: 16, epochs: 3 und ein Scheduler mit decay: cosine und warmup_fraction: 0.01. Der backend-Block mit type: local legt fest, wo trainiert wird. Ein prompt-Block mit template: und den Platzhaltern {instruction}, {input} und {response} steuert, wie die Textspalten in das Modell eingespeist werden. Das ist die vollständige Kette vom Befehl bis zum Template, und sie zeigt auch, wo die Konfiguration endet: Alles, was nicht als Schlüssel existiert, muss man am Framework vorbei lösen.

Die Breite der 0.16-Featureliste als Warnsignal

Die Release-Tabelle für 0.16 führt PatchTST und N-BEATS für Zeitreihenprognose, PiSSA, EVA, CorDA/LoftQ, TinyLoRA, OFT, HRA, WaveFT, LN-Tuning, VBLoRA und C3A als Adaptervarianten, VLM-Fine-Tuning für LLaVA, Qwen2-VL und InternVL, einen HyperNetwork-Combiner, Nash-MTL und Pareto-MTL, LLM-gestützte Konfigurationsgenerierung über ludwig generate_config, einen ModelInspector, Ray-Serve- und KServe-Deployment, GRPO, torchao-Quantisierung, Multi-Adapter-Merging mit TIES, DARE und SVD, einen Optuna-Executor, eine forecast-API, die Optimierer Muon und ScheduleFreeAdamW sowie Segmentierungs-Decoder UNet, SegFormer und FPN. Das ist keine Roadmap, sondern eine Liste bereits ausgelieferter Funktionen. Für Nutzer bedeutet diese Breite zweierlei. Positiv: Für viele Aufgaben existiert bereits ein Konfigurationsschlüssel. Negativ: Jede dieser Funktionen ist ein eigener Codepfad mit eigenen Abhängigkeiten, und die Kombination aus einem exotischen Adapter, einem bestimmten Quantisierungs-Backend und einem multimodalen Basismodell ist wahrscheinlich weniger erprobt als der Standardfall LoRA plus SFT. Wer eine dieser Kombinationen wählt, sollte den Codepfad als jung behandeln, unabhängig davon, wie vollständig die Schlüssel dokumentiert sind.

Wo die deklarative Grenze liegt

Eine YAML-Datei kann nur abbilden, was das Schema kennt. Sobald eine Anpassung nötig wird, die nicht als Schlüssel existiert, etwa eine eigene Loss-Funktion, eine ungewöhnliche Datenaufbereitung oder ein Eingriff in die Attention, endet der deklarative Pfad. Das ist keine Schwäche von Ludwig allein, sondern die Grenze jedes konfigurationsgetriebenen Frameworks, und sie ist bei einem Projekt mit dieser Featurebreite schwerer zu erkennen, weil die Liste der vorhandenen Schlüssel lang ist. Ein zweiter Punkt betrifft die Versionierung der Konfiguration. Die Releases folgen einem schnellen Takt: v0.17.7 im Juli 2026, v0.17.8 mit einem Path-Traversal-Fix bei der Extraktion von Datensatzarchiven, v0.17.9 im August 2026. Der Fix in v0.17.8 ist ein Sicherheitshinweis darauf, dass Ludwigs Datenlademechanismus Archivdateien entpackt. Wer Datensätze aus nicht vertrauenswürdigen Quellen bezieht, sollte diese Version oder neuer einsetzen. Wer eigene Erweiterungen am Framework vornimmt, trägt bei diesem Takt laufende Anpassungskosten. Für reine YAML-Nutzer ist das billiger, aber nicht kostenlos: Konfigurationsschlüssel können sich zwischen Minor-Versionen verschieben, und das README dokumentiert den aktuellen Stand, nicht die Historie.

Ludwig oder PyTorch Lightning: unterschiedliche Abstraktionsebenen

PyTorch Lightning ist die naheliegende Alternative, wenn man die Trainingsschleife selbst schreiben will. Der Unterschied liegt in der Ebene: Lightning abstrahiert die Schleife, aber der Nutzer definiert weiterhin das Modul, die Loss-Berechnung und die Datenaufbereitung in Python. Ludwig abstrahiert zusätzlich die Merkmalsdefinition und die Modellzusammensetzung, weshalb input_features und output_features mit Typangaben wie text oder image ausreichen, um Encoder zuzuordnen. Für Tabellenklassifikation ist das ein spürbarer Unterschied: In Lightning schreibt man das Modul, in Ludwig beschreibt man die Spalten. Für LLM-Fine-Tuning verschiebt sich das Bild, weil Hugging Face Transformers mit Trainer und peft bereits Bausteine liefert, die den Abstand zu Ludwig verkleinern. Ludwigs Vorteil liegt dort weniger in der Abstraktion als in der Bündelung: Alignment-Verfahren, Adaptervarianten und Quantisierung hinter einer gemeinsamen Konfiguration. Wer diese Bündelung nicht braucht und ohnehin eigene Trainingslogik schreibt, gewinnt durch Ludwig wenig und verliert die direkte Kontrolle über den Trainingsschritt.

Wartung, Lizenz und der praktische Prüfpunkt

Ludwig steht unter Apache-2.0 und wird von der Linux Foundation AI & Data gehostet. Die Lizenz erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung der Urheberrechts- und Lizenzhinweise sowie eine Kennzeichnung geänderter Dateien; wer das Projekt weiterverbreitet, sollte die Bedingungen im LICENSE-File selbst lesen, statt sich auf eine Zusammenfassung zu verlassen. Das gilt besonders, wenn Ludwig in ein Produkt eingebettet wird. Für die Wartung ist die Kombination aus Trägerschaft und Release-Takt ein gutes Zeichen für Kontinuität, aber sie sagt nichts über die Stabilität einzelner Konfigurationsschlüssel. Der konkrete Prüfpunkt vor dem Einstieg ist deshalb nicht die Featureliste, sondern die eigene Umgebung: Python 3.12 oder neuer, die im README genannten Versionen von PyTorch, Transformers und Ray, und die Frage, ob die vorhandene Hardware zu der Quantisierung passt, die man einsetzen will. Wer ein 8B-Modell mit quantization.bits: 4 trainieren möchte, sollte den Speicherbedarf vor dem ersten vollständigen Lauf mit einer kleinen Teilmenge des Datensatzes messen, nicht schätzen. Diese Messung ist der eigentliche Einstiegstest: Sie zeigt in einem Durchlauf, ob Konfiguration, Umgebung und Hardware zusammenpassen.

Redaktionelles Fazit

Wer LLM-Fine-Tuning, multimodale Klassifikation oder Tabellenmodelle über eine YAML-Datei steuern will und dafür bereit ist, Python 3.12 sowie die im README genannten Abhängigkeiten (PyTorch 2.7+, Transformers 5, Ray 2.54) zu akzeptieren, findet in Ludwig einen konfigurationsgetriebenen Einstieg. Wer volle Kontrolle über Trainingsschleife und Modellarchitektur braucht oder keinen YAML-Zwischenlayer will, sollte bei PyTorch Lightning oder einem eigenen Trainer bleiben. Vor dem ersten produktiven Lauf ist zu klären, ob die eigene Karte in die Spezifikation passt, die das gewählte Quantisierungs-Backend voraussetzt, und ob die installierte Ludwig-Version die verwendeten Konfigurationsschlüssel kennt, da sich diese zwischen Releases ändern. Wer das geprüft hat, kann mit 'ludwig train --config model.yaml --dataset my_data.csv' starten.

Offizielle Quellen

1. License: Apache-2.0
2. ludwig-ai/ludwig on GitHub
3. Project website
4. README
5. Releases