Spekulatives Decoding wurde ausgeliefert, weil es die Ausgabe nicht verändert.

Liquid AI hat LFM2.5-DSpark am 20. August 2026 ausgeliefert: drei Draft-Modelle, die auf LFM2.5 1.2B-Instruct, LFM2.5 2.6B und LFM2.5 8B-A1B (eine MoE) abzielen, unter der lfm1.0-Lizenz. Die Schlagzeilenzahlen sind eine mittlere 2,67×-Beschleunigung auf H100 und 2,27× auf M4 Max gegen das 2.6B-Ziel, mit einem Spitzenwert von 3,06× auf MATH500. Die Schlagzeile ist das am wenigsten Interessante an dieser Veröffentlichung. Das Interessante ist, warum diese Art von Veröffentlichung überhaupt in Produktion ausgeliefert werden kann, am ersten Tag, ohne Erweiterung der Evaluations-Suite und ohne Rollback-Plan.

Was spekulatives Decoding ist

Das Muster ist einfach. Ein kleines Draft-Modell schlägt eine kurze Token-Folge vor; das Zielmodell verifiziert sie parallel, akzeptiert, was übereinstimmt, verwirft den Rest und setzt ab der ersten zurückgewiesenen Position fort. Drei Zahlen kennzeichnen einen Zyklus: Draft-Länge (wie viele Token der Draft-Modell pro Schritt vorschlägt), Akzeptanzrate (wie viele der Verifier akzeptiert) und effektive Token-pro-Schritt (der realisierte Durchsatzgewinn).

Die entscheidende Eigenschaft ist Exaktheit unter Greedy Decoding. Wenn der Verifier argmax verwendet und einen Draft-Token akzeptiert, ist dieser Token byte-identisch mit dem, was das Zielmodell allein erzeugt hätte. Der Ausgabestrom ist byte-identisch mit nicht-spekulativem Greedy Decoding. Die gesamte Familie von EAGLE, Medusa, DFlash, DSpark handelt mit dieser Eigenschaft. Ohne sie wäre spekulatives Decoding ein Quantisierungsproblem mit schlechterer Werkzeugunterstützung, kein kostenloses Mittagessen.

Was DSpark tatsächlich tut

Die interessante Designentscheidung ist das, was nicht da ist. Das Paper (arXiv:2607.05147, Cheng et al., DeepSeek-AI + PKU) beschreibt einen confidence-scheduled Markov-Kopf-Draft, geschichtet auf der DFlash-/EAGLE-3-Linie. Ein Confidence-Scheduler wurde gebaut, um Drafts mit niedriger Konfidenz zur Inferenzzeit dynamisch zu kürzen. Er blieb dormant. Dynamisches Trimmen schadete mehr als es nutzte. DSpark liefert die einfachere, statische Version aus, weil die einfachere Version auf realen Benchmarks gewinnt.

Dies ist eine Haltungsaussage. Die Familie des spekulativen Decodings jagt seit drei Generationen dynamischer Anpassung hinterher. EAGLE-2 führte die Baum-von-Token-Idee ein, bei der das Draft-Modell mehrere Kandidaten an Verzweigungspunkten vorschlägt und der Verifier das längste akzeptierte Präfix auswählt. EAGLE-3 verfeinerte den Kopf; DFlash (arXiv:2602.06036) verallgemeinerte den Markov-Kopf zu einem confidence-scheduled Mechanismus. DSpark liefert statisch aus. Die dynamische Maschinerie ist gebaut und dormant. Die statische Version gewann. Haltung zählt, wenn die Familie seit drei Generationen klettert und die Veröffentlichung das Fundament ausliefert.

Die Zahlen

Die Tabelle ist das Rückgrat.

Draft-Ziel	Akzeptanzlänge	H100 Mittel	M4 Max Mittel	MATH500 Spitze
LFM2.5-1.2B-Instruct	—	—	—	—
LFM2.5-2.6B	4,81	2,67×	2,27×	3,06×
LFM2.5-8B-A1B (MoE)	—	—	1,18×	—

Zwei Extras, die es wert sind, genannt zu werden. BFCL-Funktionsaufruf-Latenz: 57 % Reduktion auf M4 Max gegen das 2.6B-Ziel (BFCL ist in PMLR v267). Confidence-scheduled Verifikation: gebaut, aber nicht verwendet; der veröffentlichte Checkpoint nutzt statisches Drafting.

Die ehrliche Schwäche ist die Zeile 8B-A1B auf M4 Max: 1,18×. MoE-Routing plus Draft-Modell-Speicherbandbreite sättigen den Unified-Memory-Bus, bevor der Draft-Pfad hilft. Die Veröffentlichung hat den 8B-A1B-Draft trotzdem ausgeliefert, und das ist die richtige Entscheidung: Eine ehrliche Zahl auf einer realen Arbeitslast ist nützlicher als eine herausgepickte. Der 8B-A1B-Draft ist nicht unbrauchbar; er ist nur nicht die Schlagzeile.

