Tu dashboard muestra una latencia P95 de 4.2 segundos. El sitio de benchmarks dice que tu modelo hace 800 tokens por segundo — “rápido” — y tus usuarios todavía cierran la pestaña antes de que llegue el primer token.
Esa brecha es toda la historia de la latencia de LLM: el número que todos miden con benchmarks y el número que los usuarios realmente sienten son números distintos, y la mayoría de los equipos optimiza el equivocado.
La latencia es el rincón del stack de LLM con más datos y menos prescripciones: los sitios de benchmarks publican cientos de tablas de TTFT y tokens por segundo — las páginas de proveedores de Artificial Analysis y el ranking de velocidad en vivo de AI API Cost son los puntos de referencia — y casi ninguno te dice qué hacer con tu número. La documentación del proveedor explica su propio stack, no el tuyo. Y la métrica favorita del campo — tokens por segundo — se confunde con regularidad con lo que los usuarios realmente sienten.
Esta guía es la capa de prescripciones: qué significa realmente la latencia (cuatro números distintos, solo uno de los cuales es TPS), por qué ahora es una métrica de producto, cómo medirla con un presupuesto que puedas defender, cómo arreglar cada capa — streaming, caché, niveles de modelo, routing regional — y los errores que convierten la optimización en superstición.
Qué significa realmente “latencia” en las APIs de LLM
En resumen: hay cuatro números de latencia, y optimizar el equivocado es cómo los equipos lanzan modelos “rápidos” que se sienten lentos.
- TTFT — time to first token. Lo primero que sienten los usuarios: la brecha entre “enviar” y el primer token en streaming. El número más importante para productos interactivos.
- Latencia inter-token — el inverso del TPS. Qué tan rápido hace streaming el resto de la respuesta. Importa para salidas largas y bucles de agente; es irrelevante para una respuesta de una línea.
- Tiempo total de solicitud. La suma, menos la percepción del streaming. Lo que le importa al trabajo en batch y en segundo plano; no lo que sienten los usuarios.
- Latencia percibida. En lo que se convierte el streaming: TTFT más el ritmo del stream. Un sistema con buen TTFT y ritmo constante se siente rápido incluso cuando el tiempo total es largo.
La fijación del campo con el TPS es la trampa: un modelo de 800 tokens/seg con un TTFT de 1.5 segundos pierde la primera impresión frente a un modelo de 300 tokens/seg con un TTFT de 300ms. Mide los cuatro; optimiza por caso de uso.
Por qué la latencia es una métrica de producto
En resumen: los agentes multiplican la latencia y los usuarios sienten el producto — los números pasaron de la hoja de benchmarks al gráfico de churn.
Dos razones estructurales por las que la latencia es ahora una decisión de producto:
-
Los bucles de agente multiplican cada espera. Una sola conversación hace N llamadas secuenciales al modelo; una ventaja de 500ms por llamada se convierte en una ventaja de 5 segundos en un bucle de 10 llamadas. La misma lógica de acumulación que impulsa la regla de los 800ms para sistemas interactivos aplica aquí: las llamadas secuenciales se multiplican, así que la latencia por llamada es una decisión de producto, no un detalle de rendimiento.
-
La velocidad percibida es retención. Los estudios de UI con streaming muestran consistentemente que el tiempo hasta el primer token impulsa la calidad percibida; el modelo más rápido en benchmarks pierde si su TTFT es lento. La pregunta de producto no es “qué tan rápido es el modelo” — es “qué tan rápido es el primer token de mi usuario”.
Cómo medir: el presupuesto de latencia
En resumen: la medición es un presupuesto, no un benchmark — descompón, mide en P50 y P95, en tu región, con tus tamaños de prompt.
La descomposición del presupuesto:
| Etapa | Qué incluye | Rango típico |
|---|---|---|
| Red | DNS, TLS, conexión, distancia regional | 20-200ms |
| Cola | del lado del proveedor, cercanía a límites de tasa | 0-500ms+ |
| TTFT | prefill del modelo + primer token | 200-1500ms |
| Inter-token | ritmo de generación | 1-5ms/token |
| Cliente | parseo, renderizado, infraestructura de streaming | 10-100ms |
Reglas que mantienen honesto el presupuesto:
- Mide en regiones de producción. Una medición en US-east de un producto dirigido a Singapur es un número completamente distinto — la latencia regional puede superar a la del modelo.
- El P50 esconde la historia; el P95 la cuenta. La mediana esconde los timeouts; la cola es lo que los usuarios recuerdan.
- Mismos tamaños de prompt, misma concurrencia. Los benchmarks que usan prompts diminutos favorecen el TTFT y no castigan nada. Tu mezcla de prompts o la medición es marketing.
El script de medición, mínimo pero honesto:
import time
from openai import OpenAI
client = OpenAI() # your production endpoint and region
PROMPT = "..." # a representative production prompt
N, STREAM = 50, True # 50 runs, streaming on
ttfts, ipss = [], []
for _ in range(N):
t0 = time.perf_counter()
first = True
stream = client.chat.completions.create(model="gpt-4o-mini",
messages=[{"role": "user", "content": PROMPT}],
stream=STREAM)
for chunk in stream:
if first:
ttfts.append((time.perf_counter() - t0) * 1000) # TTFT in ms
first = False
t_last = time.perf_counter()
else:
ipss.append((time.perf_counter() - t_last) * 1000) # inter-token ms
t_last = time.perf_counter()
def pct(xs, p):
xs = sorted(xs); return xs[int(len(xs) * p)]
print(f"TTFT P50={pct(ttfts, .5):.0f}ms P95={pct(ttfts, .95):.0f}ms")
print(f"Inter-token P50={pct(ipss, .5):.1f}ms P95={pct(ipss, .95):.1f}ms")Ejecútalo desde las regiones donde están realmente tus usuarios, con tus tamaños reales de prompt, y registra los resultados como la línea base contra la que compara tu suite de CI.
El hábito de medición pertenece al CI: una suite de regresión de latencia que falle ante la deriva del TTFT es lo único que mantiene honesta la afirmación “el modelo mejoró” — la misma disciplina que una buena práctica de observabilidad construye para el resto de tu stack.
Cómo optimizar: streaming, caché, routing
En resumen: tres palancas, en orden de implementación — haz streaming de todo, cachea lo repetido, enruta por nivel — y las tres son configuraciones, no proyectos.
Capa 1 — Streaming. La primera palanca y la más barata: haz streaming de las respuestas y renderiza los tokens a medida que llegan. La decisión interactiva es SSE vs. WebSocket — SSE para streams de solicitud-respuesta (más simple, nativo de HTTP, funciona a través de la mayoría de los proxies), WebSocket para flujos bidireccionales (agentes, audio en realtime). Los detalles de producción que rompen el streaming ingenuo: el buffering de los proxies (los intermediarios que retienen la respuesta hasta que esté completa anulan el propósito), el manejo de desconexiones (el cliente abandona; el stream debe abortar) y el backpressure. El streaming no hace al modelo más rápido — hace que la espera del usuario desaparezca dentro del ritmo del stream.
Capa 2 — Caché. Dos ganancias distintas: el prompt caching (los prefijos repetidos se saltan el prefill, recortando el TTFT en la segunda llamada idéntica) y el response caching (solicitudes idénticas servidas sin contacto con el modelo). La guía de prompt caching cubre la economía; el ángulo de latencia es la misma palanca: los prefijos estables hacen la segunda llamada más rápida y más barata. Vigila la tasa de miss — un caché que falla el 90% de las veces añade overhead sin beneficio.
Capa 3 — Niveles de modelo y routing. El camino interactivo no necesita el modelo de frontera en cada turno: enruta las llamadas críticas para la UX al nivel rápido (incluyendo los proveedores de chips especializados cubiertos en nuestra comparación de inferencia rápida) y el trabajo de fondo al nivel de costo. El routing personalizado hace mecánica la decisión por solicitud, y los fallbacks evitan que la indisponibilidad ocasional del nivel rápido se convierta en tu historia de latencia.
Cómo arreglar la latencia global: routing regional
En resumen: para una base de usuarios global, la elección de región supera a la elección de modelo — el mismo modelo, en la región correcta, es la diferencia entre 300ms y 900ms.
Los números no mienten: un modelo servido desde Estados Unidos a un usuario europeo carga 100-200ms de latencia de red extra por salto frente a un endpoint regional, y la diferencia se acumula a través de los bucles de agente. El arreglo es arquitectónico:
- Routing de región más cercana. Sirve a cada usuario desde la región más cercana donde el modelo esté disponible — la capa de load balancing hace esto a nivel del endpoint.
- Auto-failover entre regiones. Cuando un proveedor o región se degrada, haz failover a la siguiente región antes de que se gaste el presupuesto de TTFT del usuario — la documentación de auto-failover cubre la mecánica.
- Llamadas edge, brevemente. Para rutas extremadamente sensibles a la latencia, las funciones edge pueden hacer de front-end de la llamada LLM — reduciendo el salto de red y manejando la reutilización de conexiones. La nota honesta: edge añade su propio costo de cold start, y para la mayoría de las cargas de trabajo gana el endpoint regional; prueba antes de adoptarlo (este es el caso límite que señalamos en lugar de sobreprometer).
La regla de medición anterior aplica aquí con fuerza extra: las decisiones de routing regional necesitan mediciones regionales — un benchmark hecho en EE. UU. de un cambio de routing global no es una medición.
Errores comunes
En resumen: cuatro modos de fallo — cada uno convierte una iniciativa de latencia en teatro.
- Optimizar una sola métrica. Fijación con el TPS ignorando el TTFT; fijación con el TTFT ignorando el streaming. El modelo de cuatro números de esta guía es el antídoto.
- Ignorar la capa de red. Toda la optimización del lado del modelo y cero routing regional — para un producto global, eso es optimizar la mitad equivocada del presupuesto.
- Caché sin disciplina de tasa de acierto. Cachear “porque es rápido” con un 90% de tasa de miss — la economía del caché solo funciona cuando el prefijo es estable y la tasa de acierto se mide.
- Sin línea base antes de optimizar. Cambiaste el stack, desplegaste el cambio, nunca mediste el antes. Sin la suite de latencia en CI, la “optimización” es una esperanza con un dashboard.
FAQ
¿Qué métrica de latencia debo optimizar primero?
TTFT para productos interactivos — es lo primero que sienten los usuarios. TPS para bucles de agente y salidas largas. Optimiza la métrica que siente tu caso de uso y luego mide las demás para que no sufran regresiones en silencio.
¿El streaming es más rápido o solo se siente más rápido?
Ambas cosas, en sentidos distintos: el tiempo total normalmente no cambia, pero la latencia percibida se derrumba porque el primer token llega temprano y el stream marca el ritmo del resto. Para productos interactivos, la latencia percibida es la métrica de producto — haz streaming de todo.
¿Cuánto afecta la elección de región a la latencia?
A menudo más que la elección de modelo: los saltos de red entre continentes añaden cientos de milisegundos por llamada, acumulándose a través de los bucles de agente. El routing de región más cercana es el cambio de latencia de mayor apalancamiento que la mayoría de los productos globales nunca hace.
¿SSE o WebSocket para streaming?
SSE para streams de solicitud-respuesta — más simple, nativo de HTTP, amigable con proxies. WebSocket para flujos bidireccionales como agentes en realtime. Elegir por la forma del flujo, no por la moda, es toda la respuesta.
¿El caché reduce realmente la latencia?
El prompt caching recorta el TTFT en prefijos repetidos (el prefill es la parte cara), y el response caching elimina por completo la latencia del modelo para solicitudes idénticas — pero solo cuando las tasas de acierto son reales. Mide la tasa de acierto; la tasa de miss es el impuesto.
¿Por qué mi P95 es mucho peor que mi P50?
La latencia de cola en las APIs de LLM viene del queueing del proveedor bajo carga, la cercanía a los límites de tasa y la variación regional de la red. Si el percentil alto importa (y sí importa), el arreglo es una mezcla de headroom, fallbacks y routing regional — no un modelo más rápido.
Resumen
La optimización de la latencia de LLM API es un problema de cuatro números: mide TTFT, inter-token, total y latencia percibida en P50 y P95 en tus regiones de producción; luego arregla cada capa — streaming para la percepción, caché para las repeticiones, niveles para el balance costo-velocidad y routing regional para la mitad de red del presupuesto. Las tablas de benchmarks te dicen qué es posible; tu presupuesto te dice qué es tuyo. Mide primero, optimiza segundo, y el modelo más rápido del mundo se convierte en el que tus usuarios realmente sienten.
No puedes arreglar un presupuesto de latencia que nunca mediste. Obtén tu API key de TokSpan — $5 en créditos gratis para medir — y ejecuta los mismos prompts desde algunas regiones.