ReaDy nutzt rekurrente Modellzustände für schnellere spekulative LLM-Inferenz

Warum rekurrente Zustände als Kontextquelle dienen

Hybride Linear-Attention-Modelle kombinieren rekurrente Schichten mit vollständigen oder sparsamen Attention-Schichten. Die rekurrenten Komponenten führen kompakte Zustände, in denen historische Zusammenhänge zusammengefasst werden; Attention-Schichten arbeiten weiterhin mit tokenbezogenen Schlüssel-Wert-Caches. Die kompakte Zustandsdarstellung gilt daher nicht für den gesamten Speicherbedarf des Modells. [3] [4]

Nach Darstellung der Autoren können Drafter, die sich auf bereits bereitgestellte verborgene Merkmale des Zielmodells stützen, für spätere Positionen eines Token-Blocks nicht unbedingt die jeweils benötigten Kontextbeziehungen abfragen. Ein Zugriff auf einen tokenweisen KV-Cache könnte zusätzliche Abrufe ermöglichen, würde aber mit der Länge des Präfixes mehr Daten umfassen. ReaDy nutzt stattdessen die rekurrenten Zustände als ergänzende Quelle, deren Größe in der beschriebenen Zustandsdarstellung nicht mit jedem verarbeiteten Token wächst. [2] [4]

Diese Motivation ist enger gefasst als die Behauptung, verborgene Merkmale enthielten grundsätzlich nicht genug Information. Die theoretische Analyse des Papers betrachtet idealisierte, abfrageabhängige Lesezugriffe auf einen Zustand. Sie zeigt nach der Darstellung auf alphaXiv nicht, dass die vollständigen mehrschichtigen Merkmale des Drafters unzureichend sind. Außerdem können gespeicherte Zustände keine Informationen über Schreibvorgänge rekonstruieren, die das Zielmodell erst während einer noch unbekannten Fortsetzung vornehmen würde. [3] [4]

• ReaDy greift pro Draft-Position mit einer gelernten Abfrage auf dieselben Zustände des bereits bestätigten Präfixes zu. [2] [4]
• Der Zielgenerator bleibt für die Prüfung der Vorschläge zuständig; verworfene Fortsetzungen liefern keine Zustände für die nächste Runde. [3] [4]

Positionsabhängiges Lesen statt größerem Token-Cache

Der Drafter leitet für jede Position eine eigene Abfrage aus seiner Repräsentation ab. Ein leichter „State Reader“ liest damit passende Informationen aus den ausgewählten rekurrenten Zuständen und führt sie als Residual-Update in die Draft-Repräsentation zurück. Der parallele Backbone und der sequenzielle Vorhersagekopf von DSpark bleiben erhalten. [1] [2] [4]

In der beschriebenen Konfiguration sitzt der Reader in der letzten Draft-Schicht. Er verwendet einen Rang-8-Engpass; die rekurrenten Zustände des Zielmodells behalten dabei ihre ursprüngliche Größe von 128 mal 128. Der Reader komprimiert also seine eigenen Leseoperationen, nicht die Zustände des Zielmodells auf dieselbe Weise. Als Standardquellen nennt die Paper-Zusammenfassung die Zielmodellschichten 30 und 62, jeweils nullbasiert. [3] [4]

Trainingsaufbau und Vergleichsmaßstab

Für die Versuche nutzte das Team Qwen3.8-27B als Zielmodell und initialisierte den Drafter aus einem vortrainierten DSpark-Modell. Das Zielmodell blieb während der Anpassung eingefroren. In der ersten Trainingsphase wurde laut Paper der Reader mit 20.000 Beispielen trainiert, während der Drafter eingefroren blieb. In einer zweiten Phase trainierten die Autoren den Reader gemeinsam mit LoRA-Parametern des Drafters auf 50.000 Beispielen weiter. Als Trainingsdaten nennt die Arbeit Open-PerfectBlend. [4]

Diese Trainingsschritte sind wichtig für die Interpretation des Vergleichs: ReaDy wird nicht nur um den Zustandszugriff erweitert, sondern auch angepasst. Die Autoren weisen selbst darauf hin, dass der Vergleich mit dem vortrainierten DSpark deshalb sowohl die zusätzliche Anpassung als auch den Zustandszugriff umfasst. Ein Kontrolllauf, in dem DSpark ohne Zustandszugriff feinabgestimmt wurde, soll den Beitrag der Anpassung isolierter einordnen. [3] [4]

