Guidellm on lo0 — Blog Técnico

El harness reproducible: medir coste, rendimiento y energía en un solo experimento auditable

Tue, 16 Jun 2026 12:00:00 +0200

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

TL;DR

La serie “datos” ha producido tres ejes de medición independientes: coste por millón de tokens (OpenCost + LiteLLM), rendimiento bajo SLO (GuideLLM + AIPerf) y energía por token (DCGM + Kepler). El problema es que los tres se han medido en artículos distintos, con cargas distintas y en momentos distintos: no son comparables entre sí. Este artículo de cierre describe el harness integrado que ejecuta los tres ejes en el mismo experimento, sobre el mismo nodo (4×H100 SXM, referencia genérica), con todos los metadatos fijados, la salida en JSON/CSV versionados y un Job de Kubernetes idempotente. El resultado es el scorecard de 3 ejes (€/1M tok, Wh/token, TTFT/ITL P99) que permite comparar configuraciones sobre una frontera de Pareto multi-objetivo y auditar cualquier cifra con el banco para reproducirla.

Por qué los tres ejes deben medirse juntos

El post de apertura de la serie (Los tres ejes) estableció la identidad:

$$\text{CPM} = \frac{\text{coste/h}}{\text{throughput (tok/s)} \times 3{,}6 \times 10^{-3}}$$ $$\text{energía/token (Wh)} = \frac{\text{potencia media (W)}}{\text{throughput (tok/s)} \times 3\,600}$$

El throughput es el denominador común. Si se mide en experimentos distintos —diferente hora, diferente carga, diferente temperatura de GPU— el CPM y la energía/token no comparten denominador: son tres anécdotas, no un scorecard. El harness los captura en la misma ventana temporal, sobre la misma carga, con ventanas de Prometheus alineadas al segundo. Solo así la fila del scorecard es coherente por construcción.

La segunda razón es la reproducibilidad. El post Sesgo y reproducibilidad en el benchmarking listó doce sesgos que invalidan comparaciones: motor no pinneado, tokenizador no declarado, longitud de entrada/salida no fijada, warmup ausente, cliente fuera del cluster. El harness elimina todos ellos porque los metadatos son parte del Job, no de la documentación.

Arquitectura del banco integrado

El harness tiene cuatro capas. Cada una es OSS, exporta a Prometheus y convive en el mismo namespace de Kubernetes:

Capa	Herramienta(s)	Métrica primaria	Protocolo de export
Rendimiento	GuideLLM (sweep SLO) + AIPerf	TTFT P99, ITL P99, goodput (tok/s)	JSON/CSV nativo + `/metrics` OpenMetrics
Coste	OpenCost + LiteLLM proxy	CPM (€/1M tok), coste/petición	API REST + Prometheus scrape
Energía (GPU)	DCGM Exporter	`DCGM_FI_DEV_POWER_USAGE` (W), `DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION` (mJ)	DaemonSet Prometheus
Energía (pod)	Kepler	`kepler_container_joules_total`, energía por pod	DaemonSet Prometheus

MLPerf Power se usa como referencia de comparabilidad externa: sus resultados publicados, con hardware documentado al detalle, permiten calibrar si las cifras del harness son plausibles. El banco propio no pretende ser un submission de MLPerf, sino ser reproducible en el propio cluster.

El Job de Kubernetes: YAML completo

El experimento se ejecuta como un Kubernetes Job versionado. Todos los metadatos relevantes son variables de entorno declaradas en el manifiesto: ni en scripts ad-hoc, ni en documentación externa. El Job es idempotente (mismo nombre = misma corrida) y deja trazas en el log del pod y en el volumen de salida.

apiVersion: batch/v1
kind: Job
metadata:
 name: bench-llama3-70b-fp8-h100x4-20260616
 namespace: benchmark
 labels:
 bench/model: llama3-70b
 bench/precision: fp8
 bench/engine: vllm-0.9.1
 bench/hardware: h100x4-sxm
 bench/isl: "1024"
 bench/osl: "256"
 bench/concurrency: "32"
 bench/tokenizer: meta-llama-3-tokenizer-v3
 bench/run-id: "20260616T1200"
spec:
 backoffLimit: 0
 template:
 spec:
 restartPolicy: Never
 serviceAccountName: bench-runner
 volumes:
 - name: results
 persistentVolumeClaim:
 claimName: bench-results-pvc
 initContainers:
 # Warmup: 60 s de tráfico previo al experimento
 - name: warmup
 image: ghcr.io/vllm-project/guidellm:0.4.2
 command:
 - guidellm
 - benchmark
 - --target
 - http://vllm-svc.inference.svc.cluster.local:8000
 - --rate-type
 - concurrent
 - --rate
 - "4"
 - --max-seconds
 - "60"
 - --data
 - prompt_tokens=1024,output_tokens=256
 env:
 - name: GUIDELLM_ENV
 value: production
 containers:
 - name: guidellm-sweep
 image: ghcr.io/vllm-project/guidellm:0.4.2
 command:
 - guidellm
 - benchmark
 - --target
 - http://vllm-svc.inference.svc.cluster.local:8000
 - --rate-type
 - sweep
 - --max-seconds
 - "120"
 - --data
 - prompt_tokens=1024,output_tokens=256
 - --output-path
 - /results/guidellm-$(BENCH_RUN_ID).json
 env:
 - name: BENCH_RUN_ID
 valueFrom:
 fieldRef:
 fieldPath: metadata.labels['bench/run-id']
 volumeMounts:
 - name: results
 mountPath: /results

 - name: aiperf-concurrent
 image: nvcr.io/nvidia/aiperf:0.2.0
 command:
 - aiperf
 - profile
 - --url
 - http://vllm-svc.inference.svc.cluster.local:8000/v1
 - --model
 - meta-llama/Meta-Llama-3-70B-Instruct
 - --concurrency
 - "4,8,16,32"
 - --input-tokens
 - "1024"
 - --output-tokens
 - "256"
 - --num-requests
 - "200"
 - --output
 - /results/aiperf-$(BENCH_RUN_ID).json
 volumeMounts:
 - name: results
 mountPath: /results

 - name: scorecard-exporter
 image: python:3.12-slim
 command:
 - python
 - /scripts/export_scorecard.py
 - --run-id
 - "$(BENCH_RUN_ID)"
 - --prometheus
 - http://prometheus.monitoring.svc.cluster.local:9090
 - --output
 - /results/scorecard-$(BENCH_RUN_ID).json
 env:
 - name: BENCH_RUN_ID
 valueFrom:
 fieldRef:
 fieldPath: metadata.labels['bench/run-id']
 volumeMounts:
 - name: results
 mountPath: /results

El nombre del Job (bench-llama3-70b-fp8-h100x4-20260616) es el identificador único de la corrida. Cambiarlo es suficiente para registrar una variante. Los labels son los metadatos que el scorecard-exporter lee para enriquecer el JSON de salida.

Capa de rendimiento: GuideLLM y AIPerf

GuideLLM — el sweep dirigido por SLO

