Sechzig Container auf einem Server
Eine Bare-Metal-Box führt Dutzende bis Hunderte von Hoody-Containern aus. KSM und BTRFS-Dedup machen die Marginalkosten nahezu null.
Containers·Snapshots
TypFreigeschaltetPhaseProduktionSchwierigkeitMittelAufgabeStream teilenFürKI-BuilderFürBackend-DevsServicesPipeServicesAgentWarum HoodyHTTP-nativWarum HoodyKI-nativ
TypFreigeschaltetPhaseProduktionSchwierigkeitMittelAufgabeStream teilenFürKI-BuilderFürBackend-DevsServicesPipeServicesAgentWarum HoodyHTTP-nativWarum HoodyKI-nativ
use-cases / stream-llm-tokens-to-anything / hero
PIPE · AGENT · STREAMING
LLM-Tokens an alles streamen, was HTTP liest
Schritt 3 deines Agents generiert Tokens. Schritt 4 muss anfangen sie zu konsumieren, bevor Schritt 3 fertig ist. Pipe den Output des Modells direkt in einen Pfad; der nächste Prozess curlet denselben Pfad. Keine SSE-Plumbing, kein Broker, kein Callback-Gewürge — Bytes bewegen sich in Lichtgeschwindigkeit.
PRODUCER · STEP 3CONSUMER · STEP 4
agent.sh
STEP 3 · LLM
# stream tokens upwardai.generate([ stream: true]) | curl -T - \ /pipe/tokensTOKEN STREAMLIVE
theagentcalls{tool:searchquery:kafkavspipe}->streamtheagentcalls{tool:searchquery:kafkavspipe}->stream
ÄLTERNEUSTE
kein Buffer · kein Broker · kein Re-Encode
reader.sh
STEP 4 · CONSUMER
# read at line speedcurl \ /pipe/tokens \ | jq -c .delta | apply()# no buffer between ususe-cases / stream-llm-tokens-to-anything / mechanism
Zwei curls, ein Pfad, keine Schicht dazwischen
Die meisten Streaming-Stacks brauchen einen SSE-Endpoint, eine Queue, einen Pub/Sub-Bus und einen Framework-Callback, um Tokens einen Meter weit zu bewegen. Die Pipe ersetzt all das: der Producer schreibt mit PUT auf einen Pfad, der Consumer liest mit GET vom selben Pfad. Bytes fließen direkt zwischen beiden — kein Zwischenspeicher auf dem Server.
DER ÜBLICHE STACK
Fünf Schichten zwischen Generator und Leser
- LangChain Streaming-AbstraktionCallback-Hölle
- Server-Sent Events PlumbingFraming + Heartbeats
- Redis Pub/SubBroker zu betreiben
- Custom WebSocket RelayAuth + Reconnect
- Message Broker (Kafka/RabbitMQ)Topics + Partitions
- Agent-Framework CallbacksVendor-spezifisch
DIE PIPE
Zwei curls auf demselben Pfad
PRODUCER
curl -T - /pipe/tokensGLEICHER PFAD
CONSUMER
curl /pipe/tokensServer-seitiger Storage: null. Bytes streamen vom Sender zum Empfänger, sobald beide verbinden, mit Backpressure pro Empfänger. Der Endpoint existiert nur, weil zwei curls ihn berührt haben.
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 pusht die Bytes hoch, GET zieht sie runter. Der ?n-Parameter sagt, auf wie viele Leser zu warten ist; die Pipe blockiert, bis so viele verbinden, dann fan-outet sie gleichzeitig. Kein Client-SDK, kein Broker, keine SDK-Installation — nur HTTP.
use-cases / stream-llm-tokens-to-anything / listeners
Gleicher Pfad, viele Leser, kein SDK
Sobald der Producer pipet, kann alles, was HTTP spricht, abonnieren. Bis zu 256 Leser auf demselben Stream, von der Pipe fan-outet, mit Backpressure pro Empfänger. Keine Client-Library zu installieren, kein Relay zu provisionieren.
FÜR DAS FRONTEND
Der Browser liest dieselbe URL
Ein EventSource- oder fetch-Reader trifft den Pipe-Pfad und bekommt denselben Byte-Stream, den der Agent produziert. Kein SSE-Framing auf deinem Server — die Pipe trägt die Bytes, die das Modell emittiert, roh.
FÜR DEN EVALUATOR
Ein zweiter Agent hört zu und entscheidet
Ein Evaluator-Prozess abonniert denselben Pfad. Er kann den Producer in dem Moment unterbrechen, in dem der Output abdriftet. Zwei Agents auf derselben Leitung, kein Orchestrator-Framework, das dazwischen vermittelt.
FÜR DEN LOG-TRAIL
Den Stream in einen beobachtenden Container teen
Ein Logging-Consumer liest, gzipt und schreibt auf Disk. Eine Debugger-UI liest parallel. Keiner weiß von den anderen — die Pipe gibt jedem Leser einfach dieselben Bytes.
FAN-OUT-LIMIT256Pro-Pfad-Empfänger-Obergrenze, von der Pipe erzwungen — setze ?n, um auf so viele zu warten, bevor der Transfer startet.
LATENZ-OVERHEAD0Bytes durchqueren die Pipe, sobald sie ankommen. Kein Buffering auf dem Server — Backpressure läuft pro Empfänger.
SDK-FOOTPRINT0 kbProducer und Consumer sind curl. Alles, was HTTP spricht, kann abonnieren — Browser, Container, Agent, Shell.
use-cases / stream-llm-tokens-to-anything / punchline
Das LLM streamt. Die Pipe streamt. Der Leser streamt. Keine Schicht dazwischen.
0101 · das Modell emittiert Tokens
0202 · die Pipe leitet Bytes weiter
0303 · der Leser wendet sie an
kein Broker zwischen Schrittender Pfad ist das Protokoll
use-cases / stream-llm-tokens-to-anything / replaces
Was das ersetzt
Die Verdrahtung, zu der du greifst, wenn ein Prozess Tokens in Echtzeit an einen anderen streamen muss. Jede davon bringt ihr eigenes Framing, ihr eigenes SDK, ihre eigene Ops-Oberfläche mit. Die Pipe ist der Draht.
- LangChain Streaming-AbstraktionenCallback-Ketten, Framework-Lock-in
- Server-Sent-Events-PlumbingFraming + Heartbeats + Reconnect-Logik
- Redis Pub/SubBroker zum Installieren, Betreiben und Bezahlen
- Custom WebSocket-RelaysAuth, Reconnect, Backpressure alles selbst
- Message Broker (Kafka, RabbitMQ)Topics, Partitions, Consumer Groups für einen Stream
- Agent-Framework CallbacksVendor-spezifisch, nur aus demselben SDK lesbar
use-cases / stream-llm-tokens-to-anything / cta
Hör auf, Streaming-Infrastruktur zwischen zwei Prozesse zu verdrahten, die schon HTTP sprechen. Öffne einen Pfad. Pipe rein. Lies raus.
use-cases / stream-llm-tokens-to-anything / related
Lies die anderen
