DSpark ist eine von Novita veröffentlichte Methode des spekulativen Decodings. Wir haben produktionsorientierte DSpark-Spekulatoren für Kimi-K2.6 und Kimi-K2.7-Code trainiert und veröffentlicht, sie in vLLM integriert und evaluiert, wie ihr Ansatz des parallelen Block-Entwurfs skaliert, wenn das spekulative Fenster wächst.
Die Checkpoints sind darauf ausgelegt, die Kimi-Bereitstellung zu beschleunigen, ohne das Zielmodell zu verändern. Ein leichtes Draft-Modell schlägt einen Block von Kandidaten-Token vor, und das vollständige Kimi-Modell überprüft diese Kandidaten, bevor sie akzeptiert werden.
In unseren vLLM-Nightly-Evaluierungen mit Batch-Größe 1 erreichte DSpark mit num_speculative_tokens=7 eine durchschnittliche Durchsatzsteigerung von 2,55x für Kimi-K2.6 und 2,36x für Kimi-K2.7-Code. Mit zunehmendem spekulativem Fenster von n=3 auf n=7 wandelte DSpark die zusätzlichen Draft-Token konsistenter in Durchsatz um als die verfügbaren Eagle3-MLA-Baselines.
Die veröffentlichten Checkpoints sind:
- novita/kimi-k2.6-dspark für Kimi-K2.6
- novita/kimi-k2.7-code-dspark für Kimi-K2.7-Code
DSpark-Benchmark-Ergebnisse für Kimi-K2.6 und Kimi-K2.7-Code
Bei Batch-Größe 1 erhöhte sich der durchschnittliche Speedup von DSpark durch die Erhöhung von num_speculative_tokens von 3 auf 7 von 2,17x auf 2,55x für Kimi-K2.6 und von 2,12x auf 2,36x für Kimi-K2.7-Code. Die aufgeführten Eagle3-MLA-Baselines blieben im Durchschnitt nahezu flach.
| Zielmodell | Draft-Modell | avg. Speedup n=3 | avg. Speedup n=7 | Änderung gegenüber n=3 |
|---|---|---|---|---|
| Kimi-K2.6 | DSpark | 2,17x | 2,55x | +17,8 % |
| Kimi-K2.6 | Eagle3-MLA | 2,01x | 2,01x | +0,2 % |
| Kimi-K2.7-Code | DSpark | 2,12x | 2,36x | +11,7 % |
| Kimi-K2.7-Code | Eagle3-MLA | 2,04x | 2,05x | +0,3 % |
Diese Werte sind einfache, ungewichtete Durchschnitte der Benchmark-Speedups über GSM8K, MATH500, AIME, HumanEval, LiveCodeBench und SPEED-Bench Coding; sie sind nicht nach der Anzahl der Prompts gewichtet. Ein größeres Draft-Fenster verbessert den Durchsatz nicht automatisch: Die zusätzlichen Vorschläge müssen oft genug akzeptiert werden, um den Overhead von Drafting und Verifikation auszugleichen.
LiveCodeBench macht den Unterschied deutlich. Für Kimi-K2.6 stieg DSpark von 1,86x bei n=3 auf 1,87x bei n=7, während Eagle3-MLA von 1,67x auf 1,48x fiel. Für Kimi-K2.7-Code stieg DSpark von 1,75x auf 1,78x, während Eagle3-MLA von 1,69x auf 1,52x fiel. Bei SPEED-Bench Coding stieg DSpark von 2,19x auf 2,41x für Kimi-K2.6 und von 2,15x auf 2,31x für Kimi-K2.7-Code.
Evaluierungssetup: Batch-Größe 1, Online-vLLM-Nightly-Spekulatives-Decoding, Greedy-Decoding, TP=8, max_model_len=20000, CUDA-Graphen aktiviert und fuse_allreduce_rms=false. Höhere Token/s und Speedup sind besser. Batch-Größe 1 isoliert das Decodierungsverhalten einzelner Anfragen; Ergebnisse können unter kontinuierlichem Batching oder Produktionsworkloads mit höherer Parallelität abweichen. Vollständige Ergebnisse sind auf den Hugging-Face-Seiten für Kimi-K2.6 DSpark und Kimi-K2.7-Code DSpark verfügbar.
Warum DSpark das spekulative Decoding von Kimi verbessert
Unsere Checkpoints wenden DSpark auf Kimi-K2.6 und Kimi-K2.7-Code als Draft-Modelle für die vLLM-Bereitstellung an.
Relativ zum DFlash-Parallel-Drafting-Backbone fügt DSpark zwei leichte Heads hinzu: einen Markov-Logit-Bias-Head für die Intra-Block-Token-Abhängigkeit mit niedrigem Rang und einen positionsabhängigen Confidence-Head für die Akzeptanzvorhersage. DSpark schlägt den gesamten Draft-Block parallel vor und verwendet dann diese Heads, um die Draft-Qualität auf Blockebene zu verbessern und abzuschätzen, welche Positionen der Verifizierer wahrscheinlich akzeptieren wird.
Wir haben die Draft-Modelle mit einem angepassten Fork des Speculators-Frameworks von vLLM trainiert. Während des Trainings verbraucht der Draft versteckte Zustände, die von einem live in vLLM laufenden Kimi-Verifizierer gestreamt werden, und richtet den Spekulator auf das Verifiziererverhalten aus, dem er zur Bereitstellungszeit begegnen wird.
Unsere veröffentlichten Tabellen verwenden die verfügbaren Open-Source-Eagle3-MLA-Checkpoints als Draft-Modell-Baselines unter derselben Verifizierer- und Bereitstellungskonfiguration. Das zentrale Ergebnis ist, wie die Methoden mit einem größeren spekulativen Fenster skalieren: Von n=3 auf n=7 stieg der durchschnittliche Speedup von DSpark um 17,8 % für Kimi-K2.6 und 11,7 % für Kimi-K2.7-Code, während die aufgeführten Eagle3-MLA-Baselines im Durchschnitt nahezu flach blieben und sich bei beiden LiveCodeBench-Evaluierungen verlangsamten. Dies deutet darauf hin, dass DSpark die nützliche Draft-Qualität bei wachsendem Fenster effektiver bewahrt. Der Vergleich bezieht sich spezifisch auf die hier getesteten Checkpoints, den Batch-Größe-1-Workload und die Bereitstellungskonfiguration.
So stellen Sie Kimi-K2.7-Code mit DSpark in vLLM bereit
Die DSpark-Unterstützung erfordert derzeit einen vLLM-Nightly-Build. Für Kimi-K2.7-Code verwenden Sie die folgende Konfiguration für spekulatives Decoding:
uv pip install vllm --extra-index-url https://wheels.vllm.ai/nightly
vllm serve moonshotai/Kimi-K2.7-Code \
--tensor-parallel-size 8 \
--max-model-len 20000 \
--trust-remote-code \
--compilation-config='{"pass_config": {"fuse_allreduce_rms": false}}' \
--speculative-config '{
"model": "novita/kimi-k2.7-code-dspark",
"num_speculative_tokens": 7,
"method": "dspark"
}'
Für Kimi-K2.6 verwenden Sie dieselbe Konfiguration und setzen speculative_config.model auf novita/kimi-k2.6-dspark.
Bekannte Einschränkungen des Nightly-Builds: Das AOT-Scheduling von FA3 auf der Draft-Seite kann erfordern, dass fast_build=True beim Erstellen der Draft-Attention-Metadaten übergeben wird, und die CUDA-Graph-Erfassung kann auf einen FlashInfer-All-Reduce-Workspace-Größenfehler stoßen. Die getestete Konfiguration deaktiviert fuse_allreduce_rms; siehe die verlinkten Hugging-Face-Seiten für die aktuellen Workarounds.
DSpark ändert den Decodierungspfad, ohne das Ziel-Kimi-Modell zu verändern. Wir empfehlen, mit num_speculative_tokens=7 zu beginnen und dann den Durchsatz, die akzeptierte Länge, die Inter-Token-Latenz und die End-to-End-Latenz gegen repräsentativen Produktionsverkehr zu validieren. Die beste Konfiguration hängt von der Workload-Form, dem Batching und der Serving-Hardware ab.
