Mlperf on lo0 — Blog Técnico

Almacenamiento en la era de la IA (2/4): rendimiento

Mon, 22 Jun 2026 11:00:00 +0200

En el primer artículo dibujamos el mapa: la jerarquía memoria-almacenamiento, las tecnologías de medio y la pila de software que domina los clústeres GPU. Este segundo artículo entra en la propiedad que justifica toda esa complejidad: el rendimiento. La pregunta que debe responder un arquitecto no es “¿cuántos GB/s da mi cabina?”, sino “¿consigo que mis GPU trabajen al 95 % en lugar de al 40 %?”. Esa diferencia es, literalmente, la mitad de la factura de cómputo.

La métrica que de verdad importa: utilización del acelerador

Es tentador medir el almacenamiento de IA con las métricas clásicas —throughput secuencial, IOPS aleatorias, latencia—, y las necesitamos. Pero ninguna de ellas captura lo que paga el negocio. La métrica integradora es la utilización del acelerador: qué fracción del tiempo la GPU está calculando en lugar de esperando datos.

La mayoría de los pipelines de ML reales corren entre el 30 % y el 60 % de utilización de GPU. Las encuestas del sector son demoledoras: solo en torno al 7 % de los equipos de IA/ML logra superar el 85 % en picos, y una mala previsión o un autoescalado deficiente pueden dejar GPUs ociosas el 70-85 % del tiempo. Un job que corre al 30 % de utilización está pagando el 70 % de su capacidad de cómputo para nada.

Podemos formalizarlo. Si $ t_{\text{cmp}} $ es el tiempo de cómputo por batch y $ t_{\text{io}} $ el tiempo que la GPU pasa bloqueada esperando I/O que no logra solaparse con el cómputo, la utilización efectiva es:

$$U = \frac{t_{\text{cmp}}}{t_{\text{cmp}} + t_{\text{io}}}$$

El objetivo de toda la ingeniería de almacenamiento para IA es llevar $ t_{\text{io}} $ hacia cero, ya sea aumentando el ancho de banda, reduciendo la latencia o solapando la I/O con el cómputo mediante prefetching y pipelining. Y hay un agravante: cuanto más rápida es la GPU, más difícil es alimentarla. El paso de V100 a H100 redujo el tiempo de cómputo por batch del modelo 3D U-Net en un 76 %, convirtiendo una carga que era sensible al ancho de banda en una sensible a la latencia. Cada generación de acelerador sube el listón para el almacenamiento.

Este cambio de régimen —de limitado por ancho de banda a limitado por latencia— tiene una consecuencia de diseño que conviene interiorizar. Cuando una carga está limitada por ancho de banda, la solución es añadir capacidad de transferencia: más NVMe, más lanes, más nodos. Cuando pasa a estar limitada por latencia, esa receta deja de funcionar; lo que importa entonces es el tiempo de respuesta por operación, que se ataca con caché, con prefetching inteligente y con rutas de datos que eliminan saltos (como GPUDirect). Diagnosticar correctamente en cuál de los dos regímenes está cada carga es la primera tarea de cualquier optimización: invertir en ancho de banda una carga limitada por latencia es gastar dinero sin mover la utilización.

MLPerf Storage: el banco de pruebas que sí mide lo correcto

Durante años faltó una forma neutral de comparar plataformas de almacenamiento para IA. MLPerf Storage, de MLCommons, la ha proporcionado. Su acierto de diseño es no medir GB/s en abstracto, sino simular el “think time” de los aceleradores para generar un patrón de I/O realista, y exigir que esos aceleradores simulados mantengan un nivel mínimo de utilización. Es decir, mide exactamente lo que importa: cuántos aceleradores puede mantener alimentados una plataforma sin que su utilización caiga por debajo del umbral.

La v1.0 (septiembre de 2024) usaba los modelos 3D U-Net, ResNet-50 y CosmoFlow, simulando A100 y H100, con umbrales de utilización del 90 % para los dos primeros y del 70 % para CosmoFlow. La v2.0 (agosto de 2025) marcó un salto: más de 200 resultados de 26 organizaciones —Alluxio, DDN, Hammerspace, HPE, IBM, KIOXIA, Micron, Oracle, Samsung, WDC, entre otras—, sistemas capaces de sostener aproximadamente el doble de aceleradores que en v1.0, y, sobre todo, una nueva carga de checkpointing (a la que volveremos).

Algunos resultados de v2.0 sirven para calibrar el estado del arte:

Sistema	Throughput	Aceleradores	Utilización GPU
Volumez	1,079 TB/s	—	92,21 %
Hammerspace (5 nodos)	420,8 GB/s	140	>94,7 %
Hammerspace (3 nodos)	253,1 GB/s	84	>94,7 %
Hammerspace (1 nodo)	85,6 GB/s	28	>94,7 %
Alluxio	24,14 GiB/s	128	99,57 %

El dato de Hammerspace ilustra una propiedad que un arquitecto debe exigir: escalado lineal. De 1 a 5 nodos el throughput crece de 85,6 a 420,8 GB/s manteniendo la utilización por encima del 94,7 % con un coeficiente de variación ínfimo (0,08-0,14 %). El escalado lineal es lo que separa una plataforma de IA de un NAS rápido.

Las cifras de las plataformas comerciales

Fuera del banco de pruebas, las plataformas certificadas para DGX SuperPOD publican cifras agregadas que conviene tener como referencia de orden de magnitud:

WEKA WEKApod Nitro: 720 GB/s de lectura y 186 GB/s de escritura por configuración, 18 millones de IOPS, con NIC ConnectX-8 a 800 Gb/s. Por nodo, 70 GB/s de lectura y 40 GB/s de escritura; la configuración mínima de 8 nodos entrega 560 GB/s de lectura. Un único equipo de entrada cubre la demanda de I/O de una “scalable unit” GB200 de 1.152 GPUs.
DDN AI400X2: más de 90 GB/s y 3 millones de IOPS por appliance; la variante Turbo satura cerca de 100 GB/s (800 Gbps) por DGX B200. La nueva plataforma de DDN declara más de 1 TB/s de lectura por appliance con escalado por rack, y ha alimentado al supercomputador Eos de NVIDIA con 4 TB/s.
VAST Data: múltiples TB/s desde un único mount point vía multipathing NFS, RDMA sobre NFS y GPUDirect, gestionando exabytes en un único espacio de nombres multiprotocolo.
Pure Storage: certificado para DGX SuperPOD con GB200 y GB300.

