NVIDIA presentó SPEED-Bench — un benchmark unificado para speculative decoding

NVIDIA presentó SPEED-Bench en Hugging Face — un nuevo benchmark para speculative decoding, una técnica para acelerar la inference de grandes modelos de lenguaje. Su objetivo no es medir picos de rendimiento de laboratorio, sino el comportamiento de los modelos y de los inference engines en tareas más cercanas a la operación real.

Cómo funciona SPEED-Bench

Los autores parten de un problema simple: las pruebas existentes están fragmentadas. Unas evalúan la calidad del draft model sobre muestras demasiado pequeñas, otras miden el throughput con prompts cortos y batch size 1, y otras dependen de un stack concreto que refleja mal el entorno de producción. Como resultado, comparar entre sí los métodos de speculative decoding es difícil: un mismo algoritmo puede verse excelente en un toy dataset y bastante peor en contextos largos o con alta concurrencia de solicitudes.

SPEED-Bench está dividido en dos partes y se complementa con un framework unificado de medición. En el qualitative split hay 880 prompts procedentes de 18 fuentes públicas, distribuidos en 11 categorías — desde coding y math hasta roleplay, RAG, summarization y multilingual. En cada categoría hay 80 ejemplos, seleccionados para reducir la duplicación semántica y cubrir la mayor cantidad posible de escenarios distintos. Para esa selección, los autores generaron embedding de los candidatos con el modelo text-embedding-3-small y minimizaron la similitud media por pares dentro de cada categoría.

• Qualitative split mide acceptance rate y acceptance length en distintos dominios
• Throughput split comprueba la velocidad en secuencias de entrada de 1k a 32k tokens
• Para cada longitud hay tres niveles de dificultad: low-, mixed- y high-entropy
• Un bucket contiene 1.536 prompts, lo que permite construir curvas estables de throughput con batch size de hasta 512
• El framework puede trabajar con TensorRT-LLM, vLLM y SGLang

También se resolvió por separado el problema de la comparación justa entre engines. Distintos sistemas de inference aplican chat templates, BOS tokens y tokenization de forma diferente, por lo que un mismo modelo puede recibir entradas ligeramente distintas. En SPEED-Bench, la preparación del prompt se saca fuera: los engines reciben secuencias ya pretokenized. Esto reduce la influencia de las diferencias de implementación y permite comparar los propios algoritmos de speculative decoding, y no los efectos secundarios del preprocessing. El framework también recoge telemetría detallada sobre step latency, user TPS y output throughput total.

Qué mostraron las pruebas

Los primeros resultados muestran que speculative decoding depende mucho del tipo de tarea. En dominios de baja entropía, como coding y math, la acceptance length es mayor: al drafter le resulta más fácil adivinar los siguientes tokens. En tareas más abiertas, como roleplay y writing, las métricas son más bajas. En los ejemplos del artículo, los MTP-heads nativos de Qwen3-Next dan una acceptance length media de 2,81, EAGLE3 en GPT-OSS 120B alcanza 2,25 y N-Gram en Llama 3.3 70B llega a 1,41; al mismo tiempo, N-Gram con batch size 32 cae incluso a una ralentización media de 0,88x en lugar de aceleración.

Otra conclusión tiene que ver con las optimizaciones agresivas. Los autores analizan por separado el vocabulary pruning en EAGLE3 — una técnica que reduce el coste de la proyección final. En coding y math su efecto es casi imperceptible, pero en la larga cola de solicitudes de usuarios, especialmente en multilingual, RAG y summarization, la acceptance length cae más. Es decir, una optimización que parece inocua en un dataset estrecho puede empeorar el comportamiento real en un conjunto más amplio de tareas.

La observación más práctica está relacionada con los synthetic workloads. En la industria sigue siendo habitual ejecutar inference sobre tokens aleatorios, pero para speculative decoding este modo distorsiona la imagen. El modelo reconoce el ruido, responde de forma estereotipada y eleva artificialmente la acceptance length. En las mediciones de SPEED-Bench, esto provoca una sobreestimación del throughput de aproximadamente un 23% en comparación con workloads realistas. Para los equipos, es una señal directa: los benchmarks sintéticos pueden llevar a elegir mal la draft length o incluso todo el esquema de aceleración.

Qué significa esto

SPEED-Bench es un intento de acercar la evaluación de speculative decoding a lo que realmente importa para los equipos que operan LLM en producción: contextos largos, batch sizes altos, distintos dominios y condiciones comparables entre engines. Si el benchmark se consolida, la discusión sobre la aceleración de LLM se desplazará de las cifras vistosas en pruebas sintéticas a datos reproducibles sobre dónde exactamente funciona la aceleración y dónde no. Para los equipos de infra y research, eso es más útil que otro récord en un único dataset conveniente.