💬 NLP

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

D-Cut is een adaptieve verificatiediepte-pruningmethode voor gebatchte speculatieve decodering die verificatiebudgetten dynamisch toewijst over gelijktijdige verzoeken op basis van conceptvertrouwen en runtime-kostenmodellen, wat de inferentiesnelheid onder hoge concurrentie aanzienlijk verbetert terwijl verspilde berekening op afgewezen tokens wordt voorkomen.

Oorspronkelijke auteurs: Tianyu Liu, Yuhao Shen, Rui Cen, Junhan Shi, Jiebin Zhang, Guangshuo Qin, Hong Liu, Song Liu, Guanghua Yu, Jianchen Zhu

Gepubliceerd 2026-07-17

📖 7 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Tianyu Liu, Yuhao Shen, Rui Cen, Junhan Shi, Jiebin Zhang, Guangshuo Qin, Hong Liu, Song Liu, Guanghua Yu, Jianchen Zhu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een enorme, razendsnelle bibliotheek runt waar een enkele, ongelooflijk slimme bibliothecaris (de AI) vragen beantwoordt van duizenden mensen tegelijk. Deze bibliothecaris is briljant maar werkt op een zeer specifieke manier: hij kan slechts één woord tegelijk opschrijven. Om een complexe vraag te beantwoorden, moet hij pauzeren, nadenken, één woord opschrijven, weer pauzeren, nadenken, het volgende woord opschrijven, enzovoort. Deze "één woord tegelijk"-regel is de belangrijkste reden dat de bibliotheek achterloopt; de bibliothecaris brengt de meeste tijd door met wachten om het volgende woord uit de schappen te pakken.

Om dit te versnellen, hebben ingenieurs een slimme truc uitgevonden genaamd "speculative decoding". In plaats van dat de bibliothecaris één woord tegelijk schrijft, huurt hij een snelle, iets minder slimme assistent in (de "drafter") om in een korte burst de volgende paar woorden te raden. De bibliothecaris controleert deze gokken vervolgens snel. Als de gokken juist zijn, accepteert de bibliothecaris ze allemaal tegelijk, waardoor hij de trage "denk-pauzeer-schrijf"-cyclus voor die woorden overslaat. Het is alsof de assistent roept: "Ik wed dat de volgende drie woorden 'De', 'snelle', en 'bruine' zijn!" en de bibliothecaris zegt: "Ja, je hebt gelijk!" en daarna verdergaat. Dit werkt geweldig wanneer de bibliotheek rustig is. Maar wat gebeurt er wanneer de bibliotheek vol zit met 64 mensen die tegelijkertijd vragen roepen? De assistent roept misschien een lange lijst met gokken voor iedereen, maar de bibliothecaris raakt overweldigd door het controleren van al die gokken. Als de gokken fout zijn, verspilt de bibliothecaris kostbare tijd aan het controleren van woorden die worden weggegooid, wat de hele bibliotheek vertraagt. Dit is het puzzelstukje waar dit artikel zich mee bezighoudt: hoe de snelheidswinst te behouden wanneer de menigte enorm wordt.

Het Probleem: Te Veel Gokken, Niet Genoeg Tijd

De onderzoekers van Tencent Hunyuan merkten een glitch in het systeem op. Onlangs zijn nieuwe assistenten (zoals een genaamd DFlash) erg goed geworden in het uitroepen van lange lijsten met gokken—zeg bijvoorbeeld 15 woorden tegelijk. Wanneer de bibliotheek leeg was, was dit een superkracht; de bibliothecaris accepteerde de meeste van de gokken en de bibliotheek vloog door de vragen heen.

Maar naarmate de menigte groeide (wanneer de "batch size" of het aantal gelijktijdige verzoeken toenam), begon het systeem vast te lopen. De assistent bleef lange lijsten met gokken uitroepen, maar de bibliothecaris, die nu overbelast was, kon ze niet allemaal snel genoeg controleren. Erger nog, veel van die lange lijsten waren fout. De bibliothecaris verspende al zijn energie aan het controleren van woorden die uiteindelijk waardeloos bleken te zijn, om ze vervolgens af te wijzen. Het was alsof een beveiliger bij een druk concert de ID's van 15 mensen in een rij controleert, om er vervolgens achter te komen dat 10 van hen vals zijn, waardoor tijd werd verspild die gebruikt had kunnen worden om de echte fans binnen te laten. De onderzoekers ontdekten dat bij grote drukte deze "lange gok"-methode eigenlijk langzamer was dan de bibliothecaris gewoon alleen laten werken, één woord tegelijk.

De Oplossing: D-cut (De Slimme Uitsmijter)

