Sessenta contêineres em um servidor
Uma caixa bare-metal executa dezenas a centenas de contêineres Hoody. KSM e BTRFS dedup fazem o custo marginal próximo a zero.
Contêineres·Snapshots
TipoDesbloqueadoEstágioProduçãoDificuldadeModeradoTrabalhoCompartilhar streamParaConstrutores de IAParaDesenvolvedores backendServiçosPipeServiçosAgentePor que HoodyHTTP-nativoPor que HoodyNativo de IA
TipoDesbloqueadoEstágioProduçãoDificuldadeModeradoTrabalhoCompartilhar streamParaConstrutores de IAParaDesenvolvedores backendServiçosPipeServiçosAgentePor que HoodyHTTP-nativoPor que HoodyNativo de IA
use-cases / stream-llm-tokens-to-anything / hero
PIPE · AGENTE · STREAMING
Faça streaming de tokens de LLM para qualquer coisa que leia HTTP
O passo 3 do seu agente gera tokens. O passo 4 precisa começar a consumir antes do 3 terminar. Mande a saída do modelo direto para um caminho; o próximo processo faz curl no mesmo caminho. Sem encanamento de SSE, sem broker, sem domesticar callbacks — os bytes correm na velocidade da linha.
PRODUTOR · PASSO 3CONSUMIDOR · PASSO 4
agent.sh
PASSO 3 · LLM
# stream tokens upwardai.generate([ stream: true]) | curl -T - \ /pipe/tokensSTREAM DE TOKENSAO VIVO
theagentcalls{tool:searchquery:kafkavspipe}->streamtheagentcalls{tool:searchquery:kafkavspipe}->stream
MAIS ANTIGOMAIS NOVO
sem buffer · sem broker · sem re-encode
reader.sh
PASSO 4 · CONSUMIDOR
# read at line speedcurl \ /pipe/tokens \ | jq -c .delta | apply()# no buffer between ususe-cases / stream-llm-tokens-to-anything / mechanism
Dois curls, um caminho, sem camada do meio
A maioria das stacks de streaming precisa de um endpoint SSE, uma fila, um barramento pub/sub e um callback de framework para mover tokens um metro. O pipe substitui tudo: o produtor escreve em um caminho com PUT, o consumidor lê do mesmo caminho com GET. Os bytes fluem direto entre os dois — sem armazenamento intermediário no servidor.
A STACK USUAL
Cinco camadas entre gerador e leitor
- Abstração de streaming do LangChaininferno de callbacks
- Encanamento de Server-Sent Eventsframing + heartbeats
- Redis pub/subbroker para operar
- Relay WebSocket customizadoauth + reconectar
- Message broker (Kafka/RabbitMQ)tópicos + partições
- Callbacks de framework de agenteespecíficos do fornecedor
O PIPE
Dois curls tocando o mesmo caminho
PRODUTOR
curl -T - /pipe/tokensMESMO CAMINHO
CONSUMIDOR
curl /pipe/tokensStorage do lado do servidor: zero. Os bytes fazem streaming do remetente para o receptor assim que os dois conectam, com backpressure por receptor. O endpoint existe só porque dois curls tocaram nele.
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 empurra os bytes para cima, GET puxa para baixo. O parâmetro ?n diz quantos leitores esperar; o pipe bloqueia até esse número conectar e aí faz fan-out simultâneo. Sem SDK de cliente, sem broker, sem instalação de SDK — só HTTP.
use-cases / stream-llm-tokens-to-anything / listeners
Mesmo caminho, vários leitores, sem SDK
Quando o produtor está enviando, qualquer coisa que fale HTTP pode assinar. Até 256 leitores no mesmo stream, distribuídos pelo pipe com backpressure por receptor. Sem biblioteca de cliente para instalar, sem relay para provisionar.
PARA O FRONTEND
O navegador lê a mesma URL
Um EventSource ou um leitor fetch bate no caminho do pipe e recebe o mesmo stream de bytes que o agente está produzindo. Sem framing SSE no seu servidor — o pipe carrega os bytes que o modelo emite, crus.
PARA O AVALIADOR
Um segundo agente escuta e decide
Um processo avaliador assina o mesmo caminho. Pode interromper o produtor no momento em que a saída desviar. Dois agentes no mesmo fio, sem framework orquestrador entre eles.
PARA O TRILHO DE LOG
Tee o stream para um contêiner que observa
Um consumidor de logging lê, faz gzip e escreve em disco. Uma UI de debugger lê em paralelo. Nenhum sabe que os outros existem — o pipe entrega os mesmos bytes para cada leitor.
LIMITE DE FAN-OUT256Teto de receptores por caminho garantido pelo pipe — defina ?n para esperar essa quantidade antes da transferência começar.
OVERHEAD DE LATÊNCIA0Os bytes atravessam o pipe conforme chegam. Sem buffer no servidor — backpressure é por receptor.
TAMANHO DE SDK0 kbProdutor e consumidor são curl. Qualquer coisa que fale HTTP pode assinar — navegador, contêiner, agente, shell.
use-cases / stream-llm-tokens-to-anything / punchline
O LLM faz streaming. O pipe faz streaming. O leitor faz streaming. Sem camada do meio.
0101 · o modelo emite tokens
0202 · o pipe encaminha bytes
0303 · o leitor aplica
sem broker entre os passoso caminho é o protocolo
use-cases / stream-llm-tokens-to-anything / replaces
O que isto substitui
A fiação que você procura quando um processo precisa enviar tokens em tempo real para outro. Cada um traz seu framing, seu SDK, sua superfície de operação. O pipe é o fio.
- Abstrações de streaming do LangChainCadeias de callback, lock-in de framework
- Encanamento de server-sent eventsFraming + heartbeats + lógica de reconexão
- Redis pub/subBroker para instalar, operar e pagar
- Relays WebSocket customizadosAuth, reconectar, backpressure tudo no DIY
- Message brokers (Kafka, RabbitMQ)Tópicos, partições, consumer groups para um stream
- Callbacks de framework de agenteEspecíficos do fornecedor, só legíveis a partir do mesmo SDK
use-cases / stream-llm-tokens-to-anything / cta
Pare de cabear infraestrutura de streaming entre dois processos que já falam HTTP. Abra um caminho. Mande para ele. Leia dele.
use-cases / stream-llm-tokens-to-anything / related
Leia os outros
