Qwen 3.6 27B Quantisierungs-Benchmark: Q4_K_M schlägt Q8_0 bei praktischen Abwägungen

Ein Reddit-Benutzer hat Qwen 3.6 27B in drei GGUF-Quantisierungsvarianten (BF16, Q4_K_M, Q8_0) mit llama-cpp-python über das Neo AI Engineer-Framework getestet. Die Auswertung umfasste insgesamt 664 Stichproben in drei Aufgaben: HumanEval (Codegenerierung, 164 Stichproben), HellaSwag (gesunder Menschenverstand, 100 Stichproben) und BFCL (Funktionsaufruf, 400 Stichproben).

Testergebnisse

• BF16 (Modellgröße 53,8 GB, Spitzen-RAM 54 GB, Durchsatz 15,5 tok/s): HumanEval 56,10 % (92/164), HellaSwag 90,00 % (90/100), BFCL 63,25 % (253/400). Durchschnittliche Genauigkeit: 69,78 %.
• Q4_K_M (16,8 GB, 28 GB RAM, 22,5 tok/s): HumanEval 50,61 % (83/164), HellaSwag 86,00 % (86/100), BFCL 63,00 % (252/400). Durchschnitt: 66,54 %.
• Q8_0 (28,6 GB, 42 GB RAM, 18,0 tok/s): HumanEval 52,44 % (86/164), HellaSwag 83,00 % (83/100), BFCL 63,00 % (252/400). Durchschnitt: 66,15 %.

Wichtige Erkenntnisse

Q4_K_M ist die herausragende praktische Variante. Sie bewahrt die BFCL-Genauigkeit (63,00 % vs. 63,25 %), verliert nur etwa 5,5 Punkte bei HumanEval und liegt bei HellaSwag etwa 4 Punkte hinter BF16. Die Kompromisse: 1,45-mal schneller als BF16, 48 % weniger Spitzen-RAM, 68,8 % kleinere Datei und nahezu identische Funktionsaufrufleistung. Q8_0 war enttäuschend: Es verbesserte HumanEval nur um etwa 1,8 Punkte gegenüber Q4_K_M, benötigte aber 42 GB RAM statt 28 GB, war langsamer und erzielte bei HellaSwag niedrigere Werte.

Für lokale/CPU-Bereitstellung wird Q4_K_M empfohlen, es sei denn, die Arbeitslast konzentriert sich stark auf Codegenerierung. Für maximale Qualität gewinnt immer noch BF16.

Testaufbau

GGUF-Varianten über llama-cpp-python mit n_ctx: 32768, kontrollierte Auswertung. Das Neo AI Engineer Framework erstellte die GGUF-Auswertungspipeline, führte kontrollierte Läufe durch und fasste die Ergebnisse zusammen. Eine vollständige Fallstudie mit Codeausschnitten ist in den ursprünglichen Reddit-Kommentaren verlinkt.