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)yacceptance 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-smally 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 TPSyUser 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):
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
Salida ejemplo (resumen):
- Acceptance Length Histogram: 1: 57385, 2: 36968, 3: 24441, 4: 61182
- Conditional acceptance rate: 1 -> 1.0, 2 -> 0.681, 3 -> 0.698, 4 -> 0.715
- 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:
ALy 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 ratey throughput real bajo diferentesISLy 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.