Qué son los tokens por segundo que mide MLPerf y cómo se usan en LLM

Guía Hardware » Benchmarks » Qué son los tokens por segundo que mide MLPerf y cómo se usan en LLM

Si trabajas con modelos de lenguaje, habrás escuchado mil veces eso de tokens por segundo, pero pocas veces se explica con calma qué significa en entornos reales y, sobre todo, cómo lo mide MLPerf. En este artículo te contamos de forma clara qué son los tokens, por qué la métrica de tokens por segundo manda en inferencia y cómo la usan plataformas como Databricks y el benchmark MLPerf para dimensionar, comparar y escalar. Además, incluimos cifras concretas de fabricantes y nubes para aterrizar expectativas de rendimiento.

El tema no es menor: la industria ha estandarizado tokens por segundo para evaluar rendimiento de LLM en datacenter y edge. MLPerf, la suite de MLCommons revisada por pares, se ha convertido en el referente para comparar hardware y software; en paralelo, operadores como Databricks ya aprovisionan sus endpoints de modelos directamente en función de un rango de tokens por segundo. Vamos a desgranar todo esto, con números y casos de uso en la mano.

Qué es un token y por qué importa en LLM

Los modelos de lenguaje no procesan letras ni palabras sueltas tal cual; trabajan con unidades llamadas tokens. Un token suele equivaler a unos 4 caracteres o, en promedio, a 0,75 palabras. Esa relación varía según el idioma y el tokenizador del modelo, pero sirve para tener una referencia rápida: un texto de 10 palabras se mueve en torno a 13–14 tokens.

La segmentación exacta depende del modelo: cada LLM utiliza su propio tokenizador y divide las palabras en tokens completos o subpalabras. Herramientas online permiten ver, por ejemplo, cómo tokeniza Llama una frase concreta. Esta variabilidad, que parece un detalle, influye en la latencia y en la factura de cómputo.

Cuando se habla de velocidad de generación, lo habitual es expresarlo como tokens por segundo, en lugar de palabras por segundo. Esto homogeneiza la métrica entre idiomas, longitudes de contexto y estilos de salida, y permite calcular con precisión el coste de inferencia y la capacidad necesaria.

Por qué medir rendimiento en tokens por segundo y no en RPS

En servicios tradicionales de API se miran las RPS (peticiones por segundo). En LLM, ese enfoque se queda corto: dos solicitudes pueden tardar tiempos muy distintos según los tokens de entrada y los tokens de salida. Es decir, la carga útil real viene en tokens, no en «número de llamadas».

Hay dos fuentes de variabilidad clave. Por un lado, la longitud del contexto de entrada: un prompt breve puede tener pocos tokens, pero un documento para resumir puede dispararse a cientos o miles. Por otro, la longitud de la salida: resumir suele producir menos tokens; generar un artículo o descripciones largas multiplica el tiempo, porque la decodificación de salida es la parte más costosa.

Por eso, para escalar un endpoint de inferencia de manera realista, conviene pensar en términos de tokens. Databricks, por ejemplo, aprovisiona sus endpoints de Serving con un rango de tokens por segundo y factura por hora en función del escalado. Así alineas capacidad con carga real sin engañarte con una RPS que no cuenta toda la historia.

Cómo miden Databricks y MLPerf los tokens por segundo

Databricks toma como referencia una carga representativa de RAG y resumen: 2048 tokens de entrada y 256 tokens de salida. Suma ambas fases (prefill y decode) y optimiza, por defecto, el equilibrio entre rendimiento y latencia para lotes de tamaño 1 por solicitud, simulando múltiples peticiones concurrentes.

Con esa regla, los números se leen así: si configuras un endpoint a 2304 tokens por segundo (2048 + 256), una solicitud con esos tamaños tarda alrededor de un segundo. Si lo pones en 5600 tokens por segundo, la misma petición cae a unos 0,5 s y puedes procesar dos solicitudes similares por segundo.

Cuando tu carga de trabajo cambia, cambiará la latencia. Generar más tokens de salida penaliza más que aumentar tokens de entrada. Si haces inferencia por lotes, calcula el promedio de tokens de entrada y salida de tu dataset y compáralo con el banco de pruebas anterior para estimar tiempos.

Ejemplos prácticos: con 1000 filas, una media de 3000 tokens de entrada y 500 de salida y un rendimiento aprovisionado de 3500 tokens por segundo, tardarás más de 1000 segundos porque tus promedios superan la referencia. Si en cambio promedias 1500 de entrada y 100 de salida con 1600 tokens por segundo de aprovisionamiento, bajarás de los 1000 segundos en total para esas 1000 filas.

Autoscaling por demanda y cálculo del escalado real

