Benchmarking de inferencia LLM: frameworks, métricas y estado del arte (ficha a ficha)

Notación: importes en euros (N €), decimales con coma. El rendimiento es poco sensible al país, pero su coste asociado (coste/token) se expresa en € y enlaza con el artículo de apertura.

Qué cubre esta introducción

Tercer artículo de la serie de datos, deep dive del eje de rendimiento. Medir el rendimiento de un motor de inferencia parece trivial —"¿cuántos tokens por segundo?"— y es justo donde más se engaña la gente: dos herramientas pueden reportar resultados que difieren en un factor de 7 para el mismo sistema. Este artículo inventaría las métricas que importan y cómo se definen, por qué la arquitectura de la herramienta sesga el dato, cómo se halla el punto de saturación con un sweep de concurrencia, y la ficha de cada framework. Sin recomendaciones: la elección de motor se decide en el artículo de Pareto (B8); aquí solo están los hechos y la metodología, porque un benchmark sin metodología publicada no es comparable.

Las métricas de rendimiento

No hay una métrica de rendimiento, hay cinco, y mezclarlas es la primera fuente de error:

Definiciones precisas, porque cada herramienta las calcula a su manera (Anyscale · métricas de latencia y throughput): el TTFT es lo que un usuario espera antes de ver el primer carácter, dominado por el cómputo de prefill; la ITL es el tiempo medio entre tokens sucesivos de salida y fija la “velocidad de tecleo” percibida de la respuesta; el request throughput son ciclos completos por segundo; el token throughput son tokens totales (entrada más salida) por segundo entre todas las peticiones concurrentes.

La descomposición de la latencia

La latencia total de una petición de (N) tokens de salida se descompone:

$$\text{latencia} \approx \text{TTFT} + (N-1)\times \text{TPOT}$$

Por eso TTFT y TPOT se reportan por separado: una misma media de latencia esconde perfiles muy distintos. Un sistema con TTFT alto y TPOT bajo (prefill caro, decode rápido) y otro al revés pueden tener la misma latencia media para una longitud concreta, pero se comportan de forma opuesta al cambiar el tamaño de la respuesta. Para una experiencia de chat interactivo manda el TTFT y el TPOT; para un batch de resúmenes largos, el token throughput. Medir la media oculta ambas realidades.

Goodput: la métrica honesta

El throughput bruto (TPS, RPS) dice cuánto trabajo hace el sistema; el goodput dice cuánto de ese trabajo cumple tus estándares de calidad de servicio (SLO) (Anyscale). Un motor puede presumir de 10.000 tok/s agregados, pero si la mitad de las peticiones violan el SLO de P99 de TTFT, su goodput es 5.000. La cifra que se defiende en una propuesta es el goodput, no el throughput de catálogo: es lo único que se traduce en usuarios satisfechos y en un coste por token honesto.

Cómo se instrumenta cada métrica (y dónde se cuela el error)

Antes de comparar números conviene saber dónde empieza y acaba cada reloj, porque dos herramientas pueden llamar “TTFT” a cosas distintas:

• TTFT lado cliente vs lado servidor. El TTFT medido por el cliente incluye la latencia de red y de la cola del gateway; el medido por el servidor, no. Para una comparación de motores interesa el del servidor; para la experiencia de usuario, el del cliente. Mezclar ambos invalida la comparación.
• Requiere streaming. El TTFT y la ITL solo se pueden medir si la respuesta llega en streaming (token a token). Si la herramienta mide sobre respuestas completas, no hay TTFT real: hay latencia total disfrazada.
• Conteo de tokens. El throughput en tok/s depende de qué tokenizer cuenta los tokens. Si la herramienta usa un tokenizer distinto al del modelo, el número de tokens —y por tanto el tok/s y el coste/token— está sesgado. Hay que contar con el tokenizer del modelo servido.
• Warm-up y prefix cache. Las primeras peticiones de un benchmark se benefician del prefix cache caliente y dan TTFT artificialmente bajo; hay que descartar el warm-up o el resultado infla la realidad.

Estas cuatro decisiones de instrumentación explican buena parte de las discrepancias entre herramientas. Un número de rendimiento sin especificar dónde se mide el reloj y con qué tokenizer no es comparable, por muy preciso que parezca.

La arquitectura de la herramienta sesga el dato

Aquí está la trampa que invalida la mitad de los benchmarks publicados. Las herramientas se dividen en dos clases por la arquitectura del cliente que genera la carga, y esa arquitectura determina si la medida es fiable a alta concurrencia:

• Micro-bench mono-proceso (vLLM bench, SGLang bench, genai-perf): un cliente Python con asyncio en un solo proceso. Útiles para experimentos rápidos sobre un motor concreto, pero la arquitectura mono-proceso introduce un cuello de botella en el lado cliente que sesga los datos a alta concurrencia (genAI-perf y vLLM): el cliente no consigue generar carga suficiente y mides el límite del cliente, no el del motor.
• Carga multi-proceso (GuideLLM, AIPerf): reparten la generación de carga entre varios procesos, evitando ese límite. Son la clase que ha emergido para medir a escala real.

La magnitud del sesgo es enorme: a 1.000 QPS, un benchmark mono-proceso llegó a procesar 75.574 tokens frente a los 545.733 tokens de una arquitectura distribuida — una discrepancia de 7,2× en la capacidad de medición para el mismo sistema ([búsqueda]). Quien compare dos motores con herramientas de clases distintas no está comparando los motores: está comparando los clientes de benchmark.

Frameworks, ficha a ficha

vLLM bench y SGLang bench — micro-bench del motor

Qué miden: TTFT, TPOT y throughput del propio motor (vLLM o SGLang). Clase: micro-bench mono-proceso. Uso: experimentos rápidos para tunear un motor concreto y ver el efecto de sus optimizaciones (ver decode y prefill). Límite: se saturan en el cliente a alta concurrencia; no sirven para medir la capacidad real a escala.

AIPerf — el de NVIDIA (ex genai-perf), multi-proceso

Qué mide: TTFT, ITL, throughput y latencia sobre vLLM, NIM, TGI y cualquier endpoint compatible. Clase: carga multi-proceso. Dato de estado del arte: NVIDIA jubiló genai-perf y lo sustituyó por AIPerf el 15 de abril de 2026. AIPerf, durante el sweep, detecta la saturación de la GPU e identifica la iteración anterior, devolviéndola como estimatedCapacity; si no detecta saturación, estimatedCapacity es la última iteración probada —por eso el sweep tiene que extenderse más allá del codo (AIPerf).

GuideLLM — del proyecto vLLM, orientado a SLO

Qué mide: distribuciones completas de TTFT, ITL y comportamiento de extremo a extremo, para evaluación dirigida por SLO. Clase: carga multi-proceso. Diferenciador: genera patrones de tráfico realistas y configurables en modos síncrono, concurrente y por tasa, incluyendo sweeps reproducibles para identificar rangos de operación seguros (Red Hat · GuideLLM, GuideLLM · GitHub). Es la herramienta para responder “¿hasta dónde puedo cargar este motor sin romper el SLO?”.

LLMPerf — el clásico de Anyscale/Ray

Qué mide: throughput y latencia a nivel de inferencia. Uso: validación de endpoints, muy extendido históricamente. Clase: carga. Límite: menos centrado en distribuciones y sweeps que GuideLLM/AIPerf.

MLPerf Inference — el estándar de la industria

Qué mide: rendimiento bajo escenarios normalizados con reglas estrictas, para comparabilidad entre fabricantes. Mantenedor: MLCommons. Es el patrón oro de comparabilidad cross-vendor; se desarrolla abajo en detalle.

Tabla comparativa

El sweep de concurrencia: hallar el codo

La medida más útil para dimensionar no es un número, es una curva: cómo cambian la latencia y el throughput a medida que sube la concurrencia. Subir la concurrencia mantiene la GPU más ocupada y sube el RPS, pero a partir de cierto punto dispara el TTFT, la ITL y la latencia de extremo a extremo ([búsqueda]). El objetivo del sweep es encontrar el codo (knee): la concurrencia máxima donde el throughput sigue subiendo sin que la latencia rompa el SLO.

Por eso AIPerf extiende el sweep más allá del codo: solo viendo dónde se dispara la latencia se puede devolver la capacidad segura (estimatedCapacity). Esta curva es la materia prima del capacity planning: del codo sale el número de réplicas y el coste por token a la carga objetivo.

Ejemplo trabajado: lectura de un sweep

Un sweep ilustrativo sobre un nodo de ejemplo (un 70B en 8×H100, SLO de P99 de TTFT < 500 ms), para ver cómo se lee el codo:

Lectura: hasta concurrencia ~16 el throughput crece y el P99 se mantiene bajo el SLO (goodput ~100 %). Entre 16 y 24 está el codo: el throughput ya casi no sube (3.400 → 3.900 tok/s) pero el P99 se dispara (460 → 980 ms) y el goodput se desploma (98 % → 62 %). A concurrencia 32 el throughput bruto es máximo (4.000 tok/s) pero el goodput es 20 %: el sistema “rinde mucho” sirviendo sobre todo peticiones que violan el SLO. La capacidad segura defendible es la de concurrencia ~16, no la del throughput máximo. Este es el número que entra en el capacity planning y en el coste por token: a 3.400 tok/s útiles, no a 4.000 tok/s brutos.