Warum Exaktheit unter Greedy das ganze Spiel ist

Die übertragbare Regel. Jede Inferenz-Optimierung, die die Ausgaben nicht verändert, ist ein kostenloses Mittagessen: A/B-Parität, keine erneuten Evaluations-Suite-Läufe, keine goldenen Regressionstraces, kein Rollback-Plan. Optimierungen, die die Ausgaben verändern (Post-Training-Quantisierung, Destillation, Pruning, Kernel-Fusion mit numerischer Drift), brauchen Evaluations-Suites, goldene Traces und einen Rollback-Plan. Spekulatives Decoding unter Greedy braucht nichts davon.

Die Kostenrechnung ist asymmetrisch. Exaktheit wird ausgeliefert. Nicht-Exaktheit budgetiert. Das ist der Grund, warum jeder Produktions-Serving-Stack, den ich ausgeliefert oder auditiert habe, spekulatives Decoding auf dem Hot Path hat, und fast keiner von ihnen Post-Training-Quantisierung auf dem Hot Path ohne Evaluations-Gate. Die Entscheidung wurde nicht anhand von Beschleunigungszahlen getroffen; sie wurde danach getroffen, ob die Änderung ein Qualitäts-Gate brauchte. Spekulatives Decoding braucht keines. Die 2,67× sind der Bonus.

Dies ist die Umkehrung der byte-identical-still-broken-Eigenschaft. Dort sollte eine Transformation byte-identisch zu einer Referenz sein und war es nicht; der Bruch wurde unter Last entdeckt. Hier ist Byte-Identität die tragende Eigenschaft, und sie ist exakt unter der spezifischen Decoder-Konfiguration, auf die die Familie abzielt (Greedy). Beide Beiträge handeln von der Differenz zwischen einer Eigenschaft, die das System beansprucht, und der Eigenschaft, die das System hat. DSpark liegt auf der Seite, wo der Anspruch zur Eigenschaft passt. Das ist der Grund, warum es unter lfm1.0 mit SGLang-Integration in Arbeit (PR #31041) und Metal-Kernels in llama.cpp ausgeliefert werden kann.

Wo dies verallgemeinerbar ist

Der Leser sollte mit einem übertragbaren Test gehen. Wenn Sie eine Inferenz-Optimierung bewerten, stellen Sie eine Frage: verändert sie die Ausgaben unter Greedy Decoding?

Wenn nein, liefern Sie sie ohne Evaluations-Suite aus. Wenn ja, budgetieren Sie eine.

Die Frage gilt für jede Serving-Entscheidung der nächsten zwei Jahre: KV-Cache-Komprimierung, Paged Attention, kontinuierliches Batching, Prefix-Caching, Quantisierungs-Kernels, Draft-Modelle, MoE-Experten-Pruning. Jede einzelne verändert entweder die Ausgaben oder nicht, und diese einzige Eigenschaft bestimmt, ob das Rollout ein Qualitäts-Gate braucht. Beschleunigung ist irrelevant, bis die Frage beantwortet ist. Meistens ist die Antwort „nein” (die Optimierung ist exakt unter Greedy), und die Antwort ist die Freigabe. Manchmal ist die Antwort „ja”, und die Frage ist, ob die Beschleunigung die Evaluations-Suite-Steuer wert ist. Beide Fragen leben stromabwärts der ersten.

Die Falle

Die Falle besteht darin, die Beschleunigungszahlen als das Ergebnis zu lesen. Sie sind der Nebeneffekt. Das Ergebnis ist, dass Liquid AI drei Draft-Modelle unter einer permissiven Lizenz ausgeliefert hat, die auf drei verschiedene Zielgrößen abzielen, am ersten Tag, mit SGLang-Integration in Arbeit und Metal-Kernels in llama.cpp. Das Ergebnis ist, dass der Engpass für das Serving von LFM2.5 auf Apple Silicon nicht mehr Compute ist; es ist die Speicherbandbreite auf dem Draft-Pfad. Das Ergebnis ist, dass ein Confidence-Scheduler gebaut, evaluiert und dormant gelassen wurde, weil die statische Version die richtige Entscheidung war.

Omarchy-Kontinuität. Sichtbare Eigenschaften (Exaktheit unter Greedy) wurden ausgeliefert. Verborgene Eigenschaften (dynamische Anpassung) wurden auf das Regal gelegt. Die gesamte Veröffentlichung ist ein einziges Argument: Die Technik ist auslieferbar, weil die Eigenschaft, die sie beansprucht, die Eigenschaft ist, die sie hat, und die Eigenschaft, die sie beansprucht, ist Exaktheit unter einem bestimmten Decoder. Spekulatives Decoding hat diese Eigenschaft immer beansprucht. DSpark ist die Veröffentlichung, in der der Anspruch zum Benchmark passt, der Benchmark zur Arbeitslast passt und die Arbeitslast zum Produktions-Stack passt. Die 2,67× sind die Schlagzeile. Die Byte-Identität ist das Ergebnis.