Skip to content

AIExplore

How to Run and Explore Hugging Face Spaces Demos

Open Hugging Face Spaces built with Gradio, Streamlit, static apps, or Docker, test demos fairly, note ZeroGPU limits, and decide when a Space is enough versus your own deploy.

Hugging Face Spaces host interactive demos and apps on the Hub. Common SDKs include Gradio, Streamlit, static sites, and Docker. Many ML demos let you try models without writing client code first. Begin with the Explore page at /explore/huggingface.

This guide shows how to find Spaces, run fair tests, read hardware notes including ZeroGPU for eligible Spaces, and decide when to graduate to Inference Providers or your own hosting. Related reading: /blog/how-to-browse-and-try-models-on-the-hugging-face-hub and /blog/how-to-use-hugging-face-inference-providers-for-chat-completion.

When to explore Spaces

Use Spaces when you want a visual demo, a teaching tool, or a quick product spike. Spaces shine for Gradio model UIs, Streamlit data apps, and Docker wrapped tools. Do not treat a public Space as your production SLA. Cold starts, hardware tiers, and author maintenance vary.

ZeroGPU provides on demand GPUs for eligible Spaces. Availability and rules can change, so read the Space README and Hugging Face docs for current ZeroGPU behavior before you promise demo uptime to stakeholders.

Spaces are also a teaching surface. A clear Gradio layout can show product managers what a model does faster than a slide deck. That value disappears if the Space is undocumented, unmaintained, or secretly calling a different backend than the Hub model you plan to ship. Exploration is only useful when you capture what you saw.

How Spaces are organized

A Space repo includes app code, a README, and hardware settings. Gradio and Streamlit Spaces are common for ML demos. Static Spaces serve front end only apps. Docker Spaces package custom runtimes. Always open Files and README before you trust outputs for a decision.

Look for recent commits and open issues the same way you would for any open source app. A beautiful UI with a stale backend can waste a whole workshop. If the author links a Model Card and a dataset, open those too so your notes stay connected to Hub artifacts rather than to a one off demo feel.

Step by step Spaces exploration workflow

1. Define what the demo must prove

Write the question the Space should answer. Example: does this summarizer keep action items? Clear success criteria stop endless clicking.

Space test brief
Goal: verify meeting summarizer keeps decisions and owners
Must preserve: names, dates, action verbs
Fail if: invents attendees or deadlines
Hardware note: record if ZeroGPU or CPU only
Time box: 20 minutes

2. Open README, license, and hardware

Read how the author expects inputs. Note SDK type, duplicated model ids, and any API keys the Space needs. Check whether the Space stores prompts.

Space README review
Space id: user/space-name
SDK: Gradio / Streamlit / static / Docker
Hardware: CPU / GPU / ZeroGPU / other
Requires secrets: yes/no
Stores user inputs: unclear / yes / no
Model backends linked:
Decision: try / skip

3. Run a fixed golden input

Use one golden prompt or file across competing Spaces. Save screenshots or text outputs with timestamps so comparisons stay honest after UI changes.

Golden meeting notes
Attendees: Ana, Beau, Chris
Decision: ship v1 Friday if eval pass rate >= 90%
Action: Beau owns eval dashboard by Wednesday
Action: Chris drafts customer email after ship
Please summarize decisions and owners only.

4. Probe failure modes on purpose

Try empty input, huge input, mixed languages, and adversarial asks. Demo UIs often look great on happy path only.

Failure probes
1) Empty submit
2) 5k word paste
3) Non English paragraph if the card claims multilingual
4) Ask for private data the model should refuse
5) Duplicate submit to check queue behavior
Log: errors, timeouts, silent bad answers

5. Trace where inference actually runs

Some Spaces call Inference Providers, others load local checkpoints, others hit external APIs. Read the code tab. Knowing the backend tells you whether results will match your later SDK calls.

Backend trace notes
Calls Inference Providers: yes/no
Local model in Space: yes/no
External API: yes/no
Matches Hub model id we shortlisted: yes/no
If Providers: note model id and any :suffix in code
Next step if good: reproduce with InferenceClient

6. Decide keep, fork, or rebuild