MLPerf Inference: el estándar de comparabilidad

Para comparar entre fabricantes y motores con reglas idénticas existe MLPerf Inference (MLCommons). La categoría de datacenter se centra en dos escenarios, más uno opcional (MLCommons · datacenter):

El escenario Server es el realista para inferencia online: el generador de carga manda peticiones siguiendo una distribución de Poisson y exige cumplir cotas concretas de TTFT y TPOT. MLPerf Inference v5.0 (abril 2025) introdujo un benchmark de 405B a gran escala y uno interactivo de 70B de baja latencia, ofreciendo benchmarks de lenguaje a todas las escalas (7B a 405B), diversidad de arquitecturas (incluido MoE) y escenarios (MLCommons · v5.0); v5.1 (septiembre 2025) amplió los resultados con participación récord (MLCommons · v5.1).

El valor de MLPerf es la comparabilidad: todos miden lo mismo bajo las mismas reglas. Su límite es que esas reglas pueden no coincidir con tu carga (tu distribución de longitudes, tu SLO concreto), así que sirve para comparar hardware/motores entre sí, no necesariamente para dimensionar tu caso —para eso, el sweep propio.

El sesgo de medición y la reproducibilidad

Que dos benchmarks den resultados muy distintos para el mismo sistema no es un accidente: el sesgo sistemático de medición en benchmarks de producción está caracterizado en la literatura (arXiv 2605.24217), y hay trabajo dedicado a las meta-métricas y buenas prácticas del benchmarking de rendimiento a nivel de sistema (arXiv 2508.10251). Las fuentes de sesgo más comunes:

La conclusión metodológica de este artículo: un benchmark sin metodología publicada no es comparable. Para que un número de rendimiento sostenga una propuesta tiene que venir con la herramienta, su versión, el modelo y precisión, la distribución de carga y el SLO. El artículo de síntesis S4 monta un harness reproducible que fija todo eso.

Checklist de un benchmark reproducible

Para que un número de rendimiento sea defendible ante un comité, tiene que venir con todo lo que permite reproducirlo. El mínimo que se publica junto al resultado:

La regla práctica: si no puedes entregar esta tabla junto a la cifra, la cifra no es un dato, es una anécdota. El harness reproducible del artículo S4 automatiza el registro de todos estos parámetros para que cualquiera —incluido quien rebata la propuesta— pueda reproducir el número exacto.

Rendimiento ≠ calidad

Una advertencia que evita el error más caro: estas herramientas miden velocidad y throughput, no acierto. Un motor puede ser rapidísimo sirviendo un modelo que responde mal. La calidad se mide con otra familia de herramientas —lm-evaluation-harness, HELM, leaderboards de tareas— que es otro eje del cuadro de mando (artículo B7). Confundir “rápido” con “bueno” es montar una plataforma que sirve respuestas malas muy deprisa. En la frontera de Pareto final, rendimiento y calidad son dos ejes distintos que hay que ver juntos, nunca uno en lugar del otro.

La otra familia de herramientas, para referencia (se desarrolla en B7):

El punto de datos: la contaminación —que el modelo haya visto el test en su entrenamiento— infla las métricas de calidad igual que el warm-up infla las de rendimiento. Por eso los leaderboards dinámicos rotan las preguntas. Calidad y rendimiento comparten esa lección: el método de medida sesga el resultado tanto como el sistema medido.

El trade-off latencia vs throughput

Una propiedad que el sweep deja ver y que conviene tener presente: latencia y throughput tiran en direcciones opuestas. El batching agrupa peticiones para amortizar el coste de mover los pesos desde la VRAM —sube el throughput— pero cada petición espera a que se forme el lote, lo que sube la latencia individual. Hay dos regímenes de operación, y el benchmark sirve para situarse en el correcto:

No existe un único “mejor” punto: existe el mejor punto para tu SLO. Un benchmark que reporta solo el throughput máximo está describiendo el régimen de throughput e ignorando si ese punto cumple la latencia que tu caso necesita. Por eso el goodput —throughput bajo el SLO— es la métrica que reconcilia los dos regímenes: mide cuánto throughput consigues sin salirte de la latencia aceptable. El sweep recorre la curva entre ambos regímenes; tu SLO marca dónde, en esa curva, está tu sistema.

La conexión con coste y energía

