Tokens por segundo: mide la velocidad real de un LLM

¿Qué miden los tokens por segundo?

Los tokens de salida por segundo miden la rapidez con la que un LLM entrega los tokens generados después de recibir el primero. Un modelo de lenguaje de gran tamaño, o LLM, procesa el texto en forma de tokens: unidades que pueden ser palabras, fragmentos de palabras o signos de puntuación. Contar tokens no equivale a contar palabras de forma universal. La definición de Cerebras distingue expresamente ambos conceptos.

Imagina que vas a una biblioteca a recoger varios libros. El tiempo que esperas hasta que abren la puerta es una cosa; el ritmo al que te entregan los libros, otra. Ambos determinan cuándo puedes salir con todo lo que necesitas. Una entrega rápida no elimina la larga espera en la entrada.

En una aplicación, conviene medir cada intervalo por separado:

Estos intervalos siguen las definiciones de métricas de Artificial Analysis. El primer token de razonamiento puede llegar antes que el primer token de respuesta; por eso, cada medición necesita su propio nombre.

La latencia de extremo a extremo de tu aplicación empieza cuando el usuario actúa y termina cuando obtiene un resultado útil. En un asistente de voz, ese resultado puede ser una respuesta audible; en un agente, una acción completada. La recuperación de información, la ejecución de herramientas, la síntesis de audio y las actualizaciones de la interfaz pueden quedar fuera de la solicitud al modelo. Añade mediciones que cubran también ese recorrido completo.

Las etapas internas son prefill, en la que se procesa el prompt, y decode, en la que se genera la continuación. La guía de inferencia de LLM explica cómo avanza ese trabajo por el sistema que sirve el modelo.

Por qué una sola cifra de velocidad de inferencia puede engañar

Un resultado de velocidad describe una carga de trabajo en un endpoint, no una propiedad del modelo que se mantenga en cualquier circunstancia. Si cambia el trabajo o las condiciones de ejecución, también cambia la comparación.

Longitud del prompt y contexto en caché

Un chat de soporte con una pregunta breve no plantea el mismo trabajo que ese mismo chat con un historial extenso y documentos de políticas recuperados. Una entrada más larga modifica el trabajo previo a la respuesta. Groq señala el tamaño de la entrada como uno de los factores que influyen en el TTFT en su guía de latencia.

Registra la longitud del prompt y el estado de la caché en las pruebas. La guía de la caché KV explica qué estado de atención se guarda durante la generación y cómo se relaciona la reutilización de prompts con la caché. Una prueba con un prompt repetido que ya está en caché no debe presentarse, sin indicarlo, como si representara una conversación nueva con un cliente.

El razonamiento previo a la respuesta

Un modelo de razonamiento puede generar tokens intermedios antes de entregar la respuesta. Que genere rápido no indica cuánto va a razonar. Comprueba si la velocidad publicada incluye ese flujo y si el cronómetro del primer token se detiene al recibir razonamiento o texto de respuesta.

En un asistente de reservas, lo que cuenta es una respuesta útil o una llamada a una herramienta. Mostrar un indicador de que el modelo está pensando puede confirmar la recepción de la solicitud, pero no completa la reserva.

Procesamiento por lotes y concurrencia

El procesamiento por lotes agrupa trabajo para aprovechar mejor el hardware. El rendimiento agregado contabiliza la salida del conjunto de solicitudes; la velocidad por usuario describe el flujo que recibe una solicitud individual. Cerebras señala que agrupar solicitudes puede aumentar el rendimiento y, al mismo tiempo, añadir espera. Fuente: explicación del rendimiento de Cerebras.

Al operar el sistema, hay una pregunta clave: ¿cada conversación sigue avanzando cuando llegan otras? Mide con un tráfico simultáneo representativo e incluye las solicitudes fallidas y los reintentos. Un buen resultado en un endpoint sin más actividad deja esa pregunta sin responder.

Región y entrega de la respuesta

La ubicación de tu aplicación y del endpoint de inferencia influye en el retraso de red. Groq distingue los tiempos del servidor de la latencia que percibe el cliente en sus indicaciones para analizar la red.

Mide desde la región donde se ejecuta tu backend. Si la aplicación reenvía el flujo al navegador, añade una medición en el navegador: la acumulación de datos en búferes entre ambos puntos puede hacer que una respuesta fluida en origen llegue en ráfagas. Corregir ese trayecto puede tener más efecto que cambiar de modelo.

Tokens por segundo según la GPU

Una GPU, el acelerador que ejecuta la inferencia, no tiene una cifra única de tokens por segundo que resulte útil al margen del modelo y la carga de trabajo. Para comparar hardware, el resultado debe ir acompañado del modelo, la precisión numérica, el contexto, la configuración de inferencia y la carga concurrente.

La cuantización reduce la precisión numérica para ahorrar memoria; sus efectos sobre la velocidad y la calidad dependen de la implementación. Cerebras documenta esa distinción en su explicación de la compresión de modelos. Consulta la guía de cuantización de LLM al comparar despliegues con modelos comprimidos y comprueba la calidad de las respuestas junto con los tiempos.

