Reproducibilidad 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

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

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

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

TL;DR

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

Las fuentes de sesgo: catálogo con magnitudes

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

Fuente de sesgo	Dirección del sesgo	Magnitud documentada	Referencia
Saturación del cliente mono-proceso (GIL Python, asyncio)	infravalora throughput; sobrevalora latencia	hasta 7,2× menos tokens procesados a 1.000 QPS	arXiv 2605.24217
Tokenizer distinto al del modelo (LLMPerf usa LlamaTokenizer universal)	tok/s incomparables entre vocabularios distintos	variable; hasta 33 % de overhead de overhead de cliente en denominador del TPS	NVIDIA blog (TPS = overhead de cliente ÷ duración total)
ignore_eos ausente u OSL inconsistente	subestima throughput; acorta artificialmente OSL real	hasta terminación prematura; benchmark de longitud fija irreal	docs vLLM bench; NVIDIA fundamental concepts
Distribución ISL/OSL irreal (longitud fija en vez de distribución realista)	codo optimista que no se parece a producción	desplazamiento del codo; prefill infravalorado con prompts cortos	docs AIPerf sequence-length-distributions
Warmup ausente / prefix-cache caliente	sobrevalora TTFT (artificialmente bajo en las primeras peticiones)	TTFT infra-estimado por KV-cache ya poblado	vLLM prefix caching docs; arXiv 2605.24217
`concurrency` vs `request-rate` como modo de carga	concurrency satura simétricamente; request-rate puede acumular cola	ITL sobreestimado si la cola crece sin techo con request-rate	NVIDIA fundamentals; AIPerf docs
Ventana de medición demasiado corta	no capta el régimen estacionario; incluye ramp-up	throughput sobre-estimado; latencia subestimada	meta-métricas arXiv 2508.10251
Estado térmico y frecuencias de GPU	throttling térmico reduce throughput si no hay estabilización previa	temperatura > 75 °C dispara throttling; diferencia de ~3 W de potencia estable	arXiv 2604.09048
Prefix-cache caliente entre corridas	sobrevalora TTFT; TTFT irreal si el cache está pre-poblado de la corrida anterior	efecto severo en evaluaciones multi-prompt con prefijos compartidos	arXiv 2605.24217
Media en vez de percentiles	oculta la cola de latencia	P99 puede ser 4–6× la mediana a alta concurrencia	NVIDIA fundamentals; Anyscale docs

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

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

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

La discrepancia documentada a 1.000 QPS:

Arquitectura de cliente	Tokens procesados a 1.000 QPS	Ratio
Mono-proceso (asyncio, Python GIL)	75.574	1× (base)
Multi-proceso (carga distribuida)	545.733	7,2×

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

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

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

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

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

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

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

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

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

El sesgo de ignore_eos y OSL inconsistente

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

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

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

El sesgo de la distribución ISL/OSL

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

Los casos de uso reales tienen distribuciones muy distintas:

Caso de uso	ISL típico (tokens)	OSL típico (tokens)	Domina
Traducción	500–2.000	500–2.000	equilibrado
Generación (código, email)	~100	~1.000	decode (OSL largo)
Resumen / RAG	~1.000	~100	prefill (ISL largo)
Razonamiento (CoT)	~100	1.000–10.000	decode muy largo

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

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

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

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

El sesgo del warmup y el prefix-cache

Dos fuentes de sesgo relacionadas pero distintas:

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

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

El sesgo de `concurrency` vs `request-rate`

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

Modo	Semántica	Cuándo usar	Riesgo
concurrency N	mantiene exactamente N peticiones en vuelo; en cuanto termina una, lanza otra	medir el sistema bajo una carga de concurrencia fija	sobrerepresenta la carga sostenida; no simula llegadas reales
request-rate r (constante o Poisson)	lanza una petición cada (1/r) segundos (constante) o con interarrival (\sim \text{Exp}(1/r)) (Poisson)	simular tráfico real (llegadas aleatorias)	si el motor no puede absorber r req/s, la cola crece sin techo

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

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

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

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

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

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

Cómo las herramientas calculan diferente la ITL

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

GenAI-Perf / AIPerf:

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

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

LLMPerf (archivado dic. 2025):

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

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

vLLM bench (benchmark_serving.py):

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

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

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

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

Dimensión	vLLM bench	LLMPerf (archivado)	GenAI-Perf / AIPerf	GuideLLM
Arquitectura cliente	mono-proceso asyncio	mono-proceso	multi-proceso	multi-proceso
ITL incluye TTFT	no	sí	no	no
TPS denominador	(T_y - T_x)	(T_{\text{end}} - T_{\text{start}}) (overhead incluido)	(T_y - T_x)	por ronda
Tokenizer	el del modelo servido	LlamaTokenizer universal	el del modelo servido	el del modelo servido
Warmup / sliding window	no automático	no	sí (sliding window)	por ronda
ignore_eos por defecto	no	no	recomendado explícitamente	configurable
Distribución ISL/OSL	parámetro manual	parámetro manual	distribuciones con varianza	`--data` configurable
Modo de carga primario	concurrency	concurrency (batches drenados)	concurrency (recomendado)	sweep + poisson
Salida estructurada	JSON básico	JSON	JSON + CSV	JSON + HTML + CSV

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

