Sesgo de medición y reproducibilidad: por qué dos benchmarks del mismo modelo dan cifras que difieren hasta 7×

Notación: importes en euros (N €), decimales con coma. El símbolo matemático se reserva para fórmulas: los importes se expresan en € o USD. Millar con espacio fino ((1,000)).

TL;DR

Correr el mismo modelo Llama-3-70B-Instruct en el mismo nodo de 4×H100 SXM 80 GB con dos herramientas distintas puede producir resultados de throughput que difieren 7,2× sin que el motor cambie una línea de código. La causa no es el motor: es el método de medida. A 1.000 QPS, un cliente asyncio mono-proceso (vLLM bench, SGLang bench, genai-perf pre-AIPerf) procesó 75.574 tokens frente a los 545.733 tokens de un cliente multi-proceso —ambos midiendo el mismo endpoint— (arXiv 2605.24217). El sesgo no es aleatorio: es sistemático, direccional y reproducible. Este artículo cataloga las fuentes de sesgo, cuantifica su magnitud y describe el harness mínimo que convierte un número en un dato auditable.

Las fuentes de sesgo: catálogo con magnitudes

Cada fuente de sesgo mueve el número publicado en una dirección determinada y con una magnitud característica. La tabla siguiente ordena las fuentes de mayor a menor impacto observado en la literatura:

El sesgo dominante: saturación del cliente mono-proceso

El sesgo de mayor magnitud no está en el motor sino en el cliente que genera la carga. Las herramientas mono-proceso (vLLM bench, SGLang bench, genai-perf antes de su reemplazo por AIPerf el 15 de abril de 2026) usan un único proceso Python con asyncio para gestionar las peticiones concurrentes. El Python Global Interpreter Lock (GIL) impide que un solo proceso utilice más de un núcleo CPU simultáneamente, lo que introduce un cuello de botella en el lado cliente que se vuelve crítico a alta concurrencia.

El efecto matemático: a medida que el request rate sube, el cliente no consigue despachar peticiones al ritmo configurado, acumula tiempo de espera en cola en el lado cliente, y ese tiempo se registra como latencia del motor. El resultado es que el TTFT y el TPOT aparecen inflados y el throughput aparece deprimido, sin que el motor haya cambiado nada (arXiv 2605.24217).

La discrepancia documentada a 1.000 QPS:

Nota: ambos clientes apuntan al mismo endpoint; la diferencia es íntegramente atribuible al cliente de benchmark, no al motor.

El sesgo del tokenizer: tok/s no son comparables entre vocabularios

Los tokens no son universales. Cada modelo tiene su propio tokenizer con su propio vocabulario. Llama-3 usa un vocabulario de 128.256 tokens; Gemma usa 256.128; modelos anteriores usaban 32.000–50.000. El mismo texto en inglés produce un número de tokens distinto según el tokenizer del modelo.

La consecuencia directa para el benchmarking: si la herramienta mide tok/s con un tokenizer distinto al del modelo servido, el número de tokens —y por tanto el throughput en tok/s y el coste por token— están sesgados. LLMPerf (archivado en diciembre de 2025) usaba LlamaTokenizer de forma universal para todos los modelos, lo que garantizaba consistencia interna en el leaderboard pero hacía los tok/s incomparables con mediciones de otros modelos con vocabularios distintos.

La fórmula del TPS en LLMPerf incluía además el denominador completo del benchmark —tiempo de generación de prompts, preparación de peticiones y almacenamiento de respuestas—, que NVIDIA estimó en hasta un 33 % de la duración total a concurrencia 1. Esto hace que el TPS de LLMPerf sea sistemáticamente inferior al de GenAI-Perf/AIPerf para el mismo sistema, sin que el motor sea peor:

$$\text{TPS}{\text{LLMPerf}} = \frac{\text{tokens salida}}{T{\text{end}} - T_{\text{start}}}$$

$$\text{TPS}_{\text{GenAI-Perf}} = \frac{\text{tokens salida}}{T_y - T_x}$$

Donde (T_{\text{start}}) y (T_{\text{end}}) incluyen los overheads de cliente, mientras que (T_x) y (T_y) son el instante del primer request y el del último token recibido, respectivamente (NVIDIA · Fundamental Concepts).

La regla operativa: siempre contar tokens con el tokenizer del modelo servido, no con un tokenizer proxy.

