
一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
你在一台 GPU 机器上跑 70B 模型。舰队下游五十个容器对同一个查询要同一个答案——它们在给同一份目录打分、生成同一份 embedding、评估同一个实验。别为五十次推理付费。把模型跑一次,把 token 广播出去。
# generate once, pipe upwardllama.cpp -m llama3-70b.gguf \ -p "$PROMPT" --stream \ | curl -T - \ /pipe/llm?n=50pipe/llm?n=50ONE PATH · FIFTY READERS模型只跑一次 · 管道广播 · 慢的 worker 只拖慢自己
朴素的答案是一个带队列、请求批处理和锁竞争的 HTTP 服务。对这个形态更便宜的答案:每个查询都进入一个带 ?n=50 的管道路径。模型只跑一次。五十个消费容器 GET 同一路径,被管道扇出,在同一时间流出同样的 token。慢的 worker 在自己那条连接上反压——其他几个保持线速。
# 1× GPU box — run the model once and pipe its tokens upward.
llama.cpp -m llama3-70b.gguf -p "$PROMPT" --stream \
| curl -T - https://pipe.hoody.com/api/v1/pipe/llm?n=50
# 50 consumer containers — same path, ?n=50, fanned out by the pipe.
for i in $(seq 1 50); do
curl https://pipe.hoody.com/api/v1/pipe/llm?n=50 \
| jq -c .delta \
| ./score.py --worker $i &
done
# Sender blocks until 50 readers have connected, then bytes flow.
# Slow workers backpressure their own connection — others stay at line speed.PUT 把字节往上推。GET 把它们往下拉。?n=50 参数说明要等多少个读取者;管道把连接守住直到那么多人连上,再把流同时扇向所有人。无队列,无批处理层,无「推理服务器加负载均衡器」。
五十个下游容器要同一个答案;你在 GPU 上把它生成一次。投递交给管道。无请求批处理框架,无 token 缓存层,无「请别再跑一次」的协调。
管道阻塞到五十个接收者连上之后,把生产者的字节并行流给每一个。等同副本,线速投递,服务器零存储。每条路径最多 256 个接收者。
如果某个消费容器在 GC 或者磁盘忙,它的连接就滞后。管道对这个接收者反压——其他 49 个保持全速。无队头阻塞,无队列深度调优。
当五十个容器要同一个答案时,替代方案按调用、按 token 或按推理服务器收费。管道只收一次 HTTP 传输的费。在你已经租下的机器上跑模型。
这不是每一种工作负载——它是「N 个容器要同一个答案」的形态。当那是你的形态时,管道是你能接起来最便宜的扇出。提示发散的工作负载还是要一个真正的推理服务器;这个模式在问题相同、舰队宽广时最闪亮。
一块 GPU,一条管道,五十个容器尝同样的 token。
当一个查询要喂给众多消费者时,你会去找的「让我的舰队访问模型」整套堆栈。每一种都按调用收费、托管你的权重,或者要求你在 vLLM 前面跑一个负载均衡器。管道广播一次。
别再为一个答案付五十张推理账单。在你已经租下硅片的地方跑模型。打开一条管道。让舰队来读。