GuideLLM (proyecto vLLM) genera patrones de tráfico realistas —synchronous, concurrent, poisson, throughput, sweep— y captura distribuciones completas de TTFT e ITL (Red Hat Developer). El modo sweep barre de idle a saturación en 10 rondas e identifica el codo: la carga máxima donde el goodput ≈ throughput bajo el SLO declarado. La salida es JSON/CSV con todos los percentiles por ronda, lista para versionarse.

Para el harness, el SLO de referencia del banco es:

Métrica	Umbral	Percentil
TTFT	500 ms	P99
ITL (TPOT)	50 ms/tok	P95
Tasa de error	0,5 %	—

El comando del Job ya aparece en el YAML anterior. La salida JSON incluye por ronda: tasa (req/s), TTFT (P50/P95/P99), ITL (P50/P95/P99), throughput (tok/s) y goodput (tok/s). El goodput bajo el SLO del codo es el valor que entra en el scorecard.

Para la capa de verificación cruzada de datos y comparabilidad con resultados publicados, véase el post GuideLLM a fondo.

AIPerf — el perfilador de concurrencia de NVIDIA

AIPerf (sucesor de GenAI-Perf, repositorio ai-dynamo/aiperf) mide TTFT, ITL, throughput y latencias en distribución a concurrencias fijas (GitHub ai-dynamo/aiperf). Donde GuideLLM da el sweep automático hasta el codo, AIPerf da el perfil detallado a concurrencias concretas (4, 8, 16, 32 en el ejemplo): permite caracterizar la curva throughput-latencia punto a punto.

Los dos son complementarios: GuideLLM halla el codo de forma automática; AIPerf lo confirma y caracteriza el comportamiento en el entorno de ese codo. Ambas salidas van al volumen de resultados con el mismo BENCH_RUN_ID. El análisis profundo de AIPerf/GenAI-Perf está en GenAI-Perf a fondo.

Métricas que el harness extrae de AIPerf para el scorecard:

# TTFT P99 a concurrencia 16 (la más cercana al codo del sweep):
aiperf profile ... --concurrency 16 \
 | jq '.results[] | select(.concurrency==16) | .ttft_ms.p99'

# Goodput (tok/s) a concurrencia 16:
aiperf profile ... --concurrency 16 \
 | jq '.results[] | select(.concurrency==16) | .output_token_throughput'

Capa de coste: OpenCost y LiteLLM

OpenCost — el denominador en euros por GPU-hora

OpenCost (CNCF incubating, opencost.io) asigna coste de Kubernetes a namespace, label, pod y contenedor en tiempo real (GitHub opencost/opencost). Para el harness, OpenCost resuelve la pregunta: ¿cuánto cuesta en euros por hora el pod vllm-svc durante la ventana del experimento?

El harness llama a la API REST de OpenCost al terminar el experimento:

# Coste del namespace inference en la ventana del experimento (1 hora)
curl -s "http://opencost.monitoring.svc.cluster.local:9003/allocation" \
 --data-urlencode 'window=2026-06-16T12:00:00Z,2026-06-16T13:00:00Z' \
 --data-urlencode 'aggregate=namespace' \
 --data-urlencode 'namespace=inference' \
 | jq '.data[0].inference.totalCost'

El coste devuelto (en EUR, configurado con precios reales del nodo) se divide por el throughput medido en esa misma ventana para obtener el CPM:

$$\text{CPM} = \frac{\text{coste}_\text{namespace/h} \times 10^6}{\text{goodput (tok/s)} \times 3\,600}$$

El post OpenCost: cost allocation en Kubernetes detalla la configuración de precios y la asignación por label de GPU.

LiteLLM — el token counter por petición

LiteLLM (litellm.ai, GitHub BerriAI/litellm) actúa como proxy OpenAI-compatible con contabilidad de tokens por petición, modelo y equipo. En el harness, GuideLLM y AIPerf apuntan al endpoint de LiteLLM (que a su vez reenvía a vLLM): cada petición queda registrada con prompt_tokens, completion_tokens y cost (usando el pricing custom configurado para el nodo on-prem).

# litellm-config.yaml (fragmento de pricing custom on-prem)
model_list:
 - model_name: llama3-70b-fp8
 litellm_params:
 model: openai/meta-llama/Meta-Llama-3-70B-Instruct
 api_base: http://vllm-svc.inference.svc.cluster.local:8000/v1
 api_key: sk-dummy
 input_cost_per_token: 0.00000109 # 1,09 EUR/1M tok on-prem
 output_cost_per_token: 0.00000109

Los registros de LiteLLM se exportan a Prometheus como litellm_request_total_tokens y litellm_spend_metric_total, que el scorecard exporter consume para calcular el CPM real por tipo de token (input vs output).

Capa de energía: DCGM y Kepler

DCGM Exporter — potencia y energía GPU

DCGM Exporter (GitHub NVIDIA/dcgm-exporter, docs) expone métricas de GPU en /metrics para Prometheus como DaemonSet en los nodos GPU. Las dos métricas de energía que usa el harness:

Métrica DCGM	Tipo	Unidad	Uso en el harness
`DCGM_FI_DEV_POWER_USAGE`	gauge	W	potencia instantánea por GPU
`DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION`	counter	mJ	energía acumulada desde boot

Para calcular la energía consumida durante la ventana del experimento (sin la línea de base idle), el harness hace la diferencia del counter antes y después del sweep:

# Despliegue como DaemonSet (fragmento del chart oficial)
helm repo add gpu-helm-charts \
 https://nvidia.github.io/dcgm-exporter/helm-charts
helm install dcgm-exporter gpu-helm-charts/dcgm-exporter \
 --namespace monitoring \
 --set serviceMonitor.enabled=true \
 --set serviceMonitor.interval=15s

El campo DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION (en mJ) permite calcular la energía del experimento con exactitud de contador de hardware, no de estimación:

$$\text{energía experimento (J)} = \left(\text{counter}_\text{fin} - \text{counter}_\text{inicio}\right) \times 10^{-3}$$ $$\text{Wh/token} = \frac{\text{energía experimento (J)}}{3\,600 \times \text{tokens generados}}$$

Kepler — energía a nivel de pod

Kepler (CNCF sandbox, GitHub sustainable-computing-io/kepler) usa eBPF para estimar el consumo energético a nivel de contenedor y pod, exportando kepler_container_joules_total a Prometheus (Red Hat Emerging Technologies). Combina RAPL (CPU/DRAM), NVML (GPU) y modelos de regresión cuando no hay sensores disponibles.

En el harness, Kepler complementa a DCGM: DCGM da la medición de hardware de la GPU (más precisa para cargas GPU-intensivas como la inferencia LLM), mientras Kepler atribuye la energía al pod de vLLM específico (incluida la contribución de CPU del nodo). La métrica principal que consume el harness:

# Energía del pod vllm-svc durante el experimento (J)
increase(
 kepler_container_joules_total{
 container_namespace="inference",
 container_name="vllm"
 }[${BENCH_DURATION}]
)