Estas cifras solo significan algo en relación con el cluster que alimentan. Un GB200 NVL72 mueve 130 TB/s de comunicación interna entre GPU; el almacenamiento no compite con eso, pero sí debe sostener el data loading y el checkpointing sin estrangular a 72 GPU que se comportan como una sola.

El patrón de I/O del entrenamiento y GPUDirect Storage

Entender el patrón de I/O es la clave para no sobredimensionar ni infradimensionar. El entrenamiento combina varios patrones: lecturas grandes y secuenciales del dataset, lecturas pequeñas y aleatorias en el shuffling entre épocas, y escrituras masivas y periódicas en el checkpointing. Cada uno estresa el almacenamiento de forma distinta.

El camino tradicional de datos atraviesa la CPU: del almacenamiento a un bounce buffer en memoria del host y de ahí a la memoria de la GPU. Cada byte de cada checkpoint y de cada carga de pesos paga la latencia y el overhead de CPU de ese doble salto. GPUDirect Storage (GDS) lo corta: habilita DMA directo entre la memoria de la GPU y el NVMe mediante la librería de espacio de usuario cuFile y el módulo de kernel nvidia-fs, que intercepta las llamadas POSIX y las redirige por el motor DMA. El resultado es zero-copy, con transferencias directas que superan los 40 GB/s y, sobre todo, sin robar ciclos a la CPU.

Hay un matiz que los despliegues ingenuos pasan por alto: GDS está optimizado para transferencias grandes, alineadas y secuenciales. Para cargas dominadas por archivos pequeños o acceso muy aleatorio, el camino tradicional con caché en la CPU puede ser más eficiente. GDS no es un interruptor mágico de “más rendimiento”; es una herramienta para un patrón concreto. Diseñar el data pipeline —formato de dataset, tamaño de shard, número de workers del DataLoader— importa tanto como elegir la cabina.

Merece la pena detenerse en el data pipeline, porque es donde se pierde rendimiento de forma más silenciosa. El entrenamiento no lee el dataset de cualquier manera: lo recorre en batches, lo baraja entre épocas para evitar sesgos de orden, y a menudo aplica transformaciones (decodificación de imágenes, tokenización, augmentation) en CPU antes de entregar el tensor a la GPU. Cada uno de esos pasos puede convertirse en el cuello de botella. Un número insuficiente de workers del DataLoader deja a la GPU esperando; un formato de dataset que obliga a abrir millones de ficheros pequeños hunde el rendimiento de metadatos; un shuffle mal diseñado convierte lecturas secuenciales eficientes en accesos aleatorios costosos. La práctica habitual en cargas serias es empaquetar el dataset en shards grandes (formatos como WebDataset, TFRecord o Parquet) precisamente para que el patrón de lectura sea secuencial y grande, el terreno donde GDS y los sistemas de archivos paralelos rinden mejor. La regla mental: el almacenamiento más rápido del mundo no salva a un pipeline de datos mal diseñado.

El coste real del checkpointing (cuando hay entrenamiento)

El checkpointing es la carga de escritura más exigente del mundo de la IA, pero conviene situarla: es un problema de entrenamiento. Una factoría de inferencia pura apenas lo sufre —sus escrituras pesadas son otras: KV-cache, índices vectoriales, telemetría—. Lo tratamos aquí porque muchas instalaciones combinan algo de fine-tuning o entrenamiento ocasional con el servicio, y porque ilustra mejor que ningún otro caso cómo la asincronía vence a la fuerza bruta. Si tu plataforma es de inferencia, puedes leer esta sección como contexto y saltar a la siguiente, que es la que de verdad te concierne.

Dicho esto, la intuición de la mayoría sobre el checkpointing es errónea en dos puntos: el tamaño y la frecuencia.

El tamaño. Un checkpoint no son solo los pesos. La regla práctica es de unos 16 bytes por parámetro, porque el grueso es el estado del optimizador. Las cifras de la carga de checkpointing de MLPerf Storage v2.0, basadas en el Llama 3 Herd de Meta, lo dejan claro:

Modelo	Procesos	Tamaño del checkpoint	Del cual, estado del optimizador
8B	8	105 GB	90 GB
70B	64	912 GB	—
405B	512	5,29 TB	—
1T	1024	15 TB	13,2 TB

La frecuencia. A escala, los fallos de hardware son constantes (lo desarrollamos en el artículo sobre disponibilidad). El modelo de Meta para un cluster de 16.000 aceleradores predice un fallo cada pocas horas. Para perder menos del 5 % del progreso entre fallos hay que hacer del orden de 20 checkpoints en ese intervalo. Eso se traduce en cadencias agresivas:

16.000 aceleradores: unos 155 checkpoints al día, uno cada 9,3 minutos.
100.000 aceleradores: unos 967 checkpoints al día, uno cada 1,5 minutos.

Y aquí aparece el problema de ancho de banda. El checkpoint síncrono detiene el entrenamiento mientras escribe. Si $ S_{\text{ckpt}} $ es el tamaño del checkpoint y $ t_{\text{win}} $ la ventana de tiempo aceptable para escribirlo manteniendo el overhead por debajo del 5 %, el ancho de banda requerido es:

$$B_{\text{req}} = \frac{S_{\text{ckpt}}}{t_{\text{win}}}$$

Para un modelo de 1T en 100.000 aceleradores, la ventana cae a unos 4,4 segundos. Escribir 15 TB en ese tiempo exige del orden de 3,6 TB/s a través del cluster, o unos 200 GB/s sostenidos a lo largo de todo el job. Solo en checkpoints, ese escenario genera más de 14 PB de escrituras al día. No es una carga marginal: es una de las cargas de escritura más exigentes que existen.

Conviene ver el cálculo desplegado, porque revela dónde está la palanca. Tomemos el modelo de 405B, cuyo checkpoint pesa 5,29 TB. Si la política exige escribirlo manteniendo el overhead por debajo del 5 % en una cadencia donde la ventana aceptable es, digamos, de 30 segundos, el ancho de banda síncrono necesario es de unos 176 GB/s sostenidos —al alcance de una cabina de gama alta, pero solo dedicada a esa tarea—. Si en lugar de 30 segundos la ventana se contrae a 5 (clúster más grande, fallos más frecuentes), el requisito salta por encima de 1 TB/s. La sensibilidad a la ventana es brutal: la diferencia entre un diseño viable y uno imposible está en cómo se gestiona el tiempo, no en cuántos discos se compran. Ahí es donde la asincronía cambia las reglas.

