DeepSeek hat DSpark veröffentlicht, ein Open-Source-Framework für die spekulative Dekodierung, das nach Angaben des Unternehmens die Inferenz von Large Language Models (LLM) unter Live-Verkehr um bis zu 85 % beschleunigt, ohne dass es zu Einbußen bei der Ausgabequalität kommt. Wie in einem neuen Papier von DeepSeek-AI und der Peking-Universität beschrieben, läuft das System bereits innerhalb der DeepSeek-V4-Bereitstellungsinfrastruktur, die echte Benutzeranfragen verarbeitet.
Die Arbeit befasst sich mit einem der hartnäckigsten Probleme der Produktions-KI: Die Inferenz ist langsam, weil Modelle jeweils einen Text nach dem anderen generieren, wobei jeder Token einen vollständigen Durchgang durch das Netzwerk erfordert. Spekulative Dekodierung ist ein beliebtes Mittel, bei dem ein kleines, schnelles „Entwurfs“-Modell einen Block von Token vorschlägt, den das Modell in voller Größe dann in einem einzigen Durchgang überprüft und dabei das längste korrekte Präfix akzeptiert. Da die Verifizierung parallel und mathematisch exakt erfolgt, beschleunigt sie die Arbeit und behält gleichzeitig die Verteilung des Originalmodells bei. DSpark, das zusammen mit dem DeepSpec-Schulungsrepository auf GitHub veröffentlicht wurde, wurde schnell zu einer der meistdiskutierten KI-Engineering-Geschichten bei Hacker News. Weitere Informationen zu dieser Geschichte finden Sie in unserer aktuelle KI-Trends.
Warum die bestehende spekulative Dekodierung an ihre Grenzen stößt
Die jüngste spekulative Dekodierungsforschung hat sich in Richtung „paralleler Drafter“ bewegt, die einen ganzen Block von Kandidaten-Tokens in einem einzigen Vorwärtsdurchlauf generieren, wodurch die Draft-Latenz nahezu unabhängig von der Blockgröße wird. Das DSpark-Papier identifiziert zwei Engpässe, die diese Methoden daran gehindert haben, ihr Versprechen in großem Maßstab einzulösen.
Das erste ist ein Qualitätsproblem. Da parallele Drafter jede Position unabhängig vorhersagen, können sie nicht modellieren, wie Token innerhalb eines Blocks voneinander abhängen. Die Forscher zeigen, dass dies zu „multimodalen Kollisionen“ und einem schnellen Akzeptanzabfall an späteren Positionen in einem Entwurfsblock führt, ein Phänomen, das sie Suffixzerfall nennen. Je länger der Parallelblock ist, desto wahrscheinlicher ist es, dass sein Ende falsch ist.
Das zweite ist ein Problem auf Systemebene. Während die Generierung langer Draft-Blöcke kostengünstig ist, verschwendet die blinde Überprüfung jedes vorgeschlagenen Tokens knappe Batch-Kapazität für Token, die wahrscheinlich abgelehnt werden. Unter der hohen Parallelität eines realen Bereitstellungssystems variiert die ideale Verifizierungslänge entlang zweier Achsen: Strukturierte Anfragen wie Code weisen höhere Akzeptanzraten auf als offene Chats, und die Verifizierung zusätzlicher Token ist bei geringer Auslastung nahezu kostenlos, bei ausgelastetem System jedoch teuer.
Ein semi-autoregressives Entwurfsmodell
Um den Suffixverfall zu beheben, übernimmt DSpark eine von den Autoren so genannte semiautoregressive Architektur. Es verbindet ein rechenintensives paralleles Backbone, das viele Token gleichzeitig vorschlagen kann, mit einem leichten sequentiellen Modul, das eine blockinterne Abhängigkeitsmodellierung einführt. Das Design soll die hohe Kapazität paralleler Modelle an frühen Positionen mit der Suffix-Kohärenz traditioneller autoregressiver Drafter kombinieren, die Token nacheinander generieren und natürlich Abhängigkeiten respektieren.
Anhand kontrollierter Offline-Benchmarks, die mathematisches Denken, Codegenerierung und täglichen Chat umfassen, berichtet das Team, dass DSpark die akzeptierte Länge pro Verifizierungszyklus im Vergleich zu starken Baselines erheblich verbessert. Konkret heißt es in dem Papier, dass DSpark die akzeptierte Länge gegenüber dem autoregressiven Eagle3-Drafter um 30,9 %, 26,7 % und 30,0 % über drei Einstellungen und gegenüber dem parallelen DFlash-Drafter um 16,3 %, 18,4 % und 18,3 % verbessert.
Konfidenzgesteuerte, lastbewusste Überprüfung
Der neuartigere Teil von DSpark ist sein Ansatz zur Verifizierung. Anstatt eine feste Anzahl von Draft-Tokens für jede Anfrage zu verifizieren, formuliert DSpark die Auswahl der Verifizierungslänge als globales Durchsatzmaximierungsproblem. Es kombiniert kalibrierte Schätzungen darüber, wie lange das Präfix eines Entwurfs wahrscheinlich überleben wird, was das Papier als Überlebenswahrscheinlichkeiten bezeichnet, mit einem hardwarebewussten Planer, der die Engine-Auslastung in Echtzeit liest.
Das Ergebnis ist eine konfidenzgesteuerte Überprüfung: Das System passt dynamisch an, wie viele Token es für jede Anfrage überprüft, basierend auf dem Inhalt der Anfrage und dem aktuellen Status der Serving Engine. Bei geringer Auslastung kann es sich eine großzügige Überprüfung leisten, während es bei starker Parallelität das Überprüfungsbudget des Zielmodells nur auf Token mit der höchsten erwarteten Rendite umleitet und so den Durchsatzeinbruch vermeidet, der durch die Verwendung von Batch-Kapazität für Token mit geringer Wahrscheinlichkeit entsteht.
Ergebnisse unter Live-Benutzerverkehr
Die aussagekräftigsten Zahlen stammen aus der Produktion. Das Team implementierte DSpark innerhalb des DeepSeek-V4-Bereitstellungssystems, das den Live-Benutzerverkehr bedient, und verglich es mit der früheren Produktionsbasis des Unternehmens, einer Multi-Token-Vorhersagemethode namens MTP-1.
Dem Papier zufolge beschleunigt DSpark die Generierungsgeschwindigkeit pro Benutzer bei DeepSeek-V4-Flash kontinuierlich um 60 % bis 85 % und bei DeepSeek-V4-Pro um 57 % bis 78 % bei angepasstem Gesamtdurchsatz. Im Rahmen strenger Service-Level-Agreements, bei denen sich die Kapazität der Basislinie erheblich verschlechtert, was 120 Token pro Sekunde für Flash und 50 Token pro Sekunde für Pro entspricht, verringert DSpark den Überprüfungsaufwand, um einen stabilen Durchsatz aufrechtzuerhalten. Die Autoren argumentieren, dass durch die Überwindung dieser Leistungsklippe strikte Interaktivitätsstufen freigesetzt werden, die zuvor unerreichbar waren, wodurch die Pareto-Grenze des LLM-Dienstes effektiv nach außen verschoben wird.
Diese Unterscheidung ist für die Betreiber wichtig. Eine schnellere Geschwindigkeit pro Benutzer bei gleichem Gesamtdurchsatz bedeutet reaktionsschnellere Assistenten und Agenten-Workflows, ohne dass mehr Hardware gekauft werden muss, während die Einhaltung strenger Latenz-SLAs unter Last das ist, was eine Forschungsdemo von einem System unterscheidet, das auch bei Verkehrsspitzen standhalten kann.
Open-Source für die Community
DeepSeek veröffentlicht die trainierten DSpark-Checkpoints für die Vorschaumodelle DeepSeek-V4-Flash und DeepSeek-V4-Pro. Das zugehörige DeepSpec-Repository, das unter der freizügigen MIT-Lizenz veröffentlicht wurde, wird als vollständige, algorithmusgesteuerte Trainings- und Evaluierungscodebasis für die spekulative Dekodierung beschrieben. Es umfasst Dienstprogramme zur Datenvorbereitung, Entwurfsmodellimplementierungen, Trainingsskripte und Evaluierungsumgebungen und wird mit drei Entwurfsmodellalgorithmen geliefert: DSpark, DFlash und Eagle3.
Die Veröffentlichung senkt die Hürde für andere Labore und Infrastrukturteams, ihre eigenen Modellentwürfe mit einer standardisierten Pipeline zu trainieren und zu vergleichen. Die Evaluierungssuite von DeepSpec deckt etablierte Benchmarks ab, darunter GSM8K, MATH500, AIME 2025, HumanEval, MBPP, LiveCodeBench, MT-Bench, AlpacaEval und Arena-Hard-v2.
Warum es wichtig ist
Inferenzkosten und Latenz gehören heute zu den bestimmenden Einschränkungen der KI-Branche und beeinflussen alles, von der Aggressivität, mit der Unternehmen KI-Agenten einsetzen, bis hin zur Frage, ob kleinere Anbieter mit Hyperscalern hinsichtlich der Stückökonomie konkurrieren können. Der Beitrag von DSpark ist weniger ein einzelner neuer Algorithmus als vielmehr eine Demonstration, dass die sorgfältige gemeinsame Gestaltung des Entwurfsmodells und des Verifizierungsplaners sowie die Behandlung der Verifizierungslänge als Funktion des Live-Systemstatus in realen Bereitstellungen sinnvolle Fortschritte erzielen können.
Für DeepSeek, das seinen Ruf auf effizienten, offen veröffentlichten Systemen aufgebaut hat, ist DSpark ein weiterer Datenpunkt in einem Argument, das das Labor seit über einem Jahr vorbringt: dass Spitzenleistung bei der Bereitstellung durch intelligenteres Engineering und nicht nur durch reine Rechenleistung erreicht werden kann. Die Tatsache, dass die Gewinne im Live-Verkehr und nicht in einem synthetischen Benchmark gemessen wurden, erleichtert es anderen Betreibern, das Ergebnis ernst zu nehmen, da die Open-Source-Community das Papier verdaut und beginnt, die Zahlen zu reproduzieren.
---
Bleib vorne bei KIDie neuesten KI-Nachrichten, Analysen und Durchbrüche – alles an einem Ort.
Mehr KI-Nachrichten lesen →
