Qwen3.8-27B auf einem DGX Spark: 38 Token/s mit vLLM

Seit dem 20.10.2026 läuft Qwen3.8-27B auf einer der vier NVIDIA DGX Spark in unserem Büro, auf derselben Maschine wie Nemotron 3.5 Bolt. Qwen3.8-27B ist ein dichtes Modell: Für jedes erzeugte Token werden alle 27 Milliarden Parameter gelesen. Auf einer Maschine, deren Engpass die Speicherbandbreite ist, macht es das von Haus aus langsam.

Wir haben dasselbe Modell unter Ollama und unter vLLM gemessen, jeweils mit und ohne spekulative Dekodierung, unter vLLM zusätzlich mit zwei verschiedenen Draft-Modellen. Bei gleichen Einstellungen ist vLLM 1,5- bis 1,8-mal so schnell wie Ollama. Noch mehr macht das Draft-Modell aus, bis zum Faktor drei, und welches gewinnt, hängt davon ab, wie viele Anfragen gleichzeitig kommen.

Ergebnisse

Ollama lief auf einer zweiten DGX Spark mit gleicher Hardware, vLLM auf der Maschine, die das Modell heute ausliefert. Alle Werte vom 21.10.2026.

Drei Dinge fallen auf:

1. Beide Engines brauchen ein Draft-Modell, um schnell zu sein. Ollama liefert dieses Modell mit eingeschalteter MTP-Schicht aus. Das haben wir erst beim Blick ins Server-Log bemerkt.
2. Mit derselben Art Draft-Modell (MTP) ist vLLM bei einer einzelnen Anfrage 1,8-mal so schnell wie Ollama.
3. DFlash2 ist am schnellsten für eine Anfrage, MTP für mehrere gleichzeitig: Bei 4 oder 8 gleichzeitigen Anfragen liegt MTP um 27 % bzw. 12 % vor DFlash2.

Wir betreiben heute DFlash2, weil unsere Last gering ist und meist nur eine Anfrage gleichzeitig läuft. Ob wir auf MTP wechseln, entscheidet ein Lastprotokoll (siehe Ende des Artikels).

Wie wir messen

Alle Werte stammen aus unserem eigenen Benchmark-Skript. Es läuft direkt auf der Maschine gegen den OpenAI-kompatiblen Endpunkt von vLLM bzw. Ollama, nicht über unser Gateway. Das Skript ist hier veröffentlicht: bench.py

• Die Anfragen werden gestreamt. Reasoning-Token und Antwort-Token werden gemeinsam gezählt.
• Ausgabe: bis zu 512 Token pro Anfrage, temperature 0, Denkphase aktiv. Nach 512 Token denkt das Modell noch, die Werte beschreiben also Reasoning-Ausgabe.
• Eingabe: zehn kurze deutsche Prompts aus unserem echten Betrieb (Code, SQL, Fehlerdiagnose, Erklärungen). Ein Lauf mit einer Anfrage nutzt den ersten Prompt, ein Lauf mit 4 oder 8 gleichzeitigen Anfragen die ersten vier oder acht.
• Einzelne Anfrage: reine Decode-Rate, (erzeugte Token − 1) / (Zeit des letzten Chunks − Zeit des ersten Chunks).
• Gleichzeitige Anfragen: alle erzeugten Token geteilt durch die Gesamtdauer, Prefill eingeschlossen.
• Jede Konfiguration lief mindestens dreimal, angegeben ist der Median.
• Um das Draft-Modell von Ollama abzuschalten, bietet der OpenAI-Endpunkt keine Option. Für diese Variante haben wir die native Ollama-API mit draft_num_predict: 0 und derselben Zählweise genutzt. Ein Kontrolllauf mit eingeschaltetem Draft-Modell ergab auf beiden Schnittstellen dasselbe (native Schnittstelle mit Draft-Modell: 16,1, 15,7 und 14,9 Token/s, gegenüber 16,2 Token/s über den OpenAI-Endpunkt; im Fenster der nativen Messung kamen zwei Anfragen von außen).
• Leerlauf: Für jeden Lauf haben wir in den Server-Logs die Anfragen von außen gezählt. Bei den vLLM-Läufen gab es keine. Bei Ollama: Die zweite Spark beliefert über unser Gateway auch andere Modelle, deshalb haben wir die Anfragen von außen je Lauf protokolliert: Vier der fünf Einzelläufe mit MTP hatten keine, einer drei (16,3 Token/s, ohne erkennbaren Einfluss), die übrigen Reihen zwei bis vier je Messfenster. Für den Wert ohne Draft-Modell haben wir Einzelläufe wiederholt, bis fünf ganz ohne Anfrage von außen gelaufen waren: 8,0 bis 8,1 Token/s, derselbe Median wie zuvor (Läufe mit Fremdanfragen: 7,6 bis 8,0). Der GLiNER-Dienst auf dieser Maschine bekam keine Anfrage; clef-flash bleibt dort geladen und erhielt nur seine regelmäßige Halteanfrage.

