MLPerf Inference: cómo leerlo, qué obliga LoadGen y qué comparabilidad ofrece

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

TL;DR

MLPerf Inference lo mantiene MLCommons con cadencia semestral. Impone tres cosas que ningún benchmark casero tiene: un generador de carga obligatorio (LoadGen, compilado desde una revisión etiquetada y sin modificar), unas reglas de equivalencia de modelo que acotan qué se puede optimizar, y un proceso de auditoría que revisa hasta dos submissions por ronda. Los cuatro escenarios (SingleStream, MultiStream, Server, Offline) tienen duración mínima de 600 s y métricas distintas: Server reporta el caudal de Poisson sostenido y es el único con restricción de latencia. Para los benchmarks LLM esa restricción no es una latencia de petición sino dos SLO simultáneos al percentil 99: TTFT y TPOT, con cifras por modelo que van de 2000 ms / 200 ms en Llama 2 70B a 450 ms / 40 ms en su variante Interactive. La calidad se exige relativa al modelo de referencia (99 % o 99,9 %) y se audita además la longitud de generación (Llama 2 70B: más del 90 % de 294,45 tokens por muestra). Tres reglas de lectura resumen la comparabilidad real: los resultados solo se comparan con la misma versión, división, categoría y escenario; per-accelerator no es métrica oficial de MLCommons, es derivada; y ni el coste ni la energía entran en la métrica primaria, hasta el punto de que la ronda v5.1 tuvo 2 submissions de potencia frente a 27 organizaciones participantes.

Qué es y cómo se organiza

MLPerf Inference lo mantiene la MLCommons Association a través del MLPerf Inference Working Group, cuya participación está limitada a miembros y afiliados de MLCommons (MLPerf Inference Working Group). La cadencia declarada de publicación de resultados es de aproximadamente seis meses.

La suite se divide en dos categorías de sistema: Datacenter y Edge, definida esta última en las reglas como todo lo que no es datacenter (inference_rules.adoc). Un sistema Datacenter tiene dos requisitos que no aplican en Edge:

• ECC obligatoria en DRAM y HBM, activa durante todas las corridas de rendimiento y precisión. No hay requisito sobre SRAM.
• Networking obligatorio desde la ronda v3.0, con ancho de banda mínimo calculado sobre el throughput alcanzado. Para Llama 3.1 405B el ingress mínimo es throughput × 20000 × dtype_size bytes/s; para Llama 2 70B el egress mínimo es throughput × 1024 × dtype_size.

Edge admite además resultados inferidos: un MultiStream derivado de SingleStream vale 8 veces la latencia p99; un Offline derivado de MultiStream, 8000 dividido por la latencia media en milisegundos.

Los cuatro escenarios

Esta es la tabla normativa, transcrita de las reglas:

Cuatro precisiones operativas que cambian cómo se interpreta cada número:

• En Server, LoadGen no mide una latencia: ejecuta una búsqueda binaria sobre el caudal objetivo. Para un valor dado genera queries a ese QPS con llegadas de Poisson; si la corrida falla el gate de latencia, reduce el valor y repite. La métrica final publicada es, según la FAQ oficial, scheduled samples per second, no completed samples ni el objetivo introducido por el usuario.
• En MultiStream, la latencia de una query es la máxima de las latencias de sus muestras, y las 8 muestras de cada query son contiguas en el orden en que se cargaron. El valor multi_stream_samples_per_query = 8 está fijado en la configuración oficial.
• En Offline no hay restricción de latencia alguna. Las propias reglas prohíben las técnicas que solo funcionan en experimentos de longitud fija excepto en el escenario Offline, lo que es un reconocimiento normativo de que un resultado Offline no dice nada sobre el comportamiento bajo SLO.
• Los percentiles de la tabla son el límite teórico inferior para corridas con muchísimas queries. Con parada temprana, el percentil efectivamente calculado es algo superior al nominal, como penalización por procesar pocas queries.

