💬 NLP

D-cut: Adaptive Verification Depth Pruning for Batched Speculative Decoding

D-Cut ist eine adaptive Methode zur Beschneidung der Verifizierungstiefe für gebatchtes spekulatives Dekodieren, die Verifizierungsbudgets basierend auf der Entwurfs-Konfidenz und Laufzeitkostenmodellen dynamisch über konkurrierende Anfragen verteilt, wodurch die Inferenzgeschwindigkeit unter hoher Konkurrenz signifikant verbessert wird, während gleichzeitig verschwendete Berechnungen bei verworfenen Token verhindert werden.

Ursprüngliche Autoren: Tianyu Liu, Yuhao Shen, Rui Cen, Junhan Shi, Jiebin Zhang, Guangshuo Qin, Hong Liu, Song Liu, Guanghua Yu, Jianchen Zhu

Veröffentlicht 2026-07-17

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Tianyu Liu, Yuhao Shen, Rui Cen, Junhan Shi, Jiebin Zhang, Guangshuo Qin, Hong Liu, Song Liu, Guanghua Yu, Jianchen Zhu

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie leiten eine riesige, Hochgeschwindigkeitsbibliothek, in der ein einziger, unglaublich intelligenter Bibliothekar (die KI) Fragen von tausenden Menschen gleichzeitig beantwortet. Dieser Bibliothekar ist brillant, arbeitet aber auf eine sehr spezifische Art und Weise: Er kann nur ein Wort nach dem anderen aufschreiben. Um eine komplexe Frage zu beantworten, muss er innehalten, nachdenken, ein Wort schreiben, wieder innehalten, nachdenken, das nächste Wort schreiben und so weiter. Diese „ein Wort nach dem anderen“-Regel ist der Hauptgrund dafür, dass sich die Bibliothek staut; der Bibliothekar verbringt die meiste Zeit damit, einfach nur darauf zu warten, das nächste Wort aus den Regalen zu greifen.

Um die Geschwindigkeit zu erhöhen, haben Ingenieure einen cleveren Trick namens „Speculative Decoding“ erfunden. Anstatt den Bibliothekar ein Wort nach dem anderen schreiben zu lassen, engagieren sie einen schnellen, etwas weniger intelligenten Assistenten (den „Drafter“), der in einem Schwung die nächsten paar Wörter errät. Der Bibliothekar prüft diese Vermutungen dann schnell. Wenn die Vermutungen richtig sind, akzeptiert der Bibliothekar sie alle auf einmal und überspringt so den langsamen „Denken-Pause-Schreiben“-Zyklus für diese Wörter. Es ist, als würde der Assistent rufen: „Ich wette, die nächsten drei Wörter sind 'Der', 'schnelle', und 'braune'!'“ und der Bibliothekar sagt: „Ja, du hast recht!“ und macht weiter. Das funktioniert großartig, wenn die Bibliothek ruhig ist. Aber was passiert, wenn die Bibliothek mit 64 Leuten voll ist, die gleichzeitig Fragen schreien? Der Assistent mag vielleicht eine lange Liste von Vermutungen für alle herausschreien, aber der Bibliothekar wird überfordert versuchen, sie alle zu überprüfen. Wenn die Vermutungen falsch sind, verschwendet der Bibliothekar kostbare Zeit damit, Wörter zu prüfen, die verworfen werden, was die gesamte Bibliothek verlangsamt. Dies ist das Rätsel, das dieses Paper angeht: Wie man den Geschwindigkeitsvorteil beibehält, wenn die Menge riesig wird.

Das Problem: Zu viele Vermutungen, nicht genug Zeit

Die Forscher bei Tencent Hunyuan bemerkten einen Fehler im System. Kürzlich wurden neue Assistenten (wie einer namens DFlash) wirklich gut darin, lange Listen von Vermutungen herauszuschreien – sagen wir, 15 Wörter auf einmal. Wenn die Bibliothek leer war, war dies eine Superkraft; der Bibliothekar akzeptierte die meisten davon, und die Bibliothek arbeitete sich schnell durch die Fragen.