Ollama gegen vLLM

Mit Standardeinstellungen bearbeitet Ollama eine Anfrage nach der anderen. Das Server-Log zeigt n_seq_max = 1. Vier gleichzeitige Anfragen stehen also in einer Schlange, und der Gesamtdurchsatz bleibt beim Wert für eine Anfrage. Mit OLLAMA_NUM_PARALLEL=4 in einer getrennten Ollama-Instanz lud der Server das Modell trotzdem mit n_seq_max = 1, vermutlich weil MTP nur einen Platz zulässt; im Quellcode geprüft haben wir das nicht. Unser Versuch, auf dieser Instanz vier gleichzeitige Anfragen zu messen, wurde vom Watchdog beendet, als die Produktivmodelle auf derselben Maschine nachluden.

Ohne Draft-Modell ist vLLM 1,5-mal so schnell (12,3 gegenüber 8,1 Token/s) und nutzt 79 % der Bandbreite, Ollama 47 %. Mit MTP zieht vLLM deutlich davon, obwohl Ollama mehr Token pro Schritt vorschlägt (4 gegenüber 3) und mehr davon angenommen werden (3,19 gegenüber 2,62 Token pro Schritt). Bezogen auf die Schritte des Hauptmodells schafft Ollama 8,1 Schritte pro Sekunde ohne und 5,1 mit MTP, vLLM 12,3 und 10,9. Das Vorschlagen kostet Ollama also deutlich mehr Zeit pro Schritt. So lesen wir die Zahlen; Ollama haben wir nicht im Profiler untersucht.

Was die Speicherbandbreite erlaubt

Eine DGX Spark bewegt etwa 273 GB/s. Für jeden Schritt muss das Hauptmodell alle Gewichte einmal lesen, außer der Embedding-Tabelle, aus der pro Token nur eine Zeile gelesen wird. Wir haben die Tensorgrößen in beiden Dateien zusammengezählt:

Der NVFP4-Checkpoint ist pro Schritt größer, weil die Projektionen der linearen Attention-Schichten in FP8 gespeichert sind und nicht in 4 Bit. Ohne Draft-Modell ist jedes Token ein Schritt, keine der beiden Engines kommt auf dieser Maschine also über etwa 15 bis 17 Token/s. Alles darüber stammt aus spekulativer Dekodierung: mehrere Token pro Schritt.

Der Bild-Encoder (0,9 GB) und die MTP-Schicht sind nicht mitgezählt. Der Bild-Encoder läuft nur bei Bildern, die MTP-Schicht nur zum Vorschlagen.

Das Draft-Modell entscheidet

Bei spekulativer Dekodierung schlägt ein kleines, schnelles Modell mehrere Token im Voraus vor. Das Hauptmodell prüft alle in einem Durchgang und behält die, die es selbst erzeugt hätte. Weil ein Durchgang des dichten Hauptmodells gleich viel kostet, ob es ein Token prüft oder mehrere, ist jedes zusätzlich angenommene Token fast umsonst.

(Beides unter vLLM.) DFlash2 kommt auf mehr Token pro Schritt und gewinnt deshalb, wenn nur eine Anfrage läuft. Es schlägt aber für jede Anfrage acht Token vor. Mit mehreren Anfragen im Batch kosten diese Vorschläge Rechenzeit, die dem Batch selbst dann fehlt. MTP schlägt weniger Token vor und skaliert besser. So lesen wir die Zahlen; im Profiler nachgeprüft haben wir es nicht.

Zum Vergleich: Zwei Community-Berichte mit vLLM und MTP auf einer DGX Spark nennen 23 bis 26 Token/s im Chat-Betrieb (siehe Quellen), nahe an unseren 28,6.

Beide Verfahren sind so gebaut, dass sie die Ausgabe nicht verändern. Die Modellkarte von DFlash2 gibt an, dass die Ausgabe bei Greedy-Decoding exakt der des Hauptmodells entspricht. Selbst geprüft haben wir das nicht.

Lange Eingaben

