Aller au contenu
use-cases / stream-llm-tokens-to-anything / hero
PIPE · AGENT · STREAMING

Streamez les tokens LLM vers tout ce qui parle HTTP

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.

Lire l'API pipe
use-cases / stream-llm-tokens-to-anything / mechanism

Deux curl, un chemin, pas de couche au milieu

La 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.

LA PILE HABITUELLE

Cinq couches entre générateur et lecteur

  • Abstraction de streaming LangChaincallback hell
  • Plomberie Server-Sent Eventsframing + heartbeats
  • Redis pub/subbroker à exploiter
  • Relais WebSocket customauth + reconnexion
  • Message broker (Kafka/RabbitMQ)topics + partitions
  • Callbacks de framework d'agentspécifiques au fournisseur
LE PIPE

Deux curl qui touchent le même chemin

PRODUCTEURcurl -T - /pipe/tokens
MÊME CHEMIN
CONSOMMATEURcurl /pipe/tokens

Stockage 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é.

agent-step-3.sh
# 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.

use-cases / stream-llm-tokens-to-anything / listeners

Même chemin, plusieurs lecteurs, pas de SDK

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.

POUR LE FRONTEND

Le navigateur lit la même URL

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.

POUR L'ÉVALUATEUR

Un second agent écoute et décide

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.

POUR LA PISTE DE LOGS

Tee le flux dans un conteneur qui surveille

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.

PLAFOND DE FAN-OUT256Plafond de récepteurs par chemin imposé par le pipe — réglez ?n pour attendre ce nombre avant que le transfert ne démarre.
SURCOÛT DE LATENCE0Les octets traversent le pipe au fur et à mesure. Pas de buffering côté serveur — le backpressure est géré par récepteur.
EMPREINTE SDK0 koProducteur et consommateur sont curl. Tout ce qui parle HTTP peut s'abonner — navigateur, conteneur, agent, shell.
use-cases / stream-llm-tokens-to-anything / punchline

Le LLM streame. Le pipe streame. Le lecteur streame. Pas de couche au milieu.

0101 · le modèle émet des tokens
0202 · le pipe transmet les octets
0303 · le lecteur les applique
pas de broker entre les étapesle chemin est le protocole
use-cases / stream-llm-tokens-to-anything / replaces

Ce que cela remplace

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.

  • Abstractions de streaming LangChainChaînes de callbacks, lock-in framework
  • Plomberie server-sent eventsFraming + heartbeats + logique de reconnexion
  • Redis pub/subBroker à installer, exploiter et payer
  • Relais WebSocket customAuth, reconnexion, backpressure tout en DIY
  • Message brokers (Kafka, RabbitMQ)Topics, partitions, consumer groups pour un seul flux
  • Callbacks de framework d'agentSpécifiques au fournisseur, lisibles uniquement depuis le même SDK
use-cases / stream-llm-tokens-to-anything / cta

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.

Lire l'API pipe
use-cases / stream-llm-tokens-to-anything / related

Découvrez les autres