El rendimiento no es un eje aislado: por la identidad del artículo de apertura, el throughput es el denominador del coste por token y de la energía por token. Un sweep que encuentra un codo a 4.000 tok/s en vez de 2.800 no es solo “más rápido”: baja el CPM de ~1,09 a ~0,76 €/1M tok y la energía por token en la misma proporción, sobre el mismo hierro. Por eso el benchmarking de rendimiento es la herramienta que, indirectamente, más mueve el coste: cada mejora de goodput se traduce en euros y en vatios por token. El número que conecta los tres ejes es el goodput —el throughput que cumple el SLO—, no el throughput de catálogo.

Estado del arte 2026

• Migración genai-perf → AIPerf (15-abr-2026): NVIDIA consolida su benchmarking en una herramienta multi-proceso con detección de saturación.
• GuideLLM como estándar OSS de evaluación dirigida por SLO con sweeps reproducibles.
• MLPerf Inference v5.0/v5.1 amplía a 405B, interactivo de 70B y MoE, con participación récord: la comparabilidad cross-vendor madura.
• Sesgo de medición caracterizado: la comunidad reconoce que el método de medida importa tanto como el sistema medido; crece el énfasis en reproducibilidad y meta-métricas.

Límites y trampas (data-driven)

1. Comparar herramientas de clases distintas. Un micro-bench mono-proceso y una carga multi-proceso no son comparables; la diferencia puede ser 7×. Fija la clase.
2. Throughput de catálogo en vez de goodput. El número honesto es el que cumple el SLO.
3. Medias en vez de percentiles. La media oculta la cola; reporta P95/P99.
4. No extender el sweep más allá del codo. Sin ver dónde se dispara la latencia no conoces la capacidad segura.
5. Confundir rendimiento con calidad. Son ejes distintos; rápido no es bueno.
6. No pinear versiones. Motor, modelo, precisión y carga sin fijar = irreproducible = no defendible.

El siguiente artículo del track (B2) entra en el catálogo de herramientas a fondo; este fija las métricas y la metodología. Con el rendimiento medido de forma reproducible, el cuadro de mando puede cruzarlo con el coste (en €) y la energía para la decisión final.

Cierre

El benchmarking de rendimiento parece el eje más “objetivo” de los tres —al fin y al cabo, son tokens por segundo— y es justo donde más se manipula, casi siempre sin mala intención: una herramienta mono-proceso aquí, una media en vez de un P99 allá, un throughput de catálogo en vez del goodput. La diferencia entre un número de marketing y un dato defendible no está en el motor medido, sino en la metodología: la clase de herramienta, dónde se mide el reloj, con qué tokenizer, hasta dónde llega el sweep y qué SLO define el goodput. Para una propuesta de arquitectura soberana, el rendimiento solo vale si se entrega con esa ficha de reproducibilidad —y, cruzado con el coste en euros y la energía por token, se convierte en la columna de la frontera de Pareto que decide qué motor y qué configuración sostienen la plataforma. El número que se defiende no es el más alto: es el goodput reproducible.

Ver también

• Comparativa de motores de serving (vLLM/SGLang/TRT-LLM/Dynamo) — la elección del motor tras medir el goodput: de la metodología de esta ficha a la frontera de Pareto.
• Sesgo de medición y reproducibilidad — fuentes de sesgo sistemático en benchmarks de rendimiento y cómo controlarlas para obtener datos defendibles.

Fuentes

• Anyscale · métricas de latencia y throughput de LLM — https://docs.anyscale.com/llm/serving/benchmarking/metrics
• Red Hat · GuideLLM: evaluar despliegues LLM para inferencia real — https://developers.redhat.com/articles/2025/06/20/guidellm-evaluate-llm-deployments-real-world-inference
• GuideLLM · GitHub (proyecto vLLM) — https://github.com/vllm-project/guidellm
• NVIDIA AIPerf · guía de benchmarking (ex genai-perf) — https://lucaberton.com/blog/nvidia-aiperf-llm-inference-benchmarking-guide/
• MLCommons · MLPerf Inference datacenter (escenarios) — https://mlcommons.org/benchmarks/inference-datacenter/
• MLCommons · MLPerf Inference v5.0 (405B + 70B interactivo) — https://mlcommons.org/2025/04/llm-inference-v5/
• MLCommons · MLPerf Inference v5.1 — https://mlcommons.org/2025/09/mlperf-inference-v5-1-results/
• arXiv 2605.24217 · sesgo sistemático de medición en benchmarks de inferencia LLM — https://arxiv.org/html/2605.24217
• arXiv 2508.10251 · meta-métricas y buenas prácticas de benchmarking de rendimiento — https://arxiv.org/pdf/2508.10251
• Medium · LLM Inference Benchmarking (genAI-perf y vLLM) — https://kchandan.medium.com/llm-inference-benchmarking-genai-perf-and-vllm-5dd06b57428e