Als ich Qwen3.8-27B-FP8 auf zwei H100 betrieben habe, war das MTP-Speculative-Decoding der größte Decode-Gewinn (49 → 95 Tok/s). Aber es gibt einen Haken: In vLLM schließen sich MTP und Prefix-Caching gegenseitig aus. Es blieb also die Frage: Welche Konfiguration gehört in Produktion?

Die Antwort kam aus einem direkten Vergleich der beiden Konfigurationen: GPU0 ohne MTP + Prefix-Caching, GPU1 mit MTP (3 Draft-Tokens). Beide TP1, maximaler Kontext 262K, FP8-KV-Cache, und ein LiteLLM-Proxy verteilt die Last zwischen ihnen. Alle Werte sind TTFT-p50, sofern nicht anders angegeben.

Decode: MTP gewinnt den Punkt#

Zuerst die gute Nachricht: Beim Decode ist MTP bei jeder Auslastungsstufe schneller, mit 1K-Token-Prompts und 512 Ausgabe-Tokens:

MTP Decode-Throughput

Bei einer einzelnen Session beträgt der Vorsprung 1,9× (94,9 gegenüber 49,9 Tok/s) und schrumpft bei 32 parallelen Sessions auf 1,28×. Wenn du also viele Tokens aus kalten Prompts erzeugst, ist MTP dein Freund.

Single-Turn: gemeinsames Präfix, einzigartige Suffixe#

Hier beginnt sich das Blatt zu wenden. Wenn mehrere Sessions dasselbe Präfix teilen (z. B. ein gemeinsames System-Prompt), bleibt die Caching-Konfiguration bei steigender Auslastung praktisch flach, während MTP das Präfix für jede Anfrage neu prefillen muss. Bei 4K-Präfix und ohne Auslastung gewinnt MTP noch (0,85 s gegenüber 1,02 s), bei 32 Sessions liegt es jedoch schon 2,6× zurück (13,55 s gegenüber 5,20 s). Bei 16K-Präfix und 16 Sessions beträgt der Unterschied bereits 8× (27,85 s gegenüber 3,49 s).

Und der Cache-Hit ist nicht zu unterschätzen: Bei der zweiten Anfrage mit 16K-Präfix ist der Cache-Hit 2,4× schneller als das Re-Prefill von MTP (0,91 s gegenüber 2,20 s) — bei 4K frisst allerdings der Hashing-Overhead den Großteil des Vorteils auf.

Multi-Turn: hier fällt die Entscheidung#

Drei-Turn-Sessions, jede Runde wächst der Kontext um ~1K Tokens (von 4K bis 64K). Die Turn-2-TTFT — die Zeit für die erste Folgeanfrage — linear skaliert, je ein Panel pro Basiskontext:

Multi-Turn-TTFT auf linearer Skala, pro Basiskontext

Auf der linearen Skala ist die Botschaft nicht zu übersehen: Die Caching-Konfiguration bleibt flach (~1,4–5,5 s bei jeder Kontextgröße bis zu 8 parallelen Sessions — nur das ~1K neue Suffix wird geprefillt, das gemeinsame Präfix ist ein Cache-Hit, etwa 65 % Trefferquote im Testlauf), während MTP bei jeder Folgeanfrage den gesamten akkumulierten Kontext neu prefillen muss.

Für die großen Kontexte zeige ich die MTP-Kurven auch einzeln — auf einer logarithmischen Achse wirkt diese „Wand“ fast unsichtbar:

Die MTP-Wand auf linearer Skala

Die Caching-Seite noch einmal aus der Nähe, damit die Flachheit wirklich sichtbar wird (der 132-s-Punkt bei 64K/16 ist die gemeinsame KV-Kapazitätsgrenze beider Konfigurationen, kein Caching-Fehler):

Prefix-Caching auf linearer Skala, gezoomt

In Zahlen: Bei 8 Sessions / 32K liegt MTP schon bei 28,6 s; bei 16 Sessions / 64K sind es 80,9 s. Das Verhältnis klettert bis auf 16,8× (64K, 4 Concurrent). Die Ecke 64K/16 ist dabei die Ausnahme: Dort stoßen beide Konfigurationen an die KV-Cache-Grenze (16 × 64K Live-KV sind ~1,05M Tokens gegen einen 1,32M-Pool, und die Caching-Instanz verschlechtert sich wegen der gepinnten Cache-Blöcke sogar noch stärker) — das ist eine Kapazitätsgrenze, kein Konfigurationseffekt.

Fazit#

Arbeitslast Gewinner
Einzelne Session, lange Generierung, kalte Prompts MTP (1,3–2,2× Decode)
Multi-Turn, parallele Sessions, wachsender Kontext Prefix-Caching (bis zu 17× TTFT)
64K+ Kontext bei 16+ parallelen Sessions Keines — KV-Kapazitätsgrenze

Und die praktische Erkenntnis: Für konversationelle bzw. Multi-Turn-Arbeitslasten ist Prefix-Caching die Standardwahl, vor allem wenn mehrere Nutzer Kontext oder System-Prompts teilen. MTP lohnt sich nur bei decode-lastigen, kalten Single-Session-Aufgaben. Da sich die beiden in vLLM gegenseitig ausschließen, hat diese Messung für mich entschieden, welche Konfiguration in Produktion geht.