LLM Prueba comparativa 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 modelo
LLM Resultados del benchmark de latencia
Presentamos los modelos con razonamiento y sin razonamiento por separado. Los modelos con razonamiento pasan varios segundos pensando antes de la primera respuesta visible, por lo que compararlos directamente con los modelos sin razonamiento en latencia sería engañoso. Algunos modelos también cambian su comportamiento según la tarea: GPT-5.2 responde a las preguntas y respuestas sin razonar, pero razona en los prompts de programación.
Caso de respuesta corta (preguntas y respuestas)
En el caso corto, lo que importa es la rapidez con la que aparece el primer token de respuesta, ya que toda la respuesta es solo una o dos frases. Los modelos 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 modelos con razonamiento fueron más lentos hasta la primera palabra de respuesta incluso aquí, porque piensan primero:
- 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 preguntas cortas, el paso de pensamiento es principalmente una sobrecarga, ya que la respuesta en sí es corta.
Caso de respuesta larga (generación de código)
En el caso largo, el retraso del primer token importa menos, y la velocidad de streaming y el tiempo total de respuesta se imponen. claude-haiku-4-5 lideró ambos, con streaming de aproximadamente 180 tokens por segundo y terminando en aproximadamente 5,5 segundos. Los otros modelos 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 modelos 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 tiempo total.
La longitud de salida se limitó en lugar de dejarse abierta, por lo que no se compara a los modelos por verbosidad: aproximadamente 128 tokens para las respuestas cortas y 1.024 para las largas. A los modelos con razonamiento se les dio un presupuesto adicional más allá de este límite para contener sus tokens de pensamiento, por lo que sus tiempos de extremo a extremo reflejan el pensamiento más la respuesta, en lugar de una respuesta cortada a mitad del razonamiento.
Respuestas cortas frente a respuestas largas
El contraste entre los dos casos es la principal conclusión:
- En el caso corto, los modelos más rápidos respondieron en menos de un segundo y la dispersión fue estrecha.
- En el caso largo, los modelos sin razonamiento se mantuvieron cerca de la cabeza (Haiku fue el más rápido con unos 5,5 segundos), mientras que los modelos con razonamiento quedaron muy por detrás, con de 18 a 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 streaming.
Latencia en el 90 percentil
El patrón principal es que la cola se multiplica en los modelos 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 p90, y Hunyuan de unos 16 a 46 segundos. El tiempo extra es pensamiento, y la duración del pensamiento varía de una solicitud a otra, por lo que estos modelos no solo son más lentos, sino también menos predecibles.
Destacan algunos puntos:
- MiMo es la excepción entre los modelos con razonamiento. Razona en cada solicitud, pero piensa brevemente, por lo que su p90 se mantuvo cerca de 3,7 segundos. Razonar por sí solo no hace que un modelo sea impredecible; la cantidad de pensamiento sí.
- GPT-5.2 muestra una cola solo donde razona. En preguntas y respuestas, su p90 estuvo por debajo de 2 segundos, pero en programación, donde activa el razonamiento, su p90 subió a unos 11 segundos.
- Los modelos sin razonamiento se mantuvieron estables. Haiku 4.5 y Opus 4.8 mantuvieron el p90 dentro de aproximadamente 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.
La cuestión práctica es que la mediana puede ocultar esto. La mediana de MiniMax en programación, 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 otro medido.
LLM razonamiento y su efecto en la velocidad
Los modelos 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, desde aproximadamente un segundo en los modelos sin razonamiento hasta varios segundos o más.
El hecho de que un modelo razone no siempre es fijo. Detectamos el razonamiento en cada solicitud a partir del número de tokens de razonamiento que devolvió cada respuesta y luego agrupamos los resultados por tarea. El porcentaje de solicitudes en las que razonó cada modelo:
GPT-5.2 lo muestra directamente: respondió a los prompts cortos de preguntas y respuestas sin razonar, pero razonó en la mayoría de los prompts de programación. Para un modelo híbrido como este, «razonar» no es una etiqueta fija; el modelo decide según la tarea y su latencia cambia con esa decisión. Por eso GPT-5.2 se sitúa en el grupo rápido en preguntas y respuestas, pero retrocede en programación.
Medimos cada modelo en su estado predeterminado. Varios son híbridos que pueden razonar a demanda, pero vienen con el pensamiento desactivado: Claude Opus 4.8, por ejemplo, admite pensamiento extendido, pero está desactivado 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 modelos de Claude (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 tanto, aquí «nunca razona» significa que no lo hace por defecto, no que carezca de la capacidad. GPT-5.2 destaca porque tomó esta decisión por sí mismo, activando el razonamiento en los prompts de programación más difíciles y dejándolo desactivado en preguntas y respuestas.
Efecto del endpoint en la latencia para LLMs
La latencia de un modelo alojado no es solo el modelo. También incluye la pila de servicio del proveedor, las colas, la ruta de red y la geografía. Nuestra lista lo muestra dentro de una misma línea de modelo. Claude Opus 4.8, servido a través de Google Vertex en Europa, devolvió su primer token en aproximadamente 0,75 segundos, mientras que Claude Opus 4.7, servido a través de Anthropic y su propia API, tardó unos 2 segundos.
Se trata de versiones diferentes, por lo que la brecha no se debe solo 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 de Vertex europeo tenía una ruta de red más corta, lo que en parte explica que saliera mejor parado.
Para ver cómo elegimos el proveedor de cada modelo, lea nuestra metodología del benchmark.
Límite máximo de tokens y modelos con razonamiento
Para medir la latencia de forma justa, establecimos una longitud de salida máxima fija para que ningún modelo sea recompensado o penalizado por escribir más. Ese límite es el presupuesto de tokens para toda la respuesta y es de donde proceden la mayoría de los fallos:
- Los modelos con razonamiento gastan parte del presupuesto en pensar antes de que comience la respuesta.
- En los prompts difíciles de programación, algunos piensan mucho y de forma impredecible (MiniMax utilizó 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 la respuesta vuelve vacía.
- Esto afectó sobre todo a MiniMax en programación, donde en 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 conviene vigilar: si se ajusta demasiado bajo, un modelo con razonamiento puede gastarlo todo pensando y no llegar nunca a una respuesta. Aumentamos el presupuesto para los modelos con razonamiento, dimos margen para el pensamiento además de la longitud de la respuesta y reintentamos las solicitudes fallidas. La mayoría de las lagunas se llenaron, aunque algunas siguieron fallando cuando el pensamiento de un modelo superaba incluso el presupuesto mayor.
Añadir como fuente preferidaLLM metodología del benchmark de latencia
Realizamos un benchmark de 11 modelos de lenguaje con 1.320 solicitudes, midiendo la rapidez con la que responde cada modelo.
Modelos
Tomamos los cinco modelos más utilizados en OpenRouter y añadimos seis modelos actuales má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 lo largos que resultaran el prompt o la respuesta.
- Respuesta corta (preguntas y respuestas): entrada corta (unos 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 (unos 512 tokens), salida larga (limitada a 1.024 tokens). Ejemplo: «Crea un descargador de URL multihilo 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 modelo, lo que da 60 mediciones por modelo 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 derivamos 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.
Con razonamiento frente a sin razonamiento
Cada respuesta devuelve un resumen de uso que incluye un recuento de tokens de razonamiento. Lo leímos en cada solicitud y marcamos la solicitud como con razonamiento cuando el recuento era superior a cero y como sin razonamiento cuando era cero, en lugar de fiarnos de la etiqueta del modelo. Así descubrimos que GPT-5.2 razona en programación pero no en preguntas y respuestas.
Cómo elegimos los proveedores
El mismo modelo es servido por diferentes proveedores a distintas velocidades, por lo que fijamos cada modelo a un único proveedor en lugar de dejar que las solicitudes se enrutaran libremente. OpenRouter muestra la disponibilidad, la latencia y el rendimiento de cada proveedor, y usamos esas cifras para elegir. Descartamos a cualquier proveedor con menos de un 98 por ciento de disponibilidad y luego elegimos al más rápido del resto 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 mantuvo. 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 corto, 1.024 para largo) para que la verbosidad no distorsione la latencia. A los modelos con razonamiento se les dio 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 procedía de la caché.
- Todos los recuentos de tokens utilizan un único tokenizador para que la velocidad sea comparable entre modelos.
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 Prueba comparativa 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.