| --- |
| title: Zerogpu Workflow |
| emoji: 👀 |
| colorFrom: blue |
| colorTo: blue |
| sdk: gradio |
| sdk_version: 6.20.0 |
| python_version: '3.12.12' |
| app_file: app.py |
| pinned: false |
| short_description: gr.Workflow serialization experiment on ZeroGPU |
| --- |
| |
| # gr.Workflow serialization experiment on ZeroGPU |
|
|
| This Space demonstrates that `gr.Workflow` (canvas UI) executes all node runs sequentially, process-wide, instead of in parallel. The workflow is defined in `workflow.json`: a text input (`Prompt`) feeds a two-node chain, and the final text lands in an output node (`Result`). |
|
|
| - `generate`: a `@spaces.GPU` function that sleeps 5 seconds (stand-in for GPU inference). It records its start/end timestamps and the attached GPU name in its output. |
| - `visualize`: a plain CPU function that sleeps 3 seconds and passes the text through, also with timestamps. |
|
|
| ## How to reproduce |
|
|
| 1. Open this Space in two browser tabs. |
| 2. Type a distinct input in each tab's `Prompt` node (e.g. `tab1` / `tab2`) and click Run in both tabs within a second or two. |
|
|
| ## What to observe |
|
|
| If runs were parallel, both tabs' `Result` nodes would fill in roughly 8 seconds after clicking, and the Space page would show 2 concurrent GPUs while both `generate` calls are in flight. |
|
|
| What actually happens (the bug): |
|
|
| - The concurrent-GPU indicator stays at 1. |
| - The timestamps embedded in the `Result` text show strict serialization across tabs: tab2's `generate` starts right when tab1's `generate` ends, and the `visualize` steps queue behind both (`gen1 -> gen2 -> vis1 -> vis2`). |
| - Tab 1's `Result` stays on "Waiting for output..." far longer than its own work takes — its rendering is blocked while tab 2's nodes run. |
| - While any node is running, the whole app is unresponsive for everyone (page loads stall too). |
|
|
| Root cause: each canvas node runs via `POST /gradio_api/component_server/`, whose handler calls the synchronous workflow server functions directly on the asyncio event loop, with no threadpool offload. One running node therefore blocks the entire server process. |
|
|