El harness honesto: checklist de reproducibilidad

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

Hardware

Metadato	Ejemplo 4×H100	Efecto si no se fija
GPU (modelo, variante, cantidad)	4× NVIDIA H100 SXM 80 GB	H100 PCIe vs SXM difieren en BW de memoria y NVLink
Interconexión GPU-GPU	NVLink 4.0	tensor parallelism depende de la BW de interconexión
CPU, RAM, ancho de banda CPU-GPU	2× Intel Xeon 8480+, 512 GB DDR5, PCIe 5.0	el cuello de tokenización puede estar en la CPU
Estado térmico al inicio	temperatura GPU < 65 °C, potencia estable ± 3 W	throttling altera TPS y TTFT en hasta ~15 %
Frecuencias de GPU (clocks)	sin `nvidia-smi -pm 1` pueden variar	diferencia de hasta ~10 % en throughput

Software y modelo

Metadato	Ejemplo	Efecto si no se fija
Motor + versión + flags	vLLM 0.8.4, `--tensor-parallel-size 4 --gpu-memory-utilization 0.90`	cada versión cambia el scheduler y el KV cache management
Modelo + precisión	Llama-3-70B-Instruct, FP8	FP16 vs FP8 difieren ~1,4–1,8× en throughput
Tokenizer usado para contar	tokenizer del modelo servido (HF tokenizer)	LlamaTokenizer universal sesga tok/s entre vocabularios
Semilla de generación	`--seed 42`	sin semilla fija, la OSL varía run-to-run
`ignore_eos`	`True`	sin él, OSL varía con el contenido del prompt
Sampling parameters	`temperature=1.0, top_p=0.95`	greedy vs sampling afectan velocidad de logit

Carga

Metadato	Ejemplo	Efecto si no se fija
Herramienta de bench + versión	AIPerf 0.2.1	cada versión cambia fórmulas y warmup
Distribución ISL/OSL	(\mathcal{N}(512, 64)) ISL, (\mathcal{N}(128, 20)) OSL	cambiar distribución mueve el codo
Modo de carga	concurrency, sweep 1–64	concurrency vs request-rate: distribuciones distintas
Niveles de concurrencia	1, 2, 4, 8, 16, 32, 64 (sweep completo, más allá del codo)	sin pasar el codo, la capacidad segura es desconocida
Duración por punto	120 s mínimo por nivel	ventanas cortas capturan ramp-up, no régimen estacionario
Warmup	30 s excluidos del cómputo de métricas	sin warmup, las métricas incluyen estado frío
Tratamiento prefix cache	frío (flush entre corridas) o caliente (declarar explícitamente)	cache caliente: TTFT irreal para baseline

SLO y métricas reportadas

Metadato	Ejemplo	Efecto si no se declara
SLO declarado	TTFT P99 < 500 ms, ITL P95 < 50 ms	el goodput depende del SLO; sin SLO no hay goodput
Percentiles reportados	P50, P95, P99 (no solo media)	la media oculta la cola; irrelevante para SLO
Throughput vs goodput	goodput bajo SLO, no throughput bruto	el throughput de catálogo puede ser 5–10× el goodput
Número de peticiones totales	≥ 1.000 por nivel de concurrencia	muestras pequeñas: alta varianza en percentiles

Defensa metodológica del dato ante una auditoría

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

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

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

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

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

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

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

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

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

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

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

Configuración de benchmark	Throughput reportado	Goodput real	Factor vs goodput
vLLM bench, concurrency=32, sin ignore_eos, sin warmup, OSL=64 fijo	5.800 tok/s	~1.200 tok/s (OSL corto infla TPS)	4,8×
LLMPerf, concurrency=32, LlamaTokenizer, overhead incluido en denominador	3.100 tok/s	~1.600 tok/s (ITL incluye TTFT)	1,9×
AIPerf, concurrency=32, ignore_eos, sliding window, tokenizer del modelo	3.400 tok/s	3.350 tok/s	1,01×
GuideLLM, sweep 1–64, poisson, distribución ISL/OSL realista, SLO declarado	3.330 tok/s goodput (codo en ronda 6)	3.330 tok/s	1,0× (base honesta)

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

La descomposición del sesgo total

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

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

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

Estado del arte 2026: qué ha cambiado

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

Cross-links del track de benchmarking

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

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

Fuentes

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

Reproducibilidad 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

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

TL;DR

Las fuentes de sesgo: catálogo con magnitudes

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

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

El sesgo de ignore_eos y OSL inconsistente

El sesgo de la distribución ISL/OSL

El sesgo del warmup y el prefix-cache

El sesgo de concurrency vs request-rate

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

Cómo las herramientas calculan diferente la ITL

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

El harness honesto: checklist de reproducibilidad

Hardware

Software y modelo

Carga

SLO y métricas reportadas

Defensa metodológica del dato ante una auditoría

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

La descomposición del sesgo total

Estado del arte 2026: qué ha cambiado

Cross-links del track de benchmarking

Fuentes

El sesgo de `concurrency` vs `request-rate`