Aber als die Menge wuchs (als die „Batch Size“ oder die Anzahl der gleichzeitigen Anfragen zunahm), begann das System zu stürzen. Der Assistent schrie weiterhin lange Listen von Vermutungen heraus, aber der Bibliothekar, der nun unter Hochspannung stand, konnte sie nicht alle schnell genug überprüfen. Schlimmer noch, viele dieser langen Listen waren falsch. Der Bibliothekar verbrachte seine ganze Energie damit, Wörter zu prüfen, die sich als Müll herausstellten, nur um sie dann abzulehnen. Es war, als würde ein Sicherheitsmann bei einem belebten Konzert die Ausweise von 15 Personen in einer Schlange kontrollieren, nur um dann festzustellen, dass 10 von ihnen gefälscht waren, und dadurch wertvolle Zeit verschwendet, die er hätte nutzen können, um die echten Fans hereinzulassen. Die Forscher fanden heraus, dass diese „lange Vermutungs“-Methode bei großen Menschenmengen tatsächlich langsamer war, als den Bibliothekar einfach alleine arbeiten zu lassen, ein Wort nach dem anderen.

Die Lösung: D-cut (Der smarte Türsteher)

Um dies zu beheben, schlug das Team eine neue Strategie namens D-cut vor. Betrachten Sie D-cut als einen super-smarten Türsteher, der zwischen dem Assistenten und dem Bibliothekar steht.

Anstatt den Assistenten erlauben zu lassen, für jeden eine lange, feste Liste von Vermutungen herauszuschreien und den Bibliothekar alle prüfen zu lassen, betrachtet D-cut die Menge und die Vermutungen in Echtzeit. Es stellt zwei einfache Fragen:

Wie selbstbewusst ist der Assistent? Wenn der Assist mit hoher Zuversicht schreit, lässt der Türsteher diese Vermutungen durch. Wenn der Assistent stammelt oder unsicher ist, kürzt der Türsteher die Liste ab.
Wie müde ist der Bibliothekar? Der Türsteher überprüft die aktuelle Arbeitslast des Bibliothekars. Wenn der Bibliothekar überlastet ist (wie auf einem geschäftigen GPU-Chip), wird der Türsteher strenger und kürzt mehr Vermutungen. Wenn der Bibliothekar frisch und leistungsstark ist (wie auf einem anderen, schnelleren Chip), lässt der Türsteher mehr Vermutungen durch.

D-cut kürzt die Liste nicht nur für eine Person; es betrachtet die gesamte Gruppe von Anfragen. Es erkennt, dass der Assistent für manche Leute ein Genie ist, aber für andere wild herumrät. So nimmt D-cut das „Verifikationsbudget“ (die Zeit, die der Bibliothekar zum Prüfen hat) und gibt es den Leuten, die am wahrscheinlichsten richtig liegen. Es beschneidet (kürzt ab) die niedrig konfidenten, langen Enden der Vermutungen der unsicheren Anfragen und konzentriert die Energie des Bibliothekars auf die hoch konfidenten Teile.

Wie es in der Praxis funktioniert

Die Forscher testeten diese Idee auf einer Vielzahl von KI-Modellen, von kleinen bis zu massiven, und auf verschiedenen Computertypen. Sie fanden heraus, dass D-cut in geschäftigen Zeiten ein Game-Changer war:

Die Rettung bei großen Menschenmengen: Wenn die Anzahl der Anfragen hoch war (wie 64 Leute gleichzeitig), war die alte Methode (DFlash) oft so langsam, dass sie tatsächlich langsamer war als die Standardmethode „ein Wort nach dem anderen“. D-cut behob dies. Es hielt den Geschwindigkeitsvorteil selbst aufrecht, als die Bibliothek voll war.
Die Zahlen: In ihren Tests steigerte D-cut die durchschnittliche Geschwindigkeit von 1,26-mal schneller auf 1,65-mal schneller im Vergleich zur Standardmethode unter hoher Last. Bei einigen spezifischen, sehr großen Modellen erreichte es sogar bis zu das 3,0-fache der Geschwindigkeit.
Anpassung an die Hardware: Eine der coolsten Funktionen ist, dass D-cut lernt, wie schnell der Bibliothekar ist, bevor die Menge eintrifft. Es profiliert den Computerchip (wie einen H20 oder H800 GPU), um zu sehen, wie teuer es ist, ein Wort zu prüfen. Wenn das Prüfen eines Wortes teuer ist (wie auf einem langsameren Chip), schneidet D-cut aggressiver. Wenn es günstig ist, schneidet es weniger. Das bedeutet, dass es keinen Menschen braucht, der es für jeden neuen Computer abstimmt; es findet es automatisch heraus.