El Serving de modelos de Databricks incluye un autoscaling rápido que aumenta o reduce los recursos según la demanda de tokens por segundo. El sistema escala en bloques de capacidad y solo se factura el extra cuando se usa. En pruebas con más solicitudes en paralelo, se observa cómo el rendimiento aprovisionado crece hasta estabilizarse en torno a 8000 tokens por segundo cuando se saturan los recursos, subiendo la latencia por colas.

Si notas menos tokens por segundo de los que marcaste, revisa dos cosas: la concurrencia aprovisionada que reflejan las métricas del endpoint y el tamaño mínimo de banda configurado. Con esos datos, el escalado real se estima con la fórmula: concurrencia aprovisionada × tamaño mínimo de banda / 4.

Un ejemplo concreto: con una concurrencia máxima de 8 y un tamaño mínimo de banda de 850 tokens por segundo, el tope efectivo sería de 1700 tokens por segundo (8 × 850 / 4). Entender este cálculo te evita sorpresas y te ayuda a ajustar la configuración a tus SLO de latencia.

MLPerf Inference: qué es y qué está midiendo hoy

MLPerf, desarrollado por MLCommons, es la suite abierta y estandarizada para medir rendimiento de IA en datacenter y edge, desde visión hasta LLM. Su objetivo es comparar plataformas de forma justa y reproducible para empujar la eficiencia del ecosistema. En las últimas ediciones, el foco se ha desplazado claramente hacia GenAI y LLM de gran tamaño.

En la quinta edición se consolidó Llama 2 70B como benchmark estrella, desplazando a ResNet50, y las métricas de tokens por segundo mejoraron hasta 3,3 veces en el mejor caso en un año, con una mediana 5 veces mayor gracias a optimizaciones de hardware y software. La presencia de CPUs como Intel Xeon 6 en resultados oficiales demostró, además, que hay espacio para soluciones generalistas eficientes en determinados escenarios.

La versión 5.1 de MLPerf Inference ha dado otro salto: incorporó tres nuevos benchmarks clave, razonamiento con DeepSeek‑R1, speech‑to‑text con Whisper Large v3 y un LLM pequeño basado en Llama 3.1 8B. En conjunto, el consorcio reportó 27 participantes, marcó el hito de 90.000 resultados y estrechó las métricas de latencia en escenarios interactivos.

Métricas y objetivos en los nuevos benchmarks

El benchmark de razonamiento con DeepSeek‑R1, un MoE de 671B parámetros, refleja que estos modelos producen cadenas de razonamiento largas antes de la respuesta. Soporta salidas de hasta 20.000 tokens, con un promedio de 3880 tokens por salida en el dataset, el más largo hasta la fecha en inferencia.

Las reglas miden throughput en modo offline y modo server con límites estrictos: tiempo hasta el primer token de 2 segundos y latencia por token de 80 ms al p99. Así se busca equilibrar el presupuesto de «pensamiento» con la capacidad de respuesta necesaria para desplegarlo.

El benchmark de LLM pequeño con Llama 3.1‑8B sustituye a GPT‑J 6B como puerta de entrada. Soporta contextos de hasta 128.000 tokens y evalúa resumen en CNN‑DailyMail con entradas de 778 tokens y salidas de 73. Se valida precisión con ROUGE y, en división cerrada, se exige igualar el 99 por ciento de una referencia de alta precisión.

En métrica de latencia, se usan dos indicadores: TTFT (tiempo hasta el primer token) y TPOT (tiempo por token de salida). En server se apuntan 2 s de TTFT y 100 ms de TPOT (alrededor de 480 ppm), y en el nuevo escenario interactivo se aprieta a 0,5 s y 30 ms respectivamente (cerca de 1600 ppm) para casos tipo chat, coding o herramientas creativas.

Cifras destacadas de rendimiento por fabricante y operador

