Was ist die Akzeptanzrate beim Speculative Decoding und warum ist sie wichtig?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Die Akzeptanzrate beim spekulativen Decoding misst, wie oft die Verifizierung durch das Zielmodell vorgeschlagene Entwurfstokens beibehält, und bestimmt damit direkt den nützlichen Arbeitsfortschritt pro Verifizierungslauf.

Ein kleineres Entwurfsmodell kann mehrere zukünftige Tokens vorschlagen, während ein größeres lokales Modell sie parallel verifiziert. Wenn die meisten Vorschläge bestehen bleiben, bringt ein teurer Durchlauf des Zielmodells die Antwort um mehrere Positionen voran; bei einer frühen Ablehnung wird ein großer Teil der Entwurfsarbeit verworfen. Die Rate ist daher ein von der Arbeitslast abhängiges Effizienzsignal, keine eigenständige Genauigkeitsbewertung und keine Garantie für eine Beschleunigung von Anfang bis Ende.

Die Akzeptanz zählt den verifizierten Fortschritt des Entwurfs

Beim standardmäßigen spekulativen Sampling schlägt das Entwurfsmodell einen Block vor, und das Zielmodell bewertet diese Positionen gemeinsam. Tokens werden der Reihe nach akzeptiert, bis die erste Ablehnung erfolgt. Anschließend sampelt der Algorithmus eine Korrektur und startet eine weitere spekulative Runde.

Das ursprüngliche Paper zum spekulativen Decoding definiert eine Akzeptanzwahrscheinlichkeit anhand der Beziehung zwischen Entwurfs- und Zielverteilungen, wobei die Ausgabeverteilung des Zielmodells erhalten bleibt. Der entscheidende Wert ist der akzeptierte Fortschritt, nicht die visuelle Ähnlichkeit zwischen den Antworten der Modelle.

Implementierungen können akzeptierte Tokens geteilt durch vorgeschlagene Tokens, die durchschnittliche akzeptierte Länge oder die Akzeptanzwahrscheinlichkeit angeben. Diese Metriken hängen zusammen, sind aber nicht identisch. Daher müssen Vergleiche dieselbe Definition und Entwurfslänge verwenden. Dieser Unterschied bleibt auch bei späteren Tests im Haushalt sichtbar.

Entwurfsqualität und Sampling-Richtlinien verändern die Rate

Ein Entwurf, der hinsichtlich der aktuellen Sprache, Domäne und Eingabe näher am Zielmodell liegt, schlägt tendenziell mehr akzeptable Fortsetzungen vor. Temperatur, Top-p, Tokenizer-Ausrichtung, Entwurfslänge und die Sicherheit des Zielmodells beeinflussen ebenfalls, wie oft ein Block bestehen bleibt.

Online Speculative Decoding passt den Entwurf anhand des Feedbacks des Zielmodells an und zeigt, dass eine Verbesserung der Token-Akzeptanzrate die Latenz bei wechselnden Anfrageverteilungen senken kann. Das Ergebnis zeigt, dass sich die Akzeptanz mit der Arbeitslast verändern kann, anstatt eine feste Eigenschaft eines Modellpaars zu bleiben.

Ein größerer Entwurf kann die Akzeptanz erhöhen, verursacht aber höhere Ausführungskosten; ein kleinerer Entwurf ist günstig, kann jedoch häufig abgelehnt werden. Die sinnvolle Wahl gleicht den akzeptierten Fortschritt gegen die Zeit für Entwurf und Verifizierung ab. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung darauf aufbaut.

Eine hohe Akzeptanz ist für eine Beschleunigung notwendig, aber nicht ausreichend

Der tatsächliche Gewinn hängt außerdem davon ab, wie effizient das Zielmodell einen Block verifizieren kann, sowie von der Entwurfslatenz, dem Speicherverkehr, der Synchronisierung, der Batch-Größe und den Kosten verworfener Arbeit. Ein hoher Anteil bei kurzen Blöcken kann weniger serielle Schritte einsparen als ein mittlerer Anteil bei angemessen dimensionierten Blöcken.

Medusa ersetzt ein separates Entwurfsmodell durch mehrere Decoding-Köpfe, die mehrere Fortsetzungen aus der Repräsentation des Zielmodells vorschlagen. Das Design zeigt, dass Vorschlagsarchitektur und Verifizierung denselben Durchsatzkompromiss bestimmen. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.

Die Fehlergrenze liegt bei einer Arbeitslast, bei der Entwurf und Verifizierung zusammen genauso viel kosten wie gewöhnliches Decoding. Code, mehrsprachige Texte, kreatives Sampling oder Domänenwechsel können die akzeptierte Länge so weit verringern, dass die Spekulation zusätzlichen Speicher verbraucht, ohne die Latenz zu senken.

Akzeptierten Fortschritt pro Millisekunde messen

Erfasse für jede Prompt-Klasse vorgeschlagene Tokens, akzeptierte Tokens, die Länge des akzeptierten Präfixes, Entwurfszeit, Verifizierungszeit des Zielmodells, Ablehnungsposition, Gesamtlatenz, Tokens pro Sekunde, Speicherverbrauch und Prüfungen der Ausgabegleichheit. Die praktische Bedeutung zeigt sich, wenn mehrere Quellen um begrenzten Kontext konkurrieren.

Setze die Arbeitslast in Beziehung zur Sampling-Richtlinie. Variiere Entwurfslänge und Sampling-Einstellungen, während Zielmodell und angeforderte Verteilung unverändert bleiben, und vergleiche die Ergebnisse anschließend mit gewöhnlichem autoregressivem Decoding. Diese Abhängigkeit sollte in der endgültigen Benutzeroberfläche ausdrücklich sichtbar bleiben.

Aktiviere Spekulation nur dort, wo sich der akzeptierte Fortschritt pro gesamter Millisekunde verbessert. Wenn die Akzeptanz hoch erscheint, die Latenz aber nicht sinkt, sollten Entwurfs- und Verifizierungs-Overhead optimiert werden, anstatt das Verhältnis als endgültige Leistungsmetrik zu behandeln. Das Ergebnis muss daher anhand der ursprünglichen Belege überprüft werden.

Tech- & KI-Zentrum

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.