During startup, model components such as text encoders are downloaded.
The Space then fails during startup with the ZeroGPU detection error.
Switching temporarily to CPU allowed the container to start further, but the UI still did not become available.
Connecting through a VPN also changed the behavior from Restarting to Starting.
Since two unrelated, previously working ZeroGPU Spaces started exhibiting the same ZeroGPU-specific error without corresponding code changes, could this be a ZeroGPU runtime/detection or infrastructure issue?
Could someone from the Spaces/ZeroGPU team check whether there is currently an issue with GPU function detection?
I can provide the Space IDs, build logs, and runtime logs if needed.
I’ve seen this behavior before on ZeroGPU Spaces, especially when the runtime changes on HF’s side. The fact that two previously working Spaces suddenly fail with “No @spaces.GPU function detected during startup” — without any code changes — strongly suggests an infrastructure-side issue rather than a bug in your project.
Just to clarify: ZeroGPU does not use your local physical GPU. So this error is not related to your hardware. It happens when the HF runtime fails to attach the virtual GPU during startup. I’ve seen identical failures after backend updates on the ZeroGPU infrastructure.
I’m using the same GPU class locally (GTX 1650 Ti / low-VRAM environment), and I’ve also experienced situations where GPU detection fails during startup even though the @spaces.GPU function is present at module level. In my case, the failure happened after a runtime update on HF’s side.
A few things you can try while waiting for HF staff to check the issue:
temporarily switch to CPU to confirm the rest of the app loads correctly
delay GPU initialization (ZeroGPU sometimes fails if GPU is requested too early)
add a minimal GPU-only function at the top-level to test detection in isolation
check whether the Space starts if you disable heavy model downloads during startup
I’m also working on a small GPU stability utility for low-VRAM cards and ZeroGPU environments. It focuses on preventing stuck contexts and VRAM fragmentation during model startup. I’m preparing a public demo soon — if you want, I can share it with you once it’s ready so you can test whether it helps your Space start more reliably.
But overall, given your description, this looks like something the ZeroGPU team should investigate. If you post the Space IDs, I’m sure they can check whether GPU detection is failing on their side.
I had tried switching, rebuilding, restarting, a lot of stuffs. Nothing actually worked, until i did a “Factory rebuild”. Spent about 3 hours trying different variations with ChatGPT help, nothing worked until I did Factory rebuild, without knowing what it actually did. Previously there have been few dependency failing issues since past couple of days, but I managed to get by them.
BTW I too have a GTX1650 4gb, 16gb ram system. But it heats up crazily and takes about 5 mins for a simple krea image gen. How do tou manage your ?
Since I’m using an RTX 3060 Ti (with a 3060 as a backup), I can’t really handle heavy computations locally. So, I use my local PC for lighter tasks. When running models in the tens of 10GB range, I use Google Colab or ZeroGPU.
Part of it is simply that powerful GPUs are too expensive for me to afford, but I also don’t want to own the hardware myself because technology advances too quickly. Just thinking about the heat dissipation and maintenance involved if I were to buy one makes my head spin.
I also run a GTX 1650 4GB, and I had the same issues in the past — high temperatures, slow generation times, and VRAM getting stuck after a few runs.
What helped me was keeping the VRAM clean between workloads. The 1650 has very limited memory, so once the pipelines get fragmented, generation speed drops heavily and the GPU starts heating more than normal.
I use a small VRAM‑cleaning tool I built for NVIDIA cards (GTX/RTX). It doesn’t touch Windows folders or system files — it only resets CUDA/DirectML contexts and frees VRAM that stays locked after AI workloads. On my system it keeps the 1650 stable and prevents the “5‑minute per image” slowdown.
If you want to try it, I can upload the NVIDIA demo to a Hugging Face Space so you can test it safely.