Keep using the Space for demos if it is stable enough. Fork when you need small UI changes. Rebuild in your stack when you need auth, logging, or SLAs. SDK reproduction tips live in /blog/how-to-run-programmatic-inference-with-hugging-face-sdks.

Decision record
Space: user/space-name
Keep as public demo: yes/no
Fork for internal workshop: yes/no
Rebuild with Providers chat: yes/no
Owner:
Follow up ticket:

Copyable Spaces test templates

Use these prompts and checklists across Gradio, Streamlit, and Docker Spaces.

Gradio image demo test

Upload: product photo on white background
Prompt: Describe materials and colors only. Do not invent brand names.
Pass: no fake logos
Fail: claims a brand not visible
Also try: heavily cropped image

Streamlit data app test

Load sample CSV with columns date, country, revenue
Checks:
[ ] Filters change charts
[ ] Empty filter shows a clear message
[ ] Download button returns expected rows
[ ] No raw exception stack in UI

Docker Space smoke script notes

Docker Space smoke
[ ] Container builds on Space hardware listed
[ ] Health route or UI loads within time box
[ ] Secrets referenced in README are set in Space settings
[ ] Logs do not print tokens
Rollback plan: previous Space commit hash

ZeroGPU awareness checklist

ZeroGPU checklist
[ ] README mentions ZeroGPU or GPU on demand
[ ] First request may be slower (cold start)
[ ] Do not promise always on latency to customers
[ ] Have a CPU fallback story for workshops
[ ] Confirm eligibility in current Hugging Face docs

Side by side Space compare sheet

Space A | Space B
Latency feel:
Output quality (1-5):
Backend clarity:
License / card links:
Maintenance signals (recent commits):
Winner for workshop:

Embed or link decision

If embedding a Space in docs
Prefer: link out with expected input example
Avoid: silent iframe with no hardware warning
Add: last verified date
Add: golden prompt used

Workshop facilitator script

Facilitator script
1) Open Space README together (2 min)
2) Run golden input (3 min)
3) Run one failure probe (3 min)
4) Open Files to find model id (5 min)
5) Reproduce one call via Providers or local notebook
Capture: screenshots + model ids in shared notes

Security quick pass

Security quick pass
[ ] Do not paste customer PII into public Spaces
[ ] Check whether prompts are logged
[ ] Prefer private Spaces for internal data
[ ] Rotate any keys if a demo Space was shared widely
[ ] Treat outputs as untrusted until verified

Static Space content check

Static Space check
[ ] Links resolve
[ ] No broken model deep links
[ ] Clear CTA to Hub model or dataset
[ ] Last updated date visible
[ ] Contact or discussion link present

Tips and verification

Bookmark Spaces that include clear READMEs and linked Model Cards. Re verify before external demos. If you need datasets that match a Space schema, use /blog/how-to-explore-and-use-datasets-on-hugging-face. For publishing your own model behind a future demo, see /blog/how-to-upload-and-share-a-model-on-hugging-face.

After a useful Space session, write a five line handoff: Space id, golden prompt, backend model id, hardware note, and keep or skip decision. That handoff lets the next teammate skip the wandering phase and start from your evidence. Store it beside other Hub shortlist notes so demos, datasets, and model picks stay in one trail.

  • Read README and hardware before trusting outputs
  • Use golden inputs across competing Spaces
  • Trace whether Providers, local weights, or external APIs power the UI
  • Treat ZeroGPU as on demand, not always on
  • Keep PII out of public demos

Common mistakes

  • Treating a public Space as a production endpoint with an SLA
  • Skipping README hardware and secrets sections
  • Comparing Spaces with different prompts and calling it a model bakeoff
  • Pasting confidential data into a public Gradio app
  • Assuming ZeroGPU means always on dedicated GPUs
  • Never opening the Files tab to see how inference is called
  • Embedding stale Spaces without a last verified date

Related Hugging Face articles: /blog/how-to-browse-and-try-models-on-the-hugging-face-hub, /blog/how-to-use-hugging-face-inference-providers-for-chat-completion, and /blog/how-to-run-programmatic-inference-with-hugging-face-sdks. Return to /explore/huggingface for the tool overview.

Related articles