Was es nicht tut (Und was es ausschließt)

Es ist wichtig zu wissen, was D-cut nicht ist. Es versucht nicht, den Assistenten intelligenter zu machen oder die Art und Weise zu ändern, wie der Bibliothekar denkt. Es ändert nicht die endgültigen Antworten, die die KI gibt; die Ausgabe bleibt exakt dieselbe wie wenn der Bibliothekar alles geprüft hätte, nur kommt sie viel schneller an.

Das Paper argumentiert explizit gegen die Idee, dass „länger immer besser ist“. Sie zeigten, dass das blinde Generieren langer Listen von Vermutungen (wie die 15-Wort-Blöcke in DFlash) eine schlechte Idee ist, wenn die Menge groß ist. Der „Einheitsansatz“, die gleiche Anzahl an Vermutungen für alle zu prüfen, scheitert, weil nicht jeder die gleiche Menge an Prüfung benötigt. D-cut beweist, dass selektiv zu sein besser ist als erschöpfend zu sein.

Das Fazit

Die Forscher haben nicht nur vorgeschlagen, dass dies funktionieren könnte; sie haben es gemessen. Sie führten Simulationen und Reallife-Tests auf tatsächlichen Servern mit tausenden von Anfragen durch. Die Ergebnisse zeigten, dass D-cut durch das Agieren als smarter, adaptiver Türsteher, der die niedrig konfidenten Vermutungen kürzt und sich auf die hoch konfidenten konzentriert, die KI-Bibliothek auch dann schnell hält, wenn die Türen weit aufgestoßen werden. Es verwandelt ein System, das sonst zu einem langsamen Kriechen neigen würde, in eines, das effizient bleibt, und beweist, dass der beste Weg, schnell zu sein, manchmal darin besteht, aufzuhören, die Dinge zu prüfen, von denen man weiß, dass sie falsch sind.

Technisches Resümee: D-cut: Adaptive Verifizierungstiefe-Pruning für gebatchtes Spekulatives Dekodieren

1. Problemstellung

Spekulatives Dekodieren hat sich als ein führender verlustfreier Ansatz zur Beschleunigung der Inferenz von Large Language Models (LLMs) etabliert, indem die Entwurfserstellung (Draft Generation) von der Verifizierung entkoppelt wird. Jüngste Fortschritte, wie etwa blockparallele Drafter (z. B. DFlash), generieren ganze Blöcke von Draft-Token in einem einzigen Vorwärtspass, wodurch die Entwurfsgeschwindigkeit von der Draft-Länge entkoppelt wird und eine hohe mittlere Anzahl akzeptierter Token (Mean Accepted Tokens, MAT) in Szenarien mit geringer Konkurrenz erreicht wird.

Das Paper identifiziert jedoch einen kritischen Engpass bei der Hochkonkurrenz-Batch-Bedienung (High-Concurrency Batched Serving):

Explosion der Verifizierungskosten: Wenn die Batch-Größe ( $B$ ) steigt, muss das Zielmodell pro Schritt $B \times (D+1)$ Token verifizieren (wobei $D$ die Draft-Länge ist). Dies verschiebt den Verifizierungsprozess von einem speichergebundenen zu einem rechengebundenen Prozess.
Ineffiziente Ressourcenallokation: In Szenarien mit hoher Konkurrenz führen lange, fest definierte Verifizierungstiefen oft zu einer hohen Ablehnungsrate. Beispielsweise kann bei einer Draft-Länge von 15 die durchschnittliche Akzeptanzlänge nur etwa 6 Token betragen, was bedeutet, dass etwa 60 % der verifizierten Token abgelehnt werden.
Suboptimale Durchsatzraten: Die Rechenkosten für die Verifizierung dieser abgelehnten Token blähen die Schrittzeit auf, was dazu führt, dass der Durchsatz des spekulativen Dekodierens bei hohen Batch-Größen (z. B. $bs=64$) stagniert oder sogar unter das Standard-Autoregressive (AR) Dekodieren fällt.
Statische vs. Dynamische Anforderungen: Bestehende Methoden wenden typischerweise eine einheitliche Verifizierungstiefe für alle Anfragen in einem Batch an. Dies berücksichtigt nicht die signifikante Varianz der Akzeptanzlängen über verschiedene parallele Anfragen hinweg sowie die variierenden Rechenkosten der Verifizierung in unterschiedlichen Hardware-Umgebungen (z. B. rechenbeschränkte H20 vs. rechenreiche H800 GPUs).