La solución no es solo más ancho de banda; es asincronía. El checkpointing asíncrono desacopla el snapshot (copia GPU→CPU, rápida) de la persistencia (escritura en segundo plano, solapada con el cómputo). El Distributed Async Checkpointing de PyTorch reduce el tiempo efectivo de checkpoint entre 10 y 20 veces; en un ejemplo de IBM, un modelo de 7B bajó su down time de 148,8 a 6,3 segundos, una mejora de 23,6 veces. Técnicas como CheckFreq pipelinean el snapshot y la persistencia con el entrenamiento, permitiendo checkpointear cada 14-19 iteraciones. Por eso proveedores como VAST sostienen que la métrica relevante no es GB/s sino el checkpoint overlap: qué fracción del checkpoint se solapa con el cómputo. Un 10 % de solapamiento suele bastar.

La lección de diseño es clara: dimensionar el almacenamiento de entrenamiento por el pico de escritura del checkpointing síncrono es caro y, a menudo, innecesario si la pila de software hace bien la asincronía. Pero confiar en la asincronía sin medir el overlap es jugar a la ruleta con semanas de cómputo.

El rendimiento de una factoría de inferencia

Aquí está el corazón del asunto para quien explota una factoría de inferencia. En una factoría de inferencia el almacenamiento no se mide en épocas ni en GPU-horas, sino en la experiencia que percibe el cliente, y esa experiencia se condensa en dos métricas: el TTFT (time to first token, el tiempo hasta el primer token de respuesta) y la latencia inter-token (la velocidad a la que llegan los tokens siguientes). A escala de flota, la métrica que paga las facturas es el throughput en tokens por segundo por GPU, porque determina cuántas peticiones atiende cada acelerador. El almacenamiento toca las tres, y de formas que un diseño centrado solo en entrenamiento no anticipa.

Prefill, decode y su desagregación

La inferencia tiene dos fases con perfiles opuestos. El prefill procesa todo el prompt de entrada de una vez, genera los pares clave-valor del KV-cache y es una fase intensiva en cómputo; domina el TTFT. El decode genera los tokens uno a uno reutilizando ese caché, es intensivo en ancho de banda de memoria y domina la latencia inter-token. Como sus cuellos de botella son distintos, la tendencia de 2025-2026 es desagregarlas: ejecutar el prefill y el decode en pools de GPU separados y transferir el KV-cache entre ellos. Esa transferencia —que puede ir por NVLink, por red o a través de una capa de almacenamiento compartida— convierte el movimiento del KV-cache en una operación de rendimiento crítico. Una factoría que desagrega prefill y decode necesita una vía de KV-cache de altísimo ancho de banda y baja latencia entre ambos pools; el almacenamiento (o la DPU que lo gobierna) deja de ser un actor pasivo y entra en el camino crítico de cada petición.

El KV-cache como capa de rendimiento

El problema central es el tamaño del KV-cache con contextos largos: desborda la HBM, que es escasa y cara. Las opciones son recomputarlo en cada petición —carísimo en cómputo y letal para el TTFT— o descargarlo a una capa más lenta y reutilizarlo. Aquí compiten dos enfoques. El offload a memoria CXL ofrece mejoras de más de 5 veces frente al caching basado en SSD o RDMA, según los proveedores de la cadena CXL, y permite manejar batches hasta un 30 % más grandes manteniendo los objetivos de latencia, lo que sube el throughput y la utilización de GPU. El offload a NVMe, estandarizado por NVIDIA en 2026 con su plataforma ICMS sobre BlueField-4, es más lento pero mucho más barato y capaz, idóneo para KV-cache a escala de pod.

La gran palanca de rendimiento aquí es la reutilización de KV-cache (prefix caching). Muchas peticiones comparten prefijos: el mismo system prompt, el mismo documento de contexto, la misma conversación previa. Si el KV-cache de esos prefijos se conserva en una capa de almacenamiento rápida y se reutiliza en lugar de recomputarse, el prefill se acorta drásticamente y el TTFT se desploma. Esto convierte una capa de almacenamiento de baja latencia en un multiplicador directo del throughput de la factoría: cuanto más caché útil quepa y más rápido se sirva, menos cómputo se desperdicia recalculando lo ya calculado. Dimensionar bien esta capa —capacidad, ancho de banda, latencia, política de expulsión— es una de las decisiones de rendimiento más rentables de toda la factoría.

El tiempo de carga de modelos y el cold start

Hay un coste de almacenamiento específico de la inferencia que el entrenamiento ignora: arrancar una réplica. Cuando el autoescalado decide levantar una instancia nueva de un modelo —porque sube la demanda, porque falla una réplica o porque se rota una versión—, hay que leer los pesos del repositorio y cargarlos en la HBM. Para un modelo de decenas o cientos de GB, ese cold start puede ir de segundos a minutos según el ancho de banda del repositorio y la ruta de carga. Y durante ese tiempo, la GPU nueva no atiende peticiones mientras el sistema, quizá, está saturado. Un repositorio de modelos lento se traduce directamente en SLA incumplidos en los picos. Las mitigaciones —mantener los pesos en flash local caliente, usar formatos de carga rápida, streaming de pesos a medida que se necesitan, o GPUDirect Storage para cargar directamente a la HBM— son decisiones de almacenamiento que determinan la elasticidad real de la factoría.

El rendimiento de RAG y la búsqueda vectorial

Si la factoría sirve RAG, hay un eslabón más en el camino crítico de cada petición: la recuperación. Antes de que el modelo genere nada, el sistema busca en una base de datos vectorial los fragmentos relevantes, y esa búsqueda de similitud —sobre índices que pueden ocupar TB— se suma al TTFT. El rendimiento de la búsqueda vectorial depende de mantener los índices en flash de baja latencia y de un patrón de lectura aleatoria eficiente; un índice que no cabe en memoria y se sirve desde almacenamiento lento añade latencia a cada petición. Además, los KV-cache precomputados de los documentos recuperados aceleran el prefill, porque el modelo reutiliza claves y valores ya calculados y solo codifica la consulta del usuario. La factoría de inferencia con RAG, por tanto, tiene dos cargas de lectura sensibles a latencia conviviendo —el índice vectorial y el KV-cache— que compiten por el mismo flash rápido y que hay que dimensionar juntas.

