Qué tan rápido y cuánto: latencia y throughput

La latencia de punta a punta (end-to-end latency) es el tiempo total de una request entre dos puntos que tú nombras, sumando todo lo que pasa en medio. «Punta a punta» no dice nada si no dices cuáles puntas.

En C01 están escritas en el SLO, como viste en la lección de percentiles: el reloj arranca cuando el balanceador de carga de carga (la puerta que reparte las requests entre los pods) tiene la request completa y para cuando sale la respuesta. Es una medida del lado del servidor (server-side). La subida de la foto desde el celular de Ana, por 4G, queda fuera: depende de su señal, no del servicio.

Tres maneras de gastar el tiempo

Entre esas dos puntas, la request da varios saltos: del balanceador al gateway, del gateway a Triton (el servidor que corre el modelo en la GPU) y de vuelta. En cada salto, el tiempo se va en una de tres cosas:

• Viajar. Los bytes cruzan la red. Cada mensaje viaja en paquetes, y una ida y vuelta, el RTT (round-trip time), cuesta poco dentro de la misma zona y mucho más a otra ciudad. Una zona es un centro de datos de la nube, o un grupo de ellos muy cercanos, con su propia luz y su propia red; lo verás a fondo en la lección de regiones. Abrir una conexión nueva cuesta un handshake, un saludo de idas y vueltas antes del primer byte útil; por eso C01 reusa conexiones abiertas (keep-alive). Lo viste en las lecciones de red y de HTTP.
• Esperar. La request ya llegó, pero el recurso que necesita está ocupado con otras. Espera su turno en una fila.
• Trabajar. Un recurso le dedica su tiempo: la CPU decodifica la foto, la GPU corre la ResNet-50.

La Ronda (M03) estima el camino típico de C01 tramo por tramo. Esta es una request ilustrativa, dentro de sus rangos, a una hora tranquila:

Medir cada tramo

La regla práctica: mide cada tramo por separado. El gateway de C01 lleva un histograma para el preproceso y otro para la llamada a Triton. Si la latencia sube y solo crece uno, ya sabes dónde buscar. La suma de los p99 de los tramos sirve para repartir el presupuesto, pero no da el p99 total: eso se mide de punta a punta, como viste en la lección de percentiles.

Fíjate en la columna que casi no aparece. Con poco tráfico, «esperar» vale solo la ventana de Triton. Cerca del pico es la única que crece. La siguiente sección la abre.

El tiempo que un recurso trabaja de verdad en una request es su tiempo de servicio (service time), que en las fórmulas se escribe S. En el gateway de C01, ≈ 6 ms de CPU por foto (con el ≈ 1 ms de armar la respuesta son 7, pero la Ronda y la lección de async redondean a 6 en las cuentas de capacidad, y aquí también); en la T4, de 3 a 6 ms por batch chico. Se baja con mejor hardware o con menos trabajo: el draft mode de JPEG (decodificar la foto ya achicada), un modelo en FP16, mandar menos bytes.

El tiempo que la request pasa esperando a que ese recurso se desocupe es su tiempo en cola (queueing time o queueing delay). No se baja optimizando el código: se baja con más capacidad o con llegadas más parejas.

Su suma es lo que la request vive en ese tramo: W = espera + S. Es la misma W de la Ley de Little: el tiempo que pasa adentro.

Una fila, a mano

Un pod con un solo núcleo y 6 ms de CPU por foto. Le llegan 5 fotos en 30 ms. Primero, llegan parejas, una cada 7.5 ms: cuando llega cada una, la anterior ya terminó. Nadie espera, y las cinco tardan 6 ms.

Ahora llegan las mismas cinco, pero tres casi juntas. La regla de una fila es simple: cada request empieza cuando llega o cuando el núcleo se desocupa, lo que pase después.

En la vida real nadie se pone de acuerdo para llegar parejo. Las requests llegan al azar, como viste con Poisson en la lección de probabilidad: en ventanas de 10 ms con 5 llegadas en promedio, ≈ 3 % de las ventanas trae 10 o más (M03). Siempre hay ráfagas, y cada ráfaga deja una fila. Por eso aparece la espera aunque el servidor no esté lleno.

