llm-foundry: Trainings- und Evaluationscode für MPT und DBRX
LLM training code for Databricks foundation models
Auf einen Blick
- Was ist das?
- Das Repository von MosaicML bündelt Skripte zum Trainieren, Finetunen, Evaluieren und Ausliefern von LLMs auf Basis von Composer. Es ist kein Framework für den schnellen Einstieg, sondern eine Sammlung von Workloads für eigene Cluster und die MosaicML-Plattform.
- Für wen ist es gedacht?
- Wer MPT- oder DBRX-Modelle auf eigener Hardware trainieren oder finetunen will und Composer bereits einsetzt, findet hier die passenden Skripte unter scripts/train und scripts/eval. Wer nur ein vortrainiertes Modell per API ansprechen möchte, ist mit einem Inferenz-Stack besser bedient.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 174 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Lücke llm-foundry schließt
Ein Basismodell zu trainieren besteht nicht aus einem einzigen Skript. Daten müssen in ein Format gebracht werden, das der Trainer lesen kann. Der Trainingslauf braucht Konfiguration für Optimierer, Batch-Größen und Checkpointing. Danach folgen Evaluierung und die Umwandlung in ein Format, das Inferenzserver verstehen. llm-foundry bündelt genau diese Schritte in einem Repository. Die README beschreibt den Inhalt als Code zum Trainieren, Finetunen, Evaluieren und Ausliefern von LLMs mit Composer und der MosaicML-Plattform. Die Zielgruppe sind Teams, die eigene Modelle auf eigener Hardware oder auf der MosaicML-Plattform betreiben, nicht Anwender, die eine fertige API suchen. Dass Databricks das Repository für die eigenen Foundation Models nutzt, ist der Repository-Beschreibung zu entnehmen. Der Code ist damit nicht auf ein Forschungsprojekt zugeschnitten, sondern auf einen produktiven Trainingsbetrieb.
Verzeichnisse als Architektur
Die Struktur des Repositories verrät mehr über den Aufbau als jede Beschreibung. Unter llmfoundry/ liegt der Quellcode für Modelle, Datasets, Callbacks und Hilfsfunktionen. Alles, was ausgeführt wird, liegt unter scripts/, aufgeteilt nach Aufgabe. scripts/data_prep/ konvertiert Textdaten aus den Quellformaten in das StreamingDataset-Format. scripts/train/ trainiert oder finetunt HuggingFace- und MPT-Modelle von 125M bis 70B Parametern, wobei scripts/train/benchmarking den Trainingsdurchsatz und die MFU profiliert. scripts/inference/ wandelt Modelle nach HuggingFace oder ONNX um und erzeugt Antworten. scripts/eval/ evaluiert Modelle auf akademischen oder eigenen In-Context-Learning-Aufgaben. Der Datenfluss ist damit linear: Rohdaten werden einmalig über data_prep in Shards überführt, das Training liest diese Shards über StreamingDataset, und die Ausgabe ist ein Checkpoint, der anschließend konvertiert oder evaluiert wird. Diese Trennung ist der Grund, warum das Repository skalierbar bleibt. Der Preis dafür ist, dass zwischen den Schritten Dateien und Konfigurationen weitergereicht werden müssen, statt dass ein einziger Aufruf alles erledigt.
Training starten: Skripte, YAML und MCLI
Der Einstieg läuft über die Skripte in scripts/train. Die README nennt für die Inferenz konkrete Dateien: scripts/inference/hf_generate.py und scripts/inference/hf_chat.py, jeweils mit einer Anleitung in scripts/inference/README.md. Für das Training selbst verweist das Repository auf YAML-Konfigurationen, die an die Trainingsskripte übergeben werden. Wer die Workloads nicht selbst auf einem Cluster starten will, nutzt das Verzeichnis mcli/, das laut README jeden dieser Workloads über MCLI und die MosaicML-Plattform startet. Das ist eine bewusste Kopplung: Das Repository funktioniert eigenständig, aber der vorgesehene Weg für verteiltes Training führt über die Plattform des Anbieters. Für einen ersten Testlauf ist TUTORIAL.md der richtige Ausgangspunkt, weil es laut README Beispiel-Workflows und FAQs enthält. Wer direkt in scripts/train einsteigt, muss die Konfigurationsdateien selbst durcharbeiten.
MPT, DBRX und die Modellmatrix
Das Repository ist eng mit den Modellen von MosaicML verbunden. MPT-Modelle sind laut README GPT-artige Transformer mit Flash Attention, ALiBi zur Kontextlängenextrapolation und Stabilitätsverbesserungen gegen Loss-Spikes. Die README listet MPT-7B mit 2048 Token Kontext, MPT-30B und MPT-7b-8k mit 8192 Token sowie MPT-7B-StoryWriter mit 65536 Token. Entscheidend für die kommerzielle Nutzung ist die Spalte Commercial use: Die Instruct-Varianten sind mit Yes markiert, die Chat-Varianten mit No. Wer ein Chat-Modell produktiv einsetzen will, muss die Lizenzbedingungen also getrennt prüfen. DBRX ist ein Mixture-of-Experts-Modell mit 132B Gesamtparametern und 36B aktiven Parametern, trainiert mit optimierten Versionen von Composer, LLM Foundry und MegaBlocks. Laut README wurden DBRX Base und DBRX Instruct mit 32768 Token Kontext veröffentlicht. Die Gewichte und der Code sind für Forscher und kommerzielle Nutzer lizenziert, wobei die README auf die Databricks Open Source License und eine Acceptable Use Policy verweist. Diese Trennung zwischen Code-Lizenz und Modell-Lizenz ist der Punkt, an dem viele Teams stolpern.
Wo llm-foundry an Grenzen stößt
Die Lizenz des Repositories selbst ist Apache-2.0. Das ist eine der permissivsten Lizenzen und erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, sofern die Lizenzbedingungen eingehalten werden. Das sagt jedoch nichts über die Modellgewichte aus. Die MPT-Tabelle zeigt Chat-Varianten ohne kommerzielle Freigabe, und die README verweist für DBRX ausdrücklich auf eine separate Lizenz und eine Acceptable Use Policy. Wer die Apache-2.0-Angabe des Repositories als Freigabe für alle enthaltenen Modelle liest, zieht den falschen Schluss. Eine zweite Grenze ist die Hardware. Das Training von Modellen bis 70B Parametern setzt verteilte GPU-Ressourcen voraus. Die README nennt diese Größenordnung, ohne Mindestanforderungen zu spezifizieren. Wer mit einer einzelnen GPU arbeitet, kann Finetuning kleinerer Modelle betreiben, stößt bei den größeren jedoch an Speichergrenzen. Drittens die Plattformbindung: mcli/ ist auf MCLI und die MosaicML-Plattform ausgelegt. Ohne diese Umgebung bleiben die Skripte unter scripts/ nutzbar, der Komfort der Workload-Orchestrierung entfällt aber. Wer bereits eine eigene Ausführungsumgebung betreibt, wird Teile davon doppelt aufbauen müssen.
Der Vergleich mit einem reinen Trainer
Der naheliegende Vergleich ist ein Framework, das Training auf ein Modell und einen Datensatz reduziert, etwa die Trainer-Klassen aus der HuggingFace-Bibliothek. llm-foundry geht den umgekehrten Weg. Es setzt auf Composer als Trainingsschicht und ergänzt darum herum Skripte für Datenaufbereitung, Benchmarking, Evaluierung und Konvertierung. Der Unterschied liegt im Umfang der Kontrolle. Ein HuggingFace Trainer abstrahiert die Trainingsschleife weitgehend und funktioniert ohne eigenes Datenformat. llm-foundry verlangt, dass Daten zuerst über scripts/data_prep in das StreamingDataset-Format überführt werden, und belohnt das mit einem Datenpfad, der für sehr große Korpora ausgelegt ist. Wer ohnehin schon Composer verwendet, bekommt hier die passenden Modelldefinitionen und Callbacks. Wer Composer nicht einsetzt, muss diese Abhängigkeit akzeptieren, bevor der erste Trainingslauf möglich ist. Die Entscheidung ist damit weniger eine Frage der Funktionalität als eine Frage der bestehenden Infrastruktur.
Wartung, Releases und Aktualisierungskosten
Die letzten Releases liegen bei v0.22.0 vom Juli 2025, v0.21.0 vom Mai 2025 und v0.20.0 vom April 2025. Der Abstand zwischen den Versionen beträgt jeweils etwa zwei Monate, der letzte Push ins Repository ist mit März 2026 datiert. Das Repository ist als nicht archiviert gekennzeichnet, wird also weiter gepflegt. Für Anwender bedeutet der Zwei-Monats-Rhythmus, dass zwischen Minor-Versionen Änderungen an Konfigurationsschlüsseln und Skriptaufrufen auftreten können. Wer eine Trainingspipeline auf eine feste Version pinnt, vermeidet Überraschungen, verliert aber Fehlerkorrekturen. Wer immer auf die aktuelle Version geht, muss die Release Notes lesen, bevor ein laufender Trainingsjob neu gestartet wird. Ein weiterer Kostenpunkt ist die Abhängigkeit von Composer. Dessen Versionsstand bestimmt mit, welche llm-foundry-Version funktioniert. Diese Kette aus Composer, llm-foundry und den Modellgewichten ist der eigentliche Wartungsaufwand, nicht das Repository allein.
Redaktionelles Fazit
Wer MPT- oder DBRX-Modelle auf eigener Hardware trainieren oder finetunen will und Composer bereits einsetzt, findet hier die passenden Skripte unter scripts/train und scripts/eval. Wer nur ein vortrainiertes Modell per API ansprechen möchte, ist mit einem Inferenz-Stack besser bedient. Vor dem ersten Lauf sollte man TUTORIAL.md lesen, die YAML-Konfiguration unter scripts/train/yamls prüfen und die GPU-Anforderungen der gewählten Modellgröße gegen die eigene Hardware abgleichen.
Community-Notizen