---
title: "Benchmarking de inferencia LLM: frameworks, métricas y estado del arte (ficha a ficha)"
url: https://blog.lo0.es/posts/benchmarking-llm-frameworks-estado-del-arte/
markdown: https://blog.lo0.es/posts/benchmarking-llm-frameworks-estado-del-arte/index.md
lang: es
date: 2026-06-13
lastmod: 2026-08-30
author: "José Manuel Román"
description: "Introducción de datos al tooling de benchmarking de inferencia LLM: las métricas (TTFT, TPOT/ITL, throughput, goodput) y cómo se descomponen, la diferencia entre micro-bench mono-proceso y carga multi-proceso (y el sesgo que introduce), el sweep de concurrencia para hallar el codo, la ficha de vLLM/SGLang bench, AIPerf (ex genai-perf), GuideLLM, LLMPerf y MLPerf Inference, y la metodología reproducible. Estado del arte 2026, con fuentes."
tags: ["benchmarking","vllm","guidellm","aiperf","llmperf","mlperf","ttft","throughput","goodput","serie-datos"]
translations:
  en: https://blog.lo0.es/en/posts/llm-inference-benchmarking-frameworks-metrics-state-of-the-art/index.md
---

# 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](https://blog.lo0.es/posts/tres-ejes-coste-rendimiento-energia-inferencia-llm/index.md).

## 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:

| Métrica | Definición | Unidad | Fase que domina |
|---|---|---|---|
| **TTFT** (Time To First Token) | tiempo desde que se envía el prompt hasta el primer token | ms | prefill |
| **TPOT / ITL** (Time Per Output Token / Inter-Token Latency) | tiempo medio entre tokens de salida una vez empezada la generación | ms/token | decode |
| **Request throughput** | ciclos completos petición-respuesta por segundo a la concurrencia probada | req/s | ambas |
| **Token throughput** | tokens totales (entrada + salida) por segundo entre todas las peticiones concurrentes | tok/s | ambas |
| **Goodput** | porcentaje de peticiones que **cumplen el SLO** definido | tok/s útiles | ambas |
| **P50 / P95 / P99** | percentiles de latencia (no la media) | ms | — |

