Über 20 Konfigurationen auf Geschwindigkeit gemessen, dann die Kandidaten wochenlang als Coding-Agent gegen verdeckte Tests laufen lassen. Ergebnis: Q4_K_M mit MTP und Tensor-Split liefert 79 Tokens pro Sekunde und hat in den Agententests am Ende auch qualitativ vorne gelegen.

Dieser Bericht fasst die Messungen vom 16. bis 30. Oktober zusammen. Die Einzelheiten zu Testaufbau und ersten Läufen stehen in zwei früheren Beiträgen: Was MTP, Quantisierung und Tensor-Split wirklich bringen und Lokale Coding-Agenten im Härtetest. Dort war die schnellste Variante in den langen Agentensitzungen noch gescheitert. Die Wiederholungsläufe seither haben dieses Bild gedreht.

Aufbau

Zwei unterschiedliche Karten in einem Rechner, zusammen 28 GB VRAM. Qwen3.8 27B ist ein dichtes Modell, es muss also komplett in den Grafikspeicher passen, sonst bricht die Geschwindigkeit ein. Jede Messung lief deshalb zu 100 % auf der GPU, andere Modelle und Dienste waren vorher entladen.

Verglichen wurden fünf Quantisierungen, jeweils mit und ohne zwei Beschleuniger:

• MTP (Multi-Token Prediction): Das Modell bringt eigene Vorhersage-Köpfe mit, die mehrere Token im Voraus raten. Das Hauptmodell prüft sie in einem Durchgang. Ein separates Draft-Modell ist nicht nötig.
• -sm tensor: Beide GPUs rechnen an jeder Schicht gleichzeitig. Beim normalen Schicht-Split (-sm layer) wartet immer eine Karte auf die andere.

Gemessen wurde die Ausgabegeschwindigkeit (Decode) für drei kurze Aufgaben (Code, JSON, Fließtext) und für einen langen Prompt mit 26k Token.

Geschwindigkeit

Decode, Mittel aus Code / JSON / Prosa, in tok/s. Die Zahl hinter MTP ist die Anzahl der Draft-Token, „+ tensor“ steht für -sm tensor, sonst wurde der Schicht-Split verwendet. Blau = ohne MTP, Orange = mit MTP.

Q5_K_M + MTP + tensor passte nicht mehr in den Speicher (OOM). -sm row wird für dieses Modell nicht unterstützt.

Details der wichtigsten Varianten

Alle Werte in tok/s, VRAM als Spitzenwert je Karte.

Was die Zahlen zeigen

• Tensor-Split ist der einfachste Gewinn. Eine Zeile in der Server-Konfiguration bringt bei zwei GPUs +60 bis 65 %. Im Schicht-Split lag die Auslastung bei etwa 60 % / 40 %, die Karten haben abwechselnd gerechnet.
• MTP verdoppelt K-Quants. Q4_K_M mit Tensor-Split geht von 39,6 auf 79,4 tok/s. Bei der IQ3_S-Variante (GSQ) bremst MTP sogar: Drei Entwurfs-Token kosten dort das 2,08-Fache der Zeit, bei K-Quants nur das 1,1- bis 1,2-Fache.
• Der Gewinn hängt vom Text ab. JSON ist gut vorhersagbar (102 tok/s, 89 % der Entwürfe angenommen), Fließtext deutlich weniger (57 tok/s, 36 %). Mehr Draft-Token helfen bei JSON und Code, bei Prosa nicht.
• Prefill wird etwas langsamer. Mit Tensor-Split und MTP sinkt die Prompt-Verarbeitung von rund 1400 auf rund 1070 tok/s. Ein größerer Micro-Batch (-ub 1024) holt davon nur 4 bis 6 % zurück.
• Platz ist die Grenze. Mit Q4_K_M + MTP + Tensor-Split bleibt auf der 12-GB-Karte rund 1 GB frei. Q5_K_M passt mit MTP nicht mehr. Ein zweites Modell (hier Whisper für Spracherkennung) daneben hat den Server in der Praxis sehr wahrscheinlich zum Hängen gebracht.

Server-Konfiguration der schnellsten Variante

llama-server -m Qwen3.8-27B-MTP-Q4_K_M.gguf \
  -ngl 99 --device CUDA0,CUDA1 -sm tensor \
  -c 65536 --parallel 1 \
  --spec-type draft-mtp --spec-draft-n-max 4 \
  --jinja --reasoning-format deepseek --reasoning-budget 2048 \
  --temp 0.7 --top-k 20 --top-p 0.8 --min-p 0 \
  --presence-penalty 1.5 --repeat-penalty 1.0

Testszenarien

Tokens pro Sekunde sagen nichts darüber, ob ein Modell als Agent etwas fertig bringt. Deshalb liefen die Kandidaten in OpenCode gegen Aufgaben mit verdeckten Tests. Der Agent arbeitet in einem abgeschotteten Verzeichnis, sieht weder Tests noch Musterlösung und darf nur ein Prüfskript aufrufen.

minipack (Reverse Engineering)