El sesgo de ignore_eos y OSL inconsistente

La mayoría de los modelos LLM generan un token especial de fin de secuencia (EOS) cuando consideran completa la respuesta. Si el benchmark no configura ignore_eos=True, la longitud real de salida (OSL) varía de petición en petición según la distribución de longitudes naturales del modelo, lo que produce:

1. OSL inconsistente: dos corridas con la misma semilla pueden producir distribuciones de OSL distintas si el modelo varía su output natural.
2. Comparación espuria: un modelo “más rápido” puede serlo simplemente porque genera respuestas más cortas (termina antes en EOS), no porque tenga más throughput real.
3. Throughput subestimado: si el benchmark espera OSL=256 pero el modelo termina en OSL=80 de media, el throughput en tok/s parece mayor pero mide menos trabajo.

El parámetro ignore_eos (o --ignore-eos en vLLM bench) instruye al motor a ignorar el token EOS y continuar hasta alcanzar max_tokens. Es obligatorio para que el OSL sea el configurado, no el natural del modelo, y para que dos corridas sean comparables (vLLM benchmark CLI docs).

El sesgo de la distribución ISL/OSL

La distribución de longitudes de entrada (ISL) y salida (OSL) determina qué proporción del tiempo de cómputo se destina al prefill (costoso en TTFT) y cuánto al decode (costoso en ITL). Un benchmark con longitud fija —por ejemplo ISL=128, OSL=128— produce resultados que no se parecen a ningún tráfico real.

Los casos de uso reales tienen distribuciones muy distintas:

Un benchmark de ISL corto con un modelo optimizado para prefill dará un TTFT artificialmente bajo y un throughput artificialmente alto. El codo del sweep se desplaza: con ISL=64 el sistema admite más concurrencia sin romper el SLO de TTFT; con ISL=1.024 el prefill satura antes y el codo aparece antes. Usar la distribución equivocada es dimensionar para un tráfico que no existe.

AIPerf introduce distribuciones de secuencia con varianza configurable por componente para reproducir mezclas de tráfico realistas (AIPerf · Sequence Length Distributions):

--sequence-distribution "64|10,32|8:70;256|40,128|20:20;1024|100,512|50:10"

Esto crea el 70 % de peticiones con (\text{ISL} \sim \mathcal{N}(64, 10)) y (\text{OSL} \sim \mathcal{N}(32, 8)), el 20 % con ISL/OSL medios, y el 10 % con ISL/OSL largos —mucho más fiel a un tráfico de chatbot real que una longitud fija—.

El sesgo del warmup y el prefix-cache

Dos fuentes de sesgo relacionadas pero distintas:

Warmup ausente. Las primeras peticiones de un benchmark llegan a un motor “frío”: la GPU está en estado de baja frecuencia, el KV cache está vacío, y el sistema operativo puede estar paginando memoria. El TTFT de las primeras peticiones es estructuralmente más alto que el del régimen estacionario. Si el benchmark no descarta un periodo de warmup, la media de TTFT incluye estos outliers y sobreestima la latencia real de producción. Algunos frameworks (GenAI-Perf/AIPerf) usan una ventana deslizante que excluye las peticiones de ramp-up y ramp-down; otros no.

Prefix-cache caliente entre corridas. La caché de KV de prefijos (prefix cache o prompt cache) almacena los resultados computados de los prefijos de prompt que se repiten. Si el benchmark corre múltiples corridas consecutivas con los mismos prompts, la segunda y siguientes corridas encuentran el KV cache ya poblado y reportan un TTFT artificialmente bajo —el del decode, no el del prefill—. Para un benchmark de baseline, el prefix cache debe estar frío; para uno que simula producción con prompts repetidos, caliente. La distinción debe explicitarse (arXiv 2605.24217; vLLM · Automatic Prefix Caching).

El sesgo de concurrency vs request-rate

Los dos modos de control de carga producen distribuciones de latencia distintas para el mismo sistema:

NVIDIA recomienda el modo concurrency para la mayoría de los benchmarks de capacidad (NVIDIA · LLM Benchmarking Fundamental Concepts). El modo request-rate es más fiel para tráfico online (distribución Poisson de llegadas), pero si el rate supera la capacidad del motor la cola crece indefinidamente y las métricas de latencia incluyen tiempo de espera en cola que puede dominar el TTFT, mezclando comportamiento de cola con comportamiento del motor.

