💬 NLP

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

D-Cut es un método de poda de profundidad de verificación adaptativo para la decodificación especulativa por lotes que asigna dinámicamente presupuestos de verificación entre solicitudes concurrentes basándose en la confianza del borrador y modelos de costo en tiempo de ejecución, mejorando significativamente la aceleración de la inferencia bajo alta concurrencia mientras evita el desperdicio de computación en tokens rechazados.

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

Publicado 2026-07-17

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

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

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que diriges una biblioteca masiva de alta velocidad donde un único bibliotecario increíblemente inteligente (la IA) responde preguntas de miles de personas a la vez. Este bibliotecario es brillante pero trabaja de una manera muy específica: solo puede escribir una palabra a la vez. Para responder a una pregunta compleja, tiene que hacer una pausa, pensar, escribir una palabra, hacer otra pausa, pensar, escribir la siguiente palabra, y así sucesivamente. Esta regla de "una palabra a la vez" es la razón principal por la que la biblioteca se congestiona; el bibliotecario pasa la mayor parte del tiempo simplemente esperando a coger la siguiente palabra de los estantes.

Para acelerar las cosas, los ingenieros inventaron un truco ingenioso llamado "decodificación especulativa". En lugar de dejar que el bibliotecario escriba una palabra a la vez, contratan a un asistente ligeramente menos inteligente (el "redactor") para que adivine las siguientes palabras en un estallido. El bibliotecario luego verifica rápidamente estas conjetas. Si las conjetas son correctas, acepta todas a la vez, saltándose el ciclo lento de "pensar-pausa-escribir" para esas palabras. Es como si el asistente gritara: "¡Apuesto a que las próximas tres palabras son 'El', 'rápido' y 'marrón'!" y el bibliotecario dijera: "¡Sí, tienes razón!", y así continúa. Esto funciona de maravilla cuando la biblioteca está tranquila. Pero, ¿qué pasa cuando la biblioteca está abarrotada con 64 personas gritando preguntas al mismo tiempo? El asistente podría gritar una larga lista de conjetas para todos, pero el bibliotecario se ve abrumado intentando verificarlas todas. Si las conjetas son erróneas, el bibliotecario pierde un tiempo precioso verificando palabras que luego se desechan, ralentizando toda la biblioteca. Este es el rompecabezas que este artículo aborda: cómo mantener la mejora de velocidad cuando la multitud es enorme.

El Problema: Demasiadas Conjetas, No Suficiente Tiempo

Los investigadores de Tencent Hunyuan notaron un fallo en el sistema. Recientemente, los nuevos asistentes (como uno llamado DFlash) se volvieron muy buenos gritando largas listas de conjetas—por ejemplo, 15 palabras a la vez. Cuando la biblioteca estaba vacía, esto era un superpoder; el bibliotecario aceptaba la mayoría de ellas y la biblioteca avanzaba volando a través de las preguntas.

Pero a medida que la multitud crecía (cuando el "tamaño del lote" o número de solicitudes simultáneas aumentaba), el sistema empezaba a colapsar. El asistente seguía gritando largas listas, pero el bibliotecario, ahora estirado al máximo, no podía verificarlas todas lo suficientemente rápido. Peor aún, muchas de esas largas listas eran erróneas. El bibliotecario gastaba toda su energía verificando palabras que resultaban ser basura, solo para rechazarlas. Era como un guardia de seguridad en un concierto concurrido revisando las identificaciones de 15 personas en una fila, solo para darse cuenta de que 10 de ellas eran falsas, perdiendo tiempo que podría haber pasado dejando entrar a los fans reales. Los investigadores descubrieron que, con multitudes altas, este método de "conjetas largas" era en realidad más lento que dejar que el bibliotecario trabajara solo, una palabra a la vez.

La Solución: D-cut (El Portero Inteligente)

Para solucionar esto, el equipo propuso una nueva estrategia llamada D-cut. Piensa en D-cut como un portero súper inteligente que se interpone entre el asistente y el bibliotecario.

En lugar de dejar que el asistente grite una larga lista fija de conjetas para todos y que el bibliotecario las verifique todas, D-cut observa a la multitud y las conjetas en tiempo real. Hace dos preguntas simples:

¿Qué tan seguro está el asistente? Si el asistente grita con alta confianza, el portero deja pasar esas conjetas. Si el asistente balbucea o no está seguro, el portero acorta la lista.
¿Qué tan cansado está el bibliotecario? El portero comprueba la carga de trabajo actual del bibliotecario. Si el bibliotecario está saturado (como en un chip GPU ocupado), el portero se vuelve más estricto y recorta más conjetas. Si el bibliotecario está fresco y es potente (como en un chip diferente y más rápido), el portero deja pasar más conjetas.

D-cut no solo recorta la lista para una persona; observa el lote completo de solicitudes. Se da cuenta de que para algunas personas, el asistente es un genio, pero para otras, el asistente está adivinando salvajemente. Así, D-cut toma el "presupuesto de verificación" (el tiempo que el bibliotecario tiene para verificar) y se lo entrega a las personas que tienen más probabilidades de estar en lo cierto. Podas (recorta) las colas largas y de baja confianza de las conjetas de las solicitudes inseguras y enfoca la energía del bibliotecario en las partes de alta confianza.

Cómo Funciona en el Mundo Real

Los investigadores probaron esta idea en una variedad de modelos de IA, desde pequeños hasta masivos, y en diferentes tipos de chips informáticos. Descubrieron que D-cut era un cambio radical para los momentos de mucha actividad:

Salvando el día en las altas multitudes: Cuando el número de solicitudes era alto (como 64 personas a la vez), el método antiguo (DFlash) a menudo se ralentizaba tanto que era en realidad más lento que el método estándar de "una palabra a la vez". D-cut solucionó esto. Mantuvo la aceleración viva incluso cuando la biblioteca estaba repleta.
Los Números: En sus pruebas, D-cut aumentó la velocidad promedio de 1.26 veces más rápido a 1.65 veces más rápido en comparación con el método estándar bajo carga alta. En algunos modelos específicos y muy grandes, incluso alcanzó hasta 3.0 veces la velocidad.
Adaptándose al Hardware: Una de las características más geniales es que D-cut aprende qué tan rápido es el bibliotecario antes de que llegue la multitud. Perfila el chip informático (como un GPU H20 o H800) para ver qué tan costoso es verificar una palabra. Si verificar una palabra es costoso (como en un chip más lento), D-cut recorta de forma más agresiva. Si es barato, recorta menos. Esto significa que no necesita que un humano lo ajuste para cada nuevo ordenador; lo descubre automáticamente.

Lo Que No Hace (Y Lo Que Descarta)

Es importante saber qué no es D-cut. No intenta hacer al asistente más inteligente ni cambia cómo piensa el bibliotecario. No cambia las respuestas finales que da la IA; el resultado es exactamente el mismo que si el bibliotecario hubiera verificado todo, solo que se llega a él mucho más rápido.

El artículo argumenta explícitamente en contra de la idea de que "más largo siempre es mejor". Demostraron que generar ciegamente largas listas de conjetas (como los bloques de 15 palabras en DFlash) es una mala idea cuando la multitud es grande. El enfoque de "talla única" de verificar el mismo número de conjetas para todos falla porque no todos necesitan la misma cantidad de verificación. D-cut demuestra que ser selectivo es mejor que ser exhaustivo.

La Conclusión

Los investigadores no solo sugirieron que esto podría funcionar; lo midieron. Ejecutaron simulaciones y pruebas del mundo real en servidores reales con miles de solicitudes. Los resultados mostraron que, al ser un portero inteligente y adaptativo que recorta las conjetas de baja confianza y se enfoca en las de alta confianza, D-cut mantiene la biblioteca de IA funcionando rápido incluso cuando las puertas están a punto de reventar. Convierte un sistema que de otro modo se ralentizaría hasta casi detenerse en uno que se mantiene eficiente, demostando que, a veces, la mejor manera de ir rápido es dejar de verificar las cosas que sabes que están mal.

Resumen Técnico: D-cut: Poda de Profundidad de Verificación Adaptativa para Decodificación Especulativa por Lotes

1. Declaración del Problema

La decodificación especulativa ha surgido como un enfoque sin pérdida líder para acelerar la inferencia de Modelos de Lenguaje de Gran Escala (LLM) al desacoplar la generación del borrador de la verificación. Avances recientes, como los redactores paralelos por bloques (por ejemplo, DFlash), generan bloques enteros de tokens de borrador en una sola pasada hacia adelante (forward pass), desacoplando la longitud del borrador de la latencia de redacción y logrando un alto MAT (Mean Accepted Tokens) en configuraciones de baja concurrencia.

