Spaces:
Running on Zero
Running on Zero
Commit History
-
Tighten ZeroGPU reservation with a dynamic duration Running
generate_image previously used @spaces.GPU with the default 60s reserve, but Z-Image-Turbo at 9 steps finishes in ~3-5s. ZeroGPU reserves GPU time upfront based on the declared duration, so over-reserving 60s gives this Space worse queue priority and holds GPUs longer than needed — under high traffic that pile-up surfaces as 429 'Too many requests' to callers. Add get_duration(num_inference_steps) estimating steps*0.75s + 3s overhead (slightly over-estimated so runs never get killed mid-flight) and apply it via @spaces.GPU(duration=get_duration). Per HF ZeroGPU docs, a shorter accurate duration raises queue priority and frees GPUs faster, improving throughput for both this Space's direct users and the workflow frontends that call /generate_image via gradio_client. Co-Authored-By: Claude <[email protected]>5d4d3b8 -
Pin gradio to 6.20.0 (sdk_version + requirements.txt)
GLM 5.2Match the gr.Workflow frontend (mrfakename PR #92 / akhaliq/z-image-workflow test mirror), which is pinned to 6.20.0. Keeping the backend on the same gradio version avoids a cross-version gradio_client/call_space mismatch when the canvas forwards the visitor's HF OAuth token to /generate_image.d8a630b
-
Revert to pre-workflow Blocks backend (commit ad4a177)
GLM 5.2akhalq space is being repurposed as the @spaces.GPU backend that mrfakename's gr.Workflow frontend will call. The simplest way to make that work cleanly is to be the same shape as the original mrfakename duplicate (commit ad4a1778b2900e1f8106e71fd78471bea5e78aa6a on HF): app.py -> gr.Blocks with pipe + @spaces.GPU generate_image exposing /generate_image (signature: prompt, height, width, num_inference_steps, seed, randomize_seed); returns (image, seed_used) — exactly what mrfakename's Workflow's space operator will call. requirements.txt -> diffusers + transformers + kernels + gradio[mcp] (no `spaces`, no hf_oauth plumbing). README.md -> plain Hub-config frontmatter (no hf_oauth, no scopes). workflow.json -> removed; akhalq is no longer a workflow space. This is a byte-identical match to the pre-PR-#89 commit. The wrapping workaround for per-user metering …b7132b8 -
Revert PR #91 in app.py; trust the framework's token propagation
GLM 5.2A fresh gr.Workflow().launch() with the built-in Space operator confirms the framework already forwards the visitor's HF OAuth token (data[3]) on its own. PR #91 added a LocalContext.request.set() wrap to compensate on the hypothesis that the workflow call_fn path didn't propagate, but empirically: - signed-in == signed-out on our Space (no per-user benefit) - error text changed only in form, not in real quota/priority Either our wrap is redundant (framework already sets LocalContext and the proxy binds account identity without it), or our wrap *replaces* the framework's better-set LocalContext with a worse one (the inbound /component_server request, which carries only the IP-bound X-IP-Token with no account context). Both hypotheses point the same way: remove the wrap and let the framework's default propagation work. This commit is the surgical revert on my test space ONLY (mrfakename's deployed app.py is unchanged). Diff: - drop `from contextlib import contextmanager` - drop `f…d1cb4a8 -
Forward caller X-IP-Token so ZeroGPU meters per user
GLM 5.2The workflow's call_fn route injects the request via _special_args when a bound fn declares gr.Request, but does not publish it to LocalContext.request — and the ZeroGPU allocator/gradio_client reads the caller's X-IP-Token from LocalContext.request (see gradio_client.add_zero_gpu_headers). So every workflow call ran with the token missing and was metered as unauthenticated (2 min/day, lowest priority), saturating a busy Space for all visitors, signed-in PRO users included. This matches the reported 'reached its GPU limit' for everyone regardless of inputs/tier/sign-in. Fix: generate_image now accepts `request: gr.Request | None` (injected by _special_args; excluded from the workflow port schema so topology is unchanged) and wraps the @spaces.GPU call in a LocalContext.request context-manager that publishes the request for the duration of the call. This restores per-user ZeroGPU metering — PRO users get their 40 min / highest queue priority instead of being lumped into the Space's una…e05cf4f -
Clear ZeroGPU errors + accurate duration (keep showcase defaults)
GLM 5.2The 'Space app has reached its GPU limit' message is a Space-level capacity rejection (shared ZeroGPU pool saturated), not a per-user quota wall -- PRO users hit it too -- so the previous 'lower steps to save quota' framing was both dishonest and weak as a funnel. Real capacity lever: the bare @spaces.GPU held each slot for the 60s default even though a Turbo call finishes in seconds, hogging the Space's concurrent-GPU cap. Requesting an accurate dynamic duration turns slots over far faster, so far fewer users (PRO or not) get rejected. - app.py: keep the dynamic-duration GPU worker, but call it from a plain (non-GPU) generate_image wrapper that catches the allocator's pre-body rejection and rewords it into a clear, honest message: shared GPU busy -> retry; truthful PRO nudge (priority queue + 8x more daily GPU time -> through faster when busy), not 'upgrade to fix'. - workflow.json: restore 1024^2 / 9-step showcase defaults so the free experience is impressive; the wall, n…214eba7 -
Tune ZeroGPU usage: dynamic duration + cheaper defaults
GLM 5.2The "reached its GPU limit" error is the daily-quota throttle, not a bug. Per the ZeroGPU docs, shorter requested durations raise queue priority (the default 60s is far more than a Turbo call needs), and smaller/shorter calls burn less of the per-visitor quota. - app.py: @spaces.GPU(duration=_estimate_duration) -- a dynamic callable mirroring generate_image's signature, scaled by pixels and steps, clamped to [20,120]s. Avoids reserving a full minute per call. - workflow.json: lower defaults 1024^2 @ 9 steps -> 768^2 @ 7 steps. Z-Image-Turbo stays strong at these settings; each Run is shorter. These reduce both per-call quota cost and queue-rejection probability.b0e5c69
-
Drop inference-api OAuth scope
GLM 5.2ZeroGPU allocations are authorized via the Space's hosting tier and the OAuth token registered against the Space, not via the inference-api scope (which is for Inference Providers, not Space API calls). With hf_oauth: true and no hf_oauth_scopes, Gradio defaults to openid profile (both docs say they're always included).1fadc38 -
Single Space: workflow + @spaces.GPU fn bound via gr.Workflow
GLM 5.2Replace the cross-Space "spaces mode" workflow with a single-Space architecture: the frontend and the GPU worker share one process. - app.py: load DiffusionPipeline on ZeroGPU, bind generate_image (decorated with @spaces.GPU) to gr.Workflow. Image return value is serialized to a /gradio_api/file=... URL so the fn bridge stays JSON-only (matching how gr.workflow._save_tmp handles model/space image outputs). - workflow.json: operator is now kind:"fn" / fn:"generate_image" / source:"fn", wired to the same 6 input refs and 2 output subjects. - requirements.txt: restore diffusers + transformers + kernels + spaces. gradio[mcp] kept. - README.md: document the single-Space / @spaces.GPU-fn design. This PR will work as-is once merged into mrfakename's space: the workflow calls its own @spaces.GPU function (no self-loop API endpoint), so the ZeroGPU backend keeps running under the same frontend.8859027 -
Use Spaces mode: workflow calls mrfakename/Z-Image-Turbo Space
GLM 5.2Switch the gr.Workflow from the HF Inference API (model operator) to a space operator node that calls the mrfakename/Z-Image-Turbo Space's /generate_image endpoint via gradio_client. This surfaces all six generation parameters (prompt, height, width, num_inference_steps, seed, randomize_seed) on the canvas and captures both outputs -- Output Image and Seed Used -- as subject nodes. - workflow.json: space operator (space_id mrfakename/Z-Image-Turbo, endpoint /generate_image), 6 input refs -> 2 output subjects - app.py: pure gr.Workflow(graph=workflow.json); drop InferenceClient - requirements.txt: drop huggingface_hub (no longer called directly) - README.md: document the Spaces-mode architecture2546607 -
Pin gradio 6.20.0 and scope OAuth to inference-api only
GLM 5.2- sdk_version 6.20.0; requirements gradio>=6.20.0 - hf_oauth: true with a single hf_oauth_scopes entry (inference-api), since the workflow only calls the model via the HF Inference API and needs no repo read/write/gated/manage access3953d49 -
Convert app to gr.Workflow calling Z-Image-Turbo via HF Inference API
GLM 5.2Replace the local-diffusers/GPU Blocks app with a gr.Workflow pipeline: Prompt (reference) -> Z-Image-Turbo (model operator, fal-ai provider) -> Output Image (subject). Calls InferenceClient.text_to_image on Tongyi-MAI/Z-Image-Turbo, so no GPU or local weights are needed. - app.py: gr.Workflow(graph=workflow.json, bind={"text_to_image": ...}) - workflow.json: pre-wired schema-v2 canvas (model operator + edges) - requirements.txt: drop diffusers/torch/kernels, add huggingface_hub - README.md: pin gradio 6.1.0 (ships gr.Workflow), set hf_oauth: true639e5b2
-
Set output image format to PNG for higher quality (#56)
- Set output image format to PNG for higher quality (dd4666c603a7646b6910906b9237ca2e47081039) Co-authored-by: Boroll <[email protected]>ad4a177
-
fixed
Verified signature29b9fbc -
debug
Verified signature7f67510
-
allow MCP (#39)
Verified signature- allow MCP (71d776aa27638c7fa26eca4884211bcaf3e6b493) Co-authored-by: seyf EL <[email protected]>79c4bb8
-
Update app.py
Verified signaturee7338c1
-
Update app.py
Verified signature190e9bc -
Update app.py from anycoder
Verified signature81688cf -
Update app.py from anycoder
Verified signature4789a7f -
🎨 Redesign from AnyCoder (#5)
Verified signature- 🎨 Redesign from AnyCoder (a421fa1dd24b5b67591ff24585afbe328c543246)e28279b
-
Update app.py
Verified signature8da5cdc -
Update requirements.txt
Verified signature17f20b0 -
Update app.py
Verified signaturebfe4467 -
remove preload from hub
Verified signaturee9a1299 -
Performance enhancements (#2)
Verified signature- Update app.py (4a892379d783a3ac642585be81313dcee9a6262f) - Update requirements.txt (aa854da254c1ff82bda2ea19115b837e4bf2954e) - Create optimization.py (579120fd169946f14aeeb643af8be59976f32748) - Update app.py (b619a3366181b6ef0a418ea1e4594f4eefb7a101) - Update app.py (98b5ab5e7f8ecaeda306170041fa982d65679d49) - Delete optimization.py (0866e2dbdce41ed5aaaf637c53f2cf7786b259e8) - Update app.py (35a8941a336a4943855807004d4cdf43cfec017d)eee0c8d -
Update app.py
Verified signaturee17facd
-
Update app.py
Verified signature5d2046d -
Update app.py
Verified signaturec96ee5c -
Update app.py
Verified signaturec7d89d3 -
Update app.py
Verified signature3176199 -
Update requirements.txt
Verified signature5db0fcc -
Update requirements.txt
Verified signature95193ff -
ZeroGPU
Verified signature62594be -
Create app.py
Verified signature55fe803 -
Update README.md
Verified signature8c35c0c -
Update README.md
Verified signature5616c9b -
Create requirements.txt
Verified signatureeb41c7e -
initial commit
Verified signature187a4d9