Hacer varias cosas a la vez: async, event loop y GIL

Qué es I/O

Un programa calcula con lo que tiene a la mano: la CPU, que hace las cuentas, y la RAM, la memoria donde guarda sus datos mientras corre. Todo lo demás está afuera: el disco, la red, otros servicios, la GPU. Pedirle algo a lo de afuera, o mandárselo, se llama I/O (input/output, entrada y salida).

Leer un archivo es I/O. Recibir los bytes de la foto de Ana, también. Y mandarle el tensor a Triton, el servidor que corre el modelo en la GPU, para que regrese los logits, también: la GPU calcula en otra máquina, y el gateway solo espera.

Lo que distingue al I/O es lo que tarda. Los números son aproximados, pero sus órdenes de magnitud no cambian. Para sentirlos, imagina que un nanosegundo durara un segundo:

Mientras el gateway espera esos 10 ms a Triton, un núcleo de ≈ 3 GHz (3 × 10⁹ ciclos de reloj por segundo) da 3 × 10⁹ × 0.01 s = 30 millones de ciclos, y en cada ciclo termina varias instrucciones. Una operación suelta es casi gratis comparada con una espera. La CPU se nota cuando son millones de operaciones, como al decodificar una foto.

Bloquear

¿Qué hace un programa mientras espera? Con el código de todos los días, nada. Cuando escribes datos = archivo.read() o r = requests.get(url) (requests es una de las librerías de Python más usadas para pedir datos por la red), el hilo se queda detenido en esa línea hasta que llegan los bytes. Una llamada así es bloqueante, y a esa espera se le llama bloqueo (llamada bloqueante) (blocking): el hilo pasa al estado «bloqueado» que viste con el planificador en «Programa, proceso e hilo».

Bloquear no gasta CPU: el sistema operativo duerme al hilo y le presta el núcleo a otro. Lo que gasta es el hilo: mientras espera, no puede atender nada más. Un servidor con un solo hilo que bloquea atiende de una en una.

La salida clásica es darle un hilo a cada request: mientras uno espera, el sistema operativo corre otro, y cada cambio es un cambio de contexto de microsegundos. Funciona con decenas o cientos a la vez. Con miles se vuelve caro, porque cada hilo necesita su propia pila en memoria y el sistema operativo tiene que repartirles turnos a todos. La otra salida, la de esta lección, es que un solo hilo aproveche las esperas.

De qué está hecha una request de C01

Suman de 18 a 20 ms: son los números de una request típica (M03 y C01). El promedio que usa la Ronda, ≈ 50 ms, es una estimación más larga: suma las esperas en fila, detrás de otras requests, y las requests lentas, que jalan el promedio hacia arriba. La CPU trabaja ≈ 6 a 7 ms por request, casi todo en el decode; la Ronda usa ≈ 6 ms en sus cuentas de capacidad, y aquí también. Todo lo demás es esperar, y ahí está el truco: mientras una request espera, el núcleo puede trabajar para otra.

Un trabajo tarda por una de dos razones: mucho que calcular o mucho que esperar. Las dos tienen nombre en inglés:

• CPU-bound, limitado por la CPU: tarda por las cuentas. Mientras corre, un núcleo está al 100 %. Decodificar una foto, tokenizar texto, correr un modelo en CPU.
• I/O-bound, limitado por el I/O: tarda por las esperas. Mientras tanto, la CPU casi no trabaja. Llamar a otro servicio, descargar archivos, escribir logs (el registro de lo que va pasando).

Cómo saber cuál es

Compara dos relojes: el tiempo que pasó y el tiempo que la CPU trabajó para tu programa. Python tiene los dos: time.perf_counter() es el reloj de pared (el tiempo que pasa de verdad), y time.process_time() cuenta solo el tiempo de CPU de tu proceso.

import time

def esperar():                 # I/O: aquí la espera es un sleep; en la vida, la red o el disco
    time.sleep(0.5)

def calcular():                # CPU: cuentas y nada más
    total = 0
    for i in range(8_000_000):
        total += i * i

for tarea in (esperar, calcular):
    reloj0, cpu0 = time.perf_counter(), time.process_time()
    tarea()
    reloj = time.perf_counter() - reloj0     # cuánto tardó, en el reloj de pared
    cpu = time.process_time() - cpu0         # cuánto trabajó la CPU para este programa
    if cpu / reloj > 0.5:
        print(f"{tarea.__name__:>8}: la CPU trabajó casi todo el tiempo → CPU-bound")
    else:
        print(f"{tarea.__name__:>8}: la CPU casi no trabajó → I/O-bound")

 esperar: la CPU casi no trabajó → I/O-bound
calcular: la CPU trabajó casi todo el tiempo → CPU-bound

Donde se escribió esta lección, esperar usó ≈ 0 % de CPU y calcular, ≈ 100 %. En tu máquina los tiempos cambian, pero la diferencia no: esperar no gasta CPU, y calcular la gasta toda.

En producción se lee igual, en las gráficas: lento con un núcleo al 100 % es CPU-bound; lento con la CPU baja, algo está esperando.

Qué es qué en ML

La regla que ordena todo