Los escenarios obligatorios dependen del benchmark. En Datacenter, las tareas de resumen, question answering, generación de texto y VLM requieren (Server | Interactive), Offline, es decir, el submitter elige entre Server e Interactive. Razonamiento y recomendación requieren Server, Offline. Segmentación médica, clasificación de nodos, speech-to-text y RAG solo requieren Offline.

LoadGen: qué mide y qué no

LoadGen es el módulo que genera la carga y calcula las métricas. Su uso es obligatorio para todas las submissions, y debe compilarse desde una revisión etiquetada y aprobada del repositorio, sin alteración; el README es explícito en que no se admiten modificaciones locales de la biblioteca C++.

Sus cuatro responsabilidades declaradas son generar las queries según el escenario, rastrear la latencia de cada query, validar la precisión de los resultados y calcular las métricas finales. La latencia se define como el tiempo desde que LoadGen fue planificado para pasar una query al sistema bajo prueba hasta que recibe la respuesta.

Igual de importante es lo que declara fuera de su alcance: LoadGen no conoce el modelo, no conoce los formatos de datos, no sabe puntuar la precisión y no conoce las restricciones de escenario de las reglas MLPerf. La consecuencia está escrita en su propio README: como es ajeno al modelo, no puede imponer los requisitos de MLPerf, por ejemplo los percentiles y latencias objetivo. Esos límites se inyectan desde mlperf.conf y user.conf. La justificación de que sea obligatorio aparece en el paper fundacional de ISCA 2020: establece una frontera clara entre los componentes que pertenecen al submitter y los que pertenecen a MLPerf, y mide el rendimiento del sistema completo en lugar de el de una pieza.

Duración, número de queries y parada temprana

La duración mínima es de 600 000 ms en los cuatro escenarios. El número mínimo de queries sale de una tabla de intervalo de confianza que las reglas publican:

El verificador de submissions aplica Server: 270336, SingleStream: 1024 y MultiStream: 662. Para Offline, el mínimo se fija por benchmark: 24 576 en Llama 2 70B, 15 000 en Mixtral 8x7B, 13 368 en Llama 3.1 8B, 8 313 en Llama 3.1 405B, 4 388 en DeepSeek-R1, 1 633 en Whisper y 43 en 3D UNet.

El mecanismo de parada temprana permite acortar corridas manteniendo la garantía estadística. Con tolerancia d = 0 y confianza c = 0,99, el algoritmo resuelve por búsqueda binaria el menor número de queries por debajo del umbral de latencia que satisface el criterio, dado el número de queries observadas por encima.

Los modos de LoadGen son SubmissionRun (accuracy seguido de performance), AccuracyOnly, PerformanceOnly y FindPeakPerformance. Este último, aplicable solo a Server, toma el target_qps como cota inferior si pasa, estima la superior en el doble y la duplica hasta fallar, y luego hace búsqueda binaria. En modo performance LoadGen selecciona queries uniformemente al azar con reemplazo de un conjunto de tamaño QSL; en modo accuracy usa una copia del dataset de validación, cada muestra exactamente una vez. Debe ejecutarse una corrida de accuracy por cada resultado de rendimiento presentado, y el mismo código en ambos modos.

Las semillas se anuncian cuatro semanas antes del cierre y el generador obligatorio es Mersenne Twister 19937. Cambian cada ronda: en v5.1, qsl_rng_seed = 1780908523862526354; en v5.0 era 6023615788873153749.

Los tests de compliance

Se activan colocando un fichero audit.config en el directorio de trabajo, cuyos parámetros sobrescriben los de mlperf.conf y user.conf. Sus logs son obligatorios en el paquete de submission. El propósito declarado es detectar anomalías, no diagnosticar su causa.

Para los benchmarks LLM el test requerido es TEST06, específico contra el exploit del token de fin de secuencia. Ejecuta 100 muestras y exige tres condiciones: que el primer token reportado por separado coincida con el primer token de la salida del modelo, que la salida termine con cero o un único token EOS, y que el número de tokens reportados coincida con la longitud real de la secuencia generada.

Divisiones, categorías y qué se puede tocar

Las tres divisiones