Para un arquitecto de inferencia, todo esto introduce un plano de almacenamiento con un perfil propio: lecturas aleatorias sensibles a latencia (índices, prefijos de KV-cache reutilizables), escrituras efímeras de alta rotación (KV-cache nuevo), lecturas grandes y esporádicas pero urgentes (carga de modelos) y un flujo append-only de telemetría. No se dimensiona, en absoluto, como el almacenamiento de un clúster de entrenamiento.

Cómo medir lo propio: más allá de la hoja de especificaciones

Las cifras de los fabricantes y de MLPerf son útiles como referencia, pero el rendimiento real depende de la carga concreta, y un arquitecto debe medir, no asumir. La metodología que funciona parte de tres principios.

El primero es medir la utilización del acelerador, no el almacenamiento en abstracto. Una cabina puede entregar 500 GB/s en una prueba sintética y, sin embargo, dejar las GPU al 50 % porque el patrón real es de archivos pequeños y aleatorios que la prueba secuencial no reproduce. La pregunta correcta siempre es: ¿qué fracción del tiempo está calculando mi GPU con esta carga, este formato de dataset y este pipeline?

El segundo es reproducir el patrón de I/O real, no uno cómodo. Esto implica probar con el mismo formato de dataset, el mismo tamaño de shard, el mismo número de workers y la misma cadencia de checkpointing que se usarán en producción. El acierto de MLPerf Storage fue precisamente simular el think time del acelerador para generar un patrón realista; replicar ese rigor a escala propia es lo que separa una medición útil de un número de marketing.

El tercero es buscar el escalado, no el pico. Una plataforma que entrega un pico altísimo en una configuración pequeña pero se aplana al añadir nodos no sirve para crecer. Las pruebas deben hacerse a varias escalas para verificar que el throughput crece de forma aproximadamente lineal y que la utilización del acelerador se mantiene, como mostraba el ejemplo de Hammerspace en MLPerf v2.0. Un coeficiente de variación bajo entre configuraciones es tan importante como el pico.

El coste de equivocarse

Conviene poner número al problema. El precio de una H100 en la nube a mediados de 2026 se mueve en un rango amplio según proveedor, con una mediana de mercado en torno a 2,3-3,1 USD por hora y GPU. Multiplíquese por miles de GPU y por las semanas que dura un entrenamiento, y un 40 % de utilización en lugar de un 90 % se traduce en millones de euros de cómputo desperdiciado. Por eso más del 50 % de las organizaciones reportan en 2026 cuellos de botella de datos o almacenamiento que limitan su IA, y por eso el ancho de banda de almacenamiento ha emergido como un techo duro al escalado, comparable a la energía y la refrigeración: cuando hay data starvation, añadir cómputo da rendimientos decrecientes.

La recomendación operativa que se repite es dimensionar el pipeline de I/O para 300 Gbps o más en cargas serias, y medir —no asumir— la utilización del acelerador como indicador de salud. Un almacenamiento optimizado puede entregar hasta 5 veces el throughput de un acceso S3 estándar sobre HTTP: más de 100 GB/s agregados frente a unos 20 GB/s.

La capa física: redes y PCIe Gen6

Todo lo anterior se apoya en una capa física que también ha avanzado. La NIC ConnectX-8 de NVIDIA combina PCIe Gen6 con 800 GbE u 800 Gb de InfiniBand XDR, diseñada para los sistemas Blackwell. InfiniBand XDR ofrece 800 Gbps por dirección (el doble que NDR, que sigue siendo el storage fabric habitual), y el switch Quantum-X800 añade cómputo en red que acelera las operaciones colectivas. La transición a XDR se acelera con los despliegues Blackwell de 2025-2026. La regla mental es sencilla: el almacenamiento debe estar a la altura de la red, y la red, a la altura de la GPU. Un eslabón lento define el rendimiento de toda la cadena.

Merece la pena traducir esto a números concretos. Una NIC de 800 Gb/s entrega, en el mejor caso, unos 100 GB/s a un nodo. Si la cabina puede servir más de lo que la NIC absorbe, la red es el cuello de botella; si la cabina sirve menos, lo es el almacenamiento. El equilibrio se busca dimensionando cada capa para que ninguna estrangule a la siguiente, y verificándolo con medidas de extremo a extremo, no con las especificaciones aisladas de cada componente. Es habitual encontrar instalaciones con una cabina excelente y una fabric infradimensionada —o al revés— que rinden muy por debajo de la suma de sus partes. La capa física también impone su geografía: la topología de la red (cuántos saltos hay entre el nodo de cómputo y la cabina, si comparten conmutador o atraviesan la columna vertebral del clúster) afecta a la latencia tanto como la propia cabina, y un diseño de almacenamiento para IA que ignore la topología de red está incompleto.

Tres preguntas antes de dimensionar

Toda esta complejidad se puede ordenar en tres preguntas que un arquitecto debería responder antes de comprar nada. ¿Cuál es el patrón de I/O dominante de mi carga —secuencial grande, aleatorio pequeño, escritura en ráfagas— y, por tanto, qué métrica me limita? ¿Está mi carga limitada por ancho de banda o por latencia, y en consecuencia dónde invierto? ¿Y cuál es mi presupuesto de checkpointing —tamaño, cadencia y, sobre todo, qué fracción puedo solapar con el cómputo? Quien responde estas tres con datos medidos, y no con intuiciones, dimensiona bien; quien las salta acaba con GPU ociosas o con una cabina sobredimensionada y carísima que nunca se aprovecha. El rendimiento del almacenamiento de IA es, en el fondo, un ejercicio de adecuación: poner la capacidad correcta donde la carga la necesita, ni más ni menos.

Para llevarse a casa

El rendimiento del almacenamiento para IA no se mide en GB/s sino en utilización del acelerador, y esa utilización depende de tres cosas: ancho de banda suficiente, latencia baja y, sobre todo, solapamiento de la I/O con el cómputo. MLPerf Storage v2.0 ha dado por fin un lenguaje común para comparar plataformas con esa óptica. El checkpointing es la carga de escritura más exigente y se domina con asincronía, no solo con hardware. La inferencia de contexto largo añade una capa de almacenamiento nueva alrededor del KV-cache. Y el coste de equivocarse se mide en GPU ociosas, que es la partida más cara del presupuesto.