El análisis comparativo de DCGM vs Kepler vs Zeus está en Herramientas de energía: deploy, precisión y overhead.

Referencia MLPerf Power

MLPerf Power (MLCommons, paper IEEE HPCA 2025) establece el protocolo de medición de eficiencia energética de sistemas ML con medición externa de alta precisión. El banco propio no es un submission MLPerf (requiere vatímetros externos y revisión por comité), pero sus resultados publicados son la referencia de calibración: si el harness da un resultado del mismo orden que el submission MLPerf del mismo hardware con el mismo modelo, la medición es plausible. Si difiere más de un factor 2, hay un problema metodológico. Véase el post MLPerf Power: eficiencia energética para los datos de referencia actuales.

Unificación de métricas: las queries PromQL

El scorecard-exporter es el contenedor del Job que, al terminar GuideLLM y AIPerf, recoge todas las métricas de Prometheus y construye el JSON de la fila del scorecard. Las queries clave:

# Potencia media GPU durante el sweep (W) — nodo 4×H100
avg_over_time(
 sum(DCGM_FI_DEV_POWER_USAGE{Hostname=~"gpu-node-.*"})[${BENCH_DURATION}:15s]
)

# Energía total GPU durante el sweep (mJ → convertir a J)
(
 sum(DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION{Hostname=~"gpu-node-.*"}) offset 0
 -
 sum(DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION{Hostname=~"gpu-node-.*"}) offset ${BENCH_DURATION}
) * 0.001

# Tokens generados durante el sweep (desde LiteLLM)
increase(
 litellm_request_total_tokens{model="llama3-70b-fp8", token_type="completion"}[${BENCH_DURATION}]
)

# Coste del namespace inference en la ventana (desde OpenCost API)
# → llamada REST al iniciar y al finalizar el Job, diferencia de accrual

La variable ${BENCH_DURATION} es la duración real del sweep (en formato Prometheus, ej. 22m), que el exporter calcula como end_ts - start_ts y sustituye en todas las queries.

El JSON de salida de cada corrida tiene esta estructura:

{
 "run_id": "20260616T1200",
 "metadata": {
 "model": "meta-llama/Meta-Llama-3-70B-Instruct",
 "engine": "vllm-0.9.1",
 "precision": "fp8",
 "hardware": "4xH100-SXM-80GB",
 "isl_tokens": 1024,
 "osl_tokens": 256,
 "tokenizer": "meta-llama-3-tokenizer-v3",
 "slo_ttft_p99_ms": 500,
 "slo_itl_p95_ms": 50,
 "bench_tool_guidellm": "0.4.2",
 "bench_tool_aiperf": "0.2.0",
 "dcgm_exporter": "3.3.9",
 "kepler": "0.10.2"
 },
 "performance": {
 "goodput_tok_s": 3120,
 "ttft_p99_ms": 487,
 "itl_p95_ms": 42,
 "throughput_peak_tok_s": 3890,
 "elbow_concurrency": 28
 },
 "cost": {
 "cpm_eur_1m": 0.97,
 "gpu_cost_eur_h": 10.8,
 "cost_window_eur": 3.24
 },
 "energy": {
 "wh_per_token": 0.00044,
 "j_per_token": 1.58,
 "power_mean_w": 4924,
 "energy_total_kwh": 0.287,
 "pue": 1.4,
 "wh_per_token_pue_adjusted": 0.000616
 },
 "carbon": {
 "grid_intensity_gco2_kwh": 40,
 "co2_per_1m_tokens_g": 24.6
 }
}

Todos los campos son calculados a partir de las mismas ventanas temporales. El JSON se versiona en git junto al código del harness. La reproducción de cualquier fila del scorecard es: git checkout <run-id> && kubectl apply -f job.yaml.

El scorecard de 3 ejes: tabla e interpretación

La siguiente tabla ilustra cómo se comparan cinco configuraciones del mismo modelo (Llama 3 70B) sobre el mismo nodo de referencia (4×H100 SXM) con el harness. Las cifras son ilustrativas de orden de magnitud (el banco las rellena con mediciones reales):

Config	Motor	Precisión	CPM (€/1M)	Goodput (tok/s)	Wh/tok	TTFT P99 (ms)	ITL P95 (ms)	CO2 /1M (g, FR)
A	vLLM 0.9	FP16	1,64	1.890	0,00074	498	49	29,6
B	vLLM 0.9	FP8	0,97	3.120	0,00044	487	42	17,6
C	SGLang 0.4	FP8	0,88	3.410	0,00041	421	38	16,4
D	vLLM 0.9	FP8, ISL 512	1,31	2.240	0,00056	294	31	22,4
E	vLLM 0.9	FP8, max-batch 128	0,84	3.590	0,00040	721	55	16,0

Cómo se lee la tabla:

B vs A: FP8 sobre FP16 reduce el CPM un 41 % y la energía por token un 41 % por el mismo throughput más alto. Ambos cumplen el SLO (TTFT P99 < 500 ms, ITL P95 < 50 ms). B domina a A en los tres ejes: es Pareto-superior.
C vs B: SGLang da goodput un 9 % mayor y CPM un 9 % menor con FP8. Ambos cumplen el SLO. C es Pareto-superior a B (si el motor es indiferente para el stack).
D vs B: ISL más corto (512 tok) baja la latencia (TTFT P99 294 ms vs 487 ms) pero baja el goodput y sube el CPM. Si el caso de uso exige TTFT < 300 ms, D es el candidato; si TTFT < 500 ms es suficiente, B es mejor en coste y energía.
E vs C: max-batch 128 sube el goodput (+5 %) y baja el CPM, pero el TTFT P99 rompe el SLO (721 ms > 500 ms) y el ITL P95 también (55 ms > 50 ms). E tiene el mejor throughput bruto pero está fuera del SLO: no es un candidato válido para el caso de uso de chat interactivo.

La frontera de Pareto del scorecard, bajo el SLO declarado, incluye solo A, B, C y D (E queda fuera por SLO roto). De esas cuatro, C domina a B que domina a A. D solo entra en la frontera si el caso de uso exige TTFT P99 < 300 ms. La decisión no es un número; es la fila entera más el SLO.

La frontera de Pareto multi-objetivo

Con tres métricas de minimización —CPM (€/1M tok), Wh/tok y TTFT P99 (ms)— la frontera de Pareto se define como el conjunto de configuraciones donde ninguna domina a otra en los tres ejes simultáneamente. Formalmente, la config $ i $ domina a la config $ j $ si:

$$\text{CPM}_i \leq \text{CPM}_j \;\land\; \text{Wh/tok}_i \leq \text{Wh/tok}_j \;\land\; \text{TTFT}_{i} \leq \text{TTFT}_{j}$$

con al menos una desigualdad estricta. El scorecard permite calcularla sobre el conjunto de corridas con una operación vectorial sencilla. En el ejemplo de la tabla, la frontera bajo SLO (con E excluido) es $\{C, D\}$: C domina en coste/energía/goodput; D domina en latencia. Entre C y D la elección depende del SLO de TTFT del caso de uso concreto.

