💬 NLP

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

D-Cut è un metodo di pruning adattivo della profondità di verifica per il decoding speculativo batchato che alloca dinamicamente i budget di verifica tra le richieste concorrenti in base alla confidenza del draft e ai modelli di costo a runtime, migliorando significativamente l'accelerazione dell'inferenza sotto alta concorrenza e prevenendo lo spreco di computazione sui token rifiutati.

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

Pubblicato 2026-07-17

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

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

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di gestire una biblioteca enorme e ad alta velocità dove un singolo bibliotecario incredibilmente intelligente (l'IA) risponde alle domande di migliaia di persone contemporaneamente. Questo bibliotecario è brillante ma lavora in un modo molto specifico: può scrivere solo una parola alla volta. Per rispondere a una domanda complessa, deve fermarsi, pensare, scrivere una parola, fermarsi di nuovo, pensare, scrivere la parola successiva, e così via. Questa regola del "una parola alla volta" è il motivo principale per cui la biblioteca si intasa; il bibliotecario passa la maggior parte del tempo semplicemente aspettando di prendere la parola successiva dagli scaffali.

Per velocizzare le cose, gli ingegneri hanno inventato un trucco astuto chiamato "decodifica speculativa" (speculative decoding). Inveve di far scrivere al bibliotecario una parola alla volta, assumono un assistente leggermente meno intelligente ma veloce (il "drafter") per indovinare le prossime parole in un colpo solo. Il bibliotecario controlla poi rapidamente questi tentativi. Se gli indovini sono corretti, il bibliotecario li accetta tutti insieme, saltando il ciclo lento "pensa-fermati-scrivi" per quelle parole. È come se l'assistente urlasse: "Scommetto che le prossime tre parole sono 'Il', 'veloce', e 'marrone'!" e il bibliotecario rispondesse: "Sì, hai ragione!", procedendo oltre. Questo funziona molto bene quando la biblioteca è tranquilla. Ma cosa succede quando la biblioteca è affollata con 64 persone che urlano domande tutte insieme? L'assistente potrebbe urlare una lunga lista di tentativi per tutti, ma il bibliotecario si ritrova sopraffatto dal tentativo di controllarli tutti. Se gli indovini sono sbagliati, il bibliotecario spreca un tempo prezioso controllando parole che vengono poi scartate, rallentando l'intera biblioteca. Questo è il puzzle che questo articolo affronta: come mantenere il vantaggio di velocità quando la folla diventa enorme.

Il Problema: Troppi Tentativi, Poco Tempo

I ricercatori di Tencent Hunyuan hanno notato un difetto nel sistema. Recentemente, nuovi assistenti (come uno chiamato DFlash) sono diventati molto bravi a urlare lunghe liste di tentativi—per esempio, 15 parole alla volta. Quando la biblioteca era vuota, questa era una superpotenza; il bibliotecario accettava la maggior parte di esse e la biblioteca procedeva velocemente attraverso le domande.

Ma man mano che la folla cresceva (quando la "dimensione del batch" o numero di richieste simultanee aumentava), il sistema iniziava a incepparsi. L'assistente continuava a urlare lunghe liste, ma il bibliotecario, ora messo sotto pressione, non riusciva a controllarle tutte abbastanza velocemente. Peggio ancora, molte di quelle lunghe liste erano sbagliate. Il bibliotecario spendeva tutta la sua energia controllando parole che si rivelavano essere spazzatura, solo per rifiutarle. Era come un addetto alla sicurezza a un concerto affollato che controlla i documenti di 15 persone in fila, solo per rendersi conto che 10 di loro sono falsi, sprecando tempo che avrebbe potuto essere usato per far entrare i veri fan. I ricercatori hanno scoperto che, con grandi folle, questo metodo dei "tentativi lunghi" diventava in realtà più lento rispetto a lasciare che il bibliotecario lavorasse da solo, una parola alla volta.

La Soluzione: D-cut (Il Buttafuori Intelligente)

Per risolvere questo problema, il team ha proposto una nuova strategia chiamata D-cut. Pensa a D-cut come a un buttafuori super intelligente che sta tra l'assistente e il bibliotecario.

Invece di lasciare che l'assistente urli una lunga lista fissa di tentativi per tutti e che il bibliotecario li controlli tutti, D-cut osserva la folla e i tentativi in tempo reale. Si pone due semplici domande:

Quanto è fiducioso l'assistente? Se l'assistente urla con alta fiducia, il buttafuori lascia passare quei tentativi. Se l'assistente borbotta o non è sicuro, il buttafuori accorcia la lista.
Quanto è stanco il bibliotecario? Il buttafuori controlla l'attuale carico di lavoro del bibliotecario. Se il bibliotecario è sommerso (come su un chip GPU affollato), il buttafuori diventa più severo e taglia più tentativi. Se il bibliotecario è fresco e potente (come su un chip diverso, più veloce), il buttafuori lascia passare più tentativi.

D-cut non taglia la lista solo per una persona; guarda l'intero lotto di richieste. Si rende conto che per alcune persone l'assistente è un genio, mentre per altre l'assistente sta tirando a indovinare selvaggiamente. Quindi, D-cut prende il "budget di verifica" (il tempo che il bibliotecario ha per controllare) e lo assegna alle persone che hanno più probabilità di essere corrette. Potano (tagliano via) le code lunghe e a bassa fiducia dei tentativi delle richieste incerte e concentrano l'energia del bibliotecario sulle parti ad alta fiducia.

Come Funziona nel Mondo Reale

I ricercatori hanno testato questa idea su una varietà di modelli IA, da quelli piccoli a quelli massicci, e su diversi tipi di chip informatici. Hanno scoperto che D-cut è un punto di svolta per i momenti di affollamento:

Salvare la situazione durante le grandi folle: Quando il numero di richieste era elevato (come 64 persone contemporaneamente), il vecchio metodo (DFlash) spesso rallentava così tanto da diventare effettivamente più lento del metodo standard "una parola alla volta". D-cut ha risolto questo problema. Ha mantenuto il vantaggio di velocità anche quando la biblioteca era piena.
I Numeri: Nei loro test, D-cut ha aumentato la velocità media da 1,26 volte più veloce a 1,65 volte più veloce rispetto al metodo standard sotto carico elevato. Su alcuni modelli specifici, molto grandi, ha raggiunto persino le 3,0 volte la velocità.
Adattarsi all'Hardware: Una delle caratteristiche più interessanti è che D-cut impara quanto è veloce il bibliotecario prima che arrivi la folla. Analizza il chip del computer (come una GPU H20 o H800) per vedere quanto è costoso controllare una parola. Se controllare una parola è costoso (come su un chip più lento), D-cut taglia in modo più aggressivo. Se è economico, taglia meno. Questo significa che non ha bisogno di un essere umano che lo regoli per ogni nuovo computer; lo capisce automaticamente.

Cosa Non Fa (E Cosa Esclude)

È importante sapere cosa non è D-cut. Non cerca di rendere l'assistente più intelligente o di cambiare il modo in cui pensa il bibliotecario. Non cambia le risposte finali fornite dall'IA; l'output rimane esattamente lo stesso come se il bibliotecario avesse controllato tutto, solo che arriva molto più velocemente.

L'articolo sostiene esplicitamente contro l'idea che "più lungo sia sempre meglio". Hanno dimostrato che generare ciecamente lunghe liste di tentativi (come i blocchi di 15 parole in DFlash) è una cattiva idea quando la folla è numerosa. L'approccio "una misura per tutti" del controllare lo stesso numero di tentativi per chiunque fallisce perché non tutti necessitano dello stesso controllo. D-cut dimostra che essere selettivi è meglio che essere esaustivi.

Il Punto Fondamentale

I ricercatori non si sono limitati a suggerire che questo potrebbe funzionare; lo hanno misurato. Hanno eseguito simulazioni e test nel mondo reale su server reali con migliaia di richieste. I risultati hanno mostrato che, essendo un buttafuori intelligente e adattivo che taglia i tentativi a bassa fiducia e si concentra su quelli ad alta fiducia, D-cut mantiene la biblioteca IA veloce anche quando le porte sono spalancate dalla folla. Trasforma un sistema che altrimenti rallenterebbe fino a quasi fermarsi in uno che rimane efficiente, dimostrando che a volte, il modo migliore per andare veloci è smettere di controllare le cose che sai essere sbagliate.

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

1. Problematica

Lo speculative decoding è emerso come un approccio lossless di primo piano per accelerare l'inferenza dei Large Language Model (LLM), separando la generazione del draft dalla verifica. Recenti progressi, come i drafter block-parallel (ad esempio, DFlash), generano interi blocchi di token di draft in un singolo passaggio forward, disaccoppiando la lunghezza del draft dalla latenza di drafting e ottenendo un alto Mean Accepted Tokens (MAT) in scenari a bassa concorrenza.

Tuttavia, il documento identifica un collo di bottiglia critico nell'serving batch ad alta concorrenza:

Esplosione dei costi di verifica: All'aumentare della dimensione del batch ( $B$ ), il modello target deve verificare $B \times (D+1)$ token per step (dove $D$ è la lunghezza del draft). Questo sposta il processo di verifica da un regime limitato dalla memoria (memory-bound) a uno limitato dal calcolo (compute-bound).
Allocazione inefficiente delle risorse: Negli scenari ad alta concorrenza, i draft a profondità fissa e lunga portano spesso a un alto tasso di rifiuto. Ad esempio, con una lunghezza del draft di 15, la lunghezza media di accettazione può essere di circa 6 token, il che significa che circa il 60% dei token verificati viene rifiutato.
Throughput subottimale: Il costo computazionale della verifica di questi token rifiutati gonfia il tempo di step, causando la saturazione o addirittura il calo del throughput dello speculative decoding rispetto al decoding autoregressivo (AR) standard ad alte dimensioni di batch (ad es., $bs=64$).
Esigenze Statiche vs. Dinamiche: I metodi esistenti applicano tipicamente una profondità di verifica uniforme a tutte le richieste in un batch. Ciò non tiene conto della significativa varianza nelle lunghezze di accettazione tra le richieste concorrenti e dei diversi costi computazionali della verifica tra differenti ambienti hardware (ad es., GPU H20 limitate dal calcolo vs. GPU H800 ricche di calcolo).

2. Metodologia: D-cut

Gli autori propongono D-cut, una strategia di pruning adattiva che tratta il budget di verifica come una risorsa condivisa tra l'intero batch, allocandolo dinamicamente ai token con maggiore probabilità di essere accettati. Il metodo opera senza modificare il modello target o richiedere un ulteriore addestramento.

Meccanismi Core

Pruning Cross-Request (Guidato dalla Confidenza):
- Invece di verificare una profondità fissa per ogni richiesta, D-cut valuta ogni posizione del token candidato nel batch utilizzando la confidenza della predizione del drafter.
- Calcola uno score di "prodotto-prefisso" ( $s_{i,k}$ ) per ogni posizione, che rappresenta la probabilità che il blocco sopravviva fino alla profondità $k$ .
- Tutte le posizioni candidate attraverso il batch sono classificate globalmente in base a questi score. Le suffissi a bassa confidenza vengono rimosse (pruned), mentre i prefissi ad alta confidenza vengono mantenuti. Ciò assicura che il budget di verifica venga spostato dalle richieste a bassa resa a quelle ad alta resa.
Selezione della Profondità Adattiva al Runtime:
- Riconoscendo che il costo della verifica di token extra dipende fortemente dall'ambiente di runtime (tipo di GPU, architettura del modello, strategia di parallelismo e dimensione del batch), D-cut incorpora un modello di costo profilato.
- Profiling: All'avvio del server, D-cut profila la latenza end-to-end degli step speculativi per vari rapporti discreti di budget di verifica ( $\rho \in \{0.25, 0.50, 0.75, 1.00\}$ ) e dimensioni di batch.
- Ottimizzazione: Durante il serving, D-cut seleziona dinamicamente il rapporto di budget globale ottimale ( $\rho^*$ ) che massimizza lo speedup previsto. Lo speedup è formulato come il rapporto tra il beneficio atteso (MAT stimato basato sugli score di confidenza) e il costo di runtime profilato dall'hardware.
- Ciò consente a D-cut di essere aggressivo nel pruning su hardware limitato dal calcolo (ad es., H20) o quando la qualità del draft è bassa, pur mantenendo più token su hardware ricco di calcolo (ad es., H800) dove la verifica è economica.

Panoramica della Pipeline

Drafting: Il drafter genera un blocco di token con i relativi score di confidenza.
Scoring & Ranking: Il selettore appiattisce tutte le posizioni, calcola gli score di prodotto-prefisso e le classifica globalmente.
Selezione del Budget: Il selettore consulta la tabella dei costi pre-profilata per scegliere il rapporto di budget ottimale $\rho^*$ che massimizza il rapporto utilità-costo.
Packing: Le top- $K$ posizioni con lo score più alto vengono impacchettate in un batch di verifica denso. Fondamentalmente, poiché gli score sono prodotti-prefisso, le posizioni mantenute per ogni richiesta formano un prefisso contiguo, garantendo la compatibilità con i motori di inferenza esistenti e i CUDA graph.
Verifica: Il modello target verifica il batch impacchettato.

3. Contributi Chiave

Identificazione del Collo di Bottiglia: Il documento dimostra empiricamente che, nel serving batch ad alta concorrenza, i draft a profondità fissa e lunga (come DFlash) possono degradare il throughput al di sotto del decoding AR a causa dell'alto costo della verifica dei token rifiutati.
Algoritmo D-cut: Una strategia di pruning lossless, priva di addestramento, che esegue il pruning della profondità di verifica cross-request guidato dalla confidenza del draft e dalla selezione della profondità adattiva al runtime.
Modellazione del Costo al Runtime: L'introduzione di un modello di costo profilato che permette alla strategia di pruning di adattarsi a specifici ambienti di deployment (hardware, dimensione del batch, architettura del modello) invece di fare affidamento su euristiche statiche.
Integrazione di Sistema: Il metodo è progettato per lavorare con i motori di inferenza esistenti (ad es., vLLM) limitando il budget di verifica a rapporti discreti, garantendo la compatibilità con la cattura piecewise di CUDA graph ed evitando l'esplosione delle forme (shape explosion).

4. Risultati Sperimentali

Gli autori hanno valutato D-cut su sei modelli target (coprendo architetture dense e MoE) attraverso cinque benchmark (math, code, chat) utilizzando GPU NVIDIA H20 e H800.

Miglioramento del Throughput: Sotto alta concorrenza (batch size 32), D-cut migliora lo speedup medio rispetto al decoding autoregressivo da 1.26× a 1.65× rispetto alla baseline DFlash.
Ripristino dell'Accelerazione: Per i modelli densi dove DFlash (con draft lunghi) scende al di sotto del decoding AR ad alta concorrenza, D-cut ripristina l'accelerazione positiva.
Performance MoE: Sui modelli Mixture-of-Experts (MoE), D-cut raggiunge fino a 3.0× di speedup rispetto al decoding autoregressivo.
Adattività all'Hardware:
- Su H20, limitata dal calcolo, D-cut effettua un pruning aggressivo (selezionando spesso un budget del 25%), superando significativamente le baseline a rapporto fisso.
- Su H800, ricca di calcolo, D-cut si adatta per mantenere più token (spesso il 50% o più), massimizzando il throughput senza un pruning non necessario.
Robustezza: D-cut mantiene il suo vantaggio anche sotto il campionamento stocastico del target (temperatura 1), dove i metodi standard a draft lungo falliscono completamente.

5. Significato e Rivendicazioni

Il documento sostiene che D-cut affronta un disallineamento fondamentale nei sistemi attuali di speculative decoding: l'assunto che draft più lunghi siano sempre migliori. Gli autori argomentano che nel serving batch, il calcolo della verifica è la risorsa scarsa, non solo la capacità di generare draft.

Cambio di Paradigma: Il lavoro sposta l'attenzione dal massimizzare le lunghezze di accettazione del singolo request alla gestione dell'efficienza della verifica batch.
Impatto Pratico: D-cut consente l'uso di potenti drafter block-parallel in ambienti di produzione ad alta concorrenza dove sarebbero altrimenti dannosi.
Limitazioni: Gli autori riconoscono una sfida di integrazione di sistema: la forma variabile del batch di verifica richiede una gestione attenta per rientrare nelle assunzioni di forma statica degli attuali motori di inferenza (come Spec-V2 e i piecewise CUDA graph). Notano che realizzare il pieno potenziale della verifica dinamica potrebbe richiedere un co-design più stretto con i framework di serving.

In sintesi, D-cut fornisce un meccanismo per bilanciare dinamicamente il compromesso tra il beneficio algoritmico dell'accettazione di più token e il costo hardware della loro verifica, assicurando che lo speculative decoding rimanga una tecnica di accelerazione valida anche sotto carichi pesanti.