Bespoke Curator: Bulk-Inferenz und Datenkuratierung für Post-Training

Welches Problem Curator löst und für wen es gedacht ist

Wer einen Datensatz für Instruction-Tuning oder für strukturierte Extraktion aufbaut, schreibt am Ende selten ein Skript, sondern ein halbes System: Aufrufe an mehrere Anbieter, Wiederholungen bei Rate-Limits, Zwischenspeicherung bereits beantworteter Prompts, ein Blick auf den Fortschritt und ein Ausgabeformat, das die Trainingspipeline akzeptiert. Curator setzt genau an dieser Stelle an. Die Bibliothek beschreibt sich selbst als Werkzeug für Bulk-Inference und skalierbare Datenkuratierung für Post-Training, mit Unterstützung für strukturierte Ausgaben und einem Viewer, der die Daten während der Generierung beobachtet. Adressat sind damit nicht Endanwender, sondern ML-Ingenieure und Forschende, die einen Datensatz erzeugen und danach ein Modell darauf trainieren. Die Beispiele im Repository zeigen diese Richtung: Produktmerkmalsextraktion, aspektbasierte Sentimentanalyse, RAFT für domänenspezifisches RAG und ein durchgängiges Beispiel, das Gedichte kuratiert und anschließend per LoRA mit dem Tinker SDK feintunt. Der Anspruch ist also nicht, ein Modell zu trainieren, sondern die Daten davor herzustellen.

Der Decorator als Pipeline: wie der Datenfluss aussieht

Das sichtbare Architekturmuster ist ein Decorator, der eine gewöhnliche Python-Funktion in einen Pipeline-Knoten verwandelt. Die Funktion bekommt eine Zeile oder ein Objekt, gibt einen Prompt zurück, und Curator übernimmt ab dort die Ausführung. Aus dieser Trennung folgt der eigentliche Nutzen: Der Prompt wird nicht sofort abgeschickt, sondern gesammelt, damit Batch-Endpunkte sinnvoll genutzt werden können. Die Dokumentation nennt als Kernpunkte asynchrone Operationen, Caching und Fehlerwiederaufnahme. Der Viewer ist als separates Werkzeug beschrieben, mit dem sich Zwischenstände betrachten lassen, während die Generierung läuft. Für strukturierte Ausgaben gibt es laut README ausdrückliche Unterstützung, was bedeutet, dass ein Schema die Form der Antwort bestimmt und nicht nachträglich aus Freitext geparst wird. Die Inferenzschicht läuft über LiteLLM, vLLM oder die Batch-APIs der Anbieter. Das ist eine bewusste Abstraktion: Curator kennt die Modellnamen nicht selbst, sondern reicht sie durch. Wer wissen will, ob ein bestimmtes Modell oder ein bestimmter Batch-Endpunkt funktioniert, muss deshalb in der LiteLLM-Anbindung nachsehen und nicht in Curator.

Installation und der erste Lauf

Die Installation ist ein einzelner Befehl: pip install bespokelabs-curator. Danach folgt der übliche Weg über Umgebungsvariablen für die Anbieterschlüssel, die LiteLLM erwartet, also etwa OPENAI_API_KEY oder ANTHROPIC_API_KEY. Ein minimales Programm besteht aus einer dekorierten Funktion, die einen Prompt liefert, einem Aufruf dieser Funktion über die Eingabedaten und einem Aufruf, der die Ergebnisse zurückschreibt. Die Beispiele im Repository, darunter examples/poem_finetuning_example.py und der RAFT-Block unter examples/blocks/raft, sind die belastbarste Quelle für die konkrete Signatur, weil sich die API zwischen den Minor-Releases bewegt hat. Wer den Code aus älteren Blogposts übernimmt, sollte die Version prüfen: Die veröffentlichten Releases springen von v0.1.25 im Mai 2025 über v0.1.26 im Juli 2025 auf v0.1.27 im März 2026, und die Nummerierung im Changelog ist nicht durchgehend konsistent. Für Batch-Läufe ist zusätzlich relevant, dass Curator laut README Batch-Processing für OpenAI, Anthropic und kompatible APIs unterstützt. Ob ein Anbieter als Batch-Endpunkt verfügbar ist, entscheidet über die Kosten pro Token und über die Laufzeit, nicht über die Korrektheit der Pipeline.

