Soixante conteneurs sur un seul serveur
Une machine bare-metal exécute des dizaines à des centaines de conteneurs Hoody. La dédupplication KSM et BTRFS rend le coût marginal quasi nul.
Containers·Snapshots
TypeDéverrouilléÉtapeParcDifficultéAvancéTravailDéployer une APIPourConstructeurs d'IAPourÉquipes de devServicesPipeServicesDaemonPourquoi HoodyHTTP-natifPourquoi HoodyÉconomie des conteneursPourquoi HoodyNatif IA
TypeDéverrouilléÉtapeParcDifficultéAvancéTravailDéployer une APIPourConstructeurs d'IAPourÉquipes de devServicesPipeServicesDaemonPourquoi HoodyHTTP-natifPourquoi HoodyÉconomie des conteneursPourquoi HoodyNatif IA
use-cases / run-a-local-llm-serve-it-to-your-fleet / hero
PIPE · LLM LOCAL · FAN-OUT
Faites tourner un LLM local, servez-le à toute votre flotte
Vous faites tourner un modèle 70B sur une seule machine GPU. Cinquante conteneurs en aval dans votre flotte ont besoin de la même réponse pour la même requête — ils notent le même catalogue, génèrent les mêmes embeddings, évaluent la même expérience. Ne payez pas cinquante inférences. Faites tourner le modèle une fois, diffusez les tokens.
gpu-01.fleet.local · llama.cpp
EN COURSRTX 409024 Go VRAMllama3-70b · q41× SOURCE
ÉTAPE 1 · MODÈLE
# generate once, pipe upwardllama.cpp -m llama3-70b.gguf \ -p "$PROMPT" --stream \ | curl -T - \ /pipe/llm?n=50ÉTAPE 2 · PIPE
pipe/llm?n=50UN CHEMIN · CINQUANTE LECTEURSflotte · 50 conteneurs consommateurs
n=50app-1
app-2
app-3
app-4
app-5
app-6
app-7
app-8
app-9
app-10
app-11
app-12
app-13
app-14
app-15
app-16
app-17
app-18
app-19
app-20
app-21
app-22
app-23
app-24
app-25
app-26
app-27
app-28
app-29
app-30
app-31
app-32
app-33
app-34
app-35
app-36
app-37
app-38
app-39
app-40
app-41
app-42
app-43
app-44
app-45
app-46
app-47
app-48
app-49
app-50
TOUS GOÛTANT LES MÊMES TOKENSBACKPRESSURE PAR CONNEXION
le modèle tourne une fois · le pipe diffuse · les workers lents ne ralentissent qu'eux-mêmes
use-cases / run-a-local-llm-serve-it-to-your-fleet / mechanism
Un GPU, un pipe, cinquante consommateurs
La réponse naïve, c'est un serveur HTTP avec une file d'attente, du batching de requêtes et de la contention de verrous. La réponse moins chère pour cette forme : chaque requête atterrit sur un chemin de pipe avec ?n=50. Le modèle tourne une fois. Cinquante conteneurs consommateurs font GET sur le même chemin et diffusent les mêmes tokens en même temps, distribués par le pipe. Un worker lent applique de la backpressure à sa propre connexion — les autres restent à pleine vitesse.
fleet-broadcast.sh
# 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 envoie les octets vers le haut. GET les tire vers le bas. Le paramètre ?n=50 indique combien de lecteurs attendre ; le pipe garde la connexion jusqu'à ce que ce nombre soit atteint, puis distribue le flux simultanément à tous. Pas de file d'attente, pas de couche de batching, pas de serveur-d'inférence-derrière-load-balancer.
UNE INFÉRENCE
Le modèle tourne exactement une fois par requête
cinquante conteneurs en aval veulent la même réponse ; vous la générez sur le GPU une seule fois. Le pipe gère la distribution. Pas de framework de batching de requêtes, pas de couche de cache de tokens, pas de coordination « surtout ne le relancez pas ».
FAN-OUT DU PIPE
?n=50 distribue les mêmes octets à cinquante lecteurs
le pipe se bloque jusqu'à ce que cinquante destinataires se connectent, puis diffuse les octets du producteur à chacun en parallèle. Copies identiques, livraison à pleine vitesse, zéro stockage côté serveur. Jusqu'à 256 destinataires par chemin.
BACKPRESSURE PAR DESTINATAIRE
Les workers lents ne ralentissent qu'eux-mêmes
si un conteneur consommateur fait du GC ou si son disque est occupé, sa connexion prend du retard. Le pipe applique de la backpressure à ce destinataire — les 49 autres continuent à pleine vitesse. Pas de blocage en tête de file, pas de réglage de profondeur de file.
PLAFOND DE FAN-OUT256Plafond de destinataires par chemin imposé par le pipe — réglez ?n pour attendre ce nombre avant que le transfert démarre.
INFÉRENCES PAR REQUÊTE1Le modèle tourne une fois par requête, pas une fois par consommateur. Le coût de calcul est découplé de la taille de la flotte.
EMPREINTE SDK0 koLe producteur, c'est curl. Les consommateurs, c'est curl. Tout ce qui parle HTTP peut s'abonner — conteneur, agent, navigateur, shell.
use-cases / run-a-local-llm-serve-it-to-your-fleet / economics
Ce que vous arrêtez de payer
Quand cinquante conteneurs veulent la même réponse, les alternatives facturent par appel, par token, ou par serveur d'inférence. Le pipe facture un seul transfert HTTP. Faites tourner le modèle sur une machine que vous louez déjà.
AVANTAPI hébergée · facturation au token50× tokensBedrock ou OpenAI vous facturent pour cinquante complétions identiques quand cinquante conteneurs posent la même question. Même prompt, même réponse, facturé cinquante fois.
APRÈSModèle local · diffusion par pipe1× tokensLa machine GPU que vous louez déjà génère une fois. Le pipe transporte les octets jusqu'aux cinquante. La flotte passe à l'échelle horizontalement sans faire grimper la facture d'inférence.
ce n'est pas tous les workloads — c'est la forme où N conteneurs veulent la même réponse. Quand c'est votre forme, le pipe est le fan-out le moins cher que vous câblerez. Les workloads à prompts divergents veulent toujours un vrai serveur d'inférence ; ce schéma brille quand la question est identique et la flotte est large.
use-cases / run-a-local-llm-serve-it-to-your-fleet / punchline
Un GPU, un pipe, cinquante conteneurs goûtant les mêmes tokens.
0101 · UN GPU GÉNÈRE LES TOKENS
0202 · UN PIPE LES TRANSPORTE
0303 · CINQUANTE CONTENEURS LES GOÛTENT EN MÊME TEMPS
pas de service de fan-out d'inférencele chemin est la diffusion
use-cases / run-a-local-llm-serve-it-to-your-fleet / replaces
Ce que cela remplace
Toutes les stacks « donne accès à un modèle à ma flotte » que vous attrapez quand une requête doit alimenter plusieurs consommateurs. Chacune facture par appel, héberge vos poids, ou vous demande de faire tourner un load balancer devant vLLM. Le pipe diffuse une fois.
- AWS Lambda + BedrockFacturation au token × taille de la flotte, poids qui ne vous appartiennent pas
- Modal LabsRunners GPU hébergés, facturation à la seconde par worker
- ReplicateTarification à l'appel, aller-retour réseau par consommateur
- API OpenAI à grande échellePrompt identique facturé une fois par consommateur
- vLLM/TGI derrière un load balancerServeur, file d'attente, réglage du batching, surface ops à maintenir
- Passerelles de modèles auto-hébergéesRoutage, auth, rate limits — tout fait maison pour un fan-out
use-cases / run-a-local-llm-serve-it-to-your-fleet / cta
Arrêtez de payer cinquante factures d'inférence pour une seule réponse. Faites tourner le modèle là où vous louez déjà le silicium. Ouvrez un pipe. Laissez la flotte lire.
use-cases / run-a-local-llm-serve-it-to-your-fleet / related
Découvrez les autres
