README.md

metadata

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.