Diseño reproducible: los doce metadatos obligatorios

El checklist que cierra el dossier de sesgo (Sesgo y reproducibilidad). Para que el JSON del harness sea auditable, los doce campos deben estar presentes en cada corrida:

#	Campo	Ejemplo	Por qué es obligatorio
1	Versión del motor de serving	`vllm-0.9.1`	el mismo modelo puede rendir diferente en distintas versiones
2	Versión del modelo (commit/tag)	`meta-llama/Meta-Llama-3-70B-Instruct@sha256:abc`	evita ambigüedad entre variantes del mismo nombre
3	Precisión	`fp8`	FP16 vs FP8 cambia throughput y latencia
4	Tokenizador y versión	`meta-llama-3-tokenizer-v3`	el ISL/OSL en tokens depende del tokenizador
5	ISL (input sequence length)	`1024` tok	cambia el tiempo de prefill y el codo
6	OSL (output sequence length)	`256` tok	cambia el tiempo de decode
7	Hardware (modelo y cantidad)	`4×H100-SXM-80GB`	base de cualquier comparación
8	Concurrencia máxima probada	`32`	define el rango del sweep
9	Versión de la herramienta de bench	`guidellm-0.4.2`, `aiperf-0.2.0`	distintas versiones pueden dar métricas distintas
10	SLO declarado	`TTFT P99 < 500 ms, ITL P95 < 50 ms`	el codo depende del SLO; sin él no hay goodput
11	Duración de warmup	`60 s`	sin warmup el KV cache está frío y las primeras rondas son sesgadas
12	Versión del harness / run-id	`20260616T1200`	identifica la corrida para reproducirla con `git checkout`

Un scorecard sin cualquiera de estos doce campos es una anécdota. Con los doce, es un dato auditable. El run-id en el nombre del Job (bench-llama3-70b-fp8-h100x4-20260616) incorpora implícitamente los campos 1-3 y 7, forzando que el nombre del Job cambie con cada variante — lo que hace imposible solapar corridas en el mismo namespace.

Idempotencia y versionado de resultados

El Job de Kubernetes es idempotente: si se vuelve a aplicar el mismo manifiesto (mismo nombre), el Job ya existe y Kubernetes no lo relanza (política backoffLimit: 0). Esto evita corridas accidentales duplicadas. Para relanzar, hay que borrar el Job (kubectl delete job <nombre>) o cambiar el run-id.

Los resultados se versionan con la siguiente convención de directorios en el repositorio git del harness:

results/
20260616T1200/
guidellm-20260616T1200.json
aiperf-20260616T1200.json
scorecard-20260616T1200.json
20260617T0900/
guidellm-20260617T0900.json
aiperf-20260617T0900.json
scorecard-20260617T0900.json
scorecard-aggregate.csv # todas las filas, para análisis y gráficas

El scorecard-aggregate.csv es la tabla del scorecard en formato plano: cada fila es una corrida, cada columna un campo del JSON. Se genera con:

# Genera el CSV agregado a partir de todos los JSON en results/
python scripts/aggregate_scorecards.py results/ > scorecard-aggregate.csv

El CSV es lo que entra en las gráficas de Pareto, en los informes y en las decisiones de arquitectura. Está versionado en git; su diff es el cambio de configuración.

Cómo se conecta con los otros posts de la serie

El harness no es un artículo autónomo: es la síntesis de los veintiocho artículos. Cada herramienta tiene su deep dive:

Rendimiento: GuideLLM a fondo — sweep, SLO, goodput, codo; GenAI-Perf / AIPerf a fondo — concurrencia, rate sweep, métricas de distribución.
Coste: OpenCost: cost allocation en Kubernetes — asignación por namespace/label, precios custom on-prem.
Energía: Herramientas de energía: deploy, precisión y overhead — DCGM vs Kepler vs Zeus, overhead de instrumentación, precisión relativa; MLPerf Power: eficiencia energética — la referencia externa de calibración.
Marco teórico: Los tres ejes: coste, rendimiento y energía — la identidad CPM/energía/throughput que justifica medir juntos.
Sesgo: Sesgo y reproducibilidad en el benchmarking — los doce sesgos que el harness elimina.

El harness cierra el dossier de la serie porque hace posible la promesa del artículo de apertura: “cuando alguien rebata un número de la propuesta, la respuesta no es ’lo dice un blog’, sino ’este es el banco, esta la metodología, reprodúcelo’”. Con el run-id y el repo git, reproducir es un comando.

Flujo completo de una sesión de benchmarking

El procedimiento operativo estándar del harness, de principio a fin:

# 1. Asegurarse de que el endpoint de inferencia está activo
kubectl get svc vllm-svc -n inference

# 2. Verificar que DCGM y Kepler están scrapeando
curl -s http://prometheus.monitoring.svc.cluster.local:9090/api/v1/query \
 --data-urlencode 'query=DCGM_FI_DEV_POWER_USAGE' | jq '.data.result | length'

# 3. Registrar el counter de energía ANTES del experimento
PRE_ENERGY=$(kubectl exec -n monitoring dcgm-exporter-xxx -- \
 curl -s localhost:9400/metrics \
 | grep DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION | awk '{sum+=$2} END{print sum}')

# 4. Lanzar el Job (nombre único por corrida)
kubectl apply -f jobs/bench-llama3-70b-fp8-h100x4-20260616.yaml

# 5. Esperar a que termine
kubectl wait --for=condition=complete job/bench-llama3-70b-fp8-h100x4-20260616 \
 -n benchmark --timeout=3600s

# 6. Registrar el counter de energía DESPUÉS
POST_ENERGY=$(kubectl exec -n monitoring dcgm-exporter-xxx -- \
 curl -s localhost:9400/metrics \
 | grep DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION | awk '{sum+=$2} END{print sum}')

# 7. Recoger los resultados del volumen
kubectl cp benchmark/bench-run-pod:/results/ ./results/20260616T1200/

# 8. Calcular la energía del experimento (mJ → kWh)
python scripts/calc_energy.py \
 --pre $PRE_ENERGY --post $POST_ENERGY \
 --run-id 20260616T1200

# 9. Añadir fila al CSV agregado
python scripts/aggregate_scorecards.py results/ > scorecard-aggregate.csv

# 10. Versionar
git add results/20260616T1200/ scorecard-aggregate.csv
git commit -m "bench: llama3-70b fp8 4xH100 ISL1024 OSL256 (20260616T1200)"

Los pasos 6-9 son candidatos a automatizarse como un segundo Job de post-procesado que se lanza al completarse el principal (con ownerReferences o un CronJob de limpieza). En el estado básico del harness, los pasos manuales son precisamente los que fuerzan la revisión del resultado antes de versionarlo.

Coste del experimento

Un sweep de GuideLLM de 10 rondas a 120 segundos por ronda ocupa el nodo ~22-26 minutos. El perfil de AIPerf a 4 concurrencias (200 peticiones cada una) añade ~8-12 minutos. Total por corrida: ~35-40 minutos de nodo 4×H100.