Caching, Fehlerwiederaufnahme und was sie im Betrieb bedeuten

Caching ist in Curator kein Zusatz, sondern Teil des Ausführungsmodells. Sobald ein Prompt bereits beantwortet wurde, kann ein erneuter Lauf die Antwort wiederverwenden, statt Tokens zu bezahlen. Das ist bei iterativer Entwicklung der Unterschied zwischen einem bezahlbaren und einem teuren Nachmittag, hat aber eine Konsequenz, die in der Dokumentation leicht untergeht: Der Cache-Schlüssel hängt vom Prompt ab. Wer das Template ändert, ohne den Cache zu invalidieren, arbeitet möglicherweise mit Antworten aus der alten Fassung weiter. Die Fehlerwiederaufnahme ist ähnlich gelagert. Ein abgebrochener Lauf muss nicht bei null beginnen, sondern setzt dort an, wo er stehen geblieben ist. Beides zusammen macht lange Läufe über zehntausende Zeilen praktikabel. Es macht sie aber nicht deterministisch. Zwei Läufe mit demselben Code können unterschiedliche Ergebnisse liefern, wenn sich das Modell hinter dem Endpunkt geändert hat. Wer Reproduzierbarkeit braucht, muss den Cache als Artefakt behandeln und versionieren, nicht als Wegwerfdatei.

CodeExecutor und die Grenze zwischen Generieren und Ausführen

Seit Februar 2025 gibt es CodeExecutor, mit dem sich generierter Code ausführen lässt. Das README nennt vier Backends: local, dort intern als multiprocessing bezeichnet, außerdem Ray, Docker und e2b. Die Auswahl ist keine Geschmacksfrage. Das lokale Backend führt fremden, von einem Modell erzeugten Code im selben Prozessraum aus, was für Experimente auf einem Entwicklungsrechner üblich ist und für alles andere eine schlechte Idee. Docker und e2b sind die Optionen, wenn der Code nicht vertrauenswürdig ist. Ray ist die Option, wenn die Ausführung selbst verteilt werden soll. Wer Curator für Code-Generierung einsetzt, sollte sich bewusst machen, dass die Bibliothek damit zwei sehr verschiedene Dinge tut: Sie ruft Modelle auf und sie startet Prozesse. Die Sicherheitsanforderungen der zweiten Aufgabe sind deutlich höher als die der ersten, und Curator löst sie durch die Wahl des Backends, nicht durch eine eigene Sandbox.

Wo Curator das falsche Werkzeug ist

Die Bibliothek ist auf Python festgelegt. Wer Pipelines deklarativ beschreiben und ohne Python-Code betreiben will, findet hier keinen Ansatzpunkt. Ein zweiter Punkt betrifft den Umfang: Curator ist kein Trainingsframework. Das README verweist für das Feintuning auf Tinker und Fireworks AI, und die Beispiele zeigen, dass die Übergabe an ein externes Werkzeug erfolgt. Wer eine durchgängige Umgebung von der Datenerzeugung bis zum Checkpoint sucht, muss diesen Teil selbst zusammenbauen. Drittens ist die Qualitätskontrolle der erzeugten Daten nicht Teil des Versprechens. Curator sorgt dafür, dass Aufrufe robust, gecacht und strukturiert zurückkommen. Ob die Antworten korrekt, vielfältig oder frei von Verzerrungen sind, entscheidet das Prompt und das Modell. Die Dokumentation macht dazu keine Zusagen, und man sollte sie auch nicht hineinlesen. Ein vierter Punkt ist die Anbieterabhängigkeit: Die Batch-Unterstützung ist an konkrete Endpunkte gebunden, und das README nennt eine zeitlich befristete Promotionsaktion mit kluster.ai, die inzwischen beendet ist. Solche Aktionen sind kein Planungsfaktor.

