
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.
L'étape 3 de votre agent génère des tokens. L'étape 4 doit commencer à les consommer avant que l'étape 3 ne soit terminée. Envoyez la sortie du modèle directement dans un chemin ; le processus suivant fait curl sur le même chemin. Pas de plomberie SSE, pas de broker, pas de jongleries de callbacks — les octets circulent à pleine vitesse.
# stream tokens upwardai.generate([ stream: true]) | curl -T - \ /pipe/tokenspas de buffer · pas de broker · pas de ré-encodage
# read at line speedcurl \ /pipe/tokens \ | jq -c .delta | apply()# no buffer between usLa plupart des piles de streaming ont besoin d'un endpoint SSE, d'une file d'attente, d'un bus pub/sub et d'un callback de framework pour déplacer des tokens d'un mètre. Le pipe remplace tout cela : le producteur écrit dans un chemin avec PUT, le consommateur lit depuis le même chemin avec GET. Les octets circulent directement entre les deux — pas de stockage intermédiaire côté serveur.
curl -T - /pipe/tokenscurl /pipe/tokensStockage côté serveur : zéro. Les octets circulent de l'émetteur au récepteur dès que les deux sont connectés, avec un backpressure géré par récepteur. L'endpoint n'existe que parce que deux curl l'ont touché.
# Step 3 — agent generates and pipes tokens upward.
ai.generate({ model, stream: true }) \
| jq -c '{delta: .text}' \
| curl -T - https://pipe.hoody.com/api/v1/pipe/run-42/tokens?n=3
# Step 4 — three readers GET the same path. The pipe fans out.
curl https://pipe.hoody.com/api/v1/pipe/run-42/tokens?n=3 | tee evaluator.log
curl https://pipe.hoody.com/api/v1/pipe/run-42/tokens?n=3 | jq -c .delta
curl https://pipe.hoody.com/api/v1/pipe/run-42/tokens?n=3 | websocketd --port=8080
# All four processes block until the n=3 readers connect, then bytes flow.PUT pousse les octets vers le haut, GET les tire vers le bas. Le paramètre ?n indique combien de lecteurs attendre ; le pipe bloque jusqu'à ce que ce nombre se connecte, puis fait du fan-out simultanément. Pas de SDK client, pas de broker, pas d'installation de SDK — uniquement HTTP.
Une fois que le producteur envoie, tout ce qui parle HTTP peut s'abonner. Jusqu'à 256 lecteurs sur le même flux, distribués par le pipe avec un backpressure géré par récepteur. Pas de bibliothèque cliente à installer, pas de relais à provisionner.
Un EventSource ou un lecteur fetch atteint le chemin pipe et obtient le même flux d'octets que l'agent produit. Pas de framing SSE sur votre serveur — le pipe transporte les octets que le modèle émet, bruts.
Un processus évaluateur s'abonne au même chemin. Il peut interrompre le producteur dès que la sortie dérive. Deux agents sur le même fil, sans framework d'orchestration entre eux.
Un consommateur de logs lit, gzippe et écrit sur disque. Une UI de débogage lit en parallèle. Aucun ne sait que les autres existent — le pipe donne simplement les mêmes octets à chaque lecteur.
Le LLM streame. Le pipe streame. Le lecteur streame. Pas de couche au milieu.
Le câblage que vous sortez quand un processus doit streamer des tokens vers un autre en temps réel. Chacun apporte son propre framing, son propre SDK, sa propre surface d'ops. Le pipe est le fil.
Arrêtez de câbler de l'infrastructure de streaming entre deux processus qui parlent déjà HTTP. Ouvrez un chemin. Envoyez dedans. Lisez dehors.