La Ronda (M03) lo resume así: el mismo modelo, en el mismo hardware, puede responder en 10 ms o en 200 ms según qué tan cargado esté. El servicio no cambió. Cambió la fila. ¿Cuánto crece? Depende de una sola cantidad.

La utilización (utilization) es la fracción del tiempo en que un servidor está ocupado. Se escribe ρ (la letra griega rho) y se calcula con lo que llega y lo que tarda cada una:

ρ = λ × S ÷ c

λ (la letra griega lambda) es la tasa de llegada, en requests por segundo; S, el tiempo de servicio; c, cuántos servidores atienden la misma fila (núcleos, GPUs, réplicas). Es una cuenta de horas de trabajo: cada segundo llegan λ × S segundos de trabajo, para c servidores.

• Un pod del gateway en el pico de diseño (500 requests por segundo entre 5 pods): 100 requests por segundo × 0.006 s ÷ 1 vCPU (el que tiene reservado cada pod) = 0.6. Ese vCPU trabaja 60 % del tiempo.
• Los 5 pods juntos: 500 × 0.006 ÷ 5 = 0.6 también. Son 3 vCPU ocupados de 5.
• Una T4 (500 fotos por segundo entre 2 GPUs): una prueba de carga midió que procesa hasta ≈ 1,200 fotos por segundo cumpliendo su presupuesto (la sección de capacidad lo explica). Es como si cada foto le costara S = 1 ÷ 1,200 de segundo, así que ρ = 250 × (1 ÷ 1,200) = 250 ÷ 1,200 ≈ 21 %.

Si ρ llega a 1, llega tanto trabajo como el servidor puede hacer. Si lo pasa, la fila crece sin fin: lo viste en la lección de async, con los pedazos de audio de C13, los subtítulos en vivo, que se atrasaban dos minutos en diez. Pero la sorpresa no está en el 100 %: está antes.

La teoría de colas, en una fórmula

La teoría de colas (queueing theory) es la parte de las matemáticas que calcula cuánto se espera en una fila. Su modelo más simple se llama M/M/1: llegadas al azar (Poisson), tiempos de servicio al azar (la mayoría cortos y unos pocos largos), un servidor y una fila en orden de llegada. El nombre se lee por partes: la primera letra dice cómo llegan las requests, la segunda cómo es el servicio y el número cuántos servidores hay. La M (de Markov, un matemático ruso) quiere decir «al azar y sin memoria»: lo que tardó la anterior no dice nada de la siguiente. Con esos supuestos, el tiempo promedio que pasa cada request en el sistema es:

W = S ÷ (1 − ρ)

Y la espera en la fila es lo que sobra: W − S = ρ × S ÷ (1 − ρ). El divisor es la clave: 1 − ρ es el tiempo libre del servidor. Cuando se acerca a cero, la espera se dispara.

Con los 6 ms del gateway:

De 50 a 90 % la espera se multiplica por 9 (de 6 a 54 ms), aunque la carga solo subió 80 %. De 90 a 99 %, por 11 más. La intuición dice «al 90 % todavía queda 10 % libre»; la fórmula dice que ese 10 % no alcanza para deshacer las ráfagas.

¿Y el p99? En M/M/1, el tiempo en el sistema sigue una distribución exponencial, y su p99 es W × ln(100) ≈ 4.6 × W (ln es el logaritmo natural). No hace falta recordar por qué: basta saber que la cola de la distribución crece igual que el promedio, multiplicada por casi 5.

Por qué se dobla la curva

Con ρ = 0.5, el servidor pasa la mitad del tiempo libre. Cuando llega una ráfaga, tiene tiempo de sobra para vaciar la fila antes de la siguiente. Con ρ = 0.9 solo tiene 10 %: cada ráfaga deja una fila que tarda en vaciarse, y la siguiente llega antes de que termine. La Ronda lo dice así: la espera no la causa la carga promedio, sino la variabilidad combinada con poco tiempo libre para absorberla.

Ahora sí, la respuesta de la lección. El HPA, la regla de Kubernetes que agrega o quita pods, mantiene al gateway cerca de 60 % de CPU. Pero el HPA reacciona en decenas de segundos o minutos: por omisión revisa las métricas cada 15 s, y después hay que decidir y arrancar los pods nuevos. Un pico llega en segundos:

Son números del modelo, no mediciones, y solo de la parte del pod. Pero cuentan la historia completa: la misma request, el mismo código, otra fila.

Compruébalo con una simulación

La fórmula sale de supuestos. Este programa no supone nada: genera 200,000 requests al azar (con semilla, para que salga igual siempre) y aplica la regla de la fila a mano de la sección anterior, una por una. La espera de cada request es la de la anterior, más lo que trabajó la anterior, menos el hueco entre las dos llegadas, y nunca menos de cero.

import math, random

def simular(rho, S=6.0, n=200_000, semilla=3):
    azar = random.Random(semilla)
    espera, servicio_anterior, tiempos = 0.0, 0.0, []
    for _ in range(n):
        hueco = azar.expovariate(rho / S)           # ms desde la llegada anterior
        espera = max(0.0, espera + servicio_anterior - hueco)
        servicio = azar.expovariate(1 / S)          # ms de CPU de esta request
        tiempos.append(espera + servicio)
        servicio_anterior = servicio
    tiempos.sort()
    return sum(tiempos) / n, tiempos[math.ceil(0.99 * n) - 1]

print("  ρ   W simulado  W fórmula   p99 simulado  p99 fórmula")
for rho in (0.5, 0.8, 0.9, 0.95):
    w, p99 = simular(rho)
    formula = 6.0 / (1 - rho)
    print(f"{rho:>4}  {w:7.1f} ms  {formula:7.1f} ms  {p99:8.0f} ms  {formula * math.log(100):8.0f} ms")

  ρ   W simulado  W fórmula   p99 simulado  p99 fórmula
 0.5     12.0 ms     12.0 ms        56 ms        55 ms
 0.8     30.4 ms     30.0 ms       140 ms       138 ms
 0.9     61.4 ms     60.0 ms       275 ms       276 ms
0.95    118.9 ms    120.0 ms       512 ms       553 ms

expovariate(t) genera tiempos al azar con promedio 1 ÷ t: huecos de S ÷ ρ entre llegadas (12 ms a 50 %) y servicios de 6 ms en promedio. Es la «M» de M/M/1. La simulación y la fórmula coinciden de cerca: los promedios, por menos de 3 %; el p99 a 95 %, por ≈ 7 % (512 contra 553). Cambia la semilla y verás otra cosa que importa: a 50 % el p99 sale casi igual con cualquiera; a 95 %, entre semillas brinca de ≈ 460 a ≈ 930 ms. Cerca del 100 %, hasta medir se vuelve ruidoso: unas cuantas ráfagas largas deciden el resultado.

Un modelo, no una ley

Tus llegadas no son exactamente Poisson. El servicio de una GPU que corre siempre el mismo engine de TensorRT es mucho más parejo que una exponencial, y Triton con batching no es una fila simple. Lo que se conserva en la práctica es la forma: plana hasta cierto punto y después, el palo de hockey. La fórmula sirve para argumentar y para estimar; para dimensionar, se mide el codo con una prueba de carga.

Un recurso está en saturación (saturation) cuando ya no tiene tiempo libre: su utilización llega cerca del 100 % y lo que sigue llegando se va a la fila. Se reconoce por dos síntomas juntos: la fila crece y el throughput deja de subir aunque llegue más. La saturación es una de las cuatro señales doradas (golden signals) que C01 vigila por cada parte del sistema, junto con la latencia, el tráfico y los errores. El nombre y la lista vienen del libro de SRE de Google (Site Reliability Engineering, 2016); SRE es el oficio de mantener servicios funcionando.

Manda el recurso más lleno

Una request de C01 pasa por varios recursos en fila: la red del gateway, su CPU, la red hacia Triton, la GPU. Cada uno tiene su capacidad y su utilización. El que se satura primero es el cuello de botella (bottleneck): fija el throughput máximo de toda la cadena, y su fila es la que domina la latencia.

Es como una cadena de tubos: el agua que sale por segundo la decide el tubo más angosto. Ensanchar los otros no cambia nada.

En C01, en el pico de diseño, cada recurso va a su propio porcentaje:

Las cuentas de red son las de la lección de unidades: 500 tensores de 602 KB por segundo son ≈ 2.4 Gb/s, repartidos entre los 2 nodos del gateway. La pieza más cara, la GPU, es la más desocupada. El cuello de botella está en la red del gateway, y luego en su CPU. Por eso la Ronda anota como mejora mandar el tensor en uint8, 4 veces menos bytes, y no comprar otra GPU.

¿Cómo se encuentra en producción? Mirando qué fila crece. Si sube el tiempo en la fila de Triton, falta GPU. Si sube el histograma del preproceso, falta CPU en el gateway. Si las dos están planas y la latencia sube, busca en la red o en las conexiones.

Capacidad: lo que aguanta cumpliendo la promesa

La capacidad (capacity) de un servidor es el throughput más alto que sostiene cumpliendo su presupuesto de latencia. No es el máximo que alcanza a procesar: pasado cierto punto todavía procesa más, pero tarde. La capacidad de una T4 de C01, ≈ 1,200 fotos por segundo, es el punto donde su p99 todavía cabe en los ≈ 30 ms que le tocan a la GPU: la parte del presupuesto de 200 ms que la Ronda (M03) le reparte. Los 150 ms del timeout del gateway son otra cosa: cuándo rendirse, no cuánto debería tardar. Se mide con una prueba de carga, como verás más adelante.

Headroom: el margen que se compra a propósito

El headroom es la distancia entre la capacidad y la carga que planeas: la parte que dejas libre a propósito. No hay un número oficial; la regla práctica de la Ronda es que un servicio online se planea a ≈ 50–70 % de la capacidad medida; un job offline, que nadie espera, puede trabajar cerca del 100 %. La Ronda insiste: el headroom es protección, no desperdicio. Paga cuatro cosas a la vez:

1. La p99. Lejos del codo, una ráfaga no se convierte en fila.
2. La caída de una réplica o de una zona. Su carga se reparte en las demás.
3. El tiempo de reacción del autoscaler. Un nodo con GPU tarda minutos en estar listo; un pico dura segundos.
4. El error de tu medición. El máximo de la prueba no es el de producción: otra mezcla de fotos, relojes más bajos con calor.

Una GPU corre un batch de 8 fotos en mucho menos que 8 veces lo que tarda una. Parte del costo es fijo por cada ejecución: lanzar los kernels, leer los pesos de la memoria, sincronizar. Con una sola foto, además, casi todos sus núcleos se quedan sin trabajo. Juntar fotos reparte ese costo fijo.

El batching dinámico (dynamic batching) hace eso en el servidor, con las requests que van llegando: las junta en una fila y manda el batch a la GPU cuando se llena (el tamaño máximo) o cuando vence una espera máxima, lo que pase primero. En C01, Triton espera como máximo 2 ms (max_queue_delay_microseconds: 2000) y junta hasta 32 fotos.

La Ronda (M03) trae una tabla ilustrativa, con forma realista, para una T4:

La cuenta de cada fila es tamaño ÷ tiempo: 8 fotos en 9 ms son 8 ÷ 0.009 ≈ 890 por segundo. El throughput sube mucho al principio y luego se aplana: de 1 a 8 se multiplica por 3.6, y de 8 a 32 solo por 1.3, mientras el batch tarda el triple. Rendimientos decrecientes.

El batch que se forma depende de lo que llega

32 es un techo, no lo que pasa. El tamaño real depende de cuántas requests llegan mientras el batcher espera y mientras la GPU está ocupada con el batch anterior:

¿Entonces para qué se activa? Para los malos ratos. Si cae una GPU, la otra recibe 500 por segundo y los batches crecen solos a ≈ 2–4: la GPU absorbe la carga extra sin escalar. En la lección de probabilidad viste la misma idea con Poisson: a 250 por segundo, ≈ 61 % de las ventanas no recibe a nadie.

Throughput contra latencia es la perilla de todo serving. Un job offline, como el backfill (clasificar de una vez todo lo que ya existía) de las ≈ 200 millones de fotos viejas, usa batches llenos de 32 todo el tiempo: nadie espera cada foto. En los LLMs la versión es el batching continuo de la lección de LLMs: las secuencias entran y salen del batch en cada token, y la perilla mueve el TTFT y el TPOT.

Una fila sin límite nunca falla. Ese es el problema.