Was LiteLLM direkt anders macht und wann Data-Juicer passt

Die naheliegende Alternative für die reine Inferenz ist LiteLLM ohne Curator. Der Unterschied liegt nicht im Modellzugriff, denn Curator nutzt LiteLLM ohnehin, sondern in der Orchestrierung. LiteLLM bietet eine einheitliche Schnittstelle über viele Anbieter und überlässt dem Aufrufer, wie Prompts gesammelt, Ergebnisse zwischengespeichert und Fehler behandelt werden. Wer zwanzig Zeilen verarbeitet, fährt damit einfacher. Wer hunderttausend Zeilen verarbeitet und nach einem Abbruch nicht alles neu bezahlen will, baut mit LiteLLM genau die Schicht nach, die Curator mitbringt. Für die Datenaufbereitung selbst, also Filterung, Deduplizierung, Umformung größerer Korpora, ist Data-Juicer die bekanntere Alternative. Dessen Ansatz ist eine konfigurationsgetriebene Pipeline aus Operatoren, oft über YAML beschrieben, mit Schwerpunkt auf der Verarbeitung vorhandener Datenmengen. Curator setzt dagegen auf Python-Code und auf die Erzeugung neuer Daten durch Modellaufrufe. Die beiden überschneiden sich bei der Nachbearbeitung, unterscheiden sich aber im Einstieg: Hier ein Decorator und ein Modellaufruf, dort eine Operator-Kette über ein bestehendes Korpus.

Wartung, Versionen und Lizenz

Der letzte Push auf den main-Branch stammt vom 2. September 2026, das Repository ist nicht archiviert. Die Release-Kadenz ist unregelmäßig: zwischen v0.1.25 und v0.1.26 liegen zwei Monate, zwischen v0.1.26 und v0.1.27 fast acht. Alle veröffentlichten Versionen tragen eine 0.x-Nummer, was bedeutet, dass die API sich zwischen Minor-Releases ändern kann. Wer Curator produktiv einsetzt, sollte die Version pinnen und beim Upgrade die Beispiele im Repository gegen den eigenen Code laufen lassen, nicht nur das Changelog lesen. Die Lizenz ist Apache-2.0, also eine permissive Lizenz mit einer ausdrücklichen Patentgewährung und den üblichen Pflichten zur Beibehaltung von Copyright- und Lizenzhinweisen sowie zur Kennzeichnung geänderter Dateien. Das ist keine Rechtsberatung; wer Curator in einem kommerziellen Produkt weiterverbreitet, sollte die Bedingungen selbst oder durch juristische Prüfung abgleichen. Ein Kostenfaktor, der leicht übersehen wird, ist nicht die Bibliothek, sondern die Inferenz. Curator ist kostenlos, die Tokens sind es nicht, und die Batch-Unterstützung ist der Hebel, mit dem sich dieser Posten halbieren lässt.

Redaktionelles Fazit

Curator passt zu Teams, die synthetische Datenpipelines in Python schreiben und dabei Batch-APIs, Caching und Fehlerwiederaufnahme nicht selbst bauen wollen. Wer nur einen einzelnen Prompt gegen ein Modell laufen lässt oder eine deklarative YAML-Pipeline mit SQL-Knoten braucht, ist mit LiteLLM direkt oder mit Data-Juicer besser bedient. Vor dem Einsatz ist zu prüfen, ob der eigene Anbieter in der LiteLLM-Anbindung als Batch-Endpunkt verfügbar ist, wie sich der Cache bei geänderten Prompt-Templates verhält und ob die Python-Version die Anforderungen von vLLM erfüllt.

Offizielle Quellen

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