A coste amortizado de referencia (~10,8 €/h para 4×H100 on-prem):

$$\text{coste por corrida} \approx 10{,}8 \times \frac{38}{60} \approx 6{,}84 \text{ EUR}$$

A precio cloud europeo de referencia (4 × 2,73 = 10,92 €/h):

$$\text{coste por corrida (cloud)} \approx 10{,}92 \times \frac{38}{60} \approx 6{,}92 \text{ EUR}$$

Un programa de benchmarking continuo (10 configuraciones × 3 modelos × 2 sweeps/semana) suma ~415 EUR/semana. Por eso el harness incluye sweeps cortos (5 rondas, ~15 minutos) para CI y sweeps completos para releases.

Lo que el harness no mide (y por qué)

Dimensión ausente	Motivo	Dónde se cubre
Calidad del output (MMLU, HumanEval)	requiere banco de evaluación de calidad, no de serving	Benchmarks de calidad LLM
Throughput de training	el harness es exclusivamente para inferencia	fuera del scope de la serie “datos”
Coste de red y almacenamiento	OpenCost puede atribuirlo, pero requiere configuración adicional	OpenCost: cost allocation
Intensidad de carbono horaria	usar ElectricityMaps API + la energía medida	Del vatio al carbono: PUE y mix de red
Latencia de red cliente-servidor	el Job corre dentro del cluster; latencia WAN requiere cliente externo	documentar como metadato adicional

Fuentes

GuideLLM · GitHub (proyecto vLLM) — https://github.com/vllm-project/guidellm
GuideLLM · PyPI — https://pypi.org/project/guidellm/
Red Hat Developer · desplegar y benchmarkear vLLM con GuideLLM en Kubernetes — https://developers.redhat.com/articles/2025/12/24/how-deploy-and-benchmark-vllm-guidellm-kubernetes
Red Hat Developer · GuideLLM: evaluar despliegues LLM para inferencia real — https://developers.redhat.com/articles/2025/06/20/guidellm-evaluate-llm-deployments-real-world-inference
AIPerf · GitHub (ai-dynamo/aiperf) — https://github.com/ai-dynamo/aiperf
GenAI-Perf · documentación NVIDIA Triton — https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/perf_analyzer/genai-perf/README.html
NVIDIA · LLM performance benchmarking con GenAI-Perf — https://developer.nvidia.com/blog/llm-performance-benchmarking-measuring-nvidia-nim-performance-with-genai-perf
NVIDIA NIM Benchmarking · métricas (TTFT, ITL, throughput) — https://docs.nvidia.com/nim/benchmarking/llm/latest/metrics.html
OpenCost · web oficial — https://opencost.io/
OpenCost · GitHub (opencost/opencost) — https://github.com/opencost/opencost
OpenCost · CNCF blog (sandbox → incubating) — https://www.cncf.io/blog/2022/12/06/opencost-a-new-cncf-sandbox-project-for-real-time-kubernetes-cost-monitoring/
LiteLLM · web oficial — https://www.litellm.ai/
LiteLLM · GitHub (BerriAI/litellm) — https://github.com/BerriAI/litellm
LiteLLM · Spend Tracking docs — https://docs.litellm.ai/docs/proxy/cost_tracking
NVIDIA DCGM Exporter · documentación oficial — https://docs.nvidia.com/datacenter/dcgm/latest/gpu-telemetry/dcgm-exporter.html
NVIDIA DCGM Exporter · GitHub — https://github.com/NVIDIA/dcgm-exporter
NVIDIA DCGM Exporter · métricas CSV — https://github.com/NVIDIA/dcgm-exporter/blob/main/etc/dcp-metrics-included.csv
Kepler (Kubernetes-based Efficient Power Level Exporter) · GitHub — https://github.com/sustainable-computing-io/kepler
Red Hat Emerging Technologies · Introducing Kepler — https://next.redhat.com/2023/08/22/introducing-kepler-efficient-power-monitoring-for-kubernetes/
MLCommons · MLPerf Inference Datacenter benchmark — https://mlcommons.org/benchmarks/inference-datacenter/
MLCommons · MLPerf Power presentado en IEEE HPCA 2025 — https://mlcommons.org/2025/03/ml-commons-power-hpca/
IEEE Xplore · MLPerf Power paper (μWatts to MWatts) — https://ieeexplore.ieee.org/document/10946778/
MLCommons · MLPerf Inference v5.1 results (septiembre 2025) — https://mlcommons.org/2025/09/mlperf-inference-v5-1-results/
Red Hat · Efficient and reproducible LLM inference: MLPerf Inference v5.1 — https://www.redhat.com/en/blog/efficient-and-reproducible-llm-inference-red-hat-mlperf-inference-v51-results
BentoML · Beyond tokens-per-second: cost, speed and quality in LLM inference — https://www.bentoml.com/blog/beyond-tokens-per-second-how-to-balance-speed-cost-and-quality-in-llm-inference

GuideLLM a fondo: validar el SLO bajo carga y dimensionar desde el codo

Sun, 14 Jun 2026 04:30: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

Tercer artículo del track de benchmarking (B3). En B2 se vio el catálogo de herramientas; aquí entramos en GuideLLM a fondo, porque es la que responde la pregunta operativa que dimensiona una plataforma: ¿hasta dónde puedo cargar este motor sin romper el SLO? No es un benchmark de catálogo (“X tokens/s”), es un sweep dirigido por SLO que encuentra el codo —la capacidad segura— y del que sale el número de réplicas y el coste por token reales. Veremos sus modos de carga, cómo se define el SLO, cómo se lee la salida y cómo se convierte el codo en sizing y en euros. Con comandos reales; sin recomendaciones, solo la mecánica.

Por qué GuideLLM

GuideLLM (proyecto vLLM) genera patrones de tráfico realistas y configurables y captura distribuciones completas de TTFT, ITL y comportamiento de extremo a extremo, para evaluación dirigida por SLO, con sweeps reproducibles que identifican el rango de operación seguro (Red Hat). A diferencia de un micro-bench, mide el motor, no el cliente (carga multi-proceso), y a diferencia de MLPerf, dimensiona tu caso concreto (tu modelo, tu SLO, tu carga). Es la herramienta del medio: ni para tunear un flag, ni para comparar fabricantes, sino para decidir cuántas GPUs necesitas.

Los modos de carga (rate-types)

GuideLLM ofrece varios modos a través de --rate-type, y elegir el correcto es la mitad del trabajo:

`--rate-type`	Qué hace	Cuándo
synchronous	una petición cada vez	latencia base, sin concurrencia
concurrent	mantiene N peticiones simultáneas fijas	medir a una concurrencia concreta
poisson	peticiones por segundo según Poisson	simular tráfico real (llegadas aleatorias)
throughput	satura el motor al máximo	capacidad bruta máxima
sweep	barrido automático de idle a máximo	hallar el codo (el más útil)