2. Methodik: D-cut

Die Autoren schlagen D-cut vor, eine adaptive Pruning-Strategie, die das Verifizierungsbudget als gemeinsame Ressource über den gesamten Batch behandelt und es dynamisch den Tokens zuweist, die am wahrscheinlichsten akzeptiert werden. Die Methode arbeitet, ohne das Zielmodell zu modifizieren oder zusätzliches Training zu erfordern.

Kernmechanismen

Anfrageübergreifendes Pruning (Vertrauensbasiert):
- Anstatt eine feste Tiefe für jede Anfrage zu verifizieren, bewertet D-cut jede Kandidaten-Tokenposition im Batch anhand des Konfidenzniveaus der Drafter-Vorhersage.
- Es berechnet einen „Präfix-Produkt“-Score ( $s_{i,k}$ ) für jede Position, der die Wahrscheinlichkeit darstellt, mit der der Block bis zur Tiefe $k$ überlebt.
- Alle Kandidaten-Positionen über den gesamten Batch hinweg werden durch diese Scores global rankiert. Suffixe mit geringer Konfidenz werden geprunt, während Präfixe mit hoher Konfidenz beibehalten werden. Dies stellt sicher, dass das Verifizierungsbudget von Anfragen mit geringem Ertrag zu Anfragen mit hohem Ertrag verschoben wird.
Laufzeitadaptive Tiefenauswahl:
- Da die Kosten für die Verifizierung zusätzlicher Tokens stark von der Laufzeitumgebung abhängen (GPU-Typ, Modellarchitektur, Parallelisierungsstrategie und Batch-Größe), integriert D-cut ein profilbasiertes Kostenmodell.
- Profiling: Bei Serverstart profiliert D-cut die End-to-End-Latenz der spekulativen Schritte für verschiedene diskrete Verifizierungs-Budgetverhältnisse ( $\rho \in \{0,25, 0,50, 0,75, 1,00\}$ ) und Batch-Größen.
- Optimierung: Während des Betriebs wählt D-cut dynamisch das optimale globale Budgetverhältnis ( $\rho^*$ ) aus, das den projizierten Beschleunigungsgewinn maximiert. Der Beschleunigungsgewinn ist als das Verhältnis des erwarteten Nutzens (geschätzte MAT basierend auf Konfidenz-Scores) zu den hardware-profilbasierten Laufzeitkosten formuliert.
- Dies ermöglicht es D-cut, bei rechenbeschränkter Hardware (z. B. H20) oder bei geringer Drafter-Qualität aggressiv zu prunen, während es auf rechenreicher Hardware (z. B. H800), wo die Verifizierung günstig ist, mehr Tokens beibehält.

Pipeline-Übersicht

Drafting: Der Drafter generiert einen Block von Tokens mit den zugehörigen Konfidenz-Scores.
Scoring & Ranking: Der Selektor flacht alle Positionen ab, berechnet die Präfix-Produkt-Scores und rankt sie global.
Budgetauswahl: Der Selektor konsultiert die vorab profilierte Kostentabelle, um das optimale Budgetverhältnis $\rho^*$ zu wählen, das das Nutzen-Kosten-Verhältnis maximiert.
Packing: Die am besten bewerteten Top- $K$ -Positionen werden in einen dichten Verifizierungs-Batch gepackt. Da die behaltenen Positionen für jede Anfrage aufgrund der Präfix-Produkt-Scores ein zusammenhängendes Präfix bilden, ist die Kompatibilität mit bestehenden Inferenz-Engines und CUDA-Graphs gewährleistet.
Verifizierung: Das Zielmodell verifiziert den gepackten Batch.

3. Zentrale Beiträge

