LLM gateway: ¿por qué la latencia crece con el contexto?

Un gateway de LLM gastaba 553 ms de TTFB antes de llamar al modelo en una conversación de 439.945 tokens, con 334 turnos y 18 herramientas. Después de eliminar tres etapas de pre-vuelo, el mismo camino respondió en 35 ms, en un benchmark publicado el 3 de octubre de 2026 por un proyecto de gateway de LLM de código abierto.

La medición separa dos cosas que la factura junta: el trabajo que el gateway ejecuta entre la llegada de la solicitud y el reenvío al proveedor, y el tiempo que tarda el modelo en emitir el primer token. Con un proveedor que respondía de inmediato, lo que queda en el cronómetro pertenece al camino. En una sesión de código larga, ese camino cobra por el historial acumulado, y el historial solo crece: la etapa más cara releía la conversación completa para responder sí o no sobre caché. El cuello de botella estaba antes de la llamada.

¿Qué números publica el benchmark del 3 de octubre?

Nueve números, una fuente, dos rutas y una máquina. Cada línea se puede citar por separado siempre que lleve la atribución: un benchmark publicado el 3 de octubre de 2026 por un proyecto de gateway de LLM de código abierto, ejecutado en un entorno local.

1. 553 ms. TTFB mediano del camino de chat completions antes de la corrección, con el proveedor respondiendo de inmediato.
2. 35 ms. El mismo camino, después.
3. 94%. Reducción del TTFB mediano del camino de chat completions.
4. 542 ms. TTFB mediano en el endpoint de Messages, antes de la corrección.
5. 40 ms. El mismo endpoint, después.
6. 439.945 tokens. Tamaño de la conversación usada en la prueba.
7. 334 turnos. Pares de solicitud y respuesta en la misma conversación, con resultados de herramienta en medio.
8. 18 herramientas. Herramientas disponibles en la sesión.
9. Tres solicitudes. La mediana de cada punto, medida después de un calentamiento.

Dos salvedades valen. Los números vienen de dos rutas medidas en una máquina local, no de tráfico de producción: no hay p50, p95 ni p99, y la mediana de tres solicitudes es toda la estadística. Y el 94% pertenece al TTFB mediano del camino de chat completions, en este diseño.

¿Cómo se hizo este benchmark?

El camino de la solicitud corrió en Python, con un único deployment saludable, caché de respuestas en Redis, la comprobación de prompt caching habilitada y un proveedor de prueba que respondía de inmediato. Cada punto es la mediana de tres solicitudes después de un calentamiento, en la misma máquina local, en dos rutas.

El upstream instantáneo es lo que da sentido al diseño. Con un proveedor real al final de la línea, el TTFB mezcla el tiempo del gateway con la cola y el prefill del modelo, y no hay forma de separar los dos solo por el número. Con algo que responde en el mismo instante, lo que resta es el camino.

El deployment único trabaja por el mismo principio: con una sola ruta saludable no existe decisión que tomar. La prueba mide, entonces, el caso en el que la pregunta de elegibilidad no decidía nada. Lo que falta: distribución, percentiles altos y precio.

¿De dónde venían los 518 ms que el gateway de LLM gastaba antes de la llamada?

Tres etapas de la versión anterior responden por los 518 ms. La mayor de ellas era una comprobación opcional de prompt caching que contaba la conversación completa para responder si el texto alcanzaba el mínimo de tamaño que el deployment exige para reutilizar el prefijo, que se define por modelo y en este gateway medido queda en 1.024 tokens. Las otras dos: hash de prefijo y búsqueda de cache pin.

La comprobación tenía un motivo defendible: mantener la solicitud en un deployment con caché ahorra computación del lado del modelo. El problema era el método. La respuesta es sí o no, y el gateway leía todo.

En una sesión de código con cientos de turnos y resultados de herramienta, ese conteo podía significar cientos de milisegundos de trabajo en Python antes de la llamada al modelo. El gateway leía el historial completo para decidir si valía la pena mandar el historial completo a un deployment con caché.

Los 518 ms suman las tres etapas que la versión nueva omite, y el conteo responde por la parte que crece con la conversación. Los 35 ms que sobran no son residuo de ellas: en el camino medido las tres etapas se omiten por completo, y lo que queda en el cronómetro es el resto del camino en la misma máquina, el mismo que la Figura 1 rotula como residuo del camino.

La pregunta costaba más que la respuesta.

Conviene separar dos cachés que aparecen juntos en esta conversación. El caché de prompt del proveedor guarda representaciones de clave y valor y los hashes de los bloques cacheados, en memoria, con TTL de minutos o de una hora, y no el prefijo como texto ni en reposo. La transferencia de KV cache entre modelos es otra técnica, de infraestructura, y no la reutilización de prefijo por solicitud. La decisión de caché en el gateway es otra cosa: la pregunta sobre dónde debe caer la solicitud.

¿Por qué el costo crece con el tamaño de la conversación?