Imagina que a una T4 de C01 le ofrecen 1,400 fotos por segundo y solo procesa ≈ 1,210, su máximo absoluto (un poco más que los 1,200 que cumplen el presupuesto). Sobran 190 cada segundo, y se van a la fila. A los 10 segundos esperan 1,900, y la última tardará 1,900 ÷ 1,210 ≈ 1.6 s solo en esperar. El gateway le da a Triton 150 ms antes de rendirse. Todas las requests llegan tarde: la GPU trabaja al máximo, el throughput es 1,210 por segundo, y ninguna respuesta le sirve a nadie. Y no hay un solo error en los logs hasta que empiezan los timeouts.

Una fila con tope

Una cola acotada (bounded queue) es una fila con un límite: por cuántas caben o por cuánto pueden esperar. Si está llena, la request nueva se rechaza en el momento. C01 pone topes en cada salto:

• En el pod del gateway: MAX_INFLIGHT = 16 requests en vuelo (ya aceptadas y todavía sin respuesta), y solo 2 decodes a la vez, con 50 ms como máximo de espera por un lugar (lección de async).
• En Triton: la fila del batcher rechaza lo que ya esperó 100 ms (en su configuración, default_queue_policy con REJECT), el último eslabón de la cadena 300 → 250 → 150 → 100 ms de la lección anterior: el backend espera 300, el gateway se da 250, a Triton le da 150 y su fila rechaza a los 100.

Un tope por número también acota el tiempo, por Little: con 16 lugares en un pod que termina 100 por segundo, el tiempo promedio adentro no pasa de ≈ 16 ÷ 100 = 0.16 s, aunque se llene.

Que la presión llegue hasta atrás

Backpressure (contrapresión) es la señal que viaja hacia atrás y dice «no me mandes más, no puedo». Puede ser un 503, el código de estado de «no disponible», con un Retry-After (un header de la respuesta que dice «vuelve en tantos segundos»), una fila que no deja meter nada hasta que haya lugar, o una conexión que no acepta más bytes. Con ella, el que produce se frena al ritmo del que consume, en vez de llenarle una fila sin fondo.

En C01 la cadena es corta: Triton rechaza, el gateway contesta un 503 en microsegundos y el backend del marketplace le muestra a Ana el selector de categorías: su fallback. Rechazar a propósito lo que no cabe, para salvar lo demás, es load shedding, de la lección anterior. Una cola acotada es su forma más simple.

¿Dónde va cada tope? Donde se rompe la promesa, no donde se acaba la memoria. Una fila que deja esperar más de lo que queda del presupuesto solo guarda requests que ya perdieron. La regla de la Ronda: si esperó tanto que ya no va a llegar a tiempo, es mejor rechazarla que gastar GPU en ella.

Todos los números de esta lección que dicen «medido» salen de una prueba de carga (load test): un programa que le manda tráfico sintético al servicio, cada vez más, y anota el throughput y los percentiles de latencia en cada escalón. En una entrevista, decir cómo lo medirías vale tanto como el número.

La rampa y su codo

La prueba básica es una rampa: subir por escalones la carga ofrecida, lo que el generador manda. Mientras hay capacidad, el throughput sigue a la carga y la latencia casi no cambia. Pasado el codo (knee), el throughput se aplana y la latencia se dispara, porque todo lo que sobra se va a la fila. Una rampa ilustrativa contra una T4 de C01 (M03):

La capacidad es el codo, 1,200, no el 1,210 del final. Y fíjate en las dos últimas filas: con la fila acotada de Triton, la latencia se queda cerca del tope y lo que sube son los rechazos.

Carga abierta y carga cerrada

Hay dos maneras de generar el tráfico, y no miden lo mismo:

• Carga cerrada (closed-loop): N usuarios virtuales; cada uno manda su siguiente request cuando le llega la respuesta de la anterior.
• Carga abierta (open-loop): las requests llegan a una tasa fija, pase lo que pase con las respuestas.

Tus usuarios reales se parecen a la abierta: un vendedor en Monterrey no espera a que termine la foto de otro para subir la suya. La cerrada tiene una trampa: cuando el servidor se frena, el generador también se frena, y manda menos requests justo cuando el servidor está lento. Los peores momentos casi no se miden, y el p99 sale mejor que la realidad. La regla de la Ronda: para medir latencia a una tasa dada, carga abierta; para encontrar el máximo, sirve la cerrada. Los números y las herramientas, en la sección extra.

