一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
类型解锁
阶段船队
难度高级
工作部署 API
用于AI 构建者
用于开发团队
服务管道
服务守护进程
为何选 HoodyHTTP 原生
为何选 Hoody容器经济学
为何选 HoodyAI 原生
类型解锁
阶段船队
难度高级
工作部署 API
用于AI 构建者
用于开发团队
服务管道
服务守护进程
为何选 HoodyHTTP 原生
为何选 Hoody容器经济学
为何选 HoodyAI 原生
类型解锁
阶段船队
难度高级
工作部署 API
用于AI 构建者
用于开发团队
服务管道
服务守护进程
为何选 HoodyHTTP 原生
为何选 Hoody容器经济学
为何选 HoodyAI 原生
类型解锁
阶段船队
难度高级
工作部署 API
用于AI 构建者
用于开发团队
服务管道
服务守护进程
为何选 HoodyHTTP 原生
为何选 Hoody容器经济学
为何选 HoodyAI 原生
use-cases / run-a-local-llm-serve-it-to-your-fleet / hero
PIPE · 本地 LLM · 扇出
本地跑一个 LLM，服务给你的整支舰队
你在一台 GPU 机器上跑 70B 模型。舰队下游五十个容器对同一个查询要同一个答案——它们在给同一份目录打分、生成同一份 embedding、评估同一个实验。别为五十次推理付费。把模型跑一次，把 token 广播出去。
gpu-01.fleet.local · llama.cpp
RUNNINGRTX 409024 GB VRAMllama3-70b · q41× 源
步骤 1 · 模型
# generate once, pipe upwardllama.cpp -m llama3-70b.gguf \ -p "$PROMPT" --stream \ | curl -T - \ /pipe/llm?n=50步骤 2 · PIPE
pipe/llm?n=50一条路径 · 五十个读取端舰队 · 50 个消费容器
n=50app-1
app-2
app-3
app-4
app-5
app-6
app-7
app-8
app-9
app-10
app-11
app-12
app-13
app-14
app-15
app-16
app-17
app-18
app-19
app-20
app-21
app-22
app-23
app-24
app-25
app-26
app-27
app-28
app-29
app-30
app-31
app-32
app-33
app-34
app-35
app-36
app-37
app-38
app-39
app-40
app-41
app-42
app-43
app-44
app-45
app-46
app-47
app-48
app-49
app-50
全部尝同样的 token每条连接独立反压
模型只跑一次 · 管道广播 · 慢的 worker 只拖慢自己
use-cases / run-a-local-llm-serve-it-to-your-fleet / mechanism
一块 GPU，一条管道，五十个消费者
朴素的答案是一个带队列、请求批处理和锁竞争的 HTTP 服务。对这个形态更便宜的答案：每个查询都进入一个带 ?n=50 的管道路径。模型只跑一次。五十个消费容器 GET 同一路径，被管道扇出，在同一时间流出同样的 token。慢的 worker 在自己那条连接上反压——其他几个保持线速。
fleet-broadcast.sh
# 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 参数说明要等多少个读取者；管道把连接守住直到那么多人连上，再把流同时扇向所有人。无队列，无批处理层，无「推理服务器加负载均衡器」。
ONE INFERENCE
每个查询模型恰好跑一次
五十个下游容器要同一个答案；你在 GPU 上把它生成一次。投递交给管道。无请求批处理框架，无 token 缓存层，无「请别再跑一次」的协调。
PIPE FAN-OUT
?n=50 把同样的字节扇向五十个读取者
管道阻塞到五十个接收者连上之后，把生产者的字节并行流给每一个。等同副本，线速投递，服务器零存储。每条路径最多 256 个接收者。
PER-RECEIVER BACKPRESSURE
慢 worker 只拖慢自己
如果某个消费容器在 GC 或者磁盘忙，它的连接就滞后。管道对这个接收者反压——其他 49 个保持全速。无队头阻塞，无队列深度调优。
FAN-OUT CAP256每条路径接收者上限由管道执行——把 ?n 设到要等的人数，传输才会开始。
INFERENCES PER QUERY1模型每个查询跑一次，不是每个消费者跑一次。算力成本和舰队规模解耦。
SDK FOOTPRINT0 kb生产者是 curl。消费者是 curl。任何说 HTTP 的东西都能订阅——容器、智能体、浏览器、shell。
use-cases / run-a-local-llm-serve-it-to-your-fleet / economics
你不再为之付费的东西
当五十个容器要同一个答案时，替代方案按调用、按 token 或按推理服务器收费。管道只收一次 HTTP 传输的费。在你已经租下的机器上跑模型。
BEFORE托管 API · 按 token 计费50× tokens当五十个容器问同一个问题，Bedrock 或 OpenAI 会按五十次等同补全收费。同样的 prompt、同样的答案，被收五十次。
AFTER本地模型 · 管道广播1× tokens你已经租下的 GPU 机器生成一次。管道把字节带给所有五十个。舰队横向扩展，不必扩展推理账单。
这不是每一种工作负载——它是「N 个容器要同一个答案」的形态。当那是你的形态时，管道是你能接起来最便宜的扇出。提示发散的工作负载还是要一个真正的推理服务器；这个模式在问题相同、舰队宽广时最闪亮。
use-cases / run-a-local-llm-serve-it-to-your-fleet / punchline
一块 GPU，一条管道，五十个容器尝同样的 token。
0101 · 一块 GPU 生成 token
0202 · 一条管道把它们带过去
0303 · 五十个容器同时尝到
无推理扇出服务路径就是广播
use-cases / run-a-local-llm-serve-it-to-your-fleet / replaces
它替代了什么
当一个查询要喂给众多消费者时，你会去找的「让我的舰队访问模型」整套堆栈。每一种都按调用收费、托管你的权重，或者要求你在 vLLM 前面跑一个负载均衡器。管道广播一次。
- AWS Lambda + Bedrock按 token 计费 × 舰队规模，权重不归你
- Modal Labs托管 GPU runner，按秒按 worker 计费
- Replicate按调用定价，每个消费者一次网络往返
- 规模化运行 OpenAI API等同的 prompt 每个消费者收一次
- vLLM/TGI 后挂负载均衡器服务器、队列、批处理调优、运维面要保活
- 自建模型网关路由、鉴权、限流——为了一次扇出全部 DIY
use-cases / run-a-local-llm-serve-it-to-your-fleet / cta
别再为一个答案付五十张推理账单。在你已经租下硅片的地方跑模型。打开一条管道。让舰队来读。
use-cases / run-a-local-llm-serve-it-to-your-fleet / related