Definiciones precisas, porque cada herramienta las calcula a su manera ([Anyscale ·
métricas de latencia y throughput](https://docs.anyscale.com/llm/serving/benchmarking/metrics)):
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](https://docs.anyscale.com/llm/serving/benchmarking/metrics)). 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](https://kchandan.medium.com/llm-inference-benchmarking-genai-perf-and-vllm-5dd06b57428e)):
  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.

> **Diagrama:** Dos clases de herramientas de benchmark: cliente mono-proceso que se satura a alta concurrencia frente a generador de carga multi-proceso que mide el motor — [verlo en la versión HTML](https://blog.lo0.es/posts/benchmarking-llm-frameworks-estado-del-arte/)

---

## 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](https://blog.lo0.es/posts/decode-optimizaciones-vllm/index.md) y
[prefill](https://blog.lo0.es/posts/prefill-optimizaciones-vllm/index.md)). 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](https://lucaberton.com/blog/nvidia-aiperf-llm-inference-benchmarking-guide/)).

### 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](https://developers.redhat.com/articles/2025/06/20/guidellm-evaluate-llm-deployments-real-world-inference),
[GuideLLM · GitHub](https://github.com/vllm-project/guidellm)). 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

| Herramienta | Clase | Qué mide | Mantenedor | Cuándo usarla |
|---|---|---|---|---|
| **vLLM bench** | micro mono-proceso | TTFT, TPOT, throughput de vLLM | vLLM (OSS) | tunear vLLM, experimentos rápidos |
| **SGLang bench** | micro mono-proceso | métricas del motor SGLang | SGLang (OSS) | tunear SGLang |
| **AIPerf** (ex genai-perf) | carga multi-proceso | TTFT, ITL, throughput; estimatedCapacity | NVIDIA (OSS) | capacidad real, multi-endpoint |
| **GuideLLM** | carga multi-proceso | distribuciones, SLO, sweeps | vLLM (OSS) | validar SLO, hallar el codo |
| **LLMPerf** | carga | throughput y latencia | Anyscale/Ray (OSS) | validación de endpoints |
| **MLPerf Inference** | suite estándar | escenarios server/offline/interactive | MLCommons | comparabilidad cross-vendor |

---

## 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.

> **Diagrama:** Curva del sweep de concurrencia: el throughput sube y satura mientras la latencia se dispara más allá del codo, que marca la capacidad segura bajo SLO — [verlo en la versión HTML](https://blog.lo0.es/posts/benchmarking-llm-frameworks-estado-del-arte/)

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](https://blog.lo0.es/posts/capacity-planning-inferencia-llm-on-premise/index.md):
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:

| Concurrencia | RPS | TTFT P50 (ms) | TTFT P99 (ms) | Token tput (tok/s) | Goodput |
|---|---|---|---|---|---|
| 1 | 2 | 80 | 110 | 350 | 100 % |
| 8 | 14 | 110 | 240 | 2.100 | 100 % |
| 16 | 22 | 180 | 460 | 3.400 | 98 % |
| 24 | 26 | 320 | 980 | 3.900 | 62 % |
| 32 | 27 | 540 | 1.800 | 4.000 | 20 % |

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](https://blog.lo0.es/posts/capacity-planning-inferencia-llm-on-premise/index.md)
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](https://mlcommons.org/benchmarks/inference-datacenter/)):

| Escenario | Qué simula | Métrica |
|---|---|---|
| **Offline** | throughput bruto procesando todo el dataset en batch | máximo throughput |
| **Server** | entorno interactivo: peticiones de una en una según Poisson a un RPS medio | RPS bajo límites de TTFT y TPOT |
| **Interactive** (opcional) | como server pero con **límites de latencia más estrictos** | RPS bajo SLO duro |

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](https://mlcommons.org/2025/04/llm-inference-v5/)); **v5.1** (septiembre
2025) amplió los resultados con participación récord
([MLCommons · v5.1](https://mlcommons.org/2025/09/mlperf-inference-v5-1-results/)).

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](https://arxiv.org/html/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](https://arxiv.org/pdf/2508.10251)). Las fuentes de sesgo más
comunes:

| Fuente de sesgo | Efecto | Mitigación |
|---|---|---|
| Cliente mono-proceso | infravalora el throughput a alta concurrencia | usar carga multi-proceso |
| Distribución de longitudes irreal | resultados que no aplican a tu tráfico | usar trazas realistas |
| Medir media en vez de percentiles | oculta la cola de latencia | reportar P95/P99 |
| Warm-up no controlado | el prefix cache infla los primeros resultados | descartar el warm-up |
| No fijar versión de motor/modelo | irreproducible | pinear todo y publicarlo |

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:

| Qué fijar | Por qué |
|---|---|
| Herramienta + versión | cada una mide distinto; la versión cambia el comportamiento |
| Modelo + precisión (FP16/FP8/INT4) | la precisión cambia throughput y calidad |
| Hardware (GPU, nº, interconexión) | un 8×H100 NVLink no es 8×H100 PCIe |
| Motor + versión + flags | vLLM/SGLang/TRT-LLM y su configuración |
| Distribución de longitudes (in/out) | el tráfico real no es de longitud fija |
| Niveles de concurrencia del sweep | hay que pasar el codo |
| SLO (qué percentil, qué umbral) | define el goodput |
| Tratamiento del warm-up | descartarlo o sesga el resultado |
| Tokenizer usado para contar | afecta a tok/s y coste/token |

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):

| Herramienta | Qué mide | Trampa habitual |
|---|---|---|
| **lm-evaluation-harness** | acierto en cientos de tareas estandarizadas | contaminación del dataset de test |
| **HELM** | evaluación holística (acierto, robustez, sesgo, eficiencia) | pesado de ejecutar |
| **LiveBench / leaderboards dinámicos** | tareas que rotan para evitar contaminación | comparabilidad temporal |

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:

| Régimen | Optimiza | Configuración | Caso |
|---|---|---|---|
| **Latencia** | TTFT/TPOT bajos | batch pequeño, baja concurrencia | chat interactivo, copilotos |
| **Throughput** | tok/s máximos | batch grande, alta concurrencia | batch nocturno, ingestión |

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](https://blog.lo0.es/posts/tres-ejes-coste-rendimiento-energia-inferencia-llm/index.md),
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)](https://blog.lo0.es/posts/comparativa-motores-serving-pareto/index.md) — la elección del motor tras medir el goodput: de la metodología de esta ficha a la frontera de Pareto.
- [MLPerf Inference: cómo leerlo y qué comparabilidad ofrece](https://blog.lo0.es/posts/mlperf-inference-como-leerlo/index.md) — el estándar de la industria: los cuatro escenarios, los SLO de TTFT/TPOT del escenario Server y las reglas de comparación entre resultados.
- [Sesgo de medición y reproducibilidad](https://blog.lo0.es/posts/sesgo-medicion-reproducibilidad-bench/index.md) — 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