Goodput: el throughput que sí cuenta

El throughput cuenta todo lo que el servidor termina. Pero una respuesta que llega después del timeout, o un error, no le sirve a nadie. El goodput es el throughput útil: las requests por segundo que terminan bien y dentro de su SLO. En una prueba de carga, la carga máxima a la que todavía se cumple el SLO.

En la cuenta de la sección anterior, la T4 sin tope tenía un throughput de 1,210 por segundo y un goodput de casi cero. Con tope, los dos valían ≈ 1,210. El goodput es el número que separa un servidor ocupado de un servidor que sirve.

En los LLMs el goodput manda todavía más, porque cada respuesta trae dos promesas: el bloque que sigue lo cuenta.

1. Planear al 90 % porque «queda 10 % libre»

En una fila, ese 10 % libre vale poco: la espera ya es 9 veces la del 50 %, y cualquier ráfaga saca al p99 del SLO.

Cómo evitarlo: planea a 50–70 % de la capacidad medida en lo online (más cerca de 50 % con tráfico en ráfagas y un SLO apretado), y deja el 100 % para los jobs offline, donde nadie espera.

2. Escalar con la señal equivocada

La utilización de nvidia-smi marca 30 % con batches de 1 y se queda en 100 % igual con 2 que con 200 en la fila. Y la CPU del pod de Triton sigue al throughput terminado: cuando la GPU se satura, se congela justo cuando más la necesitas (M06).

Cómo evitarlo: escala con una señal del recurso que se satura primero. En el gateway, su CPU; en Triton, el tiempo en la fila.

3. Una fila sin tope

asyncio.Queue() sin maxsize, un pool sin límite, un servidor que acepta todo. Nunca falla: solo se atrasa, en silencio, hasta que todas las respuestas llegan tarde.

Cómo evitarlo: un tope en cada fila, puesto donde se rompe el presupuesto de latencia, y un rechazo rápido con su fallback del otro lado.

4. Creerle al p99 de una prueba cerrada

Locust con 50 usuarios reporta un p99 precioso, porque cuando el servidor se frenó, los usuarios también.

Cómo evitarlo: para medir latencia a una tasa, un generador abierto a la tasa de diseño. Y compara siempre la tasa que pediste con la que de verdad se mandó.

5. Dimensionar con el throughput máximo o con el promedio

El máximo de una rampa no es la capacidad: pasado el codo, el servidor procesa más, pero tarde. Y el promedio no es la carga: la Ronda (M03) cuenta un gateway con 1 vCPU (un núcleo rentado en la nube) para 116 requests por segundo (116 × 6 ms ≈ 0.7 vCPU de trabajo) que a las 8 de la noche, con 350, necesitaba 350 × 6 ms ≈ 2.1.

Cómo evitarlo: capacidad = el codo que cumple el presupuesto, o el goodput; carga = el pico de diseño. Después, el headroom.

6. Sumar o promediar lo que no se suma

Sumar los p99 de los tramos, promediar los p99 de los pods o meter un p99 en la Ley de Little («500 × 200 ms = 100 en vuelo en el peor caso»). Little habla de promedios, y de un sistema estable, donde a la larga sale lo mismo que entra: con una fila que crece sin fondo, no hay un W que meter.

Cómo evitarlo: reparte el presupuesto por tramo, pero mide el p99 de punta a punta, con histogramas que sí se suman. Para Little, el W promedio.

Resuélvelos con lápiz antes de abrir la solución. Los de utilización y capacidad se comprueban con las calculadoras.

1. 1Fácil

   A un servicio le llegan 40 requests por segundo y cada una ocupa 20 ms de CPU. ¿Qué utilización tiene con 1 núcleo? ¿Y con 2? ¿Cuántas por segundo aguanta como máximo con 1?

   Ver la solución paso a paso

   • Con 1 núcleo: ρ = 40 × 0.020 ÷ 1 = 0.8, 80 %.
   • Con 2: 40 × 0.020 ÷ 2 = 0.4, 40 %.
   • Máximo con 1: el núcleo termina 1 ÷ 0.020 = 50 por segundo. Con 40 está a 80 % de ese máximo: es la misma cuenta.