En modo concurrent, el --rate "1,2,4" lanza tres benchmarks a esas concurrencias (Medium · GuideLLM en OpenShift). El modo poisson es el más realista para inferencia online (las peticiones no llegan a intervalos regulares), y el sweep es el que automatiza la búsqueda del punto de saturación.

El sweep automático: de idle al codo

El modo estrella. Al correr un perfil de sweep, GuideLLM incrementa automáticamente la tasa de petición desde idle hasta el máximo throughput a lo largo de 10 rondas, y produce un informe HTML interactivo con latencia y throughput detallados (Red Hat · GuideLLM en Kubernetes). Durante el sweep, al detectar la saturación identifica la iteración anterior —el codo— y la devuelve como capacidad estimada; si no detecta saturación, hay que extender el sweep más allá del codo.

Ejemplo trabajado: leer un sweep de 10 rondas

Una salida ilustrativa de un sweep sobre un 70B en 8×H100 (SLO: TTFT P99 < 500 ms), por ronda:

Ronda	Tasa (req/s)	TTFT P99 (ms)	ITL P50 (ms)	Throughput (tok/s)	Goodput (tok/s)
1	2	95	19	480	480
3	8	140	20	1.900	1.900
5	14	240	22	3.100	3.060
6	17	460	24	3.400	3.330
7	20	760	31	3.700	2.520
9	26	1.500	48	3.950	900
10	30	2.400	71	4.000	380

Cómo se lee: hasta la ronda 6 (17 req/s) el TTFT P99 cumple el SLO (460 ms) y el goodput ≈ throughput (3.330 ≈ 3.400). En la ronda 7 el P99 ya rompe (760 ms) y el goodput cae a 2.520. El codo está entre la 6 y la 7: la capacidad segura es la de la ronda 6, ~3.330 tok/s de goodput. Las rondas 9 y 10 dan más throughput bruto (3.950, 4.000) pero con goodput de 900 y 380 —el sistema “rinde” sirviendo sobre todo peticiones que incumplen—. Quien reporte “4.000 tok/s” describe la ronda 10, donde el sistema está roto. El número defendible es 3.330 tok/s bajo TTFT P99 < 500 ms, y ese es el que entra en el sizing. Fíjate también en que el sweep tuvo que llegar hasta la ronda 10 (P99 de 2.400 ms) para ver dónde rompía: por eso hay que extenderlo más allá del codo.

Definir el SLO: el número que decide el codo

El “codo” no es absoluto: depende del SLO que definas. Un SLO típico de inferencia online:

Métrica	Umbral de ejemplo	Qué protege
TTFT P99	< 500 ms	la espera al primer token (interactividad)
TPOT / ITL P95	< 50 ms/token	la “velocidad de tecleo” percibida
Tasa de error	< 0,1 %	fiabilidad

El goodput —el throughput que cumple ese SLO— es la métrica que define el codo: la capacidad segura es la máxima carga donde el goodput ≈ throughput. Cambiar el SLO mueve el codo: un SLO de TTFT más estricto (200 ms) da un codo más temprano (menos capacidad segura) que uno laxo (1 s). Por eso el SLO se fija antes del sweep, y se reporta junto al resultado: una capacidad “de 3.330 tok/s” sin decir bajo qué SLO no significa nada.

Ejecución: el comando

Un sweep dirigido por SLO contra un endpoint vLLM:

guidellm benchmark \
 --target "http://vllm:8000" \
 --rate-type sweep \
 --max-seconds 120 \
 --data "prompt_tokens=1024,output_tokens=256" \
 --output-path resultados.json

Parámetros clave: --rate-type sweep (el barrido automático), --data (la distribución de longitudes de la carga, que debe parecerse a tu tráfico real), --max-seconds (duración por ronda), --target (el endpoint). Para el SLO, GuideLLM permite definir las restricciones de latencia que marcan el goodput. La salida va a --output-path en JSON, YAML o CSV, además del informe HTML interactivo.

Definir la carga: el `--data` decide el resultado

El parámetro --data (la distribución de longitudes de prompt y salida) cambia el codo tanto como el SLO. Tres formas, de menos a más fiel:

Carga	`--data`	Fidelidad
Longitud fija	`prompt_tokens=1024,output_tokens=256`	baja: el tráfico real no es fijo
Distribución sintética	rangos de longitud	media
Trazas reales	dataset de tu tráfico	alta: el codo que aplica

La trampa: un sweep con prompts cortos de longitud fija da un codo optimista que no se parece a producción, donde los prompts largos dominan el coste de prefill y adelantan el codo. Para dimensionar de verdad, alimenta GuideLLM con la distribución real de tu tráfico (longitudes de prompt y salida medidas en producción). El codo de un sweep solo es tan realista como la carga que le metes; con --data irreal, dimensionas para un tráfico que no existe.

Además, el perfil de llegada importa: --rate-type poisson simula llegadas aleatorias (como el tráfico real online), mientras que concurrent mantiene N fijas (como un batch). Un servicio online medido con concurrent puede dar un codo distinto al real; para inferencia interactiva, poisson es el perfil honesto.

La salida: qué leer

GuideLLM produce reportes estandarizados y exportables para dashboards, análisis y seguimiento de regresiones, en JSON, YAML y CSV (Red Hat). Lo que importa leer, por ronda del sweep:

TTFT (P50, P95, P99) — la latencia al primer token.
ITL/TPOT (P50, P95, P99) — entre tokens.
Throughput (req/s y tok/s) — el bruto.
Goodput — el que cumple el SLO (el número honesto).

El informe HTML interactivo permite ver las distribuciones completas (no solo medias), que es donde se ve la cola de latencia que una media oculta. Para el sizing y la comparación, el JSON es lo que se versiona y se mete en el harness reproducible.

Del codo al sizing y al coste

Aquí GuideLLM se conecta con el resto de la serie. Del codo sale el número de réplicas y el coste por token:

El cálculo: si el codo da un goodput de 3.330 tok/s por réplica y tu carga objetivo en pico es de 20.000 tok/s, necesitas 6 réplicas (20.000 ÷ 3.330 ≈ 6,0). Y el coste por token sale del coste de la réplica (de OpenCost, ~11 €/h) dividido por su goodput: ~0,92 €/1M tokens. Es el puente con el capacity planning y con el coste por token: el denominador correcto es el goodput del codo, no el throughput de catálogo. Dimensionar con el throughput bruto te deja corto de capacidad útil y rompe el SLO en producción.

Despliegue como Job de Kubernetes

GuideLLM se ejecuta como un Job de Kubernetes dentro del cluster para benchmarkear modelos servidos por la plataforma de orquestación (Red Hat). Esto es importante para la fidelidad: el generador de carga corre dentro del cluster, en la misma red que el endpoint, así que mide el motor sin la latencia de red de un cliente externo. El Job se parametriza con el target, el rate-type y la carga, y vuelca el JSON a un volumen o a un almacén para versionarlo. Correrlo como Job también facilita la automatización (CronJob para benchmarking periódico, o disparado por CI).

