Skip to main content
モデルを選択し、そのスキーマを確認して、POST /v2/models/{provider}/{model} を呼び出します。ルートと認証はモデル間で変わりません。

カタログの検出

生成に使用するのと同じAPIキーでモデルを一覧表示します:
省略したカタログレスポンス:
呼び出しパスでは id を使用します。billing オブジェクトには価格ではなく、課金に関する事実が含まれます。それに依存する前に、ポリシー拒否時の課金 を読んでください。

ページネーション

  • has_moretrue の場合は、返された next_cursorcursor として渡します。has_morefalse になったら、前のページが要求より短かったとしても停止します。
  • カーソルは不透明なものとして扱います。値は URL エンコードします。たとえば cURL では --get --data-urlencode "cursor=$NEXT_CURSOR" を使用します。オフセットを計算したり、カーソルを変更したりしないでください。
  • limit のデフォルトは 20 で、上限は 100 です。上限を超える値はクランプされます。ゼロとネガティブな値はデフォルトを選択します。レスポンスには、実際に使用された limit が報告されます。
  • 無効なカーソルは 400 / invalid_input を返します。リストを暗黙的に再起動することはありません。
  • カーソルはカタログの更新をまたいでも有効なままである可能性がありますが、走査はスナップショットではありません。現在位置より前に追加されたモデルは、その走査に現れないことがあります。
503 / service_unavailable は一時的なものです。バックオフしながら再試行してください。空のカタログとして扱わないでください。SDK の run メソッドは、選択済みのモデルを直接呼び出します。

1つのモデルを読み取る

モデル ID がわかっている場合は、カタログエントリを直接取得します。
モデル詳細エンドポイントを使えば、カタログ全体をたどる必要はありません。エントリの完全なフィールドについては API リファレンス を参照してください。

入力スキーマと出力スキーマを読み取る