• NVIDIA volvió a liderar, esta vez con Blackwell Ultra en el sistema GB300 NVL72, marcando un récord en razonamiento con un 45 por ciento más de throughput DeepSeek‑R1 que GB200 NVL72, y alcanzando 5842 tokens por segundo por GPU en offline y 2907 en server, con mejoras cercanas a 5× frente a Hopper no verificado.
• En el nuevo benchmark interactivo de Llama 3.1 405B, NVIDIA aplicó serving desagregado con Dynamo, separando contexto y generación en GPUs distintas y transfiriendo KV Cache por NVLink, logrando 1,5× más throughput por GPU que el serving tradicional en Blackwell y más de 5× que sistemas con Hopper.
• Para modelos más pequeños, NVIDIA reportó más de 18.000 tokens por segundo por GPU en Llama 3.1 8B en offline y 5667 tokens por segundo por GPU en Whisper, manteniendo liderazgo por GPU en todos los escenarios (offline, server e interactivo).
• AMD amplió presencia con la primera sumisión de la GPU Instinct MI355X, que en Llama 2‑70B mostró escalado multinodo y un incremento de 2,7× en tokens por segundo respecto a MI325X en FP8. En división abierta, aplicó poda estructurada en Llama 3.1‑405B (FP4), subiendo el throughput un 82 por ciento con un modelo podado al 21 por ciento de profundidad y un 90 por ciento con otro al 33 por ciento más fine‑tuning, manteniendo la precisión.
• También estrenó envíos en Llama 2‑70B Interactive, Mixtral‑8×7B y Stable Diffusion XL, y presentó resultados mixtos MI300X/MI325X: al escalar a 4 nodos, MI355X logró 3,4× más throughput que MI300X, extendiendo a 8 nodos con buena escalabilidad.
• HPE, combinando ProLiant y Cray, reportó 14 resultados número 1. El DL380a Gen12 destacó en DLRM y Llama 3.1‑8B (Server) entre sistemas PCIe de 8 GPUs; el DL385 Gen11 marcó mejor rendimiento por GPU en Whisper con H200 NVL; y el Cray XD670 (8× H200) sumó seis primeros puestos en RetinaNet, Llama 3.1‑8B, Mixtral y Whisper, además de estrenos con RTX Pro 6000 Blackwell SE y resultados GH200 NVL2 en DLRM.
• CoreWeave fue el primer cloud en reportar resultados con GB300, entregando 6005 tokens por segundo por GPU en DeepSeek‑R1 en offline y demostrando orquestación y escalado con Slurm on Kubernetes y scheduling sensible a la topología para exprimir NVLink.
• Dell envió 12 sistemas con aceleradores AMD y NVIDIA, brillando en LLaMA 2 70B Interactive con PowerEdge XE9680L y B200, LLaMA 3.1‑8B Server en XE9685L+B200, SDXL en XE9685L y Whisper en XE9680L, evidenciando versatilidad desde imagen a voz pasando por LLM.
• Intel subrayó que sigue siendo el único en enviar resultados con CPUs de servidor y mostró que Xeon 6 con P‑cores mejora 1,9× frente a la 5.ª Gen Xeon en cinco benchmarks, consolidando su papel en inferencia generalista. Además, presentó estaciones con 8 GPUs Arc Pro B60, con 192 GB de VRAM para servir Llama2‑70B a múltiples usuarios, empaquetando drivers y frameworks para simplificar el despliegue multi‑GPU.
• Entre los integradores y partners, ASUSTeK optimizó latencia y throughput con cuantización, kernels y stack; Broadcom demostró virtualización VCF con overhead mínimo frente a bare‑metal en múltiples cargas (Whisper, SDXL, Llama 3.1‑405B, Llama2‑70B, RGAT, RetinaNet); Cisco escaló casi linealmente con UCS C885A M8 (8× H200 SXM) y UCS C845A M8 (8× H200 NVL o L40S), apoyándose en redes One G200.
• KRAI, usando OpenAI API y overheads realistas, comparó SGLang y vLLM con Llama3.1‑70B: 31.391 tokens por segundo en offline con SGLang 0.4.9 y 26.319 con vLLM 0.9.2 en un único servidor con 8× H200; con cuantización dinámica llegó a 27.697 con SGLang y 30.893 con vLLM, y en multinodo escaló hasta 87.334 tokens por segundo en tres servidores.
• Lambda, con 8× B200 180 GB SXM, mostró mejoras de throughput de hasta 7 por ciento en SDXL y 15 por ciento en Llama 3.1‑405B respecto a la ronda anterior, y ofrece clústeres desde 16 hasta 1536 GPUs con Kubernetes o Slurm gestionados.
• MiTAC, con su serie G8825Z5, brilló en LLaMA 2 70B Interactive con 18.846,1 tokens por segundo y buen resultado en Server y Mixtral; Nebius certificó su rendimiento virtualizado casi a la par de bare‑metal en GB200 NVL72, HGX B200 y HGX H200, con 596,11 tokens por segundo en server y 855,82 en offline en Llama 3.1‑405B con 4 GPUs GB200.
• Red Hat demostró que vLLM como runtime soportado en su AI Inference Server, con kernels CUTLASS para FP8 y FlashAttention‑3 más un motor vLLM v1 mejorado, impulsa Llama‑3.1‑8B en H100 y L40S con gran relación coste‑rendimiento.
• Supermicro publicó resultados punteros con HGX‑B200 de 8 GPUs (aire y líquido) tanto con CPU Intel como AMD, destacando en Llama 3.1‑8B y Llama 2‑70B en server/offline/interactivo y Whisper; en colaboraciones, mostró escalado excelente con 32× H100‑SXM y alternativas con MI325X.
• Vultr se estrenó con Supermicro AS‑8126GS‑TNMR y 8× MI325X, certificando rendimiento competitivo como Cloud GPU; GATEOverflow promovió reproducibilidad con MLCFlow en RTX 4090 y CPUs AMD/Intel; Giga Computing envió 8U aire‑refrigerado para EPYC+MI325X y Xeon+HGX B200; QCT cubrió configuraciones Xeon 6 con H200 NVL (4 GPUs) y plataformas 8× H200 SXM5 con NVLink y GPUDirect Storage, además de sistemas 8× MI325X.