• Closed: exige preprocesado, postprocesado y modelo equivalentes a la implementación de referencia. Permite calibración para cuantización y no permite reentrenamiento. Es la única que puede usar el nombre MLPerf sin cualificar.
• Open: permite preprocesado, postprocesado y modelo arbitrarios, incluido reentrenamiento. Las restricciones de precisión, de latencia y de escenario no aplican: en su lugar hay que reportar la precisión obtenida y las restricciones de latencia bajo las que se obtuvo el rendimiento. El modelo puede tener cualquier origen, cuantizarse de cualquier forma y esparsificarse de cualquier forma. Debe usar el mismo dataset de validación que el Closed correspondiente y usarlo entero.
• Network: hereda todos los requisitos de Closed, solo aplica a Datacenter, y separa el nodo LoadGen del sistema bajo prueba mediante una fabric. La biblioteca de despacho del submitter no puede preprocesar, postprocesar, batchear, paddear ni cachear. Las interconexiones de bus están prohibidas por nombre (PCIe, CXL, CCIX, HyperTransport, NVLink, QPI, UPI, ICI) y solo se admiten Ethernet, IEEE 802.11, InfiniBand y 3GPP, con requisito de funcionar chasis a chasis a más de diez metros.

Las categorías de disponibilidad

Available exige cuatro condiciones acumulativas: precio disponible, haberse alquilado o enviado a al menos un tercero, evidencia pública de disponibilidad y disponibilidad razonable para terceros adicionales en la fecha de submission. Un resultado Preview obliga a re-presentar como Available con rendimiento igual o mejor, tolerando hasta un 2 % de degradación por ruido; si no se re-presenta, el resultado Preview queda marcado como inválido. Los componentes RDI no pueden presentarse como Available hasta el ciclo siguiente al siguiente, o 221 días, lo que sea más largo.

Qué permite y qué prohíbe Closed

MLPerf entrega los pesos en fp16 o fp32. La regla central es que el submitter puede hacer cuantización puramente matemática y reproducible, usando solo los datos de calibración y los tensores del modelo entregado, a cualquier formato numérico que alcance la calidad exigida, y que el método debe describirse públicamente a un nivel que permita reproducirlo. El test contra puertas traseras es elegante: la descripción del método de cuantización debe ser mucho más pequeña que los pesos no nulos que produce.

Está permitido, entre otras cosas: cualquier framework o runtime, disposición arbitraria de datos, variar el algoritmo de multiplicación de matrices, transformaciones matemáticamente equivalentes, aproximaciones polinómicas de trascendentales, procesar queries fuera de orden dentro de lo que el escenario admita, sustituir operaciones densas por operaciones dispersas matemáticamente equivalentes, elegir a mano precisiones distintas por operación, fusionar y desfusionar, batch dinámico, y mezclas de expertos combinando pesos con distinta cuantización.

Está prohibido: sustituir o suplementar pesos al por mayor, descartar pesos no nulos, incluido el podado, cachear queries o respuestas, coalescer queries idénticas, modificar pesos durante la parte cronometrada, algoritmos de cuantización de tamaño comparable a los pesos que producen, hardcodear el número total de queries, usar conocimiento de la implementación de LoadGen para predecir picos o valles en el escenario Server, cambiar el número de haces de búsqueda, e incorporar estadísticos de los conjuntos de rendimiento o precisión.

Dos aclaraciones que interesan a cualquiera que sirva LLM en producción: el KV-cache está permitido igual que en el modelo de referencia siempre que no se aplique entre queries; PagedAttention se admite si el bloque se reutiliza solo dentro del lote; el batching continuo o dinámico está permitido; y las entradas del KV-cache se tratan como activaciones a efectos de cuantización, sin poder podarse. El decodificado especulativo solo se admite en las combinaciones de benchmark y escenario listadas explícitamente, con la cabeza de referencia a la misma precisión, y las implementaciones que manipulan artificialmente la tasa de aceptación están prohibidas.

Los SLO que casi nadie cita: TTFT y TPOT

