SPEED-Bench: benchmark unificado para speculative decoding | Keryc
SPEED-Bench llega para poner orden en cómo medimos la especulación en modelos de lenguaje. ¿Qué tan bien funciona la idea de usar un modelo ligero que propone varios tokens adelantados y luego dejar que el modelo objetivo verifique en paralelo? Eso depende mucho de los datos, del régimen de servicio y del sistema. SPEED-Bench propone un estándar para medirlo de forma realista.
Qué es SPEED-Bench
Speculative decoding (SD) usa un draft model ligero para especular múltiples tokens futuros, que luego el target model verifica en paralelo. La gracia: mejorar el rendimiento (throughput) sin cambiar la distribución exacta de salida del modelo final.
SPEED-Bench es un benchmark unificado pensado para evaluar SD en condiciones cercanas a producción. Combina datasets con amplia variedad semántica, buckets de longitud de contexto realistas y un framework de medición que integra motores de inferencia de grado productivo como TensorRT-LLM, vLLM y SGLang.
Por qué los benchmarks anteriores fallan
Conjuntos de prompts pequeños y poca diversidad semántica.
Secuencias de entrada cortas y batch size = 1, que no reflejan cargas reales.
Uso de pilas de inferencia de alto nivel que ocultan detalles del sistema.
En la práctica, la calidad de la especulación y la ganancia en velocidad dependen de: el dominio semántico, la entropía del texto, la longitud del contexto, el tamaño de batch y si la carga es memory-bound o compute-bound. SPEED-Bench está diseñado para capturar esas dependencias.
Cómo está diseñado SPEED-Bench
SPEED-Bench combina tres elementos principales:
Una splitting cualitativa (Qualitative) enfocada en diversidad semántica para medir calidad de drafts: acceptance rates (AR) y acceptance lengths (AL).
Una splitting de rendimiento (Throughput) para medir speedups a nivel de sistema en distintos input sequence lengths (ISL) y alta concurrencia.
Un framework de medición que normaliza tokenización y formateo, y que se integra con motores de producción para obtener métricas comparables.
Qualitative split
Agregaron ejemplos de 18 fuentes públicas y los organizaron en 11 categorías: Coding, Math, Humanities, STEM, Writing, Summarization, Roleplay, RAG, Multilingual, Reasoning y QA.
Cada categoría tiene 80 muestras, total 880 prompts.
Para maximizar diversidad semántica usan embeddings openai/text-embedding-3-small y un algoritmo de selección que minimiza la similitud coseno promedio entre pares dentro de cada categoría. Eso reduce redundancia y expone comportamientos dependientes del dominio.
Throughput split
ISL buckets desde 1k hasta 32k tokens, para reflejar aplicaciones de contexto largo como asistentes de código y RAG.
Para cada bucket: 1,536 prompts (512 por nivel de dificultad: baja, mixta, alta entropía).
Se controlan truncado y padding para mantener costos de prefill deterministas y evitar usar tokens aleatorios.
Framework de medición
Tokenización y formateo se hacen externamente: las inferencias reciben secuencias pre-tokenizadas para eliminar diferencias silenciosas entre motores.
Captura medidas finas desde respuestas por streaming: step latency, acceptance behavior, Output TPS y User TPS.
Integración con TensorRT-LLM, vLLM y SGLang para comparar en condiciones reales.
Ejemplo práctico y salida de la herramienta
Ejemplo de ejecución (Llama 3.3 70B Instruct como target, EAGLE3 como drafter, TensorRT-LLM, batch 32):
Acceptance Rate promedio por categoría (ejemplo): overall average AR = 2.4511
Output TPS: 2518.15 (Output TPS/gpu = 314.77)
E2E Request Time (media): 4.7313 s
TTFT Time (media): 0.1217 s
También comparan AL y speedups por dominio y modelos. Resumen de la tabla mostrada en el paper:
Domain
Llama 3.3 70B (N-Gram)
GPT OSS 120B (EAGLE3)
Qwen3-Next (MTP)
Coding
1.54
2.46
3.34
Math
1.43
2.46
3.13
Roleplay
1.15
1.87
2.09
Writing
1.33
1.98
2.46
Mean AL
1.41
2.25
2.81
Mean Speedup
0.88x
1.34x
1.20x
Estos resultados muestran claramente que:
AL y speedups son altamente dependientes del dominio: Coding y Math (baja entropía) permiten aceptaciones más largas, Roleplay y Writing (alta entropía) son mucho más difíciles de especular.
Métodos ligeros como N-Gram pueden incluso producir slowdowns en batch moderados.
MTP nativo (co-entrenado con la base) suele lograr ALs mayores que drafters post-entrenados como EAGLE3.
Hallazgos técnicos importantes
La evaluación de SD debe mirar dos cosas: la calidad del draft por dominio y el rendimiento a nivel de sistema bajo condiciones reales.
Vocabulary pruning en drafters (por ejemplo EAGLE3) reduce costo, pero puede degradar AL en la larga cola de inputs, especialmente en Multilingual, RAG y Summarization.
El uso de tokens aleatorios para medir throughput es peligroso: genera dos fallas principales que distorsionan resultados para SD y MoE:
Trivial Response: el modelo detecta ruido y responde con aclaraciones, inflando AL.
Topic Latching: el modelo ancla en palabras clave y genera respuestas coherentes pero engañosas, reduciendo AL.
Ejemplo cuantitativo: medir con tokens aleatorios puede sobreestimar throughput en aproximadamente 23% cuando SD está activo.
Recomendaciones prácticas si trabajas con SD
Evalúa both: acceptance length/acceptance rate y throughput real bajo diferentes ISL y batch sizes.
Evita usar tokens aleatorios como proxy de carga de prompts.
Usa conjuntos con diversidad semántica y evita categorías con muy pocas muestras.
Prefiere mediciones que controlen tokenización y prompt formatting externamente para comparar motores de inferencia.
Ten en cuenta que optimizaciones a nivel de vocabulario o cabeza final pueden ayudar en dominios cerrados pero perjudicar la generalidad.
SPEED-Bench no es solo un dataset: es un ecosistema con datasets, framework de medición y scripts listos para integrar en pipelines de SD. Sirve tanto a investigadores que buscan comparar algoritmos como a equipos de producción que necesitan entender trade-offs reales entre latencia, throughput y fidelidad de salida.
