1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
コンテナ·スナップショット
タイプアンロックステージ本番環境難易度中程度ジョブストリームを共有対象AI ビルダー対象バックエンド開発者サービスパイプサービスエージェントHoody の利点HTTP ネイティブHoody の利点AI ネイティブ
タイプアンロックステージ本番環境難易度中程度ジョブストリームを共有対象AI ビルダー対象バックエンド開発者サービスパイプサービスエージェントHoody の利点HTTP ネイティブHoody の利点AI ネイティブ
use-cases / stream-llm-tokens-to-anything / hero
PIPE · エージェント · ストリーミング
HTTP を読むあらゆるものに LLM トークンをストリーミング
エージェントのステップ 3 がトークンを生成。ステップ 4 はステップ 3 が完了する前に消費を開始する必要がある。モデルの出力をパスに直接パイプ; 次のプロセスが同じパスを curl。SSE 配管なし、ブローカーなし、コールバック格闘なし — バイトはラインスピードで動く。
プロデューサー · ステップ 3コンシューマー · ステップ 4
agent.sh
ステップ 3 · LLM
# stream tokens upwardai.generate([ stream: true]) | curl -T - \ /pipe/tokensトークンストリームライブ
theagentcalls{tool:searchquery:kafkavspipe}->streamtheagentcalls{tool:searchquery:kafkavspipe}->stream
古い新しい
バッファなし · ブローカーなし · 再エンコードなし
reader.sh
ステップ 4 · コンシューマー
# read at line speedcurl \ /pipe/tokens \ | jq -c .delta | apply()# no buffer between ususe-cases / stream-llm-tokens-to-anything / mechanism
2 つの curl、1 つのパス、中間レイヤーなし
ほとんどのストリーミングスタックは、トークンを 4 フィート動かすために SSE エンドポイント、キュー、pub/sub バス、フレームワークコールバックを必要とする。パイプはそのすべてを置き換える: プロデューサーが PUT でパスに書き込み、コンシューマーが GET で同じパスから読む。バイトは 2 つの間を直接流れる — サーバー上の中間ストレージなし。
通常のスタック
ジェネレーターとリーダーの間に 5 つのレイヤー
- LangChain ストリーミング抽象化コールバック地獄
- Server-Sent Events 配管フレーミング + ハートビート
- Redis pub/sub運用するブローカー
- カスタム WebSocket リレー認証 + 再接続
- メッセージブローカー (Kafka/RabbitMQ)トピック + パーティション
- エージェントフレームワークのコールバックベンダー固有
パイプ
同じパスに触れる 2 つの curl
プロデューサー
curl -T - /pipe/tokens同じパス
コンシューマー
curl /pipe/tokensサーバーサイドストレージ: ゼロ。バイトは両者が接続した瞬間に送信側から受信側へストリーミング、バックプレッシャーは受信側ごとに処理。エンドポイントは 2 つの 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 リーダーがパイプパスにヒットし、エージェントが生成しているのと同じバイトストリームを取得。サーバーで SSE フレーミングなし — パイプはモデルが発行するバイトをそのまま運ぶ。
評価者向け
2 つ目のエージェントがリッスンして決定
評価者プロセスが同じパスにサブスクライブ。出力がドリフトした瞬間にプロデューサーを中断できる。同じワイヤー上の 2 つのエージェント、その間を仲介するオーケストレーターフレームワークなし。
ログトレイル向け
監視するコンテナにストリームを tee
ロギングコンシューマーが読み、gzip し、ディスクに書く。デバッガー UI が並列で読む。誰も他の存在を知らない — パイプはすべてのリーダーに同じバイトを渡すだけ。
ファンアウト上限256パイプによって強制されるパスごとの受信側上限 — 転送が始まる前にその数を待つには ?n を設定。
レイテンシオーバーヘッド0バイトは到着するとパイプを通過。サーバー上のバッファリングなし — バックプレッシャーは受信側ごとに処理。
SDK フットプリント0 kbプロデューサーとコンシューマーは curl。HTTP を話すあらゆるものがサブスクライブできる — ブラウザ、コンテナ、エージェント、シェル。
use-cases / stream-llm-tokens-to-anything / punchline
LLM がストリーム。パイプがストリーム。リーダーがストリーム。中間レイヤーなし。
0101 · モデルがトークンを発行
0202 · パイプがバイトを転送
0303 · リーダーがそれらを適用
ステップ間にブローカーなしパスがプロトコル
use-cases / stream-llm-tokens-to-anything / replaces
これが置き換えるもの
あるプロセスが別のプロセスにリアルタイムでトークンをストリーミングする必要があるときに手を伸ばす配線。それぞれが独自のフレーミング、独自の SDK、独自の運用面を持つ。パイプがワイヤーだ。
- LangChain ストリーミング抽象化コールバックチェーン、フレームワークロックイン
- Server-sent events 配管フレーミング + ハートビート + 再接続ロジック
- Redis pub/subインストール、運用、支払うブローカー
- カスタム WebSocket リレー認証、再接続、バックプレッシャー全部 DIY
- メッセージブローカー (Kafka, RabbitMQ)1 つのストリームのためのトピック、パーティション、コンシューマーグループ
- エージェントフレームワークのコールバックベンダー固有、同じ SDK からのみ読み取り可能
use-cases / stream-llm-tokens-to-anything / cta
すでに HTTP を話す 2 つのプロセス間でストリーミングインフラを配線するのを止めよう。パスを開く。そこにパイプ。そこから読む。
use-cases / stream-llm-tokens-to-anything / related
他のユースケースを読む
