Die Implementierung von DSpark hat die Generierungsgeschwindigkeit pro Nutzer um 60–85 % im Vergleich zur vorherigen MTP-1 Produktionsbasislinie verbessert, als sie mit DeepSeek-V4 eingesetzt wurde.
Die Nutzung bestehender Modelle und GPU-Infrastrukturen kann durch verschiedene Methoden optimiert werden. Während Quantisierung, optimierte Kerne und verbesserte Inferenz-Engines hilfreich sind, bietet das spekulative Decoding besondere Vorteile, da es die Generierungsgeschwindigkeit steigern kann, ohne zusätzliche GPUs hinzuzufügen.
Ansätze des spekulativen Decodings
Es existieren mittlerweile mehrere Ansätze für spekulatives Decoding. Traditionelle Methoden verwenden ein kleineres Entwurfsmodell, während die Multi-Token-Vorhersage (MTP) mehrere zukünftige Tokens gleichzeitig vorhersagt. Techniken wie Medusa und EAGLE verbessern die Erstellung dieser Entwürfe, während DFlash Blöcke von Kandidaten-Tokens parallel generiert.
DSpark verfolgt einen anderen Ansatz, indem es paralleles Drafting mit einer leichten sequenziellen Komponente kombiniert. Dies ermöglicht es späteren Entwurfstokens, Informationen aus früheren Vorhersagen zu nutzen, während ein Großteil des Geschwindigkeitsvorteils der parallelen Generierung erhalten bleibt.
Funktionsweise von DSpark
DeepSeek’s DSpark verbessert den Entwurfsprozess des spekulativen Decodings. Parallele Entwurfsmodelle können einen gesamten Block von Tokens in einem Durchgang vorhersagen, was schnell ist, jedoch die Genauigkeit späterer Vorhersagen beeinträchtigen kann, da sie nicht vollständig von den zuvor vorhergesagten Tokens abhängen. DSpark kombiniert ein paralleles Rückgrat mit einer leichten sequenziellen Komponente, sodass spätere Entwurfspositionen Informationen aus früheren Vorhersagen einbeziehen können, während ein Großteil der Geschwindigkeit der parallelen Generierung erhalten bleibt.
Zusätzlich kann DSpark schätzen, wie wahrscheinlich es ist, dass Entwurfstokens die Verifizierung überstehen, wodurch Teile eines Blocks mit geringer Zuversicht verworfen werden können, anstatt Rechenressourcen für die Verifizierung zu verschwenden. Die Implementierung von DSpark in llama.cpp ermöglicht dies durch einen optionalen Vertrauensschwellenwert.
Implementierung und Tests
In dieser Anleitung wird DSpark mit dem Modell Qwen3-8B und llama.cpp getestet. Zunächst wird das Modell normal benchmarked, dann wird DSpark mit einem passenden Entwurfsmodell aktiviert, um die Generierungsgeschwindigkeiten zu vergleichen und zu ermitteln, wie viel Leistung mit der gleichen GPU gewonnen werden kann.
1. Aufbau von llama.cpp und Herunterladen der Modelle
Um die aktuelle DSpark-Implementierung mit CUDA-Beschleunigung zu nutzen, wird die neueste Version von llama.cpp aus dem Quellcode erstellt. Zunächst sind die erforderlichen Werkzeuge zu installieren:
- apt-get update
- apt-get install -y git cmake build-essential
Das offizielle Repository von llama.cpp wird dann geklont:
- cd /workspace
- git clone https://github.com/ggml-org/llama.cpp
Nach dem Klonen wird es mit aktivierter CUDA-Unterstützung gebaut:
- cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
- cmake –build llama.cpp/build –config Release -j –clean-first –target llama-cli llama-mtmd-cli llama-server llama-gguf-split
Dies erstellt die benötigten Binärdateien, um die Modelle auf der GPU auszuführen. Anschließend wird ein Verzeichnis für die Modell-Dateien erstellt:
- mkdir -p /workspace/models
Die GGUF-Dateien werden manuell mit dem Hugging Face CLI heruntergeladen, um die Downloadzeit nicht zu beeinflussen.
2. Messung der Basisgeschwindigkeit
Bevor DSpark aktiviert wird, ist es notwendig, eine Basislinie zu erstellen. Das Modell Qwen3-8B wird normal ausgeführt und die Generierungsgeschwindigkeit aufgezeichnet, um sie mit der spekulativen Decoding-Laufzeit zu vergleichen.
Nach dem Wechsel in das Verzeichnis llama.cpp wird Qwen3-8B ohne spekulatives Decoding ausgeführt:
- ./build/bin/llama-cli -m /workspace/models/Qwen3-8B-Q4_K_M.gguf -ngl all -fa on –temp 0 –top-k 1 -n 512 -st -p „Write a complete Python implementation of merge sort. Explain how it works and include its time and space complexity. /no_think“
Die Benchmark-Zusammenfassung, die von llama.cpp ausgegeben wird, enthält die wichtige Zahl für die Generierungsgeschwindigkeit: Generation: 95.0 tokens/s. Diese Zahl wird als Basislinie für die Messung des DSpark-Geschwindigkeitsvorteils verwendet.
3. Durchführung des Tests mit DSpark
Der Benchmark wird nun mit aktivem DSpark wiederholt. Ziel ist es, das Zielmodell, den Prompt, das Token-Limit und die Decoding-Einstellungen gleich zu halten, um den Effekt des spekulativen Decodings direkt zu messen.
Das gleiche Qwen3-8B-Modell wird nun mit dem DSpark-Entwurfsmodell ausgeführt:
- ./build/bin/llama-cli -m /workspace/models/Qwen3-8B-Q4_K_M.gguf -md /workspace/models/dspark-Qwen3-8B-Q8_0.gguf –spec-type draft-dspark –spec-draft-n-max 3 -ngl all -ngld all -fa on –temp 0 –top-k 1 -n 512 -st -p „Write a complete Python implementation of merge sort. Explain how it works and include its time and space complexity. /no_think“
Nach Abschluss des Laufs wird die Generierungsgeschwindigkeit aufgezeichnet: Generation: 124.9 tokens/s. Im Vergleich zur Basislinie ergibt sich folgendes Bild:
Vergleich der Konfigurationen
- Qwen3-8B Basislinie: 294.6 t/s (Prompt) | 95.0 t/s (Generierung)
- Qwen3-8B + DSpark: 88.0 t/s (Prompt) | 124.9 t/s (Generierung)
DSpark erhöht die Generierungsgeschwindigkeit von 95.0 auf 124.9 tokens/s, was einer Steigerung um etwa 31.5 % entspricht, während das gleiche Zielmodell und die GPU verwendet werden.
Fazit
Für die Beschleunigung lokaler LLMs bleibt MTP oft die praktischere Option, da sie einfacher ist und über eine breitere Modellunterstützung verfügt. Dennoch kann DSpark in Fällen, in denen eine bessere Entwurfsqualität zu mehr akzeptierten spekulativen Tokens führt, Vorteile bieten.
Die Einrichtung von DSpark in llama.cpp ist unkompliziert, jedoch ist die Unterstützung für Modelle derzeit noch begrenzt, da nur eine kleine Anzahl von Modellen kompatible DSpark-Entwurfsmodelle bietet. Da die Unterstützung in llama.cpp relativ neu ist, können je nach Modell und Build Bugs oder Instabilitäten auftreten. Aktuell ist DSpark eine interessante Beschleunigungstechnik, mit der experimentiert werden kann, während MTP die allgemein nützlichere Option für lokale Inferenz bleibt.
Quellen: kdnuggets
Bildquelle: KI generiert
Dieser Text wurde mit Hilfe von künstlicher Intelligenz in Zusammenarbeit mit unserer Redaktion erstellt.
🚀