Om dit op te lossen, stelde het team een nieuwe strategie voor genaamd D-cut. Denk aan D-cut als een super slimme uitsmijter die tussen de assistent en de bibliothecaris staat.

In plaats van de assistent een lange, vaste lijst met gokken voor iedereen te laten uitroepen en de bibliothecaris die allemaal te laten controleren, kijkt D-cut in realtime naar de menigte en de gokken. Het stelt twee eenvoudige vragen:

Hoe zelfverzekerd is de assistent? Als de assistent met een hoog vertrouwen roept, laat de uitsmijter die gokken door. Als de assistent mompelt of onzeker is, maakt de uitsmijter de lijst korter.
Hoe moe is de bibliothecaris? De uitsmijter controleert de huidige werklast van de bibliothecaris. Als de bibliothecaris overspoeld wordt (zoals op een drukke GPU-chip), wordt de uitsmijter strenger en snijdt hij meer gokken weg. Als de bibliothecaris fris en krachtig is (zoals op een andere, snellere chip), laat de uitsmijter meer gokken door.

D-cut kijkt niet alleen naar de lijst voor één persoon; het kijkt naar de volledige batch verzoeken. Het realiseert zich dat voor sommige mensen de assistent een genie is, maar voor anderen de assistent maar wat gokt. Dus neemt D-cut het "verificatiebudget" (de tijd die de bibliothecaris heeft om te controleren) en geeft het aan de mensen die het meest waarschijnlijk gelijk hebben. Het snoeit (snijdt af) de laag-zelfverzekerde, lange staarten van gokken van de onzekere verzoeken en richt de energie van de bibliothecaris op de hoog-zelfverzekerde delen.

Hoe het werkt in de praktijk

De onderzoekers testten dit idee op een verscheidenheid aan AI-modellen, van kleine tot enorme modellen, en op verschillende soorten computerchips. Ze ontdekten dat D-cut een game-changer was voor drukke tijden:

De dag redden bij grote drukte: Wanneer het aantal verzoeken hoog was (zoals 64 mensen tegelijk), vertraagde de oude methode (DFlash) vaak zo erg dat het zelfs langzamer was dan de standaard "één woord tegelijk"-methode. D-cut loste dit op. Het hield de snelheidswinst levend, zelfs wanneer de bibliotheek vol gepakt was.
De cijfers: In hun tests verhoogde D-cut de gemiddelde snelheid van 1,26 keer sneller naar 1,65 keer sneller vergeleken met de standaardmethode onder hoge belasting. Op sommige specifieke, zeer grote modellen bereikte het zelfs wel 3,0 keer de snelheid.
Aanpassen aan de hardware: Een van de coolste functies is dat D-cut leert hoe snel de bibliothecaris is voordat de menigte arriveert. Het profileren van de computerchip (zoals een H20 of H800 GPU) om te zien hoe duur het is om een woord te controleren. Als het controleren van een woord duur is (zoals op een tragere chip), snijdt D-cut agressiever. Als het goedkoop is, snijdt het minder. Dit betekent dat het geen mens nodig heeft om het voor elke nieuwe computer af te stemmen; het ontdekt het automatisch.

Wat het niet doet (En wat het uitsluit)

Het is belangrijk om te weten wat D-cut niet is. Het probeert de assistent niet slimmer te maken of de manier waarop de bibliothecaris denkt te veranderen. Het verandert de uiteindelijke antwoorden die de AI geeft niet; de output blijft exact hetzelfde als wanneer de bibliothecaris alles gecontroleerd zou hebben, alleen komt het veel sneller tot stand.

Het artikel betoogt expliciet tegen het idee dat "langer altijd beter is". Ze lieten zien dat het blindelings genereren van lange lijsten met gokken (zoals de 15-woord blokken in DFlash) een slecht idee is wanneer de menigte groot is. De "one size fits all"-aanpak van het controleren van hetzelfde aantal gokken voor iedereen faalt, omdat niet iedereen dezelfde hoeveelheid controle nodig heeft. D-cut bewijst dat selectief zijn beter is dan uitputtend zijn.

De Kern van de zaak

De onderzoekers suggereerden niet alleen dat dit zou kunnen werken; ze hebben het gemeten. Ze draaiden simulaties en real-world tests op echte servers met duizenden verzoeken. De resultaten toonden aan dat door een slimme, adaptieve uitsmijter te zijn die de laag-zelfverzekerde gokken wegknipt en zich concentreert op de hoog-zelfverzekerde gokken, D-cut de AI-bibliotheek snel houdt, zelfs wanneer de deuren wijd openstaan. Het verandert een systeem dat anders tot stilstand zou komen, in een systeem dat efficiënt blijft, wat bewijst dat de beste manier om snel te gaan soms is om te stoppen met het controleren van de dingen waarvan je weet dat ze fout zijn.

