Self-Hosted KI schneller machen: Speculative Decoding und dFlash

Self-Hosted-LLMs haben ein stilles Performance-Problem, und es ist nicht das, was die meisten erwarten. Die GPU ist selten der Engpass. Während der Textgenerierung wartet sie die meiste Zeit: Sie schiebt den Key-Value-Cache durch den Speicher und gibt ein Token nach dem anderen aus, strikt sequenziell. Die Recheneinheiten liegen brach. Das ist der Decode-Engpass, und deshalb wirkt eine auf dem Papier schnelle Karte im Chatfenster trotzdem zäh.

Self-Hosted-KI schneller und ressourcenschonender zu machen, hängt also weniger an der größeren GPU als daran, die vorhandene nicht zu verschwenden. Speculative Decoding ist dafür der wirksamste Hebel. NVIDIA hat gerade einen neuen offenen Baustein dazu veröffentlicht.

NVIDIA GPU visualization placeholder

Speculative Decoding in einfachen Worten

Das Prinzip ist Entwerfen-und-Prüfen. Ein kleines, schnelles Drafter-Modell rät mehrere künftige Token. Das große Ziel-Modell prüft diesen ganzen Entwurf dann in einem einzigen Forward-Pass, statt die Token Stück für Stück zu erzeugen. Token, denen das Ziel-Modell zustimmt, bleiben; das erste, dem es widerspricht, wird korrigiert, und ab dort wird neu entworfen.

Die entscheidende Eigenschaft: Die Ausgabe ist mathematisch identisch mit dem, was das Ziel-Modell allein produziert hätte. Man tauscht etwas zusätzliche Rechenleistung (den Drafter sowie das Prüfen womöglich verworfener Token) gegen deutlich weniger sequenzielle Schritte. Auf Decode-gebundener Hardware ist das ein hervorragender Tausch.

Speculative decoding diagram placeholder

dFlash: was wirklich neu ist

Die meisten Speculative-Decoder entwerfen autoregressiv, ein Token nach dem anderen. dFlash, ein offenes Block-Diffusion-Modell der UC San Diego, entwirft einen ganzen Block von Kandidaten-Token in einem Durchgang. Drei Ideen machen das leistungsfähig:

Block-Diffusion-Drafting: sagt mehrere künftige Token parallel voraus statt sequenziell.
Konditionierung auf Hidden States des Ziels: der Drafter bekommt aus dem Ziel-Modell extrahierte Kontext-Features, damit seine Vorschläge ausgerichtet bleiben.
KV-Injection: Kontext des Ziel-Modells wird über die Schichten hinweg in die Projektionen des Drafters eingespeist, was die Akzeptanzrate hoch hält.

Eine höhere Akzeptanzrate heißt: Mehr entworfene Token überstehen die Prüfung: also weniger Runden, also mehr Tempo, bei unveränderter Qualität.

Die Zahlen

NVIDIA hat dFlash auf Blackwell gegen einfache autoregressive Dekodierung gebenchmarkt:

Speed comparison chart placeholder

Die Schlagzeile ist bis zu 15× höherer Durchsatz bei gpt-oss-120b mit 500–600 Token/s pro Nutzer. Auf anderen Stacks: 5,8× bei Gemma (vLLM, Math500) und 5,1× bei Qwen3 (SGLang, Math500), während sich die Interaktivität von Llama 3.1 8B bei Batch-Größe 1 nahezu verdoppelte. Gegenüber der bisher besten Speculative-Methode, EAGLE-3, liefert dFlash immer noch rund 1,5× mehr Durchsatz und im Schnitt etwa 2,3× bessere Interaktivität.

Und das ist kein reines Forschungsartefakt: dFlash ist in vLLM (über die Speculators-Bibliothek), SGLang und TensorRT-LLM integriert, mit rund 20 fertigen Checkpoints auf Hugging Face für die Familien Qwen, Llama, Gemma und gpt-oss.

Trifft das auf unser Setup zu?

Ehrlich, mit Einschränkung. NVIDIAs Zahlen stammen von Datacenter-Blackwell (DGX B200/B300) und Hopper-Karten. Unsere Standard-Inferenzkarte ist die RTX 5090, die ebenfalls Blackwell-Klasse ist (die Architektur passt also) und Speculative Decoding selbst läuft über vLLM oder SGLang auf praktisch jeder modernen GPU.

Was man nicht erwarten sollte, sind die 15× der Schlagzeile auf einer einzelnen Consumer-Karte — diese Werte setzen große Batch-Größen und Datacenter-Speicherbandbreite voraus. Auf einer 5090 ist der realistische Gewinn ein spürbar geringerer Latenz für interaktive Single-User- oder Small-Batch-Workloads. Also: genau der Self-Hosting-Fall.

Der größere Effizienz-Werkzeugkasten

Speculative Decoding ist ein Hebel, nicht die ganze Maschine. Es kombiniert sich sauber mit den Techniken, die wir ohnehin einsetzen:

PagedAttention und kontinuierliches Batching: behandelt in unserem vLLM-Artikel. Das ist es, was zehn parallele Requests weit weniger kosten lässt als zehnmal einen Request.
Quantisierung: Gewichte in 4-Bit zu fahren (siehe unsere llama.cpp- und GGUF-Notizen) verkleinert genau den Speicherverkehr, aus dem der Decode-Engpass besteht.
Das Modell richtig dimensionieren: das günstigste Token ist das, das man nie erzeugt. Ein gut gewähltes 8B-Modell mit Speculative Decoding schlägt oft ein 70B-Modell, das gerade so hineinpasst.

Der Punkt ist, Techniken zu kombinieren, statt einer einzelnen Benchmark-Zahl hinterherzulaufen.

Ein pragmatisches Rezept

Für einen Mittelständler, der seine eigene Inferenz betreibt, ist die Reihenfolge ungefähr:

Das kleinste Modell wählen, das die Aufgabe wirklich erledigt.
Es mit vLLM oder SGLang ausliefern: PagedAttention und kontinuierliches Batching gibt es gratis dazu.
4-Bit-Quantisierung anwenden, wenn das VRAM knapp ist.
Speculative Decoding einschalten (einen dFlash-Checkpoint, wo es für das Modell einen gibt) und Token/s vorher und nachher messen.

Fazit

Schnellere Self-Hosted-KI ist überwiegend eine Effizienz-Geschichte, keine Hardware-Geschichte. Der Decode-Engpass verschwendet die GPU, die man bereits besitzt; Speculative Decoding holt sie zurück, ohne die Ausgabequalität zu beschädigen, und offene Drafter wie dFlash machen die Technik über vLLM, SGLang und TensorRT-LLM leichter zugänglich. Für alle, die LLMs auf eigener Hardware betreiben, ist es eine der wirksamsten Stellschrauben, die man dieses Jahr umlegen kann.