Cómo presentan los proveedores sus cifras de velocidad

Trata las velocidades publicadas como afirmaciones atribuidas a una fuente, con un modelo y una fecha. Las siguientes páginas de los proveedores se verificaron el 24 de octubre de 2026. Son cifras de los propios proveedores, no mediciones realizadas para este artículo.

Cerebras: una velocidad publicada con condiciones de despliegue

Cerebras, proveedor de inferencia, anuncia “~3000 tokens/s” para OpenAI GPT-OSS 120B en su tabla Developer. La misma página indica que el rendimiento varía según el modelo y la configuración, y que el acceso Developer está pensado para evaluación, no para producción. Fuente: precios de Cerebras.

Lo que necesitas saber es si el despliegue que puedes contratar atenderá tu carga de trabajo con la capacidad y los tiempos de respuesta que buscas. La tabla, por sí sola, no lo resuelve.

Tokens por segundo en Groq: revisa la fila del modelo

Groq, proveedor de inferencia, muestra “500” para OpenAI GPT-OSS 120B en la columna “SPEED (T/SEC)” de su tabla de modelos compatibles. Esa es la cifra que Groq publica para esa fila. Fuente: modelos compatibles de Groq.

Estas tablas no permiten establecer una proporción de velocidad entre proveedores para tu aplicación. Antes de afirmar que existe tal diferencia, necesitas comparar con los mismos prompts, ajustes de razonamiento, criterios de recuento de tokens, carga e intervalos de medición.

Para decidir entre velocidad y costo, compara el precio de una tarea completada correctamente y la capacidad que necesitas con la guía de precios de Cerebras y la guía de precios de Groq.

Dónde consultar mediciones independientes

Artificial Analysis, un servicio independiente de pruebas comparativas, ofrece un buen punto de partida para comparar modelos y proveedores de inferencia. Abre su clasificación de proveedores y revisa qué endpoint y qué carga de trabajo hay detrás de cada resultado.

Su metodología de evaluación del rendimiento especifica actualmente:

• Una carga de trabajo predeterminada de aproximadamente 10,000 tokens de entrada y al menos 1,500 tokens de respuesta.
• Resultados expresados como la mediana de las últimas 72 horas para las cargas habituales.
• Un servidor principal de pruebas en la zona us-central1-a de Google Cloud.
• Recuentos de rendimiento normalizados con o200k_base, en lugar del tokenizador nativo de cada modelo.

Esto proporciona una referencia común, no una garantía sobre tu aplicación. Comprueba el tamaño del prompt, el endpoint, el modo de razonamiento y la fecha antes de comparar resultados. Los prompts más largos pueden alterar tanto la espera hasta el primer token como la velocidad de salida.

En los modelos que ocultan parte de los tokens de razonamiento, Artificial Analysis calcula la velocidad de salida a partir del último 80% de los fragmentos de respuesta. El sencillo script que aparece a continuación no reproduce ese método ni la carga completa de la prueba. Mide el flujo de texto que recibe tu cliente.

Cómo medir tu propio flujo de texto

Mide en el cliente que recibe la respuesta y cuenta tokens de texto, no eventos del flujo. Un evento puede llegar sin texto o contener una porción de texto; si cuentas eventos, obtendrás fragmentos por segundo.

El siguiente ejemplo en Python utiliza la API de streaming de Groq y tiktoken, un tokenizador de texto. Informa de la espera hasta el primer fragmento de texto, el tiempo desde la solicitud hasta el último texto, el tiempo hasta el cierre del flujo y una estimación de los tokens de salida normalizados por segundo.

Instala las dependencias:

python3 -m pip install groq tiktoken

Configura GROQ_API_KEY en las variables de entorno. Asigna a GROQ_MODEL un modelo de texto sin razonamiento que esté disponible para tu cuenta en la lista de modelos compatibles de Groq y guarda un prompt representativo de tu aplicación en prompt.txt. Guarda este código como measure_stream.py y ejecuta python3 measure_stream.py.

import os
from pathlib import Path
from time import perf_counter

import tiktoken
from groq import Groq

encoder = tiktoken.get_encoding("o200k_base")
prompt = Path("prompt.txt").read_text(encoding="utf-8")
model = os.environ["GROQ_MODEL"]
parts = []
first = last = None

with Groq(max_retries=0) as client:
    start = perf_counter()
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for event in stream:
        now = perf_counter()
        if not event.choices:
            continue
        text = event.choices[0].delta.content or ""
        if not text:
            continue
        if first is None:
            first = now
        last = now
        parts.append(text)
    end = perf_counter()

if first is None:
    raise SystemExit("No text received; no text-speed measurement.")

# Tokenize after timing; never count events as tokens.
count = lambda text: len(encoder.encode(text, disallowed_special=()))
total_tokens = count("".join(parts))
post_first_tokens = total_tokens - count(parts[0])
span = last - first

print(f"First text chunk / TTFT estimate (s): {first - start:.3f}")
print(f"Request to last text (s): {last - start:.3f}")
print(f"Stream complete (s): {end - start:.3f}")
print(f"Normalized output tokens: {total_tokens}")
if span > 0 and post_first_tokens > 0:
    print(f"Post-first output tok/s (estimate): {post_first_tokens / span:.1f}")
