Weights and Biases (W&B)
Wer ein Modell trainiert, verändert dabei tausende Stellschrauben gleichzeitig. Ohne eine systematische Aufzeichnung dieser Veränderungen geht der Überblick schnell verloren. Weights and Biases (W&B) ist eine Plattform, die genau diese Aufzeichnung übernimmt: Sie protokolliert jeden Trainingslauf, speichert alle Einstellungen und macht Ergebnisse visuell vergleichbar.
Was W&B protokolliert und warum das relevant ist
Beim Training eines neuronalen Netzes verändern sich in jedem Schritt die internen Gewichte des Modells. Gleichzeitig gibt es äußere Einstellungen, die den Trainingsverlauf steuern: Batch-Größe, Lernrate, Anzahl der Epochen, Architekturentscheidungen. W&B zeichnet beides auf. Für jeden Trainingslauf (Run) entsteht ein vollständiger Datensatz: Konfiguration, Metrikverläufe, Systemressourcen, Code-Version.
Beispiel: Ein Team trainiert ein Bildklassifikationsmodell mit drei verschiedenen Lernraten. Ohne W&B müssten die Ergebnisse manuell in Tabellen eingetragen werden. Mit W&B erscheinen alle drei Runs automatisch im selben Dashboard, die Loss-Kurven lassen sich direkt übereinanderlegen.
Beispiel: Ein Forscher ändert die Architektur eines Transformer-Modells (von 6 auf 12 Attention-Heads). W&B speichert die Konfiguration beider Varianten und zeigt im Vergleich, ab welcher Epoche die größere Variante bessere Validierungswerte erreicht.
Integration in bestehenden Code
W&B wird über eine Python-Bibliothek eingebunden. Die Grundstruktur umfasst drei Schritte: Initialisierung eines Runs, Logging von Metriken innerhalb der Trainingsschleife, Abschluss des Runs. Der Code-Eingriff beschränkt sich typischerweise auf wenige Zeilen.
Beispiel: In einem PyTorch-Trainingsskript genügen vier zusätzliche Zeilen: wandb.init() vor dem Training, wandb.config für die Hyperparameter, wandb.log() in der Trainingsschleife und wandb.finish() nach dem Training.
Beispiel: Ein bestehendes TensorFlow-Projekt nutzt Keras-Callbacks. W&B bietet einen eigenen Callback (WandbCallback), der in die model.fit()-Methode eingehängt wird. Es sind keine Änderungen an der Trainingslogik selbst notwendig.
Die Bibliothek erkennt automatisch das verwendete Framework und passt das Logging entsprechend an. Neben PyTorch und TensorFlow werden unter anderem Hugging Face Transformers, XGBoost, LightGBM und scikit-learn unterstützt.
Das Dashboard: Vergleiche zwischen Runs
Das zentrale Werkzeug von W&B ist ein webbasiertes Dashboard. Es zeigt Trainingskurven, Systemmetriken (GPU-Auslastung, Speicherverbrauch) und konfigurierte Hyperparameter in einer einheitlichen Oberfläche. Runs lassen sich filtern, gruppieren und in Parallel-Coordinates-Plots darstellen.
Beispiel: Nach 50 Trainingsruns mit unterschiedlichen Konfigurationen zeigt ein Parallel-Coordinates-Plot die Kombination aus Lernrate, Batch-Größe und Loss-Wert. Auf einen Blick wird sichtbar, welche Parameterbereiche zuverlässig niedrige Fehlerwerte erzeugen.
Beispiel: Ein Modell zeigt nach 20 Epochen plötzlich steigende Validierungsfehler. Im Dashboard lässt sich der Punkt identifizieren, an dem Trainings- und Validierungskurve auseinanderlaufen. Die GPU-Temperaturkurve zeigt gleichzeitig, ob das Training durch Thermal Throttling verlangsamt wurde.
Automatische Hyperparameter-Suche mit Sweeps
Sweeps sind eine W&B-Funktion zur automatisierten Hyperparameter-Optimierung. Statt manuell verschiedene Konfigurationen auszuprobieren, definiert man einen Suchraum (welche Parameter in welchem Bereich variiert werden sollen) und eine Suchstrategie. W&B startet dann systematisch Trainingsruns mit unterschiedlichen Kombinationen.
Die verfügbaren Suchstrategien sind: Grid Search (alle Kombinationen), Random Search (zufällige Stichproben aus dem Suchraum) und Bayes'sche Optimierung (nutzt Ergebnisse früherer Runs, um vielversprechende Bereiche gezielt zu untersuchen).
Beispiel: Für ein Sprachmodell soll die optimale Kombination aus Lernrate (0,0001 bis 0,01), Batch-Größe (16, 32, 64) und Dropout-Rate (0,1 bis 0,5) gefunden werden. Ein Bayes'scher Sweep startet mit zufälligen Konfigurationen, erkennt nach 15 Runs, dass niedrige Lernraten mit hoher Batch-Größe gut funktionieren, und konzentriert die weiteren Runs auf diesen Bereich.
Beispiel: Ein Sweep über 200 Konfigurationen zeigt, dass die Lernrate den größten Einfluss auf die Modellqualität hat, während die Dropout-Rate kaum Unterschiede verursacht. Diese Erkenntnis spart bei zukünftigen Experimenten Zeit, weil der Dropout-Wert fixiert werden kann.
Versionierung mit Artifacts
Artifacts sind W&B-Objekte für die Versionierung von Dateien, die im Machine-Learning-Workflow entstehen: Datensätze, trainierte Modelle, Konfigurationsdateien. Jede Änderung erzeugt eine neue Version. W&B speichert dabei nur die Differenz zur vorherigen Version, was den Speicherbedarf reduziert.
Zwischen Artifacts können Abhängigkeiten definiert werden. Ein trainiertes Modell (Artifact v3) hängt ab vom Trainingsdatensatz (Artifact v2) und der Konfiguration (Artifact v1). Diese Abhängigkeitskette ermöglicht es, für jedes Modell exakt nachzuvollziehen, mit welchen Daten und Einstellungen es erstellt wurde.
Beispiel: Ein Trainingsdatensatz wird um 5.000 Bilder erweitert. W&B erstellt automatisch Version v2 des Datensatz-Artifacts. Das nächste Training nutzt v2, das Ergebnis wird als neues Modell-Artifact gespeichert. Drei Monate später lässt sich nachvollziehen, welche Datenversion zu welchem Modellergebnis geführt hat.
Fachliche Einordnung: Die Artifact-Versionierung adressiert ein zentrales Problem im Machine-Learning-Workflow: die Reproduzierbarkeit. Anders als in der klassischen Softwareentwicklung, wo Git den Quellcode versioniert, müssen im ML-Kontext zusätzlich Daten, Modellgewichte und Trainingskonfigurationen gemeinsam versioniert werden. W&B Artifacts übernimmt diesen Teil. Die Lösung ist allerdings proprietär. Offene Alternativen wie DVC (Data Version Control) verfolgen einen ähnlichen Ansatz, speichern die Metadaten jedoch im Git-Repository selbst.
Abgrenzung zu TensorBoard und anderen Werkzeugen
TensorBoard ist ein quelloffenes Visualisierungswerkzeug von Google, das ähnliche Grundfunktionen bietet: Trainingsmetriken darstellen, Modellgraphen visualisieren, Embedding-Projektionen anzeigen. Die wesentlichen Unterschiede betreffen Speicherung, Zusammenarbeit und Suchraum-Exploration.
TensorBoard speichert Daten lokal als Event-Dateien. W&B speichert sie zentral (Cloud oder Self-Hosted-Server). Bei Einzelpersonen spielt das kaum eine Rolle. In Teams mit mehreren Forschern ermöglicht die zentrale Speicherung, dass alle Beteiligten auf die gleichen Runs zugreifen, ohne Dateien austauschen zu müssen.
Beispiel: Ein verteiltes Team arbeitet an einem Modell. Forscher A trainiert in München, Forscher B in Berlin. Mit TensorBoard müssten sie Event-Dateien per Netzwerk teilen oder einen gemeinsamen Server einrichten. Mit W&B sehen beide Runs sofort im selben Dashboard.
Weitere Alternativen im Bereich ML-Experiment-Tracking sind MLflow (Open Source, von Databricks), Neptune.ai (kommerziell, ähnlicher Funktionsumfang wie W&B), Comet ML (kommerziell) und ClearML (Open Source). Jedes Werkzeug setzt eigene Schwerpunkte bei Integration, Skalierung und Preismodell.
Reports und Zusammenarbeit
W&B Reports sind Dokumente, die Visualisierungen, Text und Code-Snippets kombinieren. Sie funktionieren ähnlich wie Jupyter Notebooks, sind aber direkt in die W&B-Plattform integriert. Die Visualisierungen in einem Report sind an die tatsächlichen Run-Daten gebunden: Ändert sich ein Run, aktualisiert sich die Darstellung im Report.
Beispiel: Ein Forschungsteam erstellt einen Report, der die Ergebnisse von drei Modellarchitekturen vergleicht. Der Report enthält Loss-Kurven, eine Tabelle mit Precision- und F1-Werten sowie eine textuelle Zusammenfassung. Neue Teammitglieder können den Report lesen und die Entscheidung für Architektur B nachvollziehen.
Beispiel: Vor einem Paper-Review erstellt ein Doktorand einen W&B Report mit allen Experimenten der letzten sechs Monate. Die Betreuerin kann direkt in den interaktiven Grafiken filtern und eigene Analysen vornehmen, ohne den Trainingscode ausführen zu müssen.
Grenzen und Einschränkungen
W&B ist ein kommerzielles Produkt. Die kostenlose Basisversion erlaubt 100 GB Speicher für Einzelpersonen. Für Teams, private Projekte und erweiterte Funktionen (SAML-Authentifizierung, Audit-Logs) fallen Kosten an. Die Preisstruktur richtet sich nach der Anzahl der tracked Runs und dem Speichervolumen.
Die zentrale Speicherung in der W&B-Cloud bedeutet, dass Trainingsdaten und Modellmetriken auf externen Servern liegen. Für Organisationen mit strengen Datenschutzanforderungen bietet W&B eine Self-Hosted-Variante, die den gleichen Funktionsumfang innerhalb der eigenen Infrastruktur bereitstellt.
Die Abhängigkeit von einer externen Plattform erzeugt ein Lock-in-Risiko. Zwar lassen sich Runs als JSON und CSV exportieren, aber die vollständige Migration zu einem anderen Tracking-System (etwa MLflow) erfordert erheblichen Aufwand bei der Konvertierung von Artifacts und der Rekonstruktion von Run-Beziehungen.
Beispiel: Ein Startup nutzt W&B für zwei Jahre und sammelt 10.000 Runs. Bei einem Wechsel zu MLflow müssten nicht nur die Metriken, sondern auch die Artifact-Abhängigkeiten, Sweep-Konfigurationen und Report-Strukturen migriert werden. Die reinen Run-Daten lassen sich exportieren, der Kontext geht teilweise verloren.
Fachliche Einordnung: Das Experiment-Tracking ist ein vergleichsweise junges Feld. Noch 2018 war es üblich, Trainingsergebnisse in Spreadsheets zu dokumentieren oder lokale TensorBoard-Instanzen zu nutzen. W&B hat zusammen mit einigen Wettbewerbern diese Praxis professionalisiert. Die Frage, ob ein proprietäres Werkzeug oder eine Open-Source-Lösung die bessere Wahl ist, hängt von Teamgröße, Budget und den Anforderungen an Datenschutz ab. Für akademische Forschung mit beschränktem Budget und hohem Reproduzierbarkeitsanspruch sind offene Lösungen wie MLflow oder DVC eine überlegenswerte Alternative.