Validación de SLO en CI: detectar regresiones

El uso más valioso a medio plazo: un Job que corre un sweep corto en cada cambio (release de vLLM, cambio de config) y compara el goodput con la línea base. Si el goodput cae más de un umbral o el codo se adelanta, falla el pipeline. Como GuideLLM exporta JSON estandarizado para seguimiento de regresiones, comparar dos corridas es trivial. Así una regresión de rendimiento —que es una regresión de coste y de capacidad— se detecta en el commit, no en producción. No hace falta el sweep completo en cada commit: un sweep corto que cubra el codo basta para detectar la regresión; el exhaustivo, para los releases.

Comparar configuraciones con sweeps

GuideLLM brilla para decidir entre configuraciones corriendo el mismo sweep contra cada una. El protocolo justo: misma carga (--data), mismo SLO, mismo hardware, variar solo la config. Ejemplos de decisión que un sweep resuelve con datos:

Decisión	Qué comparar	Qué revela el codo
FP16 vs FP8	dos despliegues del mismo modelo	FP8 suele dar codo más alto (más goodput)
`max-num-seqs`	distintos valores del flag	el que maximiza goodput bajo SLO
vLLM vs SGLang	dos motores, mismo modelo	qué motor da más goodput a tu SLO
tamaño de KV/precisión	configs de KV cache	el efecto en la capacidad

Cada sweep da un codo; el codo más alto bajo el mismo SLO gana. Es el experimento controlado que llena la fila del cuadro de mando (artículo B8): no “X es más rápido” en abstracto, sino “X da Y tok/s de goodput más bajo este SLO concreto, lo que se traduce en Z réplicas menos y W € menos por millón de tokens”.

Observar los tres ejes durante el sweep

Un truco que conecta con el track de coste y energía: mientras corre el sweep, captura las métricas de GPU con DCGM. Así, de cada ronda sacas a la vez el goodput (GuideLLM), la potencia media (DCGM → J/token) y el coste (precio del nodo → €/token). En una sola campaña de sweep mides los tres ejes del cuadro de mando para cada punto de operación, y quedan coherentes por construcción (mismo instante, misma carga). En vez de un benchmark de rendimiento aislado, obtienes la fila completa —coste, rendimiento, energía— del codo, que es justo lo que la propuesta necesita. Alinea las ventanas temporales (la potencia de DCGM y las métricas de GuideLLM deben cubrir el mismo intervalo) o el J/token no corresponde al goodput medido.

Interpretar las distribuciones, no solo el codo

El codo es el titular, pero el informe HTML de GuideLLM da distribuciones completas, y ahí hay información que el codo resume. Tres lecturas adicionales:

La forma de la cola. Dos configs con el mismo P99 pueden tener colas distintas: una con P99 a 500 ms y P99,9 a 600 ms es estable; otra con P99 a 500 ms y P99,9 a 3.000 ms tiene una cola larga que afectará a algunos usuarios de forma severa. La media y hasta el P99 lo ocultan; la distribución lo enseña.
La separación TTFT/ITL. Ver las dos distribuciones por separado dice si el cuello es el prefill (TTFT alto) o el decode (ITL alto), lo que orienta la optimización (más concurrencia vs chunked prefill, etc.).
La dispersión entre rondas. Si el goodput varía mucho entre rondas a la misma tasa, el sistema es inestable bajo carga —algo que un único número de capacidad no revela—.

El codo dimensiona; las distribuciones diagnostican. Para una propuesta, el codo es el dato; para operar y optimizar, las distribuciones son donde se ve qué arreglar.

GuideLLM en el harness reproducible

GuideLLM encaja como el motor de carga del harness reproducible (artículo S4). El patrón:

Un script/Job que despliega el motor con la config pineada, calienta, corre el sweep y vuelca el JSON con todos los metadatos (modelo, versión, hardware, --data, SLO).
Nombrado por fecha y config para versionar las corridas.
Almacén (repo git de JSONs o bucket) para reproducir y comparar.
DCGM capturando en paralelo para añadir la energía a cada punto.

Así, “reproducir el codo de esta config” es un comando, no una tarde, y comparar dos releases es un diff de JSON. Es lo que convierte el benchmarking de una actividad puntual en una capacidad continua —y lo que permite que la cifra de capacidad de la propuesta venga con el banco para reproducirla.

El coste de un sweep (en euros)

Un sweep de 10 rondas a ~2 minutos por ronda ocupa el nodo ~20–30 minutos. A coste amortizado de ~11 €/h, son ~4–5,5 € por sweep completo de un modelo. No es mucho por corrida, pero un programa de benchmarking continuo (cada release, cada config, varios modelos) suma; por eso conviene automatizar el sweep como Job reproducible y correr sweeps cortos en CI (solo alrededor del codo) reservando el exhaustivo para los releases. El coste de medir es parte del coste de la plataforma —y pequeño frente al de dimensionar mal—.

El SLO por caso de uso: el codo se mueve con él

Como el SLO define el codo, distintos casos de uso dan capacidades distintas sobre el mismo hardware. Conviene tenerlo presente al dimensionar:

Caso de uso	SLO típico	Efecto en el codo
Chat interactivo	TTFT P99 < 500 ms, ITL < 50 ms	codo temprano (latencia manda)
Copilot de código	TTFT P99 < 300 ms	codo aún más temprano
Batch / resúmenes	sin SLO de TTFT, maximizar throughput	codo tardío (casi throughput puro)
Agente (multi-paso)	latencia por paso acotada	depende del nº de pasos

La misma GPU sirve más carga de batch que de chat interactivo, porque el SLO de batch es laxo. Por eso dimensionar requiere un sweep por perfil de carga: no hay “la capacidad del nodo”, hay “la capacidad del nodo para este SLO”. Mezclar cargas con SLOs distintos en el mismo pool sin separarlas es una fuente clásica de SLOs rotos —el batch satura y el chat interactivo lo paga—. La solución conecta con el scheduling: separar pools o prioridades por SLO.

GuideLLM vs los otros: cuándo usar cuál

Para situarlo frente a las herramientas de B2:

Pregunta	Herramienta	Por qué
“¿Hasta dónde cargo sin romper el SLO?”	GuideLLM	sweep dirigido por SLO, el codo
“¿Cuál es la capacidad máxima del endpoint?”	AIPerf	detección automática de saturación
“¿Mejora mi cambio de flag en vLLM?”	vllm bench serve	rápido, propio del motor
“¿Qué hardware/motor es mejor en abstracto?”	leer MLPerf	comparabilidad cross-vendor

GuideLLM es la herramienta del dimensionamiento bajo SLO: cuando la pregunta es operativa (cuántas réplicas, qué coste por token a mi SLO), es la respuesta más directa. AIPerf y GuideLLM se solapan (ambos multi-proceso); la diferencia práctica es que GuideLLM está más orientado al SLO y al informe reproducible, y AIPerf a la capacidad máxima con detección automática. Muchos equipos usan los dos; lo que no se debe es comparar un resultado de uno con el de otro como si fueran la misma medida.