Der Testaufbau verwendete Greedy-Decoding bei Temperatur null, eine Draft-Blockgröße von sieben Tokens, Parallelität eins und eine NVIDIA B200 pro Modellinstanz. Die sieben Benchmarks waren GSM8K und MATH500 für Mathematik, HumanEval, MBPP und LiveCodeBench für Programmierung sowie MT-Bench und eine feste Alpaca-Auswahl für Dialog beziehungsweise Instruktionsbefolgung. [3] [4]

• Der ausgewiesene Durchsatz zählt serverseitig erzeugte Tokens pro Sekunde und schließt Prefill aus. [3] [4]
• Die Akzeptanzlänge bezeichnet generierte Tokens pro Verifikationsrunde und schließt auch vom Zielmodell gelieferte Tokens ein. Sie ist daher nicht gleichbedeutend mit der Zahl akzeptierter Draft-Tokens allein. [3] [4]

Das sagen die Messwerte

Über alle Benchmarks hinweg meldet das Paper einen mittleren Durchsatz von 302,78 Tokens pro Sekunde für ReaDy, 280,42 für das vortrainierte DSpark und 95,86 für autoregressive Generierung. Daraus ergibt sich der angegebene Faktor von 3,16 gegenüber autoregressiver Generierung sowie ein Plus von 7,97 Prozent gegenüber DSpark. Die mittlere Akzeptanzlänge beträgt laut Tabelle 4,53 gegenüber 4,17 bei DSpark. [2] [4]

ReaDy lag in der Tabelle bei jedem der sieben Benchmarks beim Durchsatz über DSpark. Die Unterschiede reichten von 6,43 Prozent bei MATH500 bis 9,83 Prozent bei der Alpaca-Auswahl. Für GSM8K weist die Tabelle beispielsweise 393,60 gegenüber 362,25 Tokens pro Sekunde aus; für LiveCodeBench 234,28 gegenüber 219,23. [3] [4]

Die Zahlen sollten nicht als universelle Serving-Prognose gelesen werden. Sie messen eine konkrete Kombination aus Modell, GPU, Dekodiermodus, Blockgröße und Parallelität. Insbesondere schließen die Durchsatzwerte das Prefill aus; sie beschreiben damit nicht die gesamte Zeit vom Eingang einer Anfrage bis zur fertigen Antwort. [3] [4]

Der Kontrollvergleich relativiert den Abstand zu DSpark

Im zusätzlichen Vergleich stieg DSparks Durchsatz durch Feinabstimmung ohne Zustandszugriff von 280,42 auf 286,50 Tokens pro Sekunde; die Akzeptanzlänge stieg von 4,1739 auf 4,2732. ReaDy erreichte 302,78 Tokens pro Sekunde und eine Akzeptanzlänge von 4,5285. Gegenüber diesem feinabgestimmten Kontrollmodell betrugen die Vorsprünge demnach 5,68 Prozent beim Durchsatz und 5,97 Prozent bei der Akzeptanzlänge. [3]

Das spricht in den berichteten Tests für einen zusätzlichen Nutzen der zustandskonditionierten Anpassung. Es belegt aber nicht, dass der Zustandszugriff allein den gesamten Unterschied erklärt: ReaDy kombiniert Reader, Anpassungsstrategie und eine veränderte Nutzung des Drafters. Die Autoren führen zudem Ablationen zu Reader-Kapazität, Zustandsquellen und Position der Residualintegration auf; die verfügbaren Textauszüge enthalten jedoch nicht alle Ergebnisse dieser Untersuchungen. [2] [3] [4]

Auch der gemeldete Geschwindigkeitsgewinn durch optimierte Operatoren ist von der Ende-zu-Ende-Leistung zu trennen. Die Autoren berichten, dass Optimierungen die Latenz des State Gather von 16,388 auf 4,622 Mikrosekunden und die des State Readers von 65,519 auf 47,094 Mikrosekunden senkten. Das sind Messungen einzelner Operationen, keine direkte Aussage über die Latenz einer vollständigen Nutzeranfrage. [4]

• Die Optimierungen umfassen laut Paper unter anderem fusionierte Abläufe zum Einsammeln und Aufbereiten der Zustände sowie weniger Zwischenkopien. [4]
• Die angegebene Reduktion der Gather-Latenz beträgt 71,8 Prozent, die des State Readers 28,1 Prozent; diese Werte gelten für die jeweiligen Operatoren. [4]

Bedeutung für den Unternehmenseinsatz