Lo que espera se puede encimar; lo que calcula solo se reparte. Mientras una request espera, otra puede avanzar, sin gastar un núcleo más. Las cuentas, en cambio, necesitan núcleos: para hacer más hay que repartirlas entre más núcleos o más máquinas, o calcular menos.

C01 tiene de las dos en cada request, y por eso usa dos herramientas: async para las esperas y un threadpool (grupo de hilos), un grupo de hilos aparte, para las cuentas. Las secciones que siguen las arman.

La idea de async: mientras una request espera a Triton, que otra avance en el mismo hilo. Hacen falta dos cosas: código que diga dónde espera y alguien que reparta los turnos.

Corrutinas: funciones que se pueden pausar

Una función normal corre de principio a fin, y mientras corre, el hilo es suyo. Una corrutina (coroutine) es una función que se puede pausar a la mitad y seguir después, donde se quedó, con sus variables intactas. En Python se escribe con async def.

Dentro de una corrutina, await marca un punto de espera: «aquí espero algo; mientras llega, que corra otra». await asyncio.sleep(0.3) espera 0.3 s sin detener al hilo (asyncio es la parte de Python que trae todo esto), y await triton.infer(...) espera la respuesta de Triton igual.

El event loop: el que reparte los turnos

Las corrutinas no se turnan solas. Las administra el event loop (ciclo de eventos), un ciclo que corre en un solo hilo. Cada corrutina que le entregas es una tarea (task), y el loop lleva dos listas: las tareas listas para avanzar y las que esperan algo. Repite cuatro pasos:

1. 1

   Toma una tarea lista

   La primera de la fila.

2. 2

   La deja correr hasta su siguiente await

   Ahí la tarea se pausa sola y le regresa el turno al loop.

3. 3

   La anota entre las que esperan

   Y le pide al sistema operativo que le avise cuando llegue lo que espera: los bytes de una conexión, la respuesta de Triton, que pase cierto tiempo.

4. 4

   Vuelve a empezar

   Con la siguiente tarea lista. Si no hay ninguna, el loop duerme hasta que el sistema operativo le avise que algo llegó, y esa tarea vuelve a la fila de las listas.

Programar así es async (programación asíncrona) (asíncrono). En Python, el event loop viene en asyncio, que es parte de la biblioteca estándar: lo que trae Python sin instalar nada. El gateway de C01 está escrito con FastAPI, una librería de Python para hacer APIs, y lo corre uvicorn, un servidor que arranca un event loop en cada proceso y crea una tarea por cada request que llega.

import asyncio, time

async def atender(nombre, espera):
    print(f"{nombre}: llega y espera {espera} s")
    await asyncio.sleep(espera)                 # el punto de espera: aquí suelta el turno
    print(f"{nombre}: listo")

async def main():
    t0 = time.perf_counter()
    for nombre, espera in (("A", 0.3), ("B", 0.1), ("C", 0.2)):
        await atender(nombre, espera)            # una tras otra: cada una espera a la anterior
    print(f"una tras otra: {time.perf_counter() - t0:.1f} s\n")

    t0 = time.perf_counter()
    await asyncio.gather(atender("A", 0.3), atender("B", 0.1), atender("C", 0.2))
    print(f"turnándose: {time.perf_counter() - t0:.1f} s")

asyncio.run(main())

A: llega y espera 0.3 s
A: listo
B: llega y espera 0.1 s
B: listo
C: llega y espera 0.2 s
C: listo
una tras otra: 0.6 s

A: llega y espera 0.3 s
B: llega y espera 0.1 s
C: llega y espera 0.2 s
B: listo
C: listo
A: listo
turnándose: 0.3 s

La última línea, asyncio.run(main()), arranca un event loop y le entrega main como su primera tarea. Fíjate en dos cosas. Primera: await solo no encima nada. En la primera mitad, cada await atender(...) espera a que esa request termine antes de empezar la siguiente: 0.3 + 0.1 + 0.2 = 0.6 s. Para turnarse hacen falta varias tareas a la vez, y eso hace asyncio.gather: convierte cada corrutina en una tarea, se las entrega al loop y espera a que terminen todas. En un servidor no lo escribes tú: uvicorn crea una tarea por request.

Segunda: turnándose, el total es lo que tarda la espera más larga, 0.3 s, y B termina primero aunque llegó segunda. Las tres esperas se encimaron.

Esto es concurrencia sin paralelismo: tres requests en curso, pero en cada instante solo una corrutina corre, en un solo núcleo. Y async no hace más rápida a ninguna request. La Ronda (M03) lo dice así: «La concurrencia deja atender a otros mientras uno espera a Triton; no acelera a ninguno».

Desde 9 a la vez ya no sube: con 6 ms de CPU cada una, un núcleo termina como máximo 1,000 ÷ 6 ≈ 167 por segundo, y las que sobran hacen fila. Encimar esperas sirve hasta que la CPU se llena.

El loop tiene una regla que no se negocia: una corrutina suelta el turno solo en un await. Entre dos await, el hilo es suyo y nadie más corre. Es un trato de confianza: funciona mientras cada una suelte el turno pronto.

La trampa de C01