Un sistema medido con concurrency=16 y otro con request-rate=16 req/s no están bajo la misma carga: la concurrencia fija garantiza 16 peticiones simultáneas; el rate configura el ritmo de llegada pero no la concurrencia instantánea. Comparar sus resultados sin ajuste es incorrecto.

El sesgo de la ventana de medición y el estado térmico

Ventana demasiado corta. Un benchmark de 30 segundos puede medir el ramp-up del sistema, no el régimen estacionario. La recomendación de arXiv 2508.10251 es que la ventana de medición cubra al menos 3-5× el tiempo de rampa del sistema bajo carga, y que las métricas se calculen solo sobre la ventana estacionaria —excluyendo warmup y cooldown—.

Estado térmico de la GPU. Las GPUs de datacenter (H100 SXM, A100) operan con throttling térmico por encima de ~75 °C. Si la GPU no ha alcanzado la temperatura de régimen antes del benchmark, las primeras mediciones corresponden a un estado de mayor frecuencia que el sostenible. Experimentos controlados documentan que la potencia debe estabilizarse en un rango de 3 W durante al menos 30 segundos antes de que las medidas sean representativas (arXiv 2604.09048 · Watt Counts). El efecto es especialmente severo en benchmarks de prefill (TTFT), donde las frecuencias altas del estado frío producen TTFT artificialmente bajo.

Para un benchmark reproducible en 4×H100 SXM 80 GB: antes de medir, correr carga sostenida durante al menos 2–3 minutos hasta que nvidia-smi reporte temperatura estable y potencia estable (variación < 3 W en 30 s). Solo entonces iniciar la ventana de medición.

Cómo las herramientas calculan diferente la ITL

La ITL (Inter-Token Latency) aparece en todas las herramientas pero su fórmula varía, y las diferencias no son pequeñas:

GenAI-Perf / AIPerf:

$$\text{ITL} = \frac{\text{e2e latency} - \text{TTFT}}{\text{tokens salida} - 1}$$

El TTFT se excluye del numerador y el denominador descuenta el primer token. ITL es una métrica pura del decode, sin contaminación del prefill.

LLMPerf (archivado dic. 2025):

$$\text{ITL}_{\text{LLMPerf}} = \frac{\text{e2e latency}}{\text{tokens salida}}$$

El TTFT se incluye en el numerador. Para secuencias cortas (OSL < 50 tokens), el TTFT puede representar el 50–80 % de la e2e_latency, con lo que la ITL de LLMPerf mide principalmente el prefill, no el decode. Dos sistemas con el mismo decode pero distinto prefill aparecerán con ITL distintas en LLMPerf aunque sean idénticos en velocidad de decode.

vLLM bench (benchmark_serving.py):

Calcula ITL como media de los intervalos entre tokens consecutivos del stream de salida, incluyendo varianza intra-petición. Puede revelar jitter de decode que los otros promedian.

La consecuencia práctica: nunca cruzar una ITL de GenAI-Perf con una de LLMPerf como si fueran la misma métrica. Son fórmulas distintas sobre la misma señal.

Comparabilidad entre herramientas: por qué sus números no se cruzan

La tabla siguiente resume las diferencias metodológicas que hacen que los números de una herramienta sean estructuralmente incompatibles con los de otra sin ajuste explícito:

Un resultado de LLMPerf y uno de GenAI-Perf para el mismo endpoint pueden diferir en TTFT, ITL y TPS simultáneamente y en todas ellas por razones metodológicas, no por diferencias del motor. La única forma de cruzarlos es ejecutar ambas herramientas sobre el mismo sistema en las mismas condiciones y calcular el factor de conversión empírico —lo que en la práctica equivale a re-medir con una sola herramienta.

El harness honesto: checklist de reproducibilidad

Un benchmark cuyo número puede defenderse en una auditoría tiene que venir acompañado de todos los metadatos que permiten reproducirlo. El mínimo exigible, organizado por categoría:

Hardware

Software y modelo

Carga

SLO y métricas reportadas

Defensa metodológica del dato ante una auditoría

Un número de throughput que se presenta sin la ficha anterior no es un dato: es una anécdota. El patrón de validación para una auditoría técnica:

1. Trazabilidad de la herramienta. La herramienta y su versión deben ser pinables a un commit de Git o a un hash de imagen de contenedor. AIPerf y GuideLLM exportan JSON con metadatos de versión; vLLM bench los omite por defecto y hay que capturarlos manualmente.

2. Reproducibilidad del entorno. El script de despliegue del motor (o el manifiesto de Kubernetes) y el comando exacto de benchmark deben ser suficientes para que un tercero reproduzca el número en el mismo hardware. GuideLLM exporta el archivo de benchmark como registro autoritativo de la sesión: configuración, metadatos, estadísticas por benchmark y entradas de petición con tiempos individuales (GitHub vllm-project/guidellm).

3. Verificación del régimen estacionario. Las métricas deben proceder de la ventana estacionaria del benchmark (excluido warmup). La curva throughput vs concurrencia debe mostrar el codo —el punto donde el throughput satura y la latencia se dispara— y extenderse más allá de él. Sin codo visible, la capacidad reportada puede ser el límite del cliente, no del motor.

4. Goodput, no throughput bruto. El throughput auditable es el goodput bajo el SLO declarado, no el throughput máximo. Un sistema que reporta 4.000 tok/s pero cuyo goodput bajo TTFT P99 < 500 ms es 1.800 tok/s tiene una capacidad real de 1.800 tok/s para los casos de uso interactivos.

5. Comparabilidad interna. Si se comparan dos motores o dos configuraciones, la herramienta, la distribución de carga, el SLO, el hardware y el tratamiento del warmup deben ser idénticos. Cualquier diferencia en estas dimensiones contamina la comparación.

La fórmula del goodput como métrica auditable:

$$\text{goodput} = \text{throughput} \times \Pr[\text{TTFT} \leq \text{SLO}{\text{TTFT}}] \times \Pr[\text{ITL} \leq \text{SLO}{\text{ITL}}]$$

Donde las probabilidades se estiman sobre la distribución empírica de la corrida. Un motor con throughput de 4.000 tok/s y (\Pr[\text{TTFT} \leq 500,\text{ms}] = 0{,}45) tiene un goodput de (4{,}000 \times 0{,}45 = 1{,}800) tok/s.

Ejemplo numérico: el mismo nodo, cuatro medidas distintas

Hardware de referencia: 4×H100 SXM 80 GB, modelo Llama-3-70B-Instruct FP8, tensor parallel 4, SLO TTFT P99 < 500 ms.

El rango: de 1.200 tok/s a 5.800 tok/s para el mismo motor, el mismo hardware y el mismo modelo. El factor máximo es 4,8×. La causa no es el motor; son las decisiones de instrumentación.

La descomposición del sesgo total

El sesgo total observable entre dos herramientas es la composición multiplicativa de los sesgos individuales. Para una comparación de vLLM bench mono-proceso vs GuideLLM multi-proceso sobre el mismo sistema:

$$\text{factor total} \approx \underbrace{f_{\text{cliente}}}{\leq 7{,}2\times} \times \underbrace{f{\text{tokenizer}}}{1{,}0{-}1{,}3\times} \times \underbrace{f{\text{ignore-eos}}}{1{,}0{-}2{,}0\times} \times \underbrace{f{\text{ISL/OSL}}}{1{,}0{-}1{,}5\times} \times \underbrace{f{\text{warmup}}}_{1{,}0{-}1{,}2\times}$$

El factor de saturación del cliente ((\leq 7{,}2\times)) domina, pero los demás factores se multiplican. En condiciones adversas (cliente mono-proceso + tokenizer distinto + sin ignore_eos + OSL irreal + sin warmup), el sesgo compuesto puede superar 15–20× para el mismo sistema.

Estado del arte 2026: qué ha cambiado