Für Unternehmen mit hohen Generierungskosten ist der Ansatz vor allem als Optimierung der Inferenz zu verstehen: Wenn ein Zielmodell pro Verifikationsrunde mehr passende Draft-Tokens bestätigt, kann es bei geeigneten Aufgaben weniger Zielmodell-Runden für dieselbe Ausgabe benötigen. Die berichteten Durchsatzwerte liefern dafür einen Hinweis unter den getesteten Bedingungen, aber keine belastbare Hochrechnung auf andere Hardware, Auslastungsgrade oder Anfrageprofile. [3] [4]

Die Architektur setzt außerdem voraus, dass der Drafter auf rekurrente Zustände des Zielmodells zugreifen kann. Daraus folgt als technische Integrationsbedingung, dass ein Einsatz nicht allein durch das Aktivieren einer allgemeinen Serving-Option entsteht: Modellarchitektur, Zugriff auf interne Zustände, Anpassung des Drafters und kompatible Laufzeitoperatoren müssen zusammenspielen. Das Paper beschreibt solche Bausteine für Qwen3.8-27B und eine einzelne B200-GPU; die Quellen belegen keine breite Unterstützung anderer Modellfamilien oder Inferenzplattformen. [3] [4]

Für eine Beschaffungs- oder Kapazitätsplanung sollten Sie daher insbesondere prüfen, ob der eigene Workload dem Testsetting ähnelt, wie sich die Verifikation bei höherer Parallelität verhält und ob zusätzliche Reader- und Speicherzugriffe den Gewinn unter realer Last erhalten. Das sind offene Evaluationsfragen, keine im Paper nachgewiesenen Ergebnisse. Ebenso enthalten die bereitgestellten Quellen keine unabhängige Replikation der Benchmarks. [2] [3] [4]

Einordnung: vielversprechender Befund, eng begrenzte Evidenz

Die technische Neuerung von ReaDy liegt weniger in einem anderen Verifikationsprinzip als in der Art, wie der Drafter Kontext für spätere Blockpositionen abruft. Rekurrente Zustände werden positionsspezifisch gelesen, während die etablierte Prüfung durch das Zielmodell bestehen bleibt. Das macht den Ansatz vor allem für hybride Modelle mit zugänglicher rekurrenter Erinnerung relevant. [1] [2] [4]

Die Autoren bezeichnen ReaDy nach eigener Kenntnis als erstes spekulatives Decoding-Verfahren, das HLA-Zustände für positionsspezifischen Kontextzugriff beim Drafting nutzt. Diese Prioritätsangabe ist als Aussage der Autoren zu verstehen, nicht als unabhängige Bestätigung. Ebenso sind die Leistungswerte Ergebnisse aus dem Paper und nicht aus einer externen Vergleichsstudie. [1] [2]

Für die Bewertung im Unternehmenskontext sind deshalb drei Ebenen auseinanderzuhalten: die algorithmische Idee des gezielten Zustandslesens, die unter kontrollierten Bedingungen gemessene Leistung und der mögliche Nutzen im jeweiligen Produktionssystem. Belegt sind die ersten beiden Ebenen für die beschriebene Konfiguration; Aussagen zu Kostenersparnis, allgemeiner Skalierbarkeit oder Produktivbetrieb lassen sich aus den verfügbaren Quellen nicht ableiten. [2] [3] [4]

• Die Arbeit berichtet eine Verbesserung gegenüber DSpark in allen sieben getesteten Benchmarks, aber nur in einem einzelnen Modell- und GPU-Setup. [3] [4]
• Der Abstand wird kleiner, wenn DSpark ebenfalls feinabgestimmt wird; damit ist die isolierte Wirkung des Zustandszugriffs nicht vollständig bestimmt. [3]
• Die verfügbaren Quellen beschreiben keine unabhängige Replikation und belegen keine Ergebnisse bei anderer Parallelität oder anderer Hardware. [2] [3] [4]

Quellen

1. [1] Paper page - ReaDy: Recurrent States as Dynamic Context for Speculative Drafting in Hybrid Linear Attention Large Language Models — https://huggingface.co/papers/2610.20503 (abgerufen am 2026-10-19)
2. [2] [2610.20503] ReaDy: Recurrent States as Dynamic Context for Speculative Drafting in Hybrid Linear Attention Large Language Models — https://arxiv.org/abs/2610.20503 (abgerufen am 2026-10-19)
3. [3] ReaDy: Recurrent States as Dynamic Context for Speculative Drafting in Hybrid Linear Attention Large Language Models | alphaXiv — https://www.alphaxiv.org/abs/2610.20503 (abgerufen am 2026-10-19)
4. [4] ReaDy: Recurrent States as Dynamic Context for Speculative Drafting in Hybrid Linear Attention Large Language Models — https://arxiv.org/html/2610.20503 (abgerufen am 2026-10-19)