Testprotokoll: Qwen3.8-27B Denkmodi im CLI-Benchmark

Qwen 3.8 27B NVFP4 — Thinking-Modi-Vergleich (Qualität / Tokens / TPS)

• Modell: Qwen 3.8 27B NVFP4 (Dense, MTP, 1:3-Interleaving 16 full_attn + 48 Mamba2, 262K Context)
• Hardware: DGX Spark (asus_gx10_blackwell)
• Inference: vLLM 0.27.2rc1.dev126 (MOD thinking-budget-by-effort)
• Provider: vllm_spark
• Judge: Anthropic (Hybrid)
• Modul: cli_benchmark (6 Assets)
• Datum: 2026-08-17
• Pipeline: v5.1.5 (echte Provider-Token, TPS = output_tokens / wall-time)

---

TL;DR

---

Methodik

Jeder Modus fuhrt das gleiche cli_benchmark-Modul (cli001–cli006) einmal, sequenziell gegen den laufenden vLLM-Server. Die 4 Konfigurationen:

• enable_thinking wird via chat_template_kwargs pro Request gesteuert (Dual-Profile-Expansion).
• reasoning_effort wird pro Request gesendet; der MOD thinking-budget-by-effort leitet daraus das thinking_token_budget ab. Kein Server-Restart zwischen den Modi (per-Request-Parameter).
• Die CSV ist append-basiert mit eindeutiger run_id pro Run. Pro Modus wurde der neue run_id per Vorher/Nachher-Diff ermittelt und die 6 Zeilen als Snapshot gesichert (outputs/analysis/qwen3_8_thinking_modes/).
• --force erzwang einen frischen Lauf (Cache ignoriert). reasoning_effort wurde nach dem Lauf auf den committed Wert (medium) zurückgesetzt.

Metrik-Definitionen (v5.1.5):

• tokens_per_second (TPS) = output_tokens / execution_time — echter Decode-Durchsatz inkl. Thinking-Tokens.
• output_tokens = sichtbare Antwort + Thinking; reasoning_tokens = Thinking-Anteil; input_tokens = Prompt.
• Aggregierter TPS ist nach execution_time gewichtet.

---

Kern-Metriken je Modus

---

Qualität je Asset (Score 0–100)

---

Token-Verbrauch & TPS je Asset

(Auswahl der relevantesten Zeilen; vollständige Daten in den Snapshots.)

---

Effizienz-Metriken

* reasoning_tokens / output_tokens — wie groß der Output aus reinem Thinking besteht.

• Thinking-Anteil: xhigh ist zu 97.5 % Thinking (fast alles Reasoning, kaum sichtbare Antwort). medium 73.2 %, low 57.8 %.
• Score/1k Tokens (Qualität pro Token): instruct dominiert (467), weil kein Thinking-Overhead. xhigh ist am ineffizientesten (31) — für 15 878 Tokens nur 86.7 Score.
• Score/Sekunde (Qualitäts-Throughput): instruct am schnellsten (21.7), xhigh am langsamsten (0.38).

---

Analyse & Befunde

1. medium = klare Empfehlung. Beste Durchschnittsqualität (93.0) bei gleichzeitig schnellstem TPS (26.3) und moderatem Aufwand (3 244 Out-Tokens, 124 s). Das Thinking-Budget von medium deckt den Sweet-Spot: genug Reasoning für die harten Tasks (cli001 → 100), ohne den xhigh-Overhead.

2. xhigh ist Overkill mit Rauschen. Der Qualitätsgewinn gegenüber medium ist negativ (86.7 < 93.0) und gegenüber instruct vernachlässigbar (86.7 ≈ 86.0). Der Preis: 5× Tokens, 58× Zeit, TPS halbiert. Das Extra-Thinking ist inkonsistent — es hebt cli004/cli005, drückt aber cli001/cli006. Für Routine-Tasks nicht vertretbar; nur für Einzelfall-Hard-Problems sinnvoll.

3. low ist der schlechteste Modus. 82.4 liegt unter instruct (86.0). Ein minimales Thinking-Budget zahlt den Token-/Zeit-Preis, bringt aber keinen ausreichenden Qualitätsgewinn — auf cli005 (62) und cli006 (72) sogar deutlich schlechter als ohne Thinking. Kleines Budget ≠ proportionale Qualität.

4. instruct (off) ist die Latenz-Banker. 86.0 in 24 s. Für latency-sensitive oder hochvolumige Nutzung das beste Preis-Leistungs-Verhältnis — es liegt nur 7 Punkte unter medium, kostet aber 1/5 der Zeit und 1/3 der Tokens.

5. TPS-Caveat (xhigh): Der niedrige xhigh-TPS (11.5) ist teilweise ein Mess-Artefakt — bei cli001 gab es Request-Retries/Timeouts (918 s), die die wall-time aufblähen, während output_tokens nur die finale Antwort zählt. Der „echte" Decode-Speed ist höher; die effektive Throughput-Verlangsamung ist real, aber nicht rein hardwarebedingt.

---

Grenzen / Caveats

• n = 6 Assets pro Modus — kleines Stichprobenvolumen; einzelne Ausreißer (cli006 xhigh = 58) wiegen schwer.
• Ein Modul (cli_benchmark) — repräsentativ für praktische CLI-Problem solving, nicht für alle Task-Typen. Thinking-lastigere Module (reasoning, code_quality) könnten andere Muster zeigen.
• Ein Lauf pro Modus — keine Wiederholungen/Varianz; Scores können sich bei Re-Runs verschieben.
• xhigh-Retries verzerren die TPS-Messung (siehe Befund 5).
• CLI-Tasks sind relativ kurz; bei längeren, komplexeren Outputs könnte sich das Quality/Token-Verhältnis verschieben.

---

Empfehlung

Konkreter Vorschlag für provider_config.yaml: reasoning_effort: medium als Standard für qwen3_8-27b-nvfp4 (ist aktuell bereits gesetzt). xhigh nicht als Default — nur als explizite, bewusste Wahl für Hard-Problems.

---

Appendix

Run-IDs & Snapshots (outputs/analysis/qwen3_8_thinking_modes/):