Checklist de un sweep defendible

Para que el codo de un sweep sostenga una decisión de sizing:

Paso	Verificación
Carga realista	`--data` con la distribución de tu tráfico (o poisson)
SLO declarado	TTFT/TPOT con percentil y umbral fijados
Sweep extendido	llega hasta que el P99 rompe (pasa el codo)
Goodput, no throughput	la capacidad es el goodput bajo SLO
Job en el cluster	sin latencia de red de cliente externo
Salida versionada	JSON con todos los metadatos
DCGM en paralelo	energía por punto, opcional pero recomendado

Si puedes marcar las siete casillas, el codo es un dato auditable; si falta cualquiera, es una anécdota. El sizing de la propuesta cuelga de que estas siete estén verdes.

Límites y trampas (data-driven)

No extender el sweep más allá del codo. Si no detecta saturación, la capacidad estimada es la última ronda probada, no el codo real. Extiéndelo hasta que el P99 rompa.
Carga irreal. Un --data de longitudes fijas no se parece a tu tráfico; usa la distribución real (o poisson) para un codo que aplique.
Reportar throughput, no goodput. El codo se define por el goodput bajo SLO; el throughput bruto sobreestima la capacidad.
SLO no declarado. Una capacidad sin el SLO bajo el que se midió no es comparable ni defendible.
Cliente fuera del cluster. Correr GuideLLM desde fuera mete latencia de red en la medida; córrelo como Job dentro del cluster.

Con GuideLLM dominado, tienes la herramienta que convierte el rendimiento en un dato accionable: el codo, el sizing y el coste por token, todo de un sweep reproducible. El siguiente artículo (B4) entra en AIPerf de NVIDIA; este cierra la validación de SLO, que es la que dimensiona la propuesta.

Cierre

GuideLLM responde la única pregunta de rendimiento que dimensiona una plataforma: ¿hasta dónde cargo sin romper el SLO? Y la responde con la disciplina correcta —un sweep de idle a saturación que halla el codo, definido por el goodput bajo un SLO declarado, sobre una carga que se parece a la real—. De ese codo sale todo lo que la propuesta necesita: el número de réplicas, el coste por token (con el goodput como denominador, no el throughput de catálogo) y, si capturas DCGM durante el sweep, también la energía por token. El error que invalida el ejercicio es el de siempre: reportar el throughput máximo en vez del goodput, medir con una carga irreal, o no extender el sweep hasta ver dónde rompe. Hecho bien —como Job dentro del cluster, con la distribución real, el SLO fijado y la salida en JSON versionado— GuideLLM convierte el rendimiento de una cifra de marketing en un dato reproducible que aguanta una auditoría y dimensiona una arquitectura soberana con números. El codo no es el punto más rápido; es el punto donde tu plataforma sigue cumpliendo lo que prometió.

Ver también

GenAI-Perf a fondo — el perfilador de NVIDIA y cómo se compara con GuideLLM ficha a ficha (rate-types, sweep de concurrencia, métricas).
Comparativa de motores de serving (vLLM/SGLang/TRT-LLM/Dynamo) — tras validar los SLOs con GuideLLM, esta comparativa decide qué motor cumple la frontera de Pareto goodput-latencia.
Sesgo de medición y reproducibilidad — los errores de setup que hacen que un sweep de concurrencia resulte no reproducible, aunque la herramienta esté bien configurada.

Fuentes

Red Hat · GuideLLM: evaluar despliegues LLM para inferencia real — https://developers.redhat.com/articles/2025/06/20/guidellm-evaluate-llm-deployments-real-world-inference
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 · PyPI — https://pypi.org/project/guidellm/
GuideLLM · GitHub (proyecto vLLM) — https://github.com/vllm-project/guidellm
Medium · GuideLLM en OpenShift (rate-types, ejemplo) — https://medium.com/@jajodia.nirjhar/exploring-guidellm-benchmarking-a-live-llm-on-openshift-ccc2d0841794

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

Guidellm on lo0 — Blog Técnico

El harness reproducible: medir coste, rendimiento y energía en un solo experimento auditable

TL;DR

Por qué los tres ejes deben medirse juntos

Arquitectura del banco integrado

El Job de Kubernetes: YAML completo

Capa de rendimiento: GuideLLM y AIPerf

GuideLLM — el sweep dirigido por SLO

AIPerf — el perfilador de concurrencia de NVIDIA

Capa de coste: OpenCost y LiteLLM

OpenCost — el denominador en euros por GPU-hora

LiteLLM — el token counter por petición

Capa de energía: DCGM y Kepler

DCGM Exporter — potencia y energía GPU

Kepler — energía a nivel de pod

Referencia MLPerf Power

Unificación de métricas: las queries PromQL

El scorecard de 3 ejes: tabla e interpretación

La frontera de Pareto multi-objetivo

Diseño reproducible: los doce metadatos obligatorios

Idempotencia y versionado de resultados

Cómo se conecta con los otros posts de la serie

Flujo completo de una sesión de benchmarking

Coste del experimento

Lo que el harness no mide (y por qué)

Fuentes

GuideLLM a fondo: validar el SLO bajo carga y dimensionar desde el codo

Qué cubre este artículo

Por qué GuideLLM

Los modos de carga (rate-types)

El sweep automático: de idle al codo

Ejemplo trabajado: leer un sweep de 10 rondas

Definir el SLO: el número que decide el codo

Ejecución: el comando

Definir la carga: el --data decide el resultado

La salida: qué leer

Del codo al sizing y al coste

Despliegue como Job de Kubernetes

Validación de SLO en CI: detectar regresiones

Comparar configuraciones con sweeps

Observar los tres ejes durante el sweep

Interpretar las distribuciones, no solo el codo

GuideLLM en el harness reproducible

El coste de un sweep (en euros)

El SLO por caso de uso: el codo se mueve con él

GuideLLM vs los otros: cuándo usar cuál

Checklist de un sweep defendible

Límites y trampas (data-driven)

Cierre

Ver también

Fuentes

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

Qué cubre este artículo

Cómo elegir: el mapa de herramientas

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

vLLM bench serve

SGLang bench

AIPerf (NVIDIA, ex genai-perf)

GuideLLM (proyecto vLLM)

LLMPerf (Anyscale/Ray)

inference-benchmarker (Hugging Face)

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

MLPerf Inference (MLCommons)

Tabla comparativa práctica

Resumen: qué ejecutas para cada pregunta

Metodología paso a paso de un benchmark

Comparar dos motores: el protocolo justo

Formato de salida y comparabilidad

Ejemplo trabajado: leer la salida de un sweep

Automatizar el harness

Integración en CI: benchmarking continuo

El coste de medir (en euros)

Observar durante el benchmark: una corrida, tres ejes

El benchmark es también FinOps y energía

Estado del arte 2026 y límites

Errores que invalidan un benchmark

Cierre

Ver también

Fuentes

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

Definir la carga: el `--data` decide el resultado