Dieselben drei vLLM-Konfigurationen, ein gemeinfreier deutscher Text aus Project Gutenberg (Goethe, „Die Leiden des jungen Werther“ und „Faust“) auf die Ziellänge gekürzt, die Bitte um eine Zusammenfassung in drei Sätzen, Denk-Budget 64, bis zu 256 Ausgabe-Token, zufälliger Anfang je Anfrage, damit kein Prefix-Cache helfen konnte:

DFlash2 bei 8.000 und 32.000 Token: Median aus drei Läufen. Alle anderen Zellen: je ein Lauf.

Der Prefill schafft bei 8.000 Token etwa 2.600 Token pro Sekunde und sinkt bei 100.000 auf etwa 1.400. Lange Eingaben verringern auch den Gewinn durch das Draft-Modell: Das Decode-Tempo mit DFlash2 fällt von 38,0 Token/s bei kurzen Prompts auf etwa 20. Wir vermuten, dass die Attention über den langen Kontext einen wachsenden Teil jedes Schritts ausmacht und das Draft-Modell diesen Teil nicht verkürzen kann. Gemessen haben wir das nicht.

Speicher: was das Budget bedeutet, und zwei Fallen

Eine DGX Spark hat 128 GB Speicher, den sich CPU und GPU teilen; CUDA sieht davon 121,7 GiB. Läuft er voll, kommt keine Fehlermeldung, die Maschine friert ein. Jede neue Konfiguration startet bei uns deshalb beim ersten Mal unter einem Watchdog, der den Container binnen einer Sekunde beendet, sobald der verfügbare Speicher unter 12.000 MiB fällt. In diesem Test hat er einmal eingegriffen.

--gpu-memory-utilization beschreibt die Spitze beim Start, nicht den dauerhaften Verbrauch. Das vLLM-Log dieses Builds schlüsselt es auf:

Die beiden Anteile ergeben zusammen 101 GiB, nvidia-smi zeigte im Betrieb aber 85,3 GiB für beide Prozesse. Etwa 12 GiB der Differenz sind die Zwischenergebnisse, die nur beim Start existieren. Die übrigen 3,6 GiB sind vermutlich Speicher außerhalb von PyTorch, den nvidia-smi nicht dem Prozess zuordnet; im Detail nachverfolgt haben wir das nicht. Auf einer anderen Maschine mit vLLM 0.28 stimmten Budget und Messung auf 1 GiB überein. Ob vLLM die Abrechnung zwischen diesen Versionen geändert hat, haben wir nicht dokumentiert gefunden. Für den Betrieb heißt das: Ein Neustart braucht diese Spitze wieder, der freie Speicher im Betrieb ist also nicht vollständig Reserve.

Erste Falle: --gpu-memory-utilization deckt die MTP-Schicht nicht ab. Mit MTP und 0,47 fiel der verfügbare Speicher beim Anlegen des KV-Caches von 17,6 auf 10,2 GiB, und der Watchdog beendete den Container. Mit DFlash2 und denselben 0,47 blieben 22 GiB verfügbar. Den MTP-Lauf haben wir mit 0,42 wiederholt; das Minimum lag dann bei 15,7 GiB. Dasselbe Verhalten hatten wir vorher schon mit Qwen3.6-35B auf einer anderen Maschine gesehen.

Zweite Falle: zwei Modelle auf einer Maschine. Starteten beide vLLM-Dienste gleichzeitig, rechnete jeder beim Bemessen des KV-Caches den wachsenden Speicher des anderen als eigenen Verbrauch mit. Bolt kam auf −52 GiB verfügbaren KV-Speicher, Qwen3.8-27B auf 8,4 statt 13,3 GiB, und beide brachen ab. Unsere systemd-Dienste warten deshalb vor dem Start, bis der andere Dienst entweder nicht läuft oder fertig geladen ist (Skript unten).

Auch der Kontext von 262.144 Token braucht Platz: Bei einem Anteil von 0,35 startete vLLM nicht, weil eine Anfrage in voller Länge 11,9 GiB KV-Cache braucht und nur 8,1 GiB übrig waren. Heute läuft das Modell mit 0,47 und 22,5 GiB KV-Cache, Platz für etwa 1,9 Anfragen in voller Länge. Verfügbar auf der Maschine mit beiden Modellen im Betrieb am 21.10.: 21,5 GiB.

Das Denk-Budget ist Pflicht

Qwen3.8-27B denkt nach, bevor es antwortet. Wir haben dieselben zehn deutschen Prompts mit max_tokens 2048 und temperature 0 geschickt:

Ohne Budget verbrauchte das Nachdenken in 8 von 10 Fällen den ganzen Token-Vorrat. Mit 768 bekam jeder Prompt eine Antwort, 5 von 10 wurden bei max_tokens 2048 aber noch abgeschnitten. Im Betrieb schickt unser Gateway das Budget von 768 mit und setzt kein max_tokens; das entscheidet der Aufrufer, und ohne Wert lässt vLLM Ausgaben bis zum Rest des Kontexts zu. Die Sprache haben wir mit einer einfachen Funktionswort-Heuristik auf den ersten 300 Zeichen bestimmt; die Spalte ist daher als Tendenz zu lesen. Dieser vLLM-Build nimmt das Feld auch ohne --reasoning-config an; geprüft haben wir das mit einer einzelnen Anfrage.

Unsere Konfiguration

Das Image ist eugr/spark-vllm:nightly-20261016, ein vLLM-Entwicklungsstand für die DGX Spark (vLLM 0.32.0rc1.dev301, FlashInfer 0.7.2). Der Startbefehl folgt dem Community-Rezept qwen3.8-27b-nvfp4-dflash2 aus dem Repository eugr/spark-vllm-docker, angepasst auf eine einzelne Maschine und ein geteiltes Speicherbudget.

vLLM selbst hat keine Authentifizierung. Nie direkt ins Internet stellen. Bei uns sitzt ein Inferenz-Gateway mit API-Schlüsseln davor, und der vLLM-Port ist nur aus dem internen Netz erreichbar. Das Beispiel bindet an 127.0.0.1. Das passt, wenn das Gateway auf derselben Maschine läuft. Läuft es auf einem anderen Rechner, kommt die Adresse der internen Schnittstelle dazu (-p <interne IP>:8004:8004), und eine Firewall lässt nur das Gateway durch. So machen wir es.

docker run --name vllm-qwen27b --gpus all --ipc host --shm-size=16g --ulimit memlock=-1 \
  -p 127.0.0.1:8004:8004 \
  -v /srv/hf-cache:/root/.cache/huggingface -e HF_HUB_OFFLINE=1 \
  eugr/spark-vllm:nightly-20261016 \
  vllm serve nvidia/Qwen3.8-27B-NVFP4 --revision 482ca0f3832238542f8f5295dde86b5f22711d80 \
    --served-model-name qwen3.8-27b \
    --host 0.0.0.0 --port 8004 --tensor-parallel-size 1 --trust-remote-code \
    --kv-cache-dtype fp8 --gpu-memory-utilization 0.47 \
    --max-model-len 262144 --max-num-seqs 8 --max-num-batched-tokens 4096 \
    --enable-chunked-prefill --async-scheduling --enable-prefix-caching \
    --speculative-config '{"method":"dflash","model":"z-lab/Qwen3.8-27B-DFlash2","revision":"50307d4c4cde6860d4eee73e2547cd786fe8e8a4","num_speculative_tokens":8,"draft_tensor_parallel_size":1}' \
    --load-format instanttensor \
    --reasoning-parser qwen3 --tool-call-parser qwen3_xml --enable-auto-tool-choice

Anmerkungen:

• Für MTP statt DFlash2 die Speculative-Config durch '{"method":"mtp","num_speculative_tokens":3}' ersetzen und den Speicheranteil senken (wir nutzen 0,42), weil die MTP-Schicht nicht mitgerechnet wird.
• Qwen3.8-27B hat unter seinen 64 Schichten 48 mit linearer Attention (Gated DeltaNet). Ein offenes vLLM-Issue zu Abstürzen genau in diesem Pfad auf dem GB10 (#54173) betrifft uns damit grundsätzlich, und wir laufen mit Prefix-Caching. Bisher lief der Dienst etwa einen Tag ohne Absturz, mit 46 echten Anfragen und einigen Hundert Benchmark-Anfragen. Das belegt noch nichts: Auf einer anderen Maschine kamen Abstürze in ähnlichem Aufbau fünfmal in sechs Tagen. Prefix-Caching lohnt sich bei Gesprächen: Eine Folgefrage auf 32.000 Token Kontext bekam ihr erstes Token nach 0,5 s statt nach 14,5 s. Der FP8-Kernelfehler auf dem GB10, der einen anderen unserer Dienste abstürzen ließ (FlashInfer #3566), betrifft dieses Image nicht: FlashInfer 0.7.2 nimmt cuDNN auf diesem Chip aus der automatischen FP8-Auswahl, was unser Log bestätigt.
• Modell und Draft-Modell sind auf eine Revision festgelegt, und HF_HUB_OFFLINE=1 verhindert, dass beim Neustart still neuere Gewichte geladen werden.
• Kein --rm: Scheitert ein Start, bleiben Container und Log erhalten.
• --host 0.0.0.0 bezieht sich auf das Innere des Containers. Was von außen erreichbar ist, entscheidet -p.

Die Wartebedingung, die verhindert, dass zwei vLLM-Dienste gleichzeitig starten, läuft im systemd-Dienst jedes der beiden als ExecStartPre, mit dem jeweils anderen Dienst als Argument:

#!/bin/bash
# Wait until another vLLM service is either not running or fully loaded.
# Usage: wait-for-vllm.sh <container> <port> <systemd-unit> [max_seconds]
NAME="$1"; PORT="$2"; UNIT="$3"; MAX="${4:-1200}"; t=0
while [ "$t" -lt "$MAX" ]; do
  st=$(docker inspect -f '{{.State.Status}}' "$NAME" 2>/dev/null) || st=missing
  curl -sf -m 3 "http://127.0.0.1:$PORT/v1/models" >/dev/null && exit 0
  # Unit active but container not there yet: it is just starting, keep waiting.
  [ "$st" != running ] && ! systemctl is-active --quiet "$UNIT" && exit 0
  sleep 10; t=$((t+10))
done
# Timeout: do not start next to an instance that is still loading.
# With Restart=always, systemd tries again after RestartSec.
exit 1

Bei Zeitüberschreitung meldet das Skript bewusst einen Fehler. Trotzdem zu starten, brächte genau den Fehler zurück, den es verhindern soll. Mit Restart=always versucht systemd es erneut. Unsere Dienste erlauben 5 Starts innerhalb von 10 Minuten (StartLimitIntervalSec=600, StartLimitBurst=5, wie auf unseren anderen Maschinen); bei 20 Minuten Wartezeit je Versuch fällt höchstens ein Versuch in dieses Fenster, der Dienst wird also nie gesperrt.

Was wir anders machen würden

1. Vor einem Engine-Vergleich das Server-Log lesen. Wir hatten Ollama mit Draft-Modell gegen vLLM ohne verglichen, weil Ollama MTP standardmäßig einschaltet.
2. Zuerst die Variante ohne Draft-Modell messen. Ohne diese Basis hätten wir der Engine einen Gewinn zugeschrieben, der aus der spekulativen Dekodierung kommt.
3. Draft-Modelle unter der erwarteten Last testen, nicht nur mit einer Anfrage. Der Sieger bei einer Anfrage verlor bei vier.
4. Speicher für MTP getrennt einplanen und Platz für die Spitze beim Start lassen.
5. Nie zwei vLLM-Instanzen gleichzeitig auf einer Maschine mit Unified Memory starten.

Offene Frage: DFlash2 oder MTP

Seit dem 21.10. halten wir alle fünf Sekunden fest, wie viele Anfragen das Modell gerade bearbeitet. Wächst der Anteil der Zeit mit vier oder mehr gleichzeitigen Anfragen, wechseln wir auf MTP. Die Schicht steckt bereits im Checkpoint, der Wechsel kostet einen Neustart.

Quellen

• Basismodell Qwen3.8-27B (Apache 2.0): https://huggingface.co/Qwen/Qwen3.8-27B
• NVFP4-Checkpoint von NVIDIA: https://huggingface.co/nvidia/Qwen3.8-27B-NVFP4
• Draft-Modell DFlash2 (Apache 2.0): https://huggingface.co/z-lab/Qwen3.8-27B-DFlash2
• Community-Rezept qwen3.8-27b-nvfp4-dflash2: https://github.com/eugr/spark-vllm-docker
• vLLM-Issue #54173, Abstürze im GDN-Pfad auf GB10: https://github.com/vllm-project/vllm/issues/54173
• FlashInfer-Issue #3566 (geschlossen) und die Korrektur, die cuDNN auf SM12x aus der automatischen FP8-Auswahl nimmt: https://github.com/flashinfer-ai/flashinfer/issues/3566, https://github.com/flashinfer-ai/flashinfer/pull/4165
• Community-Messung, Qwen3.8-27B NVFP4 mit vLLM 0.27.1 und MTP auf einer DGX Spark: https://gist.github.com/Mirrdhyn/d476d17723c9d68eac72f03ec9447f2b
• NVIDIA-Entwicklerforum, Qwen3.8-27B NVFP4 auf einer einzelnen DGX Spark mit vLLM 0.26.1 und MTP: https://forums.developer.nvidia.com/t/qwen3-8-27b-nvfp4-on-a-single-dgx-spark-up-to-1m-context-vllm-mtp-measurements/380244