一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
类型解锁
阶段生产环境
难度中等
工作分享流
用于AI 构建者
用于后端开发者
服务管道
服务智能体
为何选 HoodyHTTP 原生
为何选 HoodyAI 原生
类型解锁
阶段生产环境
难度中等
工作分享流
用于AI 构建者
用于后端开发者
服务管道
服务智能体
为何选 HoodyHTTP 原生
为何选 HoodyAI 原生
类型解锁
阶段生产环境
难度中等
工作分享流
用于AI 构建者
用于后端开发者
服务管道
服务智能体
为何选 HoodyHTTP 原生
为何选 HoodyAI 原生
类型解锁
阶段生产环境
难度中等
工作分享流
用于AI 构建者
用于后端开发者
服务管道
服务智能体
为何选 HoodyHTTP 原生
为何选 HoodyAI 原生
use-cases / stream-llm-tokens-to-anything / hero
PIPE · AGENT · STREAMING
把 LLM token 流到任何能读 HTTP 的东西
你 agent 的第 3 步在生成 token。第 4 步要在第 3 步还没结束前就开始消费。把模型输出直接管道送进一条路径；下一个进程 curl 同一条路径。无 SSE 管道、无中间件、无回调缠绕——字节以线速流动。
生产者 · 步骤 3消费者 · 步骤 4
agent.sh
步骤 3 · LLM
# stream tokens upwardai.generate([ stream: true]) | curl -T - \ /pipe/tokensTOKEN 流LIVE
theagentcalls{tool:searchquery:kafkavspipe}->streamtheagentcalls{tool:searchquery:kafkavspipe}->stream
OLDERNEWEST
无缓冲 · 无中间件 · 无重新编码
reader.sh
步骤 4 · 消费者
# read at line speedcurl \ /pipe/tokens \ | jq -c .delta | apply()# no buffer between ususe-cases / stream-llm-tokens-to-anything / mechanism
两条 curl，一条路径，无中间层
大多数流式栈要 SSE 端点、队列、pub/sub 总线和一段框架回调，才能把 token 挪四英尺。管道把这一切都替掉：生产者用 PUT 写到一条路径，消费者用 GET 从同一路径读。字节直接在两端之间流——服务端不存任何中间结果。
通常的栈
生成者和读取者之间五层
- LangChain 流式抽象回调地狱
- Server-Sent Events 管道分帧 + 心跳
- Redis pub/sub要运维的中间件
- 自定义 WebSocket 中继鉴权 + 重连
- 消息中间件(Kafka/RabbitMQ)topic + partition
- Agent 框架回调厂商绑定
管道
两条 curl 共用一条路径
PRODUCER
curl -T - /pipe/tokens同一路径
CONSUMER
curl /pipe/tokens服务端存储：零。两端一连，字节就从发送端流到接收端，反压按接收端处理。端点存在，只是因为有两条 curl 摸到了它。
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 把字节推上去，GET 把它们拉下来。?n 参数说要等几个读取者；管道阻塞到那么多人连上，然后同时扇出。无客户端 SDK、无中间件、无 SDK 安装——只有 HTTP。
use-cases / stream-llm-tokens-to-anything / listeners
同一路径，多个读取者，无 SDK
生产者一开始管道送字节，任何说 HTTP 的东西就能订阅。同一条流上最多 256 个读取者，管道扇出，反压按接收端处理。无客户端库要装，无中继要部署。
致前端开发者
浏览器读同一个 URL
EventSource 或 fetch 读取者命中 pipe 路径，就能拿到 agent 正在生成的同一字节流。你的服务器上不必做 SSE 分帧——管道运的就是模型发出的原始字节。
致评估者
第二个 agent 监听并决策
评估进程订阅同一路径。一旦输出跑偏，它可以在第一时间打断生产者。两个 agent 在同一根线上，无编排框架在中间撮合。
致日志追踪者
把流分支给一个监听容器
一个日志消费者读、压缩、写盘。一个调试 UI 并行地读。它们都不知道彼此存在——管道只是把同一字节交给每个读取者。
FAN-OUT CAP256管道强制的每路径接收端上限——用 ?n 让它等到那么多人连上再开始传输。
LATENCY OVERHEAD0字节随到随穿。服务器上无缓冲——反压按接收端处理。
SDK FOOTPRINT0 kb生产者和消费者都是 curl。任何说 HTTP 的东西都能订阅——浏览器、容器、agent、shell。
use-cases / stream-llm-tokens-to-anything / punchline
LLM 流式。管道流式。读取者流式。无中间层。
0101 · 模型发出 token
0202 · 管道转发字节
0303 · 读取者应用它们
步与步之间无中间件路径就是协议
use-cases / stream-llm-tokens-to-anything / replaces
它替代了什么
当一个进程要实时把 token 流给另一个时，你伸手会去找的那些东西。每一种都自带分帧、自带 SDK、自带运维表面。管道就是那根线。
- LangChain 流式抽象回调链、框架绑定
- Server-sent events 管道分帧 + 心跳 + 重连逻辑
- Redis pub/sub要装、要运维、要付费的中间件
- 自定义 WebSocket 中继鉴权、重连、反压都得自己写
- 消息中间件(Kafka、RabbitMQ)为一条流引入 topic、partition、消费组
- Agent 框架回调厂商绑定，只能在同一 SDK 里读
use-cases / stream-llm-tokens-to-anything / cta
别再为两个本来就说 HTTP 的进程之间架流式基础设施。开一条路径。管道送进去。读出来。
use-cases / stream-llm-tokens-to-anything / related