Este es el punto donde más se malinterpreta una tabla de MLPerf. En los benchmarks LLM del escenario Server, la restricción no es una latencia de petición: las reglas fijan target_latency = 0 y activan use_token_latencies = 1, de modo que el gate lo forman dos métricas simultáneas, ambas evaluadas al percentil 99:

• TTFT (time to first token): latencia del primer token.
• TPOT (time per output token): intervalo medio entre todos los tokens generados.

Las cifras están en mlperf.conf y cambian por ronda y por benchmark:

Un TPOT de 40 ms equivale a 25 tokens por segundo y por usuario, que es el orden de magnitud de una interfaz conversacional; uno de 200 ms equivale a 5 tokens por segundo, que es un caso de uso por lotes disfrazado de servicio. Dos resultados del mismo modelo bajo etiquetas Server e Interactive no son la misma medida. Quedan dos discrepancias documentadas entre fuentes primarias: la variante llama2-70b-interactive no aparece en el mlperf.conf etiquetado como v5.0 pese a haberse anunciado en esa ronda, y en el ciclo v6.x el TPOT de gpt-oss-120b-interactive figura como 15 ms en mlperf.conf y como 20 ms en el texto de las reglas.

Para contraste, las restricciones de los benchmarks no-LLM del escenario Server son latencias de petición convencionales: ResNet-50 15 ms, RetinaNet 100 ms, BERT 130 ms, DLRMv2 60 ms, DLRMv3 80 ms, RNN-T 1000 ms, GPT-J y Stable Diffusion XL 20 000 ms.

Calidad: el 99 % y el recuento de tokens

Los objetivos de calidad se expresan relativos al modelo de referencia, nunca en absoluto, y cada benchmark exige una variante, otra o ambas. En la suite Datacenter vigente, 3D UNet, Llama 3.1 8B y Whisper piden 99 % y 99,9 % de FP32, lo que genera dos resultados distintos; Llama 2 70B pide solo 99,9 %; Llama 3.1 405B, Mixtral, DeepSeek-R1, GPT-OSS-120B, Qwen3-VL, RGAT y WAN-2.2 piden solo 99 %; y E2E-RAG es la excepción con 97 %. En el verificador esto se materializa como benchmarks separados (bert-99 y bert-99.9), cada uno con su umbral numérico calculado.

Sobre esa métrica hay una segunda restricción específica de LLM que se cita muy poco: también se audita la longitud de la generación.

La FAQ zanja el atajo evidente: no se permite reducir la longitud máxima de salida por debajo de la referencia, y truncar tokens para mejorar el rendimiento o alcanzar la precisión no está permitido. Los parámetros de inferencia están fijados en Closed (max_new_tokens = 1024 en Llama 2 70B, 20000 en Llama 3.1 405B y DeepSeek-R1), igual que el algoritmo de decodificación: búsqueda voraz en la familia Llama, Mixtral y DeepSeek-R1; muestreo con temperature = 1.0 y top_p = 1.0 en GPT-OSS-120B y Qwen3-VL. La precisión se reporta a cinco cifras significativas con redondeo al par.

La suite Datacenter vigente

El benchmark E2E-RAG merece atención de cualquiera que diseñe una plataforma RAG, porque fija el pipeline entero: índice FAISS HNSW con parámetros obligatorios M = 32, efConstruction = 200 y efSearch = 100; embeddings e5-base-v2; reranking ColBERTv2; generación y reescritura de consulta con GPT-OSS-120B; evaluación con Llama 3.1 8B como juez; y un máximo de 5 iteraciones de recuperación, obligatorio para todos los submitters. La carga de modelos no se cronometra; la construcción de la base vectorial sí.

La definición de sample cambia por modelo y es una fuente frecuente de confusión: en los LLM es una secuencia, en DLRMv3 es una petición con un historial de usuario y 2048 candidatos, en WAN-2.2 es un par de prompts positivo y negativo, y en PointPainting son cinco imágenes y una nube de puntos lidar.

Cómo leer una fila de resultados

