LLM Benchmark de latencia por casos de uso
We benchmarked 11 top large language models with a total of 1,320 requests, splitting reasoning and non-reasoning models, and measured first-token latency, per-token latency, and overall response time.
Aquí puede encontrar detalles sobre cómo medimos la latencia.
Tiempo de respuesta de extremo a extremo por model
LLM Resultados del benchmark de latencia
Informamos por separado de los models con razonamiento y sin razonamiento. Los models con razonamiento pasan varios segundos pensando antes de la primera respuesta visible, por lo que compararlos directamente con los models sin razonamiento en latencia sería engañoso. Algunos models también cambian de comportamiento según la tarea: GPT-5.2 responde a Q&A sin razonar, pero razona en los prompts de programación.
Caso de respuesta corta (Q&A)
En el caso corto, lo que importa es lo rápido que aparece el primer token de respuesta, ya que toda la respuesta es solo una o dos frases. Los models sin razonamiento se agrupan en la región de baja latencia:
- claude-opus-4-8: 0,75 segundos
- gpt-5-2: 0,8 segundos
- claude-haiku-4-5: 0,96 segundos
- claude-sonnet-5: 1,5 segundos
- claude-opus-4-7: 2 segundos
Los models con razonamiento fueron más lentos en alcanzar la primera palabra de la respuesta incluso aquí, porque primero piensan:
- mimo-v2-5: 1,2 segundos
- minimax-m3: 2,4 segundos
- deepseek-v4-flash: 3,6 segundos
- gemini-3-1-pro-preview: 9 segundos
- hy3-preview: 14,6 segundos
En las preguntas cortas, el paso de pensamiento es sobre todo una sobrecarga, ya que la respuesta en sí es corta.
Caso de respuesta larga (generación de código)
En el caso largo la demora del primer token importa menos y la velocidad de transmisión spEn el caso largo la demora del primer token importa menos y la velocidad de transmisión y el tiempo total de respuesta pasan a dominar. claude-haiku-4-5 lideró en ambos, transmitiendo a unos 180 tokens por segundo y terminando en unos 5,5 segundos. Los demás models sin razonamiento terminaron en aproximadamente 10 a 13 segundos: claude-sonnet-5 en 10 segundos, claude-opus-4-8 en 10.8, y claude-opus-4-7 en 12.7.
Los models con razonamiento produjeron tiempos totales más largos, porque el pensamiento y la salida larga se suman:
- gemini-3-1-pro-preview: 18,5 segundos
- hy3-preview: 23,1 segundos
- deepseek-v4-flash: 24,3 segundos
- minimax-m3: 28,1 segundos
- mimo-v2-5: 35 segundos
Algunos transmiten rápidamente una vez que comienzan (hy3-preview funciona a unos 200 tokens por segundo), pero el pensamiento inicial mantiene alto el total.
La longitud de salida se limitó en lugar de dejarse abierta, por lo que los models no se comparan en verbosidad: aproximadamente 128 tokens para respuestas cortas y 1.024 para respuestas largas. A los models con razonamiento se les dio un presupuesto adicional más allá de este límite para contener sus tokens de pensamiento, de modo que sus tiempos de extremo a extremo reflejan el razonamiento más la respuesta en lugar de una respuesta cortada a mitad del pensamiento.
Respuestas cortas frente a respuestas largas
El contraste entre los dos casos es la principal conclusión:
- En el caso corto, los models más rápidos respondieron en menos de un segundo y la dispersión fue reducida.
- En el caso largo, los models sin razonamiento se mantuvieron cerca del frente (Haiku más rápido, en unos 5,5 segundos), mientras que los models con razonamiento quedaron muy por detrás, entre 18 y 35 segundos.
- El orden dentro del grupo sin razonamiento también cambia: Haiku fue uno de varios que arrancaron por debajo del segundo en los prompts cortos, pero se adelanta claramente en las salidas largas gracias a su velocidad de transmisión.
Latencia en el percentil 90
El patrón principal es que la cola se multiplica en los models con razonamiento en lugar de simplemente desplazarse. En la tarea de programación, MiniMax pasó de unos 13 segundos en la mediana a 42 segundos en el p90, y Hunyuan de unos 16 a 46 segundos. El tiempo adicional es pensamiento, y la duración del pensamiento varía de una solicitud a otra, por lo que estos models no solo son más lentos, sino también menos predecibles.
Destacan algunos puntos:
- MiMo es la excepción entre los models con razonamiento. Razona en cada solicitud, pero piensa brevemente, por lo que su p90 se mantuvo cerca de 3,7 segundos. El razonamiento por sí solo no hace que un model sea impredecible; lo hace la cantidad de pensamiento.
- GPT-5.2 muestra una cola solo donde razona. En Q&A su p90 fue inferior a 2 segundos, pero en programación, donde activa el razonamiento, su p90 subió a unos 11 segundos.
- Los models sin razonamiento se mantuvieron estables. Haiku 4.5 y Opus 4.8 mantuvieron el p90 en un rango de unos 2 a 2,5 segundos. Incluso Sonnet 5, que se amplió en salidas largas (unos 4 segundos en la mediana a 8 en p90), se mantuvo muy por debajo del grupo con razonamiento.
El punto práctico es que la mediana puede ocultar esto. La mediana de MiniMax en programación, de unos 13 segundos, no es la peor del grupo, pero su p90 de unos 42 segundos coincide con Hunyuan, por lo que en una solicitud mala es tan lento como cualquier cosa medida.
LLM razonamiento y su efecto en la velocidad
Los models con razonamiento tardan más en producir su primer token de respuesta porque generan tokens internos de cadena de pensamiento antes de la respuesta visible. Ese paso de pensamiento es lo que eleva su tiempo hasta la primera respuesta, de aproximadamente un segundo en los models sin razonamiento a varios segundos o más.
El que un model razone no siempre es fijo. Detectamos el razonamiento por solicitud a partir de la cantidad de tokens de razonamiento que devolvió cada respuesta y luego agrupamos los resultados por tarea. La proporción de solicitudes en las que razonó cada model:
GPT-5.2 lo muestra directamente: respondió a prompts cortos de Q&A sin razonamiento, pero razonó en la mayoría de los prompts de programación. Para un model híbrido como este, el “razonamiento” no es una etiqueta fija; el model decide en función de la tarea y su latencia cambia con esa decisión. Por eso GPT-5.2 se sitúa en el grupo rápido en Q&A, pero retrocede en programación.
Medimos cada model en su estado predeterminado. Varios son híbridos que pueden razonar a demanda, pero se envían con el pensamiento desactivado: Claude Opus 4.8, por ejemplo, admite pensamiento extendido, pero está deshabilitado de forma predeterminada, por lo que nunca produjo tokens de razonamiento en nuestras ejecuciones y se mantuvo rápido, al igual que los demás Claude models (Opus 4.7, Sonnet 5, Haiku 4.5).
El resto razonó en casi todas las solicitudes, por lo que parecen más lentos hasta la primera respuesta. Por lo tanto, “nunca razona” aquí significa que no lo hace de forma predeterminada, no que le falte la capacidad. GPT-5.2 destaca porque tomó esta decisión por sí solo: activó el razonamiento en los prompts de programación más difíciles y lo dejó desactivado en Q&A.
Efecto del endpoint en la latencia para los LLMs
La latencia de un model alojado no es solo el model. También incluye la pila de servicio del proveedor, la cola, la ruta de red y la geografía. Nuestro listado muestra esto dentro de una única línea de model. Claude Opus 4.8, servido a través de Google Vertex en Europa, devolvió su primer token en unos 0,75 segundos, mientras que Claude Opus 4.7, servido a través de Anthropic, con su propia API, tardó unos 2 segundos.
Se trata de versiones diferentes, por lo que la brecha no se debe únicamente al endpoint, pero el patrón coincide con un efecto bien conocido: los mismos pesos pueden ser varias veces más rápidos o más lentos según dónde y cómo se sirvan. Nuestro cliente de medición se ejecutó en Europa, por lo que el endpoint europeo de Vertex tenía una ruta de red más corta, lo que en parte explica por qué salió adelante.
Para ver cómo elegimos el proveedor de cada model, lea nuestra metodología del benchmark.
Límite máximo de tokens y models con razonamiento
Para medir la latencia de forma justa, establecimos una longitud máxima de salida fija para que ningún model sea recompensado o penalizado por escribir más. Ese límite es el presupuesto de tokens para toda la respuesta y es de donde provinieron la mayoría de los fallos:
- Los models con razonamiento gastan parte del presupuesto en pensar antes de que comience la respuesta.
- En los prompts de programación difíciles, algunos piensan mucho y de forma impredecible (MiniMax usó entre 2.500 y 3.700 tokens de pensamiento en un solo prompt).
- Cuando el pensamiento llena todo el presupuesto, no quedan tokens para la respuesta y esta regresa vacía.
- Esto afectó más a MiniMax en programación, donde la primera pasada completó menos de la mitad de sus solicitudes.
La conclusión es que el límite máximo de tokens es un parámetro que vale la pena vigilar: si se configura demasiado bajo, un model con razonamiento puede gastarlo todo en pensar y nunca llegar a una respuesta. Aumentamos el presupuesto para los models con razonamiento, dimos espacio para el pensamiento además de la longitud de la respuesta y reintentamos las solicitudes fallidas. La mayoría de los huecos se llenaron, aunque algunos pocos seguían fallando cuando el pensamiento de un model superaba incluso el presupuesto mayor.
Añadir como fuente preferidaLLM Metodología del benchmark de latencia
Realizamos un benchmark de 11 models de lenguaje con 1.320 solicitudes, midiendo la rapidez con la que responde cada model.
Models
Tomamos los cinco models más utilizados en OpenRouter y añadimos otros seis models actuales además:
- Sin razonamiento por defecto: Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5, Claude Haiku 4.5, GPT-5.2
- Con razonamiento por defecto: DeepSeek V4 Flash, Xiaomi MiMo v2.5, MiniMax M3, Gemini 3.1 Pro, Tencent Hunyuan HY3, Claude Fable 5
Casos de uso y prompts de ejemplo
Utilizamos dos casos de uso con longitudes de entrada y salida fijas, de modo que los resultados reflejan la velocidad y no la extensión que tuviera un prompt o una respuesta:
- Respuesta corta (Q&A): entrada corta (aproximadamente 256 tokens), salida corta (limitada a 128 tokens). Ejemplo: “¿Cuál es el propósito de una clave primaria en una base de datos?”
- Respuesta larga (generación de código): entrada corta (aproximadamente 512 tokens), salida larga (limitada a 1.024 tokens). Ejemplo: “Crea un descargador de URL multiproceso en Python que reciba una lista de URL de imágenes y las descargue de forma concurrente.”
Cada caso de uso utilizó 20 prompts, y cada prompt se envió 3 veces por model, lo que da 60 mediciones por model y caso de uso. Informamos de la mediana (p50) y del p90.
Qué medimos
Transmitimos cada respuesta y registramos cuándo se envió la solicitud, cuándo llegó el primer token, cuándo llegó el primer token de respuesta (después de cualquier pensamiento) y cuándo llegó el último token. A partir de estos datos obtuvimos el tiempo hasta el primer token, el tiempo hasta el primer token de respuesta, la latencia por token y la velocidad de salida, y el tiempo de extremo a extremo.
Razonamiento frente a no razonamiento
Cada respuesta devuelve un resumen de uso que incluye un recuento de tokens de razonamiento. Leímos este resumen en cada solicitud y marcamos la solicitud como con razonamiento cuando el recuento era superior a cero y sin razonamiento cuando era cero, en lugar de fiarnos de la etiqueta del model. Así descubrimos que GPT-5.2 razona en programación, pero no en Q&A.
Cómo elegimos los proveedores
El mismo model es servido por diferentes proveedores a diferentes velocidades, por lo que fijamos cada model a un proveedor en lugar de dejar que las solicitudes se enrutaran libremente. OpenRouter enumera el tiempo de actividad, la latencia y el rendimiento de cada proveedor, y usamos esas cifras para elegir. Descartamos cualquier proveedor con un tiempo de actividad inferior a un 98 por ciento y, entre el resto, elegimos el más rápido por latencia y rendimiento. Fijamos ese proveedor para cada solicitud y registramos el proveedor que realmente sirvió cada respuesta para confirmar que la fijación se mantenía. Algunos de los proveedores más rápidos no eran accesibles con nuestra cuenta y devolvían errores de límite de velocidad, por lo que usamos el proveedor más rápido que sirvió de forma fiable.
Los proveedores fijados fueron Claude Opus 4.8 en Google Vertex (Europa), Claude Opus 4.7 en Anthropic, Claude Sonnet 5 y GPT-5.2 en Azure, Claude Fable 5 y Claude Haiku 4.5 en Amazon Bedrock, DeepSeek V4 Flash en Novita, MiMo v2.5 en DeepInfra, MiniMax M3 en Together, Gemini 3.1 Pro en Google Vertex, y Hunyuan HY3 en GMICloud.
Controles
- Todas las solicitudes se ejecutaron desde una única región de cliente.
- La longitud de salida se limitó (128 para cortas, 1.024 para largas) para que la verbosidad no distorsione la latencia. Los models con razonamiento recibieron un presupuesto adicional para el pensamiento además de este límite.
- Cada prompt comenzaba con un bloque de texto único para evitar el almacenamiento en caché de prompts, y verificamos que ningún token de entrada procediera de la caché.
- Todos los recuentos de tokens usan un único tokenizador para que la velocidad sea comparable entre models.
Cita este benchmark
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{LLM Benchmark de latencia por casos de uso}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Recuperado el 6 de agosto de 2026}
}Resultados y marcas de tiempo de 1.4 mil puntos de datos. Descargue los datos resumidos que se muestran en los gráficos y las tablas de este artículo como un archivo ZIP que contiene 6 archivos CSV y un README.
¿Quieres los datos granulares que hay detrás? Únete a Premium
Registro de cambios
5 actualizacionesSe reemplazaron los rangos de latencia aproximados por valores de tiempo precisos por modelo en el benchmark de latencia.
Se reemplazó la lista de modelos evaluados por 11 modelos actuales con y sin razonamiento.
Ampliación de la sección "Resultados de la evaluación comparativa de latencia de LLM" con resultados detallados de la latencia del primer token y la latencia por token.
El trabajo de Cem en AIMultiple ha sido citado por publicaciones líderes mundiales como Business Insider, Forbes, Morning Brew y Washington Post, empresas globales como Deloitte y HPE, ONG como World Economic Forum y organizaciones supranacionales como European Commission. [1], [2], [3], [4], [5]
A lo largo de su carrera, Cem trabajó como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.
Dirigió la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando al CEO. También lideró el crecimiento comercial de la empresa de deep tech Hypatos, que alcanzó unos ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.
Cem participa habitualmente en conferencias internacionales de tecnología. Se graduó en Bogazici University como ingeniero informático y tiene un MBA de Columbia Business School.
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.