El costo crecía porque la etapa recorría el texto que llegaba. El trabajo acompaña tokens y turnos, y la carga agéntica maximiza ambos: cada resultado de herramienta entra en el historial, el historial vuelve completo en la solicitud siguiente, y la sesión que más necesita contexto es la que más paga.

Esto es lectura de mecanismo, no medición directa. La etapa recorría la conversación completa, así que el costo removido acompaña el texto contado, con la salvedad de que la fuente publica un punto, no una curva. Una tasa en milisegundos por token no existe, y una regresión de overhead contra contexto sería invención.

Una decisión de enrutamiento que examine el texto consume el insumo sobre el que decide. En un prompt corto, la cuenta es irrelevante. En una conversación de 439.945 tokens, las tres etapas de pre-vuelo sumaban 518 ms, y lo que el modelo gasta después de eso no está medido.

Cuando el precio empata, la latencia se vuelve la variable de la ruta, y la que decide ahí es la del modelo, medida por quien sirve la inferencia. La latencia de este texto es la del camino hasta el modelo.

¿Qué cambia cuando existe más de un deployment?

El camino cambia, el caché no. Con un único deployment saludable no hay ruta que elegir, y la versión nueva omite la comprobación de elegibilidad, el hash de prefijo y la búsqueda de cache pin. Con varios deployments, el conteo se detiene en el primer mensaje que alcanza el mínimo de tamaño que el deployment exige para reutilizar el prefijo. Ese mínimo se define por modelo, y el rango va de 512 a 4.096 tokens; en este gateway medido el corte ocurre en 1.024 tokens. La afinidad y el hash siguen en uso.

La corrección para el caso multi-deployment separa overhead de funcionalidad. Nadie apagó el prompt caching. La pregunta siguió existiendo, con un techo: deja de contar cuando la respuesta ya se conoce. El costo de la decisión de enrutamiento de LLM baja porque ya no recorre la conversación completa para responder algo que el primer mensaje resolvía.

El tercer camino, el endpoint /v1/responses, ya ignoraba la comprobación y quedó aproximadamente estable. La contabilización de uso no cambió en ninguna rama.

La economía de cache read en el enrutamiento es aritmética de precio: cuánto cuesta leer un prefijo ya cacheado. Lo que este benchmark mide es el precio de decidir quién puede leer el caché: el costo de la decisión, no el ahorro que compra. Con un upstream instantáneo no hay prefill real, así que la ganancia del caché queda inobservable en este diseño.

¿Qué cambia en el presupuesto de latencia de una aplicación?

Lo que cambia es la forma de la suma. El TTFB es el trabajo de pre-vuelo del gateway, más la red, más la cola del proveedor, más el prefill y la primera decodificación del modelo. El pre-vuelo crece con aquello que consume el resto de la suma. En gateways que hacen trabajo proporcional al contexto antes del despacho, como el medido aquí, un overhead medido con prompt corto subestima la latencia de una carga agéntica. En un gateway que elige ruta por metadatos, salud de deployment y tabla de costo, el pre-vuelo no crece con la conversación, y la subestimación no aparece.

Los valores vienen del benchmark del 3 de octubre de 2026, mediana de tres solicitudes después de un calentamiento en la misma máquina. Las dos columnas de la derecha son restas de las medianas publicadas.

La consecuencia para quien diseña la arquitectura es incómoda. Un presupuesto de latencia armado con medición de prompt corto no vale para la carga agéntica, medida aquí en una sesión de código de 439.945 tokens y 334 turnos. La decisión de enrutamiento de LLM por latencia pasa a necesitar los dos términos de la suma.

Leer el número ajeno exige la misma disciplina, y las métricas de benchmark de enrutador separan lo que la medición cubre de lo que solo sugiere. Un TTFB de 35 ms con upstream instantáneo no es lo que siente el usuario. Es el piso del camino.

Cómo medir el overhead de un gateway con contexto largo

Siete pasos, y cada uno evita un error específico. El diseño parte del benchmark del 3 de octubre de 2026, aplicado al tráfico propio: conversación real larga, upstream inmediato, muestra suficiente para percentiles, concurrencia, frontera de medición, rutas medidas por separado y comparación con la comprobación activada y desactivada.

1. Capturar una conversación real y larga. Usar una sesión que ya ocurrió, con turnos y resultados de herramienta. Evita medir con un prompt de juguete y concluir que el overhead de gateway es pequeño.
2. Apuntar a un upstream que responda de inmediato. Evita mezclar generación del modelo con trabajo del camino.
3. Muestrear lo suficiente para p95 y p99. La mediana de tres solicitudes no describe los percentiles altos. Descartar el calentamiento y publicar percentiles. Evita esconder un p99 que se derrumba.
4. Medir cada ruta por separado. Evita un promedio que esconde la ruta que duele.
5. Medir bajo concurrencia. El benchmark es serial. El conteo de tokens en Python dentro de un gateway asíncrono es trabajo CPU-bound en el mismo proceso: ocupa el event loop y bloquea toda solicitud concurrente del mismo worker. Evita aceptar una mediana serial mientras el p99 con decenas de sesiones simultáneas colapsa.
6. Medir dentro del proceso o en el mismo host. El TTFB medido en el cliente incluye TCP, TLS y RTT, y en un cuerpo de 439.945 tokens la ida y vuelta y la transmisión pueden exceder el efecto medido. Evita atribuir al pre-vuelo lo que es red.
7. Repetir con la comprobación activada y desactivada. Solo la diferencia entre las rondas pertenece al pre-vuelo. Evita acreditar la mejora a otro cambio.