2. 2Fácil

   La Ronda arma su tabla de M/M/1 con S = 10 ms. Calcula W a 50, 70, 80, 90 y 95 %.

   Ver la solución paso a paso

   • W = 10 ÷ (1 − ρ): 10 ÷ 0.5 = 20 ms; 10 ÷ 0.3 ≈ 33 ms; 10 ÷ 0.2 = 50 ms; 10 ÷ 0.1 = 100 ms; 10 ÷ 0.05 = 200 ms.
   • De 50 a 95 %, la carga no llega al doble y el tiempo se multiplica por 10.
3. 3Fácil

   Una cadena tiene tres tramos, con números parecidos a los de C01: la CPU del gateway aguanta 800 por segundo, la red 650 y las GPUs 2,400. ¿Cuál es el throughput máximo de la cadena? ¿Ayuda comprar otra GPU?

   Ver la solución paso a paso

   • El máximo es el del tramo más angosto: 650 por segundo, la red. Es el cuello de botella.
   • Otra GPU sube su tramo a 3,600 y la cadena sigue en 650: no ayuda. Ayuda mandar menos bytes (uint8) o más red.
4. 4Fácil

   Con la ventana de 2 ms de Triton, ¿cuántas requests llegan en la ventana a una T4 que recibe 500 por segundo? ¿Cuánto tardaría en llenarse un batch de 32?

   Ver la solución paso a paso

   • En la ventana: 500 × 0.002 = 1 request en promedio.
   • Para llenar 32: 32 ÷ 500 = 0.064 s = 64 ms. Por eso la ventana corta a los 2 ms: esperar a llenarlo se comería un tercio de los 200 ms de la promesa.
5. 5Medio

   El pico de diseño de C01 sube a 650 por segundo. Con la T4 a 1,200 medidas y planeada al 50 %, ¿cuántas compras con N+1? ¿A qué utilización trabaja cada una en el pico? ¿Y si cae una?

   Ver la solución paso a paso

   • Por throughput: ⌈650 ÷ 600⌉ = ⌈1.08⌉ = 2. Con repuesto: 3 T4.
   • Las tres vivas: 650 ÷ (3 × 1,200) ≈ 18 %.
   • Si cae una: 650 ÷ (2 × 1,200) ≈ 27 %. La fracción que pasa de 600 obliga a la segunda GPU: el redondeo hacia arriba compra mucho headroom.
6. 6Medio

   Una prueba cerrada usa 100 usuarios virtuales. Con el servidor respondiendo en 50 ms, ¿qué tasa manda? Si el servidor se frena a 500 ms, ¿qué tasa manda ahora? ¿Qué le pasa a lo que mide?

   Ver la solución paso a paso

   • Cada usuario manda 1 ÷ 0.05 = 20 por segundo: 100 × 20 = 2,000 por segundo. Es Little al revés: λ = L ÷ W.
   • A 500 ms: 100 ÷ 0.5 = 200 por segundo, diez veces menos.
   • Justo cuando el servidor está lento, la prueba manda menos y mide menos requests lentas. Los usuarios reales seguirían llegando a 2,000: el p99 real sería peor que el medido.
7. 7Medio

   En una rampa, el servicio cumple su p99 ≤ 200 ms hasta 900 requests por segundo; a 1,000, el p99 es 260 ms y el throughput 990. ¿Cuál es su capacidad? ¿Su goodput a 1,000? Si planeas al 60 %, ¿cuánto le asignas?

   Ver la solución paso a paso

   • Capacidad: 900 por segundo, el último escalón que cumple. No 990: ahí ya no cumple.
   • A 1,000 ofrecidas, el SLO se rompe, así que más de 1 % llega tarde. El goodput de la prueba, la carga máxima que cumple, sigue siendo 900.
   • Planeado al 60 %: 900 × 0.6 = 540 por segundo por réplica.
