Modal veröffentlicht Spindle: Open-Source-Trainingsserver mit Tinker-kompatibler API

Warum Modal eine Alternative zu Tinker gebaut hat

Nach Darstellung von Modal hat Tinker verändert, wie Post-Training funktioniert: Nutzer schreiben die Trainingsschleife in einfachem Python auf dem Laptop, und Tinker führt Forward- und Backward-Pass auf seinen GPUs aus. Modal bezeichnet sich als großen Fan, ebenso viele seiner Kunden. Wenn diese Teams jedoch skalieren, sprechen sie laut Modal immer wieder zwei Probleme an.

• Die Preisgestaltung pro Token wird teuer, sobald Teams Dutzende Experimente laufen lassen.
• Nutzer können nur die Modelle und Funktionen verwenden, die der Anbieter unterstützen will.

Modals Antwort: Eine gute API verdient mehr als eine Implementierung. Spindle lässt sich mit einem einzigen Befehl bereitstellen, spindle deploy, anschließend führen Nutzer ihr Trainingsskript gegen den Server aus. Da der Server dem Kunden gehört, lasse sich laut Modal alles darin anpassen. Die Standardkonfigurationen sind auf GPU-Auslastung optimiert, und das Unternehmen will weitere Optimierungen nachliefern.

Wo Spindle in Modals Stack einzuordnen ist

Modal erklärt, es decke nun den gesamten Post-Training-Stack ab. Teams, die keine eigene Trainingsschleife schreiben wollen, können Modal Dojo nutzen, eine Trainingsbibliothek, die das Unternehmen am Vortag veröffentlicht hat. Teams, die alles bis hinunter zum Cluster selbst steuern wollen, können On-Demand-Multi-Node-Cluster und Sandboxes für RL-Rollouts einsetzen.

Spindle liegt dazwischen. Nutzer schreiben die Schleife mit eigenen Losses, Rewards und Umgebungen, und Spindle übernimmt das verteilte Training. Unterstützt werden Full-Parameter-Training und Multi-LoRA für eine breite Palette offener Modelle sowie, so Modal, Hunderte gleichzeitige Trainingsläufe bei vergleichbarer Leistung und deutlich geringeren Kosten als bei Closed-Source-APIs.

Die Tinker-kompatible API stützt sich auf eine verteilte Control Plane für Anfrage- und Sitzungsverwaltung sowie auf Container-Autoscaling auf Basis von Modal Functions. Das Backend nutzt entkoppelte Trainer-Engines und Inferenz-Pools, die weder auf denselben Beschleunigern noch mit derselben Präzision laufen müssen. Modal Clusters planen Anfragen für große Modelle auf dynamisch verfügbaren, per RDMA verbundenen Knoten ein, ohne dass ein Cluster reserviert werden muss; Modal Volumes übernehmen das Checkpointing, Modal Servers liefern die Inferenz. Modal gibt außerdem an, beim Aufbau des Multi-LoRA-Trainings Verbesserungen an Miles und SGLang in die jeweiligen Upstream-Projekte eingebracht zu haben.

Paritätstests und Anpassbarkeit

Modal hat das Projekt Training Search Agents with GRPO von Jasper Lu nachgebaut, in dem gpt-oss-20b darauf trainiert wird, mehrstufige Suchen in SEC-Einreichungen durchzuführen. Das Team änderte lediglich BASE_URL und API_KEY, um auf Spindle zu verweisen. Laut Modal folgt Spindle sowohl dem eigenen Tinker-Rerun als auch den veröffentlichten Ergebnissen des Autors über alle Updates hinweg auf 0,01 Reward genau; Checkpoints bei den Updates 16, 20 und 24 schnitten bei 32 zurückgehaltenen Anfragen ähnlich ab.

Als Beispiel für die Anpassbarkeit nennt Modal das Training von Qwen3.5-9B auf Softwareaufgaben mit langem Zeithorizont, wofür nur eine Standardkonfiguration mit 16k Kontext vorlag. Zwei Konfigurationsänderungen hoben den Kontext auf 256k: max_context_length auf "256k" und context_parallel_size auf 4. Der Lauf dauerte rund 3 Tage auf unterbrechbaren GPUs und setzte nach dem Entzug von Maschinen automatisch von Checkpoints aus fort; 8 Clients teilten sich dieselben GPUs über Multi-LoRA.

Wie Multi-LoRA die Kosten senkt

Modal erläutert, dass agentisches RL die meiste Zeit mit dem Erzeugen von Rollouts verbringt, sodass die Trainer-GPUs im Leerlauf warten, während ein Client wartet. Je nach Workload war ein Trainer, der einen Client bediente, weniger als die Hälfte der Zeit ausgelastet. Spindles Multi-LoRA-Backend lässt mehrere Clients einen Trainer teilen, sodass der Trainingsschritt eines Clients läuft, während ein anderer auf Rollouts wartet.

In einem GRPO-Job mit einem 27B-Modell auf DAPO-math, mit 4×H200 für das Training und 12×B200 für die Inferenz, hielten vier sich abwechselnde Clients den Trainer zu etwa 88 % ausgelastet. Zusätzliche Clients senken die Kosten pro Lauf, verlangsamen aber jeden einzelnen Lauf leicht. Ab mehr als vier Clients beobachtete Modal in diesem Setup Trainer-Thrashing, das den Durchsatz pro Client deutlich verschlechterte.

Modals Vergleich mit Tinker bei identischen Skripten:

• DAPO-math (Qwen3.8-27B): 9,77 $ pro 1 Mio. Output-Tokens bei Tinker; 3,57 $ bei Spindle mit 2 Clients (−63 %) und 1,99 $ mit 8 Clients (−80 %).
• Suchagent, bis zu 40 Turns (gpt-oss-20b): 5,06 $ bei Tinker; 4,06 $ bei Spindle mit 4 Clients (−20 %) und 3,80 $ mit 8 Clients (−25 %).
• SWE-Gym, 256K Kontext (Qwen3.8-27B): 10,79 $ (geschätzt) bei Tinker; 6,17 $ bei Spindle mit 4 Clients (−43 %) und 5,82 $ mit 8 Clients (−46 %).

Was das für Teams bedeutet

Modals Fazit: Wer GPUs ausgelastet hält, etwa indem mehrere Experimente gleichzeitig laufen, erhält mit Spindle ein deutlich besseres Preis-Leistungs-Verhältnis als bei Closed-Source-APIs. Die genannten Zahlen stammen aus Modals eigenen Tests, nicht aus unabhängigen Benchmarks.

Spindle ist quelloffen und befindet sich noch in der Beta-Phase. Nutzer können es in ihrem Modal-Workspace bereitstellen, Issues für fehlende Modelle oder Funktionen eröffnen und Pull Requests für neue Modellkonfigurationen oder Leistungsoptimierungen einreichen. Für größere Beiträge lädt Modal dazu ein, Ideen in seinem Slack zu besprechen. Das Unternehmen arbeitet nach eigenen Angaben an Performance-Optimierungen, verbessertem Autoscaling, neuen Funktionen und Trainingsrezepten.