Alte Idee mit neuen Verbesserungen
Die Verbesserungen beim Durchsatz erreicht DSpark dadurch, dass das spekulative Modell deutlich kleiner und damit schneller ist als das reguläre Modell. Die Idee der spekulativen Decodierung ist nicht neu, die Veröffentlichung von Deepseek vergleicht mit den existierenden Implementierungen Eagle3 und DFlash. DSpark schneidet hier besser ab, da die Forscher im Kern zwei Optimierungen vorgenommen haben.
Die beiden Referenzen stehen gleichzeitig für zwei unterschiedliche Paradigmen: Eagle3 ist autoregressiv, hier bezieht sich auch jeder geratene Token auf seinen Vorgänger. Genau das macht die Stärke autoregressiver Modelle beim Erzeugen von Text aus, es macht sie aber auch langsam. DFlash rät daher die Tokens parallel, was deutlich schneller geht. Die Laufzeit steigt hier kaum, wenn mehr Tokens geraten werden.
DSpark geht einen Zwischenweg: Zunächst werden parallel Tokens geraten, anschließend laufen diese aber noch durch ein kleines autoregressives Modell. Dieses kann die Tokens noch einmal ändern, wenn eines nicht zum Vorgänger passt. Aufgrund der geringen Modellgröße wirkt sich dies kaum auf die Laufzeit aus, gleicht aber den Nachteil der parallelen Erzeugung zumindest teilweise aus.
Drei Modelle raten mit
Eine zentrale Frage spekulativer Decoder ist: Wie viele Tokens lohnt es zu erzeugen? Generell gilt, dass die Wahrscheinlichkeit, dass ein geratener Token vom realen Modell akzeptiert wird, mit der Länge der Sequenz sinkt.
Wie stark dieser Effekt ist, hängt aber von der konkreten Nutzung ab. Beim Generieren von Code etwa funktioniert die spekulative Decodierung sehr gut, da die Struktur sehr vorhersehbar ist. Bei klassischen Chats hingegen werden im Mittel deutlich weniger Tokens akzeptiert. Das ist besonders ein Problem, wenn das System an der Auslastungsgrenze betrieben wird, also ohne SLA.
Die Überprüfung der geratenen Tokens erfolgt zwar parallel, indem sie als Teil eines Batch durch das Modell laufen. Hier können sie aber Tokens anderer Nutzer den Platz wegnehmen – ärgerlich, wenn dann am Ende der Großteil der geratenen Tokens verworfen werden muss. Deshalb haben die Forscher noch ein drittes Modell implementiert, das für jeder geratene Token die Wahrscheinlichkeit schätzt, dass es akzeptiert wird. Unterschreitet die einen Schwellwert, wird die Sequenz bei diesem Token abgeschnitten. Lediglich der Teil mit hoher Akzeptanzwahrscheinlichkeit wird noch vom großen Modell geprüft.
Hier entschieden sich die Forscher für eine einfache Markow-Kette. Sie untersuchten auch ein rückgekoppeltes neuronales Netz (RNN), das trotz höheren Aufwands aber nur marginale Verbesserungen erreichte. Daneben entscheidet noch ein Scheduler anhand der aktuellen Hardware-Auslastung, wie viele Tokens weitergegeben werden: Je höher die Auslastung, desto kürzer die Sequenzen, um möglichst wenig Aufwand auf falsche Vorhersagen zu verschwenden.
Code und Parameter können heruntergeladen werden
Nach eigenen Angaben nutzt Deepseek DSpark bereits mit Deepseek-V4 im Produktivbetrieb. Bei SLAs habe man die Token-Rate pro Nutzer zwischen 60 und 85 Prozent bei der Flash-Variante sowie 57 und 78 Prozent beim Pro-Modell steigern können. Checkpoints beider Varianten hat Deepseek zudem bei Huggingface hochgeladen. Das Trainings-Framework ist unter dem Namen Deepspec bei Github zu finden(öffnet im neuen Fenster) und steht unter MIT-Lizenz. Für llama.cpp existiert bereits ein Pull Request(öffnet im neuen Fenster).
- Anzeige Hier geht es zu Künstliche Intelligenz: Wissensverarbeitung bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.