En FastAPI, la función que atiende una dirección de la API, como /v1/classify, se llama ruta (route; no es la ruta de un archivo). La de abajo es la trampa que la Ronda cuenta en C01, M02, M03 y M07; la línea @app.post la conecta con su dirección. Es una ilustración, sin salida, porque necesita FastAPI:

@app.post("/v1/classify")
async def classify(request: Request):
    body = await request.body()      # I/O: suelta el turno mientras llegan los bytes. Bien.
    x = preprocess(body)             # CPU: ≈ 6 ms; de 40 a 80 con una foto de 12 MP. Sin await.
    return await infer(x)            # I/O: suelta el turno mientras responde Triton. Bien.

preprocess decodifica y redimensiona con la CPU, sin ningún await, y mientras tanto el loop está detenido. Ninguna otra request avanza: ni las que ya tienen su respuesta de Triton esperando, ni las que acaban de llegar, ni el health check, la request que Kubernetes manda cada pocos segundos para preguntar «¿sigues vivo?».

El síntoma

La Ronda lo resume en una frase: «un p99 que crece con la concurrencia sin que la CPU esté llena». La mediana se mueve poco y las requests más lentas, mucho: las que caen detrás de una foto grande esperan decenas de milisegundos de más, y esas forman el p99, el tiempo que solo 1 de cada 100 supera. Y la CPU no tiene por qué llenarse: la espera no es por falta de núcleos, es por falta de turnos, porque todo pasa por un solo hilo.

Hay un efecto peor. En C01, Kubernetes le pregunta a cada pod por su salud cada 10 s y espera la respuesta 2 s. Si el loop está congelado más de 2 s en tres preguntas seguidas, Kubernetes da al pod por muerto y lo reinicia, justo en la hora de más tráfico.

import asyncio, time

def decodificar():                       # bloqueante: un decode de verdad ocupa así el hilo
    time.sleep(0.3)

async def latido(huecos):                # como un health check: debería avanzar cada 50 ms
    for _ in range(8):
        antes = time.perf_counter()
        await asyncio.sleep(0.05)
        huecos.append(time.perf_counter() - antes)

async def ruta_mal():
    decodificar()                        # corre en el hilo del loop: nadie más avanza

async def ruta_bien():
    await asyncio.to_thread(decodificar)  # corre en otro hilo; el loop sigue repartiendo turnos

async def probar(ruta):
    huecos = []
    await asyncio.gather(latido(huecos), ruta())
    return max(huecos)

for ruta in (ruta_mal, ruta_bien):
    hueco = asyncio.run(probar(ruta))
    print(f"{ruta.__name__}: entre dos latidos pasaron hasta {round(hueco * 20) * 50} ms")

ruta_mal: entre dos latidos pasaron hasta 300 ms
ruta_bien: entre dos latidos pasaron hasta 50 ms

Los arreglos

Los sospechosos de siempre son time.sleep, las librerías de red que no son async (como requests), leer archivos grandes, decodificar imágenes, correr el modelo de PyTorch (model(x)) y armar un JSON enorme (el formato de texto con que viajan los datos de una API). El bloque de abajo trae cada uno con su arreglo.

En FastAPI hay tres arreglos. Usar las librerías que se esperan con await para el I/O. Mandar lo bloqueante a un hilo con await run_in_threadpool(preprocess, body), que es el arreglo de C01. O escribir la ruta con def en vez de async def: FastAPI la corre entera en un hilo de su threadpool (grupo de hilos).

Si lo bloqueante va a otro hilo, ¿por qué no hacer todo con hilos? Porque en Python los hilos tienen una restricción que no tienen en la mayoría de los lenguajes.

Un candado para todo el intérprete

El Python que instalas normalmente se llama CPython: un intérprete escrito en C, como viste en «Programa, proceso e hilo». Tiene un candado (lock, como el que protege un contador entre hilos) para todo el intérprete: el GIL (Global Interpreter Lock), con una regla: dentro de un proceso, solo el hilo que tiene el GIL ejecuta código de Python. Los demás hilos esperan su turno.

Un hilo suelta el GIL en tres casos:

• Cuando espera. time.sleep, leer de la red, leer un archivo. Mientras espera, el GIL queda libre y otro hilo corre.
• Cuando entra a código en C que lo suelta. Pillow (la librería de imágenes que usa C01) al decodificar y redimensionar, NumPy en sus operaciones grandes, PyTorch dentro de cada operación. Hacen sus cuentas en C, sin tocar los datos de Python (sus objetos), y mientras tanto otro hilo puede correr Python.
• A la fuerza, cada 5 ms. Si un hilo calcula Python puro sin parar y otro espera el GIL, a los 5 ms el intérprete le pide que lo suelte (lo dice sys.getswitchinterval()), para que ningún hilo se quede sin turno.

La consecuencia, en una frase: los hilos de Python sirven para esperar, no para calcular, salvo que el cálculo pase en C y suelte el GIL.

Este programa lo mide. Cada tarea anota cuánta CPU usó su hilo (time.thread_time()), y la suma dividida entre lo que tardaron dice cuántos núcleos trabajaron en promedio:

import time
from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor
def esperar(_):                      # mientras duerme, el hilo suelta el GIL
    cpu0 = time.thread_time()        # la CPU que usa este hilo
    time.sleep(0.3)
    return time.thread_time() - cpu0