• Migración genai-perf → AIPerf (15-abr-2026): NVIDIA retiró genai-perf y lo sustituyó por AIPerf, que es multi-proceso con detección automática de saturación, distribuciones ISL/OSL configurables y ventana deslizante integrada. La migración elimina el sesgo de cliente mono-proceso del tooling oficial de NVIDIA.
• Archivo de LLMPerf (dic. 2025): el repositorio ray-project/llmperf está archivado y en modo solo-lectura. Los resultados históricos del LLMPerf leaderboard son comparables solo entre sí; no se deben cruzar con mediciones modernas sin ajuste.
• GuideLLM 0.5.x (2025–2026): refactor arquitectural completo, soporte multimodal, y exportación JSON autoritativa con todos los metadatos de sesión. Es el estándar OSS de evaluación dirigida por SLO.
• arXiv 2605.24217 (may. 2026): primera caracterización formal del sesgo sistemático de medición en benchmarks de producción LLM, con demostración matemática del efecto GIL y propuesta de harness multi-proceso.
• arXiv 2508.10251: meta-métricas y buenas prácticas para benchmarking de rendimiento a nivel de sistema; establece las dimensiones mínimas del espacio de parámetros que deben declararse para que un resultado sea reproducible.
• MLPerf Inference v5.1 (sep. 2025): 27 participantes, récord de participación. Las reglas de MLPerf exigen declarar el código exacto, el dataset y el hardware, y admiten revisión pública —es el único benchmark de la industria con proceso de revisión formal de reproducibilidad.

Cross-links del track de benchmarking

Los sesgos descritos aquí aplican a todas las herramientas del catálogo. Para la ficha completa de cada herramienta:

• Catálogo completo: Herramientas de benchmarking LLM, ficha a ficha
• GuideLLM y la validación de SLO: GuideLLM a fondo: validar el SLO bajo carga
• AIPerf (ex genai-perf) y la detección de saturación: NVIDIA GenAI-Perf a fondo
• Estado del arte de frameworks: Benchmarking LLM: frameworks y estado del arte
• Decisión de motor en el eje Pareto: Comparativa de motores de serving: frontera Pareto

Fuentes

• arXiv 2605.24217 · Identifying and Mitigating Systemic Measurement Bias in Production LLM Inference Benchmarks — https://arxiv.org/abs/2605.24217
• arXiv 2508.10251 · Meta-Metrics and Best Practices for System-Level Inference Performance Benchmarking — https://arxiv.org/pdf/2508.10251
• arXiv 2604.09048 · Watt Counts: Energy-Aware Benchmark for Sustainable LLM Inference on Heterogeneous GPU Architectures — https://arxiv.org/html/2604.09048v1
• NVIDIA Technical Blog · LLM Inference Benchmarking: Fundamental Concepts (ITL, TPS, ISL/OSL, ignore_eos, concurrency vs request-rate) — https://developer.nvidia.com/blog/llm-benchmarking-fundamental-concepts/
• NVIDIA AIPerf Docs · Sequence Length Distributions for Advanced Benchmarking — https://docs.nvidia.com/aiperf/tutorials/datasets-inputs/sequence-length-distributions-for-advanced-benchmarking
• NVIDIA AIPerf · Request Rate with Max Concurrency — https://docs.nvidia.com/aiperf/tutorials/load-patterns-scheduling/request-rate-with-max-concurrency
• NVIDIA AIPerf · Comprehensive LLM Benchmarking Guide — https://lucaberton.com/blog/nvidia-aiperf-llm-inference-benchmarking-guide/
• vLLM Documentation · Benchmark CLI (ignore_eos, métricas disponibles) — https://docs.vllm.ai/en/latest/benchmarking/cli/
• vLLM Documentation · Automatic Prefix Caching — https://docs.vllm.ai/en/stable/design/prefix_caching/
• GitHub · ray-project/llmperf (archivado dic. 2025) — https://github.com/ray-project/llmperf
• GitHub · vllm-project/guidellm (exportación JSON autoritativa, metadatos de sesión) — https://github.com/vllm-project/guidellm
• Red Hat Developer · GuideLLM: evaluar despliegues LLM para inferencia real — https://developers.redhat.com/articles/2025/06/20/guidellm-evaluate-llm-deployments-real-world-inference
• MLCommons · MLPerf Inference v5.1 results (récord 27 participantes, reproducibilidad formal) — https://mlcommons.org/2025/09/mlperf-inference-v5-1-results/
• arXiv 2502.16721 · Speed and Conversational LLMs: Not All Is About Tokens per Second (tokenizer incompatibilidad y tok/s entre vocabularios) — https://arxiv.org/pdf/2502.16721
• Medium · LLM Inference Benchmarking (genAI-perf y vLLM, discrepancia 7,2×) — https://kchandan.medium.com/llm-inference-benchmarking-genai-perf-and-vllm-5dd06b57428e