LLM Evaluación comparativa de latencia por casos de uso
Realizamos un benchmark de 11 de los principales grandes modelos de lenguaje con un total de 1,320 solicitudes, separando modelos de razonamiento y de no razonamiento , y medimos la latencia del primer token, la latencia por token y el tiempo total de respuesta.
Benchmark de latencia de LLM
Aquí puede consultar los detalles sobre cómo medimos la latencia.
Tiempo de respuesta total por modelo
Resultados del benchmark de latencia de LLM
Presentamos por separado los modelos de razonamiento y los que no razonan. Los primeros pasan varios segundos pensando antes de ofrecer la primera respuesta visible, por lo que compararlos directamente con los no razonadores en latencia sería engañoso. Algunos modelos incluso cambian de comportamiento según la tarea: GPT-5.2 responde a preguntas y respuestas sin razonar, pero razona ante las instrucciones de código.
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 la respuesta completa tiene solo una o dos frases. Los modelos sin razonamiento se agrupan en la zona 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 en alcanzar 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 supone sobre todo un costo adicional, ya que la respuesta en sí es breve.
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 y el tiempo total de respuesta son los que mandan. claude-haiku-4-5 lideró ambos, transmitiendo a aproximadamente 180 tokens por segundo y terminando en unos 5.5 segundos. Los demás 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 arrojaron 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ápido una vez que arrancan (hy3-preview funciona a cerca de 200 tokens por segundo), pero el pensamiento inicial mantiene alto el tiempo total.
Se limitó la longitud de la salida 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. A los modelos de razonamiento se les concedió un presupuesto adicional a este límite para alojar sus tokens de pensamiento, de modo que sus tiempos totales reflejen pensamiento más respuesta y no 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 pequeña.
- En el caso largo, los modelos sin razonamiento se mantuvieron a la cabeza (Haiku fue el más rápido con aproximadamente 5.5 segundos), mientras que los modelos de 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 instrucciones cortas, pero se despega claramente en salidas largas gracias 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 solo desplazarse. En la tarea de codificación, MiniMax pasó de unos 13 segundos en la mediana a 42 segundos en p90, y Hunyuan de aproximadamente 16 a 46 segundos. El tiempo extra corresponde a 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 de razonamiento. Razona en cada solicitud pero piensa brevemente, de modo que su p90 se mantuvo cerca de 3.7 segundos. Razonar por sí mismo no hace impredecible a un modelo; la cantidad de pensamiento sí.
- 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 unos 11 segundos.
- Los modelos sin razonamiento se mantuvieron ajustados. Haiku 4.5 y Opus 4.8 mantuvieron el p90 dentro de 2 a 2.5 segundos aproximadamente. Incluso Sonnet 5, que se ensanchó en salidas largas (unos 4 segundos en la mediana frente 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, de unos 13 segundos, no es la peor del grupo, pero su p90 de aproximadamente 42 segundos iguala al de Hunyuan, de modo que en una mala solicitud es tan lento como lo peor que se ha medido.
Razonamiento de LLM 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, pasando de alrededor de un segundo para los modelos sin razonamiento a varios segundos o más.
El hecho de que un modelo razone no es siempre 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 cada modelo razonó:
GPT-5.2 lo muestra directamente: respondió a las instrucciones breves de Q&A sin razonar, pero razonó en la mayoría de las instrucciones de codificación. Para un modelo híbrido como este, “razonar” 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 por defecto. Varios son híbridos que pueden razonar bajo demanda pero se distribuyen con el pensamiento desactivado: Claude Opus 4.8, por ejemplo, admite pensamiento extendido, pero está desactivado por defecto, por lo que nunca generó tokens de razonamiento en nuestras ejecuciones y se mantuvo rápido, al igual que los demás modelos Claude (Opus 4.7, Sonnet 5, Haiku 4.5).
El resto razonó en casi todas las solicitudes, razón por la cual aparecen como más lentos en la primera respuesta. Así que “nunca razona” aquí significa que no lo hace por defecto, no que carezca de la capacidad. GPT-5.2 destaca porque tomó esa decisión por sí mismo, activando el razonamiento para las instrucciones de codificación más difíciles y dejándolo desactivado en Q&A.
Efecto del endpoint en la latencia de los LLM
La latencia de un modelo alojado no depende solo del modelo. También incluye la infraestructura de servicio del proveedor, las colas, la ruta de red y la geografía. Nuestro plantel 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 la API propia de Anthropic, tardó alrededor de 2 segundos.
Se trata de versiones distintas, por lo que la diferencia no se debe exclusivamente 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, de modo que el endpoint europeo de Vertex disfrutaba de una ruta de red más corta, lo que explica en parte su ventaja.
Para ver cómo elegimos el proveedor de cada modelo, lea nuestra metodología del benchmark.
Límite máximo de tokens y modelos de razonamiento
Para medir la latencia de forma justa, establecimos una longitud máxima de salida fija para que ningún modelo se vea recompensado o penalizado por escribir más. Ese tope es el presupuesto de tokens para toda la respuesta, y es de donde provinieron la mayoría de los fallos:
- Los modelos de razonamiento gastan parte del presupuesto en pensar antes de que empiece la respuesta.
- En instrucciones de codificación difíciles, algunos piensan mucho, y de forma impredecible (MiniMax utilizó entre 2,500 y 3,700 tokens de pensamiento en una sola instrucción).
- Cuando el pensamiento ocupa todo el presupuesto, no quedan tokens para la respuesta y esta llega vacía.
- Esto afectó especialmente 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 conviene vigilar: si se fija demasiado bajo, un modelo de razonamiento puede consumirlo todo pensando y no llegar nunca a dar una respuesta. Aumentamos el presupuesto para los modelos de 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 rellenaron, aunque unas pocas siguieron fallando cuando el pensamiento de un modelo superó incluso el presupuesto ampliado.
Añadir como fuente preferidaMetodología del benchmark de latencia de LLM
Realizamos un benchmark de 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 otros seis modelos 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 instrucciones
Utilizamos dos casos de uso con longitudes de entrada y salida fijas, de modo que los resultados reflejen la velocidad y no cuán larga resultó una instrucción o respuesta:
- Respuesta corta (Q&A): entrada corta (unos 256 tokens), salida corta (limitada a 128 tokens). Ejemplo: “What is the purpose of a primary key in a database?”
- Respuesta larga (generación de código): entrada corta (unos 512 tokens), salida larga (limitada a 1,024 tokens). Ejemplo: “Build a multi-threaded URL downloader in Python that takes a list of image URLs and downloads them concurrently.”
Cada caso de uso empleó 20 instrucciones, y cada instrucción se envió 3 veces por modelo, lo que arroja 60 mediciones por modelo y 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 ahí derivamos el tiempo hasta el primer token, el tiempo hasta el primer token de respuesta, la latencia por token y la velocidad de salida, así como el tiempo total.
Razonamiento frente a no razonamiento
Cada respuesta devuelve un resumen de uso que incluye un conteo de tokens de razonamiento. Leímos esto en cada solicitud y marcamos la solicitud como de razonamiento cuando el conteo era superior a cero y como de no razonamiento cuando era cero, en lugar de basarnos 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 distintos proveedores a diferentes velocidades, por lo que fijamos cada modelo a un único 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 utilizamos esas cifras para elegir. Descartamos cualquier proveedor por debajo de aproximadamente un 98 por ciento de tiempo de actividad, y luego elegimos el más rápido del resto según 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. Unos pocos de los proveedores más rápidos no eran accesibles con nuestra cuenta y devolvieron errores de límite de tasa, por lo que utilizamos el proveedor más rápido que ofreció un servicio 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 del cliente.
- La longitud de salida se limitó (128 para caso corto, 1,024 para caso largo) para que la verbosidad no distorsione la latencia. Los modelos de razonamiento recibieron un presupuesto extra para pensamiento además de este límite.
- Cada instrucción comenzaba con un bloque de texto único para evitar el almacenamiento en caché de instrucciones, y verificamos que ningún token de entrada procediera 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 Evaluación comparativa de latencia por casos de uso}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Recuperado el 8 de Julio 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.
Siguiente para leer
Los 6 mejores creadores de apps con IA: Lovable, Base44 y Glide
Comparativa de VPN de los 5 principales proveedores de VPN
Comparación de VPS: Hetzner vs Digital Ocean
Benchmark de Reranker: Comparación de los 8 Mejores Modelos
Ejecución de código con MCP: un nuevo enfoque para la eficiencia de los agentes de IA
Herramientas de detección de alucinaciones de IA: W&B Weave y Comet
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.