SGLang 0.5.16 macht speculative decoding variabler: Mit DSpark wird die Größe des nächsten Verify-Fensters aus der Konfidenz des Draft-Modells abgeleitet, statt eine fixe Draft-Länge abzuarbeiten. Für Inference-Teams ist die wichtigere Nachricht jedoch: Der Release verändert zugleich Quantisierungs-Backends, Defaults und CLI-Flags.
Die am 25. Juli veröffentlichte Version ist damit kein Update, das man nur wegen einer neuen Durchsatz-Zahl einspielt. Sie bringt einen neuen Decoding-Pfad – und mehrere harte Kompatibilitätskanten.
DSpark: Verifikation folgt der Konfidenz
Beim speculative decoding erzeugt ein günstiger Draft-Mechanismus Tokens, die das Zielmodell anschließend verifiziert. DSpark arbeitet laut Release Notes semi-autoregressiv in Blöcken und bemisst das jeweilige Verify-Fenster anhand der eigenen Draft-Konfidenz, nicht anhand einer konstanten Draft-Länge. Aktiviert wird der Pfad mit --speculative-algorithm DSPARK; zusätzlich verlangt er SGLANG_RAGGED_VERIFY_MODE=compact.
„Sizes each verify window from the draft’s own confidence instead of a fixed draft length.“ – SGLang Release Notes
Das ist architektonisch interessant, weil sich Akzeptanzrate und Verifikationsarbeit dynamischer austarieren lassen. Die in den Notes genannte Zahl von 383,7 Token/s bei einer Accept Length von rund 5 bezieht sich ausdrücklich auf DeepSeek-V4-Pro, TP8 auf B300 bei Batch Size 1. Sie ist ein Hersteller-Messwert, keine allgemeine Erwartung für andere Modelle, Hardware oder Lastprofile.
Die konkreten Betriebsfolgen
- Weniger Scratch-Speicher für einen Spezialpfad: ReplaySSM Ring Spec-Verify soll bei einer Qwen3.5-35B-A3B-Referenz von 11,5 auf 1,8 GB Scratch-Speicher pro GPU kommen. Der Pfad ist standardmäßig aus und hat enge Voraussetzungen.
- Anderer Cache-Default:
UnifiedRadixTreeist nun Standard für SWA-, Mamba- und DSA-Modelle. Das ist eine Verhaltensänderung, die Cache-Hits und Regressionstests berührt. - Neue Kapazitätsoption für GLM-5.2: Der DSA Cache Layer Split verteilt Cache-Layer unter Prefill Context Parallelism über Ranks. SGLang nennt für seine Testkonfiguration 0,77 statt 0,20 GB KV-Speicher je Rank – etwa 74 Prozent weniger.
Warum Teams vor dem Upgrade die Launch-Kommandos prüfen sollten
Der Release entfernt die experimentellen Quantisierungspfade QServe (QoQ) W4A8 und FBGEMM FP8. Auch --fp4-gemm-backend cutlass und die integrierten NVFP4-JIT-Kernels fallen weg; NVFP4 GEMM benötigt nun FlashInfer. Dazu kommen Umbenennungen ohne deprecated Alias: --enable-deepep-waterfill wird zu --enable-waterfill, --optimistic-prefill-retries zu --optimistic-prefill-attempts.
# Erst in Staging: Konfiguration und Backends validieren
python -m sglang.launch_server \
--model-path <MODELL> \
--speculative-algorithm DSPARK \
--speculative-dspark-block-size <N>
# Für DSpark zusätzlich in der Laufzeitumgebung setzen
export SGLANG_RAGGED_VERIFY_MODE=compact
Die nüchterne Einordnung
DSpark ist ein ernsthafter Versuch, die starre Taktung des speculative decoding aufzubrechen. Die operative Priorität liegt aber vor dem Benchmark: vorhandene Images auf FlashInfer 0.6.14, entfernte Quantisierungspfade, geänderte Defaults und alle Launch-Flags testen. SGLang dokumentiert außerdem einen bekannten Temperatur-0-Nichtdeterminismus für einen spezifischen DP-Attention-/breakable-prefill-CUDA-Graph-Pfad. Für deterministische Workloads ist das kein Fußnotenthema.
Empfehlung: 0.5.16 zunächst als kontrolliertes Staging-Upgrade behandeln. Erst Kommandos und Quantisierungs-Backends migrieren, dann DSpark gegen das eigene Modell-, Batch- und Latenzprofil messen.
Schreibe einen Kommentar