The bottleneck was not the GPU: it was the network

Un usuario. Una pregunta. 2.541 ms hasta el primer token. Con una L40S de 48 GB delante. Si el modelo tarda decenas de milisegundos en responder, ¿dónde se fueron los dos segundos y medio?

La respuesta cambió cómo pensamos el PoC entero: el cuello de botella no era la GPU, era el camino de internet hasta ella.

El dato

Del barrido real, el escenario más simple:

Para una sola petición, en una GPU dedicada, eso no tiene sentido. Una L40S no tarda 2,5 segundos en leer 15.000 tokens de contexto… salvo que la petición haya pasado por media internet antes.

El desglose

Analizando los logs del gateway y las sesiones de la prueba, la espera se repartía así:

(Cifras del análisis de la prueba, no de un benchmark reproducible: los logs de sesión no quedaron versionados.)

O sea: alrededor del 94% de la espera era el viaje de ida y vuelta por internet, no el cálculo. Y el TTFT medido (2.541 ms) es aún mayor que ese desglose porque incluye el buffering del proxy.

La causa real: el proxy

El acceso al pod era a través del proxy HTTP del proveedor, y ese proxy bufferea los eventos SSE. Es decir: tu servidor puede estar emitiendo tokens uno a uno, pero el proxy los acumula y los entrega en bloques. Estás midiendo la red del proxy, no tu servidor.

Lo dice el propio runbook del PoC: "El proxy HTTP bufferea SSE y te inflaría el TTFT: estarías midiendo la red, no tu servidor."

Cómo se mide bien

• Túnel SSH al pod y medir contra localhost (sin proxy en medio).
• O medir dentro del pod, contra el propio vLLM.
• Y si el producto es un chat real, medir desde donde está el usuario (región, CDN) — porque esa latencia existirá también en producción.

Ninguna de esas mediciones quedó versionada en el PoC. Ese es el hueco más importante que deja esta prueba, y por eso todos los TTFT del barrido hay que leerlos con la advertencia: incluyen latencia de red del proxy y no son comparables con un SLO de 1.500 ms.

Por qué importa (más allá del PoC)

1. "La IA va lenta" casi nunca es el modelo. Antes de comprar una GPU más grande, separa las capas: modelo, app, red. Si el 90% es red, la GPU no es tu problema.
2. La topología es arquitectura. Servir desde un pod en otra región para usuarios en la tuya es una decisión de producto, no de infraestructura.
3. La red privada cambia las cuentas. En una VPC, esos ~1.000 ms bajan a decenas. Eso puede voltear la decisión de migrar (y por eso quedó como "pendiente de medir" en el informe final). → El informe que dijo "no migren todavía"

Y encaja con lo que ya sabíamos por otro lado: en modelos chicos, el tiempo de CPU alrededor de la GPU también pesa. → Inference Engineering: qué se optimiza

Lo que me llevo

Medimos un servidor y, sin querer, medimos internet. La lección no es "el proveedor es malo": es que cada capa entre el usuario y el modelo suma, y si no las separas vas a optimizar la equivocada. La primera pregunta ante una latencia rara debería ser siempre: ¿en qué capa se fue el tiempo?

¿Has medido alguna vez la latencia de red de tu stack de IA, o solo la del modelo? Cuéntame en los comentarios: casi todos medimos la mitad.

Referencias

• Repo del PoC: runbook con la advertencia del proxy
• vLLM documentation