Las columnas de la tabla oficial en división Closed son Submitter, Software, System, Benchmark Results, Processor/Count, Details, Accelerator/Count y Code. La división Open añade Model Used y Notes. Las filas con medición de potencia añaden System Power en Server y Offline, o Energy Per Stream en los escenarios de flujo. Cualquier cita debe usar el identificador con formato versión-mayor.versión-menor.entrada.benchmark, del estilo 5.1-0053, y llevar un pie con suite, versión, división, benchmark, escenario, fecha y fuente.

Per-accelerator no es una métrica oficial

No existe columna per-accelerator. Es una métrica derivada, y las guías de comunicación de MLCommons son tajantes: cualquier comparación basada en una métrica distinta o derivada, como potencia, coste, tamaño de modelo o precisión, debe dejar clara la base de comparación en el texto y en un pie, y las métricas secundarias y derivadas no pueden presentarse como métricas MLPerf oficiales o verificadas. El propio NVIDIA lo declara con la fórmula estándar en sus blogs de ronda: el rendimiento por GPU no es una métrica primaria de MLPerf Inference y se calcula dividiendo el throughput reportado entre el número de aceleradores reportados. Lo mismo aplica a combinar resultados de varios benchmarks: MLCommons lo permite pero no lo respalda, y el compuesto no puede presentarse como resultado oficial.

Las reglas de comparación

• Los resultados MLPerf solo pueden compararse con resultados MLPerf compatibles: mismo benchmark, mismo escenario y versiones compatibles según la tabla normativa de compatibilidad.
• Los resultados MLPerf no pueden compararse con resultados no MLPerf.
• Al comparar hay que identificar con claridad cualquier diferencia en versión, división, categoría, estado de verificación, escenario o número de chips. Al comparar Open con Closed, hay que identificar en qué sentido el resultado Open no clasificaría como Closed.
• Los submitters no pueden publicar resultados de una versión antes de su fecha oficial; los no-submitters deben esperar dos semanas desde esa fecha.
• El régimen sancionador llega a prohibir a un infractor presentar resultados en el futuro y a marcar sus resultados como no conformes de forma permanente en la base de datos, con un plazo de retirada del contenido infractor de tres días hábiles.

Cuánta auditoría hay detrás de una fila

En cada ronda se auditan hasta dos submissions: una elegida al azar entre todas y cero o una elegida por el comité de revisión. Y hay una restricción que condiciona la lectura de la tabla entera: solo son auditables las submissions Available de la división Closed. Preview, RDI y Open quedan fuera del proceso. Existe exención de la auditoría aleatoria si el sistema es equivalente a otro ya auditado y ni el rendimiento agregado ni el rendimiento por acelerador se separan más de un 10 % de los de la auditoría anterior. Los plazos son de 28 días para seleccionar auditor, 30 para el informe tras firmar los acuerdos de confidencialidad y unos 90 días para el proceso completo, con dos días de acceso al hardware para el auditor. Las reglas cierran con tres frases que definen el estándar de prueba: los resultados que no se pueden replicar no son resultados válidos, la detección del benchmark no está permitida y la optimización basada en la entrada tampoco.

Las rondas recientes, en cifras

Estos recuentos no forman una serie temporal: los criterios de conteo difieren entre notas de prensa y ninguna documenta el criterio, hasta el punto de que v4.0 y v4.1 se separan en un factor cercano a nueve.

Los saltos de rendimiento publicados sí son comparables dentro de cada anuncio. Entre v4.0 y v5.0, con doce meses de diferencia, el número de submissions de Llama 2 70B se multiplicó por 2,5, la mediana de la puntuación se duplicó y la mejor puntuación fue 3,3 veces más rápida. Entre v5.0 y v5.1, en seis meses, los mejores sistemas mejoraron hasta un 50 % en algunos escenarios. La ronda v6.0 cambió de eje y su nota de prensa habla de escala en lugar de velocidad: un 30 % más de submissions multinodo, un 10 % de los sistemas con más de diez nodos frente al 2 % de la ronda anterior, y un sistema mayor de 72 nodos y 288 aceleradores, cuadruplicando el nodo máximo previo.