Technische Samenvatting: D-cut: Adaptieve Verificatie-diepte Pruning voor Gebatchte Speculatieve Decodering

1. Probleemstelling

Speculatieve decodering is opgekomen als een leidende verliesloze aanpak om de inferentie van Large Language Models (LLM's) te versnellen door de conceptie van drafts te ontkoppelen van de verificatie. Recente ontwikkelingen, zoals blok-parallelle drafters (bijv. DFlash), genereren volledige blokken draft-tokens in één enkele forward pass, waardoor de draft-lengte wordt ontkoppeld van de drafting-latentie en een hoge Mean Accepted Tokens (MAT) wordt bereikt in scenario's met lage concurrency.

Echter, het paper identificeert een kritieke bottleneck in high-concurrency gebatchte serving:

Explosie van Verificatiekosten: Naarmate de batchgrootte ( $B$ ) toeneemt, moet het doelmodel $B \times (D+1)$ tokens per stap verifiëren (waarbij $D$ de draft-lengte is). Dit verschuift het verificatieproces van een geheugen-gebonden naar een compute-gebonden proces.
Inefficiënte Resourceallocatie: In scenario's met hoge concurrency leiden lange, vaste-diepte drafts vaak tot een hoge afwijzingsgraad. Bijvoorbeeld, met een draft-lengte van 15 is de gemiddelde acceptatie-lengte slechts ~6 tokens, wat betekent dat ongeveer 60% van de geverifieerde tokens wordt afgewezen.
Suboptimale Doorvoer: De computationele kosten van het verifiëren van deze afgewezen tokens blazen de staptijd op, waardoor de doorvoer van speculatieve decodering verzadigt of zelfs onder de standaard autoregressieve (AR) decodering zakt bij hoge batch-grootten (bijv. $bs=64$).
Statisch vs. Dynamisch Behoeften: Bestaande methoden passen doorgaans een uniforme verificatie-diepte toe op alle verzoeken in een batch. Dit houdt geen rekening met de aanzienlijke variantie in acceptatie-lengtes tussen gelijktijdige verzoeken en de variërende computationele kosten van verificatie in verschillende hardware-omgevingen (bijv. compute-beperkte H20 versus compute-rijke H800 GPU's).

2. Methodologie: D-cut

De auteurs stellen D-cut voor, een adaptieve pruning-strategie die het verificatiebudget behandelt als een gedeelde resource over de gehele batch, waarbij dit budget dynamisch wordt toegewezen aan de tokens die het meest waarschijnlijk geaccepteerd zullen worden. De methode werkt zonder de doelmodellen te wijzigen of extra training te vereisen.

Kernmechanismen

Cross-Request Pruning (Confidence-Guided):
- In plaats van een vaste diepte te verifiëren voor elk verzoek, scoort D-cut elke kandidaat-tokenpositie in de batch met behulp van de voorspellingsbetrouwbaarheid van de drafter.
- Het berekent een "prefix-product" score ( $s_{i,k}$ ) voor elke positie, die de waarschijnlijkheid vertegenwoordigt dat het blok tot diepte $k$ overleeft.
- Alle kandidaat-posities over de batch worden globaal gerankt op basis van deze scores. Suffixes met een lage betrouwbaarheid worden gepruned, terwijl prefixes met een hoge betrouwbaarheid worden behouden. Dit zorgt ervoor dat het verificatiebudget wordt verschoven van laag-rendabele verzoeken naar hoog-rendabele verzoeken.
Runtime-Adaptieve Diepte Selectie:
- Erkenning dat de kosten van het verifiëren van extra tokens sterk afhangen van de runtime-omgeving (GPU-type, modelarchitectuur, parallellisme-strategie en batchgrootte), incorporeert D-cut een geprofileerd kostenmodel.
- Profiling: Bij het opstarten van de server profileert D-cut de end-to-end latentie van speculatieve stappen voor verschillende discrete verificatie-budgetratio's ( $\rho \in \{0.25, 0.50, 0.75, 1.00\}$ ) en batchgroottes.
- Optimalisatie: Tijdens het serveren selecteert D-cut dynamisch de optimale globale budgetratio ( $\rho^*$ ) die de geprojecteerde versnelling maximaliseert. De versnelling wordt geformuleerd als de ratio van het verwachte voordeel (geschatte MAT op basis van confidence scores) tot de hardware-geprofileerde runtime-kosten.
- Dit stelt D-cut in staat om agressief te prunen op compute-beperkte hardware (bijv. H20) of wanneer de draft-kwaliteit laag is, terwijl meer tokens worden behouden op compute-rijke hardware (bijv. H800) waar verificatie goedkoop is.

Pipeline Overzicht

Drafting: De drafter genereert een blok tokens met bijbehorende confidence scores.
Scoring & Ranking: De selector vlakt alle posities af, berekent prefix-product scores en rankt ze globaal.
Budget Selectie: De selector raadpleegt de vooraf geprofileerde kosten-tabel om de optimale budgetratio $\rho^*$ te kiezen die de utility-to-cost ratio maximaliseert.
Packing: De top- $K$ scorende posities worden verpakt in een dichte verificatie-batch. Cruciaal is dat omdat scores prefix-producten zijn, de behouden posities voor elk verzoek een aaneengesloten prefix vormen, wat compatibiliteit met bestaande inference engines en CUDA graphs garandeert.
Verificatie: Het doelmodel verifieert de verpakte batch.

3. Belangrijkste Bijdragen

Identificatie van de Bottleneck: Het paper toont empirisch aan dat in high-concurrency gebatste serving, lange vaste-diepte drafts (zoals DFlash) de doorvoer kunnen verlagen onder de standaard AR-decodering vanwege de hoge kosten van het verifiëren van afgewezen tokens.
D-cut Algoritme: Een training-vrije, verliesloze pruning-strategie die cross-request verificatie-diepte pruning uitvoert, geleid door draft confidence en runtime-adaptieve diepte selectie.
Runtime Kostenmodellering: De introductie van een geprofileerd kostenmodel dat de pruning-strategie in staat stelt om te adapteren aan specifieke deployment-omgevingen (hardware, batchgrootte, modelarchitectuur) in plaats van te vertrouwen op statische heuristieken.
Systeemintegratie: De methode is ontworpen om te werken met bestaande inference engines (zoals vLLM) door de verificatie-budgetten te beperken tot discrete ratio's, wat compatibiliteit met piecewise CUDA graph capture waarborgt en shape-explosie voorkomt.

4. Experimentele Resultaten

De auteurs evalueerden D-cut op zes doelmodellen (dekend van dense en MoE architecturen) over vijf benchmarks (math, code, chat) met behulp van NVIDIA H20 en H800 GPU's.

Doorvoer Verbetering: Onder hoge concurrency (batch size 32), verbetert D-cut de gemiddelde versnelling ten opzichte van autoregressieve decodering van 1.26× naar 1.65× vergeleken met de DFlash baseline.
Herstel van Acceleratie: Voor dense modellen waar DFlash (met lange drafts) onder de AR-decodering zakt bij hoge concurrency, herstelt D-cut de positieve acceleratie.
MoE Prestaties: Op Mixture-of-Experts (MoE) modellen bereikt D-cut tot wel 3.0× versnelling ten opzichte van autoregressieve decodering.
Hardware Adaptiviteit:
- Op de compute-beperkte H20 pruneert D-cut agressief (selecteert vaak een 25% budget), wat aanzienlijk beter presteert dan fixed-ratio baselines.
- Op de compute-rijke H800 past D-cut zich aan om meer tokens te behouden (vaak 50% of hoger), waardoor de doorvoer wordt gemaximaliseerd zonder onnodige pruning.
Robuustheid: D-cut behoudt zijn voordeel zelfs onder stochastische target sampling (temperature 1), waar standaard long-draft methoden volledig falen.

5. Betekenis en Claims

Het paper claimt dat D-cut een fundamentele mismatch aanpakt in huidige speculatieve decoderingssystemen: de assumptie dat langere drafts altijd beter zijn. De auteurs argumenteren dat in gebatste serving verificatie-compute de schaarse resource is, niet alleen het vermogen om drafts te genereren.

Paradigmaverschuiving: Het werk verschuift de focus van het maximaliseren van single-request acceptatie-lengtes naar het beheren van gebatste verificatie-efficiëntie.
Praktische Impact: D-cut maakt het mogelijk om krachtige blok-parallelle drafters te gebruiken in high-concurrency productie-omgevingen waar ze anders nadelig zouden zijn.
Beperkingen: De auteurs erkennen een systeemintegratie-uitdaging: de variërende vorm van de verificatie-batch vereist zorgvuldige behandeling om binnen de statische vorm-assumpties van huidige inference engines (zoals Spec-V2 en piecewise CUDA graphs) te passen. Ze merken op dat het realiseren van het volledige potentieel van dynamische verificatie een nauwere co-design met serving frameworks vereist.

Samenvattend biedt D-cut een mechanisme om de trade-off tussen het algoritmische voordeel van het accepteren van meer tokens en de hardwarekosten van het verifiëren van die tokens dynamisch te balanceren, waardoor speculatieve decodering een levensvatbare versnellingsmethode blijft, zelfs onder zware belasting.