Elf Wege, ein lokales Modell schneller zu machen

Ein Sprachmodell auf dem eigenen Rechner schreibt ein Wort nach dem anderen, und für jedes einzelne muss es seine aktiven Gewichte einmal durch den Arbeitsspeicher lesen. Bei einem Modell mit 27 Milliarden Parametern in vier Bit sind das rund 17 Gigabyte je Token. Wie schnell die Antwort kommt, entscheidet deshalb die Speicherbandbreite und selten die Rechenleistung. Der Rechner wartet mehr, als er rechnet.

Genau hier setzt eine Familie von Verfahren an, die Speculative Decoding heißt. Der Gedanke: Wenn ohnehin die ganzen Gewichte gelesen werden müssen, dann kann derselbe Durchgang auch gleich mehrere Token prüfen statt eines. Ein Vorschlag muss nur von irgendwoher kommen.

Ich wollte wissen, was davon auf meinem Gerät ankommt, und habe sieben der elf Verfahren gemessen. Herausgekommen sind zwei Dinge, die ich so nicht erwartet hatte: Die meisten sind auf einem Arbeitsrechner gar nicht messbar, weil die Streuung größer ist als ihre Wirkung. Und die Kennzahl, auf die es ankommt, ist eine andere als die, die alle angeben.

Der Aufbau

MacBook Pro M4 Max mit 64 Gigabyte, macOS 26.6, llama.cpp Build 10470 über Homebrew, gemessen am 19.08.2026. Drei Modelle in vier Bit: Llama 3.2 mit drei Milliarden Parametern, Qwen3.6 mit 27 Milliarden in der Fassung mit den Vorhersageköpfen, und Gemma 4 mit 31 Milliarden samt einem passenden Entwurfsmodell.

Vier Textsorten, je drei verschiedene Aufträge: einen Text umschreiben, in einem Stück Programmcode eine Variable umbenennen, einen Absatz zusammenfassen, frei schreiben. Die Trennung ist der eigentliche Punkt, denn die Verfahren hängen daran, wie vorhersehbar der Text ist.

Je Verfahren lief der Server zweimal über dieselben zwölf Aufträge, einmal frisch gestartet und einmal direkt danach. Und das Ganze zweimal hintereinander, damit eine vorübergehende Störung nicht ein einzelnes Verfahren trifft. Alles bei Temperatur 0 mit festem Startwert, und die erzeugten Texte wurden mitgeschrieben.

Elf Verfahren, und fünf brauchen kein zweites Modell

Der Schalter heißt --spec-type und kennt elf Werte. Sie zerfallen in drei Familien.

Ein zweites, kleineres Modell schlägt vor, das große prüft. Das ist die Bauform, die Leviathan, Kalman und Matias 2022 vorgestellt haben, und dazu gehören vier Einträge: draft-simple, draft-eagle3, draft-dflash und draft-dspark. Sie unterscheiden sich darin, wie eng das Entwurfsmodell an das große gekoppelt ist.

Ein Kopf im Modell selbst übernimmt die Rolle des Entwurfsmodells. Das ist draft-mtp, in der Dokumentation als Use Multi Token Prediction (MTP) heads from the main model (externe Seite, github.com) beschrieben.

Die Wiederholung im schon geschriebenen Text liefert den Vorschlag, ganz ohne Modell. Das sind fünf Einträge: ngram-cache, ngram-simple, ngram-map-k, ngram-map-k4v und ngram-mod. Die Dokumentation sagt es deutlich:

They require no additional model but rely on patterns that have already appeared in the generated text (externe Seite, github.com)

Diese fünf kosten nichts außer einem Schalter. Es gibt sogar eine Voreinstellung, --spec-default, die ngram-mod einschaltet. Mischen ist erlaubt, und die Dokumentation hält fest, wer dabei gewinnt: An implementation with draft model can be mixed with an implementation without draft model (externe Seite, github.com). Das Verfahren ohne Entwurfsmodell hat Vorrang.

Drei Fehlschläge, bevor die erste Zahl stand

Der erste Versuch lief über llama-cli, das Kommandozeilenprogramm. Er lief 73 Minuten und lieferte nichts. Die Dokumentation nennt an jeder ihrer elf Beispielzeilen llama-server, und dafür gibt es einen Grund: Die Verfahren sitzen im Server.

Schlimmer war, was danach geschah. Der vergessene Prozess rechnete weiter, während ich die nächste Messreihe fuhr, und drückte die Vergleichslinie von 157 auf 70 Token je Sekunde. Eine halbierte Messung sieht genauso aus wie eine richtige, wenn niemand daneben schaut. Seitdem protokolliert das Messskript die Systemlast vor und nach jedem Lauf mit, und prompt fand sich ein zweiter Störer: die Medienanalyse von macOS, die während dreier von sechs Varianten mit über 90 Prozent Last mitlief. Diese Messreihe habe ich verworfen und wiederholt.

