llama.cpp: GLM-5.2 nutzt seinen MTP-Head für lokales Speculative Decoding

llama.cpp kann den in GLM-5.2 vorhandenen NextN-/MTP-Head jetzt als integrierten Draft-Decoder einsetzen. Das ist für lokale Inferenz interessanter als ein gewöhnlicher Release-Note-Eintrag: Statt ein zweites, kleineres Modell für speculative decoding zu betreiben, wird ein bereits im Modell angelegter Mehrtoken-Head genutzt.

Die Änderung landete am 29. Juli 2026 um 07:14 UTC in Release b10174 von llama.cpp. Sie ergänzt GLM-5.2 (GLM_DSA) um den bestehenden --spec-type draft-mtp-Pfad. Der zugehörige, gemergte Implementierungs-PR dokumentiert Architektur, Konverter und Tests.

Was technisch neu ist

Bei speculative decoding erzeugt ein Draft-Pfad mehrere wahrscheinliche Folgetokens, die das Hauptmodell anschließend verifiziert. Für GLM-5.2 liegt dieser Draft-Mechanismus als NextN/Multi-Token-Prediction-Head bereits im Modellformat. llama.cpp kann ihn nun laden und ausführen.

• Kein separates Draft-Modell: Der MTP-Head wird als draft-mtp-Target verwendet.
• Bestehende Artefakte: Community-GGUFs mit den NextN-Tensoren sollen laut Implementierungs-PR unverändert laden.
• Gezielter Export: Der Konverter erhält --mtp für einen Draft-only-GGUF und --no-mtp, um den zusätzlichen NextN-Block zu entfernen.
• Kein stiller Generationswechsel: Ohne --spec-type draft-mtp bleibt der Ausführungsgraph laut PR unverändert; die zusätzlichen Tensoren können bei vorhandenen gebündelten GGUFs dennoch geladen werden.

Der operative Haken: Kontext kostet Speicher

Der Geschwindigkeitsgewinn ist nicht kostenlos. Die Implementierung beschreibt einen separaten MTP-Kontext mit KV-Cache für die NextN-Layer. In den Contributor-Tests auf zwei RTX PRO 6000 Blackwell mit einem 744B-A40B-Modell in IQ1_S sank die mögliche F16-KV-Kontextgrenze mit aktivem MTP von rund 512K auf rund 128K Tokens. Das sind keine universellen Benchmarks, aber eine wichtige Kapazitätswarnung: Wer lange Kontexte nahe an der VRAM-Grenze plant, sollte MTP als Speicher- und Throughput-Profil testen, nicht als pauschalen Beschleuniger aktivieren.

# GLM-5.2 mit dem integrierten MTP-Draft-Pfad starten
llama-server -m GLM-5.2.gguf -ngl 99 -sm layer \
  --spec-type draft-mtp

# Beim Konvertieren gezielt trennen oder entfernen
python convert_hf_to_gguf.py MODEL --mtp
python convert_hf_to_gguf.py MODEL --no-mtp

Warum das relevant ist

Für Betreiber lokaler GLM-5.2-Instanzen verschiebt sich die Architekturentscheidung: Draft-Modell, Gewichte, Routing und Lebenszyklus müssen nicht mehr zwingend als eigener Dienst gepflegt werden. Dafür wird der vorhandene Modell-Head Teil der Kapazitätsplanung. Der richtige Test ist deshalb nicht nur Tokens pro Sekunde, sondern mindestens: Akzeptanzrate, VRAM bei Zielkontext, Prompt-Processing und Verhalten unter der eigenen Quantisierung.

Einordnung: Das Update ist ein Runtime-Feature für llama.cpp, keine neue GLM-5.2-Modellveröffentlichung. Die PR-Autor:innen berichten für ihre konkrete CUDA-Testumgebung bis zu etwa 1,37× Durchsatz im greedy Modus; Backend-, Quantisierungs- und Workload-Unterschiede sind ausdrücklich zu erwarten.

Quellen

• llama.cpp Release b10174 (29. Juli 2026)
• PR #25980: NextN/MTP speculative decoding support for GLM_DSA (GLM-5.2) – Implementierung, Konverter-Optionen und Testdetails