Davidmg0815 commited on
Commit
042df0c
·
verified ·
1 Parent(s): 96b0b63

Upload README.md with huggingface_hub

Browse files
Files changed (1) hide show
  1. README.md +70 -5
README.md CHANGED
@@ -44,11 +44,17 @@ Datei kann `llama-server` sie nicht als Draft laden.
44
  Die MTP-Tensoren sind aus den Zielmodellen **entfernt** (`--no-mtp`) und liegen
45
  ausschließlich in der Draft-Datei. Ziel- und Draft-Datei gehören zusammen.
46
 
47
- **Warum Q8_0 empfohlen ist, obwohl es größer ist:** In der Messung war es
48
- durchgehend **schneller** als Q6_K 39,5 gegen 32,8 t/s bei Fließtext, gleiche
49
- Einstellungen. Die k-Quant-Blockstruktur von Q6_K braucht pro Gewicht mehr
50
- Rechenschritte zum Entpacken als das schlichtere Q8_0. Mehr Bytes, weniger
51
- Arbeit. Q8_0 ist also gleichzeitig schneller *und* genauer.
 
 
 
 
 
 
52
 
53
  ## Verwendung
54
 
@@ -110,6 +116,65 @@ Fließtext-Dialog liegt bei **rund 1,7×**.
110
  Deutlich mehr als etwa der Gemma-4-12B-Draft mit 0,5 GB. Wer knapp an VRAM ist,
111
  muss das einplanen.
112
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
113
  ## Testaufbau
114
 
115
  * 3× NVIDIA RTX 3080 20 GB — **Ampere, SM 8.6**
 
44
  Die MTP-Tensoren sind aus den Zielmodellen **entfernt** (`--no-mtp`) und liegen
45
  ausschließlich in der Draft-Datei. Ziel- und Draft-Datei gehören zusammen.
46
 
47
+ **Welches Zielmodell?** Q8_0 ist das genauere, Q6_K das schnellere. Gemessen
48
+ ohne Draft, gleiche Einstellungen, 20 Aufgaben: **Q6_K 23,7 t/s gegen Q8_0
49
+ 19,6 t/s** Q6_K liegt 21 Prozent vorn, weil beim Erzeugen jedes Tokens alle
50
+ Gewichte einmal durch den Speicher müssen und 21 GB nun mal schneller gelesen
51
+ sind als 27 GB.
52
+
53
+ > **Korrektur, 15.08.2026.** Eine frühere Fassung dieser Karte behauptete das
54
+ > Gegenteil (»Q8_0 ist durchgehend schneller«). Diese Messung verglich Q8_0
55
+ > *mit* Draft gegen Q6_K *mit* Draft — dort hängt die Rate an der
56
+ > Draft-Trefferquote, nicht an der Dequantisierung, und der Vergleich war
57
+ > damit wertlos. Beim sauberen Vergleich ohne Draft dreht sich das Ergebnis um.
58
 
59
  ## Verwendung
60
 
 
116
  Deutlich mehr als etwa der Gemma-4-12B-Draft mit 0,5 GB. Wer knapp an VRAM ist,
117
  muss das einplanen.
118
 
119
+ ## HumanEval+ — was das Modell tatsächlich kann
120
+
121
+ **88,4 % (145 von 164)** für `qwen3.8-27b-Q8_0.gguf`, ohne Reasoning, in
122
+ 25,6 Minuten. Bewertet wird durch Ausführen: jede gelieferte Funktion läuft
123
+ gegen den vollständigen Testblock von EvalPlus, der die HumanEval-Originaltests
124
+ um etwa das Achtzigfache erweitert.
125
+
126
+ Zur Einordnung, publizierte Werte anderer Modelle:
127
+
128
+ | Modell | HumanEval+ |
129
+ |---|---|
130
+ | Phi-4 Reasoning (Microsoft) | 92,9 % |
131
+ | Llama 3 405B Instruct | 89 % |
132
+ | **Qwen3.8-27B Q8_0 — diese Messung** | **88,4 %** |
133
+ | Granite 3.3 8B Base | 86,1 % |
134
+ | Kimi K2 Base | 80,3 % |
135
+
136
+ > **Diese Zahl ist nicht eins zu eins mit den Leaderboards vergleichbar.**
137
+ > Drei Abweichungen vom offiziellen EvalPlus-Verfahren: die Aufgabe wird im
138
+ > **Chat-Format** gestellt (»Vervollständige diese Funktion«) statt als reine
139
+ > Textvervollständigung; **Temperatur 0,2** statt greedy; und der Code wird aus
140
+ > Markdown-Zäunen geschält. Jeder Punkt kann einige Prozent bewegen, meist nach
141
+ > oben — Chat-Modelle schneiden im Chat-Format besser ab. Wer vergleichen will,
142
+ > nimmt die Zahl als Hausmessung, nicht als Leaderboard-Eintrag.
143
+
144
+ Das Fehlerbild ist gesund: von 19 Fehlschlägen sind **15 AssertionError**, also
145
+ echte Logikfehler. Dazu je ein TypeError, SyntaxError, IndexError und eine
146
+ Zeitüberschreitung. Kein Muster, das auf ein kaputtes Testgerüst hindeutet.
147
+
148
+ Die übrigen Varianten (Q6_K, BF16, die Qwen3.6-Reihe) werden gerade gemessen
149
+ und hier nachgetragen.
150
+
151
+ ## Durchsatz im Vergleich
152
+
153
+ ![Durchsatz je Variante](bench/durchsatz-hell.png)
154
+
155
+ Sieben 27B-Varianten unter identischen Bedingungen — 16K Kontext, eine Session,
156
+ kein Draft, `--tensor-split 1,1,1`, KV-Cache q8_0, Temperatur 0,2:
157
+
158
+ | Variante | Größe | Token/s |
159
+ |---|---|---|
160
+ | Qwen3.6-27B Q5_K_M | 19 GB | 26,4 |
161
+ | Qwen3.6-27B Q6_K | 21 GB | 23,9 |
162
+ | **Qwen3.8-27B Q6_K** | 21 GB | **23,7** |
163
+ | Qwen3.6-27B Uncensored Q6_K_P | 22 GB | 23,1 |
164
+ | Qwen3.6-27B UD-Q6_K_XL | 24 GB | 21,1 |
165
+ | **Qwen3.8-27B Q8_0** | 27 GB | **19,6** |
166
+ | **Qwen3.8-27B BF16** | 51 GB | **11,5** |
167
+
168
+ Der Zusammenhang ist schlicht: mehr Gigabyte, weniger Token pro Sekunde. Bei der
169
+ Texterzeugung liest die GPU für **jedes einzelne Token** sämtliche Gewichte
170
+ einmal durch — Speicherbandbreite ist die Grenze, nicht Rechenleistung.
171
+
172
+ **Die BF16 läuft auf drei RTX 3080 — knapp.** 51,3 GB Gewichte belegen
173
+ 16,7 / 16,8 / 17,7 GB der drei Karten, macht 51,2 von 60 GB. Mit 16K Kontext
174
+ bleibt genug für KV-Cache und Puffer. Sie kostet allerdings 40 Prozent Tempo
175
+ gegenüber Q8_0, ohne dass sich in unserem eigenen Aufgabensatz ein
176
+ Qualitätsvorsprung gezeigt hätte — beide scheiterten an derselben einen Aufgabe.
177
+
178
  ## Testaufbau
179
 
180
  * 3× NVIDIA RTX 3080 20 GB — **Ampere, SM 8.6**