Skip to main content
Router はパートナーモデルを、1回の同期 HTTP 呼び出し、または送信して後で結果を取得するキュー中のリクエストを通じて実行します。アプリケーションが完了した結果を待つことができ、あるいは後で結果を取得でき、さらにモデル自身の入力フィールドと出力フィールドを処理できる場合に使用します。

Router がサポートするもの

キューによる送信

同期ルートは、モデルの実行中も接続を開いたまま保持します。非同期プロバイダーの場合、Router はジョブを送信し、内部的にポーリングします。代替となるのはキューによる配信(送信し、request_id を取得し、ポーリングし、収集する)です。詳しくはキュー配信を参照してください。これは認証情報の背後にあるワークスペースにスコープされるため、Comfy ワークスペースで作成したキーが必要です。ワークスペースを持たないレガシーキー、bring-your-own-key リクエスト、またはキューで実行できないモデルは、送信ルートで not_enabled とともに 403 を返します。どちらのモードもコールバックや Webhook は提供しません。 リクエストを十分な時間開いたままにできない場合は、キューに投入してください。プロバイダー自身の送信とポーリングの制御が必要な場合は、パートナープロキシを使用してください。 現在、2 つのモデルは同期専用であり、キューに送信すると 403 / not_enabled で拒否されます。elevenlabs/eleven_sfx_v2 と elevenlabs/eleven_v3 です。これらは JSON の結果ドキュメントではなく生のオーディオバイト列を返すため、キューによる配信にはそれを保存する場所がありません。同期ルートで実行してください。同期ルートはこれらのバイト列を通常どおり返します。 LTX v1 のテキストから動画へ、および画像から動画への操作も同じ理由で生のビデオバイト列を返すため、キューによる配信ではそれらを保存できません。ただし、これらに到達できるのは /proxy/ltx/v1/… のパートナープロキシ経由のみであり、Router のモデル id からは到達できません。すべての ltx/* カタログモデルは、キューに投入可能な v2 の送信とポーリングの操作に解決されるためです。

サーバーのデッドラインで呼び出しが打ち切られます

Router のデフォルトのデッドラインは 10 分で、デプロイメントごとに設定できます。Router が先にエラーとリクエスト ID を返せるよう、クライアントのタイムアウトをそれより長く設定してください。 504 / deadline_exceeded は Router が待機を停止したことを意味し、504 / provider_timeout はプロバイダーがタイムアウトしたことを意味します。タイムアウトや接続の喪失は、生成が課金されなかったことを証明するものではなく、受け入れ済みのプロバイダー側の処理をキャンセルするものでもありません。再試行する前にタイムアウトと収集をお読みください。

リカバリはプロバイダーに依存する

Router は、承認された送信とポーリング形式の生成に対して、プロバイダーのハンドルを保持できます。同じ Idempotency-Key を再利用すると、後でそれを回収できます。完了した再生可能なレスポンスも、キーの記録から取得できます。 切断されたすべての呼び出しがリカバリできるわけではありません。送信する前にリクエストとキーを保存しておき、リトライ結果テーブルを使用してください。新しいキーは新しい呼び出しを作成し、別途課金が発生する可能性があります。

リクエストボディの上限

Router は、ボディが 100 MiB (104,857,600 bytes) を超えるリクエストを拒否します。この上限は送信する生のバイト数に対して適用され、Router があらゆる解析を行う前に測定されるため、すべてのルート、および同期配信とキュー配信の両方に適用されます。 インラインのメディアが、呼び出し元がこの上限に直面する場面です。Base64 エンコードはバイナリデータを約 4/3 に膨らませるため、エンコードされたメディアを含むボディは、実際の画像・オーディオ・ビデオのバイト数がおよそ 75 MB で上限に達します。ディスク上のファイルではなく、エンコード後の文字列のサイズを見積もってください。また、1 回の呼び出しに含まれるすべての入力を数えてください。参照画像を 2 枚含むリクエストは両方にこの許容量を消費し、プロンプト、パラメータ、JSON 構造も同様にカウントされます。 拒否される場合の挙動。 413 で、他のレスポンスと同様に X-Comfy-Error-Type に invalid_input が設定され、X-Comfy-Request-Id も設定されます。ボディは RouterErrorResponse で、その detail に超過した上限が記述されます。detail を解析するのではなく error_type で分岐し、このページと API の返す内容が食い違う場合は API の返す内容を正としてください。Router は何かをディスパッチする前に拒否を発生させるため、生成は実行されておらず、課金もされていません。 この上限は、Idempotency-Key を伴うかどうかに関係なく、すべてのリクエストに適用されます。これは冪等性の制限ではなく、同じキーを再送しても結果は変わりません。大きすぎるボディは何度試しても大きすぎるのです。 プロバイダーが独自の、より低い制限を課すことがあり、この上限では通常そうなります。 プロバイダーはインラインのメディアについて独自の上限を公開しており、より小さいほうが拘束条件となります。たとえば Google のモデルは、インラインペイロードとして最大 20 MB (10 進数で 20,000,000 bytes) を受け付けます。Google のモデルページにある Size limit: 20MB の行は、Google 自身の仕様から引用したフィールド単位の Google の上限であり、リクエストボディ全体に対する Router の上限ではありません。Router の上限は、それが前面に立つすべてのパートナーの上限より意図的に高く設定されているため、単一のインラインアセットについては通常プロバイダー自身の制限に先に達します。Router の上限が効いてくるのは、1 つのボディに複数のアセットが含まれる場合です。Router の上限は超えないもののプロバイダー自身の制限を超えるボディは、Router ではなくプロバイダーによって拒否され、413 ではなくプロバイダーのエラーとして返されます。

リクエストは呼び出し元ごとにレート制限される

リクエストレートの制限は、呼び出しとカタログ/スキーマの読み取りに適用され、生成前に拒否されたリクエストも含まれます。これはソース IP ではなく、認証された呼び出し元に従います。呼び出し元のプロバイダーキーを使用した呼び出しは対象外ですが、プロバイダーの制限は引き続き適用されます。 カタログとスキーマの読み取りはキャッシュしてください。スキーマは ETag と If-None-Match で再検証してください。再試行とコミット済み支出のフィールドについてはヘッダーを参照してください。

呼び出しの実行中は進捗が表示されない

Router は最終レスポンスのみを返し、ストリーミングされるトークン、サーバー送信イベント、パーセンテージの更新、中間プレビューフレームはありません。プロバイダーの内部ポーリング状態は、リクエスト中に転送されません。 不確定な進捗インジケーターを表示してください。進捗やストリーミングが必要な場合は、それを公開しているパートナープロキシ操作を使用してください。

Comfy の課金と使用量

レスポンスにはプロバイダーの使用量やコストのフィールドが含まれる場合があります。これらは Comfy の一律の課金を表すものではありません。X-Comfy-Credits-Used はオプションであり、リプレイされません。残高、使用量、請求書については Comfy プラットフォームを使用してください。 カタログは価格ではなく、billing.charges_on_policy_rejection などの請求に関する事実を提供します。yes、no、unknown を明示的に処理してください。詳細は billing を参照してください。

Routerはすべてのパートナー操作をカバーしていない

Routerはモデルを実行します。ファイルのアップロード、アカウントの読み取り、アセット管理、ストリーミング、プロバイダーのジョブ制御には、/proxy/… 配下のパートナープロキシルートが必要になる場合があります。Comfy API specification を確認してください。サポートはプロバイダーによって異なります。

モデルの出力と保存されたアセット

入力フィールドと出力フィールドはモデルによって異なります。プロバイダー SDK やプロキシから移行すると、ルートと結果の読み取り方法の両方が変わる可能性があります。 一部のアセットは Comfy ストレージに再ホストされます。その他はプロバイダーの URL またはインラインバイトです。有効期間とリプレイ動作については、結果アセット を参照してください。

次のステップ

クイックスタート

Comfy Router を通じて最初の画像を生成します。

Router API の使用

モデルを選択し、そのスキーマを確認して、結果と再試行を処理します。