Hardware que debutó en cada ronda: MI300X, TPU v6e, Xeon Granite Rapids y B200 en v4.1; MI325X, Xeon 6980P, GB200 y Jetson AGX Thor en v5.0; MI355X, Intel Arc Pro B60, GB300 y RTX Pro 6000 Blackwell Server Edition en v5.1.

Qué no mide MLPerf Inference

• Coste. No existe métrica de coste ni de TCO, y el coste está clasificado explícitamente como métrica derivada que no puede presentarse como oficial.
• Energía, salvo extensión opcional. MLPerf Power se regula en documento aparte, exige medir a la pared con el flujo de trabajo del grupo de potencia y PTDaemon, y prohíbe cualquier otro método. Su adopción real es marginal: 2 submissions de potencia en v5.1 frente a 27 organizaciones participantes. Además, MLCommons acota qué significa esa cifra: la potencia medida solo vale para el benchmark que la acompaña, y cualquier otra referencia a potencia, como una configuración de TDP o el rating de una fuente, no está medida ni validada por MLCommons. La norma de comunicación prohíbe a los submitters publicar comparaciones normalizadas por vatio que usen cualquier proxy distinto de la potencia medida.
• Configuraciones no optimizadas por el fabricante. El sesgo está reconocido en la propia norma de auditoría, que contempla submissions cuyo rendimiento no es consistente con las características conocidas del hardware, o donde el comité carece de visibilidad sobre cómo se alcanzó, o donde hardware y software no están razonablemente disponibles para el público.
• Barrera de entrada. Solo los miembros de MLCommons y los test partners pueden presentar resultados a revisión. Quien mide con el mismo código sin presentar debe etiquetar cada cifra como no verificada con la leyenda correspondiente.

Flujo de uso para una plataforma on-premise

MLPerf Inference es útil en una decisión de compra si se usa por lo que es, un banco de pruebas con reglas escritas, y no como ranking.

1. Filtrar por división y categoría antes de mirar ningún número: quedarse con Closed y Available. Un resultado Preview o RDI describe hardware que todavía no se puede comprar, y ninguno de los dos es auditable.
2. Elegir el escenario que corresponde al patrón de carga: Server o Interactive si hay usuarios esperando, Offline si el trabajo es por lotes. Un resultado Offline no autoriza a prometer una latencia.
3. Leer el SLO antes del throughput: en cualquier benchmark LLM, el número de queries por segundo solo significa algo junto a su par TTFT/TPOT. La misma máquina publica cifras muy distintas bajo Server y bajo Interactive.
4. Comprobar la variante de calidad: 99 % y 99,9 % son resultados diferentes del mismo modelo, y el segundo suele costar rendimiento.
5. Traducir a la propia configuración con cuidado: dividir entre el número de aceleradores es una métrica derivada, no oficial, y hay que declararla como tal.
6. Cerrar el hueco que MLPerf deja abierto con medición propia: coste, energía y el comportamiento bajo el tráfico real. Esa es exactamente la función del harness reproducible y de las herramientas de bench del track B, y la razón por la que ninguna decisión de plataforma se sostiene solo sobre una tabla pública.

Cross-links del track de benchmarking

• B1/B2 — Benchmarking de inferencia LLM: frameworks, métricas y estado del arte: las métricas TTFT, TPOT y goodput fuera del corsé de MLPerf, y qué herramienta mide cada una.
• B2 — Catálogo de herramientas de benchmark LLM: las herramientas con las que se reproduce en casa lo que MLPerf estandariza.
• B3 — GuideLLM y la validación de SLO bajo carga: el equivalente práctico de la búsqueda binaria de LoadGen en el escenario Server.
• B6 — Sesgo de medición y reproducibilidad: por qué existe LoadGen, contado desde el lado de lo que pasa cuando no lo hay.
• B8 — Comparativa de motores de serving en frontera de Pareto: la comparación que MLPerf no hace, con motores en lugar de sistemas.
• C4 — MLPerf Power: la extensión energética de esta misma maquinaria, con su medición certificada a la pared.

Ver también

• El harness reproducible: coste, rendimiento y energía en un solo experimento auditable — cómo montar en casa el equivalente auditable de una submission, midiendo además lo que MLPerf deja fuera.
• Dimensionar y justificar la inversión en GPU — el paso de una cifra de throughput bajo SLO al número de aceleradores y al retorno.

