Dolma: Korpus und Toolkit für die Vortrainingsdaten von OLMo

Zwei Projekte unter einem Namen

Das Repository beschreibt Dolma als zwei Dinge. Erstens das Dolma Dataset: drei Billionen Tokens aus Web-Inhalten, wissenschaftlichen Publikationen, Code, Büchern und enzyklopädischem Material, entstanden als Trainingskorpus für OLMo vom Allen Institute for AI. Zweitens das Dolma Toolkit, ein Werkzeug zur Kuratierung großer Datensätze für das Pretraining. Im Repository liegt der Quellcode des Toolkits, nicht der Korpus selbst. Diese Trennung ist der erste Punkt, an dem sich entscheidet, ob das Projekt überhaupt passt. Wer Trainingsdaten sucht, wird im Repository nicht fündig, sondern auf dem HuggingFace Hub unter huggingface.co/datasets/allenai/dolma. Wer eine Pipeline zum Filtern eigener Daten sucht, findet sie hier. Die Zielgruppe des Toolkits sind also nicht Anwender, die einen fertigen Korpus konsumieren, sondern Teams, die aus Rohdumps wie Common-Crawl-Auszügen ein Trainingsset formen müssen.

Taggers, Bloom-Filter und die Reihenfolge der Schritte

Die README nennt fünf Eigenschaften des Toolkits, und aus ihnen lässt sich der Datenfluss rekonstruieren. Dokumente werden parallel verarbeitet, laut Beschreibung bis in den Bereich von Milliarden Dokumenten. Der eigentliche inhaltliche Kern sind die eingebauten Taggers: vorgefertigte Filterregeln nach Gopher, C4 und OpenWebText. Ein Tagger versieht jedes Dokument mit Attributen, etwa Zählungen oder Qualitätsmerkmalen, und diese Attribute sind die Grundlage für die anschließende Auswahl. Der zweite Kern ist die Deduplizierung, die laut README über einen in Rust implementierten Bloom-Filter läuft. Das ist eine bewusste Designentscheidung mit Konsequenz: Ein Bloom-Filter ist speichereffizient, liefert aber probabilistische Antworten. Dokumente, die als Duplikate markiert werden, sind es mit hoher Wahrscheinlichkeit, aber nicht garantiert. Wer exakte Duplikaterkennung auf Hash-Basis braucht, muss das selbst bauen oder einen anderen Weg gehen. Bemerkenswert ist die Reihenfolge: Erst taggen, dann deduplizieren oder filtern, je nach Konfiguration. Wer die Tag-Attribute behält, kann später andere Schwellenwerte ausprobieren, ohne die Rohdaten erneut durch die Taggers zu schicken. Genau das ist der praktische Nutzen des Zwischenschritts.

Installation und der erste Lauf

Die Installation ist in der README auf eine Zeile reduziert: pip install dolma. Alles Weitere läuft über die Dokumentation im Verzeichnis docs, die hier nicht im Detail vorliegt. Konkrete Konfigurationsschlüssel, Pipeline-Dateien oder CLI-Parameter lassen sich aus dem vorliegenden Material nicht belegen. Wer das Toolkit einsetzen will, muss also mit der Dokumentation arbeiten, nicht mit dem README allein. Zwei Dinge lassen sich dennoch festhalten. Erstens: Das Toolkit ist in Python geschrieben, die Deduplizierung nutzt eine Rust-Komponente, was bedeutet, dass beim Installieren ein kompiliertes Modul mitkommt. Auf exotischen Architekturen kann das ein Stolperstein sein. Zweitens: Die README nennt ausdrücklich AWS S3-kompatible Speicherorte als unterstütztes Ziel, ebenso den Betrieb auf einer einzelnen Maschine, im Cluster oder in der Cloud. Das ist keine Nebenbemerkung, sondern bestimmt die Deployment-Form. Wer auf einem einzelnen Rechner mit lokalem Dateisystem arbeitet, nutzt einen anderen Pfad als ein Team, das Shards in einem S3-Bucket ablegt. Für den Einstieg ist der Single-Machine-Fall der sinnvollere, weil er die Fehlersuche nicht mit Netzwerk- und Berechtigungsproblemen vermischt.

Wo das Toolkit an seine Grenzen kommt

Die eingebauten Taggers sind ein Vorteil und eine Falle zugleich. Gopher, C4 und OpenWebText sind Heuristiken, die für englischsprachige Webtexte entworfen wurden. Wer deutschsprachige oder mehrsprachige Korpora kuratiert, übernimmt Regeln, die auf einer anderen Sprachverteilung kalibriert sind, und muss damit rechnen, dass die Filter anders greifen als beabsichtigt. Die README geht auf Mehrsprachigkeit nicht ein. Ein zweiter Punkt: Das Toolkit ist auf Skalierung ausgelegt, nicht auf kleine Datensätze. Wer ein paar Millionen Tokens für einen Prototyp aufbereitet, trägt den Overhead einer Parallelisierungs- und Deduplizierungsmaschinerie, die für Milliarden Dokumente gebaut ist. Das ist kein Fehler des Projekts, aber es macht es für kleine Vorhaben zum falschen Werkzeug. Drittens die Deduplizierung: Der Bloom-Filter arbeitet über Dokumente. Teilweise überlappende Absätze in unterschiedlichen Dokumenten erkennt er nicht als Duplikat. Wer Near-Duplicate-Erkennung auf Absatzebene braucht, muss sie zusätzlich implementieren. Und schließlich: Das Toolkit endet bei kuratierten Dokumenten. Tokenisierung, Packing und das eigentliche Training sind nicht Teil des Projekts.

