Este método utiliza un modelo de borrador ligero para predecir múltiples tokens futuros, los cuales son luego verificados en paralelo por el modelo objetivo. De este modo, SD puede mejorar significativamente el rendimiento sin alterar la distribución de salida del modelo.
A pesar de los avances en los algoritmos de SD, su evaluación sigue siendo fragmentada y a menudo no representa las condiciones reales de datos y servicio.
En la práctica, la calidad de la especulación de SD y la velocidad de inferencia dependen de manera crítica de los datos, el régimen de servicio y el sistema.
Sin embargo, la mayoría de los bancos de pruebas actuales dependen de conjuntos de prompts pequeños, diversidad semántica limitada, cortas longitudes de secuencia de entrada, tamaños de lote de uno o pilas de inferencia de alto nivel que no reflejan entornos de producción.
Para abordar estas limitaciones, presentamos SPEED-Bench: un banco de pruebas unificado diseñado para evaluar SD en diversos dominios semánticos y regímenes de servicio realistas, utilizando motores de inferencia de calidad de producción.
¿Qué es SPEED-Bench?
La evaluación de SD debe considerar dos perspectivas.
Por un lado, la calidad del borrador depende del dominio semántico y la entropía del texto de entrada.
Por otro lado, las mejoras en el mundo real dependen del tamaño de lote, longitud de secuencia de entrada (ISL) y restricciones del sistema, que determinan si la inferencia está limitada por la memoria o por el cómputo.
SPEED-Bench introduce un ecosistema de evaluación para SD.
Combina dos divisiones de conjuntos de datos diseñadas para capturar diferentes aspectos del comportamiento de SD:
- División “Cualitativa”, optimizada para diversidad semántica y diseñada para medir la calidad de la especulación (precisión del borrador) en diferentes dominios.
- División “Rendimiento”, construida para evaluar mejoras a nivel de sistema en diversas longitudes de secuencia de entrada y alta concurrencia.
- Un marco de medición unificado, integrado con motores de inferencia de producción, que estandariza la evaluación entre sistemas.
Estos componentes permiten a los profesionales e investigadores analizar el comportamiento de SD que a menudo está oculto por los bancos de pruebas existentes.
La figura 1 ofrece una visión general del ecosistema SPEED-Bench.
La división cualitativa: cobertura semántica y precisión del borrador
El objetivo de la división cualitativa es medir la calidad del decodificador especulativo, específicamente las tasas de aceptación condicional (ARs) y las longitudes de aceptación (ALs) en una amplia variedad de dominios semánticos.
SpecBench introdujo el primer banco de pruebas unificado de SD en diversos escenarios de aplicación, como conversaciones multivuelta, traducción y razonamiento matemático, al agregar instancias de conjuntos de datos ampliamente utilizados en un entorno de prueba unificado. Sin embargo, a pesar de ser un avance significativo hacia evaluaciones estandarizadas, presenta limitaciones críticas en cuanto a escala y diversidad. La mayoría de las categorías contienen tan solo 10 muestras con longitudes de entrada promedio cortas (< 100 tokens) que pueden no exigir a los borradores modernos. Además, algunas de sus categorías a menudo carecen de diversidad estructural, como la categoría multilingüe que consiste únicamente en prompts de traducción de alemán a inglés.
Si bien la evaluación exhaustiva en numerosos conjuntos de datos es teóricamente posible, resulta tediosa, poco práctica para experimentación rápida y dificulta las comparaciones directas entre diferentes grupos de investigación que publican algoritmos y modelos de SD. En lugar de depender de evaluaciones exhaustivas en conjuntos de datos dispares, curamos un subconjunto compacto pero altamente representativo diseñado para maximizar la diversidad semántica.
Agregamos datos de 18 fuentes disponibles públicamente y los organizamos en 11 categorías, incluyendo Programación, Matemáticas, Humanidades, STEM, Redacción, Resumen, Juego de Roles, RAG, Multilingüe, Razonamiento y QA.
Cada categoría contiene 80 muestras, resultando en un total de 880 prompts.
A diferencia de los bancos de pruebas previos, que a menudo sufren de baja diversidad intra-categoría, la división cualitativa de SPEED-Bench prioriza explícitamente la diversidad semántica.
Para lograr esto, cada prompt candidato se embebe en un espacio vectorial denso utilizando un embebedor de texto preentrenado (openai/text-embedding-3-small).
Luego aplicamos un algoritmo de selección que minimiza la similitud coseno promedio entre pares dentro de cada categoría.
Esto asegura que las muestras seleccionadas abarquen el espacio semántico de la manera más amplia posible, reduciendo la redundancia y aumentando la fidelidad de la evaluación.
La efectividad de este enfoque se muestra en Figura 2, que compara la similitud semántica promedio entre SPEED-Bench y SpecBench.
Esta diversidad semántica es crucial para exponer el comportamiento dependiente del dominio en SD, como el fuerte contraste entre dominios de baja entropía (por ejemplo, Programación, Matemáticas) y dominios de alta entropía (por ejemplo, Juego de Roles, Redacción).
La división de rendimiento: cargas de trabajo de servicio realistas
Si bien la división cualitativa captura la precisión del borrador, es insuficiente para evaluar las mejoras a nivel de sistema.
Evaluamos las mejoras a nivel de sistema utilizando dos métricas: Rendimiento (Output TPS), que mide el total de tokens generados por segundo en todas las solicitudes concurrentes, y User TPS, que representa la tasa de generación de tokens por solicitud. User TPS actúa como un proxy para la latencia del usuario.
En entornos de producción, los modelos se ofrecen bajo alta concurrencia y una amplia gama de longitudes de secuencia de entrada, que a menudo son mucho más largas que las muestras cortas de ISL utilizadas en muchos bancos de pruebas de SD.
A medida que aumenta el tamaño del lote, la inferencia a menudo transita de un régimen limitado por cómputo a uno limitado por memoria, cambiando fundamentalmente la relación costo-beneficio de la decodificación especulativa.
La división de rendimiento está diseñada específicamente para capturar este comportamiento.
Construimos cubos de ISL fijos que varían de 1k a 32k tokens, reflejando la creciente importancia de aplicaciones de contexto largo como asistentes de codificación y generación aumentada por recuperación.
Para cada cubo de ISL, los prompts se agrupan en tres categorías de dificultad gruesa correspondientes a dominios de baja, mixta y alta entropía.
Cada cubo de ISL contiene 1,536 prompts (512 por categoría de dificultad), lo que proporciona un volumen suficiente para construir curvas de Pareto estables de rendimiento en una amplia gama de tamaños de lote (Figura 3).
Para asegurar un costo de prellenado determinista, los prompts se truncan o rellenan de manera controlada, mientras se preserva su contenido semántico.
Es importante destacar que SPEED-Bench evita el uso de entradas de tokens aleatorios para la evaluación de rendimiento.
Como mostraremos más adelante, los tokens aleatorios pueden distorsionar gravemente el comportamiento de aceptación, el enrutamiento experto en modelos de Mixtura de Expertos (MoE) y las mediciones de rendimiento, llevando a conclusiones excesivamente optimistas.
Un marco de medición unificado
Evaluar SD en diferentes motores de inferencia presenta un desafío sutil pero crítico.
Diferentes motores pueden aplicar diferentes plantillas de chat, manejar tokens BOS de manera diversa o tokenizar entradas de forma inconsistente.
Estas diferencias pueden alterar silenciosamente la secuencia redactada, haciendo que las comparaciones entre motores sean poco fiables.
SPEED-Bench introduce un marco de medición ligero que maneja tokenización y formato de prompts externamente.
Los motores de inferencia reciben secuencias pre-tokenizadas, asegurando que todos los sistemas procesen entradas idénticas.
El marco se integra con motores de calidad de producción: TensorRT-LLM, vLLM y SGLang.
Captura información de tiempo detallada de respuestas en streaming para computar el comportamiento de aceptación, latencia por paso, tokens por segundo a nivel de usuario y rendimiento general.
A continuación se muestra un ejemplo de funcionamiento de nuestro marco de medición en Llama 3.3 70B Instruct como modelo objetivo con EAGLE3 como modelo borrador en la división cualitativa de SPEED-Bench, utilizando TensorRT-LLM con un tamaño de lote de 32 (8*H100 GPUs):
Ejemplo de salida del marco de medición
bash-5.2$ mpirun -n 1 --oversubscribe python3 run.py --model_dir meta-llama/Llama-3.3-70B-Instruct --tokenizer meta-llama/Llama-3.3-70B-Instruct --draft_model_dir yuhuili/EAGLE3-LLaMA3.3-Instruct-70B --dataset speed --dataset_path data/speed/qualitative --tp_size 8 --ep_size 1 --draft_length 3 --output_length 4096 --engine TRTLLM --concurrency 32 --show_progress ... [TensorRT-LLM] TensorRT LLM version: 1.2.0rc1 ... Running requests (c): 100%|██████████| 880/880 [02:58<00:00, 4.93it/s] ... Acceptance Length Histogram {1: 57385, 2: 36968, 3: 24441, 4: 61182} Conditional acceptance rate 1 1.0 2 0.681151931368627 3 0.6984444208791836 4 0.7145509968116043 Acceptance Rate Results ┏━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓ ┃ Category ┃ Average AR ┃ ┡━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━┩ │ coding │ 3.0001 │ │ humanities │ 2.3699 │ │ math │ 2.4710 │ │ multilingual │ 1.7277 │ │ qa │ 2.3184 │ │ rag │ 2.7502 │ │ reasoning │ 2.6142 │ │ roleplay │ 2.0407 │ │ stem │ 2.4306 │ │ summarization │ 2.6026 │ │ writing │ 2.6364 │ ├─────────────────┼────────────┤ │ Overall Average │ 2.4511 │ └─────────────────┴────────────┘ Output TPS 2518.1464055829188 Output TPS/gpu 314.76830069786485 E2E Request Time {'min': '0.1031', 'max': '51.3442', 'mean': '4.7313', 'std': '4.8872', 'quantiles': {'0.25': '1.6972', '0.5': '3.5459', '0.75': '6.1715'}} TTFT Time {'min': '0.0528', 'max': '0.8010', 'mean': '0.1217', 'std': '0.1133', 'quantiles': {'0.25': '0.0841', '0.5': '0.0982', '0.75': '0.1139'}} Request Generation Step Time {'min': '0.0000', 'max': '0.8010', 'mean': '0.0299', 'std': '0.0173', 'quantiles': {'0.25': '0.0259', '0.5': '0.0267', '0.75': '0.0280'}} Request Generation Tokens Per Second {'min': '35.1116', 'max': '142.9547', 'mean': '85.3162', 'std': '17.4823', 'quantiles': {'0.25': '75.0608', '0.5': '84.9756', '0.75': '97.0815'}} Number of Output Tokens {'min': '3.0000', 'max': '4096.0000', 'mean': '394.8787', 'std': '452.7451', 'quantiles': {'0.25': '123.0000', '0.5': '281.0000', '0.75': '518.2500'}}Este diseño aísla los efectos de los algoritmos de SD y las optimizaciones del sistema de los artefactos de preprocesamiento.
Perspectivas desde SPEED-Bench
Precisión y mejoras dependientes del dominio
La tabla a continuación reporta las longitudes de aceptación promedio y mejoras en diferentes dominios y modelos a un tamaño de lote realista (32) y una longitud de borrador de 3.
Los resultados confirman que la longitud de aceptación de SD es altamente dependiente del dominio.
Los dominios de baja entropía como Programación y Matemáticas consistentemente producen longitudes de aceptación más altas, mientras que las tareas de alta entropía como Juego de Roles y Redacción son más difíciles de especular.
La tabla también destaca las diferencias entre los métodos de especulación.
Enfoques ligeros como la especulación N-Gram pueden resultar en desaceleraciones netas a tamaños de lote moderados. Además, observamos que las cabezas MTP nativas logran longitudes de aceptación significativamente mayores que las alternativas post-entrenadas como EAGLE3, resaltando el beneficio de co-entrenar el modelo base y el borrador desde cero.
| Dominio | Llama 3.3 70B con N-Gram (TensorRT-LLM) | GPT OSS 120B con EAGLE3 (TensorRT-LLM) | Qwen3-Next con MTP (SGLang) |
|---|---|---|---|
| Programación | 1.54 | 2.46 | 3.34 |
| Matemáticas | 1.43 | 2.46 | 3.13 |
| Juego de Roles | 1.15 | 1.87 | 2.09 |
| Redacción | 1.33 | 1.98 | 2.46 |
| Promedio AL | 1.41 | 2.25 | 2.81 |
| Mejora Promedio | 0.88x | 1.34x | 1.20x |
Los resultados completos en la división cualitativa de todas las categorías y diferentes modelos están en nuestro documento.
La poda de vocabulario revela fallos de cola larga
SPEED-Bench también puede ayudar a exponer efectos secundarios de optimizaciones agresivas del sistema.
La poda de vocabulario se utiliza en EAGLE3 para reducir el costo computacional de la capa de proyección final.
Aunque es efectiva en dominios restringidos, esta optimización puede degradar la longitud de aceptación en la “cola larga” de entradas de usuario.
La figura 4 muestra la longitud de aceptación en diferentes dominios al usar vocabularios completos frente a podados para GPT-OSS 120B con EAGLE3.
El impacto es mínimo en Programación y Matemáticas, pero sustancial en las categorías Multilingüe, RAG y Resumen.
Estos efectos son en gran medida invisibles en bancos de pruebas de baja diversidad, subrayando la importancia de una amplia cobertura semántica en los datos de evaluación.
Los tokens aleatorios sobreestiman el rendimiento
Una práctica común en la evaluación de inferencia es utilizar tokens aleatorios para simular la carga de prompts.
Si bien puede ser suficiente para la decodificación autorregresiva, este enfoque es fundamentalmente defectuoso para los algoritmos de SD y incluso para modelos de mezcla de expertos (MoE) sin especulación, como se presenta a continuación.
Los tokens aleatorios desencadenan dos modos de fallo que distorsionan las mediciones:
- Respuesta Trivial: El modelo identifica el ruido y recurre a respuestas predecibles, inflando artificialmente las ALs.
Salida de ejemplo (Base: GPT-OSS 120b, Borrador: EAGLE3, Longitud de Borrador: 3, AL Promedio: 3.44):
Parece que has pegado un bloque de texto en varios idiomas que no forma una pregunta o solicitud clara. Estoy feliz de ayudar, pero necesito un poco más de orientación.
¿Podrías decirme qué te gustaría hacer con este texto? Por ejemplo: …
- Enganchado a Temas: El modelo se ancla a palabras clave específicas dentro del ruido y alucina una respuesta coherente, típicamente resultando en ALs más bajas.
Salida de ejemplo (Base: GPT-OSS 120b, Borrador: EAGLE3, Longitud de Borrador: 3, AL Promedio: 1.877):
Abajo hay un hoja de ruta expandida y lista para producción que te lleva desde la primera instalación de Unity hasta un plataformero 2D completo y pulido (jugador, cámara, enemigos, coleccionables, UI, audio, carga de niveles y una compilación final).
Todo está dividido en tareas pequeñas, cada una con las acciones exactas que necesitas realizar y fragmentos de C# listos para copiar.
…
La figura 5 compara el rendimiento medido utilizando tokens aleatorios frente a las cargas de trabajo de SPEED-Bench.
Cuando se habilita SD, los tokens aleatorios sobreestiman el rendimiento en aproximadamente un 23%.
Las entradas aleatorias también fallan en activar de manera realista el enrutamiento experto en modelos de MoE, llevando a mediciones de rendimiento inexactas incluso en configuraciones no especulativas, como se presenta en Figura 6.
Comienza a usar SPEED-Bench
SPEED-Bench se ha lanzado para establecer un estándar unificado para evaluar SD tanto en entornos de investigación como de producción.
Permite a los profesionales analizar la precisión del borrador en diversos dominios, medir el rendimiento bajo regímenes de servicio realistas, y comparar motores de inferencia utilizando cargas de trabajo idénticas.
El conjunto de datos y el marco de medición están disponibles públicamente y diseñados para integrarse directamente con implementaciones existentes de SD.
Recursos
Esperamos que SPEED-Bench ayude a impulsar una evaluación más rigurosa, realista y consciente del despliegue de la decodificación especulativa!