def calcular(_):                     # Python puro: necesita el GIL en cada paso
    cpu0, total = time.thread_time(), 0
    for i in range(4_000_000):
        total += i * i
    return time.thread_time() - cpu0

def nucleos(Pool, tarea):            # núcleos trabajando, en promedio: lo mejor de 5 intentos
    mejor = 0.0
    with Pool(max_workers=2) as pool:
        for _ in range(5):
            t0 = time.perf_counter()
            mejor = max(mejor, sum(pool.map(tarea, range(2))) / (time.perf_counter() - t0))
    return round(mejor)

if __name__ == "__main__":
    print("2 hilos que esperan, núcleos:    ", nucleos(ThreadPoolExecutor, esperar))
    print("2 hilos que calculan, núcleos:   ", nucleos(ThreadPoolExecutor, calcular))
    print("2 procesos que calculan, núcleos:", nucleos(ProcessPoolExecutor, calcular))

2 hilos que esperan, núcleos:     0
2 hilos que calculan, núcleos:    1
2 procesos que calculan, núcleos: 2

El programa mide 5 veces y se queda con la mejor, para que no cuente lo que la máquina hacía en otra cosa. Si la tuya tiene al menos dos núcleos y usas el Python de siempre, el que tiene GIL, deberían salirte los mismos números. El if __name__ == "__main__": hace falta por los procesos, como en «Programa, proceso e hilo»: para arrancar cada uno, Python vuelve a leer tu archivo (en macOS, en Windows y, desde la 3.14, en Linux), y sin esa línea cada hijo volvería a correr todo el archivo e intentaría arrancar sus propios procesos: Python lo impide con un error (RuntimeError) y el programa falla.

En producción, la Ronda (M07) da el síntoma: «CPU del proceso clavada en ≈ 100 % de un core con los demás libres». Pasa con el código en Python puro alrededor del modelo: recorrer una por una las cajas que encontró un detector de objetos, leer o armar un JSON grande.

El trabajo de CPU no va en el loop. ¿A dónde, entonces? Hay tres lugares, del más barato al más caro.

1. Un threadpool

Un threadpool (grupo de hilos) (grupo de hilos) es un conjunto de hilos que se reusan: esperan trabajo en una fila. Llega una tarea y la toma un hilo libre; si todos están ocupados, la tarea espera su turno. Tiene dos ventajas: no se paga crear un hilo por tarea, y hay un tope.

En un servidor async, el pool es el lugar natural para lo bloqueante: el loop le pasa la tarea y espera el resultado con await, así que sigue repartiendo turnos. FastAPI usa un pool de 40 hilos por omisión (el de run_in_threadpool y las rutas def), y asyncio tiene el suyo, el de asyncio.to_thread.

¿Y acelera las cuentas? Depende del GIL: sí, para lo que corre en C y lo suelta, como el decode de Pillow, NumPy o PyTorch; no, para Python puro. Aunque no las acelere, el pool libera al loop: el planificador turna los hilos en los núcleos y el GIL cambia de dueño cada 5 ms, así que el loop recibe su turno aunque el decode siga. Si el decode corre en C, como el de Pillow, el loop ni siquiera espera el GIL.

El tope importa tanto como el pool. C01 deja decodificar solo 2 fotos a la vez por pod, no 40: un PNG de 40 MP llega a ocupar ≈ 320 MB mientras se decodifica (lo midió la Ronda), y el pod tiene 1 GiB de memoria. Cómo se pone ese tope está en la sección extra «Async a fondo».

2. Varios procesos

Para calcular Python puro en paralelo hay que salir del GIL: multiproceso, varios procesos, cada uno con su intérprete, su memoria y su GIL. concurrent.futures.ProcessPoolExecutor es el pool de procesos que usaste en la sección anterior.

Cuesta tres cosas: arrancar un intérprete por proceso; copiar los datos de ida y de vuelta, porque los procesos no comparten memoria (Python los convierte en bytes con pickle); y que cada proceso cargue su propia copia de todo, modelo incluido.

3. Workers

Un worker (trabajador) es un proceso, a veces un hilo, que toma trabajo de una fila y lo hace. La palabra tiene dos usos:

• Workers de un servidor. uvicorn --workers 4 arranca 4 procesos iguales, cada uno con su event loop, que se reparten las requests. Un proceso padre los vigila: si uno muere o se queda colgado, arranca otro. gunicorn, muy usado en Python, hace lo mismo, y puede arrancar workers de uvicorn.
• Workers de una cola, los del patrón asíncrono de M02 (asíncrono en la arquitectura, no en el código): procesos que sacan trabajos (jobs) de una cola y los procesan a su ritmo.

Los workers de un servidor tienen una trampa cuando hay un modelo adentro: cada proceso carga el suyo. Con una CNN chica como la ResNet-50 caben, pero se turnan la GPU sin armar batches entre ellos. Con Llama 3 8B, que pesa ≈ 16 GB en BF16 (8 mil millones de parámetros × 2 bytes), dos workers ya no caben en una GPU L4 de 24 GB. La cuenta completa, con la memoria que pide CUDA en cada proceso, está en la sección extra de «Programa, proceso e hilo». Para un modelo grande, la salida es un servidor con una sola copia que arme batches adentro.

