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.
Anyway, that particular error can be worked around with a small tweak, but there are a few more traps after 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 Spaces documentation confirms that secret values are not inherited by duplicates.
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 now
This was the part that initially confused me too.
CPU Basic is still listed as:
2 vCPU
16 GB RAM
$0/hour
but the current Spaces Overview says that creating a compute-backed Gradio or Docker Space requires a paid plan.
There is now a specific exception for ZeroGPU: Free personal accounts in good standing (verified email and old enough to satisfy the account-age requirement) can host up to two ZeroGPU Spaces.
The same rule applies when duplicating a Space.
So this slightly strange situation is possible:
CPU Basic
hardware price = FREE
but creating/duplicating a compute Gradio Space = paid-plan gated
ZeroGPU
Free-account exception exists
therefore it may be the available free duplication route
In other words, choosing ZeroGPU here was not an unreasonable hardware choice by you. It is a consequence of how the current Spaces hosting rules interact with an older course template.
If you already have PRO / another plan that lets you create ordinary compute Spaces, I would simply use CPU Basic for this particular agent. It is conceptually cleaner because the template itself does not need a Space GPU.
The second trap: ZeroGPU quota and LLM inference credit are not the same thing
This distinction is easy to miss.
Current ZeroGPU Free accounts have a daily GPU quota; the ZeroGPU docs currently list 5 GPU-minutes/day for Free accounts.
But those GPU minutes apply to work executed through @spaces.GPU.
The Qwen model in this lesson is instead invoked through InferenceClientModel, which uses Hugging Face’s inference infrastructure / Inference Providers.
So:
ZeroGPU daily GPU quota
!=
Inference Providers monthly credits
The current Inference Providers pricing page lists the Free-account allowance as:
$0.10/month
with an explicit note that the amount is subject to change.
That is enough for some experimentation, so I would not say the course is impossible to try for free. But it is a very small allowance if you repeatedly experiment with an agent that can make several model calls per run (max_steps=6 in this template).
The dummy @spaces.GPU function above does not somehow route Qwen onto ZeroGPU. If you never call that dummy, the model inference is still happening remotely through the inference backend.
So I would think of the two resources as separate:
Free ZeroGPU Space
= a way to host the application
Inference Providers
= where the course's large LLM actually runs
For just completing the lesson, the included inference credit may be enough to experiment a little.
For sustained agent experimentation, I would use a capable hosted model backend rather than trying to force the 32B model itself into this Space.
smolagents is deliberately model/backend-agnostic; its current documentation supports InferenceClientModel, TransformersModel, LiteLLMModel and several other backends.
So if HF-routed credits become the limiting factor, other reasonable paths include:
- continuing with Hugging Face Inference Providers using paid/prepaid credit;
- using your own provider key where appropriate;
- using
LiteLLMModel with another provider.
For example, at the time of writing:
Those provider policies can obviously change, so I would check their current limits rather than treating any particular free quota as permanent.
The third/fourth trap: the course page and the Space template have drifted apart
There is another independent problem here: the current lesson and the Space that it tells you to duplicate are not quite from the same generation of smolagents.
The current Unit 1 tutorial shows:
from smolagents import ... InferenceClientModel ...
model = InferenceClientModel(...)
But the current First_agent_template/app.py still contains:
from smolagents import CodeAgent, DuckDuckGoSearchTool, HfApiModel, load_tool, tool
...
model = HfApiModel(...)
and its current requirements.txt is still pinned to:
smolagents==1.13.0
There is already an open upstream issue about this family of problems:
First_agent_template broken with smolagents > 1.13.0 — huggingface/agents-course #520
That issue reports that newer smolagents detects this missing prompt-template section:
Some prompt templates are missing from your custom prompt_templates:
{'final_answer'}
and specifically points out that pinning smolagents==1.13.0 masks the underlying template mismatch rather than repairing it.
There is also a much newer proposed fix:
First_agent_template PR/Discussion #717 — update smolagents 1.13.0 → 1.26.0
As of this post, it is still open / “Ready to merge”.
That patch is useful because it identifies essentially the same compatibility bundle:
HfApiModel → InferenceClientModel- adjust the
CodeAgent call for the newer API
- add the missing
final_answer section to prompts.yaml
- update the
smolagents dependency
So if you fix the ZeroGPU startup error and then encounter a different smolagents, constructor, import, or prompt-template error, I would treat that as this second problem rather than assuming the ZeroGPU workaround failed.
Why I suggested adding final_answer even if you keep 1.13.0
This is a slightly subtler bug.
Pinning to 1.13.0 avoids the newer startup-time validation, but 1.13.0 can still need the missing section later.
I tested the old template far enough to hit the agent’s maximum-step fallback. With the stock prompts.yaml, it eventually reached:
KeyError: 'final_answer'
because the fallback path tries to read:
prompt_templates["final_answer"]["pre_messages"]
prompt_templates["final_answer"]["post_messages"]
Adding:
"final_answer":
"pre_messages": ""
"post_messages": ""
was enough to make that fallback complete normally.
So for the minimal-change route, I would repair that small latent mismatch but otherwise leave the old dependency set alone.
If you do want to modernize the template
I would update it as a coherent set rather than changing one dependency at a time:
old HfApiModel
↓
InferenceClientModel
old smolagents pin
↓
current compatible smolagents
old CodeAgent constructor
↓
constructor matching that smolagents version
old prompts.yaml
↓
add final_answer template
PR #717 is a useful map for that migration, but I would check the diff rather than blindly applying it verbatim. For example, its current requirements.txt diff says:
smolagent==1.26.0
(singular), whereas the package is smolagents.
That looks like a simple typo, but it is another reason I would keep the minimal repair and the full modernization as two separate paths.
Optional: an entirely local CPU route also works, but I would not make it the default
I also wanted to see whether the Free ZeroGPU Space could be used merely as the hosting shell while running a tiny model on its normal CPU, avoiding hosted inference credit altogether.
smolagents officially supports this through TransformersModel.
I tried:
ibm-granite/granite-3.1-1b-a400m-instruct
on CPU.
That model is deliberately small and is documented for instruction following, code-related tasks and function-calling. A minimal direction is approximately:
smolagents[transformers]==1.13.0
transformers==4.47.0
and:
from smolagents import TransformersModel
model = TransformersModel(
model_id="ibm-granite/granite-3.1-1b-a400m-instruct",
device_map="cpu",
max_new_tokens=512,
)
while keeping the unused ZeroGPU dummy solely to satisfy the ZeroGPU startup check.
This did work mechanically:
ZeroGPU Space startup OK
model download/load OK
local CPU generation OK
Inference Providers needed no
CPU agent steps were on the order of roughly ten seconds in my test, which is quite usable for experimentation.
However, there is a reason I would consider this an educational fallback, not a replacement for the course’s 32B model.
The stock prompts.yaml contains many few-shot examples using explicitly “notional” tools such as:
document_qa
image_generator
translator
image_qa
search
visit_webpage
wiki
web_search
while the initial course agent actually registers only final_answer until you add tools yourself.
A large/capable model can usually follow the later instruction saying that those tools are merely examples.
The tiny Granite model was much more literal: it repeatedly generated something like:
search(...)
even though search was not an allowed tool.
Removing the irrelevant notional-tool examples immediately stopped that particular failure mode. It could then execute ordinary Python, and with an explicit instruction not to repeat an action after receiving the same observation, it also successfully called final_answer(...).
So the local-CPU route is real, but it changes the exercise:
Hosted capable model
→ closer to the intended course behavior
Tiny CPU model
→ no inference-provider bill
→ but you may also be debugging small-model/tool/prompt behavior
For learning how the plumbing fits together, that can still be useful.
For actually building a reliable agent, I would much rather keep a capable hosted model behind the Space.
So 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.
