llama.cpp kann jetzt die Multi-Token-Prediction-(MTP-)Schichten von Qwen3-Next und DeepSeek V3.2 nutzen. Die am 3. August veröffentlichten Builds b10237 und b10238 machen damit eine im Modell vorhandene Decoding-Optimierung im lokalen Serving verfügbar. Das verbessert nicht die Modellqualität – kann aber die Zeit bis zum vollständigen Output senken.
Was MTP im lokalen Serving verändert
Statt pro Schritt genau ein nächstes Token zu erzeugen, schlägt ein MTP-Head mehrere Folgetokens vor. Das Hauptmodell prüft diese Vorschläge und übernimmt nur akzeptierte Tokens. In llama.cpp wird der Pfad über --spec-type draft-mtp aktiviert; --spec-draft-n-max und --spec-draft-p-min steuern, wie aggressiv spekuliert wird.
llama-server -m model.gguf --spec-type draft-mtp --spec-draft-n-max 2 --spec-draft-p-min 0.5Die Implementierungen sind modellabhängig: DeepSeek V3.2 und Qwen3-Next erhalten jeweils expliziten Support. Teams brauchen dafür keinen separaten Draft-Server, sofern ihr Modell die MTP-Schichten enthält und das passende GGUF eingesetzt wird.
Benchmark-Signal, kein universelles Versprechen
Der Qwen3-Next-PR dokumentiert auf einem M5 Max für neun Prompts 18,14 Sekunden ohne und 14,21 Sekunden mit abgestimmter MTP-Konfiguration. Der DeepSeek-PR nennt für Codegenerierung bei zwei Draft-Tokens ungefähr 80 Prozent Akzeptanzrate. Beides sind Maintainer-Messungen auf konkreter Hardware und Workloads – keine übertragbare SLA.
MTP verschiebt die Latenzfrage vom Modellnamen zu Akzeptanzrate, Prompttyp, Quantisierung und Hardware.
Was Betreiber jetzt testen sollten
- Canary statt Flächenrollout: MTP mit Produktionsprompts gegen den bisherigen Decode-Pfad messen.
- TTFT und Gesamtlatenz getrennt beobachten: Ein schnellerer Decode-Pfad ersetzt keine Analyse von Prefill und Queueing.
- Qualität und Determinismus regressieren: Akzeptierte Drafts müssen mit den erwarteten Output- und Tool-Call-Tests zusammenpassen.
- Speicherbudget mitmessen: Spekulatives Decoding verändert den Laufzeitpfad; Quantisierung und Kontextgröße bleiben Teil der Kapazitätsrechnung.
Für lokale Qwen3-Next- und DeepSeek-V3.2-Deployments ist das ein substantielles Runtime-Update: Nicht ein weiteres Modell wird angeschlossen, sondern ein bereits mitgelieferter Decoder wird praktisch nutzbar. Der richtige nächste Schritt ist ein kontrollierter Canary mit realen Prompts – nicht das Übernehmen einer einzelnen Benchmarkzahl.
Quellen: llama.cpp b10237 (3. August 2026, DeepSeek V3.2 MTP); llama.cpp b10238 (3. August 2026, Qwen3-Next MTP); PR #25589; PR #26457.
Leave a Reply