Por qué C01 corre un solo proceso por pod

C01 corre un solo worker de uvicorn por contenedor y escala con más pods: el HPA (Horizontal Pod Autoscaler), la regla de Kubernetes que agrega o quita pods según su CPU, los mueve entre 3 y 12. La Ronda (M05) da las razones: varios workers en un pod esconden cuánta CPU usa cada proceso, multiplican la memoria, complican las métricas (los números que el servicio publica para vigilarlo) y pueden dejar un pod «sano» con un worker colgado.

Así, la concurrencia de C01 se reparte en capas. En cada pod, el loop encima las esperas y 2 hilos hacen las cuentas. Entre pods, Kubernetes reparte los núcleos. Y Triton, escrito en C++ y sin GIL, junta las fotos de muchas requests en un batch para la GPU.

Falta una pregunta: ¿cuántas cosas a la vez? ¿Cuántas requests en vuelo, cuántos hilos, cuántas conexiones? La respuesta es una multiplicación.

L = λ × W. Lo que hay adentro, en promedio, es lo que llega por unidad de tiempo por lo que tarda cada uno adentro. Es la Ley de Little (Little's law), que John Little demostró en 1961:

• L: cuántas hay adentro en promedio. En un servidor, las requests en vuelo: ya llegaron y todavía no terminan.
• λ (la letra griega lambda): la tasa de llegada, en requests por segundo.
• W: cuánto pasa cada una adentro, en promedio: su latencia.

El ejemplo de todos los días: a un restaurante llegan 100 clientes por hora y cada uno se queda media hora. Adentro hay, en promedio, 100 × 0.5 = 50. No importa el menú ni a qué hora llegó cada quien.

Vale para cualquier cosa con entradas y salidas. En C01 sirve para cuatro cosas:

Dónde se pone el límite

Cada request en vuelo ocupa algo: memoria para su foto, una conexión, un lugar en el loop. Por eso el gateway de C01 tiene un tope, MAX_INFLIGHT = 16 por pod: la request 17 recibe al instante un 503, un error que dice «estoy saturado, reintenta», y rechazarla cuesta microsegundos. ¿Por qué 16? Por Little al revés: a 100 por segundo, con 20 en vuelo cada request tardaría en promedio 20 ÷ 100 = 0.2 s, justo la promesa de 200 ms de C01, y con más, ni el promedio la cumpliría. Se baja a 16 por memoria: 16 fotos de hasta 10 MB son 160 MB, que caben en el 1 GiB del pod junto con los 2 decodes.

Little también dice qué pasa cuando algo se frena. El gateway espera a Triton como máximo 150 ms: es su timeout, su tiempo máximo de espera. Si Triton tarda hasta ese límite, las llamadas abiertas pasan de 5 a 500 × 0.15 = 75, ≈ 15 por pod. Con un timeout de 5 s serían 500 × 5 = 2,500 colgadas, ≈ 500 por pod, cada una con su memoria y su conexión, para respuestas que nadie espera: quien llamó, el backend del marketplace (el programa que pidió la categoría), se va a los 300 ms. Los timeouts acotan W y, con W, la concurrencia.

La trampa: Little habla de promedios

L es un promedio. En un instante dado puede haber muchas más, porque las requests llegan al azar: en una hora simulada de un pod, con 5 en promedio, hubo un momento con 19. Por eso un tope como el de C01 deja margen sobre el promedio. Con 16, el pod casi nunca rechaza en condiciones normales, y si rechaza seguido, algo va lento.

Lo que no se hace es multiplicar la tasa por el p99 para sacar «la concurrencia en el peor caso». La Ronda (M03) es tajante: «es una cuenta sin significado». Piensa en el restaurante: si el cliente más lento de cada 100 se queda 2 horas (un supuesto), 100 × 2 = 200 supondría que todos se quedan 2 horas; adentro sigue habiendo 50 en promedio. Cuántos hay en el peor momento depende de cuántos llegan juntos, y eso lo dicen una simulación o una prueba de carga.

import random
from collections import Counter
random.seed(7)

lam, W = 100, 0.050                     # un pod de C01: 100 requests por segundo, 50 ms en promedio
eventos, t = [], 0.0
for _ in range(360_000):                # una hora de tráfico
    t += random.expovariate(lam)        # llegadas al azar, 100 por segundo en promedio
    dura = random.expovariate(1 / W)    # cada una tarda distinto: 50 ms en promedio
    eventos += [(t, +1), (t + dura, -1)]

tiempo, adentro, antes = Counter(), 0, 0.0   # tiempo[n]: cuánto duró «n requests en vuelo»
for instante, cambio in sorted(eventos):     # recorre la hora: +1 al llegar, −1 al salir
    tiempo[adentro] += instante - antes
    adentro, antes = adentro + cambio, instante

total = sum(tiempo.values())
# el primer n que, sumando su tiempo y el de todos los de abajo, junta el 99 % de la hora
p99 = next(n for n in sorted(tiempo) if sum(tiempo[k] for k in tiempo if k <= n) >= 0.99 * total)
print(f"Little, λ × W: {lam} × {W} = {lam * W:.1f} en vuelo")
print(f"simulado, en promedio: {sum(n * s for n, s in tiempo.items()) / total:.1f} en vuelo")
print(f"el 99 % del tiempo hubo {p99} o menos; el máximo fue {max(tiempo)}")
print(f"16 o más en vuelo: {100 * sum(s for n, s in tiempo.items() if n >= 16) / total:.3f} % del tiempo")

Little, λ × W: 100 × 0.05 = 5.0 en vuelo
simulado, en promedio: 5.0 en vuelo
el 99 % del tiempo hubo 11 o menos; el máximo fue 19
16 o más en vuelo: 0.005 % del tiempo

Cuándo deja de funcionar

Aplicada a la CPU, Little da los núcleos ocupados: tasa × CPU por request. Ese número tiene un techo, los núcleos que tienes. Si lo pasa, cada segundo llega más trabajo del que se puede hacer y la fila crece sin parar. Y aun en el 100 % justo, la fila no tiene techo: por eso se deja margen, y el HPA de C01 apunta al 60 %.

Pasa más fácil de lo que parece: basta con que suba el tráfico o la CPU de cada request. Una foto web de 12 MP sin draft mode cuesta de 40 a 80 ms de CPU, no 6, y el ejercicio 6 calcula con cuántas así ya no alcanza.

Con esto ya tienes la respuesta completa. Un pod de C01 atiende 100 requests por segundo porque cada una pasa casi toda su vida esperando y el loop las encima: 5 en vuelo con 0.6 vCPU. Deja de funcionar de tres maneras:

1. Algo bloquea el loop, y nadie avanza.
2. La CPU no alcanza: tasa × CPU por request llega a los núcleos.
3. W crece, porque algo de atrás se frena, y la concurrencia crece con ella hasta acabarse la memoria o las conexiones. Por eso los timeouts y los topes.

1. Llamar algo bloqueante dentro de async def

time.sleep, requests.get, un decode de Pillow o model(x) dentro de una ruta async def congelan el loop: ninguna request avanza, ni los health checks.

Cómo evitarlo: para el I/O, las versiones que se esperan con await (asyncio.sleep, httpx.AsyncClient, tritonclient.http.aio). Lo bloqueante y la CPU, a un hilo con run_in_threadpool o asyncio.to_thread, o la ruta escrita con def. Y una métrica aparte para el preproceso.

2. Creer que async hace más rápida cada request

Async no acelera a nadie: deja que, mientras una espera, otras avancen. Una request sola tarda lo mismo, y a un trabajo CPU-bound no le ayuda en nada.

Cómo evitarlo: pregunta primero dónde se va el tiempo. Si es espera, async o hilos. Si es CPU, procesos, más máquinas o calcular menos.

3. Usar hilos para acelerar Python puro

Por el GIL, cuatro hilos que calculan Python puro usan un núcleo, no cuatro.

Cómo evitarlo: procesos o más pods, o mover la cuenta a código que suelte el GIL (NumPy, Pillow, PyTorch).

4. Pools y filas sin tope

Un pool de 40 hilos que decodifica 40 fotos de 40 MP pide 12.8 GB en un pod de 1 GiB. Una fila sin tope (asyncio.Queue()) nunca falla: solo crece, y la latencia con ella.

Cómo evitarlo: un tope por recurso (los 2 lugares de CPU de C01, MAX_INFLIGHT = 16, filas con maxsize) y rechazar rápido lo que no cabe: un 503 cuesta microsegundos.

5. Varios workers con el modelo adentro

uvicorn --workers 4 son 4 procesos y 4 copias del modelo, sin batching entre ellos. Con Llama 3 8B, ni dos copias caben en una L4.

Cómo evitarlo: un proceso por contenedor y más pods para la CPU; para el modelo, un servidor con una sola copia que arme batches, como Triton o vLLM.

6. Calcular la concurrencia con el p99

λ × p99 no es el peor caso: es una cuenta sin significado, porque Little habla de promedios.

Cómo evitarlo: L = λ × W con la latencia promedio, y λ del pico, no del promedio del día. El peor caso lo acota el timeout (500 × 0.15 = 75), y el margen se mide con una prueba de carga.

7. Un await sin timeout

La Ronda (M03) lo dice así: «Un servicio lento es peor que uno caído». Por Little, cada segundo de más que tarda suma λ requests colgadas: a 500 por segundo, 500 más.

Cómo evitarlo: un timeout en cada llamada por la red, más corto que el de quien te llama, y pasarle a cada salto (cada servicio por el que pasa la request) lo que queda del presupuesto.

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

1. 1Fácil

   ¿CPU-bound o I/O-bound? (a) Descargar 1,000 fotos de S3. (b) Redimensionar 1,000 fotos que ya están en memoria. (c) Pedirle una respuesta a la API de un LLM. (d) Tokenizar 10,000 textos con un ciclo de Python. (e) Escribir una línea de log por request.

   Ver la solución paso a paso

   • (a) I/O-bound: casi todo es esperar a la red.
   • (b) CPU-bound: cuentas sobre millones de píxeles.
   • (c) I/O-bound: tu programa espera segundos; el que calcula es el servidor del LLM.
   • (d) CPU-bound: un ciclo de Python que no espera nada.
   • (e) I/O-bound: escribir al disco o a la red. Por eso C01 escribe cada línea a la salida del programa (stdout) y otro programa la lleva a S3: la respuesta no espera al log.
2. 2Fácil

   Un servidor con un solo hilo bloquea mientras espera, y cada request tarda 25 ms. ¿Cuántas atiende por segundo? ¿Y con 4 hilos, si casi todo es espera?

   Ver la solución paso a paso

   • De una en una: 1 ÷ 0.025 s = 40 por segundo.
   • Con 4 hilos, 4 requests en curso a la vez: 4 × 40 = 160 por segundo, mientras la CPU alcance. Como casi todo es espera, los hilos sueltan el GIL y se enciman.
3. 3Fácil

   A un servicio le llegan 200 requests por segundo y cada una tarda 80 ms en promedio. ¿Cuántas hay en vuelo? ¿Y si la latencia sube a 400 ms?

   Ver la solución paso a paso

   • Little: L = 200 × 0.08 s = 16 en vuelo.
   • Con 400 ms: 200 × 0.4 = 80. Cinco veces la latencia son cinco veces los hilos, las conexiones y la memoria.
4. 4Fácil

   Una ruta async def hace time.sleep(1) y llegan 5 requests al mismo tiempo. ¿Cuándo termina la última? ¿Y si fuera await asyncio.sleep(1)?

   Ver la solución paso a paso

   • time.sleep(1) bloquea el loop: las 5 se atienden en fila, y la última termina a los 5 s.
   • await asyncio.sleep(1) suelta el turno: las 5 esperas se enciman, y todas terminan a los ≈ 1 s.
5. 5Medio

   Un script de Python puro procesa 4 archivos, y cada uno pide 2 s de CPU. ¿Cuánto tarda con 1 hilo, con 4 hilos y con 4 procesos, en una máquina de 4 núcleos?

   Ver la solución paso a paso

   • 1 hilo: 4 × 2 s = 8 s.
   • 4 hilos: también ≈ 8 s. El GIL deja correr Python a un hilo a la vez: los cuatro se turnan el mismo núcleo.
   • 4 procesos: ≈ 2 s más lo que tardan en arrancar, porque cada uno tiene su GIL y su núcleo.
   • Si el trabajo fuera esperar a la red, los 4 hilos sí tardarían lo de uno.
6. 6Medio

   Un pod de C01 recibe 100 requests por segundo con ≈ 6 ms de CPU cada una. ¿Qué parte de su núcleo usa? Ahora 1 de cada 10 fotos llega de 12 MP sin draft mode y cuesta 60 ms. ¿Y ahora? ¿Desde qué fracción de fotos grandes deja de alcanzar?

   Ver la solución paso a paso

   • Al principio: 100 × 6 ms = 600 ms de CPU por segundo: 60 % del núcleo.
   • Con 10 % de fotos grandes: 0.9 × 6 + 0.1 × 60 = 11.4 ms en promedio, y 100 × 11.4 ms = 1.14 s de CPU por segundo: 114 %. No alcanza: la fila crece sin parar.
   • El límite es 10 ms en promedio, porque 100 × 10 ms = 1 s: 6 + f × (60 − 6) = 10, así que f = 4 ÷ 54 ≈ 7.4 %.
   • Arreglos: draft mode, rechazar las fotos demasiado grandes, más pods. El tráfico no subió; subió la CPU por request.
7. 7Medio

   Una request necesita features del vendedor (40 ms), la predicción del modelo (90 ms) y un re-ranker (60 ms). ¿Cuánto tarda en serie? ¿Y con asyncio.gather, si son independientes? ¿Y si el re-ranker necesita la predicción?

   Ver la solución paso a paso

   • En serie: 40 + 90 + 60 = 190 ms.
   • Las tres a la vez: lo que tarda la más lenta, 90 ms.
   • Si el re-ranker espera al modelo: las features van en paralelo con la cadena modelo → re-ranker, que suma 90 + 60 = 150. El total es el máximo: max(40, 150) = 150 ms.
8. 8Medio

   Tienes una L4 de 24 GB y un modelo que, con su contexto de CUDA, ocupa 7 GB por proceso. ¿Cuántos workers de uvicorn caben? ¿Por qué no es buena idea, y qué harías?

   Ver la solución paso a paso

   • Caben 24 ÷ 7 = 3.4, o sea 3 workers, con 3 GB libres.
   • Pero son 3 copias del mismo modelo turnándose la GPU con batch 1: la memoria se triplica y no se arman batches entre ellas.
   • Mejor un solo servidor con una copia del modelo que reciba la concurrencia y arme batches (Triton, o vLLM si es un LLM), y en el gateway, procesos sin modelo.
9. 9Reto

   C01 en el pico de diseño: 500 requests por segundo, 5 pods, 50 ms en promedio, de los que ≈ 10 son la llamada a Triton. Triton se frena y tarda hasta su timeout de 150 ms. (a) ¿Cuántas llamadas a Triton quedan abiertas por pod? (b) ¿Cuántas requests en vuelo por pod, contando todo? (c) ¿Qué hace MAX_INFLIGHT = 16? (d) ¿Y si el timeout fuera de 5 s?

   Ver la solución paso a paso

   • (a) 500 × 0.15 = 75 llamadas abiertas: 15 por pod.
   • (b) Cada request tarda ahora 50 − 10 + 150 = 190 ms. L = 500 × 0.19 = 95: 19 por pod.
   • (c) 19 no cabe en 16: el pod rechaza con un 503 inmediato lo que pasa del tope. Falla rápido, en microsegundos, en vez de encolar trabajo que se va a vencer.
   • (d) Con 5 s, 500 × 5 = 2,500 colgadas, ≈ 500 por pod, para respuestas que quien llamó abandonó a los 300 ms; sin el tope, se acaba la memoria. Por eso cada salto lleva timeout, y el gateway, tope.
10. 10Reto

    En C13 el audio llega en pedazos de 160 ms. Ahora la GPU tarda 180 ms en procesar cada uno, con una asyncio.Queue() sin tope en medio. (a) ¿Qué utilización implica? (b) ¿Cuánto atraso hay después de 30 minutos? (c) ¿Desde qué tiempo por pedazo deja de crecer el atraso, y qué regla pondrías mientras tanto?

    Ver la solución paso a paso

    • (a) 180 ÷ 160 = 1.125, es decir 112.5 %. Con más de 100 %, la fila no tiene techo.
    • (b) En 1,800 s llegan 1,800 ÷ 0.16 = 11,250 pedazos y salen 1,800 ÷ 0.18 = 10,000. Esperan 1,250 × 0.16 s = 200 s: 3 minutos y 20 segundos de atraso. Es lo mismo que 20 ms de atraso por cada uno de los 10,000 pedazos procesados.
    • (c) Deja de crecer cuando cada pedazo se procesa en menos de 160 ms, lo que tarda en llegar el siguiente. Mientras tanto, una fila con tope y una regla para cuando no alcanza, como la de la Ronda: saltarse resultados intermedios y, si el atraso pasa de ≈ 2 s, cerrar la sesión para que se reabra en una GPU con lugar.

En la Ronda:

• M02 · Patrones de inferencia abre con el patrón síncrono y su trampa: un JPEG decodificado dentro de un async def frena todo el proceso, health checks incluidos. Después arma el patrón asíncrono con cola y workers, y le aplica Little a los jobs.
• M03 · Latencia y capacidad separa latencia, throughput y concurrencia («25 = 500 × 0.05»), usa Little para el tope de requests en vuelo y el pool de conexiones a Triton, y cuenta cómo un threadpool saturado hace explotar el p99.
• M07 · Servidores de modelos parte de FastAPI con PyTorch: el modelo dentro de un async def, el GIL, uvicorn --workers 4 y el batching que Triton ya hace en C++.
• También M05 (un proceso por contenedor), M06 (escalar por requests en vuelo, con un objetivo que sale de Little) y M14 (en un LLM, la capacidad se cuenta en respuestas que se generan a la vez).

En el Dojo: cuando abra la estación 6, «Código de serving», ahí vas a escribir el gateway de C01 con estas piezas. La estación 7, «Empaquetado», ya mete un gateway y un servidor de modelo en contenedores, cada uno con uvicorn como único proceso.

En Sensei: la fase siguiente, «La red y la web», abre lo que aquí fue «esperar a la red»: cómo viaja un mensaje, HTTP y sus códigos (el 503 y el 504), los timeouts y los reintentos. Y «Qué tan rápido y cuánto: latencia y throughput» lleva la Ley de Little a las filas y a la utilización.

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¿Por qué una request del gateway de C01 pasa casi todo su tiempo esperando?Ver respuesta

   Porque casi todo lo que hace es I/O: recibir la foto y esperar ≈ 10 ms a Triton, además de esperar su turno. La CPU trabaja ≈ 6 a 7 ms, casi todo en el decode.

2. 2¿Qué hace await, y por qué un await solo no encima nada?Ver respuesta

   Marca un punto de espera y le regresa el turno al event loop, que corre otra tarea lista. Para encimar hacen falta varias tareas: asyncio.gather o, en un servidor, una por request.

3. 3¿Qué pasa si decodificas un JPEG dentro de una ruta async def?Ver respuesta

   El loop se detiene mientras dura el decode: nada avanza, ni el health check. El p99 crece con la concurrencia sin que la CPU esté llena. Arreglo: run_in_threadpool o asyncio.to_thread.

4. 4¿Por qué en Python los hilos sirven para esperar y no para calcular?Ver respuesta

   Por el GIL: solo el hilo que lo tiene ejecuta Python. Los que esperan lo sueltan y se enciman; los que calculan Python puro se turnan un núcleo. Pillow o PyTorch, que lo sueltan, sí aprovechan varios hilos.

5. 5¿Por qué C01 corre un solo worker de uvicorn por pod?Ver respuesta

   Porque varios workers multiplican la memoria, esconden la CPU de cada proceso, complican las métricas y pueden dejar uno colgado en un pod «sano». La CPU se escala con más pods.

6. 6En el pico de diseño de C01, ¿cuántas requests hay en vuelo? ¿Qué no debes hacer con el p99?Ver respuesta

   500 × 0.05 s = 25, ≈ 5 por pod. No multipliques la tasa por el p99: Little habla de promedios. El peor caso lo acota el timeout.