Sin embargo, el artículo identifica un cuello de botella crítico en el servicio por lotes de alta concurrencia:

Explosión del Costo de Verificación: A medida que el tamaño del lote ( $B$ ) aumenta, el modelo objetivo debe verificar $B \times (D+1)$ tokens por paso (donde $D$ es la longitud del borrador). Esto desplaza el proceso de verificación de estar limitado por la memoria a estar limitado por el cómputo.
Asignación Ineficiente de Recursos: En escenarios de alta concurrencia, los borradores de profundidad fija y larga suelen resultar en una alta tasa de rechazo. Por ejemplo, con una longitud de borrador de 15, la longitud de aceptación promedio puede ser de solo ~6 tokens, lo que significa que aproximadamente el 60% de los tokens verificados son rechazados.
Rendimiento (Throughput) Subóptimo: El costo computacional de verificar estos tokens rechazados infla el tiempo del paso, causando que el rendimiento de la decodificación especulativa se sature o incluso caiga por debajo de la decodificación autorregresiva (AR) estándar en tamaños de lote altos (por ejemplo, $bs=64$).
Necesidades Estáticas vs. Dinámicas: Los métodos existentes suelen aplicar una profundidad de verificación uniforme para todas las solicitudes en un lote. Esto no tiene en cuenta la significativa varianza en las longitudes de aceptación entre solicitudes concurrentes y los costos computacionales variables de la verificación en diferentes entornos de hardware (por ejemplo, GPUs H20 limitadas por cómputo frente a GPUs H800 ricas en cómputo).

2. Metodología: D-cut

Los autores proponen D-cut, una estrategia de poda adaptativa que trata el presupuesto de verificación como un recurso compartido en todo el lote, asignándolo dinámicamente a los tokens con mayor probabilidad de ser aceptados. El método opera sin modificar el modelo objetivo ni requerir entrenamiento adicional.

Mecanismos Principales

Poda Transversal de Solicitudes (Guiada por Confianza):
- En lugar de verificar una profundidad fija para cada solicitud, D-cut califica cada posición de token candidato en el lote utilizando la confianza de predicción del redactor.
- Calcula una puntuación de "producto de prefijo" ( $s_{i,k}$ ) para cada posición, que representa la probabilidad de que el bloque sobreviva hasta la profundidad $k$ .
- Todas las posiciones candidatas en el lote se clasifican globalmente mediante estas puntuaciones. Los sufijos de baja confianza se podan, mientras que los prefijos de alta confianza se retienen. Esto asegura que el presupuesto de verificación se desplace de las solicitudes de bajo rendimiento a las de alto rendimiento.
Selección de Profundidad Adaptativa en Tiempo de Ejecución:
- Reconociendo que el costo de verificar tokens adicionales depende fuertemente del entorno de ejecución (tipo de GPU, arquitectura del modelo, estrategia de paralelismo y tamaño del lote), D-cut incorpora un modelo de costo perfilado.
- Perfilado: Al inicio del servidor, D-cut perfila la latencia de extremo a extremo de los pasos especulativos para varias proporciones discretas de presupuesto de verificación ( $\rho \in \{0.25, 0.50, 0.75, 1.00\}$ ) y tamaños de lote.
- Optimización: Durante el servicio, D-cut selecciona dinámicamente la proporción de presupuesto global óptima ( $\rho^*$ ) que maximiza la aceleración proyectada. La aceleración se formula como la relación entre el beneficio esperado (MAT estimado basado en puntuaciones de confianza) y el costo de ejecución perfilado por hardware.
- Esto permite que D-cut sea agresivo en la poda en hardware limitado por cómputo (por ejemplo, H20) o cuando la calidad del borrador es baja, mientras retiene más tokens en hardware rico en cómputo (por ejemplo, H800) donde la verificación es barata.

Resumen del Pipeline