El rendimiento, sin embargo, no sirve de nada si los datos no están protegidos ni disponibles. El tercer artículo aborda la seguridad de esta nueva capa de almacenamiento.

Ver también

Fuentes

MLCommons, MLPerf Storage v2.0 Results — https://mlcommons.org/2025/08/mlperf-storage-v2-0-results/
MLCommons, Announcing the MLPerf Storage v2.0 Checkpointing Workload — https://mlcommons.org/2025/08/storage-2-checkpointing/
MLCommons, MLPerf Storage v1.0 Benchmark Results — https://mlcommons.org/2024/09/mlperf-storage-v1-0-benchmark-results/
Hammerspace, MLPerf Storage v2.0 Benchmark Results — https://hammerspace.com/hammerspace-mlperf-storage-v2-0-benchmark-results/
Alluxio, Strong Performance in MLPerf Storage v2.0 — https://www.alluxio.io/blog/alluxio-demonstrates-strong-performance-in-mlperf-storage-v2-0-benchmarks
NVIDIA, GPUDirect Storage Overview Guide — https://docs.nvidia.com/gpudirect-storage/overview-guide/index.html
Spheron, GPU Direct Storage Guide 2026 — https://www.spheron.network/blog/gpu-direct-storage-nvme-ai-training-inference-guide/
PyTorch, Reducing Checkpointing Times with Async Checkpointing — https://pytorch.org/blog/reducing-checkpointing-times/
VAST Data, Optimizing Checkpoint Bandwidth for LLM Training — https://www.vastdata.com/blog/optimizing-checkpoint-bandwidth-for-llm-training
Astera Labs, How CXL Transforms RAG and KV Cache Performance — https://www.asteralabs.com/breaking-through-the-memory-wall-how-cxl-transforms-rag-and-kv-cache-performance/
MinIO, AI Storage Architecture: Overcoming the Bottleneck in 2026 — https://www.min.io/blog/ai-storage-architecture-bottleneck-2026
WEKA, WEKApod Nitro reference architecture — https://www.weka.io/resources/reference-architecture/nvidia-gb200-nvl72-systems-reference-architecture-for-cloud-partners/
Blocks & Files, Storage vendors rally behind Nvidia at GTC 2025 — https://blocksandfiles.com/2025/03/18/nvidia-storage-announcements/
ServeTheHome, NVIDIA ConnectX-8 SuperNIC PCIe Gen6 800G — https://www.servethehome.com/nvidia-connectx-8-supernic-pcie-gen6-800g-nic-detailed/
SpendArk, GPU Cloud Pricing 2026 — https://spendark.com/blog/machine-learning-cloud-cost/

Catálogo de herramientas de benchmark LLM: ficha práctica a fondo

Sun, 14 Jun 2026 02:00:00 +0200

Notación: importes en euros (N €), decimales con coma. No se usa el símbolo de dólar (en este sitio es delimitador de fórmula).

Qué cubre este artículo

Segundo artículo del track de benchmarking (B2). La introducción B1 fijó las métricas y la metodología; este artículo es el manual práctico: para cada herramienta, qué mide, cómo se invoca de verdad (con el comando), qué formato de salida da y cuándo elegirla. El objetivo es que, tras leerlo, sepas qué ejecutar para medir tu motor y puedas reproducir el número. Sin recomendaciones universales; solo la mecánica de cada herramienta y el criterio para escoger.

Cómo elegir: el mapa de herramientas

Recordando la división de B1, las herramientas se ordenan en dos ejes: micro-bench (mono-proceso, para tunear un motor) vs generador de carga (multi-proceso, para medir capacidad real), y propias del motor vs agnósticas del endpoint.

Datasets: la carga sintética importa tanto como la herramienta

Antes de las fichas, un punto que cambia los resultados sin que se note: qué carga le metes. Las herramientas aceptan distintos tipos de dataset, y cada uno mide algo distinto:

Dataset	Qué simula	Sesgo que introduce
random (longitudes fijas)	carga uniforme controlada	irreal: el tráfico no es de longitud fija
sharegpt (conversaciones reales)	distribución realista de prompts	el estándar de facto para comparar
trazas propias	tu tráfico real	el más fiel, pero específico de tu caso

La trampa: un benchmark con prompts cortos de longitud fija da un throughput altísimo que no se parece a producción, donde las longitudes varían y los prompts largos dominan el coste de prefill. Para una cifra defendible, usa sharegpt (comparabilidad) o, mejor, trazas de tu propio tráfico (fidelidad). Y declara siempre la distribución de longitudes (prompt/salida) junto al número, porque dos benchmarks con datasets distintos no son comparables aunque usen la misma herramienta.

vLLM bench serve

Qué mide: TTFT, TPOT, throughput y latencias del servidor vLLM bajo una carga sintética. Clase: micro-bench (mono-proceso). Es la herramienta para tunear vLLM y ver el efecto de sus optimizaciones (decode, prefill).

Invocación típica (vLLM · CLI de benchmark):

vllm bench serve \
 --backend vllm \
 --model meta-llama/Llama-3.1-8B-Instruct \
 --endpoint /v1/completions \
 --dataset-name sharegpt \
 --dataset-path ShareGPT_V3_unfiltered_cleaned_split.json \
 --num-prompts 1000

Parámetros clave: --num-prompts (carga), --dataset-name (sharegpt, random, etc.), --request-rate (peticiones/s). La salida es un resumen por consola con TTFT, TPOT, throughput y percentiles, y puede volcarse a JSON. Para barrer concurrencias existe vllm bench sweep serve, que automatiza el sweep (vLLM · sweep).

Límite: mono-proceso, se satura en el cliente a alta concurrencia; menos flexible que GuideLLM en datasets y patrones de carga. Úsalo para iterar rápido sobre la config de vLLM, no para medir la capacidad máxima a escala.

SGLang bench

Qué mide: el equivalente para el motor SGLang (TTFT, TPOT, throughput). Clase: micro-bench. Uso: tunear SGLang y compararlo consigo mismo entre configuraciones. La mecánica es análoga a vllm bench serve: una carga sintética, salida por consola/JSON con las mismas métricas. Si evalúas SGLang vs vLLM, no los compares con sus micro-benchs respectivos (clases iguales pero implementaciones distintas): usa un generador de carga agnóstico (GuideLLM/AIPerf) contra ambos endpoints, para que la herramienta no sea la variable.