Identifizierung des Engpasses: Das Paper zeigt empirisch auf, dass bei der Hochkonkurrenz-Batch-Bedienung langgestreckte, feste Tiefen-Drafts (wie DFlash) den Durchsatz aufgrund der hohen Kosten für die Verifizierung abgelehnter Tokens unter das Niveau des Standard-AR-Dekodierens senken können.
D-cut Algorithmus: Eine trainingsfreie, verlustfreie Pruning-Strategie, die ein anfragenübergreifendes Verifizierungs-Tiefen-Pruning durchführt, geleitet durch Drafter-Konfidenz und eine lazuzeitadaptive Tiefenauswahl.
Laufzeit-Kostenmodellierung: Die Einführung eines profilierten Kostenmodells, das es der Pruning-Strategie ermöglicht, sich an spezifische Deployment-Umgebungen (Hardware, Batch-Größe, Modellarchitektur) anzupassen, anstatt auf statischen Heuristiken zu beruhen.
Systemintegration: Die Methode ist so konzipiert, dass sie mit bestehenden Inferenz-Engines (z. B. vLLM) kompatibel ist, indem sie das Verifizierungsbudget auf diskrete Verhältnisse beschränkt, was die Kompatibilität mit stückweiser CUDA-Graph-Erfassung sicherstellt und eine Shape-Explosion verhindert.

4. Experimentelle Ergebnisse

Die Autoren evaluierten D-cut auf sechs Zielmodellen (die dichte und MoE-Architekturen abdecken) über fünf Benchmarks (Math, Code, Chat) unter Verwendung von NVIDIA H20 und H800 GPUs.

Durchsatzverbesserung: Unter hoher Konkurrenz (Batch-Größe 32) verbessert D-cut die durchschnittliche Beschleunigung gegenüber dem autoregressiven Dekodieren von 1,26× auf 1,65× im Vergleich zur DFlash-Baseline.
Wiederherstellung der Beschleunigung: Für dichte Modelle, bei denen DFlash (mit langen Drafts) bei hoher Konkurrenz unter das AR-Dekodieren fällt, stellt D-cut eine positive Beschleunigung wieder her.
MoE-Performance: Bei Mixture-of-Experts (MoE)-Modellen erreicht D-cut eine bis zu 3,0× höhere Beschleunigung gegenüber dem autoregressiven Dekodieren.
Hardware-Adaptivität:
- Auf der rechenbeschränkten H20 prunt D-cut aggressiv (wählt oft ein 25%-Budget), was die Fixed-Ratio-Baselines deutlich übertrifft.
- Auf der rechenreichen H800 passt sich D-cut an, um mehr Tokens zu behalten (oft 50% oder höher), wodurch der Durchsatz maximiert wird, ohne unnötiges Pruning.
Robustheit: D-cut behält seinen Vorteil auch unter stochastischem Target-Sampling (Temperatur 1) bei, wo Standard-Long-Draft-Methoden vollständig versagen.

5. Bedeutung und Behauptungen

Das Paper behauptet, dass D-cut einen grundlegenden Widerspruch in aktuellen spekulativen Dekodiersystemen adressiert: die Annahme, dass längere Drafts immer besser sind. Die Autoren argumentieren, dass in der Batch-Bedienung die Verifizierungsrechenleistung die knappe Ressource ist, nicht nur die Fähigkeit, Drafts zu generieren.

Paradigmenwechsel: Die Arbeit verschiebt den Fokus von der Maximierung der Akzeptanzlänge einzelner Anfragen hin zum Management der Batch-Verifizierungseffizienz.
Praktische Auswirkungen: D-cut ermöglicht den Einsatz leistungsfähiger blockparalleler Drafter in Hochkonkurrenz-Produktionsumgebungen, in denen sie sonst nachteilig wären.
Einschränkungen: Die Autoren räumen eine Herausforderung bei der Systemintegration ein: Die variierende Form des Verifizierungs-Batches erfordert eine sorgfältige Handhabung, um den statischen Form-Annahmen aktueller Inferenz-Engines (wie Spec-V2 und stückweisen CUDA-Graphs) zu entsprechen. Sie merken an, dass die Realisierung des vollen Potenzials von dynamischer Verifizierung eine engere Co-Design-Zusammenarbeit mit Serving-Frameworks erfordern könnte.

Zusammenfassend bietet D-cut einen Mechanismus, um den Trade-off zwischen dem algorithmischen Nutzen (mehr akzeptierte Tokens) und den Hardwarekosten (Verifizierung dieser Tokens) dynamisch auszubalancieren, wodurch sichergestellt wird, dass spekulatives Dekodieren auch unter hoher Last eine praktikable Beschleunigungstechnik bleibt.