各モデルはスタンドアロンの OpenAPI ドキュメントを公開しています:
モデルのオペレーション内では、requestBody が入力を表し、200 レスポンスは、出力スキーマが作成されている場合に出力を表します。入力の検証と出力のドキュメント化は別物です。Router は自身の入力スキーマに対して検証を行いますが、返されたプロバイダーの結果を出力スキーマに対して検証しません。 出力のフィールドだけでなく、メディアタイプも確認してください。作成されていない出力は */* を使用することがあり、一部のモデルは JSON ではなくバイナリデータを返します。

スキーマをキャッシュする

スキーマとその ETag を保存します。後でスキーマを取得する際に、その ETag を If-None-Match で渡します。304 にはボディがありません。キャッシュしたドキュメントを保持してください。200 は置き換え用のドキュメントと ETag を提供します。
スキーマルートは Cache-Control: private, must-revalidate を使用します。認証済みレスポンスは共有キャッシュに保存しないでください。この ETag/304 の動作はスキーマエンドポイントにのみ適用されます。

検証とフォールバックスキーマ

作成済みの入力スキーマは、プロバイダーの呼び出し前に不正なフィールドを 422detail[] 配列で拒否します。loc 内のフィールドパスを確認してください。詳細は検証エラーを参照してください。 一部のスキーマは任意の JSON オブジェクトを受け入れ、x-comfy-input-schema-authored: false を設定します。ルーターはそれらのリクエストをモデル固有の検証なしで転送するため、プロバイダー側で拒否される可能性があります。 bfl/flux-2-pro は現在このフォールバックを使用しています。必須フィールドについては、プロバイダーのドキュメントまたはそのモデルページを確認してください。

結果を読み取る

Router は各モデルのターミナル結果の形状を返します。共通の画像、ビデオ、テキストのエンベロープはありません。BFL の画像出力は result.sample を使用しますが、他のモデルは URL のリストやインラインバイトを返すことがあります。 一部のアセット URL は Comfy によって再ホストされますが、それ以外はプロバイダーの URL やインラインバイトのままです。結果アセットを確認し、有効期限のあるアセットは速やかにダウンロードしてください。リプレイでは URL は更新されません。

エラー、リトライ、課金の処理

エラーを防御的に読み取る

失敗したリクエストは、プロキシの HTML エラーページ、切り詰められた JSON、またはプレーンテキストを返すことがあります。JSON パースエラーによって HTTP ステータスやリクエスト ID が隠れないようにしてください。以下のヘルパーは、Python では httpx.Response、TypeScript では Fetch の Response を使用します。SDK は通常の SDK 呼び出しに対してすでにエラーフィールドを公開しています。

バリデーションエラー

Router の 422 は、プロバイダーの呼び出し前に検証に失敗したことを意味し、課金されません。そのボディには detail[] 配列があり、拒否されたフィールドごとに 1 つのエントリが含まれます。エラーカテゴリはボディではなく X-Comfy-Error-Type にあります。例:
これは一例の形状です。寛容な入力スキーマを持つモデルは、Router の 422 を返す代わりに、不足しているフィールドをプロバイダーに転送することがあります。 400 は、このフィールド単位の検証ボディではなく、不正な形式のカーソルなど、リクエストレベルの問題を表します。サポートされているカテゴリはエラーリファレンスに記載されています。制御フローでは、不明なカテゴリを internal_error として扱いますが、診断用にオリジナルの値は保持してください。新しいエラー値を厳密に拒否したり、予測されるエラーカテゴリがすでに発生しているかのように実装したりしないでください。

安全にリトライする

送信する前に、キーをモデル ID とリクエストボディとともに永続化します。その論理呼び出しのすべての試行で同じキーを再利用します。Router はレスポンスで Idempotency-Key を返しません。Python SDK は発生した例外にキーを含めますが、TypeScript では自分で指定したキーを自分で保持しておく必要があります。 キーは、認証情報が持つワークスペース内で共有され、ワークスペースを持たない場合はユーザーにスコープされます。そのスコープ内で一意な UUID を使用し、同じ認証情報でリトライしてください。別のワークスペースメンバーのキーを再利用すると、そのメンバーの記録済みの結果が返されたり、競合が発生したりする可能性があります。認証情報を変更すると、別の課金対象呼び出しが開始されることがあります。 Router はキー付きのレスポンスまたはコレクションの状態を 24 時間保持します。リトライしても新しい保持ウィンドウは開始されません。その状態が期限切れになった後は、古いキーで結果を復元できることや、新しいディスパッチを防げることを期待しないでください。また、キーがあっても期限切れのアセット URL が再び使用可能になるわけではありません。

タイムアウトと収集

リトライの結果

競合は method、model パス、クエリ、ボディを比較します。過大なレスポンス、レスポンスの書き込み失敗、または安全に再生できないアセットの後、キーは再生不能になることがあります。待機しても消費された結果は回復しません。新しいキーは新しい呼び出しを開始するものであり、古い出力を取得するものではありません。 プロバイダーへのディスパッチ前の拒否はキーを解放します。ディスパッチされた呼び出しはプロバイダーハンドルを保持するか、再生不能になる可能性があります。ステータスコードだけからキーの状態や課金を推測しないでください。 呼び出しがタイムアウトした、または接続が切断されたという理由だけで、まったく新しいキーを発行しないでください。Router がすでに生成を受け入れていた場合、新しいキーは 2 つ目の論理実行を作成し、したがって 2 つ目の課金対象の結果を生む可能性があります。元の呼び出しが回復不能であるとわかるまで、同じキーを再利用してください。

タイムアウトと収集

1 回の Router 呼び出しは、デフォルトで接続を 10 分間保持することがあります。クライアントのタイムアウトをその上限より上に設定すると、不透明なローカルアボートではなく、型付きの 504 とリクエスト ID を取得できます。 deadline_exceeded は Router の待機制限で、provider_timeout はプロバイダーの期限です。完了したプロバイダーの生成は、呼び出し元がタイムアウトを受け取ったか切断されたとしても、課金される可能性があります。クライアントのキャンセルは待機と SDK のリトライを停止しますが、受け入れられたプロバイダー処理を必ずしもキャンセルするわけではありません。 送信とポーリングを行うプロバイダーの場合、保持されたハンドルにより、同じキーのリクエストが元の生成の収集を続けることができます。回復可能なハンドルなしで遮断されたディスパッチ済み呼び出しは、再生可能な結果なしにキーを消費する可能性があり、同じキーでのリトライは 409 を返します。成功が捕捉されていないプロバイダー起因の一時的な失敗でも、別の試行のためにキーを解放することがあります。ハンドルが存在しないだけでは、どの結果が該当するかはわかりません。 SDK は一部の失敗を限られた予算内でリトライします。エラーを返したら、新しいものを生成するのではなく、リクエストとキーを保持してください。生の HTTP の場合、この例では 2 つの明示的な収集ヒントのみをリトライします:
元のモデル、ボディ、保存したキーを渡します。これは試行回数を制限するもので、合計の実時間を制限するものではありません。各呼び出しはクライアントのタイムアウトまで続く可能性があり、各待機は Retry-After に従います。HTTP エラーは検査用にレスポンスを保持し、トランスポートエラーはキーを置き換えることなく伝播します。アプリケーションがより長い回復ウィンドウを必要とする場合は、保存したキーで後で収集をスケジュールしてください。

モデル課金の仕様

GET /v2/models とモデル詳細レスポンスには billing.charges_on_policy_rejection が含まれます。これはポリシーによる拒否について説明するものであり、すべての失敗や価格の見積もりを表すものではありません。 これらの文字列は明示的に比較してください。"no" は Python と JavaScript では真値(truthy)です。認識できない値はすべて unknown(不明)として扱ってください。クレジット不足により拒否されたリクエストは insufficient_credits を返します。 プロバイダーのペイロードには独自のコストや使用量の数値が含まれることがありますが、それらは Comfy の課金ではありません。X-Comfy-Credits-Used は許可リストに登録されたプロバイダーでは表示されることがありますが、すべてに共通するものではなく、再送もされません。突き合わせにはワークスペースの使用量と請求書を使用してください。課金を調査する際はリクエスト ID を保持してください。

モデル別の例

次へ