Redacción (Drafting): El redactor genera un bloque de tokens con sus respectivas puntuaciones de confianza.
Calificación y Clasificación (Scoring & Ranking): El selector aplana todas las posiciones, calcula las puntuaciones de producto de prefijo y las clasifica globalmente.
Selección de Presupuesto: El selector consulta la tabla de costos pre-perfilada para elegir la proporción de presupuesto $\rho^*$ que maximice la relación utilidad-costo.
Empaquetado (Packing): Las $K$ posiciones con mayor puntuación se empaquetan en un lote de verificación denso. Crucialmente, debido a que las puntuaciones son productos de prefijos, las posiciones retenidas para cada solicitud forman un prefijo contiguo, asegurando la compatibilidad con los motores de inferencia existentes y los gráficos CUDA.
Verificación: El modelo objetivo verifica el lote empaquetado.

3. Contribuciones Clave

Identificación del Cuello de Botella: El artículo demuestra empíricamente que en el servicio por lotes de alta concurrencia, los borradores de profundidad fija larga (como DFlash) pueden degradar el rendimiento por debajo de la decodificación AR debido al alto costo de verificar los tokens rechazados.
Algoritmo D-cut: Una estrategia de poda sin pérdida y sin necesidad de entrenamiento que realiza la poda de la profundidad de verificación transversal de solicitudes guiada por la confianza del borrador y la selección de profundidad adaptativa al tiempo de ejecución.
Modelado de Costo en Tiempo de Ejecución: La introducción de un modelo de costo perfilado que permite a la estrategia de poda adaptarse a entornos de despliegue específicos (hardware, tamaño de lote, arquitectura de modelo) en lugar de depender de heurísticas estáticas.
Integración de Sistema: El método está diseñado para trabajar con motores de inferencia existentes (por ejemplo, vLLM) al restringir el presupuesto de verificación a proporciones discretas, asegurando la compatibilidad con la captura de gráficos CUDA por partes (piecewise) y evitando la explosión de formas (shape explosion).

4. Resultados Experimentales

Los autores evaluaron D-cut en seis modelos objetivo (cubriendo arquitecturas densas y MoE) a través de cinco benchmarks (matemáticas, código, chat) utilizando GPUs NVIDIA H20 y H800.

Mejora del Rendimiento (Throughput): Bajo alta concurrencia (tamaño de lote 32), D-cut mejora la aceleración promedio sobre la decodificación autorregativa de 1.26× a 1.65× en comparación con la línea base DFlash.
Restauración de la Aceleración: Para modelos densos donde DFlash (con borradores largos) cae por debajo de la decodificación AR en alta concurrencia, D-cut restaura la aceleración positiva.
Desempeño en MoE: En modelos de Mezcla de Expertos (MoE), D-cut logra hasta un 3.0× de aceleración sobre la decodificación autorregativa.
Adaptabilidad al Hardware:
- En la GPU H20, limitada por cómputo, D-cut poda agresivamente (seleccionando a menudo un presupuesto del 25%), superando significativamente a las líneas base de proporción fija.
- En la GPU H800, rica en cómputo, D-cut se adapta para retener más tokens (a menudo 50% o más), maximizando el rendimiento sin una poda innecesaria.
Robustez: D-cut mantiene su ventaja incluso bajo muestreo estocástico del objetivo (temperatura 1), donde los métodos estándar de borrador largo fallan completamente.

5. Significado y Reivindicaciones

El artículo afirma que D-cut aborda un desajuste fundamental en los sistemas actuales de decodificación especulativa: la suposición de que los borradores más largos son siempre mejores. Los autores argumentan que en el servicio por lotes, el cómputo de verificación es el recurso escaso, no solo la capacidad de generar borradores.

Cambio de Paradigma: El trabajo desplaza el enfoque de maximizar las longitudes de aceptación de una sola solicitud hacia la gestión de la eficiencia de la verificación por lotes.
Impacto Práctico: D-cut permite el uso de redactores potentes basados en bloques en entornos de producción de alta concurrencia donde, de otro modo, serían perjudiciales.
Limitaciones: Los autores reconocen un desafío de integración de sistema: la forma variable del lote de verificación requiere un manejo cuidadoso para ajustarse a las suposiciones de forma estática de los motores de inferencia actuales (como Spec-V2 y gráficos CUDA por partes). Señalan que realizar el pleno potencial de la verificación dinámica puede requerir un codiseño más estrecho con los marcos de servicio (serving frameworks).

En resumen, D-cut proporciona un mecanismo para equilibrar dinámicamente la compensación entre el beneficio algorítmico de aceptar más tokens y el costo de hardware de verificarlos, asegurando que la decodificación especulativa siga siendo una técnica de aceleración viable incluso bajo carga pesada.