i tried to duplicate the agents example using zeroGPU cz it’s the free one , but i get this error runtime error
Hmm… at first I thought, “Why ZeroGPU??” …but apparently with a Free account now, ZeroGPU is basically the only compute-backed Gradio option you can host yourself… I didn’t know that.
The immediate error:
No @spaces.GPU function detected during startup
does not look like a smolagents
or Qwen error. It is ZeroGPU rejecting the Space at startup because it cannot find a function decorated with @spaces.GPU
.
For this particular course template, I would take the minimal route first rather than trying to move the agent itself onto the GPU.
Add this near the imports in app.py
:
import spaces
@spaces.GPU(duration=1)
def dummy_gpu():
return None
and leave the function unused.
The documented/intended ZeroGPU pattern is, of course, to decorate an actual GPU-dependent function; see the ZeroGPU documentation. The decorator causes a GPU to be allocated when the decorated function is called and released afterward.
But this course agent does not actually need a Space GPU for its LLM inference, so I tested the unused dummy-decorator variant in a duplicated ZeroGPU Space, and it was enough to get past this startup check.
I would also make one tiny preventive edit to prompts.yaml
while you are there:
"final_answer":
"pre_messages": ""
"post_messages": ""
Add that as a top-level section near the end of the file.
And make sure that your duplicated Space has an HF_TOKEN
Secret with inference permission. Secrets are deliberately not copied into duplicated Spaces; the course itself asks you to recreate HF_TOKEN, and the
For the smallest-change course path, I would therefore do only this initially:
1. Keep the template's smolagents==1.13.0 for now.
2. Add the unused @spaces.GPU dummy.
3. Add the three-line final_answer section to prompts.yaml.
4. Recreate/check HF_TOKEN.
5. Rebuild.
I would not upgrade all of smolagents
at the same time unless you actually want to modernize the template, because there is a separate version-drift problem hiding behind this one.
The important conceptual warning is that getting the ZeroGPU Space to start does not mean that Qwen-32B is now running for free on ZeroGPU. Those are two different systems.
ZeroGPU
→ hosts the Gradio Space / allocates GPU to @spaces.GPU calls
InferenceClientModel
→ calls a remotely hosted model through Hugging Face Inference Providers
The current course page explicitly uses:
model = InferenceClientModel(
max_tokens=2096,
temperature=0.5,
model_id="Qwen/Qwen2.5-Coder-32B-Instruct",
custom_role_conversions=None,
)
and describes Qwen2.5-Coder-32B-Instruct as being accessed through the serverless API.
So there are really several independent traps layered on top of each other here.
Why choosing ZeroGPU on a Free account actually makes sense nowSo my mental model for this particular failure would be:
Trap 1:
Free-account Space policy
↓
ZeroGPU becomes the practical free Gradio-hosting route
Trap 2:
ZeroGPU expects @spaces.GPU
↓
old course template has none
↓
"No @spaces.GPU function detected"
Trap 3:
getting ZeroGPU to start does NOT put Qwen-32B on ZeroGPU
↓
the LLM still uses Inference Providers
↓
separate inference credits / provider limits apply
Trap 4:
the current lesson and duplicate template have version drift
↓
HfApiModel vs InferenceClientModel
smolagents 1.13.0 pin
missing final_answer prompt
other migration differences
For your immediate problem, though, I would not try to solve all four layers at once.
I would start with just:
import spaces
@spaces.GPU(duration=1)
def dummy_gpu():
return None
plus:
"final_answer":
"pre_messages": ""
"post_messages": ""
make sure HF_TOKEN
exists, and rebuild.
If that starts, then the original ZeroGPU error is solved. Any error after that is much easier to classify as an inference/token/provider issue or as the separate template-version issue above, rather than one giant mysterious Space failure.