Ese diseño responde por la forma de la carga. La distribución en tráfico real todavía pide el método para p50, p95 y p99 en medir el overhead operativo de un gateway: una pieza mide la distribución, la otra mide cómo cambia el overhead de gateway con la conversación.

Qué entrega Nexforce Router en esa capa

El Router entrega las tres cosas que este diseño exige, y ninguna de ellas es una promesa de menor latencia. El Router elige ruta por costo, desempeño, latencia y contexto, guarda caché de respuestas y de embeddings, y mantiene un trace completo de cada llamada con logs, métricas y alertas en el mismo lugar.

La selección por latencia dialoga con el presupuesto descrito arriba: quien decide ruta sin saber cuánto del TTFB es pre-vuelo optimiza el término equivocado de la suma. El trace resuelve el mismo problema desde otro ángulo, porque sin registro por llamada el overhead pagado no aparece en la factura ni en el panel del proveedor.

Conviene registrar el límite. Ningún número de latencia del Router entra aquí, porque no existe una medición pública que sostenga uno. El producto entrega la capa donde ocurre la medición.

Preguntas frecuentes

¿Qué es el TTFB en una llamada de LLM? Es el tiempo entre el inicio de la solicitud y el primer byte de la respuesta, la definición de TTFB en la documentación de MDN, que vale igual para una llamada de modelo. En una llamada de LLM suma cinco partes: el trabajo de pre-vuelo del gateway, la red, la cola del proveedor, el prefill y la primera decodificación del modelo.

¿Qué es el prompt caching y por qué influye en la ruta? Es la reutilización de un prefijo ya procesado, para que el proveedor no recalcule el mismo tramo en cada turno, como describe la documentación de prompt caching de Anthropic. Influye en la ruta porque no todo deployment reutiliza el prefijo, y la elegibilidad depende de que el prompt alcance el mínimo en tokens de ese modelo. La documentación no fija una constante: el rango va de 512 a 4.096 tokens y el valor se define por modelo, así que conviene revisar el modelo que se usa, y en este gateway medido el corte ocurre en 1.024 tokens.

¿Por qué contar tokens antes de la llamada puede costar caro? Porque contar exige recorrer el texto, y el texto de una sesión larga es el activo más pesado del camino. En una conversación de 439.945 tokens, con 334 turnos y 18 herramientas, el conteo podía significar cientos de milisegundos de Python antes de la llamada al modelo, según el benchmark del 3 de octubre de 2026.

¿94% de reducción significa que mi gateway puede quedar 94% más rápido? No. El número vale para el TTFB mediano del camino de chat completions, en una conversación de 439.945 tokens, con un deployment saludable y un proveedor que respondía de inmediato, mediana de tres solicitudes en una máquina local. Mide la eliminación de tres etapas de pre-vuelo en este diseño, que no incluye cola de proveedor, red ni tráfico real.

Referencias y lectura complementaria

La fuente numérica es un benchmark publicado el 3 de octubre de 2026 por un proyecto de gateway de LLM de código abierto, en entorno local, con lectura completa el 22 de octubre de 2026. La atribución es por categoría y fecha porque el proyecto es competidor y no se nombra en ninguna superficie publicada.

• Definición de Time to First Byte, documentación de MDN
• Prompt caching, documentación de Anthropic

La lectura complementaria interna está en el cuerpo, en los cinco textos citados a lo largo de las secciones. Ningún enlace apunta al proyecto medido.

La cuenta que no entra en la hoja de cálculo de latencia

El rubro más caro del presupuesto de latencia fue una pregunta que el gateway se hacía a sí mismo. La llamada al modelo, la cola del proveedor y el tamaño de la respuesta quedan afuera. Lo que pesa es la contabilidad interna que decide dónde debe caer la solicitud, ejecutada en cada solicitud, sobre el texto que llegó.

Dos acciones, en este orden. Primero, medir el TTFB con una conversación real larga y un upstream instantáneo, porque el número medido con prompt corto no describe la carga que importa. Después, revisar qué corre antes de la llamada y preguntar, punto por punto, si eso necesita correr en cada solicitud.

El límite honesto: ningún dato público dice con qué frecuencia aparece este patrón en otros gateways. Lo que existe es una medición fechada, en un camino, con diseño explícito, y un mecanismo que cualquier gateway que decida ruta puede reproducir.

Cómo citar: benchmark publicado el 3 de octubre de 2026 por un proyecto de gateway de LLM de código abierto, ejecutado en entorno local, con lectura el 22 de octubre de 2026. Actualización: revisión cuando haya una nueva medición pública del mismo camino.