AIPerf (NVIDIA, ex genai-perf)

Qué mide: TTFT, ITL, throughput y latencia sobre cualquier endpoint compatible (vLLM, NIM, TGI, SGLang). Clase: generador de carga multi-proceso. Es el sucesor de genai-perf (jubilado el 15-abr-2026). Su rasgo distintivo: durante el sweep detecta la saturación de la GPU y devuelve la iteración anterior como estimatedCapacity; por eso hay que extender el sweep más allá del codo (AIPerf).

Salida: métricas estructuradas (JSON) con distribuciones de TTFT/ITL y el estimatedCapacity. Úsalo cuando quieras la capacidad real de un endpoint, sea cual sea el motor, con la detección automática del punto de saturación.

GuideLLM (proyecto vLLM)

Qué mide: distribuciones completas de TTFT, ITL y comportamiento de extremo a extremo, para evaluación dirigida por SLO. Clase: generador de carga multi-proceso. Es la herramienta recomendada para benchmarkear servidores vLLM en producción: más flexible que vllm bench serve en carga de datasets, formato de peticiones y patrones de tráfico, con progreso en vivo y generación automática de informe (Red Hat).

Invocación típica:

guidellm benchmark \
 --target "http://localhost:8000" \
 --rate-type throughput \
 --max-requests 1000 \
 --data "samples=1000,prompt_tokens=1024,output_tokens=256"

Parámetros clave: --rate-type (synchronous, concurrent, throughput, o por tasa), --data (especificación de la carga: nº de muestras y longitudes de prompt/salida), --target (el endpoint). Genera sweeps reproducibles para hallar el rango de operación seguro bajo SLO, con distribuciones completas (no solo medias). Salida: informe con percentiles y, a menudo, exportable a JSON/HTML. Es la opción por defecto para responder “¿hasta dónde cargo este motor sin romper el SLO?”.

LLMPerf (Anyscale/Ray)

Qué mide: throughput y latencia a nivel de inferencia. Clase: generador de carga. Uso: validación de endpoints, históricamente muy extendido en el ecosistema Ray/Anyscale. Es una opción sólida y conocida, aunque menos centrada en distribuciones y sweeps que GuideLLM/AIPerf. Encaja si ya operas en Ray o quieres una herramienta simple para validar un endpoint.

inference-benchmarker (Hugging Face)

Qué mide: latencia y throughput de endpoints de inferencia, con orientación a generar informes comparables. Clase: generador de carga. Uso: alternativa OSS dentro del ecosistema Hugging Face, útil si ya trabajas con TGI o el stack de HF. Como las demás de su clase, su valor está en medir capacidad real con carga distribuida; la elección entre ésta, GuideLLM y AIPerf suele venir por el ecosistema en el que ya operas más que por diferencias de fondo en lo que miden.

GuideLLM vs AIPerf: cuál de los dos generadores de carga

Son las dos opciones serias de carga multi-proceso, y se solapan mucho. Las diferencias prácticas que inclinan la elección:

Criterio	GuideLLM	AIPerf
Origen	proyecto vLLM (Red Hat)	NVIDIA (sucesor de genai-perf)
Foco	evaluación dirigida por SLO, sweeps reproducibles	capacidad real, estimatedCapacity automático
Patrones de carga	síncrono, concurrente, por tasa	sweep con detección de saturación
Informe	progreso en vivo + informe automático	métricas estructuradas (JSON)
Ecosistema	vLLM / OpenShift AI	NVIDIA NIM / Triton / vLLM

En la práctica: si tu pregunta es “¿hasta dónde cargo sin romper el SLO?”, GuideLLM la responde de forma más directa con sus sweeps dirigidos por SLO; si tu pregunta es “¿cuál es la capacidad máxima de este endpoint?”, AIPerf la da con su detección automática del codo. Muchos equipos usan los dos: GuideLLM para el SLO operativo, AIPerf para la capacidad de referencia. Lo que no debes hacer es comparar un resultado de GuideLLM con uno de AIPerf como si fueran la misma medida: aunque ambos sean multi-proceso, su metodología de sweep difiere; elige uno para una comparación dada y mantenlo.

MLPerf Inference (MLCommons)

Qué mide: rendimiento bajo escenarios normalizados (Offline, Server, Interactive) con reglas estrictas. A diferencia de las anteriores, MLPerf no se “ejecuta” para tu caso del día a día: es una suite de comparación entre fabricantes cuyos resultados se leen (publicados por NVIDIA, AMD, Intel, etc.). Úsalo para comparar hardware/motores entre sí con reglas idénticas, no para dimensionar tu carga concreta —para eso, GuideLLM/AIPerf sobre tu endpoint—.

Tabla comparativa práctica

Herramienta	Clase	Comando base	Salida	Cuándo
vllm bench serve	micro	`vllm bench serve`	consola/JSON	tunear vLLM
vllm bench sweep	micro (sweep)	`vllm bench sweep serve`	consola/JSON	barrer concurrencia en vLLM
SGLang bench	micro	bench del repo SGLang	consola/JSON	tunear SGLang
AIPerf	carga	`aiperf profile …`	JSON + estimatedCapacity	capacidad real, multi-endpoint
GuideLLM	carga	`guidellm benchmark …`	informe + JSON/HTML	SLO, sweep reproducible
LLMPerf	carga	script Ray/LLMPerf	JSON	validar endpoint (Ray)
MLPerf	suite	(se leen resultados)	resultados oficiales	comparar fabricantes

Resumen: qué ejecutas para cada pregunta

Para no perderse en el catálogo, el mapeo directo de pregunta a herramienta:

Tu pregunta	Herramienta	Por qué
“¿Mejora mi cambio de config en vLLM?”	`vllm bench serve` (+ sweep)	rápido, propio del motor
“¿Hasta dónde cargo sin romper el SLO?”	GuideLLM	sweeps dirigidos por SLO
“¿Cuál es la capacidad máxima del endpoint?”	AIPerf	detección automática del codo
“¿vLLM o SGLang para mi carga?”	GuideLLM/AIPerf contra ambos	misma herramienta, motor variable
“¿Qué hardware/motor es mejor en abstracto?”	leer MLPerf	comparabilidad cross-vendor
“¿Hay regresión en este release?”	sweep corto en CI vs línea base	detección continua