Der zweite Fehlschlag war eine Anfrage, die ich in der Kommandozeile zusammengesetzt hatte. Ein Zeilenumbruch im Auftragstext zerbrach das JSON, der Server antwortete mit einem Fehler, und mein Auswertungsskript las daraus 0 Token je Sekunde. In der Tabelle stand eine Null, die aussah wie ein Messergebnis.

Der dritte kam vom Modell selbst. Gemma 4 verbrauchte sein ganzes Token-Budget im Denken und lieferte einen leeren Antworttext dazu. Die Zeitmessung stimmte, aber der Textvergleich hätte lauter leere Zeichenketten verglichen und zufrieden Gleichheit gemeldet.

Aus allen drei Fällen sind Riegel im Messskript geworden: Eine Antwort ohne Zeitmessung, eine mit null erzeugten Token und eine mit leerem Text beenden den Lauf. Alle drei sind mit gefälschten Antworten gegengeprüft, in beide Richtungen.

Dazu kam ein Fehler im Aufbau selbst. Zuerst hatte ich denselben Auftrag mehrfach geschickt und die Abweichung Streuung genannt. Gemessen wurde die Aufwärmung eines Caches, den der erste Durchgang gefüllt hatte. Seitdem stehen je Textsorte drei verschiedene Aufträge.

Der Kopf muss in der Datei stecken

Die Vorhersage mehrerer Token stammt aus einer Arbeit von Gloeckle und Mitautoren bei Meta vom April 2024. Sie beschreiben es als Trainingsverfahren:

we ask the model to predict the following n tokens using n independent output heads, operating on top of a shared model trunk (externe Seite, arxiv.org)

Das Ziel war damals eine bessere Ausnutzung der Trainingsdaten. Die zweite Verwendung fand DeepSeek im Dezember 2024 (externe Seite, arxiv.org): Dieselben Köpfe taugen bei der Ausführung als Entwurf, und ein eigenes zweites Modell wird dafür nicht mehr gebraucht.

Das heißt aber auch, dass die Köpfe in der Modelldatei liegen müssen. Ich habe die vier großen Modelle nachgesehen, die auf meinem Rechner liegen, alle als GGUF in der gängigen Vier-Bit-Fassung aus der Sammlung, die LM Studio vorschlägt: Qwen3.6 mit 27 Milliarden, Gemma 4 mit 31 Milliarden, Gemma 4 mit 26 Milliarden und Qwen3.5 mit 35 Milliarden. Keine einzige hat sie.

Die eigens gebaute Fassung desselben Qwen3.6 hat 866 Tensoren, die gewöhnliche 851. Fünfzehn Stück machen den Unterschied, und sie wiegen 436 Megabyte. Der Anbieter stellt sie sogar einzeln bereit. Als Entwurfsmodell neben die vorhandene Datei laden lassen sie sich trotzdem nicht, der Server bricht mit failed to load draft model ab. Wer die Köpfe haben will, lädt die ganze Datei noch einmal herunter: 18 Gigabyte für 436 Megabyte Unterschied.

Wie groß eine Wirkung sein muss, um sichtbar zu werden

Bevor eine einzige Zahl über die Verfahren fällt, gehört eine über die Messung dazu. Derselbe Auftrag, dasselbe Modell, keine Spekulation, nur mehrfach ausgeführt: Die Geschwindigkeit schwankte im Mittel um 22 Prozent, im schlimmsten Fall um 41. Auf dem kleinen Modell lag die Vergleichslinie zwischen 86 und 145 Token je Sekunde, ohne dass sich irgendetwas geändert hätte.

Das ist der Normalzustand eines Rechners, auf dem jemand arbeitet. Es hat aber eine harte Folge: Ein Verfahren, das zehn Prozent bringt, ist auf diesem Gerät nicht messbar. Erst jenseits von etwa einem Viertel in die eine oder andere Richtung lässt sich überhaupt etwas sagen, und auch das nur, wenn beide Durchläufe dasselbe sagen.

Nach diesem Maßstab bleiben von 40 gemessenen Kombinationen aus Verfahren, Textsorte und Durchgang genau acht übrig. Die Zählung betrifft die beiden Modelle, die zweimal durchliefen; das Entwurfsmodell weiter unten kam nur zu einem Durchlauf.

Was übrig bleibt

ngram-mod im zweiten Durchgang. Das ist der eine große Gewinner, und er gewinnt in allen vier Textsorten. Auf dem kleinen Modell zwischen dem 1,8- und dem 5,2-Fachen, auf dem großen zwischen dem 2,3- und dem 4,6-Fachen. Das Verfahren legt einen Vorrat aus gesehenen Wortfolgen an, und der ist beim ersten Durchgang leer. Die Dokumentation erklärt, warum er danach auch fremden Anfragen hilft: Der Vorrat gehört dem Server. Er überdauert die einzelne Anfrage.