La academia también tuvo su momento. La Universidad de Florida, con su DGX B200 SuperPOD integrado en HiPerGator, fue la primera institución en enviar resultados de inferencia cumpliendo latencias en Server bajo división cerrada, usando Apptainer sin Docker/Sudo y encajando en SLURM multiusuario. En el extremo opuesto, un envío individual en un MacBook Pro M1 Pro, con ONNX Runtime y CoreML en GPU y Neural Engine, superó la precisión objetivo en categoría de edge y evidenció que se puede evaluar inferencia de calidad en hardware de consumo.

Velocidad percibida por usuarios y límites prácticos

La experiencia de uso no se mide solo en benchmarks; en el día a día, la sensación de fluidez llega cuando superas cierto umbral de tokens por segundo. Un usuario comentaba que, para conversación, su límite son 4 tokens por segundo y, para escritura de historias, alrededor de 10 tokens por segundo; por debajo, la interacción se siente lenta.

Si intentas ejecutar un LLM en local, hay tres realidades. En CPU de sobremesa, lo normal es moverse en 1–2 tokens por segundo, inviable para respuestas largas. Con una GPU de gama alta de gaming, puedes acercarte a 5 tokens por segundo. Con una NVIDIA H100, sí, ya hablamos de unos 60 tokens por segundo, pero es hardware de centro de datos, no de escritorio.

¿Qué pasa en la nube? Los proveedores más potentes baten estas cifras gracias a hardware especializado y stacks de inferencia optimizados. Se han reportado medias en torno a 119 tokens por segundo en ChatGPT‑4 y 168 en Gemini, mientras que modelos populares open como DeepSeek se quedan cerca de 21 tokens por segundo. Si lo conviertes a palabras, 119 tokens por segundo rondan las 90 palabras por segundo.

Conclusión operativa: para la mayoría de usuarios, correr una IA en el ordenador es posible, pero poco práctico por la lentitud. Para trabajar a ritmos cómodos y con latencias ajustadas, los servicios gestionados siguen siendo la opción sensata.

Cómo dimensionar tu endpoint por TPS y qué esperar de la latencia

Pasos prácticos para dimensionar. Primero, perfila tu caso de uso: media de tokens de entrada y de salida, distribución de longitudes y simultaneidad esperada. Segundo, corre una prueba de carga con un dataset representativo, conllevando TTFT y tokens por segundo sostenidos por solicitud.

Luego, alinea la configuración con tu patrón. Si tu workload se parece al de referencia de Databricks (2048 in, 256 out), elige un rango de tokens por segundo tal que una solicitud entre en el presupuesto de latencia deseado. Recuerda que duplicar salida suele costar más que duplicar entrada y que la concurrencia efectiva depende del autoscaling real.

Monitoriza y ajusta. Vigila métricas de concurrencia aprovisionada, colas, TTFT y TPOT, y compara con tus SLO. Si te falta techo, amplía el rango; si sobran recursos, bájalo y ajusta bloques para ahorrar. La fórmula de escalado real te ayudará a entender por qué el endpoint no rinde lo configurado si no levantó suficientes réplicas.

Por último, sé consciente del escenario. En modo interactivo al estilo chatbot, apuntar a TTFT de 0,5 s y 30 ms por token te situará en una experiencia de usuario premium. En modo server, 2 s y 100 ms por token son guías razonables, y en offline, busca throughput máximo manteniendo la precisión requerida por el benchmark.

Mirando las tendencias de MLPerf, el vector es claro: más contexto, más tokens y mejores técnicas de eficiencia —disaggregated serving, FP4/FP8, pruning estructurado, kernels a medida, planificación de KV cache— empujan el techo de tokens por segundo año tras año, tanto por chip como por sistema.

La foto de conjunto que dibujan Databricks y MLPerf es coherente: pensar en tokens por segundo es la forma correcta de razonar sobre coste, latencia y escalabilidad en LLM. Con un buen benchmark representativo, métricas de TTFT/TPOT y un autoscaling bien calibrado, es posible dar respuestas rápidas y estables, sin sobredimensionar la infraestructura.

Artículo relacionado:

NVIDIA Blackwell Ultra GB300: arquitectura, memoria y NVLink 5