Gradio、AIパイプラインを実行可能なノードグラフに変換――ただしキャンバスとAPIの並列実行セマンティクスには依然として差異

Hugging Faceは8月25日、`gr.Workflow`の完全な利用ガイドを公開した。従来はPythonで手動接続する必要があったモデル、データセット、Gradio Space、カスタム関数を、型付きポートを備えたノードグラフとして表現できる。関連コード自体は7月末にリリースされたGradio 6.22.0ですでに登場していた。今回の更新で重要なのは、新たなモデルや推論バックエンドではなく、デプロイ、API、権限に関するセマンティクスが公式に整備された点だ。

ワークフローはreference、operator、subjectという3種類のノードで構成され、それぞれ入力、処理ステップ、出力を表す。OperatorはHugging Face Inference Providers、リモートSpace、Hubデータセット、または`bind=`で登録したPython関数を呼び出せる。グラフはschema version、ノード、型付きポート、エッジを含む`workflow.json`として保存されるため、バージョン管理の対象にできるほか、プログラムエージェントが直接生成または変更することも可能だ。現在サポートされる型には、テキスト、画像、音声、動画、数値、JSON、ファイル、`any`がある。ただし、関数シグネチャの推論は意図的に簡素なままであり、複数出力やメディア型については、通常はJSONを手動で修正する必要がある。

出力ノードを含む連結部分グラフは、それぞれ自動的にGradio REST endpointとなる。デプロイには引き続き`gradio deploy`とSpacesを使用する。これにより、研究用プロトタイプを、観察可能なノードキャンバスから直接呼び出し可能なサービスへ移行できる。中間結果もノード単位で再実行できるため、画像生成、データプロファイリング、複数モデルを組み合わせたメディアパイプラインに特に適している。

エンジニアは2つの境界に注意する必要がある。第一に、インタラクティブキャンバスでは依存関係の深さが同じ分岐を並列実行するが、REST APIから起動した場合は現時点で逐次実行される。そのため、レイテンシ、GPU使用量のピーク、タイムアウト時の挙動がまったく異なる可能性がある。第二に、ローカルで起動するとワークフローへの書き込みが可能な非公開URLが生成される一方、Spacesへデプロイした場合、所有者を識別するにはOAuthを有効にする必要がある。書き込み用URLが漏えいすると、訪問者が全員に表示されるパイプラインを変更できる可能性がある。今後は、API executorがいつ同等のDAG並列スケジューリングを実装するのか、またschema migrationや複数ユーザーによる編集競合をどのように処理するのかが注目される。