draft-mtp beim freien Schreiben. Hier ragt das Ergebnis nach unten heraus: 0,76 und 0,66 in den beiden Durchläufen, also rund ein Drittel langsamer als ganz ohne Spekulation. Ein verworfener Vorschlag ist Rechenzeit ohne Gegenwert.

ngram-cache beim Umschreiben. 0,76 und 0,70, ebenfalls deutlich langsamer.

Alles andere lag im Rauschen. Die vier übrigen Verfahren ohne Zusatzmodell haben über zwei Modelle, vier Textsorten und zwei Durchgänge nichts Messbares bewirkt.

Das zweite Modell, die dritte Familie

Für Gemma 4 mit 31 Milliarden Parametern gibt es einen fertigen Entwurf nach dem EAGLE-3-Verfahren, 2,2 Gigabyte neben den 17 des Hauptmodells. Er war in dieser Messung das langsamste Verfahren im ganzen Feld: 0,28-fach beim Umschreiben, 0,27 beim Zusammenfassen und beim freien Schreiben, 0,54 im Code. Die Annahmequoten erklären es, sie lagen bei 7 bis 15 Prozent, im Code bei 55.

Hier gehört eine Einschränkung dazu, die den Befund begrenzt. Der Entwurf ist für dieses Modell gebaut, aber von dritter Seite in das Ausführungsformat gebracht, und mein Hauptmodell stammt aus einer anderen Sammlung mit einer anderen Quantisierung. Das ist nicht die Paarung, die der Hersteller vorsieht. Gemessen habe ich außerdem nur einen Durchlauf, und davon nur die erste Hälfte: Im zweiten Teil lief eine Datensicherung mit und drückte die Vergleichslinie von 19 auf 6 bis 19 Token je Sekunde. Der erste Teil lag stabil zwischen 18,7 und 20,4.

Die Kennzahl, die wirklich stabil ist

An dieser Stelle wurde die Messung interessanter als geplant. Neben der Geschwindigkeit gibt der Server eine zweite Zahl aus: wie viele der Vorschläge das große Modell übernommen hat. Ich habe beide auf ihre Wiederholbarkeit geprüft, über die zwei Durchläufe derselben Messung.

	Abweichung zwischen zwei Durchläufen
Token je Sekunde, kleines Modell	im Mittel 14,4 %, größte 49,2 %
Token je Sekunde, großes Modell	im Mittel 2,8 %, größte 11,3 %
Anteil übernommener Vorschläge	0,0 %

Die Annahmequote war in jeder der 33 geprüften Kombinationen auf die Nachkommastelle identisch. Sie hängt am Modell und am Text, und bei Temperatur 0 folgt daraus ein fester Wert. Die Geschwindigkeit hängt zusätzlich daran, was der Rechner sonst gerade tut.

Damit lässt sich der Nutzen abschätzen, ohne dem eigenen Zeitmesser zu trauen:

Verfahren	umschreiben	Code	zusammenfassen	frei schreiben
draft-mtp, großes Modell	95 %	97 %	55 %	37 %
draft-eagle3, Gemma 4 31B	15 %	55 %	7 %	7 %
ngram-mod, zweiter Durchgang	100 %	77 %	100 %	97 %
ngram-mod, erster Durchgang	0 %	3 %	0 %	0 %
ngram-cache	22 %	0 %	6 %	0 %
ngram-simple	3 %	12 %	3 %	0 %
ngram-map-k und ngram-map-k4v	8 %	0 %	0 %	0 %

Die Tabelle erklärt beide belastbaren Befunde von oben. draft-mtp bringt dort etwas, wo es 95 Prozent trifft, und schadet dort, wo es auf 37 fällt. Zwischen beidem liegt die Schwelle, ab der ein Verfahren mehr kostet, als es einbringt.

Sie erklärt auch, warum eine hohe Quote allein nicht genügt: ngram-cache bringt beim Umschreiben 22 Prozent unter und ist trotzdem das langsamste Verfahren im Feld. Was das Vorschlagen selbst kostet, zählt mit.

Die Ausgabe war nicht immer dieselbe

Von 96 Läufen am großen Modell lieferten 86 denselben Text wie der Lauf ohne Spekulation, also knapp 90 Prozent. Beim kleinen Modell waren es 230 von 240. Alle Abweichungen am großen Modell traten beim freien Schreiben auf, und es sind keine Kleinigkeiten:

	Schluss desselben Absatzes
ohne Spekulation	… in dem Zeit und Raum ihre gewohnte Bedeutung verloren hatten.
mit draft-mtp	… in dem Zeit und Raum ihre Bedeutung verloren.

