コンテンツにスキップ
タイプアンロック
ステージ本番環境
難易度中程度
ジョブストリームを共有
対象AI ビルダー
対象バックエンド開発者
サービスパイプ
サービスエージェント
Hoody の利点HTTP ネイティブ
Hoody の利点AI ネイティブ
タイプアンロック
ステージ本番環境
難易度中程度
ジョブストリームを共有
対象AI ビルダー
対象バックエンド開発者
サービスパイプ
サービスエージェント
Hoody の利点HTTP ネイティブ
Hoody の利点AI ネイティブ
タイプアンロック
ステージ本番環境
難易度中程度
ジョブストリームを共有
対象AI ビルダー
対象バックエンド開発者
サービスパイプ
サービスエージェント
Hoody の利点HTTP ネイティブ
Hoody の利点AI ネイティブ
タイプアンロック
ステージ本番環境
難易度中程度
ジョブストリームを共有
対象AI ビルダー
対象バックエンド開発者
サービスパイプ
サービスエージェント
Hoody の利点HTTP ネイティブ
Hoody の利点AI ネイティブ
PIPE · エージェント · ストリーミング

HTTP を読むあらゆるものに LLM トークンをストリーミング

エージェントのステップ 3 がトークンを生成。ステップ 4 はステップ 3 が完了する前に消費を開始する必要がある。モデルの出力をパスに直接パイプ; 次のプロセスが同じパスを curl。SSE 配管なし、ブローカーなし、コールバック格闘なし — バイトはラインスピードで動く。

パイプ API を読む

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 のみ。

同じパス、多くのリーダー、SDK なし

プロデューサーがパイプし始めると、HTTP を話すあらゆるものがサブスクライブできる。同じストリームに最大 256 リーダー、パイプによってファンアウトされ、バックプレッシャーは受信側ごとに処理。インストールするクライアントライブラリなし、プロビジョニングするリレーなし。

フロントエンド向け

ブラウザが同じ URL を読む

EventSource または fetch リーダーがパイプパスにヒットし、エージェントが生成しているのと同じバイトストリームを取得。サーバーで SSE フレーミングなし — パイプはモデルが発行するバイトをそのまま運ぶ。

評価者向け

2 つ目のエージェントがリッスンして決定

評価者プロセスが同じパスにサブスクライブ。出力がドリフトした瞬間にプロデューサーを中断できる。同じワイヤー上の 2 つのエージェント、その間を仲介するオーケストレーターフレームワークなし。

ログトレイル向け

監視するコンテナにストリームを tee

ロギングコンシューマーが読み、gzip し、ディスクに書く。デバッガー UI が並列で読む。誰も他の存在を知らない — パイプはすべてのリーダーに同じバイトを渡すだけ。

ファンアウト上限256パイプによって強制されるパスごとの受信側上限 — 転送が始まる前にその数を待つには ?n を設定。
レイテンシオーバーヘッド0バイトは到着するとパイプを通過。サーバー上のバッファリングなし — バックプレッシャーは受信側ごとに処理。
SDK フットプリント0 kbプロデューサーとコンシューマーは curl。HTTP を話すあらゆるものがサブスクライブできる — ブラウザ、コンテナ、エージェント、シェル。

LLM がストリーム。パイプがストリーム。リーダーがストリーム。中間レイヤーなし。

0101 · モデルがトークンを発行
0202 · パイプがバイトを転送
0303 · リーダーがそれらを適用
ステップ間にブローカーなしパスがプロトコル

これが置き換えるもの

あるプロセスが別のプロセスにリアルタイムでトークンをストリーミングする必要があるときに手を伸ばす配線。それぞれが独自のフレーミング、独自の SDK、独自の運用面を持つ。パイプがワイヤーだ。

  • LangChain ストリーミング抽象化コールバックチェーン、フレームワークロックイン
  • Server-sent events 配管フレーミング + ハートビート + 再接続ロジック
  • Redis pub/subインストール、運用、支払うブローカー
  • カスタム WebSocket リレー認証、再接続、バックプレッシャー全部 DIY
  • メッセージブローカー (Kafka, RabbitMQ)1 つのストリームのためのトピック、パーティション、コンシューマーグループ
  • エージェントフレームワークのコールバックベンダー固有、同じ SDK からのみ読み取り可能

すでに HTTP を話す 2 つのプロセス間でストリーミングインフラを配線するのを止めよう。パスを開く。そこにパイプ。そこから読む。

パイプ API を読む

他のユースケースを読む