Fuentes

• MLCommons, MLPerf Inference Working Group — https://mlcommons.org/working-groups/benchmarks/inference/
• MLCommons, MLPerf Inference Rules (inference_rules.adoc) — https://github.com/mlcommons/inference_policies/blob/master/inference_rules.adoc
• MLCommons, MLPerf Inference Power Measurement (power_measurement.adoc) — https://github.com/mlcommons/inference_policies/blob/master/power_measurement.adoc
• MLCommons, MLPerf Submission Rules (submission_rules.adoc) — https://github.com/mlcommons/policies/blob/master/submission_rules.adoc
• MLCommons, MLPerf Results Messaging Guidelines — https://github.com/mlcommons/policies/blob/master/MLPerf_Results_Messaging_Guidelines.adoc
• MLCommons, LoadGen README — https://github.com/mlcommons/inference/blob/master/loadgen/README.md
• MLCommons, loadgen/test_settings.h — https://github.com/mlcommons/inference/blob/master/loadgen/test_settings.h
• MLCommons, loadgen/mlperf.conf (master) — https://github.com/mlcommons/inference/blob/master/loadgen/mlperf.conf
• MLCommons, loadgen/mlperf.conf (tag v5.1) — https://github.com/mlcommons/inference/blob/v5.1/loadgen/mlperf.conf
• MLCommons, loadgen/mlperf.conf (tag v5.0) — https://github.com/mlcommons/inference/blob/v5.0/loadgen/mlperf.conf
• MLCommons, tools/submission/submission_checker.py (tag v5.0) — https://github.com/mlcommons/inference/blob/v5.0/tools/submission/submission_checker.py
• MLCommons, compliance/nvidia TEST06 README (tag v5.1) — https://github.com/mlcommons/inference/blob/v5.1/compliance/nvidia/TEST06/README.md
• MLCommons, Benchmark results: Inference Datacenter — https://mlcommons.org/benchmarks/inference-datacenter/
• Reddi et al., MLPerf Inference Benchmark, ISCA 2020 — https://arxiv.org/abs/1911.02549
• MLCommons, MLPerf Inference v5.0 Benchmark Results (abril 2025) — https://www.businesswire.com/news/home/20250402313932/en/MLCommons-Releases-New-MLPerf-Inference-v5.0-Benchmark-Results
• MLCommons, MLPerf Inference v5.1 Benchmark Results (septiembre 2025) — https://www.globenewswire.com/news-release/2025/09/09/3147136/0/en/MLCommons-Releases-New-MLPerf-Inference-v5-1-Benchmark-Results.html
• MLCommons, MLPerf Inference v6.0 Benchmark Results (abril 2026) — https://www.globenewswire.com/news-release/2026/04/01/3266801/0/en/MLCommons-Releases-New-MLPerf-Inference-v6-0-Benchmark-Results.html
• MLCommons, MLPerf Inference v4.1 Benchmark Results (agosto 2024) — https://www.businesswire.com/news/home/20240828886616/en/New-MLPerf-Inference-v4.1-Benchmark-Results-Highlight-Rapid-Hardware-and-Software-Innovations-in-Generative-AI-Systems
• NVIDIA Developer Blog, NVIDIA Blackwell delivers massive performance leaps in MLPerf Inference v5.0 — https://developer.nvidia.com/blog/nvidia-blackwell-delivers-massive-performance-leaps-in-mlperf-inference-v5-0/
• NVIDIA Developer Blog, NVIDIA Blackwell Ultra sets new inference records in MLPerf debut — https://developer.nvidia.com/blog/nvidia-blackwell-ultra-sets-new-inference-records-in-mlperf-debut/
• MLCommons, MLPerf Automotive (octubre 2025) — https://arxiv.org/html/2510.27065v1
• Tschand et al., MLPerf Power: Benchmarking the Energy Efficiency of Machine Learning Systems from Microwatts to Megawatts — https://arxiv.org/abs/2410.12032