Gemessen bei Temperatur 0 und festem Startwert, also unter den Bedingungen, unter denen man Wiederholbarkeit erwartet.

Überraschend ist es nur, wenn man die Zusage zu weit liest. Leviathan und Mitautoren versprechen 2022, dass die Verteilung erhalten bleibt, aus der gezogen wird (externe Seite, arxiv.org). Chen und Mitautoren von DeepMind formulieren drei Monate später denselben Satz mit einem Nebensatz, den man leicht überliest:

preserves the distribution of the target model within hardware numerics (externe Seite, arxiv.org)

Im Rahmen der Rechengenauigkeit der Hardware. Die Dokumentation von llama.cpp sagt für die Praxis dasselbe: Use greedy sampling when exact output matching is required (externe Seite, github.com). Temperatur 0 über die Schnittstelle reicht dafür offenbar nicht.

Für die Beurteilung heißt das: Ein Vergleich zweier Aufbauten misst zwei verschiedene Dinge, wenn auf einer Seite spekuliert wird. Wie das Annahmekriterium arbeitet und warum die Verteilung trotzdem stimmt, steht in Grundkurs, Kapitel 12.

Was sonst noch am Tempo dreht

Die Verfahren oben sind der jüngste Hebel. Drei ältere aus eigenen Messungen sind größer.

Die Bauform schlägt die Größe. Am 17.08.2026 habe ich zwei Modelle mit praktisch gleicher Dateigröße gegeneinander gemessen: Qwen3.8 mit 27,78 Milliarden Parametern, die alle bei jedem Token rechnen, gegen Gemma 4 26B-A4B, ein Mixture-of-Experts-Modell mit rund vier Milliarden aktiven. Faktor 6,4 in der Antwortzeit, zugunsten des zweiten. Das langsamere lief dabei in der besseren Fassung, nämlich mit vier statt drei Bit. Eine gröbere Speicherung senkt die Last auf dem Speicherbus, und sie ändert nichts daran, dass jeder Parameter gelesen wird.

Der Unterbau kann gegen die Erwartung ausfallen. Apples eigenes Rechenframework MLX (externe Seite, github.com) gilt auf Apple-Rechnern als der schnellere Weg, und eine Fremdmessung hatte ihm 35 Prozent Vorsprung zugeschrieben. Am 30.05.2026 habe ich es nachgemessen: Dasselbe Modell in derselben Größe brauchte über MLX 405 Millisekunden und über llama.cpp 187, dazu anderthalb Gigabyte mehr Speicher. Das viel größere Gemma 4 über llama.cpp war mit 332 Millisekunden immer noch schneller als das kleine über MLX. Was MLX besser kann, gehört dazu: Es rechnet bitgenau wiederholbar.

Ein Werkzeug-Update allein verschiebt die Zahlen. Zwischen llama.cpp b8920 und b9430 liegen rund 500 Bauläufe. Am 14.06.2026 gemessen, mit unveränderten Modelldateien, über 25 Aufnahmen in fünf Wiederholungen:

Modell	mit b8920	mit b9430
Qwen3-4B, klassisch aufgebaut	222 ms	180 ms
Qwen3.5-4B, hybrid aufgebaut	249 ms	282 ms

Das eine wurde 19 Prozent schneller, das andere langsamer. Die Lücke wuchs von 12 auf 56 Prozent. Ein Update beschleunigt Architekturen verschieden.

Wie weit das reicht, zeigt ein Blick auf dieselbe Zeile in einem anderen Text: Im Bericht über die eigene Diktier-App steht für Qwen3-4B 260 Millisekunden. Das ist der Lauf vom 19.04.2026 mit einer anderen Auftragsfassung und einem älteren Programmstand. Dieselbe Datei, dasselbe Gerät, drei Zahlen über zwei Monate. Eine Messung vom Frühjahr sagt im Sommer wenig.

Woran diese Zahlen hängen

An einem Gerät, an einem Tag, an einer Programmfassung. Und am freien Speicher: In einem älteren Entscheidungsprotokoll steht die Beobachtung vom 30.04.2026, dass dieselbe Aufgabe rund 300 Millisekunden braucht, solange das Modell im Seitencache liegt, und mit drei großen Browsersitzungen daneben sprunghaft auf mehrere Sekunden steigt.

Wer es nachstellen will, sollte zwei Dinge mitnehmen. Messen Sie Ihre eigene Streuung, bevor Sie einem Faktor glauben: zehnmal derselbe Auftrag ohne jede Änderung, und die Spanne ist die Grenze, unterhalb derer nichts zu sehen ist. Und sehen Sie auf die Annahmequote statt auf die Sekunden. Sie steht in der Antwort des Servers, sie ist reproduzierbar, und sie sagt vor der ersten Zeitmessung, ob ein Verfahren für Ihre Art von Texten überhaupt in Frage kommt.