Benchmarks für spekulatives Decodieren auf RTX 3090 mit Qwen-Modellen für den Einsatz im HLK-Geschäft

Hardware und Setup

Der Entwickler verwendete eine RTX 3090 24GB, Ryzen 7600X, 32GB RAM und WSL2 Ubuntu. Er wechselte von Ollama unter Windows zu llama.cpp unter WSL Linux mit spekulativer Dekodierung für eine interne KI-Plattform, die Kundenabfragen, Angebotsformatierung, Geräterecherche und das Parsen unordentlicher Arbeitsnotizen handhabt.

Testmethodik

Sie testeten 16 GGUF-Modelle aus den Qwen2.5-, Qwen3- und Qwen3.5-Familien, jede Ziel+Entwurf-Kombination, die in 24GB VRAM passt, generationsübergreifende Entwurfspaarungen (Qwen2.5-Entwürfe auf Qwen3-Zielen und umgekehrt) und überwachten den VRAM bei jeder Kombination, um CPU-Offloading zu erkennen. Die Qualitätsbewertung nutzte echte HLK-Geschäftsaufforderungen für SQL-Generierung, Angebotsformatierung, Parsen unordentlicher Feldnotizen und Gerätekompatibilitätslogik. Sie verwendeten draftbench und llama-throughput-lab für Geschwindigkeitstests, wobei Claude Code den Prozess über Nacht automatisierte.

Top-Geschwindigkeitsergebnisse

• Qwen3-8B Q8_0 + Qwen3-1.7B Q4_K_M: 279,9 Tok/Sek. (+236% Beschleunigung, 13,6 GB VRAM)
• Qwen2.5-7B Q4_K_M + Qwen2.5-0.5B Q8_0: 205,4 Tok/Sek. (+50% Beschleunigung, ~6 GB VRAM)
• Qwen3-8B Q8_0 + Qwen3-0.6B Q4_0: 190,5 Tok/Sek. (+129% Beschleunigung, 12,9 GB VRAM)
• Qwen3-14B Q4_K_M + Qwen3-0.6B Q4_0: 159,1 Tok/Sek. (+115% Beschleunigung, 13,5 GB VRAM)
• Qwen2.5-14B Q8_0 + Qwen2.5-0.5B Q4_K_M: 137,5 Tok/Sek. (+186% Beschleunigung, ~16 GB VRAM)
• Qwen3.5-35B-A3B Q4_K_M (Baseline, kein Entwurf): 133,6 Tok/Sek. (22 GB VRAM)
• Qwen2.5-32B Q4_K_M + Qwen2.5-1.5B Q4_K_M: 91,0 Tok/Sek. (+156% Beschleunigung, ~20 GB VRAM)

Die Qwen3-8B + 1.7B-Entwurfskombination erreichte eine 100%ige Akzeptanzrate – perfekte Entwurfsübereinstimmung, bei der das 1.7B-Modell genau vorhersagt, was das 8B-Modell generieren würde.

Qwen3.5-Denkmodus-Problem

Qwen3.5-Modelle starten standardmäßig im Denkmodus auf llama.cpp und generieren versteckte Denktoken, bevor sie antworten. Dies führte zu unberechenbaren Benchmark-Ergebnissen: 0 Tok/Sek. im Wechsel mit 700 Tok/Sek., TTFT sprang zwischen 1s und 28s. Nur drei Methoden funktionierten, um ihn zu deaktivieren:

• --jinja + gepatchtes Chat-Template mit hartkodiertem enable_thinking=false ✅
• Roh-/completion-Endpunkt (umgeht Chat-Template vollständig) ✅
• Alles andere (Systemaufforderungen, /no_think-Suffix, Temperatur-Tricks) ❌

Wenn Sie Qwen3.5 auf llama.cpp ausführen, benötigen Sie das gepatchte Template, sonst erhalten Sie unbrauchbare Benchmarks.

Ergebnisse der Qualitätsbewertung

Sie führten vier schwierige HLK-spezifische Aufforderungen durch, die mehrdeutige Kundenanfragen, komplexe Angebote, unordentliche Notizen mit Tippfehlern und Gerätekompatibilitätslogik testeten. Wichtige Erkenntnisse:

• Jedes einzelne Modell scheiterte an der Preisformelmathematik: 8B, 14B, 32B, 35B – keines konnte $4.811 / (1 - 0,47) = $9.077 korrekt berechnen. LLMs können Geschäftsmathematik nicht zuverlässig – setzen Sie Ihre Formeln in Code.
• Das 8B-Modell bewältigte 3/4 der schwierigen Aufforderungen – gut bei mehrdeutigen Anfragen, unordentlichen Notizen, täglichen Aufgaben – scheiterte aber bei technischer Gerätelogik.
• Das 35B-A3B-Modell war das einzige mit echtem HLK-Fachwissen – dimensionierte korrekt eine Mini-Split-Anlage für eine ungedämmte Chicago-Garage, wusste, Hyper-Heat-Serie für kaltes Klima zu empfehlen, sagte korrekt, dass kein Branch-Box für Einzelzone benötigt wird – verpasste aber eine Modellnummer in unordentlichen Notizen und scheiterte an der Mathematik.
• Größer ≠ besser überall: Das Qwen3-14B Q4_K_M (159 Tok/Sek.) schnitt bei den meisten Aufforderungen schlechter ab als das 8B-Modell. Das 32B-Modell empfahl eine 5-Tonnen-Einheit für eine 400 sqft Garage.
• Qwen2.5-7B halluzinierte bei jedem Notizparsing-Test – erfand konsequent Details.