Al evaluar las API de modelos, comprender las compensaciones entre la latencia y el throughput (rendimiento) de los LLM es esencial para optimizar tanto la experiencia del usuario como los costos de infraestructura. La latencia mide el tiempo transcurrido para que un modelo responda a una consulta, mientras que el throughput mide el volumen de tokens procesados o generados por el sistema durante un intervalo de tiempo específico. Para los desarrolladores y creadores de productos de IA, optimizar una métrica a menudo requiere hacer concesiones con la otra.
Seleccionar la métrica de velocidad incorrecta puede derivar en interfaces de usuario lentas o facturas de API innecesariamente altas. Este análisis proporciona un marco para medir estas métricas, seleccionar las API adecuadas para sus cargas de trabajo específicas e implementar estrategias de optimización.
Conclusiones clave
- Time to First Token (TTFT) es la métrica de latencia crítica para aplicaciones interactivas como interfaces de chat, impactando directamente en la velocidad percibida por el usuario.
- Tokens Per Second (TPS) por flujo es la métrica de throughput principal para tareas de procesamiento en segundo plano, como el resumen de documentos o la extracción masiva de datos.
- La arquitectura y el tamaño del modelo dictan el rendimiento base, con modelos más pequeños como DeepSeek V4 Flash o Gemini 3.5 Flash ofreciendo velocidades más rápidas que los modelos insignia como Claude Fable 5 o GPT-5.5.
- El enrutamiento entre múltiples proveedores permite a los desarrolladores optimizar la latencia o el throughput de forma dinámica en función del rendimiento del proveedor en tiempo real.
Definición de las métricas principales: Latencia vs. Throughput
Para tomar decisiones informadas al comprar o enrutar API, los desarrolladores deben desglosar la "velocidad" en componentes distintos y medibles.
Línea de tiempo de una solicitud de API de LLM:
[El usuario envía la solicitud]
│
▼ (Tránsito de red + Procesamiento de prompt)
[Time to First Token (TTFT)] <--- Crítico para una UX interactiva
│
▼ (Generación autorregresiva: Tokens por segundo)
[Inter-Token Latency (ITL)] <--- Dicta la comodidad de lectura
│
▼ (Generación completa)
[Latencia total] <--- Crítico para llamadas bloqueantes sin streaming
1. Time to First Token (TTFT)
El TTFT es la duración entre el envío de una solicitud de API y la recepción del primer token de la respuesta. Esta métrica incluye el tiempo de ida y vuelta de la red, la serialización del prompt y el tiempo necesario para que el modelo procese los tokens de entrada (fase de prefill). Para aplicaciones interactivas, el TTFT es la métrica más importante porque determina qué tan rápido comienza a fluir la respuesta para el usuario.
2. Inter-Token Latency (ITL)
El ITL es el tiempo promedio transcurrido entre la generación de tokens consecutivos durante la fase de streaming. Si el ITL es demasiado alto, el texto fluye más lento de lo que un humano puede leer, lo que resulta en una experiencia de usuario frustrante. Un ITL estable y bajo garantiza una renderización de texto fluida.
3. Tokens Per Second (TPS)
El TPS representa el throughput de generación del modelo. Se calcula como el número total de tokens de salida dividido por el tiempo total de generación (excluyendo la fase de prefill). Al evaluar el throughput, los desarrolladores deben distinguir entre:
- TPS de usuario único: La velocidad de generación de un solo flujo activo.
- Throughput del sistema: El número total de tokens que el proveedor de API puede procesar simultáneamente en todos los usuarios activos.
4. Latencia total
La latencia total es la duración completa de la solicitud de API de principio a fin. Para solicitudes que no son de streaming, como la extracción de JSON estructurado o la clasificación en segundo plano, la latencia total es la métrica principal a monitorear.
Las compensaciones arquitectónicas: Por qué varía la velocidad
La compensación entre la latencia y el throughput de los LLM tiene su origen en la física de las arquitecturas transformer y el ancho de banda de la memoria del hardware. Durante la fase de prefill (que determina el TTFT), el cálculo es altamente paralelizable porque todo el prompt de entrada se procesa a la vez. Esta fase suele estar limitada por la capacidad de cómputo.
Durante la fase de generación (que determina el TPS), el modelo genera tokens uno por uno. Cada nuevo token requiere cargar todos los pesos del modelo desde la memoria de alto ancho de banda (HBM) a la SRAM de la GPU. Este proceso autorregresivo está limitado por el ancho de banda de la memoria.
Debido a estas limitaciones, los desarrolladores deben alinear sus elecciones de modelos con sus requisitos de rendimiento principales:
- Modelos insignia: Modelos como Claude Fable 5, Claude Opus 4.8 y GPT-5.5 priorizan la profundidad de razonamiento sobre la velocidad bruta. Cuentan con un número masivo de parámetros, lo que resulta en un TTFT más alto y un TPS más bajo.
- Modelos rápidos y de bajo costo: Modelos como DeepSeek V4 Flash, Gemini 3.5 Flash y Laguna XS 2.1 están optimizados para la velocidad. Utilizan un menor número de parámetros, decodificación especulativa o arquitecturas destiladas para ofrecer un TTFT excepcionalmente bajo y un TPS alto.
Los desarrolladores pueden consultar el TokenLab LLM API Leaderboard for Developers para comparar métricas de velocidad en tiempo real entre estos niveles de modelos.
Marco de decisión: Cuándo priorizar la latencia vs. el throughput
La prioridad entre latencia y throughput depende totalmente del caso de uso de la aplicación.
| Caso de uso | Métrica principal | Métrica secundaria | Clase de modelo recomendada |
|---|---|---|---|
| Chatbots interactivos | Time to First Token (TTFT) | Inter-Token Latency (ITL) | Fast Frontier (ej. Gemini 3.5 Flash) |
| Asistentes de codificación | TTFT y TPS de flujo único | Latencia total | Codificación especializada (ej. Claude Sonnet 5, Kimi K2.7 Code) |
| Extracción masiva de datos | Throughput del sistema | Costo por tarea | Open-Weight de bajo costo (ej. DeepSeek V4 Flash, GLM-5.2) |
| Agentes autónomos | Latencia total (sin streaming) | TTFT | Open-Weight de alto razonamiento (ej. DeepSeek V4 Pro) |
| Generación de imagen/video | Latencia total | Costo por imagen | API de medios especializados (ej. Nano Banana 2, Seedance) |
Aplicaciones interactivas (Latencia primero)
Para interfaces conversacionales, bots de atención al cliente y asistentes de búsqueda en vivo, la retención de usuarios cae si el sistema se siente lento. Los desarrolladores deben priorizar la minimización del TTFT. Incluso si la generación total toma varios segundos, un TTFT inferior a 300 milisegundos mantiene a los usuarios comprometidos.
Procesamiento por lotes y pipelines (Throughput primero)
Para tareas offline como procesar miles de facturas en PDF, generar informes diarios o ejecutar evaluaciones por lotes, el TTFT es irrelevante. El objetivo es maximizar el volumen total de tokens procesados por minuto al menor costo posible. Los desarrolladores deben centrarse en el throughput del sistema y la eficiencia de costos. Para un análisis detallado de la optimización de costos durante el procesamiento por lotes, consulte el TokenLab AI Model Routing Benchmark Cost Per Task.
Medición del rendimiento de la API: Un ejemplo de código práctico
Para medir con precisión el TTFT, el ITL y el TPS, los desarrolladores deben utilizar API de streaming y registrar marcas de tiempo en puntos específicos del ciclo de vida de la solicitud. A continuación, se muestra un script de Python ejecutable que utiliza el cliente compatible con OpenAI para medir estas métricas para un modelo determinado.
import time
import os
from openai import OpenAI
# Inicializar cliente (configurado para OpenRouter o cualquier proveedor compatible)
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key=os.environ.get("OPENROUTER_API_KEY", "your_api_key_here")
)
def measure_api_performance(model_name: str, prompt: str):
print(f"Evaluando métricas de velocidad para: {model_name}")
start_time = time.time()
response = client.chat.completions.create(
model=model_name,
messages=[{"role": "user", "content": prompt}],
stream=True
)
ttft = None
token_timestamps = []
total_tokens = 0
for chunk in response:
chunk_time = time.time()
# Verificar si el contenido de texto está presente en el fragmento
if chunk.choices and chunk.choices[0].delta.content:
content = chunk.choices[0].delta.content
# Estimar el recuento de tokens (1 token ≈ 4 caracteres para una medición aproximada)
estimated_tokens = max(1, len(content) // 4)
total_tokens += estimated_tokens
if ttft is None:
ttft = chunk_time - start_time
print(f"-> Time to First Token (TTFT): {ttft:.3f} segundos")
token_timestamps.append(chunk_time)
end_time = time.time()
total_duration = end_time - start_time
generation_time = total_duration - ttft if ttft else total_duration
# Calcular latencia entre tokens (ITL) y tokens por segundo (TPS)
if len(token_timestamps) > 1:
intervals = [token_timestamps[i] - token_timestamps[i-1] for i in range(1, len(token_timestamps))]
avg_itl = sum(intervals) / len(intervals)
tps = total_tokens / generation_time if generation_time > 0 else 0
else:
avg_itl = 0
tps = 0
print(f"-> Latencia total: {total_duration:.3f} segundos")
print(f"-> Latencia promedio entre tokens (ITL): {avg_itl:.3f} segundos")
print(f"-> Throughput estimado (TPS): {tps:.2f} tokens/seg")
print("-" * 50)
# Ejemplo de uso con un modelo rápido de bajo costo
if __name__ == "__main__":
test_prompt = "Escribe un ensayo de 200 palabras sobre la historia de la computación."
# Usando un ejemplo de modelo de enrutamiento de bajo costo actual
measure_api_performance("google/gemini-3.5-flash", test_prompt)
Estrategias de optimización para compradores de API
Si sus mediciones revelan que la API elegida es demasiado lenta o costosa, varias estrategias de optimización pueden mejorar el rendimiento.
1. Optimización de prompts y reducción de prefill
Debido a que la fase de prefill escala con el tamaño del prompt de entrada, reducir la longitud del prompt disminuye directamente el TTFT.
- Elimine instrucciones redundantes.
- Utilice el almacenamiento en caché de prompts del sistema si el proveedor lo admite. Esto permite al host de la API almacenar en caché el estado compilado de un prompt de sistema largo, evitando el cálculo de prefill en solicitudes posteriores.
2. Enrutamiento dinámico de proveedores
De acuerdo con la documentación de selección de proveedores de OpenRouter, el rendimiento de un modelo puede variar significativamente según el host subyacente (proveedor) que atienda la solicitud. Algunos proveedores optimizan para una latencia baja, mientras que otros ofrecen costos más bajos a expensas de la velocidad.
Al utilizar capas de enrutamiento, los desarrolladores pueden:
- Consultar a múltiples proveedores para encontrar la latencia actual más baja.
- Establecer rutas de respaldo para que, si un proveedor principal experimenta un pico de latencia, las solicitudes se enruten automáticamente a una alternativa más rápida.
- Filtrar proveedores según umbrales de rendimiento específicos.
3. Niveles de modelos (Tiering)
No utilice modelos insignia como Claude Fable 5 o GPT-5.5 para tareas que pueden ser manejadas por modelos más pequeños. Implemente un enrutador que envíe consultas simples (ej. clasificación, formato) a DeepSeek V4 Flash o GLM-5.2, reservando los modelos costosos solo para pasos de razonamiento complejos.
Limitaciones de los benchmarks de velocidad
Al evaluar las métricas de velocidad, los desarrolladores deben tener en cuenta las siguientes limitaciones:
- Variación de red: La latencia de la API depende en gran medida de la distancia física entre sus servidores de aplicaciones y la región de alojamiento del proveedor de la API. Ejecute siempre los benchmarks desde servidores ubicados en la misma región que su despliegue de producción.
- Congestión del proveedor: El throughput y la latencia fluctúan a lo largo del día según los patrones de tráfico global. Una sola ejecución de benchmark no representa un rendimiento de producción consistente.
- Discrepancias en la estimación de tokens: Diferentes modelos utilizan diferentes tokenizadores. Un modelo con un TPS más alto podría no ser realmente más rápido si su tokenizador divide las palabras en tokens más pequeños y numerosos que los de un modelo competidor.
Preguntas frecuentes
¿Un throughput (TPS) más alto significa siempre una experiencia de usuario más rápida?
No. Si una API tiene un throughput alto pero un TTFT deficiente, el usuario experimentará una pausa larga e inactiva antes de que el texto aparezca repentinamente en la pantalla. Para aplicaciones interactivas, un TTFT bajo es más crítico que un TPS alto.
¿Cómo afecta el almacenamiento en caché de prompts a la latencia?
El almacenamiento en caché de prompts reduce significativamente el TTFT para prompts largos. Al almacenar en caché los tokens procesados de las instrucciones del sistema o documentos de contexto, el proveedor omite la fase de prefill (que consume muchos recursos) en solicitudes posteriores, lo que genera tiempos de respuesta más rápidos.
¿Debo elegir modelos de pesos abiertos (open-weight) o de código cerrado para obtener la mejor velocidad?
Depende de la infraestructura de alojamiento. Los modelos de pesos abiertos como Qwen3.7 Plus, GLM-5.2 o DeepSeek V4 Pro pueden desplegarse en hardware privado dedicado, lo que le permite garantizar el throughput. Sin embargo, las API gestionadas de código cerrado a menudo utilizan una infraestructura masiva y optimizada que puede ser difícil de replicar de manera rentable en instancias privadas. Puede comparar las clasificaciones de rendimiento actuales en TokenLab Model Rankings.
Próximos pasos
Para optimizar la velocidad y la eficiencia de costos de su aplicación, comience por medir sus cargas de trabajo de producción actuales utilizando las métricas de streaming descritas anteriormente.
¿Listo para evaluar y comparar los modelos más recientes para su pipeline de producción? Comience con las clasificaciones integrales de modelos de TokenLab para encontrar el equilibrio óptimo de latencia, throughput y costo para su aplicación.
Fuentes
Precio observado el 2026-07-14
- OpenRouter latency and performanceObservado el 2026-07-14
- OpenRouter provider routingObservado el 2026-07-14
- TokenLab model rankingsObservado el 2026-07-14
