Convierte MLPerf v6.1 en un modelo de coste por token para tu stack de serving

MLPerf v6.1 aporta la aritmética de la compra

Estás eligiendo GPUs, software de serving y capacidad para cargas de trabajo de LLM, RAG y agentes. El dilema es tokens por segundo brutos frente a coste por token útil: GPUs en espera, solicitudes fallidas y software de serving deficiente acaban en la factura. Usa coste por token útil = (horas-GPU x $/hora + coste de caídas) / tokens útiles. MLPerf Inference v6.1 contó con 30 organizaciones que enviaron resultados y 486 resultados de datacenter y edge. El mejor resultado por acelerador de DeepSeek R1 en el escenario server fue 5,7 veces el resultado de v5.1 de un año antes. El conjunto de resultados ofrece un perfil común y separa el progreso de software del progreso de silicio.

v6.1 añadió End-to-End RAG y Agentic Edge Inference, de modo que el tráfico de RAG y agentes ahora tiene perfiles medidos. GPT-OSS-120B fue la carga de trabajo más enviada, con 112 envíos. Úsala como línea base cuando tu tráfico se aproxime a ese perfil; en caso contrario, busca el escenario más cercano y anota la diferencia.

Cinco pasos para convertir el throughput en coste por token útil

• Ajusta el perfil de la carga de trabajo. Elige el escenario de MLPerf que refleje tu tráfico: server para solicitudes interactivas, offline para lotes, retrieval-plus-generation para RAG, o llamadas de agente para cargas de trabajo de agentes. Anota la longitud del prompt, la longitud de la completion, la concurrencia y el timeout. Registra la mezcla de solicitudes, no solo los tokens promedio. Detente cuando puedas nombrar el escenario y el presupuesto de tokens por solicitud.
• Normaliza los tokens por segundo. Coloca cada resultado en un único acelerador, un único modelo, un único escenario y una única versión de software. Convierte el throughput por lotes en latencia por solicitud y luego en tokens por segundo por acelerador. Mantén la versión de software visible en la tabla. Deja una sola tabla sin tamaño de lote oculto.
• Aplica la utilización y el coste de caídas. Multiplica las horas-GPU por tu tarifa en dólares y suma el coste de las solicitudes fallidas o retrasadas. Incluye el tiempo en espera entre solicitudes, los arranques en frío y los reintentos. Trata los reintentos como trabajo pagado, no como ruido gratuito. No uses el throughput offline de pico para la capacidad interactiva; sobreestima los tokens utilizables. Usa tu SLO real, no el objetivo del benchmark. El número debe ser el coste por token útil, no el coste por token publicado.
• Compara las ganancias solo de software. Comprueba si el mismo hardware es más rápido con un stack de serving más nuevo. El nodo de cuatro GPUs Arc Pro B70 de Intel mejoró GPT-OSS-120B en un 36 por ciento en el escenario server y un 27 por ciento en el escenario offline frente a v6.0 en hardware idéntico, impulsado por optimizaciones de software. Ejecuta el mismo modelo y escenario en tu stack actual y luego en el stack candidato. Registra una diferencia en dólares antes de cualquier nueva compra. Si la diferencia es pequeña, mantén el stack actual.
• Dimensiona la capacidad. Dimensiona a partir del sistema más grande y creíble, no de un solo nodo. El clúster de 512 GPUs AMD Instinct MI355X de Crusoe fue el sistema más grande enviado, y el clúster alcanzó 5,75 millones de tokens por segundo para GPT-OSS-120B offline. Aplica esa escala para comprobar si tu objetivo es un problema de nodo o un problema de flota. El margen de holgura debe cubrir crecimiento y fallos, no solo el pico. Termina con un número de GPUs, un presupuesto en dólares y un número de margen de holgura.

Usa la diferencia de hardware para elegir stack o silicio

El Vera Rubin NVL72 de NVIDIA alcanzó hasta 3,7 veces el throughput de Qwen3-VL del GB300 NVL72 usando vLLM con Dynamo. Coloca ese número junto a la diferencia en dólares del paso de ganancias de software. El esfuerzo de migración incluye controladores, configuración de serving y rollback. Si la ganancia de hardware no sobrevive a la utilización, el coste de caídas y el esfuerzo de migración, la opción más barata es una actualización del stack. En caso contrario, la partida de hardware se convierte en el principal impulsor del coste.

Mantén una fila por candidato: modelo, escenario, acelerador, stack de serving, tokens por segundo por acelerador, horas-GPU, tarifa en dólares, utilización, coste de caídas y coste por token útil. Añade una fila para el stack actual para que la comparación sea explícita. La tabla debe responder a tres preguntas: cuántas GPUs, cuál es el coste mensual y qué pasa cuando el tráfico crece. Cuando los stacks caen dentro de un rango pequeño, elige el de menor riesgo operativo; descarta temprano un stack claramente peor.