8. 8Reto

   Un pico sube el tráfico de C01 de 500 a 750 por segundo en un minuto. El gateway tiene 5 pods con 1 núcleo y S = 6 ms. Supón que el HPA tarda 3 minutos en tener listos los pods nuevos. (a) ¿Qué ρ, W y p99 tiene cada pod en esos 3 minutos, con M/M/1? (b) ¿Cuántos pods pide el HPA, con su objetivo de 60 %? (c) ¿Qué cambiarías para no depender de esos 3 minutos?

   Ver la solución paso a paso

   • (a) 750 ÷ 5 = 150 por pod; ρ = 150 × 0.006 = 0.9. W = 6 ÷ 0.1 = 60 ms; p99 ≈ 4.6 × 60 ≈ 276 ms: solo el pod ya pasa los 200 ms de la promesa. Contra el pico de diseño (ρ = 0.6, 9 ms de espera en la fila), la espera se multiplicó por 6 con 1.5 veces la carga: 0.9 × 6 ÷ 0.1 = 54 ms.
   • (b) ⌈5 × 90 ÷ 60⌉ = ⌈7.5⌉ = 8 pods: 750 ÷ 8 ≈ 94 por pod, ρ ≈ 0.56.
   • (c) Más headroom de base para los picos conocidos (un mínimo de pods más alto antes de un evento), el MAX_INFLIGHT que rechaza rápido lo que no cabe, y mandar el tensor en uint8 para aliviar la red, el primer cuello de botella.
9. 9Reto

   A una T4 le ofrecen 1,600 fotos por segundo y procesa ≈ 1,210. (a) Sin tope en la fila, ¿cuánto espera la última request que llegó a los 5 s? ¿Cuál es el goodput si el gateway corta a los 150 ms? (b) Con el tope de 100 ms de Triton, ¿qué fracción se rechaza? (c) ¿Por qué la CPU del pod de Triton no le avisaría al HPA?

   Ver la solución paso a paso

   • (a) Sobran 1,600 − 1,210 = 390 por segundo. A los 5 s esperan 1,950, que tardan 1,950 ÷ 1,210 ≈ 1.6 s en salir. Todas pasan los 150 ms: goodput ≈ 0.
   • (b) (1,600 − 1,210) ÷ 1,600 ≈ 24 % rechazadas; el 76 % restante sale antes del timeout. La Ronda (M06) trae justo este caso: ≈ 24 % de rechazos.
   • (c) La CPU de ese pod sigue al throughput terminado, que se quedó en 1,210: la señal se congela mientras se rechaza una de cada cuatro. Por eso C01 escala Triton por el tiempo en la fila.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿En qué tres cosas se va el tiempo de una request en cada salto, y cuál crece cerca del pico?Ver respuesta

   Viajar (la red), esperar (la fila) y trabajar (el tiempo de servicio). Cerca del pico crece la espera. La utilización, ρ = λ × S ÷ c, dice cuánto: un pod con 100 requests por segundo de 6 ms y un núcleo está a 0.6.

2. 2¿Por qué la espera explota cerca del 100 % aunque todavía quede tiempo libre?Ver respuesta

   Porque las llegadas vienen en ráfagas y cada ráfaga deja una fila que solo se deshace con tiempo libre. En M/M/1, W = S ÷ (1 − ρ): de 50 a 90 % la espera en la fila se multiplica por 9.

3. 3¿Qué es el cuello de botella de C01 en el pico de diseño, y qué no lo es?Ver respuesta

   La red del gateway (≈ 77 %) y luego su CPU (60 %). La GPU, la pieza más cara, va al ≈ 21 %.

4. 4¿Para qué sirve el headroom?Ver respuesta

   Para que el p99 no salga de la parte plana de la curva, para aguantar la caída de una réplica o zona, para cubrir los minutos que tarda el autoscaler y para el error de la medición.

5. 5¿Qué hace una cola acotada que no hace una fila sin tope?Ver respuesta

   Rechaza rápido lo que no va a llegar a tiempo. Así las demás se contestan a tiempo. Una fila sin tope atiende a todas y todas llegan tarde: throughput al máximo y goodput en cero.

6. 6¿Por qué una prueba de carga cerrada reporta un p99 mejor que la realidad?Ver respuesta

   Porque cuando el servidor se frena, los usuarios virtuales esperan y mandan menos requests justo en el peor momento. Es la coordinated omission. Para medir latencia, carga abierta a una tasa fija.