else:
    print("Output tok/s unavailable: insufficient text delivery intervals.")

El SDK de Groq permite desactivar los reintentos automáticos. El ejemplo los desactiva para evitar que una muestra que parece correcta incluya, sin advertirlo, tiempos de espera por reintentos; una solicitud fallida debe registrarse como un fallo.

El cálculo de la tasa excluye el primer fragmento de texto tanto del recuento de tokens como del intervalo de entrega. Sigue la fórmula basada en fragmentos de las definiciones de Artificial Analysis. También omite los metadatos finales al localizar la llegada del último texto.

Utiliza este ejemplo para texto simple. Un flujo de razonamiento, los argumentos de una llamada a herramientas o el audio requieren un tratamiento específico de sus tipos de evento y una definición de qué se considera la primera salida útil. Para comparar, conserva el prompt y los ajustes, registra la longitud de la salida y repite las pruebas desde la región de tu despliegue con una carga representativa. Conserva los resultados habituales y los lentos; no conviertas la muestra más rápida en una garantía.

Qué puedes saber con una calculadora o un simulador

Una herramienta de planificación puede mostrar qué implica un supuesto sobre los tiempos, pero no descubrir el retraso de tu endpoint.

Simulador de tokens por segundo

Usa un simulador para debatir si una interfaz de chat debe mostrar el texto a medida que llega o esperar a que se complete un objeto. Después, valida ese diseño con un flujo real. Una tasa constante simulada no permite saber si la respuesta real se detiene, llega en ráfagas o espera a una herramienta.

Para una respuesta de texto completada, la cuenta es sencilla: el tiempo desde la solicitud hasta el último texto equivale a la espera inicial más el intervalo entre el primer texto y el último. El script mide ambos intervalos en lugar de deducirlos de una velocidad anunciada.

¿Cuántos tokens por segundo son suficientes?

El objetivo útil depende de los momentos de espera que haya en la tarea. Para fijarlo, responde a estas preguntas sobre la experiencia que estás construyendo.

Si desarrollas una aplicación de voz: ¿cuánto espera quien llama desde que termina una frase hasta que escucha una respuesta útil? ¿Puede empezar la voz antes de que se haya escrito toda la respuesta? ¿Se queda sin datos el búfer de audio? ¿Puede interrumpir la persona que llama? Si el silencio aparece antes de que empiece el texto, una mayor velocidad de decodificación puede dejar intacto el problema principal.

Si desarrollas un chat: ¿el usuario espera la primera frase útil, la explicación completa o un resultado estructurado válido? ¿Puede la interfaz mostrar una salida parcial? Una respuesta de soporte y un informe exportable tienen distintos puntos de finalización. Mide el evento que necesita tu interfaz.

Si operas un agente: ¿qué parte de la tarea corresponde a la generación del modelo y qué parte a la ejecución de herramientas? ¿Una respuesta más rápida mantiene los argumentos correctos de las herramientas y permite completar bien la tarea? ¿El siguiente paso espera a recibir toda la salida? Mejorar el intervalo equivocado puede dejar casi igual el tiempo total del flujo de trabajo.

Si vas a contratar un proveedor: ¿el despliegue propuesto puede mantener la experiencia que necesitas con tu tráfico, desde tu región y con tus prompts? ¿La cifra anunciada es habitual en ese despliegue? ¿Qué ocurre cuando fallan las solicitudes o la capacidad está ocupada?

Actúa cuando las trazas indiquen que los usuarios esperan por la generación o por la primera respuesta útil. Pospón el cambio de proveedor si todavía no has identificado el retraso dominante. Un trabajo en segundo plano que ya cumple su plazo de finalización apenas se beneficia de una cifra de velocidad más alta, salvo que el rendimiento agregado o el costo por tarea completada correctamente cambien la decisión.

¿Qué se exagera al hablar de la velocidad de los LLM?

La mayor exageración consiste en asumir que la tasa de salida más alta identifica el mejor endpoint para una aplicación. La velocidad no demuestra la calidad de la respuesta, la validez de la salida ni el uso correcto de herramientas.

Todo endpoint rápido acaba encontrando el límite de la aplicación que lo rodea. Generar texto más deprisa no arregla una consulta lenta a la base de datos, un razonamiento innecesariamente largo o una respuesta que no supera la validación. Del mismo modo, un excelente tiempo hasta el primer token puede ocultar un flujo que se atasca antes de entregar algo útil al usuario.

Incluye la velocidad en la evaluación, pero fija la meta en un resultado correcto y utilizable.

Preguntas frecuentes

El siguiente paso para tu aplicación

En la próxima iteración, toma un turno de voz, un prompt de chat o una tarea de agente representativos y define qué hace que su resultado sea utilizable. Añade una medición de ese evento junto a la primera salida y la finalización del flujo. Compara los endpoints candidatos con la misma tarea, revisa los fallos y optimiza el intervalo que mantiene al usuario esperando.

Para recibir guías prácticas sobre cómo crear aplicaciones de IA útiles, suscríbete al boletín.