SpecForge: Spekulatives Decoding trainieren und direkt nach SGLang ausliefern
Train speculative decoding models effortlessly and port them smoothly to SGLang serving.
Auf einen Blick
- Was ist das?
- SpecForge ist ein Framework der SGLang-Gruppe zum Trainieren spekulativer Decoding-Modelle. Es vereinheitlicht Trainingseinstieg, Konfiguration und Auslieferung, verlangt aber eine klare Trennung zwischen Offline- und Online-Setups und koppelt den Betrieb an SGLang.
- Für wen ist es gedacht?
- Wer SGLang betreibt und spekulative Decoding-Modelle selbst trainieren will, findet in SpecForge einen einheitlichen Einstieg über specforge train und eine Konfigurationsstruktur, die Feature-Modus, Topologie und Serviceverantwortung im Pfad sichtbar macht. Wer stattdessen vLLM oder TensorRT-LLM einsetzt oder keinen Mooncake- und SGLang-Betrieb aufsetzen will, sollte nicht mit SpecForge beginnen, weil die Auslieferung ausdrücklich auf SGLang zielt.
- Darf ich es kommerziell nutzen?
- Ja. MIT 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. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- 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 SpecForge schließt
Spekulatives Decoding ist in der Theorie einfach: ein kleines Modell schlägt mehrere Token vor, das große Modell prüft sie in einem Durchlauf. In der Praxis scheitert die Einführung selten am Algorithmus, sondern an der Werkzeugkette. Das README benennt genau diesen Punkt: viele Open-Source-Projekte für spekulatives Decoding seien entweder schlecht gepflegt oder nicht direkt mit SGLang kompatibel. SpecForge ist die Antwort der SGLang-Gruppe darauf, ein Framework, das laut eigener Beschreibung regelmäßig gepflegt wird, ohne zusätzlichen Portierungsaufwand mit SGLang zusammenarbeitet und sowohl Online- als auch Offline-Training in einer Laufzeitumgebung abbildet.
Die Zielgruppe ist damit enger, als der Name vermuten lässt. Angesprochen sind Teams, die bereits eine SGLang-Serving-Umgebung betreiben und dort Durchsatz gewinnen wollen, ohne eine zweite, fremde Trainingspipeline zu pflegen. Wer nur einen fertigen Draft-Kopf sucht, ist hier falsch: SpecForge trainiert, es liefert keine vortrainierten Gewichte mit. Dafür gibt es den separaten SpecBundle-Katalog, auf den das README verweist.
Ein Einstiegspunkt, sieben Methoden
Die auffälligste Designentscheidung steht in der README recht unspektakulär: jeder unterstützte Ansatz nutzt denselben typisierten Trainingseinstieg. Es gibt keine methodenspezifischen Python-Skripte. Stattdessen wählt der Pfad der Konfigurationsdatei das Verfahren, die Topologie und die Frage, wer die beteiligten Dienste besitzt.
Das Beispiel aus dem README lautet:
specforge train --config examples/configs/online/disaggregated/external/qwen3-8b-eagle3-disaggregated.yaml
Der Pfad zerfällt in drei Aussagen. online/disaggregated beschreibt den Betriebsmodus, external die Zuständigkeit für die Dienste, und der Dateiname nennt Methode und Modell. Unterstützt werden laut Tabelle EAGLE3, P-EAGLE, EAGLE3.1, DFlash, DFlash2, Domino und DSpark, jeweils mit Verweisen auf die zugehörigen Paper. Als Optimierungen tauchen LK loss für EAGLE3 und D-PACE für DFlash und DFlash2 auf, während P-EAGLE, EAGLE3.1 und Domino in dieser Spalte leer bleiben.
Bemerkenswert ist der Umgang mit nicht unterstützten Kombinationen. Das README formuliert, sie würden bei der Konfigurationsvalidierung oder beim Zusammenbau des Laufs abgelehnt, statt auf einen älteren Trainer zurückzufallen. Das ist die richtige Wahl, denn ein stiller Fallback würde Ergebnisse produzieren, die niemand mehr einem Verfahren zuordnen kann.
Online, offline und die Frage, wem Mooncake gehört
Die Konfigurationshierarchie unterscheidet zwei Achsen, die leicht verwechselt werden. Die erste Achse ist online gegen offline. Offline-Training liest Daten aus einem vorbereiteten Korpus, Online-Training bezieht die Zielverteilung von einem laufenden Serving-System. Die zweite Achse betrifft die Betriebsverantwortung. In einem external-Rezept beaufsichtigt SpecForge laut README Produzent und Konsument auf einem Trainer-Knoten, während Nutzer oder Scheduler Mooncake und SGLang betreiben. Rezepte unter managed-local starten diese Dienste zusätzlich auf dem lokalen Host.
Für die Parallelität zieht SpecForge eine Grenze, die man kennen sollte. Die Online-Zielparallelität gehört zu SGLang, nicht zu SpecForge. Der Trainer verwaltet über den Schlüssel deployment.trainer seine eigene Datenparallelität sowie die Prozessgruppen für Offline-EAGLE3-USP. Wer erwartet, die Parallelität des Zielmodells aus der Trainer-Konfiguration heraus steuern zu können, wird an dieser Stelle umdenken müssen. Die Trennung ist plausibel, weil das Zielmodell im Online-Fall ohnehin von SGLang bedient wird, aber sie macht den Betrieb zu einer Zwei-System-Aufgabe.
Was die Beispielkonfigurationen abdecken
Die Menge der mitgelieferten Rezepte ist ungleich verteilt, und das sagt etwas über den Reifegrad der einzelnen Verfahren. EAGLE3 erscheint in drei Varianten: online external, offline colocated und offline disaggregated. DFlash ebenfalls in drei, darunter ein managed-local-Rezept mit der Bezeichnung 1server-dp7-disaggregated. Domino ist mit online external, offline colocated und einem managed-local-Multiserver-Rezept vertreten. DSpark bringt zwei Rezepte mit, online external und offline colocated.
Dünner sieht es bei den neueren Ansätzen aus. P-EAGLE und EAGLE3.1 erscheinen in der Tabelle jeweils nur mit einem einzigen Online-external-Rezept, und bei EAGLE3.1 ist der Dateiname qwen3-30b-a3b-eagle3.1-online.yaml nicht nach demselben Muster aufgebaut wie die übrigen. DFlash2 taucht ausschließlich als managed-local-Variante für ein 27B-Modell auf. Wer eines dieser Verfahren im Offline-Modus oder mit eigener Serviceverantwortung fahren will, findet dafür im gezeigten Material kein Rezept und muss die Konfiguration selbst herleiten. Das ist kein Fehler, aber ein Hinweis darauf, wo die Erprobung bisher stattgefunden hat.
Wo SpecForge die falsche Wahl ist
Die deutlichste Einschränkung steht implizit in der Projektbeschreibung selbst: SpecForge ist ein Ökosystemprojekt der SGLang-Gruppe und auf die Auslieferung nach SGLang zugeschnitten. Wer mit vLLM oder TensorRT-LLM serviert, bekommt von der engen Kopplung nichts und muss die Gewichte selbst übertragen. Der Satz aus der README, es sei kein zusätzlicher Portierungsaufwand nötig, gilt für SGLang und nur dort.
Der zweite Vorbehalt betrifft den Betrieb. Online-disaggregiertes Training setzt Mooncake und ein laufendes SGLang-System voraus. Ein Team ohne diese Infrastruktur kann zwar auf die Offline-Rezepte ausweichen, verliert dann aber genau den Vorteil, der Online-Training interessant macht, nämlich die Verteilung direkt vom Zielmodell. Drittens ist die Frage der Datenaufbereitung im gezeigten Material nicht beantwortet. Die README verweist auf eine Trainingsanleitung und eine Anleitung zum disaggregierten Training, nennt aber kein Werkzeug, das die Hidden States oder Feature-Verläufe erzeugt, die ein EAGLE3-Training benötigt. Wer diesen Schritt unterschätzt, plant zu knapp.
Schließlich gibt es keine abgerufenen Releases. Das Repository ist laut Metadaten nicht archiviert und der letzte Push datiert auf den 9. September 2026, aber ohne veröffentlichte Versionen muss man sich entscheiden, ob man dem Branch main folgt oder einen eigenen Commit pinnt. Für reproduzierbare Trainingsläufe ist das keine Nebensache.
Der Vergleich mit dem üblichen EAGLE-Trainingsskript
Die naheliegende Alternative ist das Referenz-Trainingsskript aus dem EAGLE-Projekt selbst. Der Unterschied liegt weniger im Verfahren als in der Betriebsform. Ein solches Skript trainiert einen Draft-Kopf gegen einen festen Datensatz und schreibt ein Checkpoint-Verzeichnis. Was danach kommt, bleibt dem Nutzer überlassen: Gewichte umbenennen, Architektur im Serving-Framework registrieren, Speicherlayout anpassen, Testlauf.
SpecForge verlagert diese Arbeit nach vorn, in die Konfiguration. Der Pfad examples/configs/online/disaggregated/external/qwen3-8b-eagle3-disaggregated.yaml benennt nicht nur, was trainiert wird, sondern auch, wie die Daten fließen und wem die Dienste gehören. Der Preis dafür ist Bindung. Ein eigenständiges Skript läuft auch ohne SGLang und Mooncake, ein SpecForge-Rezept im external-Modus nicht. Wer nur einmalig einen Draft-Kopf für eine andere Laufzeitumgebung braucht, fährt mit dem schlankeren Skript günstiger. Wer regelmäßig neue Zielmodelle einbindet und die Ergebnisse direkt ausliefern will, spart mit SpecForge die wiederkehrende Portierungsarbeit.
Pflegeaufwand, Lizenz und was vor dem ersten Lauf zu klären ist
SpecForge steht unter der MIT-Lizenz. Das ist eine permissive Lizenz und erlaubt die Nutzung, Veränderung und Weitergabe, auch in kommerziellen Zusammenhängen, sofern der Urheberrechtshinweis und der Lizenztext erhalten bleiben. Rechtlich verbindliche Aussagen sind das nicht; wer die trainierten Gewichte oder abgeleitete Werke weitergibt, sollte die Lizenzbedingungen der eingesetzten Basismodelle und der referenzierten Paper separat prüfen, denn die MIT-Lizenz des Frameworks sagt nichts über die Herkunft der Trainingsdaten oder der Zielmodelle aus.
Der Wartungsaufwand hängt an zwei Dingen. Erstens an der Kopplung an SGLang: ändert sich dort die Schnittstelle für spekulative Decoding-Modelle, muss SpecForge nachziehen, und der Nutzer mit ihm. Zweitens an der Methodenvielfalt. Sieben Verfahren mit jeweils eigenen Papern und teils eigenen Optimierungen bedeuten, dass nicht jede Kombination aus Methode und Topologie gleich gut gepflegt sein wird. Die Tabelle zeigt das an der Verteilung der Rezepte.
Vor dem ersten eigenen Lauf sind drei Dinge konkret zu prüfen. Ob das gewählte Paar aus Methode und Topologie in der Matrix in docs/sections/basic_usage/training.md steht. Ob die Beispielkonfiguration unter examples/configs zum eigenen Betriebsmodell passt, also managed-local oder external, weil davon abhängt, wer Mooncake und SGLang startet. Und ob die im README genannten Schlüssel wie deployment.trainer in der eigenen Version tatsächlich existieren, da ohne veröffentlichte Releases keine Versionsnummer als Bezugspunkt dient.
Redaktionelles Fazit
Wer SGLang betreibt und spekulative Decoding-Modelle selbst trainieren will, findet in SpecForge einen einheitlichen Einstieg über specforge train und eine Konfigurationsstruktur, die Feature-Modus, Topologie und Serviceverantwortung im Pfad sichtbar macht. Wer stattdessen vLLM oder TensorRT-LLM einsetzt oder keinen Mooncake- und SGLang-Betrieb aufsetzen will, sollte nicht mit SpecForge beginnen, weil die Auslieferung ausdrücklich auf SGLang zielt. Vor dem ersten eigenen Lauf ist zu prüfen, ob das gewählte Methoden- und Topologie-Paar in der Matrix aus docs/sections/basic_usage/training.md enthalten ist, ob die Beispielkonfiguration unter examples/configs zum eigenen Betriebsmodell passt (managed-local oder external) und ob die im Repository referenzierten Konfigurationsschlüssel wie deployment.trainer in der eigenen Version vorhanden sind.
Community-Notizen