LLM Comparativa de latencia por casos de uso
Evaluamos 11 modelos de lenguaje grandes principales con un total de 1.320 solicitudes, dividiendo modelos de razonamiento y no razonamiento, y medimos la latencia del primer token, la latencia por token y el tiempo de respuesta total.
LLM comparativa de latencia
Puede encontrar detalles sobre cómo medimos la latencia aquí.
Tiempo de respuesta de extremo a extremo por modelo
LLM resultados de la comparativa de latencia
Presentamos por separado los modelos con razonamiento y sin él. Los modelos de 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 de comportamiento según la tarea: GPT-5.2 responde a Q&A sin razonamiento, pero razona en las instrucciones de codificación.
Caso de respuesta corta (Q&A)
En el caso corto lo que importa es la rapidez con 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 de razonamiento fueron más lentos para llegar a la primera palabra de 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 preguntas cortas, el paso de pensamiento es principalmente sobrecarga, ya que la respuesta en sí es corta.
Caso de respuesta larga (generación de código)
En el caso largo, la latencia del primer token importa menos, y la velocidad de transmisión spIn the long case the first-token delay matters less, and streaming speed and total response time take over. claude-haiku-4-5 lideró ambos, transmitiendo a 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 de 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 aproximadamente 200 tokens por segundo), pero el pensamiento inicial mantiene el total alto.
La longitud de salida se limitó en lugar de dejarla abierta, por lo que los modelos no se comparan en verbosidad: aproximadamente 128 tokens para respuestas cortas y 1.024 para respuestas largas. Los modelos de razonamiento recibieron 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 pensamiento 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 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 el más rápido con aproximadamente 5.5 segundos), mientras que los modelos de razonamiento se quedaron muy atrás con 18 a 35 segundos.
- El orden dentro del grupo sin razonamiento también cambia: Haiku fue uno de varios modelos que arrancaron en menos de un segundo en indicaciones cortas, pero se destaca claramente en salidas largas debido a su velocidad de transmisión.
Latencia en el percentil 90
El patrón principal es que la cola se multiplica para los modelos de razonamiento en lugar de simplemente desplazarse. En la tarea de codificación, MiniMax pasó de aproximadamente 13 segundos en la mediana a 42 segundos en p90, y Hunyuan de aproximadamente 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.
Algunos puntos destacan:
- MiMo es la excepción entre los modelos de 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 modelo sea impredecible; es 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 codificación, donde activa el razonamiento, su p90 subió a aproximadamente 11 segundos.
- Los modelos sin razonamiento se mantuvieron ajustados. 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 (aproximadamente 4 segundos en la mediana a 8 en p90), se mantuvo muy por debajo del grupo de razonamiento.
La cuestión práctica es que la mediana puede ocultar esto. La mediana de MiniMax en codificación, aproximadamente 13 segundos, no es la peor del grupo, pero su p90 de aproximadamente 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 de 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 para los modelos sin razonamiento a varios segundos o más.
Que un modelo razone no siempre es fijo. Detectamos el razonamiento por solicitud a partir del número 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 modelo:
GPT-5.2 lo muestra directamente: respondió a indicaciones breves de Q&A sin razonamiento, pero razonó en la mayoría de las indicaciones de codificación. Para un modelo híbrido como este, “razonamiento” no es una etiqueta fija; el modelo 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 codificación.
Medimos cada modelo en su estado predeterminado. Varios son híbridos que pueden razonar bajo demanda, pero se entregan con el pensamiento desactivado: Claude Opus 4.8, por ejemplo, admite pensamiento extendido, pero está deshabilitado por defecto, por lo que nunca produjo tokens de razonamiento en nuestras pruebas y se mantuvo rápido, al igual que los otros 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. Así que “nunca razona” aquí significa no por defecto, no que la capacidad esté ausente. GPT-5.2 destaca porque tomó esta decisión por sí mismo, activando el razonamiento para las indicaciones de codificación más difíciles mientras lo dejaba desactivado para Q&A.
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, la cola, la ruta de red y la geografía. Nuestra lista muestra esto dentro de una sola 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 la API propia de Anthropic, tardó aproximadamente 2 segundos.
Estas son versiones diferentes, por lo que la diferencia no es puramente del 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 dependiendo de 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, razón por la cual salió adelante.
Para ver cómo elegimos el proveedor para cada modelo, lea nuestra metodología de comparativa.
Límite máximo de tokens y modelos de razonamiento
Para medir la latencia de manera justa, establecimos una longitud máxima de salida 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 provienen la mayoría de los fallos:
- Los modelos de razonamiento gastan parte del presupuesto en pensar antes de que comience la respuesta.
- En indicaciones de codificación difíciles, algunos piensan mucho y de manera impredecible (MiniMax usó aproximadamente de 2.500 a 3.700 tokens de pensamiento en una sola indicación).
- Cuando el pensamiento llena todo el presupuesto, no quedan tokens para la respuesta y la respuesta vuelve vacía.
- Esto afectó más a MiniMax en codificació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 establece demasiado bajo, un modelo de razonamiento puede gastarlo todo pensando y nunca llegar a una respuesta. Aumentamos el presupuesto para los modelos de razonamiento, dimos margen para el pensamiento además de la longitud de la respuesta y reintentamos las solicitudes fallidas. La mayoría de las brechas se llenaron, aunque algunas aún fallaron cuando el pensamiento de un modelo superó incluso el presupuesto más amplio.
Añadir como fuente preferidaLLM metodología de la comparativa de latencia
Evaluamos 11 modelos de lenguaje con 1.320 solicitudes, midiendo la rapidez con que responde cada modelo.
Modelos
Tomamos los cinco modelos más utilizados en OpenRouter y añadimos seis modelos más actuales:
- 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 ejemplos de indicaciones
Usamos dos casos de uso con longitudes de entrada y salida fijas, para que los resultados reflejen la velocidad y no lo larga que fuera una indicación o 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: “Construye un descargador de URL multihilo en Python que tome una lista de URLs de imágenes y las descargue de forma concurrente.”
Cada caso de uso utilizó 20 indicaciones, y cada indicación se envió 3 veces por modelo, lo que da 60 mediciones por modelo por caso de uso. Informamos la mediana (p50) y el 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 esto 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.
Razonamiento vs. no razonamiento
Cada respuesta devuelve un resumen de uso que incluye un recuento de tokens de razonamiento. Leímos esto para cada solicitud y marcamos la solicitud como razonamiento cuando el recuento era superior a cero y sin razonamiento cuando era cero, en lugar de confiar en la etiqueta del modelo. Así descubrimos que GPT-5.2 razona en codificación pero no en Q&A.
Cómo elegimos los proveedores
El mismo modelo es servido por diferentes proveedores a diferentes velocidades, por lo que fijamos cada modelo a un proveedor en lugar de dejar que las solicitudes se enruten libremente. OpenRouter enumera el tiempo de actividad, la latencia y el rendimiento de cada proveedor, y utilizamos esas cifras para elegir. Descartamos cualquier proveedor por debajo de aproximadamente 98 por ciento de tiempo de actividad, luego elegimos el 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 devolvieron errores de límite de velocidad, por lo que utilizamos el proveedor más rápido que sirvió de manera 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 corta, 1.024 para larga) para que la verbosidad no distorsione la latencia. Los modelos de razonamiento recibieron un presupuesto adicional para pensar además de este límite.
- Cada indicación comenzaba con un bloque de texto único para evitar el almacenamiento en caché de indicaciones, y verificamos que ningún token de entrada proviniera 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 Comparativa de latencia por casos de uso}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Recuperado el 12 de Agosto de 2026}
}Resultados y marcas de tiempo de 1.3 mil puntos de datos. Descargue los datos utilizados en este artículo como un archivo ZIP que contiene un archivo CSV y un README.
El trabajo de Cem ha sido citado por publicaciones globales líderes como Business Insider, Forbes, Washington Post, firmas globales como Deloitte, HPE y ONG como el Foro Económico Mundial y organizaciones supranacionales como la Comisión Europea.
A lo largo de su carrera, Cem se ha desempeñado 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.
Lideró la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando directamente al CEO. También lideró el crecimiento comercial de la empresa de tecnología profunda Hypatos, que alcanzó 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 habla regularmente en conferencias internacionales de tecnología. Se graduó de la Universidad de Bogazici 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.