
Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Estás corriendo un modelo de 70B en una sola caja con GPU. Cincuenta contenedores aguas abajo de tu flota necesitan la misma respuesta para la misma consulta — están puntuando el mismo catálogo, generando los mismos embeddings, evaluando el mismo experimento. No pagues por cincuenta inferencias. Corre el modelo una vez, retransmite los tokens.
# generate once, pipe upwardllama.cpp -m llama3-70b.gguf \ -p "$PROMPT" --stream \ | curl -T - \ /pipe/llm?n=50pipe/llm?n=50UNA RUTA · CINCUENTA LECTORESel modelo corre una vez · el pipe retransmite · los workers lentos solo se ralentizan a sí mismos
La respuesta ingenua es un servidor HTTP con cola, batching de peticiones y contención de locks. La respuesta más barata para esta forma: cada consulta va a una ruta de pipe con ?n=50. El modelo corre una vez. Cincuenta contenedores consumidores hacen GET a la misma ruta y reciben los mismos tokens al mismo tiempo, abiertos en abanico por el pipe. Un worker lento aplica backpressure a su propia conexión — los demás siguen a velocidad de línea.
# 1× GPU box — run the model once and pipe its tokens upward.
llama.cpp -m llama3-70b.gguf -p "$PROMPT" --stream \
| curl -T - https://pipe.hoody.com/api/v1/pipe/llm?n=50
# 50 consumer containers — same path, ?n=50, fanned out by the pipe.
for i in $(seq 1 50); do
curl https://pipe.hoody.com/api/v1/pipe/llm?n=50 \
| jq -c .delta \
| ./score.py --worker $i &
done
# Sender blocks until 50 readers have connected, then bytes flow.
# Slow workers backpressure their own connection — others stay at line speed.PUT envía bytes hacia arriba. GET los baja. El parámetro ?n=50 dice a cuántos lectores esperar; el pipe mantiene la conexión hasta que conectan tantos, luego abre el stream en abanico simultáneamente a todos. Sin cola, sin capa de batching, sin servidor-de-inferencia-con-load-balancer.
cincuenta contenedores aguas abajo quieren la misma respuesta; tú la generas en la GPU una vez. El pipe se encarga de la entrega. Sin framework de batching de peticiones, sin capa de caché de tokens, sin coordinación de "por favor no lo vuelvas a ejecutar".
el pipe se bloquea hasta que cincuenta receptores conectan, luego transmite los bytes del productor a cada uno en paralelo. Copias idénticas, entrega a velocidad de línea, cero almacenamiento en servidor. Hasta 256 receptores por ruta.
si un contenedor consumidor está haciendo GC o su disco está ocupado, su conexión se retrasa. El pipe aplica backpressure a ese receptor — los otros 49 siguen transmitiendo a tope. Sin head-of-line blocking, sin tunear profundidad de cola.
Cuando cincuenta contenedores quieren la misma respuesta, las alternativas cobran por llamada, por token, o por servidor de inferencia. El pipe cobra por una transferencia HTTP. Corre el modelo en una caja que ya alquilas.
esto no es para cualquier carga — es para la forma en la que N contenedores quieren la misma respuesta. Cuando esa es tu forma, el pipe es el fan-out más barato que vas a cablear. Cargas con prompts divergentes siguen queriendo un servidor de inferencia de verdad; este patrón brilla cuando la pregunta es idéntica y la flota es ancha.
Una GPU, un pipe, cincuenta contenedores probando los mismos tokens.
Cada stack de "dale a mi flota acceso a un modelo" al que recurres cuando una consulta tiene que alimentar a muchos consumidores. Cada uno cobra por llamada, hospeda tus pesos, o te pide que corras un load balancer delante de vLLM. El pipe retransmite una vez.
Deja de pagar cincuenta facturas de inferencia por una respuesta. Corre el modelo donde ya alquilas el silicio. Abre un pipe. Deja que la flota lea.