Was man stattdessen nimmt

Der offensichtliche Vergleichspunkt ist datatrove, eine ebenfalls in Python geschriebene Bibliothek für genau dieselbe Aufgabe: Filterung und Deduplizierung von Pretraining-Daten. Der Unterschied liegt im Ansatz. Dolma setzt auf eine feste Sammlung eingebauter Taggers (Gopher, C4, OpenWebText) und einen Rust-Bloom-Filter für die Deduplizierung. Datatrove verfolgt einen stärker bausteinartigen Ansatz, bei dem einzelne Filterstufen explizit zu einer Pipeline zusammengesetzt werden. Für Teams, die schnell einen erprobten, in einem veröffentlichten Modell verwendeten Filterstack reproduzieren wollen, ist Dolma der direktere Weg: Der Korpus, den das Toolkit erzeugt hat, ist derselbe, auf dem OLMo trainiert wurde, und die Regeln sind damit nachvollziehbar dokumentiert. Wer dagegen eigene Filterstufen mischen, eigene Deduplizierungsstrategien einhängen oder die Kontrolle über jeden Verarbeitungsschritt behalten will, wird bei einem Pipeline-Framework besser bedient. Die Entscheidung hängt also weniger an der Leistung als daran, ob man einen fertigen, belegten Filterstack übernehmen oder einen eigenen zusammenstellen will.

Lizenzen: zwei verschiedene Regime

Hier ist Sorgfalt angebracht, weil zwei verschiedene Lizenzen im Spiel sind. Der Quellcode des Toolkits steht unter Apache-2.0, einer permissiven Lizenz mit Patentklausel, die kommerzielle Nutzung und Modifikation erlaubt. Das Dataset dagegen steht unter ODC-BY. Die README verweist ausdrücklich auf einen Blogbeitrag, der den Wechsel zu ODC-BY erklärt. ODC-BY ist eine Attributionslizenz für Datenbanken: Die Nutzung ist weitgehend frei, aber die Namensnennung ist verpflichtend. Wer den Korpus verwendet, muss also die Attributionsanforderung erfüllen, und die README liefert dafür den BibTeX-Eintrag gleich mit. Wichtig ist die Trennung: Apache-2.0 für den Code bedeutet nicht, dass die mit dem Code erzeugten Daten unter Apache-2.0 stehen. Wer eigene Daten durch die Pipeline schickt, bleibt für deren Lizenzierung selbst verantwortlich. Das Toolkit trifft darüber keine Aussage. Eine rechtliche Bewertung ist hier nicht möglich und auch nicht beabsichtigt, aber die Unterscheidung zwischen Code-Lizenz und Daten-Lizenz sollte man beim Lesen der README nicht übersehen.

Wartung und Aktualisierung

Die Release-Historie ist aus dem vorliegenden Material ablesbar: v1.1.2 im Februar 2025, v1.2.0 im Juni 2025, v1.2.1 im Juli 2025. Das sind drei Releases innerhalb von etwa fünf Monaten, danach folgen bis zum letzten Push im August 2026 keine weiteren Einträge. Aus dieser Abfolge lässt sich keine Aussage über die weitere Entwicklung ableiten, und das sollte man auch nicht versuchen. Wer das Toolkit in eine bestehende Datenpipeline einbaut, sollte zwei Dinge einplanen. Erstens: Die Abhängigkeit von einer kompilierten Rust-Komponente bedeutet, dass ein Upgrade der Python-Seite nicht automatisch mit einem Upgrade der Erweiterung einhergeht. Zweitens: Die Taggers sind Teil des Toolkits, nicht austauschbar konfigurierbar. Ändert sich eine Filterregel zwischen Versionen, ändert sich das Ausgabeverteil, ohne dass sich an den Eingabedaten etwas geändert hat. Wer Reproduzierbarkeit braucht, sollte die Toolkit-Version festnageln und nicht auf die neueste Version aktualisieren, ohne die Tag-Zählungen vorher und nachher zu vergleichen.

Redaktionelles Fazit

Wer einen fertigen, lizenzierten Vortrainingskorpus braucht, lädt das Dolma-Dataset von HuggingFace und kommt mit dem Toolkit nie in Berührung. Wer eigene Rohdaten nach Gopher-, C4- oder OpenWebText-Regeln filtern und deduplizieren will, ist beim Toolkit richtig, sollte aber zuerst einen einzelnen Shard durch die gesamte Pipeline schicken und die Tag-Zählungen gegen die eigene Heuristik prüfen, bevor Rechenzeit in den vollen Korpus fließt. Wer eine fertige Trainingspipeline mit Tokenizer, Sharding und Checkpointing sucht, ist hier falsch: Dolma endet bei den kuratierten Dokumenten.

Offizielle Quellen

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