La regla que subyace a toda la tabla: micro-bench para iterar sobre un motor, generador de carga para medir capacidad y decidir, MLPerf para comparar fabricantes. Y, para cualquier comparación entre sistemas, la misma herramienta para todos los candidatos. Si tienes claras estas tres categorías, la elección concreta es secundaria.

Metodología paso a paso de un benchmark

Una corrida fiable no es “lanzar el comando”: es un procedimiento. Los pasos, con la herramienta de carga (GuideLLM/AIPerf) contra tu endpoint:

Desplegar el motor con la config exacta a medir (modelo, precisión, flags), pineada.
Calentar: lanzar unas peticiones y descartarlas, para que el prefix cache y el autotuning no inflen los primeros números.
Sweep: barrer concurrencias crecientes (1, 8, 16, 24, 32…) más allá del codo, para ver dónde se dispara la latencia.
Recoger la salida en JSON con percentiles (TTFT/ITL/throughput/goodput) y los metadatos.
Comparar: leer el goodput bajo el SLO, no el throughput máximo.

Saltarse el paso 2 (warm-up) o no pasar el codo en el 3 son los dos errores que más sesgan el resultado.

Comparar dos motores: el protocolo justo

Si el objetivo es elegir entre vLLM y SGLang (o TRT-LLM), el protocolo que evita conclusiones falsas:

Misma herramienta de carga (GuideLLM o AIPerf) contra ambos endpoints — nunca el micro-bench de cada motor.
Mismo dataset y distribución de longitudes.
Mismo hardware y precisión.
Mismo SLO para calcular el goodput de ambos.
Variar solo el motor; todo lo demás, fijo.

Solo así la diferencia que midas es del motor y no de la herramienta, el dataset o el hardware. Es el experimento controlado que sostiene la fila del cuadro de mando (artículo B8).

Formato de salida y comparabilidad

Lo que registres junto al número es lo que lo hace comparable. Una salida útil incluye, en JSON para versionarla:

{
 "tool": "guidellm", "version": "x.y.z",
 "model": "Llama-3.1-70B", "precision": "FP16",
 "hardware": "8xH100 SXM NVLink",
 "load": {"prompt_tokens": 1024, "output_tokens": 256, "concurrency": 16},
 "results": {"ttft_p50_ms": 180, "ttft_p99_ms": 460,
 "itl_p50_ms": 22, "throughput_tok_s": 3400, "goodput_tok_s": 3330}
}

Guardar esto por cada corrida convierte un benchmark en un dato auditable: cualquiera reproduce la cifra con la misma herramienta, versión, modelo, hardware y carga. Es el material del harness reproducible (artículo S4), y la diferencia entre un número defendible y una captura de consola.

Ejemplo trabajado: leer la salida de un sweep

Una salida ilustrativa de un sweep de GuideLLM sobre un 70B en 8×H100 (SLO: P99 de TTFT < 500 ms), tal como la leerías:

Concurrencia	TTFT P99 (ms)	ITL P50 (ms)	Throughput (tok/s)	Goodput (tok/s)
8	240	20	2.100	2.100
16	460	22	3.400	3.330
24	980	31	3.900	2.420
32	1.800	54	4.000	800

Cómo se lee: el codo está entre 16 y 24. A concurrencia 16, el P99 (460 ms) cumple el SLO y el goodput (3.330 tok/s) ≈ throughput. A 24, el throughput sube poco (3.400 → 3.900) pero el P99 ya viola el SLO y el goodput cae a 2.420. A 32, el throughput es máximo (4.000) pero el goodput se desploma a 800: el sistema “rinde mucho” sirviendo peticiones que incumplen. La capacidad defendible es la de concurrencia 16 (3.330 tok/s útiles), y ese es el número que entra en el capacity planning y en el coste por token. Quien reporte “4.000 tok/s” está describiendo el punto donde el sistema ya no cumple su SLO.

Automatizar el harness

Una corrida manual no escala a un programa de benchmarking. La automatización mínima:

Script idempotente que despliega el motor, calienta, corre el sweep y guarda el JSON con todos los metadatos (modelo, versión, hardware, dataset, SLO).
Nombrado por fecha y config, para versionar las corridas y comparar en el tiempo.
Almacén de resultados (un repo git de JSONs, o un bucket) para que cualquiera reproduzca y compare.

El objetivo es que reproducir un número sea un comando, no una tarde. Es la base del harness del artículo S4, y lo que convierte el benchmarking de una actividad puntual en una capacidad continua de la plataforma.

Integración en CI: benchmarking continuo

El siguiente nivel es medir en cada cambio: un job de CI que, al actualizar el motor o la config, lanza un sweep corto contra un entorno de pruebas y compara con la línea base. Si el goodput cae más de un umbral, falla el pipeline. Así una regresión de rendimiento se detecta en el commit, no en producción. Cuidado con dos cosas: el benchmarking en CI consume GPU-horas (presupuéstalo) y necesita un entorno estable (mismo hardware) para que la comparación sea válida. No hace falta el sweep completo en cada commit: un sweep corto que cubra el codo basta para detectar regresiones; el sweep exhaustivo, para los releases.

El coste de medir (en euros)

Benchmarkear consume GPU-horas, y eso tiene un coste que conviene presupuestar. Un sweep serio sobre un nodo 8×H100 puede ocupar las tarjetas un par de horas; a coste amortizado de ~11 €/h, son ~22 € por sweep completo, más si barres varios modelos y precisiones. No es mucho por corrida, pero un programa de benchmarking continuo (cada release, cada cambio de config) suma. La regla práctica: automatiza el harness para que cada corrida sea barata y reproducible, y mide lo que vas a usar para decidir, no por exhaustividad. El coste de medir es parte del coste de la plataforma —pequeño frente al de servir, pero real—.

Observar durante el benchmark: una corrida, tres ejes

Un truco que ahorra trabajo y conecta la serie: mientras corre el sweep, captura también las métricas de GPU. Con DCGM exportando a Prometheus durante la corrida, registras a la vez:

Eje	Fuente durante el sweep	Métrica
Rendimiento	la herramienta (GuideLLM/AIPerf)	TTFT, ITL, throughput, goodput
Energía	DCGM	potencia (W) → J/token
Coste	precio del nodo (OpenCost)	€/hora → CPM por punto

