大多数の魅力的な AI アプリケーションは、複数のステップから成るパイプラインとして構成されています。まず画像を生成し、必要に応じて背景を切り抜いたり、まったく新しい内容に編集したりできます。スクリプトを書いてから音声を生成することも、スクリプトを変えずに声だけ差し替えることも可能です。通常は Python でこれらのステップをつなぎ合わせますが、結果がおかしいときには、結局 print を使ったデバッグに戻り、どのステップで異常な値が生成されたのかを突き止めることになります。
Gradio に直接統合された gr.Workflow を使えば、パイプラインそのものをインターフェースにできます。各ステップを型付きノードからなるグラフとして定義すると、Gradio がドラッグ&ドロップに対応したキャンバスを提供します。各ノードを実行できるだけでなく、途中の結果もすべて分かりやすく確認できます。同じグラフが自動的に REST API になり、1 つのコマンドで Hugging Face Spaces にデプロイすることも可能です。
この概念を理解する最良の方法は、実際に動作しているワークフローを見てみることです。以下で紹介するアプリはすべて、開いて実行したり、コピーしたりできる Hugging Face Space です。
画像を編集する
画像をアップロードし、編集指示(「雪の積もった冬の風景に変える」「サングラスをかける」「車を赤くする」など)を入力すると、編集後の画像が得られます。アプリ全体は、Hugging Face Inference Providers 上の Qwen-Image-Edit を呼び出す 1 つのノードだけで構成されています。
実際のモデルをつないでメディアスタジオを構築する
1 枚の画像から、3 つのパイプラインを実行します。プロンプトを入力すると、まず FLUX で画像を生成し、それを背景を削除する Gradio Space に渡してステッカーに変換します。また、テキスト読み上げ Gradio Space でテーマのナレーションを生成し、同じテーマを LLM に渡して、魅力的な番組タイトルに変換することもできます。
キャンバス全体には、Hugging Face Inference Providers を介したモデル呼び出しが 2 回、Gradio Spaces の呼び出しが 2 回含まれています。
ワークフローであるため、3 つの出力にはそれぞれ独自の REST エンドポイント(/sticker、/voiceover、/episode_title)があります。UI を開かなくても、コードから任意のエンドポイントを直接呼び出せます。実行可能なサンプルについては、以下のコードから呼び出すセクションをご覧ください。
画像生成を並列に拡張する
アイデアを入力すると、アート作品のセットを一度に生成できます。FLUX で生成したベース画像、その画像を AI で再創作した 2 枚の画像(柔らかな水彩画風と、ネオンのサイバーパンク風)、そして LLM が作成したギャラリータイトルが生成されます。
各画像は、Inference Providers を利用するモデルノードによって、プロンプトから直接生成されます。一方、タイトルは LLM を呼び出す fn ノードから生成されます。これはファンアウト(fan-out)パターンの実例です。1 つのアイデアを複数の処理ノードに同時に渡し、並列にコンテンツを生成できます。
Hugging Face データセットを分析する
stanfordnlp/imdb や mteb/tweet_sentiment_extraction などの Hugging Face データセット ID を入力すると、1 つの入力が 4 つの処理ノードにファンアウトされ、Datasets Server API を使ってデータセットをリアルタイムに分析します。
概要カード、先頭数行のデータプレビュー、列ごとの統計情報、分布グラフを確認できます。これらはすべて独立して並列に計算されます。これこそがワークフローの力です!
👉 データ探偵を試す
独自の GPU モデルを実行する
ここまでに紹介した各ノードは、いずれも Hugging Face にアクセスしていました。しかし、fn ノードの本質は Python であるため、Space 内部の GPU 上でモデルを実行することもできます。
バインドされた関数に @spaces.GPU デコレーターを追加すると、ノードの実行時に ZeroGPU がその呼び出しのために GPU を 1 基確保し、モデルを実行した後に GPU を解放します。常に Inference Providers や既存の Gradio Spaces に頼る必要はありません。
デモとして、Diffusers で読み込んだ Lightricks/LTX-Video を使って静止画像をアニメーション化する例をご覧ください。この処理は 1 つのノードだけで完結します。gr.Workflow は GPU の構成を意識する必要がなく、バインドされた関数を呼び出すだけで動作します。
仕組みの概要
各ワークフローは、3 種類のノードからなるグラフです。参照(references)(入力)、オペレーターノード(operators)(タスクを実行するステップ)、そして サブジェクト(subjects)(出力)で構成されます。オペレーターノードには、独自の Python 関数、Hugging Face Inference Providers 上のモデル、別の Gradio Space、あるいは Hub データセット内の 1 行を指定できます。型付きポート同士をドラッグして線でつなぎ、実行ボタンをクリックすれば、各結果が対応する場所に表示されます。
コードから呼び出す
構築したワークフローは、追加の操作なしで自動的に API になります。各出力は、そのラベルを名前とする REST エンドポイントになります。Gradio クライアントを使えば、Python から呼び出すことができます。以下は、複数のエンドポイントを持つデモ Space に対する実際のサンプルで、トークンなしでそのまま実行できます。
from gradio_client import Client
client = Client("ysharma/gr-workflow-multi-endpoint-API")
print(client.predict("hello there friend", api_name="/word_count")) # -> 3print(client.predict(20, api_name="/fahrenheit")) # -> 68.0モデルや Space のエンドポイントを呼び出す場合は、Hugging Face トークンの権限で実行されるため、クライアントの作成時にトークンを渡す必要があります。
from gradio_client import Client, handle_file
client = Client("ysharma/gr-workflow-image-editor", token="hf_...")
edited = client.predict( handle_file("dog.jpg"), "turn it into a snowy winter scene", api_name="/edited_image",)通常の HTTP を使いたい場合は、各エンドポイントに curl からもアクセスできます。
curl -s https://ysharma-gr-workflow-multi-endpoint-API.hf.space/gradio_api/call/word_count \ -H "Content-Type: application/json" -d '{"data": ["hello there friend"]}'独自のワークフローを構築する
最も手軽な始め方は、上記のデモのいずれかを開いて Duplicate をクリックし、ノードをつなぎ直してみることです。Python では、コードを次のように短く記述できます。
import gradio as gr
def your_function(text: str) -> str: pass
gr.Workflow(bind=[your_function]).launch()完全なチュートリアル、オペレーターノードの種類、JSON Schema、再利用可能なパターンについては、Gradio ドキュメントの公式 gr.Workflow ガイドをご覧ください。
gr.Workflow を使えば、AUTOMATIC1111 のような複雑なアプリケーションも構築できます。次回の記事では、その構築方法をステップごとに紹介する予定です。まずは、その概要を少しだけご覧ください 😉👇