Ein eigenes C++-Kommandozeilenprogramm (Kompressions-Codecs, abstrakte Basisklasse, Statistik) wird mit MSVC /O2 ohne Debug-Symbole gebaut. Der Agent sieht nur die EXE und rekonstruiert den Quellcode über Ghidra (pyghidra-mcp).

120 Differenzialtests gegen das Original · Strukturbewertung 21 Punkte (für den Agenten unsichtbar) · 120 min + 45 min Abschluss-Sitzung

heatshrink (Reverse Engineering, groß)

Ein LZSS-Packer, leicht verändert, damit das Modell ihn nicht aus dem Training kennt. Encoder, Decoder, Fehlerbehandlung und CLI müssen byte-genau stimmen.

152 Testfälle in 6 Gruppen · Strukturbewertung 15 Punkte · bis 360 min

web-lab (Web-Entwicklung)

Eine FastAPI- und React-App mit LLM-Anbindung wird erweitert: Chat, Streaming per SSE, Verlauf in SQLite, strukturierte Ausgabe, dann Tool-Calling, Kontextbudget, Token-Auth, Verbrauchslimits und UI-Extras.

Stufe 1: 6 Aufgaben, 52 Tests · Stufe 2: 6 weitere Aufgaben quer durch den Bestand, 102 Tests · Mock-LLM und Vitest

Ergebnisse als Coding-Agent

minipack: rekonstruieren und aufräumen

Alle Läufe mit Thinking-Budget 2048 und Tensor-Split, im gleichen Aufbau aus zwei Sitzungen: Erst wird rekonstruiert, bis alle Tests grün sind, dann folgt eine frische Sitzung für Ghidra-Dokumentation und Code-Qualität.

Im ersten MTP-Lauf war die Rekonstruktion nach 44 Minuten fertig, die Abschluss-Sitzung hat den Code dann aber kaputt umgebaut und die Zeit überschritten. Die Wiederholung lieferte die erste volle Punktzahl: unique_ptr statt rohem new, abstrakte Basis mit 12 override, keine Warnungen bei /W4, 22 Funktionen in Ghidra benannt und kommentiert. Zum Vergleich: Claude Sonnet löste dieselbe Aufgabe über ein anderes Ghidra-Werkzeug in 11 Minuten.

heatshrink: nur mit Modulen

Mit GSQ IQ3_S in einer einzigen langen Sitzung: 60/152 nach sechs Stunden. Der Encoder meldete nur „Ausgabe weicht ab“, der Agent hatte nichts, woran er sich entlanghangeln konnte. Mit einer frischen Sitzung pro Modul, der Meldung der ersten abweichenden Byte-Position und automatischem Zurückspielen des besten Stands: 152/152, Struktur 13/15.

web-lab: Stufe 2 mit 102 Tests

In Stufe 1 (52 Tests) lagen zum Vergleich Qwen3.6 35B-A3B (52/52, 10 min) und Qwen3.8 GSQ (52/52, 14 min) vorne, dahinter GLM-4.7-Flash (45/52), Qwen3-Coder-30B (41/52) und Devstral Small 2 (40/52).

Was mehr gebracht hat als das Quant

1. „Code zuerst“ in der Arbeitsanleitung. Ohne diese Vorgabe analysierte auch die beste Variante eine Stunde lang und schrieb keine Zeile.
2. Thinking begrenzen. Unbegrenztes Thinking frisst das Ausgabelimit, ohne Thinking dreht der Agent nach etwa zwölf Minuten Schleifen. --reasoning-budget 2048 am Server liegt dazwischen.
3. Kurze Anleitungen. Jede zusätzliche Regel in der AGENTS.md machte die Ergebnisse schlechter. Besser: zwei Sitzungen mit je einer schlanken Anleitung.
4. Fleißarbeit vorbereiten. „Dokumentiere alle Funktionen in Ghidra“ wurde ignoriert. Eine fertige Liste mit Adresse, Namensvorschlag und Kommentar wurde in 39 Minuten vollständig abgearbeitet.
5. Feedback, das man verwerten kann. „Datei weicht ab“ führt zu nichts, „erste Abweichung bei Byte …“ führt zum Ziel.

Fazit

Für Qwen3.8 27B auf zwei Consumer-GPUs mit zusammen 28 GB ist Q4_K_M mit MTP (4 Draft-Token) und -sm tensor die schnellste Variante, die noch komplett in den Speicher passt: knapp 80 tok/s bei kurzen Antworten, 65 tok/s bei 26k Kontext. Als Coding-Agent war sie in den Web-Tests klar schneller fertig als GSQ IQ3_S und lieferte im Reverse-Engineering-Test den saubersten Code. GSQ IQ3_S bleibt die sparsamere Wahl (rund 18 GB, 47 tok/s), wenn noch etwas anderes auf den Karten laufen soll.

Messungen 16.–30. Oktober 2026 · llama.cpp b10964 · Quants: GSQ-RCO IQ3_S (ISTA-DASLab), Q4_K_M mit MTP-Köpfen (Jackrong), UD-Q4_K_XL (Unsloth)