Así, de una sola corrida sacas los tres números del mismo punto de operación: a concurrencia 16, el goodput (3.330 tok/s), la potencia media (de DCGM, que dividida por el throughput da los J/token) y el coste por token (con el precio del nodo). En vez de tres campañas separadas, mides los tres ejes a la vez, y quedan coherentes por construcción porque corresponden al mismo instante y la misma carga. Es lo que hace el harness del artículo S4, y la razón de exportar DCGM durante el benchmark aunque solo busques rendimiento: la energía y el coste salen casi gratis si los capturas en la misma ventana.

La advertencia metodológica: alinea las ventanas temporales. La potencia de DCGM y las métricas de la herramienta tienen que cubrir exactamente el mismo intervalo (sin warm-up ni apagado), o el J/token no corresponde al throughput medido. Misma ventana, mismos tres números.

El benchmark es también FinOps y energía

Una idea que conecta este artículo con el resto de la serie: medir rendimiento es, de hecho, medir coste y energía. Por la identidad del artículo de apertura, el goodput es el denominador del coste por token y de la energía por token. Cuando un sweep revela que la config A da 3.330 tok/s de goodput y la config B da 4.000, no estás midiendo solo velocidad: estás midiendo que B cuesta menos euros y menos vatios por token. Por eso el JSON de salida de un benchmark debería acompañarse del coste de hierro (de OpenCost) para calcular el CPM real de cada punto del sweep: throughput × precio del nodo = coste por token. El benchmarking no es un eje aislado; es la herramienta que, indirectamente, más mueve el coste y la energía de la plataforma, y la que llena la columna de rendimiento del cuadro de mando con números que se traducen directamente a euros.

La consecuencia operativa: no benchmarkees el rendimiento en el vacío. Cada corrida que guardes con su throughput y su goodput debería poder cruzarse con el coste del nodo (€/hora) y la energía (J/token) para dar las tres caras del mismo punto de operación. Esa es la forma de que el track de benchmarking alimente al de FinOps y al de energía, en vez de vivir aparte.

Estado del arte 2026 y límites

Migración a multi-proceso: AIPerf (ex genai-perf) y GuideLLM consolidan la medición de capacidad real; los micro-benchs quedan para tunear motores.
GuideLLM como estándar OSS de evaluación dirigida por SLO con informe automático.
Cuidado con comparar entre clases: un micro-bench y un generador de carga no son comparables; fija la clase y la herramienta.
Versión y dataset importan: el mismo comando con otro dataset o versión da otro número; pínealos.
MLPerf no dimensiona tu caso: compara fabricantes, no sustituye un sweep sobre tu carga.

Con el catálogo práctico cubierto, el siguiente artículo del track (B3) entra en GuideLLM y la validación de SLO bajo carga a fondo. La herramienta es el medio; el dato reproducible, el fin.

Errores que invalidan un benchmark

Para terminar, la lista de lo que convierte una corrida en basura, por frecuencia:

Error	Efecto	Arreglo
Comparar clases distintas	hasta 7× de diferencia espuria	misma herramienta para todos
No descartar el warm-up	TTFT artificialmente bajo	calentar y descartar
No pasar el codo	no conoces la capacidad segura	extender el sweep
Dataset irreal (longitud fija)	throughput que no aplica	sharegpt o trazas propias
Reportar media, no P99	oculta la cola	percentiles siempre
Tokenizer ajeno al modelo	tok/s y coste/token sesgados	contar con el del modelo
No pinear versión/config	irreproducible	guardar todo en el JSON

Cualquiera de estos basta para que el número no sea defendible. Un benchmark es tan bueno como su metodología: la herramienta importa menos que ejecutarla bien y registrarlo todo.

Cierre

El catálogo de herramientas de benchmark se reduce a una decisión simple —micro-bench para tunear un motor, generador de carga para medir capacidad, MLPerf para comparar fabricantes— y a una disciplina que pesa más que la elección: el método. La misma guidellm benchmark da un dato de oro o uno inútil según el dataset, el warm-up, hasta dónde llegue el sweep y qué registres en la salida. Para una propuesta de arquitectura soberana, el rendimiento solo cuenta si viene con su comando, su versión, su carga y su goodput bajo SLO —y, cruzado con el coste en euros y la energía por token, se convierte en la columna del cuadro de mando que decide qué motor y qué configuración sostienen la plataforma. La herramienta la eliges en cinco minutos; la metodología es lo que hace que el número aguante una auditoría.

Ver también

GenAI-Perf a fondo — ficha ampliada del perfilador de NVIDIA: métricas (TTFT/TPOT/ISL/OSL), invocación contra endpoint OpenAI-compatible y comparación con GuideLLM/LLMPerf.
Comparativa de motores de serving (vLLM/SGLang/TRT-LLM/Dynamo) — una vez medido el goodput con estas herramientas, aquí se ven qué motor gana en cada punto de la frontera de Pareto.
Sesgo de medición y reproducibilidad — las fuentes de sesgo que invalidan resultados aunque la herramienta esté bien configurada: warmup, dataset real vs sintético, entorno compartido.

Fuentes

vLLM · CLI de benchmark (bench serve) — https://docs.vllm.ai/en/latest/cli/bench/serve/
vLLM · bench sweep serve — https://docs.vllm.ai/en/latest/cli/bench/sweep/serve/
Red Hat · desplegar y benchmarkear vLLM con GuideLLM en Kubernetes — https://developers.redhat.com/articles/2025/12/24/how-deploy-and-benchmark-vllm-guidellm-kubernetes
GuideLLM · GitHub (proyecto vLLM) — https://github.com/vllm-project/guidellm
NVIDIA AIPerf · guía de benchmarking — https://lucaberton.com/blog/nvidia-aiperf-llm-inference-benchmarking-guide/
Medium · Benchmarking LLM Serving Performance (guía) — https://medium.com/@kimdoil1211/benchmarking-llm-serving-performance-a-comprehensive-guide-db94b1bfe8cf

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

Sat, 13 Jun 2026 02:30:00 +0200

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:

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

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.

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:

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

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

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

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.
Throughput de catálogo en vez de goodput. El número honesto es el que cumple el SLO.
Medias en vez de percentiles. La media oculta la cola; reporta P95/P99.
No extender el sweep más allá del codo. Sin ver dónde se dispara la latencia no conoces la capacidad segura.
Confundir rendimiento con calidad. Son ejes distintos; rápido no es bueno.
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